best practices for creating keys

[Robert J. Hansen]

> Is this accurate?

Not really, no.

One of the weirdest things about OpenPGP (and, by extension, GnuPG) is
that it provides a great deal of mechanism and very little in the way of
policy.  As a result, it's incredibly difficult to speak about best
practices in specific terms.  What's good practice for one person isn't
so for another.

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

The phrase 'perfect' in that link is a warning.  There is no such thing
as a perfect keypair.  Everything will always involve tradeoffs.  Those
who claim otherwise are usually charlatans.

It's worth noting, BTW, that the official guidance of the GnuPG project
is, "unless you know what you're doing and why you're doing it, stick
with the defaults."

8.1: Q.  Does GnuPG need to be 'tuned' before use?
     A.  No.  GnuPG has sensible defaults right out of the box.  You
         don't need to tune GnuPG before you can use it.

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

Don't.  Stick with the defaults.  You'll be happier, the learning curve
(which is already steep!) will be easier, and you'll enjoy wildly more
safe communications with people.  Once you've used GnuPG for a while,
have become familiar with how it does things and why, learned what
tradeoffs go into different decisions, and so on... at that point you
can generate a new keypair that's made just perfectly, exactly, the way
you like it.  :)

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

It depends.  For some people in particularly high-security applications,
yes, it's necessary.  For instance, the website kernel.org was
compromised a few years ago.  The prospect of an attacker being able to
insert a backdoor into the Linux kernel was so dramatic that a lot of
the kernel developers decided taking extreme steps was appropriate.
Can't fault them for it a bit.

On the other hand, if you're trading fantasy football picks with your
friends, those extreme steps would just be overkill.

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

Keyloggers are a possibility.  So are $10,000-a-night hookers.  It all
depends on your enemy and how much in the way of resources they're
willing to throw at the task of acquiring your passphrase.

Everyone always thinks I'm joking about $10,000-a-night hookers,
incidentally.  I'm not.  If someone were to give me a $100,000 budget to
acquire a secret worth $1,000,000, hiring a high-class call girl for two
weeks would be a *damned* tempting attack vector.  People spend so much
time obsessing over technical minutiae of crypto, and so little time
realizing the weakest part of the system is always the human being... so
why not hire an expert in manipulating human beings?

This said, brute force isn't something you need to worry about.  A
strong passphrase will resist brute force for, quite possibly, longer
than the earth will exist.

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

That's the idea.  That said, this is just one way to solve the problem
of how to recover from a key compromise event.  There are many others.

> (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 use it to decrypt the data.