Defaults

[Bob (Robert) Cavanaugh]

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.com at 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?