best practices for creating keys
Benjamin Black
benjamin.black at gmail.com
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
Linux.conf.au 2015:
https://www.youtube.com/watch?v=_ahcUuNO4so
On Mon, Nov 23, 2015 at 9:25 AM James <jameszee13 at gmail.com> 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
> 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
> >
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151123/0fcee34d/attachment.html>
More information about the Gnupg-users
mailing list