On 01/08/2009 05:34 PM, tz wrote:
To analyze the RFC, the internal structure of the key certificates
which are signed need to be analyzed (first there has to be a current
source for new things with MD5 anyway, I'd have to come up with two
things to be signed, a real one which will be signed and the rogue one
that has the same MD5 hash).
I suppose i should have been more explicit: i'm not concerned about this
specific attack working against OpenPGP. It just got me to thinking
about various ways that an abused hash function could cause a PKI
failure, and how the community around that PKI could respond to such an
attack.
The X.509 community was able to respond by further deprecating MD5
because there was a parameterized method in place to switch to another
hash function. OpenPGP currently has this in place almost everywhere a
hash function is used. That's good!
However, there are a few places where we don't have that agility, which
is what i was trying to highlight. Actually doing the switch from one
hash algorithm to another within a well-defined parameterized structure
is a chore, but it's doable. My concern is that there are places in
OpenPGP (fingerprints being the most worrisome place) where we would be
unable to actually make such a transition should there be a
cryptographic result rendering that hash function unusable.
I don't think there are many such things in place, but I would look if
there are any legacy signers (including prominent people with older
keys or implementations). I think after PGP5 it would be very
unlikely, but I would look for something that allowed, requested, or
forced "backward compatibility", i.e. if there are bits or something
else I can cause the hash algorithm to be MD5.
Doing a test of common implementations of OpenPGP to see if they give
adequate warnings based on use of deprecated algorithms would be good,
though this was not intended to be the point of my initial message. For
example, the following series of commands generates warnings on
signature creation, but not on signature verification, afaict:
echo test > test
gpg --digest-algo MD5 --clearsign test
gpg --verify test.asc
Is this the desired behavior? Or should there be a warning during
verification that the signature was based on a deprecated hash? What
about during certification verification or web of trust calculations?
How do other implementations approach this scenario?
--dkg
signature.asc
Description: OpenPGP digital signature