Thanks for the detailed reply. Since --s2k-count will just affect the encryption of my private key, I'll go ahead and give myself a half second delay.
> sending passphrase-encrypted messages (which also have a s2k-count) By this you mean symmetrically-encrypted messages, with the -c flag? So I can just use the --s2k-count flag again, to change this. Presumably it's pretty pointless to change the count for asymmetrically-encrypted messages, since the session key will be long enough to discourage any brute forcing anyway. Cheers Chris On 4 Jul 2011, at 04:01, David Shaw <ds...@jabberwocky.com> wrote: > On Jul 3, 2011, at 12:15 PM, Chris Poole wrote: > >> On Sun, Jul 3, 2011 at 4:45 PM, David Shaw <ds...@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 > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
