An Op-Ed piece from ArsTechnica:
Every once in a while, a prominent member of the security community publishes an article about how horrible OpenPGP is. Matthew Green wrote one in 2014 and Moxie Marlinspike wrote one in 2015. The most recent was written by Filippo Valsorda, here on the pages of Ars Technica, which Matthew Green says "sums up the main reason I think PGP is so bad and dangerous."
In this article I want to respond to the points that Filippo raises. In short, Filippo is right about some of the details, but wrong about the big picture. For the record, I work on GnuPG, the most popular OpenPGP implementation.
(Score: 2) by darkfeline on Monday December 26 2016, @10:15PM
Both your argument and the original article's argument is "PGP support sucks" which is 1. not a problem with PGP itself and 2. a chicken-and-egg problem of adoption.
PGP itself works entirely as intended. In my opinion, all we really need is PGP integration into Gmail. Give Google your public key, and let you sign messages through JavaScript (so you keep your private key). Your Gmail contacts would be able to check against your public key. There needs to be an easy way for the vast majority of normal users to start using PGP, then PGP support will grow and that will open the way for more secure implementations (if you don't trust Google as a public key store).
Join the SDF Public Access UNIX System today!
(Score: 2) by TheRaven on Tuesday December 27 2016, @07:46AM
Both your argument and the original article's argument is "PGP support sucks" which is 1. not a problem with PGP itself and 2. a chicken-and-egg problem of adoption.
That's not quite my argument. My argument is that there are two standards for doing encrypted email. One is well supported by all mail clients out of the box and easy to use, the other is PGP.
sudo mod me up
(Score: 2) by darkfeline on Tuesday December 27 2016, @06:04PM
S/MIME works well when supported by corporate IT. I have had less luck getting S/MIME to work in a personal context than I've had with PGP.
If companies used PGP internally, it'd work just as well as S/MIME.
Join the SDF Public Access UNIX System today!
(Score: 1) by cpghost on Tuesday December 27 2016, @03:20PM
Well, since Google needs to scan your mails to target advertisers, PGP integration into GMail won't happen, at least not on the free GMail accounts. But maybe they'll be willing to integrate that on their Gmail-for-Work paid services.
And even if they integrated PGP into GMail, there's still the issue of key management. In other words: where do you store the private key? If you keep it on your computer, you'll need to sync it to your mobile devices, it can get lost, etc. If you upload it to Google's servers and attach it to your Google Account so it is always available, then even if protected by a passphrase, that kinds of defeats the purpose of a private key, doesn't it?
Cordula's Web. http://www.cordula.ws/
(Score: 2) by urza9814 on Wednesday December 28 2016, @05:40PM
Well, if you're using PGP on Gmail, you've really got to trust Google anyway, so you might as well just give them the key.
The OP suggested giving Google your public key, then having them sign/encrypt for you. But that means you give Google the plaintext contents of every message. Even if they encrypt locally in Javascript, unless you're checking the code every time there's no guarantee they haven't added Javascript to pull the plaintext as well. I don't really understand how there's any benefit in not giving them the private key if you're giving them the ability to read all of your mail anyway...
So, there's two options. You encrypt locally, then copy/paste into Google. Which means there is no "Gmail integration" problem, because there can be no integration. The alternative is you give Google both the public and private keys and trust that Google will keep it secure and that your SSL connection is safe. Might as well let them generate the keys in the first place, since I don't see the average user being willing to do that.