moving in an orderly fashion toward the theater exits,deprecating SHA-1 where possible with an eye toward abandoning it soon (one point of reference: US gov't federal agencies have been directed to cease all reliance on SHA-1 by the end of 2010, and this directive was issued before the latest results).
Since Debian relies heavily on OpenPGP and other cryptographic infrastructure, i'll be blogging about how Debian users can responsibly and carefully migrate toward better digests. This post focuses on some first steps for users of gpg, and for Debian Developers and Debian Maintainers in particular.
The good news is that gpg and gpg2 both support digest algorithms from the stronger SHA-2 family: SHA512, SHA384, SHA256, and SHA224.
By using these stronger digest algorithms some of your signatures may be un-readable by users of older software. However, gpg and PGP (a proprietary implementation) have both had support for at least SHA256 for well over 5 years. Debian's gnupg packages have supported the full SHA-2 family since sarge.
However, most existing signatures in today's Web of Trust were made over the SHA-1 digest algorithm, which means that abandoning it immediately would cause the Web of Trust as we know it to evaporate. So we need to rely on SHA-1-based signatures until a reasonably-fleshed-out Web of Trust based on stronger digests is in place. Since we don't want to have to rely on SHA-1 for too much longer, we need to collectively start the transition now.
So what can you do to help facilitate the move away from SHA-1? I'll outline three steps that current gpg users can do today, and then i'll walk through how to do each one:
The simplest thing that you can do is to start making signatures using stronger digests by default. Add three lines to the end of your GnuPG configuration:
cat >>~/.gnupg/gpg.conf <<EOF personal-digest-preferences SHA256 cert-digest-algo SHA256 default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed EOF
This will cover most messages sent out, including clearsigned messages that are sent to mailing lists, and signatures over Debian packages. The last line ensures that when you create new keys, the new keys will prefer stronger digests.
Your preferences for the types of digest you wish to receive will be published to the public keyservers, so people who send you signed messages will know that you can (and prefer to) accept messages signed by stronger digests. The example assumes that your OpenPGP key ID is $KEYID:
test@foo:~ $ gpg --edit-key $KEYID gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Secret key is available. pub 2048R/8A4EA1C3 created: 2009-05-06 expires: 2010-05-06 usage: SC trust: ultimate validity: ultimate [ultimate] (1). Test User (DO NOT USE) <test@example.org> Command> showpref [ultimate] (1). Test User (DO NOT USE) <test@example.org> Cipher: AES256, AES192, AES, CAST5, 3DES Digest: SHA1, SHA256, RIPEMD160 Compression: ZLIB, BZIP2, ZIP, Uncompressed Features: MDC, Keyserver no-modify Command> setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed Set preference list to: Cipher: AES256, AES192, AES, CAST5, 3DES Digest: SHA512, SHA384, SHA256, SHA224, SHA1 Compression: ZLIB, BZIP2, ZIP, Uncompressed Features: MDC, Keyserver no-modify Really update the preferences? (y/N) y You need a passphrase to unlock the secret key for user: "Test User (DO NOT USE) <test@example.org>" 2048-bit RSA key, ID 8A4EA1C3, created 2009-05-06 pub 2048R/8A4EA1C3 created: 2009-05-06 expires: 2010-05-06 usage: SC trust: ultimate validity: ultimate [ultimate] (1). Test User (DO NOT USE) <test@example.org> Command> save test@foo:~ $
The important command here is the weird, long setpref line — you need to type the whole thing:
setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP UncompressedNote that we're setting digest, cipher, and compression preferences all at once here. Note also that gpg displays the implied 3DES cipher and SHA1 digest at the end of your stated preferences even though you did not ask for them. This is because RFC 4880 requires implementations to support these two algorithms, and gpg is subtly informing you that people might end up using them anyway, even though you aren't asking for them.
Now that the preferences are updated, publish them to the public keyservers so that your correspondents can discover them:
test@foo:~ $ gpg --keyserver keys.gnupg.net --send-key $KEYID gpg: sending key 8A4EA1C3 to hkp server keys.gnupg.net test@foo:~ $
That does it!
The Digital Signature Algorithm, in its original form, only allowed maximum 1024-bit asymmetric keys, and the signature process itself signs a 160-bit hash, initially officially specified as SHA-1. This means that 1024-bit DSA keys should be phased out as well.
So if you have a 1024-bit DSA key as your primary key (this is the vast majority of Debian Developers: 1675 out of 2243 keys in /usr/share/keyrings/debian-keyring.gpg are DSA-1024), you should consider creating a new primary key and starting the migration process.
Also, if you are responsible for a DSA-1024 OpenPGP primary key for a Debian team, role, or archive, please consider something similar to the process below for the Debian-related key as well. I'm happy to note that the Debian Archive Automatic Signing Key (5.0/lenny) <ftpmaster@debian.org> has a 4096-bit RSA primary key, but unfortunately most of our other important infrastructural keys are still 1024-bit DSA.
A reasonable migration process over the course of 3 months might be:
keys you've signed) with your old key. For keys you believe to still be active, check with the key owner, and verify that they are still in control of the key. If they are, consider issuing a new certification with your new key. If you get a request for new keysignings, use your new key during this period.
I welcome comments and suggestions about anything i've missed or screwed up here. The steps above do not complete the removal of SHA-1, but (if most of us take similar action soon) they lay the groundwork for an orderly and non-disruptive abandonment of SHA-1 in the future. The sooner this groundwork is in place, the less susceptible our infrastructure will be to potential compromise by reasonably-well-funded organizations.
That wraps up this set of suggestions. As i work through other consequences and practicalities around the gradual deprecation of SHA-1, i'll post more notes on this blog. Questions and pointers are welcome!
UPDATE: I've clarified step 5 of the key transition process above in response to feedback from David Shaw: please make sure the keyholder is still active and in full control of the key before re-issuing certifications.
Another UPDATE: i've added a new suggestion to the ~/.gnupg/gpg.conf additions, to set default-preference-list so that new keys are generated with stronger preferences. Thanks to David Crick for the suggestion.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
We could get similar benefits with a DSA2 key, but DSA2 is not nearly as widely implemented as RSA is, so is not a good option for a default key at this time.
And i was under the impression that while DSA2 allows the use of larger hashes, it does so for smaller keysizes only by truncating them to the size of the traditional hash for that keysize. So a key transition (to a larger DSA key) would be necessary at any rate to take advantage of the full strength of the larger hash.
If you're going through a key transition, switching to a more widely-used standard seems reasonable to me, but i would be happy if people switched to DSA-2048 instead. I wanted to make simple, clear recommendations in the main piece here, so i picked RSA because of the above reasons. Thanks for broadening the discussion a bit, though. If you have pointers to good arguments why people should switch to DSA-2048 instead of RSA-2048, i'd be happy to read them.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Cards with Version < 2.0 support RIPEMD-160 and SHA-1 onlybut version 2.0 appears to support digests from the SHA-2 family, up to and including SHA-512.
But if you're stuck with a pre-2.0 card? I don't have a good answer for you. Maybe get a 2.0 card? Even the 2.0 card still only supports 1024-bit RSA, though, which is smaller than any key you'd want to use more than a year from now (e.g. ssh-keygen has been creating 2048-bit RSA keys since etch).
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
3 independent 2048 bit RSA keys (signing,encryption,authentication).
Key lengths reducable to 1024 bit; key length of signature keys increasable to 3072 bit.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
While RIPEMD-160 is an option, the longer digest lengths of SHA-2, more intense public scrutiny of SHA, and wider adoption of RSA seem like they add up to a better plan for the future to me. But i would be happy to hear evaluations of the situation from people with a stronger crypto background than myself. I'm pretty much learning as i go here (as usual).
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
But i wanted to provide a set of instructions that will cause people the least hassle while still building the post-SHA-1 WoT.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
However, i tend to interact more with the free software world, so perhaps upgrade paths for my peers are less onerous than they would be for people with proprietary vendors.
If anyone does run into trouble with the certifications or data signatures i produce, please e-mail me about it! My e-mail address is well-bound to my OpenPGP key (0xCCD2ED94D21739E9), and i'd be happy to help diagnose any trouble if it happens.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Oh great I see. So gpg will just automatically create the sign/encrypt pair on DSA/ElGamal keys, and just create a master key for RSA, so I have to manually create the encryption subkey.
Thanks for explaining.
--------
Felipe Sateler
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
My understanding is that the string-to-key (S2K) use of a digest algorithm in OpenPGP does not rely on the collision-resistance of the digest itself, the way that digital signatures do.
Basically, what S2K does is to take a human-memorizable string (like "th1s1sMY53krit%pazzwd" -- note:do not use this password!) and munge it up to make a stronger key that itself is used to encrypt (via a standard symmetric cipher like AES) your actual secret key material. The goal of S2K is to ensure that this new key has each bit position be equally-likely to be 0 or 1. It also is designed to force a user to spend computational resources to do this, to make recurrent attacks harder. Why do this? Some things to notice:
0 dkg@pip:~$ printf "%s" "th1s1sMY53krit%pazzwd" | hd 00000000 74 68 31 73 31 73 4d 59 35 33 6b 72 69 74 25 70 |th1s1sMY53krit%p| 00000010 61 7a 7a 77 64 |azzwd| 00000015 0 dkg@pip:~$This is due to the fact that UTF-8 (and other character encoding schemes) are reasonably well-organized, and that humans tend to use certain characters (like "e") more frequently than other characters (like "q"). Compare this to the distribution of bytes in the digested version:
0 dkg@pip:~$ printf "%s" "th1s1sMY53krit%pazzwd" | sha1sum 2052ab047c8a9126a04eee752d454e4c3ccba281 - 0 dkg@pip:~$
0 dkg@pip:~$ time perl -e "print 'th1s1sMY53krit%pazzwd'x1000;" | sha1sum f538f59d0fbbd953e3f729738d6f3db77e64c452 - real 0m0.007s user 0m0.004s sys 0m0.004s 0 dkg@pip:~$ time perl -e "print 'th1s1sMY53krit%pazzwd'x1000000;" | sha1sum 19843526fe65b45c2aeb2684238714842ff4daf0 - real 0m0.704s user 0m0.424s sys 0m0.112s 0 dkg@pip:~$This is why you should prefer the iterated S2K algorithms, because they force an attacker who is trying a brute force attack against your encrypted secret key to spend many more computational resources for each attempted decryption.
In fact, if someone proposes that you should switch your S2K algorithm from SHA-1 to a digest algorithm which happens to be faster to compute than SHA-1 (i don't believe that the SHA-2 family is faster than SHA-1, but some of the proposed SHA-3 possibilities apparently are), you may want to re-consider, as it would reduce the cost of a brute-force attack.
That said, should you decide that you do want to change the digest algorithm used for S2K within OpenPGP, you probably want --s2k-digest-algo, which can also be stored in ~/.gnupg/gpg.conf.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
i've added a new suggestion to the ~/.gnupg/gpg.conf additions, to set default-preference-list so that new keys are generated with stronger preferences. Thanks to David A. Crick for the suggestion.
[ Parent | Reply to this comment ]
In particular, my proposed 3 month window for key transitions was based on my own key transition in 2007 (that time frame worked well for me) and the date of debconf (when new keysignings will be easy for many members of the Debian community). It is not a deadline after which SHA-1 should be considered useless.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Since this article is about digest algorithms, not ciphers, i stuck with the default cipher preferences chosen by gpg. I am not going to update the article to change that list, because i don't know enough about the state of the various ciphers to know why that's currently set up that way. If you're curious, i recommend asking on gnupg-users (after searching its archives, of course).
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Choosing this strategy right now will help you make new, stronger certifications, but those certifications themselves should be considered suspect by anyone who distrusts SHA-1, simply because they are only bound to your primary key (your only real entry in the Web of Trust) by a signature over SHA-1.
Note that no one is saying that SHA-1 itself is actively broken right now. But if you want to plan for a build-out of the post-SHA-1 WoT, doing so with a subkey hooked to a 1024-bit DSA primary key would not really contribute.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
It also sets up your published algorithm preferences to prefer SHA256 over SHA1 (though even stronger well-supported algorithms are listed after SHA1, which i think is a mistake). So that bit is in better shape as well.
What has not changed is the cert-digest-algo defaults. All your certifications are currently made by default with SHA1, which means that when we decide that SHA1 is truly deprecated, the WoT will need significant re-building. Please remember to set cert-digest-algo to a stronger digest in ~/.gnupg/gpg.conf (and in ~/.caff/gnupghome/gpg.conf if you use caff from the signing-party package).
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
My weblog entry above describes (and encourages) the use of GnuPG (the GNU Privacy Guard), which implements the RSA algorithm, but does not use Dual EC DRBG, or any code from RSA the company.
So yes, i think the above recommendations still hold.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
I am happy to recommend that people read, consider, comment on, and help to improve ">that page, and act on its recommendations.
[ Parent | Reply to this comment ]
It is now https://riseup.net/en/gpg-best-practices.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]