[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A review of hash function brittleness in OpenPGP



The other exploit was also complex and required finding collisions
which was not trivial but possible with MD5.  The key seemed to be
that the separate bits of the certificate were in places which made
the exploit easy, e.g. the top half was either static or predictable,
but there was a comment field (which could be stuffed with the bits to
generate the collision), then the big prime product.

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 think the simplicity of the
certificates might make it more difficult, but that is where I would
look.

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.

On Thu, Jan 8, 2009 at 12:59 PM, Daniel Kahn Gillmor
<dkg@xxxxxxxxxxxxxxxxx> wrote:
> Hey folks--
>
> I've been trying to evaluate RFC 4880's resistance to a hash function
> compromise in light of the recent activity exploiting weaknesses MD-5 in
> That Other PKI [0].
>
> I'm quite pleased with the bulk of what i've found.  OpenPGP's use of
> message digests is almost entirely parameterized, leaving the door open
> to forward-looking adoption of new hash algorithms and the smooth
> deprecation as older ones are demonstrated to be weak.
>
> So I've been looking for places in the spec where the choice of digest
> function is not parameterized.  In particular, explicit and hardcoded
> reliance on SHA-1 could become problematic as it is already being
> deprecated.  For example, reliance on SHA-1 must be eliminated in all US
> Gov't federal agencies by the end of 2010 [1].
>
> Here are the concerns i've found so far:
>
> MDC
> ---
>
> The modification detection packets (sections 5.13 and 5.14) explicitly
> specify SHA-1, and basically acknowledge that this choice may need to be
> made more flexible in the future.
>
> Fingerprints
> ------------
>
> Fingerprints (section 12.2) are specified as an SHA-1 computation.
> While this isn't an explicit reliance on SHA-1 for cryptographic
> security (and the RFC makes it clear that there is a non-zero chance of
> fingerprint collisions), the real-world use of fingerprints as unique
> identifiers for keys poses a serious risk to OpenPGP infrastructure
> should SHA-1 become further compromised.
>
> Revocation keys
> ---------------
>
> Section 5.2.3.15 defines a way that key A can allow key B to
> authoritatively issue revocation signatures on A's behalf, including key
>  revocation (sigtype 0x20), subkey revocation (sigtype 0x28), and
> certification revocation (sigtype 0x30).  However, this mechanism relies
> on the fingerprint of B being unique.  Since the fingerprint itself is
> bound to SHA-1, this presents a risk to users of this feature of the
> specification should SHA-1 become further compromised.
>
>
>
> As the IETF working group for OpenPGP, we probably should start actively
> working to resolve these issues so we can have infrastructure in place
> well before SHA-1 is similarly compromised.  Any suggestions?  I'm new
> to the WG, so i don't have any experience addressing concerns like this.
>
> I'm particularly concerned about fingerprints, since they is used widely
> in the real world (e.g. i have my fingerprint on my business card).  I
> can imagine relatively straightforward technical measures to resolve the
> other concerns.
>
> Also, it's quite likely that i've missed things in my reading of the
> spec.  If anyone sees any other problematic areas, it would be great to
> air them as soon as possible.
>
> Regards,
>
>        --dkg
>
> [0] http://www.phreedom.org/research/rogue-ca/
> [1] http://csrc.nist.gov/groups/ST/hash/statement.html
>
>