[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <bb8f0468-0624-4058-aa53-9d1b5ae8097d@gmail.com>
Date: Fri, 16 Jan 2026 19:44:28 -0600
From: Jacob Bachmeyer <jcb62281@...il.com>
To: oss-security@...ts.openwall.com, Peter Gutmann
<pgut001@...auckland.ac.nz>, Demi Marie Obenour <demiobenour@...il.com>,
Collin Funk <collin.funk1@...il.com>
Cc: "kf503bla@...k.com" <kf503bla@...k.com>
Subject: Re: Re: Best practices for signature verifcation
On 1/15/26 21:50, Peter Gutmann wrote:
> Demi Marie Obenour writes:
>
>> To answer your last question: I believe that it is sufficient for the TSA to
>> sign the public key, hash algorithm, and signature algorithm used to make the
>> signature, as well as the signature itself.
> That's more or less what a TSA does anyway, but it doesn't address any of the
> other issues. I think the required approach would be to start with a threat
> model and work from there, not with a given technology and say "the threat is
> whatever this tech counters" (which is admittedly the standard "threat model"
> used in 99% of all crypto designs).
>
> So you'd have:
(simple solutions proposed)
> Signed malware
>
> An attacker can use a compromised key to sign malware. To deal with this ...
... revocations include a timestamp of the last-known-before-compromise
signature. If legitimate releases were made after the key was
compromised, they MUST be re-signed using the new key.
The timestamp attestation is simply a certification that the artifact
was presented to the timestamping authority at that time. If the signed
timestamp is prior to the first-compromise timestamp in the revocation
certificate, the signature can still be considered valid (although the
user SHOULD be informed that the signature is from a key that was later
found to have been compromised and has therefore been revoked). If the
signed timestamp is *after* the known first-compromise, the signature is
from a revoked compromised key and invalid.
> Rollback attacks
>
> Once a binary is signed, it's universally trusted. An attacker can feed in an
> older signed binary (with an vulnerability) in place of a newer one that has
> the vulnerability fixed. To deal with this ...
... the user is expected to catch the attempted substitution and
packaging tools MUST warn the user before installing an older version
over a newer version. (The version numbers themselves are part of the
signed information, so the attacker cannot alter them.)
-- Jacob
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
