"Are End-To-End security bugs eligible for Google’s Vulnerability Rewards Program?
Yes, we have specifically expanded the scope of our Vulnerability Rewards Program to include End-To-End. This means that reports of exploitable security bugs within End-To-End are eligible for a reward."
Should be an interesting trove of JS tricks:
"JavaScript crypto has very real risk of side-channel attacks
Since JavaScript code doesn't control the instructions being executed by the CPU — the JavaScript engine can perform optimizations out of the code’s control — it creates the risk of security-sensitive information leaks.
End-To-End requires user interaction for private operations in normal use, mitigating this risk. Non-user-interaction actions are rate-limited and done in fixed time. End-To-End’s crypto operations are performed in a different process from the web apps it interacts with.
The End-To-End library is as timing-aware it can be and we’ve invested effort to mitigate any exploitable risk."
Well if you're encrypting your email on your local PC and an attacker can conduct a side-channel attack then you're boned already. Your PC must be secure to begin with otherwise no crypto is going to save you. If an attacker can side-channel this encryption then he can probably just straight-up read your keystrokes or hard drive.
I think you're both right. There are side channel attacks against remote hosts (timing-based padding oracle attacks agains TLS come to mind). But for the case of PGP, which is mostly for encryption at-rest, attacks like this don't seem as relevant. I say seem as relevant, because crypto attacks can be surprising :)
BEAST is a design bug, insecure use of CBC mode. CRIME is a side channel attack, but the side channel that leaks information (compressed cleartext size) is not related to the language used, but again to the design of the algorithm.
The basic idea is that implementation-related side-channel attacks, such as timing and power draw, are very hard to exploit remotely. I guess you could write a JavaScript implementation of AES that is so bad that key-dependent multimillisecond jitter can be measured remotely. But it's almost impossible to do it by mistake.
The real problems of JavaScript are it's highly malleable runtime that offers no guarantees, everything is writable. So you need to improve browser support before you can write JavaScript crypto, that's why this is a great project: Google has the ability to change Chrome into a secure end-to-end platform, should they want that.
We hold ourselves to a higher standard; we started from scratch
and created a testable, modern, cryptographic library.
That is awesome. So's this:
Chrome’s design means that extensions should be safe against
other extensions.
And this:
End-To-End uses Content Security Policy as well as inherently
safe APIs in frameworks (strict Closure Templates). End-To-End
doesn’t trust any website's DOM or context with unencrypted data.
I had a slightly different reaction to the "high standard" bit. I always thought Prof. Boneh was a high standard. Does anyone know if there were any obvious reasons to exclude SJCL?
Disclaimer: I contribute to the core crypto library in Google End-To-End.
I was also a student of Prof. Boneh. I took his CS255, and became a TA for his infamous's Crypto I class on Coursera. So I guess at the end of the day it's still Boneh's teaching that has helped my colleagues and me create this library ;-).
SJCL is a great library, but it didn't quite work for us because:
* It isn't a Closure library. We want to use Closure because it supports types, which in turn make it easier and less error-prone to develop crypto code.
* It doesn't support typed arrays. We don't have typed arrays in End-To-End yet, but we're working on that.
* It doesn't support all the curves we want, and it seems that the main developer isn't interested in adding new curves, e.g., Curve25519.
* It doesn't have ciphers or signature schemes that we need such as RSA, Ed25519, deterministic ECDSA, etc.
I do expect users to hash the message before passing it to ECDSA, this way you could use any hashing library with it. Though, elliptic.js does actually depends on hash.js to seed it's PRNG.
> I do expect users to hash the message before passing it to ECDSA, this way you could use any hashing library with it. Though, elliptic.js does actually depends on hash.js to seed it's PRNG.
I think this isn't a good design because most people won't know that they must hash the message before passing it to the ECDSA. People will misuse it, and open themselves to attacks.
Anyway, it would be interesting to compare speeds of our implementations. I'm really obsessed with try to reach 1ms verification, but so far only got to 4ms.
Not a stupid question at all. We actually considered this option, but OpenPGP.js looked pretty bad back then.
Security-wise the library wasn't in good shape. One of our cryptographers would "classify [OpenPGP.js] as trash". It has been audited recently, but the result doesn't look very good either [1]. I don't know the current status though.
OpenPGP.js didn't actually implement most of the ciphers - it just imported them from various sources. This made the library inconsistent, i.e., some functions expect string, while others expect byte array, which in turn made it harder to use correctly in a language like Javascript. If we chose OpenPGP.js, we needed to change these ciphers anyway, so we thought it's just better to write them from scratch.
I'm a contributor to OpenPGP.js. I understand your choice as the code was indeed in quite bad shape several months ago. I do want to point out though, that the code has gone through a big refactoring an cleanup since then:
https://github.com/openpgpjs/openpgpjs/releases
Having said that, a consistent rewrite using typed array and native web crypto apis under the hood does indeed sound very reasonable. I saw that native web crypto is not used throughout. What are your plans in regards to web crypto?
Also what is the predicted timeline for getting End-to-End into a production ready state? We would be quite interested in using it as a standalone library in our Chrome Packaged App: https://whiteout.io
The plan is to use WebCrypto if it's available. We've moved RSA to WebCrypto, and the next targets are ECDH and ECDSA.
> Also what is the predicted timeline for getting End-to-End into a production ready state? We would be quite interested in using it as a standalone library in our Chrome Packaged App: https://whiteout.io
I can't tell you about our timeline for the extension. But if you just want to use the crypto library, you may want to wait for a couple of weeks, just to make sure none discovers any serious vulnerabilities.
I like WhiteOut. It's a great product in the right direction. We really want and will support the usage of the library in products like yours.
Thanks for for reply. I'm wondering if you know if it's possible to use the AES-CFB mode from the Web Crypto Apis, since the OpenPGP CFB (resync) mode seems to have special requirements?
> I like WhiteOut. It's a great product in the right direction. We really want and will support the usage of the library in products like yours.
Thanks! Is there a guide somewhere that explains how to build the standalone lib?
> Thanks for for reply. I'm wondering if you know if it's possible to use the AES-CFB mode from the Web Crypto Apis, since the OpenPGP CFB (resync) mode seems to have special requirements?
I haven't looked into it.
> Thanks! Is there a guide somewhere that explains how to build the standalone lib?
No, there isn't. But can you file a bug with us? I'll make sure we have something for you.
In the long term, could you extract the underlying crypto library and make it available for others to use in easy form? Crypto.js is pretty difficult to use and I keep seeing people including the files into their projects because of this. I'm mainly looking for:
* Officially hosted on GitHub (or at least official mirror)
I guess I should have been more clear. Why not add the primitives to SJCL and leverage an existing code base--a code base authored by someone who is considered to set a very high standard in crypto--instead of reinventing everything? Setting a higher standard than Prof. Boneh seems like a tough thing to do. Why not stand on Boneh et. al's shoulders?
It would be useful to have someone from Google elaborate on the summary they posted today. But I do recall that at least one of Prof. Boneh's postdocs mentioned in the original 2009 SJCL whitepaper is now at Google working on encryption...
[edit: Looks like that elaboration did happen elsewhere in the discussion -- just noticed it now.]
"Please note that enabling Chrome’s "Automatically send usage statistics and crash reports to Google" means that, in the event of a crash, parts of memory containing private key material might be sent to Google."
I hope that has more than a FAQ warning when they release it to the Chrome Store. Otherwise....:/
It isn't perfect but it is probably the best in-browser option given the constraints available.
Maybe encryption/decryption could be performed in a separate, isolated process, which stack would never be sent? It seems like Chrome multiprocess architecture could allow for this.
Under "JavaScript crypto has very real risk of side-channel attacks": End-To-End’s crypto operations are performed in a different process from the web apps it interacts with.
It's probably relying on normal process isolation (and extensions run in a different process), but in order to disable stack dumps for it, you'd have to have some way of indicating "this process is special", which rules out treating it like any other extension.
Maybe there could be some new extension permission for "encryption extension" or something, but it's possible that could be abused...
I'd agree that is better...but I am guessing that Google doesn't want to build this functionality directly into Chrome. Anyone who isn't Google wouldn't have the option for Chrome...Chromium isn't 'mainstream' :(
EDIT: Maybe the other guy is right and you didn't mean baking it into the browser. xD
Just tried this out and it works great! Had to build it using the instructions on the wiki, but nothing too painful. It doesn't just integrate with gmail, but more with all textarea's around the web. When you are typing in a textarea and press the extension icon next to the hamburger menu it will pop open a menu containing the text that you were typing on the site, and are given the options to encrypt/sign a message. When done it replaces the contents of the textarea on the site with the signed/encrypted message.
It works quite nicely, and I like it. I would like to see some kind of keybase integration, though it's not hard to import my tracked users into the extension by exporting my gpg keyring and importing it again.
But as I'm typing, Gmail is saving my draft automatically to Google servers. Normally, at least. This means Google would have a copy of my email as it existed before I encrypted it.
In your testing, do you see any evidence that this extension prevents Gmail's automatic draft saving?
In the FAQ they mention "End-To-End doesn’t trust any website's DOM or context with unencrypted data. We have tried to ensure that the interaction between the extension and websites is minimal and does not reveal secrets to the website."
I'm curious about this too. Does that mean they somehow insert a textbox that the host page can't see? I didn't realize extensions could do that.
Edit: ah, this appears to be where it happens. They insert an iframe the extension owns, so the host page won't be able to see what's in it:
It would be nice if that got added to PwdHash[1] extension[2]. PwdHash chrome extension currently seems to just try to capture all keyboard events while the master password is entered in a site's password box. Also, it seems to me that it runs in the site's context.
But when displaying the cleartext of a previously sent email or received email... they must be able to decipher the encrypted text in order to display it to the viewer, no?
Not if you choose to first type your message in the textarea on the website, but this is optional. You can also click the extension icon, and begin typing your message in the extension window. That way it never touches the DOM of the target page, but it is slightly less convient.
Should be fixed now. The Google End-to-End library uses the 5-byte encoding scheme for signature subpacket lengths, which I hadn't seen used before and was buggy in KBPGP. Most signature subpackets are <192 bytes long and can be encoded with the 2-byte length encoding.
BTW, our library doesn't support the ECC extensions yet, so any encryptions/signatures generated with ECC keys will fail to decrypt/verify on keybase (and also on GPG v1.4).
If it is a chrome extension and is installed via the Chrome Web Store, it can be updated silently in the background if I'm not mistaken. So in theory, wouldn't it be possible to serve Google with a NSL and force them to silently push a modified update to a targeted user that reveals the private key?
Ya, I'd build it myself if I wanted to rely on the security of it. We'd have no way to know if the source is the same in the Chrome Web Store as it is in the open source project sign we can't check the signature.
I don't think so. PGP scrambles the text of the message for you (that's the body), but you're still using the standard email protocol, which sends attachments without making changes to them. You'd need to encrypt the files before sending them. (And the recipient would have to unencrypt them manually.)
I think it very easily could. Email bodies are often MIME Multipart messages [0], which can be nested to arbitrary depth. You can see an example of such a message here [1]. The PGP setup used by default with Mutt will encrypt your cleartext multipart message (which contains your text, html, and attachments) and then send only the new cyphered body.
It depends on whether they use PGP/MIME or inline PGP. Without installing the tool, I'm guessing they use PGP/MIME, because you pretty much can't use html email with inline PGP, and I doubt they're going to default to plain/text mails.
Their FAQ explicitly says that they do not currently support RFC 3156, "MIME Security with OpenPGP" (http://tools.ietf.org/html/rfc3156). I don't know this stuff well, but that makes me suspect that PGP/MIME is not currently supported.
For this to be able to send PGP/MIME emails, the webmail service would have to allow the client to uploaded a body which is not tampered with at all, and also to specify the mime type of the email. That way, you could upload a pre-built MIME structure to be used as the body, generated by the OpenPGP extension, which includes the encryted attachments.
This could work, but the web service would have to support it as well as the extension.
Then there is also the issue of how does the receiver read the message? The extension would need to be able to parse MIME, and allow access to the separate parts.
Regardless of how e-mail protocol transfers attachments, GMail pre-uploads files to their servers when composing an e-mail, so if you want to encrypt them, you'll need to do it beforehand.
If you look that low, the body isn't actually encrypted, just the parts of it that contain your data.
Answering the GP, that varies from one implementation to another. Most clients encrypt attachments, but it looks like this one extension only encrypts the textarea contents.
Right, I was responding to the "why would attachments be considered part of the body?", not describing whether or not the Google implementation actually did treat them that way.
"Please note that EC support was added to GnuPG 2.1 beta in 2010, but it hasn’t been released as a stable version yet. To communicate with other people that don't use End-To-End, you will need to either generate a key in GnuPG and then import it, or build GnuPG 2.1 yourself."
So basically, out the box this doesn't interoperate well with non-beta versions of GnuPG which are what everyone else is using for end-to-end e-mail encryption. That's annoying.
I don't think they're planning on changing that, according to later FAQ entries generating non-EC private keys is just too slow and it's the use of EC keys that causes the problem.
This is a huge problem that's akin to "replacing HTML/JS." It's a non backward-compatible change that make the plugin nearly 100% useless for current PGP users. Obviously folks can generate new EC keys, but they will be reluctant to abandon keys they've had for years that contain valuable third-party signatures. I think this will be a huge hindrance to adoption, and it would be imperative for the community to implement RSA, even if it's only for key import and interop, not generation.
Their workaround of "To communicate with other people that don't use End-To-End, you will need to either generate a key in GnuPG and then import it" wouldn't make much sense if ETE wasn't able to import and interop with RSA keys already. You can also find an rsa implementation in the repo (https://code.google.com/p/end-to-end/source/browse/javascrip...) that would indicate that they do support RSA encrypt/decrypt. However I can't find any DSA implementation, I think there could indeed be issues with people using DSA/ElGamal keys. (which is weird because there is an implementation of ElGamal, probably the DSA implementation is still being worked on)
Isn't this contrary to Google's goals as an advertising business? If people are using end-to-end encryption, they won't have cleartext emails to mine, &c. I need to wonder what the catch is, because there is definitely one: does Google own all the keys, or does Google secretly own all the keys?
What if there is no catch? Google's security team is apparently pissed off over the NSA revelations with regards to the infiltration of their infrastructure.
> does Google own all the keys, or does Google secretly own all the keys
The keys are generated by you, stored on your browser's localStorage, preferably encrypted (their words, not mine). Since it's open source and distributed by Google, I bet many eyeballs will look for bugs, much more than alternatives such as Mailvelope or WebPG. So, no, I don't think Google will ever have access to your private key through this mean.
My theory:
- We're talking about PGP. This will only impact geeks.
- Google prefers keeping the trust of said geeks by willingly revoking its capability to read their conversations. One of the primary support of Google success is said geeks, and it wants to keep it that way.
- PGP only encrypts the body of an email. The header (ie the metadata) is still here for Google to collect, in plaintext
It's not really possible to send encrypted messages to people who aren't already using OpenPGP, since you need to get their public key, before you can encrypt the message. You could presumably encrypt it with some symmetric cipher ahead of time, then send them the encrypted junk and say, "Send me a PGP key and I'll send you the passphrase for the message!", but I dunno that anyone's going to do that.
That said, pretty much every message I send to someone who doesn't have a key on the keyservers includes, "Hey, send me your PGP key, I don't do plaintext."
No, this is a very wise strategy that puts users' interests before short-sighted goals to increase revenue at all cost. Companies need to understand it, users' interest must come first, revenue will follow.
Why do people use webmail? Because it's convenient. If I use a client like Thunderbird and download all my emails then if I want to find one of them I have to search for it on the device that I downloaded it. Of course I could upload my emails on a server and access them from other devices but it's a hassle. Webmail solves this problem. Additionally, why competent, smart, technical people very often don't use digital signatures? Same as before plus if you want to use your emails in other devices you have to transfer your secret keys and remember their passphrases.
The transfer of the secret keys is what will keep the usage of this extension low. Therefore, Google succeeds in gaining more trust while offering something that you can already achieve on your own using other software like Thunderbird with the Enigmail extension. Also, note that even by using a digital signature you hide only the emails that you choose to send encrypted and those that you receive encrypted by the senders. I use digital signatures every day, I usually send and receive signed messages. However, the percentage of unencrypted messages in my inbox is probably more than 99%.
Google is not mining all networks for cleartext email. They are mining gmail which they have control of the "end". This is a huge advantage for Google as ISPs are starting to offer ability to advertise to end users by mining traffic.
"End-to-end" implies that Gmail won't be able to read your emails. That means that this software and Gmail, one of Google's largest products, are going to be competing. One of them needs to adapt or die: if this software isn't backdoored or vulnerable right now, it will either be shuttered, backdoored or made vulnerable in the future. (Certainly Gmail is of tangible, financial good to them: it's more likely for them to favor it over End-to-End, which is a non-profit and humanitarian effort.)
Heh, that's actually a neat idea. The profile of people which regularly send/receive encrypted email is basically geeks right now. Key off of the "-----BEGIN PGP ENCRYPTED MESSAGE-----" bit.
Yeah. Honestly, I think that if you know that someone encrypts their messages, you probably know a lot more about them then most other data points reveal.
It would also get Google a lot of street cred for being a privacy centric business.
My only problem is, I just don't see how you can scale the Chromebook software stack to a privacy centric business. I can't imagine trying to secure PGP keys on a Chromebook. But I haven't used one since the early beta models, so others may have more informed opinions,.
Sure using this will just send a bunch of gibberish to Gmail in the body such that Gmail won't be able to auto-scan for ad keywords to send to you. But this probably will be used by .000001% of Gmail users, so I doubt they are worried about this affecting their business in any meaningful way.
And, even among those people who do use it, a big percentage of their email will remain unencrypted. Transactional email like flight or hotel booking confirmations sent from the airline or hotel. I have to think that's the valuable stuff to Google in terms of selling ads, not the topics you would choose to encrypt.
So the downside to them is not that big. And it's offset by the upside of user trust and confidence being maintained, or at least eroding less.
The headers, subject line, recipients are not encrypted. There's probably enough info in the subject line and recipients and corpus of other recent subject lines sent among those recipients to still do a halfway decent job at targeting ads.
Unless I'm mistaken, the author appears to be implementing OpenPGP in javascript. This has already been done by OpenPGP.js. That project is several years old, is active, and has been independently audited.
Is this simply reinventing the wheel? OpenPGP.js can easily be used in an arbitrary browser extension.
I have no affiliation with the OpenPGP.js project besides working on a small project for personal use.
Google's posting today addresses this point, I think:
https://code.google.com/p/end-to-end/
"When we started work on End-To-End, there was no JavaScript crypto library that met our needs, so we built our own. During development we took into consideration all the criticisms and risks that we are aware of, and invested effort to mitigate these risks as much as possible... We hold ourselves to a higher standard; we started from scratch and created a testable, modern, cryptographic library. We created this new core library for End-To-End with support for BigInteger, modular arithmetic, Elliptic Curve, as well as symmetric and public-key encryption. Having done that, we then developed an OpenPGP implementation on top of it..."
It's possible, but from my conversations with Google engineers in the past I'd guess (with no inside knowledge) that it was the result of a serious security evaluation of existing code.
> Also, the account you're posting from was created 22 minutes ago and has done nothing but post criticisms of today's announcement. Coincidence? :)
Declan, nothing but respect for all your writings but he's got to make an account one day and if he's critical but otherwise polite and seems to be willing to concede the point why attack like that? It might be an account created specifically to protect a reputation. As far as I can see his concerns are valid and the answers are to the point. I'd rather see someone be extra critical when it comes to new crypto stuff than too lax.
It's great to see them making the effort, but why not notify the OpenPGP.js with the outcome of a security evaluation? (I'm not aware of any other active javascript openpgp implementation, so I assume that's what you're referring to.) I've been following OpenPGP.js for a while and I've not seen anything from Google.
OpenPGP.js is not an amazing code base, I know this for sure. Perhaps a rewrite was the only way to salvage it.
I wonder why they didn't release the library independent from a browser extension. A brief look at the directory structure makes it seem that it wouldn't be too hard to decouple the OpenPGP implementation from the extension.
In any case, this is a big win for privacy. Reinventing the wheel or not.
What's the implication there? At the end of the day it sounds like they simply didn't get involved in an open-source effort, in which case the NIH critique stands.
This is a push in a great direction. I really do hope it catches on and will leave to more and more users adopting strong crypto on all ends. One can hope...
There are javascript implementations of aes, cbc, pkcs7 and more, all released with Apache 2.0 license. If the quality is what you'd expect from Google they could become valid alternatives to the other implementations out there.
No it wouldn't be better. You'd just have yet another LavaBit that claims ultimate security but has no teeth. The private keys must never touch the DOM, whether it comes from Google's servers or put there by an extension, otherwise it's vulnerable to someone hijacking/NSL-ing the gmail session.
Therefore something must be installed on the local computer, whether that means a Chrome extension that has access to localStorage (like this project) or some standalone app.
If you're worried about UX, it looks like this project is meant to interface with gmail specifically, and extensions are able to alter the experience so I imagine it will be reasonably easy to use.
Well the threat model would rather be that Google is forced to serve a version of JavaScript to you that leaks your private key. Which is a concern and a reason why you should rather use a self hosted email client like Mailpile.
If you are concerned about someone hijacking the gmail session you have lost anyway, as the decrypted (or not-yet-encrypted) text surely has to hit the dom at some point.
<infogulch> is correct. I wrote about this in 2007:
http://news.cnet.com/Will-security-firms-detect-police-spywa...
"In theory, government agencies could even seek a court order requiring security companies to deliver spyware to their customers as part of an auto-update feature. Most modern security companies, including operating system makers such as Microsoft and Apple, offer regular patches and bug fixes. Although it would be technically tricky, it would be possible to send an infected update to a customer if the vendor were ordered to do so."
Countermeasures to autoupdates include: (a) disabling them; (b) verifying that the checksum you receive is the same as posted on a number of different sites unlikely to be coerced into delivering FedGov malware; (c) only downloading autoupdates from a non-U.S. repository unlikely to be coerced into delivering malware. And probably many others I'm not thinking of offhand.
But in reality if your threat model is that the NSA/FedGov/FBI/GCHQ/CIA are already targeting YOU SPECIFICALLY, you probably already have a few dozen physical bugs that were concealed in your home placed via a sneak and peak Scarfoesque black bag job the last time you went out for pizza. A hypothetical court order to force FedGov malware on you specifically via autoupdates can be contested by the provider (I was the first to report last May that Google was litigating two non-malware NSL cases pre-Snowden) and in any case is not bulk surveillance.
I agree that such a thread model makes things difficult, however I'd like to believe that it can be solved for. Regardless, there is value in hiding your communications from mass, non-targeted surveillance.
If you're able to completely "solve for" the threat model of NSA/FBI/GCHQ/CIA/etc. having a serious and persistent interest in you, and knowing where you sleep at night, my hat's off to you. Few people are that confident.
I never implied that I could! Anyway, my comment was concerning communications. Physical security is another matter. I must have missed that portion of your OP.
In this project, even if Google is forced to serve a compromised version of Gmail's javascript they still can't get your key, since it's stored in the browser's localStorage and is private to the extension, where all the crypto happens. All gmail gets is the end result.
So the threat model for this project is autoupdates. Extension autoupdate, chrome autoupdate and OS autoupdate could all compromise this, but that's still worlds better than just sending some different obfuscated javascript in a browser session.
Encypt it offline, copy paste the encrypted text+signature into the GMail compose window. Unencrypted never hits the DOM (unless the recipient has an extension that decrypts in the DOM).
End-to-End is better outside Gmail. Because it is an extension, you can encrypt/decrypt any message in any webpage such as: web forums, other web mail providers (yes even Yahoo Mail, Outlook.com, etc), or your custom internal SquirrelMail or Outlook Web Access instance, etc.
Its open source can be reviewed by third parties, it can be built and installed locally, with no dependency or trust placed in Google's online services. Heck, it can even be (in theory - I never tried) installed on Chromium if you are paranoid and don't trust the few non-open source parts of Chrome.
Google has made this a fucking nightmare. Every time you start Chrome, you get an annoying popup "do you really want to enable local extensions blah blah"
With the risk of sounding fanboy, this is really fantastic! This could actually be a viable, secure answer to mail encryption.
And this is aawesome too: "we have specifically expanded the scope of our Vulnerability Rewards Program to include End-To-End. This means that reports of exploitable security bugs within End-To-End are eligible for a reward."
This seems like a fantastic idea. We currently use Syncdocs [1] to encrypt our Google Drive folders. It is also end-to-end encryption, but it uses AES, not PGP, which means the key exchange is separate.
If the email is drafted online, do the drafts get deleted and wiped after encryption on the Gmail server?
Between all the build tools that are available -- one would think that'd they'd been able to settle on one (or at least supply a shell script) rather than having us cut and paste?
Still, that aside, really exited about this project.
Disappointed with the secondary support for RSA/DSA (ie: pretty much all existing keys) -- sadly Google never were very good at interop with others :-/
As I understand it, everyone not using this/gmail now have the option of not being able to communicate securely with the people that start using this; or running unsupported versions of GnuPG :-/ (Or trying to explain how to securely generate, export and import RSA/DSA keys into end-to-end -- somewhat defeating the whole usability benefit...)
This is basically just plain gpg+email done via a browser extension. So no protection of metadata (headers), no indexing of body (by upstream provider).
So if you have (potentially sensitive) information in the subject, you can search on that, and on to/from/cc etc -- but not on email body. Only way to achieve that securely, would be to have an encrypted index (that might be stored in an IMAP folder, encrypted) and decrypt and search it locally. At that point you are doing something rather different from what gmail is (currently) doing, however (I believe mailpile does something along those lines).
Google is not a privacy company. How can they show you context relevant ads if they can't read your email? So this will probably never happen within Google for political reasons.
But even for technical reasons, it's probably a ways off. Doing encrypted search is a whole other problem on top of encryption. You can't just apply standard search out of the box. Given that Google is just now unveiling an encryption solution, I would not expect GMail (or any google service) to release services built on top of them for a while, even if they wanted to (which they don't).
Unless you are doing hashing and comparing a specific value exactly (e.g. how you would securely store a password hash in a DB) there is no general purpose text indexing package that I know of.
Kudos to them for doing it even though it goes directly against their business model (mining your information). I guess they're betting that the vast majority of people won't use this.
This is Open Source and will get lots of peer review. Chrome isn't.
Is there any security advantage in End-to-End bring Open Source when Chrome isn't? To assume this is secure, you have to trust Google's software isn't vulnerable or compromised in any way.
Note: I guess this extension will run on Chromium too, which is Open Source.
Eleanor Saitta (@Dymaxion) had a few things to say about this on Twitter:
On the one hand, I'm happy Google is trying to make GPG usable within GMail: https://code.google.com/p/end-to-end/ . On the other hand, this leaves many ?s
It sounds like all you get from "end-to-end", other than a name that's going to cause horrible confusion, is a bare mininum of GPG functions.
No TOFU, no pushing users to encrypt by default, no better management of keys, no attempt to stop metadata surveillance.
It's good GMail users will have an easier time with GPG, but if it keeps them on a broken-by-architecture centralized service, we all lose.
This doesn't seem to go far enough in making crypto usable (no indexing solution, for instance) but it will slow development of alternatives.
I admit Google is kind of in a bind here - if they want to help GMail users, they're also necessarily slowing the evolution of a safe net.
Mostly I wish they hadn't called it "end-to-end". Because, you know, words mean things, and like "Off the record", that means something else.
I'm surprised Google weren't willing to spend the internal security resources on end-to-end to be able to stand behind it at time of release.
All told, it pretty much smells like "keep engineers happy" + "win points with the net freedom community as cheaply as possible."
Google, if they wanted to, could do some pretty revolutionary stuff in the secure comms space, but that would cost actual cash.
Ssh, no one wants to talk about how Silicon Valley business models depend on surveillance.
Nice. While they're at it, maybe they'll revive gpgAuth, so maybe we'll eventually have a sane and useable PKI-based auth on the web?
Oh, and maybe having PGP's WOT for use by the websites would be nice too. Could provide distributed "likes" by PGP-signing, without any central authorities.
A current real alternative that uses native binaries to avoid the JS issues is WebPG[1]. I've been using it for about a year and while it has its rough edges, it's a pretty solid tool (and approach).
Can anyone tell if this addon has been built in a suitably abstract enough manner such that the core can be used to build similar extensions for other browsers? I.e, would it be possible to take this code and wrap it in a Firefox extension?
I'm not entirely clear on why it's better that sicomail (potentially) has your unencrypted emails, than that google has them?
I've thought about setting up something similar as an incoming mail filter on my imap server; encrypting and signing unencrypted mail to myself -- just to have data at rest encrypted, and as a motivator for myself to use gpg more regularly -- but having a third party do it seems a little silly?
Could someone better across current cryptographic trends than I comment on that choice? We know the NSA has found weaknesses in certain implementations of elliptic-curve based cryptography in the past, and I was under the impression there was a preference in the community to move away from them in general given the unknown extent of the integrity concerns.
Looks like they're taking it seriously:
"Are End-To-End security bugs eligible for Google’s Vulnerability Rewards Program?
Yes, we have specifically expanded the scope of our Vulnerability Rewards Program to include End-To-End. This means that reports of exploitable security bugs within End-To-End are eligible for a reward."
Should be an interesting trove of JS tricks:
"JavaScript crypto has very real risk of side-channel attacks
Since JavaScript code doesn't control the instructions being executed by the CPU — the JavaScript engine can perform optimizations out of the code’s control — it creates the risk of security-sensitive information leaks. End-To-End requires user interaction for private operations in normal use, mitigating this risk. Non-user-interaction actions are rate-limited and done in fixed time. End-To-End’s crypto operations are performed in a different process from the web apps it interacts with. The End-To-End library is as timing-aware it can be and we’ve invested effort to mitigate any exploitable risk."