Pete Stephenson pete at
Tue Mar 17 22:58:47 CET 2015

On 3/17/2015 8:44 PM, Robert J. Hansen wrote:
> 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

I mostly agree. However, I have a few minor points:

- Above RSA-2048, keys and signatures become quite large. DSA signatures
increase slightly, but are considerably smaller than RSA signatures.

As long as we're considering "legacy" algorithms like RSA and DSA, is
there any particular reason for preferring RSA over DSA at such key
lengths? I know that DSA is only defined up to DSA-3072, so those who
wish to use larger keys would need to use RSA or ECC, but why not use
DSA as the default?

Is Deterministic DSA only available in 2.1, or do 1.x and 2.0.x also
have that feature?

- The Brainpool curves are similar in structure to the NIST curves,
though their curve parameters are chosen in a clear, open manner. While
that leads to increased trust that the parameters aren't chosen for
nefarious purposes, if one is already making a major change to ECC, why
not use some other, more modern curve that's designed at a high-security

Curve M-511 comes to mind, as it's similar to Curve25519 (which GnuPG
already implements).

See -- djb and Lange clearly lay out their
criteria for different curves and why they're categorized they way they
are. I'm nothing more than an interested amateur in this subject, but
why not benefit from their efforts?

> 	* 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

> 	* 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.

Do you have a link to this discussion on the IETF list? I suspect the
community here would be very interested.

> 	* Only use IDEA if the user explicitly requests it via
> 	  default-cipher-preferences: prefer 3DES over IDEA

> 	* 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.

Is there something particular about IDEA that concerns you?

> 	* Use SHA256 for RSA-3072/-4096 signatures and SHA512
> 	  for Brainpool-512


> 	* 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.

Alas, a lot of Linux distributions are quite slow-moving: it's unlikely
that distributions like Debian and Ubuntu will have GnuPG 2.1.x
available (let alone installed by default) for several years.

Yes, the changes should be made, but ECC support won't be widely
available to most users for some time.


More information about the Gnupg-users mailing list