End-To-End – OpenPGP Chrome extension from Google
code.google.com
code.google.com
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."
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.
Chrome’s design means that extensions should be safe against
other extensions.
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.[edit: Looks like that elaboration did happen elsewhere in the discussion -- just noticed it now.]
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.
maybe a stupid question, but any reason why not use OpenPGP.js?
Is it even worse for your case than SJCL?
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 considered using OpenPGP.js in one project, I didn't go so deep though. Thanks for the information.
We also fixed all critical, high and medium issue: https://github.com/openpgpjs/openpgpjs/wiki/Cure53-security-...
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
Thanks
> What are your plans in regards to web crypto?
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.
> 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?
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.
PS: how can I contact you?
[1] https://github.com/indutny/elliptic/blob/master/lib/elliptic...
PS: were you the guy that won the CloudFlare's HeartBleed challenge? great work :-).
Thank you!
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.
What you can do instead is to pick the right hash based on the curve, like what we did in End-To-End: https://code.google.com/p/end-to-end/source/browse/javascrip....
s/infamous/famous.
* Officially hosted on GitHub (or at least official mirror)
* Bower and NPM packet management
* Common.js modules for Node
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.
EDIT: Maybe the other guy is right and you didn't mean baking it into the browser. xD
Maybe there could be some new extension permission for "encryption extension" or something, but it's possible that could be abused...
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.
edit: It seems that the keybase website does not like messages created by this extension. https://github.com/keybase/keybase-issues/issues/752
In your testing, do you see any evidence that this extension prevents Gmail's automatic draft saving?
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:
https://code.google.com/p/end-to-end/source/browse/javascrip...
[1] https://www.pwdhash.com/ [2] https://code.google.com/p/chrome-pwdhash/
There was an issue with the html copy step because of the -t option, fixed that and submitted an issue.
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).
Pointers to the proper forum to talk about this appreciated.
I don't have further comment for now, but we hear you :) > Only the body of the message. Please note that, as with all OpenPGP
> messages, the email subject line and list of recipients remain
> unencrypted.
Encrypt them before uploading them, and send the decrypting key in the body.
But Gmail itself may handle attachments differently.
AFAIK, Gmail handles attachments the same.
Because if you look at the low-level structure of email, "attachments" are just parts of a body that is in multipart/mixed MIME type.
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.
[0] http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
[1] http://msdn.microsoft.com/en-us/library/ms526560(v=exchg.10)...
I'm not saying that End-To-End does this, just that it is perfectly possible (and common) to encrypt the whole message.
H
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.
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.
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.
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,.
EDIT: NSA Smiley Face [http://theweek.com/article/index/252034/why-google-isnt-too-...]
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%.
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
Geeks email non-geeks. If the non-geeks don't decrypt the messages it's going to be all greek to them.
So the more easy they make it for geeks, the more they are pushing non-geeks to adopt as well.
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."
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.
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..."
Especially post-Snowden, Google is taking this very seriously. See these posts, for instance, about TLS weaknesses and implementation of ChaCha20 and Poly1305 in OpenSSL -- a non-trivial task: http://googleonlinesecurity.blogspot.com/2013/11/a-roster-of... http://googleonlinesecurity.blogspot.com/2014/04/speeding-up...
Also, the account you're posting from was created 22 minutes ago and has done nothing but post criticisms of today's announcement. Coincidence? :)
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.
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.
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.
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.
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.
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.
There's nothing that says Google can't bundle the extension with Chrome, and require Chrome or the extension on Firefox to use encrypted Gmail.
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"
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."
If the email is drafted online, do the drafts get deleted and wiped after encryption on the Gmail server?
https://code.google.com/p/end-to-end/wiki/BuildInstructions
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...)
Will GMail be able to find those encrypted e-mails when I search for them?
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.
There is some academic momentum on encrypted search: http://www.cs.berkeley.edu/~dawnsong/papers/se.pdf
Well... they are and they aren't.
Google has a real interest in protecting the privacy of their users from anybody but Google.
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).
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.
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.
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.
There is mentions of using Closure which is a google JavaScript technology. I think however it is cross browser.
Has anyone been able to tell how they protect against the server grabbing the plaintext after it's been decrypted?
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?
No thanks.
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.
No, we don't.
Even djb wants people to use ECC. Note that End-To-End supports not only NIST's curves but also djb's.