best practices for creating keys

[Pete Stephenson]

On 11/17/2015 1:32 PM, James wrote:
> All,
> 
> I'm just dipping my toes into GPG and am making a significant effort
> to "do things right" out of the gate.

Welcome!

> 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?

At the risk of being vague, "best practices" depend on your situation.

The recommendations for someone wishing to exchange private love letters
with their spouse is far different than someone who would be subject to
physical harm, torture, etc. if the content of their messages were
revealed, or if an adversary were able to spoof messages appearing to
come from that person.

That said, using encryption and signing subkeys for day-to-day
operations and keeping your primary key safely stored and backed-up
offline is a reasonable and sensible thing to do in nearly all
circumstances.

> 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.
> 
> https://alexcabal.com/creating-the-perfect-gpg-keypair/
> 
> I've seen a few other StackOverflow questions about this matter and
> they all seem to recommend the same thing: create one master key, a
> subkey (or more than one) and use those instead of the master key for
> signing as needed.

Yes, this is a reasonable thing to do.

> I'm particularly confused regarding the lexicon used in the article
> above, mostly because of my ignorance (as the article is rather
> clearly written). The author indicates that:
> 
> - we create a keypair
> - added signing subkey
> - exported complete keypair _to TWO files_ (along with a revocation certificate)
> - removed original signing subkey and stash that away safely (in a
> safe, offline)
> 
> My questions (and please forgive my ignorance):
> (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 consist of, respectively, the (a) private and (b) public
components of that keypair.

In the directions provided at the link you mentioned, one creates the
primary key (which consists of the primary signing key and an encryption
subkey) and later creates a second signing subkey.

This bundle of three (sub)keys is exported for offline storage and
backup. There are separate exported files for the private components and
public components.

Later, the primary signing key is removed from the online system and
only the subkeys remain. If one later wished to backup this subkey-only
set of keys, they would be able to export the public components of all
three keys but only the private component to the subkeys. The private
component of the primary key would not be available for export since it
only exists in offline storage.

> (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?

Yes, your private keys are encrypted and protected with your password.

However, this does little good if an adversary is able to compromise
your computer, copy the encrypted keyfile, and install a keylogger so
they know what password to use to decrypt it.

For typical users, this may not be an issue, but you never know.

In the case where a subkey is compromised, it can be easily revoked and
a new one generated.

In the case where one's primary key is compromised, it would also need
to be revoked and a new one generated, but it also means that one would
need to start from scratch to verify their identity to correspondents
and gain signatures from others -- the primary key represents one's
identity and reputation, so to speak, and rebuilding that can be
time-consuming and tedious.

Far better to take a few extra minutes generating a signing subkey and
moving the primary key to offline storage than dealing with the headache
of re-bootstrapping a new primary key.

> (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.

Assuming one has a strong password, brute force should be infeasible.

Keyloggers are a definite risk.

> (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 on both counts.

Additionally, if the signing subkey in the "laptop keypair" is
compromised, the adversary can sign messages claiming to be from you, at
least until your correspondents check to see if your key is updated and
are able to get the revocation notice.

In some cases, this is a greater risk than the adversary being able to
read private messages.

> (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?

A revoked encryption subkey can always decrypt messages that were
encrypted to it. However, other users cannot encrypt new messages to a
revoked encryption subkey (assuming the sender knows its revoked, which
is not always the case).

> Any thoughts / clarification appreciated.

I hope this helps a bit. If I can clarify things more, please let me know.

Again, welcome to the world of GnuPG.

Cheers!
-Pete