My vote is for the defaults Robert is proposing. Definitely in keeping with what else I have been reading.
Thanks, Bob Cavanaugh > -----Original Message----- > From: Gnupg-users [mailto:gnupg-users- > bounces+robertc=broadcom....@gnupg.org] On Behalf Of Robert J. > Hansen > Sent: Tuesday, March 17, 2015 12:45 PM > To: gnupg > Subject: Defaults > > Given that 2.1 introduces a lot of new capabilities (mostly with respect to > ECC), I think now, early on in the 2.1 series, would be a good time to discuss > changing the defaults for newly-generated certificates. > > In a nutshell: > > * Offer Brainpool-512 and RSA-3072 as options for > newly-generated certificates > * Use AES256 for a symmetric cipher > * Raise a warning if the user attempts to encrypt more > than 4 GiB with an old (64-bit block) cipher > * Only use CAST5 if the user explicitly requests it via > default-cipher-preferences: prefer 3DES over CAST5 > * Only use IDEA if the user explicitly requests it via > default-cipher-preferences: prefer 3DES over IDEA > * Use SHA256 for RSA-3072/-4096 signatures and SHA512 > for Brainpool-512 > > Rationale: > > * Although there's nothing per se *wrong* with the current > default of RSA-2048, realistically, 112 shannons of > uncertainty is not enough to inspire long-term confidence > * Originally, a lot of smart cards couldn't support more > than RSA-2048. While this is still true on some platforms > (it's hard to find RSA-3072 JavaCards), this does not > appear to be generally true any more. > * AES256 is a world standard for symmetric encryption and > appears to be resisting cryptanalysis better than AES128[*] > * A good rule of thumb is, "have twice as many bits of hash > as there are shannons of uncertainty in the key." RSA-3072 > provides ~128 shannons of uncertainty, hence SHA256. > Brainpool-512 provides ~256 shannons of uncertainty, hence > the recommendation for SHA512. > * CAST5 is not in good health: as was recently mentioned in > the IETF WG mailing list, the Canadians themselves still > allow it to be used for applications requiring 128 shannons > of uncertainty... but not for secrets that need to be kept > for more than a week. That doesn't inspire much confidence > in the long-term prospects of CAST5. > * Attacks on IDEA haven't been getting much better, but IDEA's > been giving me the heebie-jeebies for about fifteen years > now. I'd *really* prefer it if we got rid of it altogether. > Barring that, "only allow it to be used by explicit command" > will work for me. > * 3DES is still the Rock of Gibraltar. Big, slow, ungainly, > and strong. It's nobody's idea of a good modern cipher, but > I still think it's a better bet than IDEA or CAST5 today. > * CFB modes will potentially recycle internal states after > 2**(blocksize/2) blocks [**]. For a 64-bit block cipher, > that's 32GiB of data. Given that we now have thumb drives > larger than that, we need to consider the possibility users > will be using GnuPG as a bulk encryption tool and warn them > about potentially unsafe uses. If 2**32 blocks (32 GiB) > tends to be about the point at which we recycle state, > let's declare 4 GiB to be the point at which we warn users > against using a 64-bit block cipher. > * We've needed to make all these changes for years now. I've > always said we should defer on making big changes to the > defaults until we had ECC in place for users to migrate to. > Well, we've got ECC: let's start encouraging users to use it. > And while we're at it, let's see about making these other > overdue changes. > > > [*] As I read the tea leaves, I'm more convinced of AES256's long-term > strength than I am of AES128's. However, the idea that either one of them is > somehow 'weak' is just ludicrous. If you use AES128, don't panic. :) > > [**] Don't believe me, though. I haven't done any serious crypto work in > years and my memory could be off. I vividly recall this warning in both > _Applied Cryptography_ and the _Handbook of Applied Cryptography_, and I > think it was also given in _Practical Cryptography_ and maybe _Security > Engineering_. Check this before you believe it! > > > > Thoughts? _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
