best practices for creating keys

[James]

Robert,

I appreciate the input and hear you loud and clear.

I respect that GPG makes sane, technically secure and well-thought-out
decisions. As I mentioned in my previous response, the folks that
designed and coded GPG are likely far more intelligent than I. This
does not assuage my deep curiosity to understand the various knobs and
gears that can be tweaked. Said deep understanding also puts me in a
position whereby I can more easily deal with various issues or
complexities down the line.

The same can be said for almost any complex system, software or not.

It seems to me that, perhaps, making these sorts of decisions up front
is of some value. If you create a primary key, upload it to a public
keyserver and later decide: "hrm, my public key should really only
certify, not sign," it's a bit too late. (although not impossible,
difficult to change ex post facto).

It's also worth noting that the suggestion to remove the primary key
from your laptop isn't thrown up on a few random blogs; instead it is
something that other projects[1] encourage.

If one's primary key is his or her identity, I'd like to be certain
that I correctly create the key(s). Thus being meticulous and careful
in creating primary key seems like a reasonable step, IMHO.

Finally, I do appreciate the list of things that I should focus on --
there are several I had not contemplated and will now do so.

James

https://wiki.debian.org/Subkeys

On Mon, Nov 23, 2015 at 10:52 AM, Robert J. Hansen <rjh at sixdemonbag.org> wrote:
>> - 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."
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users