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 <jamesze...@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, da...@gbenet.com <da...@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@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users >
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
