FAQ: Re: key length

[Bernhard Reiter]

On Thursday 24 July 2014 at 12:02:46, Robert J. Hansen wrote:
> This is just a proposal, *not* a final draft.  If this gives people
> heartburn, let me know precisely what gives heartburn and I'll try to
> mitigate it as best as I can.

Thanks for the proposal. Together with a data, I think it is a big 
improvement!

(If you wanted to, you could put it up at wiki.gnupg.org, I believe
that we should get even more people to participate in collecting
and improving the documentation.)

> Q: Why does GnuPG default to 2048-bit RSA?
> A: Because it offers reasonable security for the next several years
>    while still being compatible with the widest variety of OpenPGP
>    installations.

This makes me curious: Is there an example for an OpenPGP implementation
that only support <= 2048-bit RSA keys? Still in usage?

> Q: What are NIST's recommendations for key sizes?
> A: According to NIST Special Publication 800-57, "Recommendation for
>    Key Management," published in July 2012, a 2048-bit RSA or DSA
>    key is comparable in strength to 3DES.  Further, they state that
>    2048-bit keys are acceptable for use through the year 2030.
>
> Q: What are ENISA's recommendations for key sizes?
> A: Slightly different, but not so much so as to be surprising.  ENISA
>    is slightly more pessimistic about the long-term prospects of
>    2048-bit keys, although they are careful to note 2048-bit keys are
>    still daunting for an adversary.

I haven't read the ENISA recommendation in full length. If they allow
2048 bit for old applications or up to a specific point, it would be an 
improvement to say so. It may make sense to directly link to their
recommendation paper.

> Q: Is there a general recommendation that 3072-bit keys be used for
>    new applications?
> A: No, although some respected people and groups within the
>    cryptographic community have made such recommendations.
>
> Q: Why does GnuPG disregard these recommendations for 3072-bit keys?
> A: We don't.  That recommendation is for *new applications*.  GnuPG
>    is not a new application.  When a user generates a GnuPG certificate,
>    that user becomes part of an ecosystem of existing certificates and
>    a userbase that spans the globe.  In short, GnuPG is not a new
>    application.
>
> Q: Are there any plans to move to stronger keys by default?
> A: Imminently. 

You may consider using a different word here. As someone who speaks English as 
a foreign language, I had to look "imminently" up to be sure about its 
meaning.

> When a version of GnuPG is released which supports 
>    elliptical-curve cryptography, then will be an ideal time for us
>    to pause, take a deep breath, and make the transition to larger
>    effective key sizes.
>
> Q: I think I need larger key sizes.
> A: By all means, feel free to generate certificates with larger keys.
>    GnuPG supports up to 4096-bit keys.

Wasn't there something about the current OpenPGP smartcards only being able to 
deal with 3072-bit keys? May be another argument. If you wanted to move your 
secret key on a smartcard some day.

I recommend to leave out the next question and answer, it does not add much 
significant information. From the above it is clear that currently the 
compatibility with other/elder OpenPGP implementations is prefered as 
default. 

> Q: If GnuPG will be moving to stronger default key sizes in the near
>    future via support for elliptical curves, why is there such
>    controversy about what GnuPG's defaults are right now?
> A: It's human nature to want things "more, better, and right now."  But
>    just like in the rest of life, good things come to those who wait.
>    It won't be long, we promise.


Best Regards,
Bernhard
-- 
www.intevation.de/~bernhard (CEO)    www.fsfe.org (Founding GA Member)
Intevation GmbH, Osnabrück, Germany; Amtsgericht Osnabrück, HRB 18998
Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20140731/a814007f/attachment-0001.sig>