Dealing with weakness in SHA-1 [LWN.net]

Dealing with weakness in SHA-1

Posted Jun 18, 2009 6:55 UTC (Thu) by djpig (subscriber, #18768)
Parent article: Dealing with weakness in SHA-1

As Gillmor's migration guide indicates, Debian is trying migrate its developers, maintainers, and teams away from SHA-1 digests and DSA keys and towards RSA keys with SHA-512 digests.

Using Debian as the subject of any sentence is always questionable ;). Notably, the position of the Debian keyring maintainer is a little more relaxed than the article suggests.

(Log in to post comments)

Dealing with weakness in SHA-1

Posted Jun 18, 2009 10:45 UTC (Thu) by dd9jn (subscriber, #4459) [Link]

It seems to me that most folks look too often at the attacks of faking a signature and come up with stronger keys to mitigate that. However, to protect an infrastructure it is better to take the view of an attacker and what he would do to mount an attack, for example, on a packaging system.

For sure he would not try to play with rogue signatures but use some simple vulnerability to get access to a developer's machine or an FTP server or whatever. This is far easier in terms of time needed and cost involved than anything else. The signatures on packages are okay, but what does such a signature actually tell us: The package has been created by a project's developer! It does not tell us how diligent he manages his machine, from where he got the upstream source, what tools he used for building and editing, how strong the door to his room is protected, how he manages his secret key, what other software is running on the development box, whether he uses HTML mail (like the author of the article) and thus possible easier to attack mail readers, and so forth.

Precomputed collisions in a properly setup PKI, like the one used by Debian, requires the secret key of the developer. Thus such an attack is irrelevant - we can't protect ourself against a rogue developer.

Rushing out mainly unneeded fixes is one thing, preparing for the future is better and that is what we are doing with GnuPG. In a few years we will have a large installation base of modern GnuPG versions and then switching to a more modern algorithm will be far easier than what Daniel is currently proposing.