removing SHA1 from digest preference list

[David Shaw]

On May 2, 2009, at 7:43 PM, Daniel Kahn Gillmor wrote:

> Hi folks--
>
> In light of the recent SHA1 advances, i thought i'd look into what it
> would take to remove SHA1 from my list of preferred ciphers for a  
> given key.
>
> it seems that  gpg2 automatically enables SHA1 (albeit at the end of  
> the
> list of preferred digests (hash functions).  (it also automatically
> includes 3DES in the list of preferred ciphers, for some reason).  For
> example:
>
>> Command> setpref AES256 TWOFISH ZLIB BZIP2 ZIP Uncompressed SHA512  
>> SHA384 SHA256 SHA224
>> Set preference list to:
>>     Cipher: AES256, TWOFISH, 3DES
>>     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
>>     Compression: ZLIB, BZIP2, ZIP, Uncompressed
>>     Features: MDC, Keyserver no-modify
>> Really update the preferences? (y/N)
>
> I don't see anything in the RFC to indicate that SHA1 must be included
> in the list of preferred hashes:

It's in section 13.3.2. Hash Algorithm Preferences:

    Since SHA1 is the MUST-implement hash algorithm, if it is not
    explicitly in the list, it is tacitly at the end.  However, it is
    good form to place it there explicitly.

There is similar language about 3DES in the cipher list (section 13.2).

In other words, GPG is not required to tell people it's there, but it  
is required to put it there.  GPG does tell people it's there as this  
is less confusing than it would be if someone saw 3DES was selected  
and had no idea why.  The basic idea behind all this is that it  
guarantees the the preference system can always succeed: even if two  
keyholders completely disagree on every possible algorithm choice,  
they must eventually agree on 3DES / SHA-1 / Uncompressed.  So the  
bottom line is that you can't remove it.  It's inherent in the  
protocol.  You can certainly rank it lower than other algorithms if  
you want to, though (as in your example above).

> There's no reason to force-include MD5 in the list of digests, for
> example, even though gnupg is capable of implementing it, right?  If  
> the
> recent results have any practical traction, it seems like we might  
> want
> to be able to exclude SHA1 in the same way that we currently exclude
> MD5, no?

Unfortunately, OpenPGP has a few spots where SHA-1 is hardwired into  
the design.  For example, key fingerprints are SHA-1, and cannot be  
anything else.  This will eventually change - even before this recent  
SHA-1 problems, the writing was on the wall for SHA-1.  Even a  
completely un-cracked SHA-1 was scheduled to "expire" off the NIST  
algorithm list after 2010.

My main advice for people concerned about the SHA-1 problem is to  
migrate away from 1024-bit DSA keys, as these keys require a 160 bit  
hash (i.e. SHA-1 or RIPEMD/160).  You can replace the keys with either  
DSA2 keys (i.e. DSA keys that are larger than 1024 bits) or RSA keys  
(there are various arguments for either choice here).  Either way,  
there is no need to go crazy and frantically revoke 1024-bit DSA keys,  
but you should at least have a migration plan.

David