removing SHA1 from digest preference list
dshaw at jabberwocky.com
Sun May 3 02:43:17 CEST 2009
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
> list of preferred digests (hash functions). (it also automatically
> includes 3DES in the list of preferred ciphers, for some reason). For
>> 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
> recent results have any practical traction, it seems like we might
> 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.
More information about the Gnupg-devel