best practices for creating keys

Benjamin Black at
Mon Nov 23 16:18:22 CET 2015

Among the privacy-concerned, there is a strong impulse to use the hardest
possible cryptography. The truth is that 2048-bit keys and a 256-bit hash
algorithm are completely secure against brute force attacks, and barring
any surprising developments in cryptanalysis, will remain so for a good
long time.

If someone is really motivated to invade your privacy, they are not going
to attack crypto, they are going to do an end-run around it by attacking
the rest of the system.  The choice of key size has never been the weak
point: it doesn't matter what size key you use if there is a key logger
installed on your system.

Watch this excellent presentation by Peter Gutmann about this subject at 2015:

On Mon, Nov 23, 2015 at 9:25 AM James <jameszee13 at> wrote:

> 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
> On Wed, Nov 18, 2015 at 7:35 PM, david at <david at>
> wrote:
> > On 18/11/15 12:08, Peter Lebbing wrote:
> >> On 17/11/15 15:33, Andrew Gallagher wrote:
> >>>>
> >>>
> >>> 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]
> >>
> >
> > 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.” -
> >
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151123/0fcee34d/attachment.html>

More information about the Gnupg-users mailing list