Google To Enable End-To-End Email Encryption, Highlight Good Email Security Practices
from the good-to-see dept
Back in December of 2012, we wrote about (and agreed with) Julian Sanchez’s suggestion that Google should do end-to-end encryption of emails, even if it (only slightly) mucked with its advertising business model. The impact on overall security would be great (and this was before the Snowden revelations had even come out). As Sanchez pointed out, not only would this (finally) drive more widespread adoption for email encryption, it would create enormous goodwill among privacy advocates. About six weeks ago, we mentioned this again, when it was rumored that Google was trying to make encrypted email easier, though it was said that it wouldn’t go “site-wide” on end-to-end encryption.
A new blog post on the Google blog* has now detailed at least some of Google’s plans, including offering a new End-to-End Chrome extension that will make it much easier for anyone to send and receive encrypted email messages. This is a big step forward, and hopefully shows how serious Google is about actually encrypting messages, rather than leaving them open for snooping.
This announcement came along with adding a new section to Google’s famed transparency report, entirely focused on email encryption in transit, which will hopefully increase the use of Transport Layer Security (TLS) from other email providers out there. In the initial report, Google notes that 65% of outbound messages on Gmail to other providers use TLS, while 50% of inbound messages use TLS (over the last 30 days). And, more importantly, it highlights who supports TLS… and who doesn’t (Comcast seems to be a shameful leader on that front). With some transparency, hopefully it will lead more email providers to adopting TLS.
* For the sake of full disclosure, the author of the blog post on Google’s site is an old friend of mine, whom I’ve known for nearly 20 years (I feel old), since long before he worked at Google. I had no idea he was working on this and actually haven’t spoken to him in probably a year or two (because life happens). I didn’t find out about it from him, but from people talking about it on Twitter.
Filed Under: chrome extension, email, encryption, end-to-end encryption, gmail, pgp, privacy, security, tls
Companies: google
Comments on “Google To Enable End-To-End Email Encryption, Highlight Good Email Security Practices”
I’m not sure I trust any large corporation to be the guardian of my privacy. But if I did, then Google would probably be about the only one. RIP TrueCrypt.
How many other companies:
1) Have a ‘don’t be evil’ sign in their lobby
and
2) Have publicly said ‘fuck the NSA’
Re: Re:
Truecrypt is NOT dead. There are multiple efforts underway to pick up the code, complete part 2 of the audit, and so on. Some of those will fail. Some will succeed. But it’s not going to hit the floor, there are too many people dependent on it.
As to Gmail, it’s the least-worst of the freemail providers, but it’s still very low quality and I emphatically recommend against it for anyone who’s serious about email privacy, security and reliability. Get a real mail account with a real provider and use a real mail client (that is: NOT a web browser).
Re: Re: Re:
Wait… what’s happening with TrueCrypt? I’ve been using it for years to encrypt all of my hard drives. Has something bad happened?
As for e-mail, my ISP recently implemented OpenPGP via their webmail service. A step in the right direction, but I can never get TLS nor AES to work using regular e-mail apps installed on my PC.
I did finally stop procrastinating about getting a VPN and adopting OpenPGP (Gpg4win) though, especially when I saw which way the wind was blowing here in Canada with Bill C-13.
Re: Re: Re: Re:
“Wait… what’s happening with TrueCrypt? I’ve been using it for years to encrypt all of my hard drives. Has something bad happened?”
Yes. For details, please see these:
http://www.theguardian.com/technology/2014/may/30/encryption-software-truecrypt-closes-doors
https://www.schneier.com/blog/archives/2014/05/truecrypt_wtf.html
http://meta.ath0.com/2014/05/30/truecrypt-warrant-canary-confirmed/
https://gist.github.com/ValdikSS/c13a82ca4a2d8b7e87ff
and what looks to be the most promising project:
http://geekcrypt.net/
Re: Re: Re:2 Re:
Thank you very much for providing those links rather than saying what a lot of folks say, which is to use Google… which I realized afterwards I should have done admittedly. Very fascinating reading and it will be interesting to see what the truth is, provided we’re lucky enough. 🙂
I applaud Google’s efforts on this front. It’s a good move to make to restore a small amount of trust. Still, as long as the NSA can present NSLs and then demand Google reveal the contents or make assess available, there is no way in hell I’d trust them.
Then too there is the spying done by themselves to aid in advertisement. Not for one second do I believe Google doesn’t have the back door key to look at anyone’s email that uses their services. If it’s there for Google it’s there for the NSA with a court order.
As long as the NSA is rampant on it’s mission of collect it all with no oversight and no one interested in pulling them back in the Administration, I have no belief in this effort as meaningful.
Re: Re:
Still, as long as the NSA can present NSLs and then demand Google reveal the contents or make assess available, there is no way in hell I’d trust them.
Fair enough — though if the encryption is truly end to end, with people doing a full vulnerability review, it should be that Google cannot reveal the contents, because Google never actually sees the content.
Then too there is the spying done by themselves to aid in advertisement. Not for one second do I believe Google doesn’t have the back door key to look at anyone’s email that uses their services. If it’s there for Google it’s there for the NSA with a court order.
Right. But the point w/ end to end encryption is it’s NOT there for Google. They never see it.
Re: Re: Re:
You would be right if it were not only a chrome extension. Chrome is still owned by google so there is no reason to trust that model either. Google can still see the content of your message.
Re: Re: Re: Re:
Not necessarily. If it’s true end-to-end encryption implemented correctly, it doesn’t matter if it’s happening through a Chrome extension or not. If it’s not, that’s easily detected and Google will be caught out. Blind trust isn’t necessary at all.
Re: Re: Re:2 Re:
The problem with this model is that the encryption code id controlled by Google, and comes from their servers ever time you load th email application. That code has to have access to private keys, and the plain text. Note, the first has the potential hole that it transmits the private key to Google whenever it is used to decrypt an email.Further a code audit is of limited value because it is downloaded from Google when the email page is loaded.
An encryption system is only as strong as its weakest/easiest to attack link, which in this cases is the Javascript implementation, and its dependency of Google keys for security. The one lesson from Lavabit is that third party keys cannot be trusted, and as Ed Snowden has shown, NSA is prepared to run man in the middle attacks, and demand the certificates and keys necessary to do this from US companies.
Re: Re: Re:3 Re:
You’re arguing against crypto in general, not against this specific implementation of it. That’s a fair argument to have, but it’s independent of Google.
I would argue that even if Google & the NSA can read the email encrypted in this manner, it’s still more secure than no crypto at all — which is what the target audience would be using.
People who are very concerned about their privacy are already encrypting their emails, and Google’s crypto doesn’t prevent that from happening.
Re: Re: Re:4 Re:
I would argue that the current interest in encrypting emails is driven by a desire for protection against government snooping, therefore the solution should resist such snooping.
I am not arguing against encryption in general, just this implementation. Its problems are:-
1) Crypto code loaded from an external site when the email page is opened.
2) NSLs and NSA’s willingness to run man in the middle attacks.
It encryption algorithm may be strong enough to defeat government snooping, but an external party has control over the actual version used, and it is running in a complex code environment of a web page. Without going to much more trouble that using PGP stand alone, and managing your own key exchange, this system cannot be relied on not to be compromised when used. That is at run time it is difficult to prove that an audited version of the code is being run, and that their is no other code associated with the web pages is exporting the plain text or private key.
NSLs mean that there is no guarantee that you are actually connected to Google servers.
Re: Re: Re:5 Re:
“I would argue that the current interest in encrypting emails is driven by a desire for protection against government snooping”
You miss my point. People who are really worried about this won’t be relying on Google to do it (especially since they won’t be using gmail!). They’ll be using their own crypto anyway. Google’s effort is an attempt to protect people who aren’t concerned enough to implement a real solution. I fail to see how this can be anything but an improvement, even if the security isn’t ironclad.
Re: Re: Re:6 Re:
The fact of the matter is that no cryptography is 100% secure. Even if the crypto itself can’t be broken (in a reasonable amount of time), the key can be found if you look in the right spot. Most crypto currently relies on passwords; and passwords are inherently insecure. Most “crypto breaking” software isn’t targeting the crypto, it’s targeting your password, which a computer will eventually guess (probably faster than you think).
The point isn’t to make your stuff perfectly secure. The point is to make it take effort. A “bulk collection” system can’t dragnet everything if it has to take the time to break the encryption on all of it. It’s sort of like locking your front door; a determined invader will get into your house. They just can’t do it easily, and without taking time and/or making some noise. By making encryption standard practice, we force the government and law enforcement to choose their targets based on evidence…which is the whole point.
Disclaimer: My explanation of encryption is extremely simplified and not perfectly accurate. I couldn’t think of another way to put it without writing a small novel. My apologies for any confusion.
I just meant TrueCrypt the product is dead. The code is open source and with any luck, it will be a thorn of the side of anyone who hates privacy for years to come. So yeah, I understand whatever new name they give the codebase, it will be the same code (hopefully with some bug fixes).
It’ll be a different name though, with a different team. But TrueCrypt itself isn’t coming back. It done bought the farm. I wonder if we’ll ever know whether the original team were heroes or cowards, or what the story was. It seems they left that to our imaginations.
Getting back to Google, I do applaud their efforts but there’s only so much they can do. When asked, will they hand over the keys to the kingdom? Have they already? How would we know? We can be pretty sure they won’t shut down the whole thing ala Lavabit. As far as I’m concerned:
“99 ways to have privacy, and a large corporation aint one.”
Re: Re:
That’s (your last point) a good one. Large operations like Google have “target” written all over them, and any intelligence agency in any country on this planet can and will attack them. (Of course they will. It’s what they get paid to do.) So regardless of the merits/lack thereof of Google or AOL or Facebook or Twitter or anything they do or anything they say….they’re going to be hacked. It’s only a question of by whom, when, how — and most importantly, what the consequences will be.
In that light, this is a good move by Google, because when (not if) they get hacked, they’ll have less data to disclose. But…even if the messages are encrypted, they’ll still have the metadata[1], and that facilitates traffic analysis which in turn facilitates tracking and association.
[1] They have to, otherwise they can’t deliver messages. They can certainly scrub the logs often, but if someone taps them in real time, scrubbing them won’t accomplish much.
Re: TrueCrypt not open source
It’s my understanding that TrueCrypt code is not open source because of it’s license restrictions. The code is available and others can use to code to fork the application but it a forked app cannot be used for commercial users.
Re: Re: TrueCrypt not open source
That USED to be true. One of the last things the Truecrypt developers did was to change the license terms, and one of the things those changes permit are forks.
In addition, on a practical level, the developers are unlikely to be able to prevent anyone from doing so. They’d have to out themselves (unlikely) and they’d have to show standing (in court) to take action, which they would have great difficulty doing.
At this point, Truecrypt has essentially been abandoned and anyone is free to pick it up. Early indications are that the truecrypt.ch people are clueless ignorant self-promoting newbies who want to do stupid things like put in auto-update, while the geekcrypt.net people are much more savvy and understand the need for stability.
Personally, I’d like to see all support for Windows ripped out, because it’s pointless: anyone using Windows isn’t serious about security and privacy anyway, so screw them. It’s not worth the effort it takes to support such a markedly inferior operating system, since that takes away from the time available to support better ones. But I doubt either project will do that, sadly.
Re: Re: Re: TrueCrypt not open source
“One of the last things the Truecrypt developers did was to change the license terms, and one of the things those changes permit are forks.”
The encryption code is not included, and probably needs a clean room implementation to be free of potential encumbrances.
“I’d like to see all support for Windows ripped out, because it’s pointless: anyone using Windows isn’t serious about security and privacy anyway, so screw them.”
I disagree with this. Those clueless users need encryption too if only to reduce the risks of compromise for others. If you use truecrypt to protect data that you ever share with anyone else then I would think you’d want to encourage them to protect it too, even if they’re on Windows (and even Bruce Schneier uses Windows for day-today use). Also truecrypt’s gentle user interface can be taught to less-techie Win users (ever tried to explain command-line gnupg to people who have never seen a command line?) First educate the Win user and give them an easy interface, then transition them to another platform where they can see the same truecrypt functionality and feel warm fuzzy glows of familiarity. We were all clueless once.
Re: Re: Re:2 TrueCrypt not open source
“Those clueless users need encryption too if only to reduce the risks of compromise for others.”
If only that were actually true: that is really DID reduce the risk to others. But sadly, it’s not.
1. Windows is probably backdoored. Microsoft’s top brass may or may not know about it; some of Microsoft’s people may or may not know about it; but I in light of what we’ve learned in the last year I can’t imagine that there haven’t been multiple attempts by extremely clueful well-funded adversaries to backdoor it.
2. A Windows system running Truecrypt BUT with a keystroke logger or other capable malware installed provides no security at all, since of course the system’s real owner has access to any Truecrypt passwords.
3. Windows systems are infected with malware on a chronic and systemic basis: the botnet plague is over a decade old and sensible estimates of its scope as in the hundreds of millions. (See for example http://arstechnica.com/news.ars/post/20070125-8707.html which is likely by now a serious UNDERestimate.
4. Schneier might be able to run a Windows securely because he’s smart, clueful and careful. How many Windows users have even a fraction of those qualities? As Ranum astutely observed, “There have been numerous interesting studies that indicate that a significant percentage of users will trade their password for a candy bar, and the Anna Kournikova worm showed us that nearly 1/2 of humanity will click on anything purporting to contain nude pictures of semi-famous females.”
(There are people who can freeclimb El Capitan. That doesn’t mean it’s a good idea for ordinary mortals.)
5. Running Truecrypt on Windows is like bolting armor plate onto a Yugo and pretending it’s a tank. It’s bullshit. It’s a half-ass happytalk feelgood useless gesture that not only provides no real security or privacy, but actually makes things worse because it presents the illusion of security and privacy but not the substance.
If you (rhetorical you) want security and privacy, even a modicum of both, then STEP UP. Run Linux or BSD, both of which of course have their faults, but both of which are enormous steps up from the shitpile of Windows. LEARN. Take some responsibility for your own computing environment instead of wallowing in the pigsty.
Re: Re: Re:3 TrueCrypt not open source
I tried Linux. I really tried to like it. I tried to make it comfortable to use.
My first week using Linux Mint I ran into the following issues:
1. The login screen at operating system start would not take input. Every time I booted up I would have to use hotkeys to log back out, then log back in. The second time it would work.
2. The mouse sensitivity was through the roof, making the system almost unusable. The system options had no sensitivity adjustment, and no mouse drivers were available anywhere to adjust it. Instead I had to create a set of console commands that auto-ran every time I booted into the system to manually set the mouse sensitivity.
3. My Soundblaster card played all system and program sounds…except any sound played through the Linux version of Google Chrome. Nothing I could find online would fix the issue. If I wanted sound to play through Chrome, I would have to plug my speakers into my onboard sound. Disabling onboard sound in bios only disabled sound from Chrome completely.
4. Only five out of the two hundred games I own on Steam play natively on Linux, and of those only two would actually run. WINE fixed some of the programs, which ran slower and required a minimum of an hour to research and set up, sometimes much longer, and sometimes they would never work.
5. None of the free or paid Linux “Office” style programs are superior to Microsoft’s offerings. They aren’t bad, but they lack a lot of powerful features.
I love the idea of Linux. But at some point I want to actually use my computer rather than search message boards for how to do basic stuff, like control sound output or adjust mouse sensitivity.
My computer is custom built (by me) and I’ve been a heavy computer user since before Windows existed (mostly MSDOS). I remember having to create custom startup scripts for individual programs and fighting just to have basic functionality (ironically, things like the mouse and sound). I don’t feel like going to back to those days.
If I wanted absolute computer security, I could just not use a computer. At some point you have to give up some level of security for functionality, and right now (for me at least) Linux sacrifices WAY more functionality than I’m willing to give up.
This is coming from someone familiar with programming, hardware, and advanced system tools. There is simply no way someone with less knowledge is going to be willing to put up with that poor of service for more than a week, not even for free. For all it’s flaws (and it has many), Windows works. And it works without requiring a technical background.
I realize my issues are not ones that everyone has or will experience. It could have been my version of Linux, it could have been my mishmash of hardware, it could have been a lot of things. The point is that the system was difficult to install and made a terrible first impression, and I really wanted to like it.
I lasted about a month, then reformatted and reinstalled Windows, got SRT working to use my SSD as a cache, and ended up with a system that worked way faster than Linux without the hassle of a SSD system drive with a separate “install” drive, and all my hardware and software works pretty much out of the box.
Linux just isn’t there yet. Maybe it will be one day…but that day is not today.
Will Google still scan emails in order to find clues as to how to target advertising?
Yes or no?
That’s the only thing that matters. If the answer is yes, then screw them.
Re: Re:
Will Google still scan emails in order to find clues as to how to target advertising?
Yes or no?
They can’t. Because they have no access to your private key, so the content of your emails is hidden from Google.
Re: Re: Re:
I’m sure they will also start placing advertisement plugins in chrome that will read the content of your email regardless to retrieve appropriate ads.
Re: Re: Re: Re:
I went and looked at Google’s ad profile of me. Golly gee, it’s set to present technology-related ads. They really don’t need, and may prefer not reading our mail. Automagically sorting people into targeting bins more than gets them in the ball-park.
For it to be end to end my computer would have to create a private key and a public key. The recipient would also have to do the same. No one but me should know my private key (and no one but the recipient should know his/her private key). I should know the recipient’s public key (and be able to confirm it through a reliable channel between me and the recipient). I should encrypt the E-Mail with a symmetric key, encrypt the symmetric key with the recipient’s public key, and send the encrypted e-mail and encrypted symmetric key to the recipient where the symmetric key gets decrypted on the recipient’s computer using his private key and then the symmetric key is used to decrypt the e-mail.
Is that’s what’s happening here?
Re: Re:
is that *
Re: Re:
For it to be end to end my computer would have to create a private key and a public key. The recipient would also have to do the same. No one but me should know my private key (and no one but the recipient should know his/her private key). I should know the recipient’s public key (and be able to confirm it through a reliable channel between me and the recipient). I should encrypt the E-Mail with a symmetric key, encrypt the symmetric key with the recipient’s public key, and send the encrypted e-mail and encrypted symmetric key to the recipient where the symmetric key gets decrypted on the recipient’s computer using his private key and then the symmetric key is used to decrypt the e-mail.
Is that’s what’s happening here?
Yes. From what’s being said about the extension, that’s exactly what happens. Google never has the private keys.
Re: Re:
Yes, BUT:
1. The code hasn’t been independently reviewed or audited. They’ve released it — so now it can be, and probably will be. But it hasn’t yet.
2. It’s written in Javascript. Ugh.
3. It thus still relies on using a web browser to access email, which is a perfectly horrible idea.
4. It still exposes metadata. (In Google’s defense, this isn’t solvable in this context because mail has to be addressed to someone.)
5. Based on their FAQ, it’s not clear to me how they expect correspondents to exchange keys.
6. I’m not entirely sanguine about the way they’ve chosen to manage the key ring. It might be fine. It might not be. Need to think about it.
7. Their answer to the question of whether or not attachments are also encrypted is ambiguous. I suspect this is just the result of poor wording choice and not an attempt to be evasive.
8. They’re trying to comply with relevant IETF standards. That’s a good thing. But they do note, and probably correctly, that there will likely be interoperability issues, e.g. user@gmail.com, who is using this Chrome extension with Chrome on Windows, sends encrypted email to user@example.com, who is using GNUPG and FreeBSD. Will it work? Don’t know.
The killer with this is #4, because — by definition — it can’t be fixed. “Capturing traffic metadata from gmail” is no doubt a primary objective of many intelligence agencies and it’s too much to hope for that they’ve ALL failed.
Re: Re: Re:
After Lavabit, trusting the security of someone else’s keys makes perfect sense. The web pages and Javascript code could be compromised by NSA in the middle, and all security and privacy flies out the window.
Re: Re: Re:
It’s not clear what you mean by “in this context”, but the problem is definitely solvable. Mail doesn’t need to be addressed to anyone–you could broadcast it to the world and everyone could try to decrypt it (note gnupg’s –throw-keyids option). This doesn’t scale of course, but it demonstrates the possibility. Now we “just” need to optimize. Relevant research: bitmessage, remailers, hidden services, the Pynchon Gate
I suspect they might be supporting the (obsolescent) inline PGP format rather than PGP MIME (both are standardized). It’s simple (for working with Web text boxes), and a decent start, but I think they’ll need to do better.
Re: Re: Re: Re:
“It’s not clear what you mean by “in this context”, but the problem is definitely solvable. Mail doesn’t need to be addressed to anyone–you could broadcast it to the world and everyone could try to decrypt it (note gnupg’s –throw-keyids option). This doesn’t scale of course, but it demonstrates the possibility. Now we “just” need to optimize. Relevant research: bitmessage, remailers, hidden services, the Pynchon Gate”
I’m aware. This is not my first day on the Internet. For example, Usenet provides a viable model for widespread/broadcast distribution of messages that aren’t addressed to anyone. However, those still carry source metadata, and some of that is actually necessary in order for Usenet to work properly. (For example, article propagation, including avoidance of duplicates, relies on it.)
But Usenet is not email. Neither are some of the other things that are proposed. That isn’t to say that they’re bad: some of them are quite good. But it is to say that billing them as email is a misnomer.
And the problem with that is that email is still THE application on the Internet. Yes, it would be nice if we could declare a flag day, replace it entirely and move on, but that will never ever happen. So we need to work with what we’ve got, and one of the ways to mitigate the mass collection of metadata by adversaries is to stop making it easy for them. (“easy”, as in 15,373 organizations all outsource their email to Google, making it much easier for an adversary than if they were all separate.) If I were to tap into Google, Yahoo, Hotmail, AOL, and a few other services, I’d have my dirty fingers on a substantial percentage of the Internet’s mail volume. That’s bad.
So yes we should use strong encryption. Yes we should audit the software. Yes we should have cryptographers vet the algorithms and the code. Yes we should encourage everyone to use this. But we also need to get people to stop handing their operations over to third parties like Google and cloud vendors, because those third parties have targets painted on them that are large enough to see from space. (e.g., there is NO WAY that Rackspace’s cloud and Amazon’s cloud aren’t tapped. Of course they are.)
Re: Re: Re:2 Re:
Usenet is not email, but email was transported over UUCP in the past. Also Fidonet, SMTP, and more recently SMTP-over-TLS. It’s not quite as homogenous as you seem to imply. Enabling SMTP-over-TLS hasn’t required a flag day, and it actually hides metadata somewhat (if you send to Gmail over TLS, the target address is never sent in plaintext). We could decide today, for example, that “_torsmtp._tcp.example.com. 86400 IN SRV 0 10 1234 ADDRESS.onion.” is a thing that mailservers should look for and use. If you do that DNS lookup over Tor and verify the DNSSEC, it will be very hard to eavesdrop on the metadata. And the MX record is still there, for now, for servers who don’t support “new email.”
in other news: global rape syndicate offers free condoms for anyone using their ‘private’ rooms.
goodwill indeed!
Eliptic Curve's ugly head surfaces again
Did notice that it supports only elliptic curve random key-pairing because it’s faster.
But isn’t it also compromised to the NSA?
Re: Eliptic Curve's ugly head surfaces again
Not sure. I remember reading an article about something supposedly being cracked but am not sure what impact it may have if any.
http://soylentnews.org/article.pl?sid=14/05/31/0329201
Re: Re: Eliptic Curve's ugly head surfaces again
This ( https://en.wikipedia.org/wiki/Dual_EC_DRBG ) explains the issue pretty well. (If not, follow some of the links.) The problem isn’t elliptic curve crypto per se, but the NSA’s tampering with the standard for one of the pseudorandom number generators (and RSA’s willingness to take a payoff).
Welcome to 1999 Google!
Terrific, we're gonna need it in Thailand
Things just keep getting more repressive in Thailand. People are arrested for doing the 3 finger ‘Hunger Games’ salute to protest the coup.
You get dragged into a taxi, detained and released only when you sign a pledge not to protest or critize the military junta on penalty of a year in prison.
The internet is heavily censored, and their latest thing is they want all the connected routed through TOT, so they can monitor all internet traffic and censor social sites heavily forcing only approved speech on an approved social network site:
http://asiancorrespondent.com/author/siamvoices/
Latest proposal is to make ‘Les Majeste’ apply to General Prayut too (the coup General), raising him above the level of the King.
Well at least Tor still works for now.
Re: Terrific, we're gonna need it in Thailand
“Latest proposal is to make ‘Les Majeste’ apply to General Prayut too (the coup General), raising him above the level of the King.”
Really? I’ve done my best to insult and degrade the King for years, because I think the concept of “Les Majeste” is bullshit. Now I’m going to have to expend all that effort again on Prayut?
Sigh. Alright. I suppose I can spare the time.
PGP has been available for decades. I don’t see how Google gets a pat on the back for “taking this step” when everyone should have been doing it in the first place.
The drawback to using PGP encryption are the keys. Misplace one and no longer can those emails be retrieved. Anyone who has ever had to reformat a system because of a fault or bought new computers will attest to this.
This means Google has to be storing the user keys somewhere, and call me cynical to believe these aren’t accessible to anyone but me.
This article presents a fundamental problem with people’s understanding of encryption: they simply don’t know how to use it or they don’t care to take the risk to lose their emails should the key be lost.
If Google really wants to make a difference, encrypt the internet as a whole, so everything is encrypted.
They can start by giving away free certs and maintain the encryption keys on a server that no one has access to.
Let’s see if they’re willing to step up their game, instead of taking credit for something they didn’t really do.
Re: Re:
The real problem with using PGP is that it’s not ubiquitous — if the person you’re sending mail to doesn’t use it, then they can’t read your email. Since harassing everyone you want to send mail to to start using PGP will only make most people unwilling to exchange mail with you, this is a serious issue.
The main reason PGP isn’t ubiquitous is because it’s inconvenient. Automatic end-to-end encryption resolves both of those problems for people using gmail (personally, the cast majority of people I know don’t use gmail, so none of this impacts them at all). All in all, it’s a good, but imperfect, thing.
“If Google really wants to make a difference, encrypt the internet as a whole, so everything is encrypted.”
How would Google do this? They don’t run the internet, and don’t have anything close to the power to do something like that.
Re: Re: Re:
Maybe Violynne is thinking about Google Fiber encrypting all traffic to and from its customers though I’m not sure if that’s doable.
Re: Re: Re:
Actually if they are not using PGP you cannot send them an encrypted email, and the cannot verify any signature you place on an email. That way, so long as private keys are kept private, only the recipient can decrypt the email contents, and only the sender could have signed it. (It is a bit pointless using a private key to encrypt contents when the public key can decrypt it.)
Re: Re: Re: Re:
“Actually if they are not using PGP you cannot send them an encrypted email”
Huh? Of course you can. They just won’t be able to read it — it will look like gibberish.
Re: Re: Re:2 Re:
Oh, I understand — you’re really saying that they won’t have a public key so you can’t encrypt the email using it. That’s true (I was thinking of the full range of crypto that PGP offers, not just PK).
Two things:
1) If you select “Americas” in the Select Region drop down menu, you will see that Verizon is also sitting pretty at 0% TLS support.
2) There might be a bit of marketing going on here. Google seems to be talking specifically about TLS, and it’s possible Comcast and Verizon support SSL. The Google report implies that Comcast and Verizon use no encryption, but it’s possible that they just use outdated encryption. Does anyone know whether or not Verizon or Comcast support SSL between mail servers?
Re: Re:
“Does anyone know whether or not Verizon or Comcast support SSL between mail servers?”
I have opportunistic encryption turned on in my mail servers: that is, if the other side supports it, my side will try to use it and both sides will attempt to negotiate a common cipher.
Looking at my mail logs from yesterday, I don’t see any support from Comcast or Verizon. Caveat: that’s just my observation and it may be something idiosyncratic to my site. But other large providers don’t support it either, e.g. mail.com actually refuses email using transport encryption.
Already here..
Plugin has existed for a couple of years now
https://www.mailvelope.com/
(although the firefox version doesn’t seem to work with the current release of firefox, the chrome version works just fine)
Will they ignore US export laws ?
I call BS on this one. Export laws of the US does not allow google to export strong encryption. From their developer guidelines. See https://support.google.com/googleplay/android-developer/answer/113770 for more info. Of course this is google play, but the laws will be more or less the same for chrome itself. So fuck em, another cheap attempt to raise in publics’ opinion.
Great way to stay out of the dragnet for an average Joe. But for sensitive information, I think not..
When is this common sense gonna spill over other google services, i dont know, such as their gmail service to name but one
(different AC then above)
googles modus operandi is antithetical to privacy.
techdirt has some serious cognitive dissonance when comes to reporting anything related to google.
this is no more then a worthless PR gimmick and you’ve done some fine marketing for them here, as always.
it’s hard to understand how TD can do such outstanding work covering tech/IP/NS related legal/moral issues, but utterly fail when it comes to explaining how those same issues affect the current climate which the tech mega-corps must operate.
Any security expert worth his OR her salt will tell you end to end encryption clients are absolutely *worthless* on compromised hardware – THIS INCLUDES *ANY* GIVEN SMARTPHONE BY DEFAULT.
Anyone who’s serious about secure communications that protect against metadata mining, aren’t using email. They’re using communication tools that are much easier to use, such as Off The Record (OTR) text chatting, or Voice over IP (VOIP) programs which support the Zimmermann Real-Time Transport Protocol (ZRTP), such as Jitsi.
Both OTR and ZRTP support soft lived ephemeral keys, which enable Perfect Forward Secrecy, meaning even if an attacker gets ahold of your private key, they can’t go back and decrypt years worth of your messages.
OpenPGP doesn’t support Perfect Forward Secrecy. OpenPGP keys are long lived. The best email project I know of that’s trying to address these issues, is leap.se .
Either way, email should be avoided as much as possible. There’s just too many legacy issues with email. It’s best to go with easier, more secure options than try to fix legacy email. In my opinion.