Generating a new key

David Shaw dshaw at
Sun Mar 21 04:28:55 CET 2010

On Mar 20, 2010, at 9:09 PM, Doug Barton wrote:

> I've been following the discussions about new key types, sizes, etc.
> with interest for a while now since my old DSA/El Gamal key (vintage
> 2003) is a bit long in the tooth, and I've been lusting after bigger
> hashes, and better long-term security. Up till now my interest has been
> mostly academic since I didn't have the easy access to key signing
> events that I once did, but there is one coming up next week at IETF 77
> that I will likely be attending, so I thought now is a good time.
> Here are my choices for the various options, I'm curious if anyone sees
> anything glaringly horrible about them. :)

As a rule of thumb, only deviate from the defaults if there is a particular reason to do so.  The defaults are carefully chosen to be a reasonable choice for the majority of people.

> gnupg version: 2.0.14
> The FreeBSD ports for gnupg, libassuan, etc. haven't been updated yet,
> and unless there is a truly compelling reason to update them myself, I'd
> rather put my time into something else.

No worries here.

> Signing key: 2048 RSA
> 1024 RSA seems right out based on recent events, however I can't see any
> reasoning for a larger signing key, and I've read all the discussion on
> why this is the default and don't see anything wrong with it (in my
> expert opinion). :)

It's the default anyway, so that's fine.

> Capabilities: SCA
> I don't have a particular need for an authentication key atm, but I
> might someday, and I'd really rather avoid a proliferation of new keys,
> subkeys, etc. I'm aiming to make this my one key for another good long
> while. If I get 7 years out of this one (like I did my DSA key) that'll
> be a good achievement I think.

I wouldn't do this.  The default is SC (sign+certify).  If you want an authentication key at some point in the future, I recommend a subkey.  If you make your primary key the authentication key, you need to have that key online, and lose the ability to store it offline someday.

> Photo UID: 30915 bytes
> This is a 175x200 jpeg, and I didn't think a 30k image was that large,
> but gpg complains that it's "very large" or some such. I could strip it
> down to a smaller size if this is truly too large, but the file size now
> makes the photo just usable as it is.

30k is a little big, but don't shrink its dimensions.  Instead, shrink its color depth and perhaps lower the JPEG quality level a bit.

> Encryption subkey: 4096 RSA
> Here is where I differ from the defaults. I understand the argument
> about a 1,000 meter wall vs. a 100,000 meter wall, however the larger
> key doesn't make any appreciable difference to the encrypted file size,
> and I like the idea of having an encryption key large enough that I
> don't have to worry about things staying encrypted for the foreseeable
> future.

Frankly, you don't have much to worry about with a 2048 bit key either.  It also is slightly odd to use an encryption key that is so much larger than your signing key.  Another reason to not go 4096 is it removes the ability to use a smartcard in the future.  The smartcard is (currently) limited to 3072-bit keys.

I'd leave this at the default value.


More information about the Gnupg-users mailing list