Yahoo To Add PGP Encryption For Email

It's a TRAP! by Anonymous Coward · 2014-08-08 00:44 · Score: -1

Because the NSA and Yahoo! are like thiz!

Re:It's a TRAP! by Anonymous Coward · 2014-08-08 01:15 · 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 they might have which grants anyone -- including themselves -- the ability to weaken the controls surrounding user data.
Re:It's a TRAP! by jep77 · 2014-08-08 01:38 · 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! by IMightB · 2014-08-08 01:42 · Score: 2

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 implementation details they come up with, yahoo seriously perusing PGP is probably a good thing.
Re: It's a TRAP! by mlts · 2014-08-08 02:00 · Score: 1

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: It's a TRAP! by Greyfox · 2014-08-08 02:02 · Score: 1

Oh that's an easy problem to solve -- you just require the user to store their key in a keystore that makes sure you could get at it if you ever want to decrypt their E-Mail. The vast majority of the users would never realize that completely eliminates the security they were looking for when they decided to use encryption in the first place. If you really need an excuse (which you don't,) you could make a nice shiny feature like the ability to decrypt your mail from any machine on the internet.

--
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Re: It's a TRAP! by 2fuf · 2014-08-08 02:05 · Score: 1

> so that even if a user keeps quiet after waterboarding, data is still recoverable
FTFY
Re: It's a TRAP! by gstoddart · 2014-08-08 02:13 · Score: 1

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.
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 has the ADK -- and, given that this is Yahoo and the PATRIOT Act and National Security Letters still exist, you can't.
Because all that really happens is there is a central authority who can decrypt anything anytime they wish. Which, is pretty much what you have now.
So, no way I'll send you anything using this encryption besides my tomato sauce recipe.

--
Lost at C:>. Found at C.
Re:It's a TRAP! by petermgreen · 2014-08-08 02:25 · Score: 4, 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.

--
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Re:It's a TRAP! by Sloppy · 2014-08-08 02:31 · Score: 4, Insightful

Where did it say in there that users would hand over private keys to a third party?
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.

--
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Re: It's a TRAP! by petermgreen · 2014-08-08 02:31 · Score: 2

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.

--
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Re: It's a TRAP! by Sloppy · 2014-08-08 02:46 · Score: 1

What a silly feature. Just put "Cc: BackupDood" at the top of your email, and you get the same thing.

--
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Re:It's a TRAP! by Steve+B · 2014-08-08 02:50 · Score: 2

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.

--
/. If the government wants us to respect the law, it should set a better example.
Re:It's a TRAP! by SpzToid · 2014-08-08 02:52 · Score: 1

Bingo. You've just busted the cloud-marketing machine that is Yahoo!

--
You can't be ahead of the curve, if you're stuck in a loop.
Re:It's a TRAP! by SpzToid · 2014-08-08 03:08 · Score: 1

...I should also add, watch Yahoo claim to be what Lavabit once was.

--
You can't be ahead of the curve, if you're stuck in a loop.
Re:It's a TRAP! by SpzToid · 2014-08-08 03:15 · Score: 1

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.

--
You can't be ahead of the curve, if you're stuck in a loop.
Re:It's a TRAP! by petermgreen · 2014-08-08 03:20 · Score: 2

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.

--
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Re: It's a TRAP! by Enigma2175 · 2014-08-08 03:26 · Score: 1

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 Symantec's key server they can just configure it to keep copies of a user's key or handle all the encryption/decryption on the server itself.

--
Enigma
Re:It's a TRAP! by radarskiy · 2014-08-08 03:34 · Score: 1

Clearly, you can only trust encrypting mail clients with no internet connectivity.
Re:It's a TRAP! by Arancaytar · 2014-08-08 04:05 · Score: 3, 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.
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! by cdwiegand · 2014-08-08 04:48 · Score: 2

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 community, can work on creating truly secure systems / interfaces.

--
. Define sqrt(x) as something really evil like (x / rand()), and bury it deep. Watch your coworkers go nuts.
Re:It's a TRAP! by MichaelSmith · 2014-08-08 09:53 · 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?
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.

--
http://michaelsmith.id.au

Republicans Hate College Education - and Obama by Anonymous Coward · 2014-08-08 00:44 · Score: -1

http://freebeacon.com/blog/do-nothing-millionaire-laments-that-millionaires-do-nothing/

"The University of California-Berkeley pays former Clinton Labor Secretary Robert Reich $240,000 a year to teach one class about the scourge of income inequality and attend Occupy Wall Street rallies. (He also makes up to $100,000 per speech.)

Reich, a millionaire, is very concerned about rich people who, unlike him, don't really deserve their fortunes. "What someone is paid has little or no relationship to what their work is worth to society," he wrote in a recent blog post, without any apparent irony.
Wonder what Reich thinks about Paul Krugman, who draws a $225,000 annual salary from the (publicly funded) City University of New York, and doesn't even have to teach a single class?"

---------

How about that you stinking leftist cowards! Bashing the rich night and day! Tax the rich, steal their money and give it to the poor oops I meant give it to the state where it will end up as birbes to the ruling class and to the pockets of the elite in congress and the crony corrptpocrats everywhere.

Reich makes 1/4 million a year teaching his socialists gobbldegook to the skulls full of mush, and goes on to advocate taxing the hateful rich people into the poor house. No one should be rich, ever, anywhere. Except for the *right* people of course, cause money is fun you know.

I hate you fucking socialists more and more every day. Fuck you all.

Re: Republicans Hate College Education - and Obama by twistedcubic · 2014-08-08 14:50 · Score: 1

...(He also makes up to $100,000 per speech.)...Reich, a millionaire, is very concerned about rich people who, unlike him, don't really deserve their fortunes. "What someone is paid has little or no relationship to what their work is worth to society," he wrote in a recent blog post, without any apparent irony.
There is no irony. He knows well that $100,000 per speech is ridiculously overpaid. But as we all know, anyone would be a fool not to accept cash for such little work.

Great by just_another_sean · 2014-08-08 00:47 · Score: 1

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?

--
Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal

Re:Great by AvitarX · 2014-08-08 00:52 · Score: 1

It'll be interesting if cloud e-mail makes things more private in the end.
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).

--
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
Re:Great by fuzzyfuzzyfungus · 2014-08-08 01:05 · Score: 1

Hopefully they'll manage to make "Keysocial! The social network for crypto keys!" a less insecure proposal than it sounds on first glance. I'm not optimistic; but it would be nice.
Re:Great by KermodeBear · 2014-08-08 01:27 · Score: 4, 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.

--
Love sees no species.
Re:Great by Anonymous Coward · 2014-08-08 01:31 · Score: 0

Yes, I think they do.
Even more importantly, a service such as this one would attract new users (such as myself) to Yahoo mail.
Re:Great by hawguy · 2014-08-08 01:47 · Score: 3, 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:Great by gstoddart · 2014-08-08 02:03 · Score: 1

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 drive a truck through.
So, do you think you will ever trust a cloud e-mail provider with your public key for even a millisecond? Because, really, at that point, they have your public key and can keep it (and hand it over to law enforcement).
I just don't see a web browser being anywhere near capable of providing the end to end security needed for this.
Key management is hard, and if your web mail tries to make it easier for you, it will make the system inherently less secure. And those will be the parts people will spend the most time attacking -- I don't need to defeat encryption if I can figure out how to obtain your private key.

--
Lost at C:>. Found at C.
Re:Great by Anonymous Coward · 2014-08-08 02:07 · Score: 1

I'm curious how this could decrease revenue though, because automated scanning is is where the adds come from
According the summary its webmail. I don't see anything that prevents them from scanning the mail before encryption, or hand over a copy to NSA if they are asked to.
The only difference this adds is that some untrusted middle-point can't snoop your mails so NSA can't just grab them mid-transition without asking Yahoo first.
I don't see any scenario where anyone working at Yahoo would stand up against NSA and say no when handed an official looking document that claims that they will be personally dragged to a secret court if they don't comply.
Re:Great by mlts · 2014-08-08 02:08 · Score: 2

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 retain the decrypted E-mail or upload the key.
What Yahoo -can- do is make key exchange and key management easier, with keyserver functionality. That way, Alice can sign Bob's key for Charlie, upload it to Yahoo's keyserver, then Charlie will have a good chance that the key purported to be Bob's is actually the right one. Making a web of trust easier for people is something that is desperately needed.
Re:Great by Bender0x7D1 · 2014-08-08 02:27 · Score: 2

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.

--
Reading code is like reading the dictionary - you have to read half of it before you can go back and understand it.
Re:Great by gstoddart · 2014-08-08 02:29 · Score: 1

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.

--
Lost at C:>. Found at C.
Re:Great by anagama · 2014-08-08 02:44 · Score: 1

Is there a reason you don't let your email client and a GPG plugin handled the encryption/decryption?

--
What changed under Obama? Nothing Good
Re:Great by CastrTroy · 2014-08-08 03:18 · Score: 1

The problem is that just switching yourself doesn't solve anything. You have to convince all your friends to switch so that they can send and receive encrypted messages too. That might actually be their plan. Get the techies to go for it, and they'll tell all their friends to go for it. It may possibly work but most people don't use email for anything confidential. Nobody cares if somebody else is reading the marketing emails or plans with family that are being sent to them. Plus, as pointed out by others, using webmail means that there could always be chance that the webmail provider is secretly keeping a copy of your private key, allowing them and the NSA to read your mail anyway.

--

Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Re:Great by SpzToid · 2014-08-08 03:43 · Score: 1

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... I still use them...
For a moment there, I thought you were talking about , Lavabit. (That citation is from Google's cache, of their website, that explains why they chose to go under)

--
You can't be ahead of the curve, if you're stuck in a loop.
Re:Great by ShaunC · 2014-08-08 04:43 · Score: 1

I believe he's speaking of HushMail.

--
Thanks to the War on Drugs, it's easier to buy meth than it is to buy cold medicine!
Re:Great by wiredlogic · 2014-08-08 05:06 · Score: 1

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.

--
I am becoming gerund, destroyer of verbs.
Re:Great by Anonymous Coward · 2014-08-08 05:28 · Score: 0

Or, you know, waterboard you until you give them the passphrase.
Re:Great by davidwr · 2014-08-08 05:49 · Score: 1

The solution is to make it easy to do and hard to corrupt.
If Yahoo published an API for web-browser plugins and provided their own open-source reference implementation, or better yet if they handed off maintenance to a strongly-pro-strong-encryption entity, then both goals would be achieved.
Want to send an email encrypted for the first time in a given web browser on a given computer while logged in as a given user? Yahoo would direct you to either take the easy route and download a plugin from the pro-strong-encryption group's web site, invite you to read instructions for installing your own plugin, or invite you to upload or paste in a pre-encoded message. Yahoo could also present an option for "non-senstive email" where you just tick a checkbox that says "encrypt before delivery." If you have never created a public key, it would either invite you to upload a public key or warn you that the copy in your "sent" folder would be stored without any additional encryption.
Need to read an encrypted email or read something you've sent that's stored in your sent folder encrypted with your public key on a web browser/computer/user-login that isn't set up for Yahoo PGP yet? Yahoo would direct you to take the same steps as above or invite you to view or download the encrypted message so you could decrypt it with a different program locally.
What would the plugin do?
For receiving, it would decrypt the message using your locally stored, password-protected private key.
For sending, it would encrypt the message once for each recipient and once for you. It would mark the messages with a common X-header so the Yahoo server would know that when it stored all of these outgoing messages in the user's "sent" folder, it would be able to show only the one encrypted with the user's public key in the default view, with links to the other, unreadable copies in case the sender needed those copies later.

--
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Re:Great by currently_awake · 2014-08-08 06:00 · Score: 1

If they hand out everyone's public key then they can give you the wrong key and man-in-the-middle your email to people of interest. If the decryption is done using code you download from them, then it's a software update away from handing over your key. It gets people thinking about crypto (a major step), but this just a stepping stone to real privacy, not the endpoint.
Re:Great by Hadlock · 2014-08-08 07:06 · Score: 1

Depends on how much you trust your email client

--
moox. for a new generation.
Re:Great by thegarbz · 2014-08-08 12:29 · Score: 2

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 that can be fixed by companies.

Metadata by Anonymous Coward · 2014-08-08 00:48 · Score: 1

If the government agencies are only collecting metadata like they say they are it should not be a problem that the contents of messages themselves are encrypted.
Or maybe they are not just collecting metadata?? Who would have guessed.

Re:Metadata by Scutter · 2014-08-08 00:57 · Score: 4, 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.

--

"Tell me doctor, with all of your defenses, are there any provisions for an attack by killer bees?"
Re:Metadata by Anonymous Coward · 2014-08-08 01:06 · Score: 1

I am not buying into their talking points. An email address is just that an address. Without an address the mail does not know where it should end up. It is metadata just like an address on the outside of an envelope is metadata. It needs to be publicly readable or else it will not reach its destination.
I expect the address to be read publicly.
Re:Metadata by Anonymous Coward · 2014-08-08 01:10 · Score: 0

Your e-mail metadata headers every bit as private as the address and the return address you write on a letter you send via the USPS.
Re:Metadata by just_another_sean · 2014-08-08 01:15 · Score: 2

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.

--
Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
Re:Metadata by Anonymous Coward · 2014-08-08 01:18 · Score: 0

Your e-mail metadata headers every bit as private as the address and the return address you write on a letter you send via the USPS.
Absolute bullshit. I never once gave the government permission to collect my *data* (everything is data, even "metadata"). The government shouldn't even be collecting metadata from letters. Just because I send things over some company's servers doesn't mean I give the government permission to conduct surveillance on my communications.
Furthermore, that makes absolutely *zero* sense anyway. How is the actual content any more private? They could just as easily scoop that up while they're collecting the "metadata." Like it or not, emails are rather different from normal letters.
Re:Metadata by Anonymous Coward · 2014-08-08 01:21 · Score: 1

Most snail mail is read and sorted by machines before it gets to the postman.
There is ample opportunity to collect metadata electronically with snail mail.
Re:Metadata by Anonymous Coward · 2014-08-08 01:23 · Score: 0

If you think that USPS "metadata" hasn't been monitored for decades, think again.
Re:Metadata by Anonymous Coward · 2014-08-08 01:31 · Score: 1

It's not the postman reading it though is it?
Nope it's the sorting and routing machines at the USPS that are reading and storing it. And if you think the NSA, et. all are not using the "metadata" from the USPS you're a moron.
Re:Metadata by Anonymous Coward · 2014-08-08 01:31 · Score: 0

Yes, there does need to be an address to send the mail, and it does need to be 'public' as in the deliverers need to be able to read it.
What doesn't have to be public is everything else: body text, subject line, sent time, return address, etc.
A secure email implementation should be able to hide all those other things so that the only thing track-able is who is getting how much mail, which I can't come up with any way to hide.
Re:Metadata by Anonymous Coward · 2014-08-08 01:32 · Score: 1

I was asked to write a script to collect email metadata passing through an ISP I worked at for sending to government servers. The metadata is collected in a XML format as directed by the governments specification I recieved in PDF. It was just metadata, not message content. I sent them everything including spam. There is much noise in the signal they receive.
Re:Metadata by Anonymous Coward · 2014-08-08 01:37 · Score: -1, Flamebait

Absolute bullshit.
In what way? Email headers are public information just like the addresses you write on a letter.

I never once gave the government permission to collect my *data* (everything is data, even "metadata").
Then stop broadcasting things publicly if you don't want others to see and collect it. Oh and if you use a third party to handle your email you likely did agree to such a thing somewhere in the ToS.

The government shouldn't even be collecting metadata from letters.
Because you say so?

Just because I send things over some company's servers doesn't mean I give the government permission to conduct surveillance on my communications.
Your email goes over much more than "some company's servers" and they are perfectly allowed to give public information to the government.

Like it or not, emails are rather different from normal letters.
What a great assertion. Now care to back this up with actual reasoning? Preferable something with a basis in established statutory/case law?
Re:Metadata by fuzzyfuzzyfungus · 2014-08-08 02:06 · Score: 1

As with any good bullshit "metadata" is not quite technically a lie; but is almost entirely misleading in use.

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 be untroubled by wide-scale encryption of email bodies. In the (likely) event that they are lying, the encrypted bodies will displease them and they'll either have to step up covert activity elsewhere(maybe hit Yahoo's key-handling mechanisms, maybe keyloggers or browser attacks that grab the email before it is encrypted, mabybe all of the above) or come up with some flavor of 'compliance' request that gets Yahoo to give them what they want.

This is unlike the current system, where it is easy to suspect that they are gathering even more than they claim; but trickier to prove without the sort of experiments that will prevent you from boarding an aircraft without a bag over your head and a CIA torture squad for company ever again.
Re:Metadata by Anonymous Coward · 2014-08-08 02:10 · Score: 0

Any government agency that just wants our metadata has nothing to fear.
Re: Metadata by macs4all · 2014-08-08 02:31 · Score: 1

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.
What scares me is that, in the US at least, every single piece of first-class mail is now individually SERIAL-Numbered, obviously so it can be tracked and databased.

The proof lies in the new (and actually quite clever) barcode (too lazy to look up the name) that replaced POSTNET (that barcode at the bottom of envelopes) about a year ago. The new barcode is actually coded to sync, mailpiece-by-mailpiece with an Excel spreadsheet that "bulk" mailers now HAVE to submit BEFORE they mail, and each and every mailpiece is individually serial-numbered, and receives a UNKQUE barcode, just like Registered or Certified mail.

I discovered this when I was writing a function to place POSTNET barcode on a shipping label, and found that the code had JUST been deprecated.

Then, I found out how far down into the "insignificant mailings" that went when I received two identical late-pay notices from a local utility. Both were mailed from the same "mailer"address, undoubtedly under the same "bulk-rate-presort contract no.", to the same name and address, and on the same date. In other words, data which would have generated identical POSTNET bar codes; but in this case, the barcodes on these plain-old ordinary first-class mailings was DIFFERENT. Since I already knew that the new code allowed for "serializing", and knew about the Excel "manifest" requirement, I came to the inescapable conclusion that the Gummint was actually tracking and likely databasing even such uninteresting and prosaic mailings as utility bills. This is ridiculous.

However, I personally believe that what that REALLY means is that the mailpieces that DON'T correlate to a record in a Manifest are actually tracked MORE closely.

So, this means that your most PERSONAL of snailmail (if indeed anyone sends actual snailmail "letters" these days) is likely being tracked with increased scuitiny than other snailmail.
Re: Metadata by macs4all · 2014-08-08 02:42 · Score: 1

Anonymous Coward an hour ago I was asked to write a script to collect email metadata passing through an ISP I worked at for sending to government servers. The metadata is collected in a XML format as directed by the governments specification I recieved in PDF. It was just metadata, not message content. I sent them everything including spam. There is much noise in the signal they receive.
Good for you for reducing the signal-to-noise ratio! Hopefully, your equivalents at other ISPs are as careful as you were in following the "all email" requirements to the letter... ;-)
Re: Metadata by just_another_sean · 2014-08-08 03:18 · Score: 1

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.

--
Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
Re:Metadata by oodaloop · 2014-08-08 04:31 · Score: 1

Metadata is actually the proper term, and used appropriately. IAA Intelligence Analyst. The metadata debate revolved around phone collection, not email. Take your conspiracy theories elsewhere.

--
Tic-Tac-Toe, Global Thermonuclear War, and relationships all have the same winning move.
Re: Metadata by Anonymous Coward · 2014-08-08 06:08 · Score: 0

They take a photograph of every item of mail now.
http://www.nytimes.com/2013/08/03/us/postal-service-confirms-photographing-all-us-mail.html?_r=0
Re:Metadata by cbiltcliffe · 2014-08-09 13:59 · Score: 1

Most snail mail is read and sorted by machines before it gets to the postman.
There is ample opportunity to collect metadata electronically with snail mail.
A snail mail letter can be dropped into a bulk, anonymous mailbox outside a variety store miles from your home/workplace, with no return address, and still get to where it needs to go. That makes the connections between sender and receiver impossible to track.
This isn't possible for email, as it needs an email account to be sent from.

--
"City hall" in German is "Rathaus" Kinda explains a few things......

And Google Cannot Follow by MyLongNickName · 2014-08-08 00:56 · Score: 1

Can you imagine Google doing this? It would ruin their business model entirely as they could not use keyword based ads.

--
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year

Re:And Google Cannot Follow by 2fuf · 2014-08-08 01:46 · Score: 2

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 injected something vile in an open source library that covers 90% of the internet connected world or someone we haven't even heard of who hardwired all keyboards straight from in the manufacturing plant to phone home your input. Hell, they could even be peeking through the window.
If they want to read it, they will. If you desperately want to avoid it, don't use Yahoo of GMail in the first place, not even with "encryption". I'm cynical enough to think this will not prevent them from reading your content, Yahoo will have a similar gain by accessing your content (why would they start the service in the first place) and they don't seem to mind.
Re:And Google Cannot Follow by Jahta · 2014-08-08 02:01 · Score: 1

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.
Re:And Google Cannot Follow by mlts · 2014-08-08 02:16 · Score: 2

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 the attacks out there and force an adversary to have to have a physical presence.
Even if one doesn't do that, just having using S/MIME is a big step up from what we have now.
Re:And Google Cannot Follow by Anonymous Coward · 2014-08-08 05:28 · Score: 0

WTF are you talking about? Google is pushing https on the web so other companies cannot follow what you are doing. They have Google analytics on more than 50% of the top million sites and with G+ and CDN traffic, reporting from browsers etc. They will have no problem tracking everything you do. It is a simple push for cash, don't let that stop you from joining the gushing idiots that are praising Google for this cash grab though.
Re:And Google Cannot Follow by Anonymous Coward · 2014-08-08 05:31 · Score: 0

Yes, Google puts out an "encryption plugin". There is no way they would backdoor it so they can still scan everything, nope not possible. Google's motto is "Do no Evil" after all.

Oh, god by roman_mir · 2014-08-08 00:56 · Score: 1

Whenever I hear that Yahoo is working on yet another great idea for their email, I cannot help but cringe at yet another incoming disaster to hit that half dead, half alive, halfassed half service. It is one of those situations where every next release is worsd than the one before. Things become less usable every time they touch something. It is a pitty too, could be an actual Google competitor, but no, not with that rotten carcas of a management and development team. Why not just acquire a porn service and milm that on a side? I mean cannot go wrong with another social media type 1000000000 dollar purchase. Oh maybe it will be better this time? Haaaa!

--
You can't handle the truth.

Re:Oh, god by sideslash · 2014-08-08 01:01 · Score: 4, Informative

Yahoo mail improved dramatically after Marissa Mayer became CEO. It seems to me that they are actually trying to be more like Gmail, and it shows in a positive way. They still fall short, but as a longtime Yahoo mail user I'll take what I can get. At least their recent improvements are much better than your characterization, for sure.
Re:Oh, god by roman_mir · 2014-08-08 01:08 · 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.

--
You can't handle the truth.
Re:Oh, god by sideslash · 2014-08-08 01:18 · Score: 1

Ah, I see. Poor linux support is a shame, but it doesn't surprise me.
Re:Oh, god by Magnus+Pym · 2014-08-08 01:40 · Score: 1

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:Oh, god by sideslash · 2014-08-08 02:05 · Score: 1

My comments were re: general usability. I don't know that I've lost email, and my message history goes back to 2000. Hmmm, this is disturbing, will have to research this some more. Do you have any specifics about how it happened, or did stuff just disappear?
Re:Oh, god by mlts · 2014-08-08 02:25 · Score: 1

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, beggars can't be choosers.
Re:Oh, god by Voyager529 · 2014-08-08 03:47 · Score: 1

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:Oh, god by Anonymous Coward · 2014-08-08 05:13 · Score: 0

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).
The servers holding your mailboxes probably got removed so Marissa could build a new fully staffed daycare area just for her own baby right beside her office. This is what happens when you put women in these types of positions, they come in and decide that their womanhood and female privilege is far more important than the business. Have you ever been in a conference room while a female executive is operating a BREAST PUMP underneath a shawl? Trying to have a serious meeting while there's a god damn milking machine at work. If they aren't pregnant or have a newborn they're cramping. Two sick days in a row, how convenient you just took a vacation day and sick day in a row 28 days ago and you'll take two more in another 28 days. This is the shit you get promoting women to high ranks. You try to do them a favor and suddenly your whole business suffers and you have to bend over backwards to accommodate every female thing, if you don't move mountains they accuse you of discrimination. Simplify your life and your business - keep women OUT of executive positions.
Re:Oh, god by wannabgeek · 2014-08-08 07:04 · Score: 1

For me, their spam filtering has gone to shit. What used to be an occasional miss earlier is a regular feature now. It's almost like I have to go through two folders (Inbox and Spam) and keep shuffling things around. I'm not saying error rate is 50%, but I am not able to trust Yahoo! not to send some important mail to spam folder!

--
I'm much more funny, interesting and insightful than the moderators think
Re:Oh, god by sideslash · 2014-08-08 07:13 · Score: 1

Interesting. At least I don't have false negatives on my Yahoo account, as I get hundreds per day. I don't take the time to look for false positives, and I agree that would stink.
Re:Oh, god by RockDoctor · 2014-08-13 09:21 · Score: 1

I don't know that I've lost email, and my message history goes back to 2000.
I joined Yahoo for mail in about 1996, and don't recall having lost mail ever. Deleted accidentally and been unable to retrieve, yes ; lost mail on the server, no.
I have lost access due to directed spam attacks (from Creationist Muslims and hipCrime) overloading the account traffic, yes ; but mail going missing, no.

--
Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"

Where is the private key stored? by Henriok · 2014-08-08 00:59 · Score: 5, Insightful

Where is the private key stored? These are web mail services and if that's going to be easy to use, the key must travel with the user, and how is that going to work securely? Or are they going to store people's private keys on their own servers? If so, wouldn't that almost completely defy the purpose? If intelligence agencies or more usual evil does have access to the mail servers, or user accounts wouldn't they also have pretty much access to the key store servers too? Could someone with more knowledge into how this might work please sort this out for me.

--

- Henrik

- when the Shadows descend -

Re:Where is the private key stored? by jbmartin6 · 2014-08-08 01:08 · Score: 1

I had the same thought. I suppose you could store the key encrypted, and then do all the encryption/decryption in the browser. So Yahoo would provide the browser the encrypted key and some Javascript would do the decryption. The article specifically mentions public keys though, which makes me think they must be working on providing a directory of public keys for Yahoo accounts as well. Another option would be using a browser extension. I guess we will find out in time.

--
This posting is provided 'AS IS' without warranty of any kind, implied or otherwise.
Re:Where is the private key stored? by BaronM · 2014-08-08 01:10 · 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:Where is the private key stored? by PPH · 2014-08-08 01:18 · Score: 2

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 order to prepare messages to you.
The problem with many popular web mail encryption services is that the private key generation and storage is in the hands of the mail service instead of distributed to individual users. So that puts it within the reach of a National Security Letter. Or a bunch of Russian hackers if the admin is less than competent.

--
Have gnu, will travel.
Re:Where is the private key stored? by Sockatume · 2014-08-08 01:18 · Score: 1

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.

--
No kidding!!! What do you say at this point?
Re:Where is the private key stored? by Anonymous Coward · 2014-08-08 01:30 · Score: 1

Where is the private key stored?
"window.localStorage for now"
source: https://twitter.com/FredericJacobs/status/497447899962560512
Re:Where is the private key stored? by Anonymous Coward · 2014-08-08 01:36 · Score: 1

Take a look at how LastPass has their system setup. They encryption key never leaves your computer unencrypted. I imagine it would not be too hard to apply the same principles to a webmail scheme.
Re:Where is the private key stored? by AmiMoJo · 2014-08-08 02:12 · Score: 1

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.

--
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Re:Where is the private key stored? by gstoddart · 2014-08-08 02:17 · Score: 1

The private key can be stored encrypted on their server
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 plugins to not also introduce security holes.

--
Lost at C:>. Found at C.
Re:Where is the private key stored? by AmiMoJo · 2014-08-08 02:45 · Score: 1

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 impossible, forcing people like GCHQ and the NSA to focus on particular targets instead of just spying on everyone indiscriminately.

--
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Re:Where is the private key stored? by anagama · 2014-08-08 02:59 · Score: 1

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.

--
What changed under Obama? Nothing Good
Re:Where is the private key stored? by Anonymous Coward · 2014-08-08 03:40 · Score: 0

And where will you store the key that you need to decrypt the key?
Re:Where is the private key stored? by Anonymous Coward · 2014-08-08 03:57 · Score: 0

... In da cloud! *tada.wav*
Re:Where is the private key stored? by cbhacking · 2014-08-08 05:26 · Score: 1

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).

--
There's no place I could be, since I've found Serenity...
Re:Where is the private key stored? by bmo · 2014-08-08 06:02 · Score: 1

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:Where is the private key stored? by AmiMoJo · 2014-08-08 07:48 · Score: 1

Correct. It does not prevent Yahoo from spying on you. What it does it prevent people like the NSA and GCHQ spying on you without a warrant or any kind of process, i.e. bulk surveillance on a massive scale.

--
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Re:Where is the private key stored? by Alarash · 2014-08-09 21:55 · Score: 1

The private key could still be stored on their servers but password protected by you. It's not as good as you having a local copy, and they should allow that, but for ease of management it could work. Cracking a RSA or DSA key's going to take a long time even to the NSA or CGHQ.

Web based pgp encryption = no encryption by Anonymous Coward · 2014-08-08 01:01 · 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!! by hymie! · 2014-08-08 01:05 · Score: 4, 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:Awesome!! by Anonymous Coward · 2014-08-08 01:17 · Score: 0

or just get them a free Yahoo email account, duh.
Re:Awesome!! by Sockatume · 2014-08-08 01:19 · Score: 1

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.

--
No kidding!!! What do you say at this point?
Re:Awesome!! by Pi1grim · 2014-08-08 01:28 · 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:Awesome!! by Anonymous Coward · 2014-08-08 01:30 · Score: 0

Mail servers don't "talk PGP."
Also, if it could be unencrypted transparently by a third party ... it wouldn't actually be a useful form of encryption.
The private keys must reside on the client for this to be useful, which means that this will either be insecure, useless, or both.
Re:Awesome!! by Aaden42 · 2014-08-08 01:55 · Score: 1

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, and there are ample opportunities for MitM attacks to cause crypto to be dropped where it might otherwise be supported (so we’re back to trusting TLS keys). That coupled with public PGP key registries offers some options for intelligent fallback behavior while still providing encryption for messages where both sides are capable of dealing with it.
Re:Awesome!! by Anonymous Coward · 2014-08-08 02:01 · Score: 0

I don't think the one who doesn't "talk PGP" is a mailserver here... ;-)
Re:Awesome!! by AmiMoJo · 2014-08-08 02:13 · Score: 1

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.

--
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Re:Awesome!! by Anonymous Coward · 2014-08-08 02:20 · Score: 1

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.
And what does those two things have to do with each other?
My first experience with DKIM was when I worked at a spam company. DKIM was very important to get right, because with correct DKIM, big e-mail providers like Yahoo and Hotmail would pass our spam directly to the users inbox, where as without it, they would start filtering after a few thousand spam mails.
For a while, DKIM worked great for filtering spam on my personal system - if it has a DKIM signature, it's spam - but then they managed to convince people running real mail servers (as opposed to spammers) to add DKIM signatures also.
Re:Awesome!! by Anonymous Coward · 2014-08-08 02:46 · Score: 0

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.
You're still missing the point. SMTP servers use an entirely different form of crypto between each other, with other mail servers (POP, IMAP, etc.), and with their clients. It's a variant of the same SSL that distinguishes https from http. That's not what this is. PGP allows you to encrypt a message on the client side and hide the content from the transmitting servers. Only the recipient's client software knows if they can decrypt it or not.
The reason why so many people are telling you that you are wrong is that you are doing the equivalent of saying, "My router doesn't support JPEGs." Of course not, it's a frickin' router. It barely cares that you are transmitting on port 80 versus port 443. It doesn't care what the content is. You wouldn't convert a JPEG to a PNG at the router level. Similarly, mail servers don't know what's in the body of a message. It could be PGP encrypted text, plain text, an embedded image, or whatever. To a mail server, the message body is just a blob.
Could they come up with an encryption method that works as you describe? Sure. It wouldn't have anything to do with PGP though. In fact, they already have. SMTP servers are perfectly capable of encrypting all their connections. So client talks to SMTP server talks to other SMTP server talks to IMAP server where it's encrypted at each step.
Re:Awesome!! by Sloppy · 2014-08-08 03:07 · Score: 1

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.
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?

--
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Re:Awesome!! by Aaden42 · 2014-08-08 03:19 · Score: 1

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’s server advertises that their stack deals with PGP correctly, Yahoo can use that as a cue to encrypt the message content and pass it over the already-encrypted TLS connection. The SMTP conversation would always be TLS encrypted, but a part of that conversation can signal to the sender that encryption at the message data level would also be handled properly by the rest of the software stack behind the receiving SMTP connection. That’s blurring the layers, but it’s not unreasonable for a primarily webmail host to signal their user agent’s capabilities as part of the lower SMTP conversation.
Granted, that’s piling on a lot more processing than would typically be done during the SMTP conversation, but it’s doable. You don’t even need the anyone’s private key at that point. The sender’s private was used to clear-sign every message sent (presumably in Javascript on the client side). If the sending SMTP server determines the remote can deal with it, then it needs to obtain the recipient’s public key and encrypt the clear-signed message to it before sending the PGP encrypted message over the TLS encrypted connection. The benefit there is that Google’s stack never gets to read the plaintext of the message.
Re:Awesome!! by Anonymous Coward · 2014-08-08 03:32 · Score: 0

Write a 1000 times on the blackboard: "Network stacks don't have anything to do with PGP". And because of that, no SMTP client or server will ever know about it either.
Re:Awesome!! by Anonymous Coward · 2014-08-08 03:36 · Score: 0

"You need to use both to get proper end-to-end encryption of message contents"
Also wrong. You get end to end encryption with just PGP.
Re:Awesome!! by rivercityrandom · 2014-08-08 04:18 · Score: 1

Now all I have to do is get my mother, father, wife, and all of my friends to actually email me instead of sending me messages on Facebook. Except for work, nobody I know uses email anymore to send personal letters.
Re:Awesome!! by Aaden42 · 2014-08-08 07:38 · Score: 1

You get end to end encryption with just PGP.
Nope. SMTP envelope sender & recipient plus all the headers are still in the clear if you skip TLS. Metadata...

Network stacks don’t have anything to do with PGP
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 tell the sender for instance that it supports 8BITMIME. A sending server which sees that capability may react by not base 64 encoding the message if it contains UTF-8 characters. The sending server makes a decision immediately before transmitting content (after connecting to the remote and saying "EHLO") on what encoding it should apply.
Adding some indication of PGP to the SMTP capabilities might trigger similar behavior. The sending server could encrypt using the recipient’s public key transparently without requiring any user intervention or access to any private key material. That change could be implemented with an RFC similar to RFC-6152 which covered 8BITMIME. An admittedly more in depth change might enhance SMTP to allow the server to provide a recipient’s key ID if available in response to the "RCPT TO” command.
Re:Awesome!! by Alarash · 2014-08-09 21:58 · Score: 1

Feel free to keep them unsecured. They probably don't care that the government read their email so they probably deserve it, and they'll never put up with the hassle that extra security brings. Unless the keys will be decrypted by using fingerprints or something, but then these users will complain that they need to buy a fingerprint reader.

And Google Cannot Follow by Anonymous Coward · 2014-08-08 01:06 · Score: 2, Informative

google is doing this (http://googleonlinesecurity.blogspot.com/2014/06/making-end-to-end-encryption-easier-to.html)

Unlikely, if they control the key by Anonymous Coward · 2014-08-08 01:18 · Score: 1

Can't RTFA from here, but there's no chance of a "standoff" if Yahoo gets to keep the private key. Hell, even if they don't, if the encryption is taking place on their side, as it necessarily would with a web client, then you're transmitting your private key for that purpose, and they effectively control it at that point. Any implementation other than a fat client on the user's equipment completely defeats any level of non-repudiation that PGP affords.

Re:Unlikely, if they control the key by Aaden42 · 2014-08-08 01:44 · Score: 1

It doesn’t necessarily need to do en-/decryption on the server side. Javascript is more than adequate to perform the necessary math.
Re:Unlikely, if they control the key by Anonymous Coward · 2014-08-08 02:27 · Score: 0

Not without also being more than adequate for grabbing a copy of your private key.
Re:Unlikely, if they control the key by Aaden42 · 2014-08-08 03:28 · Score: 1

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 problems of infected machines, using the coffee shop’s computer with half a dozen key loggers conveniently preinstalled for you, etc. You also have to trust that Yahoo won’t ship your key off the second you furnish the passphrase, but if that’s what they have in mind, they won’t even bother with doing any of it client side anyways.
There’s always room for insecure implementation (whether accidental or intentional), but there’s no reason this system can’t be *designed* in a secure manner. And if the crypto is done in script on the client, it’s possible for that script be be audited to some degree by interested parties.
Re:Unlikely, if they control the key by Anonymous Coward · 2014-08-11 00:12 · Score: 0

can you trust a website ONLINE where they can edit the javascript they send you at any give time?
Binary distributors cant do that against selected targets and wont do that against all their users.

idiotic by slashmydots · 2014-08-08 01:23 · Score: 1

Their accounts get hacked at an insanely fast rate. I would bet every single user gets their account hijacked in 2 years or less. Maybe they should work on that first if they're so concerned with security.

W... X... Yahoo... Zombie. by Sarten-X · 2014-08-08 01:26 · Score: 1

At this point, each news story about Yahoo primarily serves to let me know the company isn't quite dead yet.

--
You do not have a moral or legal right to do absolutely anything you want.

PGP Is the easy part. Key mgmt is hard by cpuh0g · 2014-08-08 01:29 · Score: 2, 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.

Right ... by gstoddart · 2014-08-08 01:41 · Score: 1

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

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, but it's done nothing at all to protect you from spying governments who simply force Yahoo to hand over your private key.

And, really, if adding encryption to your email doesn't actually prevent the NSA et al from getting to your email, this is lip service to encryption.

Sounds cool and all, but isn't really giving you any additional security.

--
Lost at C:>. Found at C.

Re:Right ... by radarskiy · 2014-08-08 03:46 · Score: 1

"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:Right ... by J'raxis · 2014-08-08 04:12 · Score: 1

That's what these large corporations all do.
Look at Google, grandstanding about moving things to HTTPS a few months ago, making things harder for the NSA, 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. Microsoft 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.

--
Liberty in your lifetime

Even if done badly, might do some good? by Aaden42 · 2014-08-08 01:43 · Score: 4, 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.

Re:Even if done badly, might do some good? by davidwr · 2014-08-08 05:02 · Score: 1

Ultimately if the NSA wants to read YOUR stuff, theyâ(TM)re going to (see: $5 wrench)
Unless of course someone wants to keep you quiet more than the NSA wants you to talk (see: cement boots).

--
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.

Mailvelope etc. by Anonymous Coward · 2014-08-08 01:47 · 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 actual mail account. That way, a user who does not use PGP can send failry secure mails to a GPG-user. A simple vanity-style URL can be given to such users for easy access to the input form. The scripts are freely available and can be used on your own webserver under your control. This idea may significantly help in overcoming the chicken/egg problem we are having in regards to PGP use!

As far as webmail with PGP goes, Startmail is already doing that. You create the keys in their interface (yes, I know!) and the use is very straight-forward. You can also communicate with outisde user who do not have PGP. They will get an SSL-link and access it via a previously agreed-upon passphrase. Their reply to the Startmail user from there will also get PGP-encrypted on Startmail's server and put into the Startmail user's mailbox.
While this setup is, for purists, far from ideal, it could help get normal people to use PGP. If you don't like it, stop bitching, and help make PGP easier to use the 'proper way'! ;-)

Why not S/MIME? by Arkham · 2014-08-08 01:49 · Score: 3, Informative

Instead of PGP they should use S/MIME. It's functionally the same but is far more widely supported. It's even included in the Exchange ActiveSync protocol via ResolveRecipients to retrieve the public keys of other users. I don't dislike PGP/GPG, but if it were me I'd go with a more standard envelope.

--
- Vincit qui patitur.

Re:Why not S/MIME? by mlts · 2014-08-08 03:41 · Score: 3, 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.
Re:Why not S/MIME? by thegarbz · 2014-08-08 12:32 · Score: 1

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.
That's a perfect lead in to the following question:
What is better for global security, a certificate based system managed by a potentially corruptible central authority, or a trust based system imposing complications on already quite inept computer users?
Note I said global security, i.e. getting away from everyone sending everything in plain text. Between experts a trust based system isn't a problem but really there are enough people who can't figure out how to turn on their phone, how do you teach them sensitive key management when at this point we haven't even managed to stop them giving their passwords to random websites.
Re:Why not S/MIME? by mlts · 2014-08-08 12:43 · Score: 1

That is the rub. PGP is better security hands-down, but it requires people to have a grasp of concepts like key infrastructure, webs of trust, keeping their private key somewhere secure, making revocation certificates and stashing them somewhere separate just in case (so the private key can be pulled out of circulation), and so on.
S/MIME, vulnerable to a CA as it may be, just requires clicking a button to use. A recipient just has to view the message for the signature verification and decryption to happen. Pure point and drool.
Of course, PGP is better for security as a whole, but trying to move a notch up and encrypt E-mail is far better than nothing, similar to how SSL is flawed, but it is a lot better than just sending HTTP in the clear.
That question can only really be answered by having both mechanisms in place for now.

Who fucking cares? by Anonymous Coward · 2014-08-08 02:13 · Score: 0

Why does Yahoo still exist? They don't even offer SSL for their email. I have idiot co-workers who use Yahoo, and yes, I can read their emails with Xplico.

Open Source? by Fnord666 · 2014-08-08 02:18 · Score: 1

It sounds like they plan on making the extension open source, which is mandatory or the whole thing is a non starter. Furthermore you better be able to match the checksum of the source version to the addons that might be available from the addon repositories for the browsers. We have to be able to confirm that what they say is the code is in fact what we are running in the browser.

Personally I'm not interested in anything that involves uploading my private keystore to a third party, encrypted or not, and without that you lose the main feature, portability, that comes with webmail.

--
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables

Re:PGP Is the easy part. Key mgmt is hard by CimmerianX · 2014-08-08 02:29 · Score: 1

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.

Democrats hate poor people - and black people by Anonymous Coward · 2014-08-08 02:39 · Score: -1

Democrats are trying to make people poor so they can control and starve them.

They want to sterilize black people through abortions and surgeries so that the Hispanics can replace the blacks

We need a Thunderbird interface to it too by Anonymous Coward · 2014-08-08 02:41 · Score: 0

We need a Thunderbird interface too, a webmail inteface isn't enough this encryption should be ubiquitous and on authomatically exchange keys and turn on by default.

Re:We need a Thunderbird interface to it too by SpzToid · 2014-08-08 03:43 · Score: 2

Like this? https://addons.mozilla.org/en-...

--
You can't be ahead of the curve, if you're stuck in a loop.

Marissa by zoomshorts · 2014-08-08 02:50 · Score: -1

Dear Marissa Mayer,
You apparently do not understand the Internet very well. Simply because you got employed by Google early on, does not mean ANYTHING. You have no clue. It is apparent that you never visit Yahoo
from a non-company computer.

Your programmers are idiots, and by extension, you are an idiot. Quality control never seems to enter your mind.

You people post articles from other new sources, and we do not get to comment without registering with the secondary site. That is bullshit.
If you publish something on your site, we should be able to fully add our comments to the article.

Articles that lead to videos are aggravating. Anyone who has been on the internet for 15 minutes, knows this. I prefer to read, rather than watch crappy videos, with loud intro music and retarded 'personalities".

The choices portion of the programming is a JOKE. I never want to see ANYTHING related to the following :
Sports
Celebrities
Recreation et al. Yet when I choose to not watch these catagories, your programmers still display these types of crappy articles to me. Ergo,
your programmers suck.

I realize that you are trying to "Monitize" this stuff, but you are pissing off many of us long time users of Yahoo. You are a PORTAL and nothing more.
You are NOT a news source. Hell, even Google does a better job of sending me things that are relevant to me. Yahoo is failing and by extension, you are failing.

Re:PGP Is the easy part. Key mgmt is hard by mlts · 2014-08-08 03:33 · Score: 1

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 first server, or a period of time after the last signature on the key. That way, a key sitting around for a number of years and not getting other people signing it (or signatures renewed) eventually drops.

X.509 certs by Anonymous Coward · 2014-08-08 03:51 · Score: 0

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.

Couple of options:
* use self-signed certs and approve them individually (close to host PGP works)
* use CA-issued certs but have the client as prompt when it sees a second cert of an address it already has one for (kind of like pinning)

Untrustworthy != Useless by Sloppy · 2014-08-08 03:57 · Score: 1

If Yahoo ends up holding the private keys, then it's completely untrustworthy and useless.

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 CALEA and NSLs, and furthermore just to make things worse, let's just say that they even publically admit that they would happily provide keys to any government who asks, without even a warrant or sternly-worded letter. But when you ask 'em if they really mean every government, "even Russia?" they reply with "no comment" so you're not sure they're really publically admitting everyone to whom they'll give the key.

There. Did I cover all the bases? Did I leave anyone's pet fear out?

Sorry, let's add a few more things. Let's say Yahoo's CEO is a Scientologist, all their network admins are required to be either Holocoaust Deniers or Creationists, and every employee is required to have at least 25% of their investments in MPAA companies. The receptionists all have iPhones, the corporate mission is the next president of the USA must have either Clinton or Bush as their last name, and henceforth all their web ads will be for either Amway or Herbalife. All the interns are spies for Google and Microsoft and Chinese industries, except for a few which are spies for Mossad, FSB, or Al-Qaeda. The head janitor is being blackmailed by two unknown parties for his participation in a kiddie porn network, and the top sysadmin hasn't heard about Heartbleed yet, the top programmer (who bears the title "Grand Wizard" on his business card) doesn't believe in comments, their implementation of OpenPGP uses a 1938 Luftwaffe cipher as its entropy source for generating session keys, and the company weather station's thermometer was installed on a south-facing patio that gets direct sun all day long.

You may possibly harbor doubts about trusting this company. Yet in that situation, switching to Yahoo email would be more secure than what most people have right now, with plaintext email. So how's that "useless?"

--
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.

no private key to SEND GPG. End bulk collection by raymorris · 2014-08-08 04:03 · Score: 3, 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.

Why I'll never use Yahoo email anymore by Anonymous Coward · 2014-08-08 04:26 · Score: 0

My previous ISP uses Yahoo for its email servers, which you can access from your email client using the ISP email address or Yahoos web based email. The problem, you change your password for your ISP email address, then access it from Yahoos web email, and both your old and new passwords work. There was no way to disable the old password, at least a few years ago when I last tried to. Haven't bothered to use it anymore since.

The private key would have to be handled locally by davidwr · 2014-08-08 04:52 · 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 standardized API.

--
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.

What is the goal from Yahoo's perspective? by davidwr · 2014-08-08 05:21 · Score: 1

1. Is the goal to provide real end-to-end protection where even Yahoo can't help the government snoop even if compelled to by law? That is hard.

2. Is the goal to prevent the government from snooping without involving Yahoo - that is, to make sure mail transiting between Yahoo servers and between Yahoo and other email server and Yahoo and those sending or receiving messages is encrypted? This may help a little but using https: and secure smtp between mail servers gets you most of the way there.

3. Is the goal to prevent the government from snooping without involving either the sender's computer, the recipient's computer, Yahoo, or if the recipient trusts his mail provider with the private keys, the recipient's mail provider? If so, then PGP with Yahoo having either the private keys or a means to compromise the recipient's computer will meet Yahoo's needs.

I suspect Yahoo wants at least #2 but probably #3.

As long as Yahoo is up-front with what they are delivering and doesn't gloss over important details, #2 or #3 could be useful and better than what's out there now.

Example press release:

THE_FUTURE - YAHOO_HQ - Yahoo is proud to announce PGP-encrypted email.

Yahoo is proud to announce PGP-encrypted email. Yahoo has partnered with FOO, BAR, and BAZ to provide a public-key registration service. Users can upload their public keys to FOOBARBAZPGPKEYREGISTRY.com. Yahoo users who wish to send encrypted mail to anyone with a registered public key can do so easily.

For those needing the same level of security as PGP, Yahoo has published specifications for plug-ins to existing PGP software. For those whose don't need quite the same level of security, Yahoo offers plugins for all popular web browsers to make sending and receiving PGP-signed easy.*

Why are we doing this? INSERTMARKETINGSPEAKHERE.

* Using the Yahoo plugin decreases security: Due to the nature of plugins, it is technically possible for Yahoo to deliver a plugin which compromises the user's security. Yahoo will make every effort to not do this unintentionally and will intentionally do this only pursuant to a legal process. For this reason, customers who wish to prevent being affected by such a court-ordered compromise should use software that is not published by Yahoo to send and receive PGP messages through Yahoo. The source code for the standard versions of all PGP-related Yahoo plugs can be found at FOOBARBAZPGPKEYREGISTRY.com/Yahoo/software .

--
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.

Why should anyone trust this or any other by mark_reh · 2014-08-08 05:53 · Score: 1

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?

Re:Why should anyone trust this or any other by Fnord666 · 2014-08-08 15:32 · Score: 1

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?
I do and many others do as well. Hopefully at least some of these others are outside of the reach of the US.

--
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables

USB can't be trusted either by davidwr · 2014-08-08 05:55 · Score: 2

You can't trust USB devices these days either.

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 would, but it would be immune from the "poisoned USB port" attack.

--
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.

Re:USB can't be trusted either by 2fuf · 2014-08-08 15:58 · Score: 1

Very creative indeed :-) There is an funny movie that kind of utilizes part of the process you described as a plot device. It's a bit of a stretch but your comment reminded me of it. I liked it very much but the IMDB score is (imho undeservedly) low: Duplicity with Paul Giamatti and Julia Roberts www.imdb.com/title/tt1135487/ Maybe you'll enjoy it too.

Lame humor interlude by davidwr · 2014-08-08 06:00 · Score: 0

And now for a lame humor interlude...

Safe and secure (except for metadata that is).

The NSA never met a data that it didn't like.

We now resume our regular /. programming

--
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.

Spam by CBravo · 2014-08-08 07:25 · Score: 1

And how do presume the spamfilter will work with all the content being encrypted? This is not well thought out.

--
nosig today

Re:Spam by Areyoukiddingme · 2014-08-08 11:11 · Score: 1

And how do presume the spamfilter will work with all the content being encrypted? This is not well thought out.
Spambots don't even bother to speak SMTP correctly, which is why greylisting is so effective. Do you think they're going to start signing their spam? I doubt it. It becomes more grist for the Bayesian mill: no encryption, spam probability goes up.
Re:Spam by CBravo · 2014-08-08 17:28 · Score: 1

Spamfiltering is a little bit more sophisticated than greylisting. My mailservers speak SMTP perfectly, it does not validate my content automatically around the world.

--
nosig today

Standards ? by DrYak · 2014-08-08 07:31 · Score: 1

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).

And a bit of key handling (well, browsers, already handle public-key infrastructure, it could be only minor modification to be able to also handle web-of-trust), where the webmail provider only has a searchable service for public key, and secure-storage of private key is handled by the browser (as are currently the private PKI keys stored. Or the saved password sotred and synced).

It's already doable with plugins (and some actually do it). But it would be good if it was integrated as an HTML5 extension available on major engines (Firefox/Gecko, Webkit, etc.) so that it could be tapped by interested webmail providers (Yahoo, but maybe GMail or Hotmail, or maybe future successors of Lavabit) or web chats (see CryptoCat for an example of plug-ins doing exactly that)

--
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]

plugins (or standard) by DrYak · 2014-08-08 07:40 · Score: 1

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 any compliant webmail provider.
Then it's the same kind of security provided by e-mail client. Nothing prevents the NSA from forcing Microsoft to put a backdoor into Outlook (or more likely, nothing prevents them from using exploit-du-jour to compromise outlook). But in turn, nothing prevents you and your mail correspondant to both pick-up a known-secure and audited copy of Thunderbird from Tor's bundle and use that for swaping your nude-pics privately.

--
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]

Re:PGP Is the easy part. Key mgmt is hard by chihowa · 2014-08-08 07:43 · Score: 1

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.

--
If you want a vision of the future, imagine a youtube comments section scrolling - forever.

Single recipient too. by DrYak · 2014-08-08 07:43 · Score: 1

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.

--
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]

Private keys are probably kept client-side... by steppin_razor_LA · 2014-08-08 07:45 · Score: 2

"Does your browser have an OpenPGP library?"

It looks like it will soon:

http://googleonlinesecurity.bl...

--
Evolution: love it or leave it

Re:PGP Is the easy part. Key mgmt is hard by chihowa · 2014-08-08 07:47 · Score: 1

PGP Corp's keyserver uses expiration dates and email verification to let abandoned keys slip away. It's not a bad system, really, although it open its own unique possibilities of abuse.

--
If you want a vision of the future, imagine a youtube comments section scrolling - forever.

Metadata is irrelevant to TFA by DrYak · 2014-08-08 08:03 · Score: 1

web-of-trust encryption (like PGP, and like the GnuPG implementation) is about encrypting the *BODY OF THE MESSAGE*.

I.e.: everything that comes after the subject is encrypted in a way that only the 2 end-points (author and recipients) are able to decrypt.
Without encryption, the content of an e-mail is as secure as a post-card.

Everything that comes before the subject, i.e.: all the headers that form this juicy "metadata" that the government wants, needs to be also readable to all the middle-men standing between the 2 end-point and who are in charge of distributing the mail. (e.g.: with paper mail, the postman needs to also see the address, otherwise he can't deliver it) But only to those in charge with the actual delivery (e.g.: only the postman sees what's written on the outside of the envelope. You don't want the gardener to keep a list of whom you're writting to).

That is encrypted by a completely different layer: it's the server-to-server encryption (things like the SSL and STARTTLS addition to IMAP/STMP/POP) which are in charge of keeping the metadata from beeing scoped.
But then you need to trust every server that your mail goes through (i.e.: you need to trust that none of all the various postmen who'll handle you mail is actually an undercover NSA spy posing as a postman) and you need to trust their security implementation (i.e.: that the postman delivering your mail pictures isn't clumsy and won't accidentally break your envelope and spill your nude picture on the ground, just right at the moment when a spy is around) (saddly, my comparison sucks: real world postmen aren't so clumsy, but real world cryptography is complex, and it's dead simple to bork something somewhere and leak secret information).

So yeah, metadata are important to protect too, but that's completely ireelevant. That remains instead for future discussion.

Note: perfectly safe messaging including secure metadata would require completely different infrastructure. Something like messaging over a tor network, instead of using a network of mail relay servers.

--
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]

Metadata protection by DrYak · 2014-08-08 08:08 · Score: 1

Your e-mail metadata headers every bit as private as the address and the return address you write on a letter you send via the USPS.

...which in real life should only be used by the postman handling the delivery of the mail and shouldn't be mined by some 3rd party.

That is more or less doable (either server-2-server encrytion for the simplest form, or messaging over a tor-like network for the best protection) but has nothing to do with PGP.

PGP is about protecting the content (i.e.: it has nothing to do with the address written *on* the parcel handled by the postman. It's more like the content of the parcel being a safe box which can only be opened by someone having the key corresponding to the padlock on the safe box).

--
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]

Hand it to the browser by DrYak · 2014-08-08 08:13 · Score: 1

Except if only the browser it-self is exclusively in charge of the decryption/encryption.

The browser does the job, and all the webpage and associated javascripts ever see in the TEXTAREA is exclusively an encrypted stream.

That should be done in a plug-in, or even better: in a complete standard way - add it as an extension to HTML5.

--
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]

We need Mailvelope as an HTML standard. by DrYak · 2014-08-08 08:18 · Score: 1

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.

The best would be it for such thing to be an actually HTML5 extension.

Gmail, Yahoo, Hotmail, etc. just flag which "TEXTAREA" tag contains the message body (or a greasemonkey script does it for them it they don't support it yet) and then the in-browser functionnality handles the encryption/decryption, completely outside of the reach of the webpage and its javascripts.

--
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]

Re:The private key would have to be handled locall by MichaelSmith · 2014-08-08 10:45 · Score: 1

JavaScript virtual machines have no security between applications. Any script can replace the javascript API at run time, messing with other code running in the same window.

--
http://michaelsmith.id.au

What is best for the economy? by Anonymous Coward · 2014-08-08 10:47 · Score: 0

Let the corporations build their programs just as strong and inpenetrable as possible. Then let the government create all their back doors in time. That way everybody gets a shot. It creates more jobs means better back doors. And, its good for extra overtime for everyone.

Re:PGP Is the easy part. Key mgmt is hard by Hawke666 · 2014-08-08 11:26 · Score: 1

But it really should remove the key from the database. There’s no reason to retain anything more than the revocation signature itself.

Re:PGP Is the easy part. Key mgmt is hard by chihowa · 2014-08-09 05:42 · Score: 1

Without the public key you can't verify the revocation signature, but I see your point. The revocation signature is only of interest to someone who already has a copy of the public key and the presence of an (assumed to be verified by the keyserver) revocation signature is enough to dissuade people from attempting to obtain and use a revoked public key. Retaining both parts allows for others to verify the revocation and limit the damage caused by a malicious keyserver, so there are arguments in favor of a completely open and transparent system (that only adds and never deletes information).

Maybe it currently just comes down to implementation. The revocation signature contains the ID of the key that generated it, but the keyservers are only set up to search for, and return, entire public keys with signatures attached.

--
If you want a vision of the future, imagine a youtube comments section scrolling - forever.

Didn't Yahoo do this once before? by Anonymous Coward · 2014-08-10 03:59 · Score: 0

I remember Yahoo mail offering email encryption (and I think it was PGP) back around 2000 or 2001. Does anyone else remember this? It failed -- but I can't recall why.

Fix DMARC first by Anonymous Coward · 2014-08-11 00:10 · Score: 0

While yahoo keeps breaking mailinglists, noone actually needs pgp support (with the private key in the cloud)

Slashdot Mirror

Yahoo To Add PGP Encryption For Email

175 comments