Defaults

[Robert J. Hansen]

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150317/67fa8f40/attachment.sig>