Thanks everyone for this discussion. Deprecating SHA-1 is a big goal of
the cryptographic refresh that we hope to have in shape for WG last call
within a few months. This discussion shows that deprecation is never as
easy as just turning off an algorithm, especially with store-and-forward
mechanisms like OpenPGP.
On Mon 2022-04-25 14:39:32 +0200, Justus Winter wrote:
I think it is more complicated than that. First, there are two
hash algorithm properties to consider: collision resistance and preimage
resistance. If the attacker controls data being signed, collision
resistance is required. But, that is not the case for binding
signatures.
I think it's even a bit more subtle than Justus makes it out here. It's
true that if the attacker controls the data being signed, collision
resistance is required. It's also true that a proper subkey binding
signature does not contain any attacker-provided data.
But consider an attack where the attacker asks the victim for a data
signature over data that the attacker does provide, and knows that this
signature is going to come from the victim's certification-capable
primary key.
If the attacker can create a collision, they may be able to create a
collision where one side of the collision is the data stream that
represents a data signature, and the other side represents a subkey
binding signature. Then if they can convince the victim to create a
data signature, they can apply that same signature object to a subkey
binding over material that they control.
The same rule goes for the "signature creation time" timestamp in every
signature. While it's tempting to say "we will accept signatures made
before time X", if "before time X" is based solely on the signature
context itself (and not, for example, on known custody of the
signature), that's a bad idea.
The signature's embedded context markers -- including both the timestamp
and the signature type, which denotes subkey binding signatures -- are
potentially part of a collision attack.
So, it is the act of making *any* signature using SHA1 over
attacker-controlled data that represents the risk to the victim. And
the relying party that sees a single signature cannot know whether the
signature in question was made by the victim in the context that the
relying party sees, due to failures in collision resistance.
So it is not unreasonable for an implementation aware of concerns about
failing collision resistance to be concerned about subkey binding
signatures too.
Second, rejecting a signature carries a risk too: if you reject a
revocation signature, then you will continue to use a key that the
holder asked you not to use.
If an attacker is able to forge a revocation signature for a key because
the keyholder has risky signing practices (e.g. making a signature over
attacker-supplied data using a digest algorithm with known flaws in
collision resistance), that is just about the nicest thing an attacker
can possibly do with that capability.
I would be uncomfortable rejecting a revocation signature just because
it uses SHA1 if you're willing to accept any other signature that uses
SHA1.
In addition, some revocation signatures are made over SHA1 at key
creation time (back when SHA1 was the only reasonable choice), and
selfsigs over stronger hash algorithms might have been made in the
meantime. Fully rejecting all SHA1-based revocation signatures would
mean invalidating those stored revocation signatures, which might be a
problem for people who end up needing to use them.
Implementations that store revocation certifications as a backup
recourse for the user should probably inspect those backup revocation
certifications and -- if they're made with weak digest signatures --
update them whenever the user is doing certificate maintenance.
--dkg
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp