Subject: Changing GPG's default key type

From: David Shaw <[email-masked]>
Date: Mon, 4 May 2009 10:40:52 -0400

Hi,

Currently, GPG's default key type, the one that is recommended to all  
new users, is a DSA primary key (1024 bits - not "DSA2") with an  
Elgamal subkey.  We are currently thinking about changing the default  
primary to a 2048-bit RSA key.

The main benefits of changing the key type is that it can go past the  
1024 bit DSA1 limit, and would also not be limited to a 160-bit hash,  
both of which are getting a little long in the tooth.  We could get  
similar benefits with a DSA2 key, but DSA2 is not nearly as widely  
implemented as RSA is, so is not a good option for a default key at  
this time.  We will of course continue supporting DSA2 (and DSA "1")  
as we do now.  This is purely a question of what the default key  
should be.

This is not directly prompted by the recent SHA-1 troubles, but it is  
somewhat related, as it would let users of the default key type use  
hashes larger than 160 bits.  That said, this is not intended to be a  
fix for the SHA-1 problems.  We are not proposing changing our default  
signing hash, which will remain SHA-1.

After a bit of internal discussion, we thought it was worth mentioning  
this here, to see if the OpenPGP community had any issue or other  
comments.  I don't expect this to be a particularly controversial  
move, but discussion is always welcome.

One issue, of course, is that RSA is not a required key type in  
OpenPGP, so there could be some implementation out there that won't be  
able to handle it.  I'm not terribly concerned about this, as in  
practice, the vast majority of code has handled RSA just fine for the  
past decade, and if a particular user needs to generate a non-RSA key,  
they can still do so.
There are a few other details (RSA signatures are physically larger,  
etc), but I believe they are outweighed by the benefit of the larger  
key and additional hash flexibility.

David

---

From: Ian G <[email-masked]>
Date: Mon, 04 May 2009 19:21:03 +0200

On 4/5/09 16:40, David Shaw wrote:
> We are currently thinking about changing the default primary to
> a 2048-bit RSA key.

I see no problems here, I would agree with the shift to RSA 2048 as the 
default.

iang

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Mon, 04 May 2009 19:28:43 +0200

On Mon, 2009-05-04 at 10:40 -0400, David Shaw wrote:
> We are currently thinking about changing the default  
Nice :-)

> We are not proposing changing our default  
Uhm.. why not?

Chris.

---

From: David Shaw <[email-masked]>
Date: Mon, 4 May 2009 14:00:12 -0400

>> signing hash, which will remain SHA-1.

Concerns about compatibility, mainly.  There is a much larger  
installed base of clients that understand SHA-1 than that understand  
(say) SHA-256.  SHA-256 has only been understood in a non-development  
version of GPG since 2004.  If I recall properly, PGP added it more or  
less around the same time.  That's not that long ago, and I frequently  
see people asking for support for some version of GPG or PGP that  
predates SHA-256.

Mind you, we're not stopping people from choosing to use SHA-256 or  
whatever they like, and with a RSA key, they are of course free to  
choose anything.  SHA-1 is just a default.  One way to look at the RSA  
change, in fact, is to enable users to make their own hash choice,  
which they didn't really have with the previous default of a 1024-bit  
DSA key (so locked at 160 bits).

None of this means that we wouldn't change the default signing hash at  
some point later.  It's just not something we're currently planning on  
for today.

David

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Mon, 04 May 2009 20:07:41 +0200

> see people asking for support for some version of GPG or PGP that  
At least we've seen from the recent SHA1-related events,... that this
point is comming closer ;)

> some point later.  It's just not something we're currently planning on  
Of course :)

Chris.

---

From: Jon Callas <[email-masked]>
Date: Mon, 4 May 2009 16:26:07 -0700

> OpenPGP, so there could be some implementation out there that won't  
> be able to handle it.  I'm not terribly concerned about this, as in  
> practice, the vast majority of code has handled RSA just fine for  
> the past decade, and if a particular user needs to generate a non- 
> RSA key, they can still do so.

PGP does precisely this now. The default you'll get when creating a  
new key is RSA 2048.

I'll invoke Jeff Schiller in this as well. The DSA/Elgamal keys are  
mandatory to implement. Mandatory to implement does not mean mandatory  
to use. It would be perfectly reasonable to make an RSA-only system  
that merely didn't hork up a hairball when it found a DSA key.

Many X.509 systems are like this too -- DSA is the mandatory-to- 
implement, but it's not clear that anyone has ever created a DSA  
certificate outside of interop testing. I'm sure someone can find some  
example that proves me literally wrong on that, but figuratively right.

These days, I see the effective -- ummm, I'm looking for the right  
word, I don't want to say "deprecate" -- minimization of integer  
discrete log. The world is pretty much integer RSA, and moving to  
elliptic curve discrete log.

	Jon

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 05 May 2009 15:02:36 +1200

Jon Callas <[email-masked]> writes:

>Many X.509 systems are like this too -- DSA is the mandatory-to-implement,
>but it's not clear that anyone has ever created a DSA certificate outside of
>interop testing.

Actually even the pretense of that one was dropped a long time ago, no-one
apart from the people drafting the standards (and I'm not even sure about
them) was ever under any illusion that the de facto standard was anything
other than RSA (the PKIX spec still contains DSA signing certs because they
were created by NIST more than a decade ago, not because they reflect current
practice).  People didn't even pretend to do the encryption-algorithm side of
things, X9.42 DH, the only implementation I know of that bothered with this
was the SFL reference implementation, which didn't have any choice in the
matter [0].  Microsoft implemented it as a read-only (i.e. decrypt-only)
option specifically to avoid accusations that they didn't comply with the
standard, but that was about all.  The last time I checked the specs still
fudged the matter by saying that you MUST support one of the following
shopping-list (including things like MD2 and X9.42), but most implementers
know how to interpret this, MUST RSA, WHO-CARES anything else.

Peter.

[0] So everyone claimed standards compliance without being compliant secure in
    the knowledge that since no-one else was either, this could never be 
    checked.

---

From: "Daniel A. Nagy" <[email-masked]>
Date: Tue, 05 May 2009 08:30:07 +0200

There is one reason why I still use DSA keys in some of my applications:

They are much cheaper to generate. I strongly believe that in order for crypto
to become ubiquitous, it is important that key pairs are generated right after
installation.

In case of RSA, it can go wrong in two ways:
1. RSA requires too many random bits and a computer that nobody touches can just
freeze up waiting for random input.
2. The time to generate an RSA key is too long on cheap embedded hardware.

Of course, neither is of concern for GPG's default key; if you have such a
system, just tell it to generate DSA keys. But these two points should be kept
in mind.

The obvious workaround for #1, is to read enough random bits for the security of
the key (e.g. 256) and then seed a secure PRNG with them.

There is, however, no known workaround for #2. Generating a PGP-compliant
1024-bit RSA key on NOKIA 3410 takes at least 20 minutes. More than enough to
make casual users frustrated and throw away the whole thing. Now, of course,
such slow mobiles are not manufactured anymore, but even 2 minutes is
unacceptable, which is the norm for today's low-end phones. And since the market
 values battery life much more than computational muscle (low-end phones are
very responsive at present clock rates) in mobiles, this is not going to improve
too rapidly.

-- 
Daniel

---

From: Werner Koch <[email-masked]>
Date: Tue, 05 May 2009 13:28:14 +0200

> 1024-bit RSA key on NOKIA 3410 takes at least 20 minutes. More than enough to

That is a problem of that implementation.  Even 10 year old smartcards
are able to generate a 1k RSA key in less than 30 seconds.  Modern
cards are much faster.

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.