best practices for creating keys

Andrew Gallagher andrewg at
Tue Nov 17 15:33:40 CET 2015

On 17/11/15 12:32, James wrote:
> Based on my research, it is my understanding that "best practices"
> dictate we should have one master key with subkeys for specific
> purposes (personal work, "work" work, etc.). The master key is kept on
> an "offline" computer and then used only to revoke particular subkeys
> if needed.
> Is this accurate?

Pretty much. You also need your primary private key if you want to
update the details of your public key (as it needs a self-signature) and
for certifying other keys (web of trust).

> Below is an article that seems to discuss precisely this subject. It's
> a bit dated (2013), so am looking for clarification on whether or not
> this is the _best_ way to deal with GPG, key pairs, etc.

This is a fairly good article - I've used it myself for reference in the
past. Also have a look at:

> My questions (and please forgive my ignorance):

Nothing to forgive!

> (a) when you create a the original keypair and export, it exports to
> _two_ files; how then, after adding another signing subkey, does the
> export also result in two files? Are both signing subkey keys
> (original and additional) embedded in your private key when exported?

The two files are the public key (including all public subkeys) and the
private key (including all private subkeys).

Think of your keypair as a pair of matching tree structures:

PUBLIC  | (private)
PRIMARY | (primary)
--SUB-- | (--sub--)
--SUB-- | (--sub--)
--SUB-- | (--sub--)

Each "key" (singular) really consists of multiple keys (plural), a
primary and some number of subkeys that are signed by the primary. This
singular/plural inconsistency in terminology is probably the confusing
bit. ;-) You can create as many subkeys as you like, but they can all be
considered part of your "key" (singular).

GPG will by default create a subkey marked usable for encryption only
(as there are attacks against keys that are used for both encryption and
signing). The best practice method above creates a separate signing-only
subkey so that you don't need to use your primary key for signing messages.

Your "laptop key" is then just your private key-tree with the primary
private key safely deleted.

> (b) is this all really necessary? Aren't your private keys, when
> secured via a password, encrypted via AES256? If you have a super
> secure password / passphrase, is this all really necessary?

You just answered yourself below. ;-)

> (b2) can someone please explain what sort of situation would be
> necessary for a private key that's been secured via a password is
> actually compromised? Are we talking about keyloggers, etc. here?
> Brute force? etc.

Keeping your primary private key offline does not help against brute
forcing, but it does protect against keyloggers, rootkits, physical
loss/theft etc. The only protection against brute force is key
complexity/length, but brute forcing a properly generated key is
vanishingly rare - you are much more likely to lose it by less glamorous

> (c) if your "laptop keypair" (terminology from article above) is
> compromised, data encrypted against that subkey will be compromised as
> well, correct? The only benefit to creating subkeys is that you can
> then revoke the subkey using your original signing key and let the
> world know that you're still "in control" of your identity, correct?

Correct. As you worked out yourself, it is of limited use in the case of
encryption subkeys (as anything encrypted against that key is now
exposed) but it is VERY useful for signing and authentication subkeys,
so long as you notice the loss and revoke them in a timely fashion.

> (d) let's say you've used the laptop keypair to encrypt a wide swath
> of data (emails, actual files, etc.). If you revoke the laptop subkey
> because it's been compromised, can you still use that compromised
> keypair to _decrypt_ the data, or is it lost forever?

You can continue to decrypt with a revoked encryption key. Revocation
does not make the private key unusable, it just marks the public key as
"do not use". Best practice is to regularly revoke your encryption
subkeys and regenerate them so that only a finite amount of data is
encrypted with each subkey, limiting the impact of a disclosure. How
often you want to do this is up to you - if you rarely get encrypted
emails it might not be worth your while, but if you are a heavy user
then I'd strongly recommend it.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20151117/42e014de/attachment.sig>

More information about the Gnupg-users mailing list