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."
Great (Score:2)
If they can lead the way on this it shouldn't be long before others follow - gmail, live, etc. Does Yahoo still have a large enough user base to really make others take notice and react if they pull this off?
Re:Great (Score:5, Insightful)
This kind of functionality would be enough for me to switch mail providers.
Yes, yes, it can always be done manually, but I have a lot of friends that aren't as tech savvy as I am. Generating a key, keeping the private one somewhere safe, copying text from the PGP application, pasting it correctly, copying incoming text, pasting, decrypting, etc., etc., it's all a pain in the butt for the typical computer user.
If Yahoo can manage to implement this correctly so that it is safe AND easy to use that's a big deal.
Re: (Score:2)
Is there a reason you don't let your email client and a GPG plugin handled the encryption/decryption?
Re: (Score:2)
Depends on how much you trust your email client
Re: (Score:2)
Re: (Score:3)
If Yahoo can manage to implement this correctly so that it is safe AND easy to use that's a big deal.
Except they can't. Yahoo Mail is webmail which leaves you with two options:
1. They have the keys. In what way is this any better than simply using SSL between mail servers? If you don't manually provide the key or manage your own key then it implies that Yahoo is holding your private key, otherwise webmail wouldn't work.
2. You have the keys, and we're back to complicated key management by end users, manually uploading them when you fire up your browser session, etc.
Public key cryptography is not something t
Re: (Score:2)
Re:Great (Score:4, Insightful)
I'm curious how this could decrease revenue though, because automated scanning is is where the adds come from, and your key would only be as long as effective as a pass-phrase (I assume cloud stored password protected key, with local javascript to unlock the key, and something stored on the local computer to cache the key so the pass-phrase doesn't need to be used constant).
The problem with a cloud stored key that's unlocked by JavaScript with a passphrase is that when the government wants your passphrase they'll either tell Yahoo to silently replace your JavaScript module with one that does keylogging of your passphrase, or they'll take over Yahoo's SSL certificate and inject keylogging JavaScript of their own.
Re: (Score:3)
I'm reminded of one encrypted E-mail provider in this regard. They did nothing wrong, but were given the choice between having people face jail time or hand over data (because if one views E-mail on the server rather than a Java client, the server has the ability to decrypt it.)
I still use them, but I have concerns about tying the endpoint encryption/decryption to the mail provider. As stated above, it wouldn't take much to force Yahoo to push an update to the one "user of interest" that would either reta
Re: (Score:2)
For a moment there, I thought you were talking about , Lavabit [googleusercontent.com]. (That citation is from Google's cache, of their website, that explains why they chose to go under)
Re: (Score:2)
It's based on the Google end-to-end browser extension which handles client side key management on its own and isn't subject to simple MITM attacks.
Re: (Score:3)
Like this? https://addons.mozilla.org/en-... [mozilla.org]
Re: (Score:2)
The problem becomes is the very first time you decrypt something, Yahoo essentially will have your public key.
Unless the decryption is done entirely inside of a trusted agent, there are huge gaps in this.
Storing your unlocked private key in your browser cache?? Really? You're gonna trust your browser with that?
This sounds like a nod to encryption, but unless they do a tremendous job of building in a hell of a secure layer that is 100% rock solid and can't be bypassed, it will have holes in it you could d
Re: (Score:3)
It absolutely does not matter who has your PUBLIC key. The entire point is for the entire world to have it. Now, the PRIVATE key - that you need to keep to yourself, and as secure as possible.
Note: I say "as secure as possible" because, at some point you are trusting an underlying layer to be doing their job correctly - be it browser, email client, PGP application, OS, or that rootkit that got installed.
Re: (Score:2)
Sorry, yes, obviously I should have typed private key -- the public key is completely public.
But if there is ever an instant where Yahoo has your private key, you're screwed, which is what I was saying ... or at least, had intended to say.
Re: (Score:2)
And Google Cannot Follow (Score:2)
Can you imagine Google doing this? It would ruin their business model entirely as they could not use keyword based ads.
And Google Cannot Follow (Score:2, Informative)
google is doing this (http://googleonlinesecurity.blogspot.com/2014/06/making-end-to-end-encryption-easier-to.html)
Re: (Score:3)
Well, they would of course have access to the content before it's encrypted. I don't trust someone else to perform the encryption for me, even on the client side, after everything that happened. But then, even your own OS, all the software that's on your machine, there are sooo many parties involved with so many affiliations, objectives, incentives. If it's not NSA that's peeking through your SSL connection, then it's probably China that bought off your antivirus manufacturer or a Russian hacker who injecte
Re: (Score:3)
There are always ways to ensure data is encrypted and stays encrypted. The simplest is to have an offline computer with a SD card slot, and read/sign sensitive stuff on that machine. Of course, this isn't 100%, but it forces someone to have "boots on the ground" in order to obtain data.
One can get fancy with an offline setup (only boots from a "trusted" USB flash drive only on a keychain, then requires a long passphrase to mount /home, etc), but the idea is to have an air gap, which will block 99.999% of
USB can't be trusted either (Score:2)
You can't trust USB devices these days either [reuters.com].
How about an offline machine that encrypts and prints the encrypted email either as text or as an easy-to-scan graphic and a scanner on the sending computer to scan it in as a graphic, mail the graphic to the recipient, and let him do the de-rasterizing and decrypting?
For receiving mail, have a 3rd computer that is air-gapped from the other two that has a scanner attached to it.
Yeah, it's hard, and yeah, it paints a target on your back about as much as using TOR
Re: (Score:2)
Can you imagine Google doing this? It would ruin their business model entirely as they could not use keyword based ads.
You don't have to imagine. They are already working on it. [dailydot.com]
Where is the private key stored? (Score:5, Insightful)
Re: (Score:2)
Re:Where is the private key stored? (Score:4, Insightful)
With any encryption scheme, key management is usually the biggest pain in the ass. No doubt, this is the biggest problem with implementing encryption for webmail.
Keeping my private key on a USB drive on my keychain could ALMOST work, in that on any desktop or laptop I could insert it to get to the key. For mobile, I think Yahoo will need to release a mail app that supports an easy & secure way to load your key.
Also - keying a passphrase on a moble device to open/sign/encrypt email will suck big time. This could be a great use for a fingerprint sensor on phones.
Re: (Score:3)
PGP uses a public/private key pair. The way it should work: You generate a key pair locally and keep your private (decryption) key to yourself. You can then publish your public key, which other parties can use to encrypt messages to you. Key management would consist of some scheme where the mail service provider would 'sign' your public key to provide authentication and some easy to use public key lookup schemes so other people can securely recieve your key (protect against man-in-the-middle attacks) in ord
Re: (Score:2)
Email is transmitted unencrypted; anyone relaying the message can read it. With PGP way your email is protected in from everybody while it's in transit, although at the endpoints it's only protected from conventional criminals and not Uncle Sam or John Bull.
Re: (Score:2)
The private key can be stored encrypted on their server, and then sent to the client which can decrypt and use it. Decryption uses the user's password. That is similar to how most encryption systems work - the key is itself encrypted with the user's password for storage.
It isn't a perfect solution but it is infinitely better than having no encryption at all. At the very least it will make bulk collection much more expensive.
Re: (Score:2)
Who is in control of that encryption? Who encrypts the encryption around the encryption around the encryption?
If it's Yahoo, then "At the very least it will make bulk collection much more expensive" becomes patently false, because at some point they'll have the private key in the clear.
Every layer in here becomes a weak point where it can be broken, exploited, or bypassed.
And, since this is webmail, you're putting a lot of faith in browsers and various
Re: (Score:2)
Who is in control of that encryption? Who encrypts the encryption around the encryption around the encryption?
It would run in the client, i.e. the browser. Presumably Javascript based and thus open to public scrutiny, so at least in theory it could be audited.
I agree that it isn't perfect, but if we wait for a perfect solution like we have been there will never be one. Yes, the browser could be compromised, but that adds cost (the attacker has to attack the browser first) and gets a third party involved in defence (the browser developer). At the very least it would make bulk capturing of plain text emails impossibl
Re: (Score:2)
Under the system you propose, any time Yahoo (or their federal overlords) wants to read your email, all they have to do is slightly modify some of the JS that your browser runs. Since your browser has your decrypted private key in hand, the JS can then upload it to anywhere the JS tells it to. This only needs to happen once; as soon as the attacker has your private key in plaintext they can decrypt all of your stored email (and sign outgoing emails as you).
Re: (Score:2)
Where is the private key stored?
It doesn't matter.
Yahoo lost control of my login credentials *twice* that I know of. While I have never been to Sweden and Bulgaria, I have apprently sent mail from there. Yahoo is the only service that I have ever used that lost control of my login creds like that - since 1986. Y! mail is now a spamtrap for me. I will never use it again.
Knowing Yahoo, the private key be stored in plaintext on the user's profile page.
--
BMO
Re: (Score:2)
But the private key leaves your system? Even if the private key is encrypted, unless it is encrypted by a different private key on your system, you've just given away your private key (e.g., LastPass has the decryption key to your private key which means LP has your private key, albeit in a convoluted manner). I don't know anything about LastPass, but if this is true, it isn't confidence inspiring.
Web based pgp encryption = no encryption (Score:2, Insightful)
If you enter your message to be encrypted into a webpage, then unless you trust that webpage (yahoo in this case), you shouldn't trust any encryption method that's out of your control. Just use an open source mail client to contact the email server to send the encrypted message. Safe and secure (except for metadata that is).
Awesome!! (Score:5, Funny)
Now all I have to do is get my father, my mother, my sister, my half-sister, my grandmother, my wife, and my assorted friends to learn what PGP is and how to read the emails I send them.
Re: (Score:2)
I think the idea is that it would fall back to unencrypted messaging transparently (perhaps with a warning) when you're sending it to a mailserver that doesn't talk PGP.
Re: (Score:2)
Mailservers don't talk PGP. Even being encrypted it's armored in base64 encoding and transmitted as plaintext. And mail client either knows what to do with it, or not. So, nope, no fallback possible, because you can never know if particular person is going to read it through a client that supports encyption or not. But if you have his\her public key, you might as well assume, that client does know ho decrypt it and if you don't - you can't encrypt it anyway.
Re: (Score:2)
Yahoo has led the charge before in enhancing email standards where bare SMTP wasn’t adequate. They were fairly early adopters of things like DKIM and helped push the industry to support it. If you want to do something that really does have a fallback route, it wouldn’t even take a standards change to have receiving SMTP servers advertise crypto as part of the SMTP capabilities response.
Granted, it’s a big hit to security if your message is encrypted or not based on the remote mail server
Re: (Score:2)
I’m well aware of the difference between SMTP+TLS and PGP. I’m not missing the point at all. TLS & PGP have nothing to do with each other. They’re encryption at two different levels of the stack. You need to use both to get proper end-to-end encryption of message contents and to protect message contents not only from observers on the wire but also observers at the mail host.
TLS (done right) prevents MitM between Yahoo’s SMTP and (let’s say) Google’s. If Google
Re: (Score:2)
Nope. SMTP envelope sender & recipient plus all the headers are still in the clear if you skip TLS. Metadata...
Sure network stacks don’t do PGP. Not sure what that has to do with SMTP which is an application level protocol common on TCP/IP networks and only a tiny part of the entire stack.
SMTP servers currently tell each other about encoding capabilities they may support. The receiving server may
Re: (Score:2)
The whole point of doing it this way is that it is transparent to the user. If Yahoo finds the recipient's public key on a known key server the email gets encrypted automatically. It isn't perfect but it is a massive step up from what we have now.
Re: (Score:2)
You jest, but don't you see how popular webmail providers adding insecure PGP implementations to their platforms would be a pretty good first step to doing exactly what you say?
W... X... Yahoo... Zombie. (Score:2)
At this point, each news story about Yahoo primarily serves to let me know the company isn't quite dead yet.
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: (Score:2)
That's why you should create a revocation certificate when you create the keypair. If you upload the revocation cert to the DB, the keys get removed.
But yes... my first keypair that I created something like 17 years ago when I was first learning about gpg are still in the DBs and come up when my name is searched. It gives me a chuckle.
Re: (Score:2)
Revoking a keypair shouldn't (and doesn't in most cases) remove a key from the database. If revoking the key removed it from the database, you'd effectively hide the fact that a key was revoked and allow its continued use. You want all of your contacts (current and potential) to know that the particular key has been revoked and is no longer valid.
Re: (Score:2)
Old school keyservers are engineered to make deleting keys impossible (where if one server deletes a key, on the next propagation, the key is re-copied.) So, there is a lot of cruft and lost/abandoned keys in the database. However, an attacker can't delete someone's key (they can make a ton of fake keys though.) It is a trade-off.
I have been thinking of a keyserver setup similar to that (where keys are not deleted), but keys would have an expiration date. This could be a few years after the key hit the
Untrustworthy != Useless (Score:2)
Let's hypothesize that Yahoo does this the worst way possible, so we can play to everyone's fears. Let's say the users aren't even going to have the key on their machines ever, and instead, Yahoo explicitly announces they have your private key, and their server will do all the decryption and signing for you (your machine won't even be doing it in Javascript), and they're under US jurisdiction and therefore subject to
Right ... (Score:2)
So, let's think about this.
They can discover your public keys, and then presumably they will need to have your private keys in order to show you the message.
If you have to enter your private key even once, you have to assume they'll keep it.
At which point, you are more secure from casual prying eyes,
Re: (Score:2)
"If you have to enter your private key even once,"
Show me an encrypted mail solution where you don't enter your private key ever.
Theoretically, you could save off any encrypted portions to removable media, move it to an unconnected machine and only there apply your private key, and destroy the media afterwards. That's a lot of tinfoil, though.
Re: (Score:2)
That's what these large corporations all do.
Look at Google, grandstanding about moving things to HTTPS a few months ago [slashdot.org], making things harder for the NSA [slashdot.org], and so on, and yet at the same time they are now proactively scanning people's data for illegal activity and then handing it over to the government [slashdot.org]. Microsoft [slashdot.org] is doing the same thing.
What makes you think Yahoo will do anything different? The whole plan here is probably to get uninformed users to hand over their PGP keys so they can store them.
Even if done badly, might do some good? (Score:5, Insightful)
Key management’s the thing here of course. If it’s on their server, NSA has it, etc. There are ways the key could be encrypted on server, decrypted only locally etc. Most of those have myriad ways the key could be mis-handled, leaked, etc.
That said, I’m kind of leaning towards this being a good thing, even if its implementation isn’t 100% paranoid geek approved secure. Ultimately if the NSA wants to read YOUR stuff, they’re going to (see: $5 wrench). If we assume Yahoo manages to implement this such that key retrieval is at least inconvenient (for $ufficiently large value$ of inconvenient) to anyone other than the account owner, then it should at least complicate NSA’s blanket “read all the things” approach. If it tips the balance back to the point that they actually have to expend more resources than your grandmother’s chocolate chip cookie recipe is really worth, then *maybe* they go back to only reading very interesting people’s emails without a warrant rather than reading everybody’s. I guess that’s worth half a point?
More importantly, if it manages to turn the seething mob of luddite Yahell users onto the fact that encryption is a thing, and explains to them why they want this thing, maybe the “winning hearts and minds” gambit is worth something to the world as a whole, even if the individuals’ email isn’t NSA-proof. Right now most mothers & grandmothers either have no clue what encryption is, or think it’s something only used by hackers, ter’ists, pr0n, criminals, etc. “Them” in other words. If Yahoo manages to convince a sizable portion of the voting public that privacy has worth, and encryption is a way to ensure that privacy, I think that’s a worthy outcome even if the encryption has flaws. Maybe that opens the door to conversations about the difference between effective and ineffective encryption. Maybe it even brings it closer to socially “normal” for someone who knows what effective encryption is to encourage others to use it without being assumed to be a nutcase or worse.
I hate to advocate selling snake oil, but there *are* an awful lot of squeaky snakes around. Maybe the right salesman can convince enough of the populace they need encryption, then we can worry about offering really good encryption for those adequately equipped to work with it.
Mailvelope etc. (Score:2, Informative)
The Mailvelope Plugin - https://www.mailvelope.com - already does that: encrypt webmails a la Gmail, Yahoo, Hotmail or your own Roundcube etc.. It does so in-browser, obviously. Still basic in functionality but works for simply sending messages back and forth. Clear-signing, though available, tends to get screwed up due to message wrapping on the receiving end.
You may also find https://encrypt.to a very cool thing. Essentially a simple contact form, that encrypts the message with GPG and sends it on to the
Why not S/MIME? (Score:4, Informative)
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.
Open Source? (Score:2)
Personally I'm not interested in anything that involves uploading my private keystore to a third party, encrypted or not,
Why should anyone trust this or any other (Score:2)
encryption? I seem to recall news about 6 months ago that RSA Security took $10M from the NSA for allegedly tweaking a random number generator or some such thing. I know PGP is open source, but who knows enough about both encryption math and programming to actually verify that the code is safe, and why should anyone trust them?
Spam (Score:2)
Re:Metadata (Score:5, Informative)
"Metadata" is a media buzzword designed to make you feel good about having your data monitored. They're still monitoring your conversations. Stop buying into their talking points. The headers of your e-mail are as much your data as the body of the e-mail.
Re: (Score:2)
The headers arevery arguably 'metadata' with respect to the body; but 'metadata' are data too; and tend to be data that are also quite powerful for drawing inferences about you even in absence of the body data.
That aside, I think the grandparent point was that, if Team Fed is actually only interested in 'metadata' and definitely not lying about the scope of their extralegal spying, they should
Re: (Score:2)
Re: (Score:3)
It's not the postman reading it though is it? There is a difference between an employee of the post office reading an address to route mail properly vs. gathering all address, storing them and creating programs to discover all connections and relationships between addressees.
It's not that they read the meta data that's the problem, it's what they do with it.
Re: (Score:2)
Yeah, that's some scary stuff and given your findings I guess it blows my analogy out of the water. I still say whether it's snail or email the fact is we need routing data to be readable but that doesn't mean it should be collected and collated for any other purpose.
Re:Oh, god (Score:4, Informative)
Re: (Score:2)
I disagree, didn't improve for me, ofcourse I run older Ubuntu and FF 16. The only saving grace is their smtp server and lets hope PGP is for that only or at least has the disable option. If they add it as a js file to online mail, I cant even imagine the horror show that will ensue.
Re: (Score:2)
Re: (Score:2)
I disagree. Since Melissa took over, I've lost months worth of mail multiple times on two yahoo accounts that I have. (Not saying that this is Melissa's fault). Tech support responded with a shrug. I've been slowly moving my mail off Yahoo.
Re: (Score:2)
Re: (Score:2)
Yahoo hasn't been bad by any means. I use them as my default provider for a spam/mass E-mail catch-bucket. For this purpose, I've never had any downtime or E-mail loss with them in many years. However, since most of the E-mail are lists or just ads from companies I do business with, I may not notice the ad for the latest zombie rated chainsaw available at Gnome Depot that might have gone missing.
Of course, my preference for E-mail is an Exchange or Zimbra hosted provider, but when it comes to free E-mail
Re: (Score:2)
Re: (Score:2)
I don't particuarly mind the current iteration of Yahoo Mail. It looks loosely like the lovechild of Gmail and Outlook.com, and works about the same.
If the interface is unbearable, a local installation of Roundcube (https://bitnami.com/stack/roundcube) will give a different, quite nice alternative, and of course using your favorite POP/IMAP client is viable as well (though admittedly it costs $20/yr for that access).
Re: (Score:3, Insightful)
Any proposal in which users hand over their private keys to a third party (such as a webmail provider) should be assumed to be done with the blessing of, or at the request of, law enforcement or intelligence agencies.
The third party (Yahoo) cannot prevent lawful intercept requests, subpoenas, etc from exposing any data they house as that data has been ruled to be not the property of the individual who supplied it.
A provider wanting to actually improve end-user security must intentionally attenuate any power
Re: (Score:2)
Any proposal in which users hand over their private keys to a third party (such as a webmail provider) should be assumed to be done with the blessing of, or at the request of, law enforcement or intelligence agencies
Where did it say in there that users would hand over private keys to a third party?
Re:It's a TRAP! (Score:5, Insightful)
It didn't but yahoo is a webmail provider and webmail kinda implies that the provider will either be storing the key or at the very least be able to access it by tweaking some javascript a litte.
The reason PGP is difficult for the plebs is that secure encryption requires you to take responsibility for your own key management and ensure to the best of your ability that the key does not leave devices you control (if you are really paranoid you don't even put it on an internet connected machine). If you leave key management up to a third party then your whole security becomes dependent on them.
Re: (Score:3)
webmail kinda implies that the provider will either be storing the key or at the very least be able to access it
Obviously they need access to the PUBLIC keys in order to encrypt messages to the designated recipient. The whole point of public-key cryptography is that revealing the public key doesn't compromise security.
Re: (Score:2)
Did you not understand the part about the plebs taking responsibility, or not, for their own keys (private and public), in the post that you replied to? The plebs can barely understand how to manage their own passwords, let alone the legal ramifications of what it means to be a Safe Harbor.
Re: (Score:3)
The problem is not so much sending encrypted mail. The problem is sending signed mail or receiving encrypted mail. In those cases you need to provide your private key to the mail software.
If the mail software is running on a third party server then that means handing your private key over to them. If the mail software is javascript in a browser then the javascript could be written to keep the private key in the browser but there is a significant risk of the javascript being quietly substituted.
The private key would have to be handled locally (Score:2)
Hushmail did some stuff client-side. In order to be immune from government interference, Yahoo webmail would have to be similar.
To be trusted for receiving mail, they would need to release an open-source web plugin or local application that hooked into the web browser to do the decrypting client-side, OR have encrypted message be downloadable but not directly readable within the web browser.
Bonus points if the client-side software is developed by a well-respected known-to-value-freedom 3rd party using a st
Re: (Score:2)
Bingo. You've just busted the cloud-marketing machine that is Yahoo!
Re: (Score:2)
...I should also add, watch Yahoo claim to be what Lavabit once was.
Re: (Score:2)
Clearly, you can only trust encrypting mail clients with no internet connectivity.
Re:It's a TRAP! (Score:4, Insightful)
Not necessarily. Securely handling keys is indeed impossible for untrusted Javascript, but it should be feasible to provide a browser add-on (analogous to Enigmail for Thunderbird) with a key management UI and PGP bindings for Javascript. As long as that add-on is open-source and vetted by browser vendors, you don't need to trust Yahoo's web page (let alone their server) with your private key.
Ideally, this would be a core part of Firefox / Chrome, or at least a unified add-on, but in practice Yahoo!, Gmail and others would probably insist on making their own.
However, a general-purpose add-on could potentially allow encrypting/signing the content of any text field in a page, so it wouldn't depend on the email provider's support.
Re:It's a TRAP! (Score:5, Insightful)
It's implied by the fact that it's webmail. Does your browser have an OpenPGP library? Does it check all the Javascript that it downloads and executes, against some repository's whitelist? You have to assume the key isn't handled safely, unless you can answer Yes to these questions. And a lot of webmail users expect the server to be able to search and that's obviously impossible unless the server can read, so it's not like the unsafeness stems just from potential trickery.
That said, the more interesting question is what social effect this might have. Even "bad" use of OpenPGP could start conditioning more people to being familiar with, tolerating, expecting PGP. Get into a better frame of mind, and better habits can come later. And with good habits, some security could eventually emerge. The security wouldn't be there for Yahoo webmail users, and yet some users might end up having Yahoo webmail to thank for it.
And let's face it, the barriers to secure communication are almost entirely social; we choose to have insecure communications. Anyone who is working on that problem is working on The Problem.
Re: (Score:3)
Indeed, this. Although I can think of no way to securely do PGP in a web interface (as even a browser plugin, suggested by an earlier poster, is vulnerable to the NSA et al going to Google, Firefox and Microsoft and demanding they implement a shim allowing them access to the innards of the browser memory), even fake security does raise exposure to encryption, and systems not compliant or that munge the encryption will be fixed to not mess up the emails. This is good, and then we, as the open source communit
plugins (or standard) (Score:2)
as even a browser plugin, suggested by an earlier poster, is vulnerable to the NSA et al going to Google, Firefox and Microsoft and demanding they implement a shim allowing them access to the innards of the browser memory
But nothing prevents the two end-point on using known-sure browser without backdoor to access the website.
If it's done in a standard manner (i.e.: a browser plugins that provides a standard way to create "securearea" a textarea whose content is transparently encrypted/decrypted by the plugin outside of the reach of the website), or even better if it's integrated into web standards (make the "securearea" tag part of HTML5 just like the "video" tag), then any compatible implementation could collaborate with a
Standards ? (Score:2)
Does your browser have an OpenPGP library?
Well, actually *THAT* would be a very good target for standardisation.
Forget about all this bullshit for adding standardised DRM protection on HTML5 videos...
We need a specific and standard way to declare a "public key protected" text fields.
All that the websites and the javascript ever see is just an encrypted string, the browser is in charge of encrypting/decrypting and presenting the content, all outside the scope of the webmail itself.
Same for attachments (browser handle the downloading and decrypting).
Private keys are probably kept client-side... (Score:3)
"Does your browser have an OpenPGP library?"
It looks like it will soon:
http://googleonlinesecurity.bl... [blogspot.com]
Re: (Score:3)
Any proposal in which users hand over their private keys to a third party (such as a webmail provider) should be assumed to be done with the blessing of, or at the request of, law enforcement or intelligence agencies
Where did it say in there that users would hand over private keys to a third party?
At best they would give the keys to software provided by Yahoo and running in their browser. Law enforcement could compel Yahoo to provide a backdoor to that software or they could compromise the encryption in the browser. Unlike java, javascript has nothing to stop code from a different source interfering with other code running in the browser.
Re: It's a TRAP! (Score:3)
I dunno I worked for a large scale email company for almost a decade... They basically persused every possible encryption method possible except for pgp. Mainly for business reasons.. For instance if an employee ever left the company, the private key basically went with them so if emails were encrypted. All of it would be effectively lost to the city company.
This lead to developments efforts to hat would basically give lip service to encryption but little real security...
While a lot depends on what im
Re: (Score:2)
The ironic thing is that the commercial version of PGP by Symantec has the ability to use/force use of an ADK, or additional decryption key. This isn't key escrow (where someone else has your private keys), but messages are encrypted to a recovery key so that even if a user loses their key, data is still recoverable.
Re: (Score:2)
> so that even if a user keeps quiet after waterboarding, data is still recoverable
FTFY
Re: (Score:2)
And, under no circumstances should anybody believe they have any security with this.
You know what ADK is? A back door. So, either they're encrypting it twice (once with your key, once with the other), or they've poked holes in the encryption and it is complete garbage.
This is useful for casual prying eyes, but it assumes you have 100% explicit trust in the agent who h
Re: (Score:3)
You know what ADK is? A back door. So, either they're encrypting it twice (once with your key, once with the other), or they've poked holes in the encryption and it is complete garbage.
The usual way to do multi-recpiant encryptions is you encyrpt the message with a freshly generated symmetric session key. Then you encrypt the sesssion key multiple times with the recipiants public keys.
but it assumes you have 100% explicit trust in the agent who has the ADK
Indeed it does, in security there is always a balance between keeping prying eyes out and keeping records available to those with legitimate reason to access them.
Single recipient too. (Score:2)
Well actually that's also the way to do single recipient mail too.
Assymetric encryption is very ressource demanding and only work using fixed-sized blocks.
Better encrypting a session key even for 1 recipient.
Re: (Score:2)
Of course an ADK requires that you trust the entity that holds the ADK. In the GP post, he lamented that when people left the company they took their keys with them. If it is company mail produced on company time I don't see the problem with the company holding a key to decrypt it. With PGP, you can also split the ADK into multiple parts so that you would need several people at the company agree to decrypt anything. That way a single employee cannot arbitrarily use the ADK. Of course, if they are using
Re: (Score:2)
What a silly feature. Just put "Cc: BackupDood" at the top of your email, and you get the same thing.
Re: (Score:2)
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.
Re: (Score:2)
It doesn’t necessarily need to do en-/decryption on the server side. Javascript is more than adequate to perform the necessary math.
Re: (Score:2)
And a binary copy of PGP could be trojaned to send your decrypted private out somewhere or steganograph it into the ciphertext the second you provide your passphrase. You need to trust your implementation to handle your key in a responsible manner. All I’m saying is that by depending on Javascript to do the math, it’s possible for the system to be designed such that your decrypted private is never present on Yahoo’s servers but only on your own hardware.
You still have all the usual probl