Daniel A. Nagy | 9 Jan 2009 01:03

Re: A review of hash function brittleness in OpenPGP

Daniel Kahn Gillmor wrote:
> 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!

As far as I can judge, X.509 PKI is still in the state of catastrophic failure
with no obvious way out.

Right now, if my browser (or yours, or anybody else's) tells me that the site I
am browsing presented a certificate issued to it by a legitimate CA, I cannot be
sure that this assertion is true. Rejecting all certificates with MD5 in their
signatures is not a solution (there are too many out there and replacing them
requires non-trivial cooperation between different parties; no-one can do it
acting alone). Not issuing any more MD5-based certificates is not a solution
(who knows how many rogue CAs are already out there?). In fact, I do not see an
easy and cheap solution out of this mess.

It is a good thought-experiment to assess the consequences of an existential
collision attack on SHA1 such as the one we have for MD5 on OpenPGP security,
considering all the places where SHA1 is wired in. I haven't checked every
corner of RFC4880, but I can see no catastrophic failure akin to what happened
to X.509 PKI.

--

-- 
Daniel

Ben Laurie | 9 Jan 2009 15:51

OpenPGP:SDK v0.9 released


I thought people might be interested in this now somewhat-complete,
BSD-licensed OpenPGP library...

http://openpgp.nominet.org.uk/cgi-bin/trac.cgi/wiki/V0.9

--

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Jon Callas | 10 Jan 2009 22:56
Gravatar

Re: A review of hash function brittleness in OpenPGP


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jan 9, 2009, at 4:16 PM, Ben Laurie wrote:

>
> Jon Callas wrote:
>> (Let me put on my hash-designer's hat for a moment. In Skein, we
>> created a one-pass MAC construction that can replace HMAC. It also  
>> has
>> a proof of security.
>
> I wish people would stop saying that things have "a proof of  
> security".
> Rot13 has a proof of security, but I don't want to use it. You need to
> state what security properties you have proved.

If we're going to get picky, Rot-13 is not a cipher, it's a code. It  
has similar security properies to ASCII, which is a related code. But  
you're right -- on another list I'm on, there was someone who made the  
comment that there's no theoretically perfect cryptography. I almost  
replied that the Caesar cipher (which is ROT-N) has perfect security,  
just an inadequate key space.

Nonetheless, you're right. Many people including me sneer at security  
proofs. The list of things that have had proofs of security and then  
fallen over is large. There are plenty of proofs of security that have  
some people raise an eyebrow. For example, we say that HMAC is secure  
on today's slightly dodgy hash functions because of a proof of  
(Continue reading)

Florian Weimer | 11 Jan 2009 18:04
Picon

Re: A review of hash function brittleness in OpenPGP


* Daniel Kahn Gillmor:

> 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.

There's the issue of V3 keys.

If packet formats are changed once again, it could make sense to
incorporate random blobs near the start of the packets, so that an
attacker cannot predict the internal state of the hash function when a
signature is created.  OpenPGP does not need the convergent property
of hash functions.


Gmane