Weblog entry #48 for dkg

HOWTO prep for migration off of SHA-1 in OpenPGP
Posted by dkg on Wed 6 May 2009 at 06:15
Last week at eurocrypt, a small group of researchers announced a fairly serious attack against the SHA-1 digest algorithm, which is used in many cryptosystems, including OpenPGP. The general consensus is that we should be 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:

  • start making data signatures and web-of-trust certifications using stronger digests,
  • explicitly state your preferences for stronger digests when receiving private communications, and
  • If you are currently using a 1024-bit DSA primary key (which relies for signatures on a 160-bit hash, traditionally SHA-1), transition to a new 2048-bit RSA key.
The first two are simple, quick, and painless actions. You'll be done with them in minutes! The third is tougher, and while you can start it today, key transitions take a little bit of time to complete. Read on for a HOWTO!
Start making data signatures and web-of-trust certifications using stronger digests

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.

Indicate that you prefer stronger digests when receiving signed messages privately

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 Uncompressed
Note 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!

Replace your 1024-bit DSA keys with 2048-bit RSA keys or larger

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:

  1. (day 0) Create a new key, using 2048-bit RSA at least (gpg appears to be about to change the default key generation to 2048-bit RSA shortly, if you need more justification). Be sure to configure ~/.gnupg/gpg.conf to use the stronger digest before creating the new key, and set up strong digest preferences on the new key (see above) immediately after key creation. Send the new key to the public keyservers. Generate a revocation certificate too, and store it in a safe place!
  2. (day 0) Sign your new key with your old one (not the other way around!), and publish the signature. Write up a transition statement (here's an example from an earlier key transition), clearsign it with both keys (old and new), and publish it in a stable place.
  3. (day 0) Write up or print out the User IDs and fingerprint of your new key on paper to hand out to people.
  4. (day 0 through day 90) Collect certifications binding the new key to your User ID to re-establish your connection to the Web of Trust. Some reasonable ways to do this effectively are
    • local keysigning parties (e.g. in NYC this coming Friday, 2009-05-08),
    • debconf (less than 90 days away!), and
    • contacting known and trusted friends, pointing them to the transition statement and asking them to reissue their certifications.
  5. (day 0 through day 90) Review the set of public certifications you've made (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.
  6. (well before day 90) Ensure that your new key is in available everywhere you need it to be (like the Debian keyring). Use your new key in those contexts and make sure it is accepted and acceptable.
  7. (day 90) Publish your stored revocation certificate for your old key. You had a revocation certificate for the old key already, right? If not, generate a new one, and publish it.

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.

 

Comments on this Entry

Posted by Anonymous (122.105.xx.xx) on Wed 6 May 2009 at 07:06
One other thing to do when you switch GPG keys; decrypt all your old encrypted mail and other files and then re-encrypt them with your new GPG key. This is likely to be quite annoying for many people, are there any tools to help do that?

[ Parent | Reply to this comment ]

Posted by Anonymous (2001:0xx:0xx:0xxx:0xxx:0xxx:xx) on Wed 6 May 2009 at 07:22
You can do this, but you will lose the signatures on the mails then. Since encrypting email protects mostly against intercepting information in transit (rather than when it's on your local hard disk), I don't think there's much point in that.

Note that you can easily decrypt mail that's been encrypted to a GPG key which was revoked, if you so wish.

[ Parent | Reply to this comment ]

Posted by sth (132.198.xx.xx) on Fri 24 Jul 2009 at 20:17
...unless said messages are stored on a remote IMAP server, in which case it's nice to keep them encrypted.

[ Parent | Reply to this comment ]

Posted by Anonymous (217.28.xx.xx) on Wed 6 May 2009 at 11:13
Not "off of"; "from"!

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Wed 6 May 2009 at 14:27
[ View dkg's Scratchpad | View Weblogs ]
i preferred "away from" myself, but this blogging engine limits the character length of my title just a few characters too much. Anyway, you get the point!

[ Parent | Reply to this comment ]

Posted by Anonymous (62.30.xx.xx) on Sat 9 May 2009 at 16:52
doesn't mean you can't update the odd post title?

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Sat 9 May 2009 at 16:55
[ View dkg's Scratchpad | View Weblogs ]
"off of" and "from" are both suboptimal, and i can't select the optimal title due to (not unreasonable) space constraints. I'm sticking with what i originally chose, thanks to the hobgoblin of my small mind. I really don't think it's a big deal.

[ Parent | Reply to this comment ]

Posted by Anonymous (131.155.xx.xx) on Wed 6 May 2009 at 13:31
A good alternative would be the use of DSA2: this will allow larger key sizes for DSA keys - and larger hash signatures. GPG and most modern crypto tools support DSA2. This should also let people use existing 1024 bit DSA keys with SHA-256 hashes.

Wouldn't it be much easier to switch to DSA2, rather than getting rid of all existing DSA keys and replacing them with RSA keys? Your crusade against DSA seems unneeded; but please do enlighten me if I'm missing something here.

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Wed 6 May 2009 at 14:45
[ View dkg's Scratchpad | View Weblogs ]
It's not a crusade! It is, however, an interest in interoperability with other implementations, and an acknowledgement of upcoming realities. As David Shaw says:
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 ]

Posted by Anonymous (131.155.xx.xx) on Wed 6 May 2009 at 16:16
Yes, you are completely right: I forgot about the hash length truncation that is different with DSA than with RSA usage. If you use SHA-256 with a DSA-1024 key, the hash will be truncated (to something that offers roughly the same cryptographic strength as the DSA key size). This does get you out of any weaknesses that are specific to SHA-1 however.

Use of SHA2 and DSA2 were promoted pretty much hand-in-hand. But I will not contest that SHA2 is more widely-used than DSA2: it probably is.


And for the record: I'm not claiming that DSA-2048 is better then RSA-2048. However I don't know of any reason why RSA-2048 in itself would be better than DSA-208, which is why found your strong suggestion to switch to RSA strange. I'd say both algorithms are rather equal. Your additional arguments have made this choice clearer: thank you for explaining.

[ Parent | Reply to this comment ]

Posted by astifter (81.217.xx.xx) on Sat 9 May 2009 at 00:02
I'm sorry but I could not resist:
I have stumbled across so may trolls lately, that it is a real pleasure to see that there are still nice and well behaved people out there that have a serious discussion, disagree AND are polite about it.
Thanks.

[ Parent | Reply to this comment ]

Posted by Anonymous (194.187.xx.xx) on Wed 6 May 2009 at 19:28
What should people using OpenPGP card do? It doesn't support SHA-2. All it does support is SHA-1 and RIPEMD160...

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Wed 6 May 2009 at 19:52
[ View dkg's Scratchpad | View Weblogs ]
Are you talking about the OpenPGP card offered by g10? Section 7.2.8.1 of the 2.0 manual states:
Cards with Version < 2.0 sup­port RIPEMD-160 and SHA-1 only
but 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 ]

Posted by Anonymous (194.187.xx.xx) on Wed 6 May 2009 at 20:00
I don't thing version 2.0 cards exist at all. The specs were just finalyzed recently.

[ Parent | Reply to this comment ]

Posted by Anonymous (87.144.xx.xx) on Fri 13 May 2011 at 11:23
The 2.0 cards offered by g10 do support 2048-bit keys, as they state on their website:
3 independent 2048 bit RSA keys (signing,encryption,authentication).
Key lengths reducable to 1024 bit; key length of signature keys increasable to 3072 bit.

Thanks for this article.

Rob

[ Parent | Reply to this comment ]

Posted by Anonymous (212.159.xx.xx) on Wed 6 May 2009 at 20:51
Forgive the crypto ignorance but what is the reason for throwing out 1024 DSA keys entirely rather than using an alternative to the "initially, officially" specified SHA1?

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Wed 6 May 2009 at 21:23
[ View dkg's Scratchpad | View Weblogs ]
I believe it is because the way that DSA-1 works, it is limited to only be able to sign over 160-bit hashes (see the discussion above about using larger hashes with 1024-bit DSA-1 keys). The only other 160-bit hash available in OpenPGP is RIPEMD-160, which (according to has not had the same level of public scrutiny as the SHA family due to its smaller user base.

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 ]

Posted by dkg (216.254.xx.xx) on Thu 7 May 2009 at 22:35
[ View dkg's Scratchpad | View Weblogs ]
One more note: section 13.6 of RFC 4880 implies that to actually comply with the digital signature standard (DSS) used by DSA keys, you need to use a hash from the SHA family, which rules out RIPEMD-160. Even though you could apparently use an SHA-2 family hash (and just rely on the truncated digest), other implementations (and previous specifications) apparently do not handle truncated digests well. So there are still more interoperability concerns with that approach.

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Wed 6 May 2009 at 22:27
[ View dkg's Scratchpad | View Weblogs ]
Aigars Mahinovs has some related discussion in his blog about whether we should push for a change in the defaults for gpg.

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Thu 7 May 2009 at 22:26
[ View dkg's Scratchpad | View Weblogs ]
An 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 any certifications.

[ Parent | Reply to this comment ]

Posted by Anonymous (89.246.xx.xx) on Fri 8 May 2009 at 13:37
I ask myself why you recommend to use SHA256 for signatures (personal and cert) instead SHA512. Shouldn't be SHA512 more secure?

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Fri 8 May 2009 at 15:31
[ View dkg's Scratchpad | View Weblogs ]
SHA512 is more secure than SHA256, from what i can tell. It's also larger, costs more to compute, and is less widely-implemented than SHA256. I'm personally using SHA512 to see what interoperability issues i run into, and i think it would be interesting to hear from others doing the same thing.

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 ]

Posted by Anonymous (89.246.xx.xx) on Fri 8 May 2009 at 16:05
Ok, thx.
Maybe you know what the different it is between DSA2 and RSA in hash length. FIPS 186-3 states that it can use 256 bit hashes for 3072 and 2048 keys. I couldn't find any such information for rsa. Is the rsa signature algorithm without hash length bounds?

[ Parent | Reply to this comment ]

Posted by Anonymous (216.254.xx.xx) on Sat 9 May 2009 at 17:49
Using RSA, the (padded) digest is limited by the size of the modulus. I think PKCS #7 or PKCS #12 defines the padding used for RSA encryption, and I'm not sure if the same padding is used for signatures, but I don't see why it wouldn't. The padding consists of zero or more non-zero octets, a single zero octet, and is followed by the message. That would seem to limit 2048-bit RSA signatures to using a 2040-bit digest, but the full 2048 bits could be used if the padding definition were changed. Perhaps OpenPGP also inserts a variable length integer in there indicating the digest algorithm used. In any case, RSA accommodates digests nearly as large as the modulus.

DSA actually uses 2 moduli, one of which is 160 bits, which is why DSA signatures are 320 bits long. The signature scheme is similar to El Gamal signatures, but the second modulus makes the signature twice as large as the smaller modulus instead of twice as large as the public key modulus. (El Gamal signatures with a 2048-bit key are 4096-bits long.) The math still all works out if you increase the size of the smaller modulus, but the larger modulus minus one must be a multiple of the smaller modulus (if memory serves), so you can't just start using longer hashes with an existing key unless you truncate the hash, as would be possible with RSA.

It's a shame SHA-3 hasn't been finalized by now, or we could be leapfrogging over the SHA-2 transition right now.

[ Parent | Reply to this comment ]

Posted by MFPA (88.202.xx.xx) on Mon 8 Feb 2010 at 01:16
Just wondering, did you encounter any issues because of using SHA512?

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Mon 8 Feb 2010 at 02:34
[ View dkg's Scratchpad | View Weblogs ]
I haven't had any difficulties using SHA512 at all, actually. If anyone has had any difficulty interoperating with the OpenPGP certifications i produce, they haven't let me know.

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 ]

Posted by fsateler (125.63.xx.xx) on Sat 9 May 2009 at 01:17
[ View Weblogs ]
But gpg doesn't allow encryption using RSA keys, it does only keysigning. Should we have 2 keys, one for signing and one (non-RSA) for encrypting? Are ElGamal keys weak too?

--------
Felipe Sateler

[ Parent | Reply to this comment ]

Posted by Anonymous (89.246.xx.xx) on Sat 9 May 2009 at 09:39
You aren't right. RSA is supported by gnupg for sign, cert, auth and encrypt. It allows to use all options set on the primary key set. You must run in expert or batch mode to set it. Beware: it is highly recommended to only create a cert or sign/cert as primary key and add a encrypt key as separate key. You only need auth if you use it with ssh or other systems where you can use standard public-key authentication.
Afaik only ElGamal as signing functions is hard to implement really secure and thus not recommended for signing. The last thing I read about ElGamal vs. RSA for encryption from Bruce Schneier was that they are equal secure. This doesn't mean if you can find a weakness in RSA that ElGamal also has that weakness in every situation as it would be with ElGamal and Diffie-Hellmann....

So, you can create a RSA cert/signing key with "gpg2 --gen-key" or a DSA2 cert/signing key with "gpg2 --enable-dsa2 --gen-key" and afterwards use "gpg2 --edit $KEYID" and the gpg command "addkey" to add a encryption key. Be sure that you use a recent version of gnupg for key generation since some weaknesses were found in old versions.

[ Parent | Reply to this comment ]

Posted by fsateler (125.63.xx.xx) on Sat 9 May 2009 at 11:10
[ View Weblogs ]

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 ]

Posted by dkg (216.254.xx.xx) on Sat 9 May 2009 at 16:29
[ View dkg's Scratchpad | View Weblogs ]
Yup, you've got it. It makes key generation a two-step process with current versions of gpg. New versions of gpg should bring this back to a 1-step process for 2048-bit RSA keys (the default), but that change hasn't been finalized yet.

[ Parent | Reply to this comment ]

Posted by lidaobing (61.145.xx.xx) on Sat 9 May 2009 at 10:52
Hello,

in the 2nd step of the last section: "clearsign it with both keys (old and new)", but how to clearsign a file with two secret keys?

thanks.

[ Parent | Reply to this comment ]

Posted by lidaobing (61.145.xx.xx) on Sat 9 May 2009 at 11:15
I have found it: gpg -u keyid1 -u keyid2 --clearsign filename

[ Parent | Reply to this comment ]

Posted by Anonymous (78.2.xx.xx) on Sat 9 May 2009 at 21:41
Hi, what about the fact that (following these instructions) the integrity of the secret key is still protected with sha-1[0]. Is sha-2 available for this so we can migrate our new keys[1], and/or should this sha-1 weakness concern us in the context of secret keys?

[0] --list-packets
iter+salt S2K, algo: 3, SHA1 protection, hash: 2

[1] PGP, GnuPG, & the New SHA1 Secret Key Hash
http://www.spywarewarrior.com/uiuc/ss/sec-key/sec-key.htm

[ Parent | Reply to this comment ]

Posted by dkg (166.84.xx.xx) on Mon 11 May 2009 at 00:17
[ View dkg's Scratchpad | View Weblogs ]
The recent sha-1 results claim a flaw in the digest's collision resistance. That is, the concern is that an attacker might be able to generate two documents A and B that hash to the same value. In the digital signature case, your signature is made over a document's digest, so if you decide to sign A, the attacker can transplant your signature onto B even though you've never seen it.

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:

  • If you look at the underlying byte values in the UTF-8 representation of the human-memorizable string, you see that the underlying values have a distinct probability distribution, with values in some ranges never even showing up at all:
    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:~$ 
    
  • Note also that if you run the digest over more data, it takes a longer time to calculate:
    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.
Note that neither of these particular goals of S2K is placed at risk by a weakening of the collision resistance of the digest algorithm used.

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 ]

Posted by Anonymous (83.160.xx.xx) on Sun 10 May 2009 at 11:30
There is one thing to be aware of: even though you can create a new key and set preferences to request better hasing than SHA1, your applications still must support that. Evolution, a widely used mail client, for example doesn't support SHA256 and silently falls back to SHA1. Generating new keys isn't enough to get rid of SHA1, applications will need updating.

http://blogs.ubuntu-nl.org/dennis/2009/05/10/evolution-vs-sha256/

[ Parent | Reply to this comment ]

Posted by dkg (166.84.xx.xx) on Mon 11 May 2009 at 00:27
[ View dkg's Scratchpad | View Weblogs ]
One more 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 A. Crick for the suggestion.

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Mon 11 May 2009 at 06:48
[ View dkg's Scratchpad | View Weblogs ]
David Shaw and Robert Hanson have made some good remarks about the situation on gnupg-devel. I encourage people to read that thread for some grounding about the current state of the infrastructure, and for their reasoned advice to avoid panicking. I want to repeat that this blog post is a call for an orderly retreat from the SHA-1 digest algorithm, not a stampede. We need to be prepared for the eventual deprecation of SHA-1, but we do appear to still have time. Let's do this right.

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 ]

Posted by Anonymous (193.205.xx.xx) on Mon 11 May 2009 at 09:18
I see you left Blowfish out of your "preferred ciphers" list. Is there something wrong with it?

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Mon 11 May 2009 at 14:21
[ View dkg's Scratchpad | View Weblogs ]
no, not that i know of. I'm not sure why that got dropped. Thanks for pointing it out! I'll update the article to include blowfish.

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Mon 11 May 2009 at 14:51
[ View dkg's Scratchpad | View Weblogs ]
Actually, after a bit of digging, i figured out why it's omitted: by default, debian's version of gpg (1.4.9) does not include BLOWFISH (or TWOFISH) in the list of preferred ciphers attached to a new key (even though it does support them).

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 ]

Posted by Anonymous (78.23.xx.xx) on Thu 14 May 2009 at 20:33
It has been a long time since I used GnuPG. Why isn't it possible (or at least good enough) to just add an RSA2048 key to an existing key? I have an old key with DSA/Elgamal. In SeaHorse i tried to add a new RSA 2048 (sign) key to that existing key. Then i modified my gpg.conf to indicate my preference for SHA256 or even SHA512. Then i just signed a file with the old key, and it was signed with SHA256. Before I added the new RSA key, SHA-1 was used when i signed a file with the old key, eventhough i indicated in gpg.conf my preference for SHA256. So it seems to me that just adding a new stronger subkey to an existing key, is enough. But since i don't know that much about GnuPG, there will probably be a good reason not to do this?

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Fri 15 May 2009 at 01:31
[ View dkg's Scratchpad | View Weblogs ]
You could add an RSA subkey, but subkeys are bound to primary keys only via certifications made by the primary key itself. If you primary key is DSA-1 (that is, 1024-bit DSA), then the official DSA standard mandates the use of SHA-1 in its signatures. So the subkey binding signature itself will be made over the weaker digest.

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 ]

Posted by Anonymous (213.100.xx.xx) on Thu 14 May 2009 at 23:41
If I have generated 4096 bit RSA sign and encryption keys before setting the preferences in ~/.gnupg/gpg.conf as stated in the article, do I still have to get new keys?

[ Parent | Reply to this comment ]

Posted by Anonymous (86.132.xx.xx) on Fri 15 May 2009 at 00:27
No, but you should update your preferences, and re-distribute your updated public-key, as it carries your preferences with it.

[ Parent | Reply to this comment ]

Posted by Anonymous (2002:0xx:0xx:0xxx:0xxx:0xxx:xx) on Sun 17 May 2009 at 14:34
Actually, as most reccomendation go, to be as secure as SHA-256 is better to use RSA keys bigger than 3000 bits, though 2048 are still enough for most uses.

[ Parent | Reply to this comment ]

Posted by Anonymous (71.139.xx.xx) on Tue 26 May 2009 at 22:32
I have a quick comment about migrating keys. I have default-key set to my new key in .gnupg/gpg.conf. However, gpg still defaults to the old key when it's only passed my email, e.g. gpg -u <email> --clearsign file uses my old key by default. How can I make it use my new key by default when it looks to the email? This is an issue because git-tag -s uses the default email's gpg key. Thanks.

[ Parent | Reply to this comment ]

Posted by Anonymous (71.139.xx.xx) on Tue 26 May 2009 at 22:47
I solved my own problem by just setting signingkey in my gitconfig.

[ Parent | Reply to this comment ]

Posted by mnaumann (91.64.xx.xx) on Tue 30 Jun 2009 at 18:17
[ View Weblogs ]
Thanks for this great guide.

Just a little note: Once you have configured default-preference-list, it is sufficient - when editing a key - to just issue setpref without additional arguments.

Since the new preferences you are setting will be displayed before the change is committed, this should be safe enough.

[ Parent | Reply to this comment ]

Posted by Anonymous (85.225.xx.xx) on Wed 29 Jul 2009 at 21:15
From a layman, probably representing a large portion of the OpenPGP/gnupg users:

If I have a 1024D key that is not signed yet (except self-signed) and the public key is submitted to a key-server, how are the above steps modified?

[ Parent | Reply to this comment ]

Posted by Anonymous (67.177.xx.xx) on Sat 8 May 2010 at 06:25
Thanks for this post. It’s been helpful. However, I cannot determine why SHA1 is used when I clear-sign a file even though SHA1 is listed last in my preferences. What’s even stranger is that when I send a signed email, SHA512 is used as expected. What am I missing? My pasted my preferences below. Thanks!

default-preference-list TWOFISH AES256 AES192 AES BLOWFISH 3DES SHA512 SHA384 SHA256 SHA224 SHA1 BZIP2 ZLIB ZIP Uncompressed
personal-cipher-preferences TWOFISH AES256 AES192 AES BLOWFISH 3DES
personal-digest-preferences SHA512 SHA384 SHA256 SHA224 SHA1
personal-compress-preferences ZLIB BZIP2 ZIP Uncompressed
cert-digest-algo SHA512

showpref
Cipher: TWOFISH, AES256, AES192, AES, BLOWFISH, 3DES
Digest: SHA512, SHA384, SHA256, SHA224, SHA1
Compression: BZIP2, ZLIB, ZIP, Uncompressed
Features: MDC, Keyserver no-modify

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Sat 8 May 2010 at 23:55
[ View dkg's Scratchpad | View Weblogs ]
Can you show the exact command you're using for clearsigning? When you send e-mail, what mail user agent are you using? how does it invoke gpg?

[ Parent | Reply to this comment ]

Posted by Anonymous (67.177.xx.xx) on Sun 9 May 2010 at 01:53
I'm clear signing from the terminal by running "gpg --clearsign filename.txt." W

I have Thunderbird 3 setup to sign and/or encrypt emails via the Enigmail plugin. When I email myself, it uses the appropriate hash (SHA512) and Encryption (Twofish)--I verified this by running "gpg -v --list-packets file.txt."

Both Enigmail and the terminal use the same keys but the Terminal clearsigning uses SHA1 unless I explicitly tell it to use a different Hashing algorithm each time I run the command. However, I didn't think that should be necessary if I want it to use what I set as a preferred digest.

I appreciate any help because I'm been searching and searching trying to determine what is going on.


[ Parent | Reply to this comment ]

Posted by Anonymous (84.92.xx.xx) on Mon 10 Jan 2011 at 12:54
I am having the same issue with gpg on Fedora, using
john@jadzia ~> gpg -u oldkey -u newkey --clearsign document
produces:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1,SHA512
…snip…

john@jadzia ~> gpg --version
gpg (GnuPG) 1.4.11
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <removed link>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,
CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

and my ~/.gnupg/gpg.conf
personal-digest-preferences SHA512
cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

even my key preference is set correctly:
gpg> showpref
[ultimate] (1). John Drinkwater (Beta) <john@nextraweb.com>
Cipher: AES256, AES192, AES, CAST5, 3DES
Digest: SHA512, SHA384, SHA256, SHA224, SHA1
Compression: ZLIB, BZIP2, ZIP, Uncompressed
Features: MDC, Keyserver no-modify

[ Parent | Reply to this comment ]

Posted by Anonymous (75.200.xx.xx) on Fri 16 Jul 2010 at 18:07
Just noticed this on Debian box but I moved over to my Ubuntu box and it looks as things may have finally changed with gpg 1.4.10:

Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)

[ Parent | Reply to this comment ]

Posted by dkg (216.254.xx.xx) on Tue 20 Jul 2010 at 00:35
[ View dkg's Scratchpad | View Weblogs ]
Yup, gpg 1.4.10 defaults to creating a pair of 2048-bit RSA keys, which is the Right Thing.

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 ]

Posted by Anonymous (193.23.xx.xx) on Mon 22 Aug 2011 at 12:36
If you use a DSA Key, you have to --enable-dsa2 to use the newer hashes. Otherwise only SHA1 will be used.

[ Parent | Reply to this comment ]

Posted by Anonymous (212.17.xx.xx) on Mon 10 Feb 2014 at 01:27
Should we still use RSA as encryption after we learned that RSA has a NSA Backdoor in the default random number generator? (Source: t.co/Ls72rBbG0Y)

[ Parent | Reply to this comment ]

Posted by dkg (212.110.xx.xx) on Mon 10 Feb 2014 at 15:56
[ View dkg's Scratchpad | View Weblogs ]
RSA refers to at least two things: RSA Security, the company, is the RSA referenced in your article. It was paid by the NSA to implement and widely deploy a compromised random number generator (Dual EC DRBG). RSA the algorithm is not compromised just because RSA the company was compromised.

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 ]

Posted by Anonymous (80.109.xx.xx) on Fri 28 Feb 2014 at 11:17
Thank you dkg, that clarified alot. That means, you have to trust your encryption library which implements the methodology of the three guys.

[ Parent | Reply to this comment ]

Posted by Anonymous (95.211.xx.xx) on Tue 8 Apr 2014 at 08:48
Please mention more things mentioned on riseup recommendation like hkps and so on.

[ Parent | Reply to this comment ]

Posted by dkg (212.110.xx.xx) on Tue 8 Apr 2014 at 12:55
[ View dkg's Scratchpad | View Weblogs ]
At this point, i consider this particular blog post of historical interest. I stand by the original intent and concrete recommendations it made for 2009, but there are a number of things in it that seem out of date now, 5 years later (e.g. i would recommend 3072-bit RSA keys at least, rather than 2048, given the keysize recommendations in documents like the ENISA report). However, i don't plan to modify this blog post into making it an up-to-date list of OpenPGP best practices. That work is better done elsewhere, like the OpenPGP Best Practices page that you're referring to, though. .

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 ]