Yahoo To Add PGP Encryption For Email 175
Bismillah (993337) writes Yahoo is working on an easy to use PGP interface for webmail, the company's chief information security officer Alex Stamos said at Black Hat 2014. This could lead to some interesting standoffs with governments and law enforcement wanting to read people's messages. From the article: "'We are working to design a key server architecture that allows for automatic discovery of public keys within Yahoo.com and other participating mail providers and to integrate encryption into the normal mail flow,' Stamos said."
PGP Is the easy part. Key mgmt is hard (Score:3, Interesting)
Implementing PGP with (yet another) public key database is easy enough to do. The biggest issue will be the management and protection of the private keys needed to sign and decrypt incoming messages. If Yahoo ends up holding the private keys, then it's completely untrustworthy and useless.
Also, why do they want to create another public key DB? Keybase.io is very nice, and the existing PGP.net servers have a huge existing database of public keys, though it is nearly impossible to delete a key once its published.
Re:Why not S/MIME? (Score:4, Interesting)
S/MIME is better than nothing. I use it often because of exactly the fact that it is part of most MUAs, and it takes zero effort on the recipient's side for a signature to be validated.
However, S/MIME is just like SSL/TLS, being one bad CA away from being useless, while PGP's web of trust system is far more robust and can handle a bad key introducer fairly easily.
If we can get people used to making webs of trust, especially if Yahoo made some type of utility for this, it would go far with security.
no private key to SEND GPG. End bulk collection (Score:4, Interesting)
There are two ways this can work well.
Yahoo, or any other email provider, doesn't need access to the private key to SEND encrypted email. Someone who wishes to receive encrypted email publishes their PUBLIC key. The message is encrypted with the public key. Yahoo can automatically check popular key servers and if the recipient publishes a private key, offer a one-click option to encrypt the email. Because the recipient publishes a key, that pretty much advertises that they know how to read a message sent with their key. They don't need Yahoo's help on the receiving side. So sending encrypted email is no problem. There are some details to get right, but no fundamental problem.
Now let's consider reading encrypted email via webmail. It has been pointed out that the obvious implementation would be to use JavaScript to do the decryption. Maybe the Yahoo team will come up with something more clever, but let's assume they don't. In that case, it's been pointed out that Yahoo could replace the encryption JavaScript for targeted users, at specific times. That's true until someone releases a browser plug-in that checks the hash of the script, but there is still a big gain. Until then, Yahoo could be ordered to intercept SPECIFIC, TARGETED users. As opposed to today, when Yahoo can be ordered to provide a tap for NSA to collect ALL emails. Getting rid of that bulk collection capability is a big win.
Note that if the FISA court did order Yahoo to switch out the JavaScript, the likelihood that would be detected would be proportional to how often they did it. If they did it once, they'd almost surely get away with it. If they did it all the time, they'd almost surely be caught. So they'd want to use it rarely, saving it for high value targets in order to keep it secret. That's actually exactly what I WANT for a widely deployed technology. The ideal, I think, would be that the technical details are such so that the government can't read everyone's email, but in special cases a proper court can authorize reading Osama bin Laden's email and the technology allows that to happen only rarely. So this actually comes pretty close to the ideal, assuming that NSA wants to keep the Yahoo hack secret and therefore rarely uses it.