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?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
