best practices for creating keys

[James]

All,

I'm pleasantly surprised by the warm and helpful reception of this
community to my many questions. Thank you all in advance for your
detailed and thorough responses. The conversation thus far has been
quite thought-provoking.

I thoroughly read and re-read the responses in this thread, tinkered
with GPG for many hours and poured over the documentation (again). I
still have a few questions:

- 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?
- I'm also curious why the default-preference-list isn't set to
something more secure, as suggested here[1]:

default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES
CAST5 ZLIB BZIP2 ZIP Uncompressed

To be perfectly clear, I am sure the folks who made the decision to
choose SHA256 is _far_ more intelligent than I am and there is sound
reason behind these default choices. I simply would like to better
understand these design decisions.

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

To go a bit further down that rabbit hole, let's say I want to create
a primary key (with certify-only capabilities), several subkeys and
then remove the private key (as has been discussed ad nauseam in this
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?

My concern is that if my primary key is for certification only, how
would it sign other people's certificates to expand the web of trust?
I suspect that if the capabilities are set to _only_ certify, I would
need to sign other people's keys using my subkey. How would this
affect the notion of "even if you lose your subkeys, your identity and
web of trust are not impacted as long as your primary key is not
compromised?"

Seems to me that the primary key /should/ have both certify and sign
capabilities to really be useful, no?

Any thoughts and ideas regarding these questions is greatly appreciated.

James

1 https://help.riseup.net/en/security/message-security/openpgp/best-practices

On Wed, Nov 18, 2015 at 7:35 PM, david at gbenet.com <david at gbenet.com> wrote:
> On 18/11/15 12:08, Peter Lebbing wrote:
>> On 17/11/15 15:33, Andrew Gallagher wrote:
>>>> https://alexcabal.com/creating-the-perfect-gpg-keypair/
>>>
>>> This is a fairly good article - I've used it myself for reference in the
>>> past. Also have a look at:
>>
>> I disagree, I'd recommend people not to read that article, let alone
>> follow its advice.
>>
>> HTH,
>>
>> Peter.
>>
>> [1] https://lists.gnupg.org/pipermail/gnupg-users/2015-November/054685.html
>>
>
> Peter,
>
> When you think about it - if a person stole your laptop with your private and public key on
> it - they still could not use your private key to do anything. Security is in the passphrase
> one sets to use your key. Without it your buggered and so is anyone who has acquired your
> private and public key. They could spend a great deal of time and money - but essentially a
> good passphrase is secure. Brute force - beating the shit out of you - may work - the human
> link is the weakest in the chain.
>
> There is no perfect key - they are all "perfect" their security depends on your passphrase.
>
> Be Happy
>
> David
> --
> “See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the
> kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No
> delusion.” https://linuxcounter.net/user/512854.html - http://gbenet.com
>