Slashdot Mirror
Yahoo To Add PGP Encryption For Email
Bismillah (993337) writes Yahoo is working on an easy to use PGP interface for webmail, the company's chief information security officer Alex Stamos said at Black Hat 2014. This could lead to some interesting standoffs with governments and law enforcement wanting to read people's messages. From the article: "'We are working to design a key server architecture that allows for automatic discovery of public keys within Yahoo.com and other participating mail providers and to integrate encryption into the normal mail flow,' Stamos said."
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
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.
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
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.
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 -
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).
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.
google is doing this (http://googleonlinesecurity.blogspot.com/2014/06/making-end-to-end-encryption-easier-to.html)
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.
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.
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.
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.
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.
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?
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.
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.
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.
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'!
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.
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.
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?
> so that even if a user keeps quiet after waterboarding, data is still recoverable
FTFY
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.
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.
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
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
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.
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.
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
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.
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.
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.
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.
...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.
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.
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
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
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.
Clearly, you can only trust encrypting mail clients with no internet connectivity.
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)
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
And how do presume the spamfilter will work with all the content being encrypted? This is not well thought out.
nosig today
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 ]
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 ]
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.
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 ]
"Does your browser have an OpenPGP library?"
It looks like it will soon:
http://googleonlinesecurity.bl...
Evolution: love it or leave it
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.
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 ]
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 ]
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 ]
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 ]
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
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
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.
But it really should remove the key from the database. There’s no reason to retain anything more than the revocation signature itself.
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.
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.
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.
While yahoo keeps breaking mailinglists, noone actually needs pgp support (with the private key in the cloud)