best practices for creating keys

Robert J. Hansen rjh at sixdemonbag.org
Mon Nov 23 16:52:02 CET 2015


> - I believe that GPG has sane settings out-of-the-box, but prefer to
> verify that trust. ;) Why doesn't GPG set the digest algorithm to
> SHA512 instead of 256 out of the box?

For the same reason it doesn't default to RSA-4096: because the authors
are unconvinced there's a need.  Longer is not the same as better.  At
some point there's such a thing as enough.

SHA-256 is (a) safe enough for essentially all purposes, (b) more
interoperable with other OpenPGP implementations, and (c) better for
human readability.

> I'm also looking for some clarification around the primary key. Out of
> the box it appears that GPG will create a private key for signing and
> certification. Some documentation around the web indicates that the
> primary key can be stripped of all capabilities, leaving _only_
> certify. What are the pros and cons of allowing the private key only
> to certify, then creating a subkey to sign (and another to encrypt)?

I'm going to repeat my earlier advice: learn to walk before you run.
The defaults are safe.  Use them.  We can have this conversation at
great length, but I don't want to encourage you to start doing this.
Quite the opposite.  Please don't.

> thread); it appears that stripping the capabilities of the primary key
> to the bare minimum (i.e., no signing, no encrypting, no
> authenticating) would be "safer," no?

The last word in your sentence is the answer.

It's not safer.  You're talking about making a bank vault door "safer"
by adding a single millimeter of armor plate.  Your attention is better
spent elsewhere, especially right now when you're just starting out.
Focusing on the technical components of the system is ... I hate to say
"you're doing it wrong," but IMO, you are.  The stuff you're paying
attention to right now is pretty much irrelevant and unimportant.  The
stuff you're ignoring is relevant and important.  Start focusing on
that.  I'd start with:

* Do you have a revocation certificate generated?
* Is it stored safely?
* Who has access to your revocation certificate and/or private key?
* How would you know if someone else had access?
* How strong is your passphrase?
* How do you know how strong it is?
* What will you do if you forget your passphrase -- what's your
  fallback?
* If you revoke your certificate, how will you rebuild your personal
  web of trust?
* Is GnuPG integrated into your email workflow?  If not, how can it
  be integrated?
* Have you considered storing your certificate on a smartcard?

These are the places where GnuPG fails in the real world.  In 20+ years
of using PGP 2.6+ and GnuPG 1.0+, I've never -- not once, not ever --
encountered anyone who has said, "man, I really wish I'd stripped my
certificate, that would've saved me no end of grief," and a lot of
people who have said, "man, I really wish I'd safely stored a revocation
certificate, that would've saved me no end of grief."




More information about the Gnupg-users mailing list