Change key prefs; few questions

[David Shaw]

On Jul 3, 2011, at 12:15 PM, Chris Poole wrote:

> On Sun, Jul 3, 2011 at 4:45 PM, David Shaw <dshaw at jabberwocky.com> wrote:
>> There are some obscure edge cases where you must have a 3DES or AES encrypted
>> private key, but for the overwhelming majority of people, no, there is no
>> reason to do this.  The default (CAST5) is quite strong (which the original
>> poster acknowledged).  It's just helpful to know what the "knobs" are to
>> understand how something as complex as OpenPGP is put together.
> 
> Exactly, it's just good to know. I won't bother changing the cipher or count,
> but this leaves me with one final question:
> 
> In a few years, assuming GPUs are faster than ever, Moore's law is still on
> track, and all that; should I change the number of iterations with --s2k-count?
> The default 65536 is probably fine for now, but it'll certainly end up being too
> slow. gpg won't do this for me, or counteract this in another way?

GnuPG generally has its defaults updated every now and then.  While some of the new possible defaults (DSA/Elgamal keys becoming RSA/RSA, new default key sizes) do require the generation of a new key to use, others (default preferences, secret key protection, and secret key iteration count) are available to any key.  Since secret key cipher and iteration count are tied to the encryption of the secret key (via the passphrase), if you just change your passphrase with that new version of GnuPG, you'll automatically pick up a new cipher and iteration count.

PGP has a clever trick to set an appropriate s2k-count without knowing anything about the various processors it will be run on: it simply figures out how many iterations it can do in 1/10 of a second (which always results in a value higher than 65536 these days), and uses that.  I believe that the newer GPG (2.x) has some support for this design, but I don't recall offhand if it is using it fully yet.  We should probably raise the (static) GPG 1.x count as well at some point.  It's been 65536 for a long time (over a decade).

It's not unreasonable to raise your s2k-count for your secret key.  If you pick a value that is too high and you find it annoying, you can always set it back down to something lower.  It doesn't cause any real harm if you go too high - just wastes some of your time (which is sort of the point!)  That's for secret keys, of course.  More complex is sending passphrase-encrypted messages (which also have a s2k-count), where you don't know the CPU capabilities of the recipient.  There was a case a year or two back where receiving an OpenPGP message with a too-high s2k-count would cause a device to hit its deadman timer since it spent so much time iterating passphrases.  Someone had created the message on a fast machine (and so didn't notice the delay), and sent it to someone on a slow machine which was clobbered by it.

Of course, if you want extra security against brute forcing, even better than bumping up your s2k-count would be to just add a character or three to your passphrase.

David