GnuPG cryptographic defaults on the 2.2 branch [was: Re: [Announce] GnuPG 2.2.1 released]

[Daniel Kahn Gillmor]

On Wed 2017-09-20 08:32:04 +0200, Werner Koch wrote:
> That is not a bug fix and thus this won't go into 2.2 unless there is a
> security problem or regulations require the use of rsa3072.

What kind of "security problem" are you thinking of that would trigger
the change?

afaict, the contract promise of the 2.2 branch for --gen-key should be
"make a default key with reasonable parameters", not "make a default key
with parameters that were considered reasonable when 2.1.0 was
released".

If the former interpretation is correct, i don't see what's stopping 2.2
from updating the defaults to reflect the current threat environment if
it's generally understood to be a sensible improvement.

As Robert points out, NIST recommends switching over to 3072-bit keys by
2020.  Do we expect people who mint keys with the GnuPG stable branch
today to be using those keys in 2020 (28 months from now)?  Do we expect
people to be using the GnuPG 2.2 branch in 2020?  If so, the time to
change the defaults for long-term key generation is *before* the
suggested date.

By default with 2.2.1, new keys are generated with a 24-month expiration
date, so keys generated today are marked for expiration before 2020.
But in 4 months from now, new keys generated by GnuPG 2.2.1 will claim
usefulness into 2020.

Do we want those keys to be 3072-bit keys?

> Those who feel the need for longer keys can create longer keys.
> Changing the default does not increase security in any way.

For a single, experienced user, i'd agree with you.  For the ecosystem
as a whole, and for non-experienced users who don't want to know how it
all works, changing the default does indeed have an impact.

> With stronger security requirements you need to tweak a lot of other
> things, for example it would be paramount to use at least an airgapped
> box for such requirements.

This statement seems to mix two different types of security requirements
-- security against malware or system compromise vs. security against
cryptanalytic attack.

The goal of cryptographic software is to defend against cryptanalytic
attack, to make it *more* expensive than, say, physical compromise.
Put another way, GnuPG needs to take care against cryptanalytic attack
so that the folks who are taking care of the other avenues of security
don't find their work obviated by cryptanalytic attack.

There is something to be said in favor of trying to raise the weakest
link first, or to raise all bars at once, but when one tool doesn't
control all the avenues of possible defense (e.g. gpg can't force people
to use airgapped machiens) it can become an argument for inaction on all
sides :(

OTOH it can be useful to consider the "raise the weakest link" argument
*within* the cryptographic defenses (which GnuPG *does* control all of
in its context): raising the default RSA key length to 3072 actually
puts it more on par with "128-bit" symmetric levels of security, so that
the asymmetric crypto isn't the weak link compared (for example) to
using AES128 as a symmetric cipher.  2048-bit RSA is widely estimated to
have roughly the same defensive power as 112-bit symmetric crypto (see
the Ecrypt-II recommendations, for example), so it is currently the
weakest link.

> Maybe.  But that is irrelevant for most people: The real threat are
> prêt-à-porter access methods: mass infection of all networked machines
> are much cheaper and a more effective way than to break crypto.  That
> needs to be addressed elsewhere but in crypto software.  Given the the
> sad state of software security we can only hope for political solutions
> against the use of government malware.

I agree we need to work on all of these fronts as a society to ensure
that people can have robust, private, non-surveilled communications, and
remain in control of their own data.  That's why i'm happy that GnuPG is
pushing on the cryptographic front :)

All the best,

       --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20170920/86f2a5c0/attachment.sig>