laying groundwork for an eventual migration away from SHA1 with gpg

[David Shaw]

On May 8, 2009, at 5:00 PM, Daniel Kahn Gillmor wrote:

>> 2) If signers use SHA-256 for new signatures, he is completely  
>> foiled.
>
> Right.  However, if you've got a DSA-1 key, you're using SHA-1 by
> default, no?  At best, signatures from a DSA-1 key would be made by
> 160-bit truncated versions of other hashes.  This is good, because  
> it's
> not the same algorithm that has currently been attacked.  but it's  
> also
> not the full-strength SHA-2 families either.

Yes.  I was expecting signers to use *all* of SHA-256.

It would be interesting to know if the new attack works against  
SHA-256.  Not in the sense that it could bring SHA-256 down to 2^52,  
but in the sense that it could bring it to something less than 2^128.

> If you don't think that strong crypto protection against impersonation
> is important, that's fine.  But I'd like to be able to offer the  
> people
> i support the ability to have their cryptosystem *not* be the weakest
> link in terms of identifying themselves.  At the moment, there do seem
> to be certainly faster, easier, cheaper ways of doing it (though some
> organizations don't publish their results, so i can't know for  
> certain).
> Anyway, I'd rather not wait until the math and CS catches up and  
> forces
> our hand.

I don't mean there are faster/easier/cheaper ways of doing this  
mathematically.  I mean boring old subterfuge like going to a  
keysigning party with a fake ID, claiming to be someone else.  I get a  
bunch of signatures, and I'm done.  It skips the whole difficult math  
problem.

I'm all for strong crypto protection against impersonation, but when  
there is a non-crypto impersonation attack that has essentially the  
same end result as a crypto impersonation attack, and the non-crypto  
variant of the attack is vastly cheaper, faster, and easier than the  
crypto attack, I do start to wonder what the point is of putting a  
strong crypto defense against the crypto attack.

> I really appreciate the discussion on this list, by the way (not to
> mention the incredible infrastructure that y'all have given us in the
> form of gnupg).  Even if we find we can't come to an agreement on the
> transition steps to take right now, it's certainly a respectful
> disagreement from my end.

Certainly.  This is the sort of thing that reasonable people can  
disagree on.  I don't think that your plan is wrong or evil or  
anything like that.  I just worry it's rather eager to expunge SHA-1.   
The plan pushes a 3-month window to migrate to SHA-256 and revoke all  
earlier keys.  We're not particularly close to having any collision at  
all, much less the finesse necessary to "weaponize" that collision  
generating process into an attack on OpenPGP.  The plan text doesn't  
really say this, though, and instead puts forth a perception that is  
scarier than (I think) the reality is.

I'm afraid that the plan document is going to result in scared people,  
and scared people do very dumb things.  I'm already seeing various  
pieces of posted advice around the net to do stuff like immediately  
switch to 4096-bit keys or force SHA256 via 'digest-algo', or use  
SHA512, or other things that can actually cause more harm than good.   
There are a good number of ways to shoot yourself in the foot with  
GPG, and I've seen a good few of them in the past week or so.  I  
suspect more are coming.  People don't understand that changing their  
various hashes to SHA-256 pretty much puts a kink in communication  
between them and every version of PGP and GPG from before 2004 or so  
(the SHA-512 people are even worse off).  But they're scared, so they  
do it.  And there is fallout.

David