12 ms·

End-To-End – OpenPGP Chrome extension from Google

509 points by gbarboza 12y ago

DoubleMalt 12y ago
This is really great news. But even better would it be if they'd incorporate it directly in gmail with a polished user interface.
- infogulch 12y ago
  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.
  - DoubleMalt 12y ago
    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 12y ago
      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.
    - lambada 12y ago
      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).
    - declan 12y ago
      <infogulch> is correct. I wrote about this in 2007: http://news.cnet.com/Will-security-firms-detect-police-spyware---page-2/2100-7348_3-6197020-2.html 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.
      - hifier 12y ago
        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.
        declan 12y ago
        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.
        hifier 12y ago
  - fragmede 12y ago
    It would be better. 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.
- mrb 12y ago
  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.
  - mschuster91 12y ago
    > it can be built and installed locally 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"
- deleted 12y ago
  [deleted]
spacefight 12y ago
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...
opendais 12y ago
"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.
- spacefight 12y ago
  That makes it largely unusable even to test for a few users, I guess.
  - nobodysfool 12y ago
    simple, just turn that feature off.
    - bildeman 12y ago
      If you wanted this to be available for the general public then it could be slightly more troublesome.
      - opendais 12y ago
        Yes, but as long as it is clearly mentioned by the Install button in big, bold letters it isn't a problem.
  - danielweber 12y ago
    If you are testing you are not mailing about nuclear secrets.
- tlrobinson 12y ago
  Does this also mean parts of memory containing, say, passwords could be send to Google?
  - 12y ago
tigerweeds 12y ago
how is this different from Mailvelope?
nilved 12y ago
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?
- specialp 12y ago
  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.
  - nilved 12y ago
    "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.)
    - res0nat0r 12y ago
      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.
      - 6cxs2hd6 12y ago
        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.
dfc 12y ago
The FAQ states: > Only the body of the message. Please note that, as with all OpenPGP > messages, the email subject line and list of recipients remain > unencrypted. Hopefully attachments are considered part of the body?
- orik 12y ago
  Why would attachments be considered part of the body? Encrypt them before uploading them, and send the decrypting key in the body.
  - tlrobinson 12y ago
    Because as far as the email protocol is concerned attachments are part of the body, just wrapped in a multipart MIME message along with text body. But Gmail itself may handle attachments differently.
    - john2x 12y ago
      > But Gmail itself may handle attachments differently. AFAIK, Gmail handles attachments the same.
      - tlrobinson 12y ago
        When it sends them, yes, but this is more what I was referring to: https://news.ycombinator.com/item?id=7842868 https://news.ycombinator.com/item?id=7842868
  - veeti 12y ago
    Any decent PGP plugin encrypts the attachments.
  - dragonwriter 12y ago
    > Why would attachments be considered part of the body? 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.
1345 12y ago
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.
- declan 12y ago
  Google's posting today addresses this point, I think: https://code.google.com/p/end-to-end/ 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..."
  - 1345 12y ago
    That sounds like NIH syndrome.
    - declan 12y ago
      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. 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-tls-cipher-suites-weaknesses.html http://googleonlinesecurity.blogspot.com/2013/11/a-roster-of... http://googleonlinesecurity.blogspot.com/2014/04/speeding-up-and-strengthening-https.html 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? :)
higherpurpose 12y ago
It doesn't support only NIST curves, does it?
- cryptbe 12y ago
  It supports Curve25519 and Ed25519: https://code.google.com/p/end-to-end/source/browse/javascript/crypto/e2e/ecc/curve_curve25519.js https://code.google.com/p/end-to-end/source/browse/javascrip... and https://code.google.com/p/end-to-end/source/browse/javascript/crypto/e2e/ecc/curve_ed25519.js https://code.google.com/p/end-to-end/source/browse/javascrip...
unbehagen 12y ago
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?
- opendais 12y ago
  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.
- davelesser 12y ago
  This scenario has been reported to Google as a "bug". Google's response, as of the time of this writing, is: I don't have further comment for now, but we hear you :)
riquito 12y ago
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.
makomk 12y ago
"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.
- zeroxfe 12y ago
  "We’re releasing this code to enable community review; it is not yet ready for general use."
  - makomk 12y ago
    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.
    - cbhl 12y ago
      s/causes/solves/
- brianmwaters_hn 12y ago
  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.
  - rca 12y ago
    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/javascript/crypto/e2e/cipher/rsa.js 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)
tokenizerrr 12y ago
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. edit: It seems that the keybase website does not like messages created by this extension. https://github.com/keybase/keybase-issues/issues/752 https://github.com/keybase/keybase-issues/issues/752
- mapgrep 12y ago
  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?
  - magicalist 12y ago
    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: https://code.google.com/p/end-to-end/source/browse/javascript/crypto/e2e/extension/ui/glass/glasswrapper.js#68 https://code.google.com/p/end-to-end/source/browse/javascrip...
    - mapgrep 12y ago
      Nice find!
panarky 12y ago
Regarding JavaScript crypto: 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.
- dfc 12y ago
  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?
  - 1345 12y ago
    SJCL does not support all of the primitives needed for OpenPGP.
    - dfc 12y ago
      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?
      - declan 12y ago
        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.]
  - cryptbe 12y ago
    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.
josephby 12y ago
Someone should try using it with this: http://sicomail.com; http://sicomail.com; automatically encrypts all of your incoming email.
- e12e 12y ago
  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?
dotBen 12y ago
So End-To-End utilizes Elliptic Curve-based keys 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.
- cryptbe 12y ago
  > We know the NSA has found weaknesses in certain implementations of elliptic-curve based cryptography in the past 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.
mindstab 12y ago
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/ 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. https://twitter.com/Dymaxion https://twitter.com/Dymaxion
- deleted 12y ago
  [deleted]
zx2c4 12y ago
Notable aspects -- 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."
- letstryagain 12y ago
  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.
  - DSingularity 12y ago
    Why do you say this? I dont think all side channel attack surfaces require local access to the machine.
    - letstryagain 12y ago
      Can you give me an example that would be relevant here?
      - brianmwaters_hn 12y ago
        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 :)
thomasahle 12y ago
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."
- CPAhem 12y ago
  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? [1] http://www.syncdocs.com/google-drive-encryption-faq/ http://www.syncdocs.com/google-drive-encryption-faq/
adrianlmm 12y ago
What about search and indexing? Will GMail be able to find those encrypted e-mails when I search for them?
- notatoad 12y ago
  no. that would completely defeat the purpose. the subject line remains plain text though.
- ikawe 12y ago
  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. There is some academic momentum on encrypted search: http://www.cs.berkeley.edu/~dawnsong/papers/se.pdf http://www.cs.berkeley.edu/~dawnsong/papers/se.pdf
  - jacquesm 12y ago
    > Google is not a privacy company. Well... they are and they aren't. Google has a real interest in protecting the privacy of their users from anybody but Google.
- e12e 12y ago
  No. (This from just reading the comments here). 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).
moeedm 12y ago
Encryption. Google. Okay. No thanks.
e12e 12y ago
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? https://code.google.com/p/end-to-end/wiki/BuildInstructions 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...)
cvwright 12y ago
Very cool! I'm assuming this is not just for sending PGP mail, but also for decrypting PGP-encrypted mail that the user receives. Has anyone been able to tell how they protect against the server grabbing the plaintext after it's been decrypted?
zobzu 12y ago
itd be cool to have this like http://www.monkeysphere.info/ http://www.monkeysphere.info/ between browser and server, and not rely on CAs.
plg 12y ago
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.
donniezazen 12y ago
What is the difference between GnuPG and OpenPGP?
- zvrba 12y ago
  OpenPGP is a standard, GnuPG is one implementation of it.
- deleted 12y ago
  [deleted]
mentat 12y ago
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). 1. https://webpg.org/ https://webpg.org/
haarts 12y ago
If you want to build the extension and your aliases don't work add "shopt -s expand_aliases" to the compile.sh file.
dave1010uk 12y ago
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.
mike-cardwell 12y ago
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?
- reitanqild 12y ago
  Seeing that you haven't got a reply in three hours here's what I found: There is mentions of using Closure which is a google JavaScript technology. I think however it is cross browser.
- sirdarckcat 12y ago
  The core library is in use in many Google products and runs across all browsers.
diasp 12y ago
Take a look at http://openpgpjs.org/ http://openpgpjs.org/ OpenPGP JavaScript Implementation.
drdaeman 12y ago
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.
mox1 12y ago
I worked at a company who has a very similar product, https://www.penango.com/products/penango-for-webmail https://www.penango.com/products/penango-for-webmail

509 points by gbarboza 12y ago

This is really great news. But even better would it be if they'd incorporate it directly in gmail with a polished user interface.

infogulch 12y ago
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.
- DoubleMalt 12y ago
  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 12y ago
    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.
  - lambada 12y ago
    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).
  - declan 12y ago
    <infogulch> is correct. I wrote about this in 2007: http://news.cnet.com/Will-security-firms-detect-police-spyware---page-2/2100-7348_3-6197020-2.html 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.
    - hifier 12y ago
      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.
      - declan 12y ago
        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.
        hifier 12y ago
- fragmede 12y ago
  It would be better. 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.
mrb 12y ago
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.
- mschuster91 12y ago
  > it can be built and installed locally 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"
deleted 12y ago
[deleted]

spacefight 12y ago

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

opendais 12y ago

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

spacefight 12y ago
That makes it largely unusable even to test for a few users, I guess.
- nobodysfool 12y ago
  simple, just turn that feature off.
  - bildeman 12y ago
    If you wanted this to be available for the general public then it could be slightly more troublesome.
    - opendais 12y ago
      Yes, but as long as it is clearly mentioned by the Install button in big, bold letters it isn't a problem.
- danielweber 12y ago
  If you are testing you are not mailing about nuclear secrets.
tlrobinson 12y ago
Does this also mean parts of memory containing, say, passwords could be send to Google?
- 12y ago

tigerweeds 12y ago

how is this different from Mailvelope?

nilved 12y ago

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?

specialp 12y ago
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.
- nilved 12y ago
  "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.)
  - res0nat0r 12y ago
    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.
    - 6cxs2hd6 12y ago
      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.

dfc 12y ago

The FAQ states: > Only the body of the message. Please note that, as with all OpenPGP > messages, the email subject line and list of recipients remain > unencrypted. Hopefully attachments are considered part of the body?

orik 12y ago
Why would attachments be considered part of the body? Encrypt them before uploading them, and send the decrypting key in the body.
- tlrobinson 12y ago
  Because as far as the email protocol is concerned attachments are part of the body, just wrapped in a multipart MIME message along with text body. But Gmail itself may handle attachments differently.
  - john2x 12y ago
    > But Gmail itself may handle attachments differently. AFAIK, Gmail handles attachments the same.
    - tlrobinson 12y ago
      When it sends them, yes, but this is more what I was referring to: https://news.ycombinator.com/item?id=7842868 https://news.ycombinator.com/item?id=7842868
- veeti 12y ago
  Any decent PGP plugin encrypts the attachments.
- dragonwriter 12y ago
  > Why would attachments be considered part of the body? 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.

1345 12y ago

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.

declan 12y ago
Google's posting today addresses this point, I think: https://code.google.com/p/end-to-end/ 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..."
- 1345 12y ago
  That sounds like NIH syndrome.
  - declan 12y ago
    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. 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-tls-cipher-suites-weaknesses.html http://googleonlinesecurity.blogspot.com/2013/11/a-roster-of... http://googleonlinesecurity.blogspot.com/2014/04/speeding-up-and-strengthening-https.html 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? :)

higherpurpose 12y ago

It doesn't support only NIST curves, does it?

cryptbe 12y ago
It supports Curve25519 and Ed25519: https://code.google.com/p/end-to-end/source/browse/javascript/crypto/e2e/ecc/curve_curve25519.js https://code.google.com/p/end-to-end/source/browse/javascrip... and https://code.google.com/p/end-to-end/source/browse/javascript/crypto/e2e/ecc/curve_ed25519.js https://code.google.com/p/end-to-end/source/browse/javascrip...

unbehagen 12y ago

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?

opendais 12y ago
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.
davelesser 12y ago
This scenario has been reported to Google as a "bug". Google's response, as of the time of this writing, is: I don't have further comment for now, but we hear you :)

riquito 12y ago

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.

makomk 12y ago

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

zeroxfe 12y ago
"We’re releasing this code to enable community review; it is not yet ready for general use."
- makomk 12y ago
  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.
  - cbhl 12y ago
    s/causes/solves/
brianmwaters_hn 12y ago
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.
- rca 12y ago
  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/javascript/crypto/e2e/cipher/rsa.js 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)

tokenizerrr 12y ago

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. edit: It seems that the keybase website does not like messages created by this extension. https://github.com/keybase/keybase-issues/issues/752 https://github.com/keybase/keybase-issues/issues/752

mapgrep 12y ago
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?
- magicalist 12y ago
  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: https://code.google.com/p/end-to-end/source/browse/javascript/crypto/e2e/extension/ui/glass/glasswrapper.js#68 https://code.google.com/p/end-to-end/source/browse/javascrip...
  - mapgrep 12y ago
    Nice find!

panarky 12y ago

Regarding JavaScript crypto: 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.

dfc 12y ago
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?
- 1345 12y ago
  SJCL does not support all of the primitives needed for OpenPGP.
  - dfc 12y ago
    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?
    - declan 12y ago
      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.]
- cryptbe 12y ago
  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.

josephby 12y ago

Someone should try using it with this: http://sicomail.com; http://sicomail.com; automatically encrypts all of your incoming email.

e12e 12y ago
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?

dotBen 12y ago

So End-To-End utilizes Elliptic Curve-based keys 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.

cryptbe 12y ago
> We know the NSA has found weaknesses in certain implementations of elliptic-curve based cryptography in the past 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.

mindstab 12y ago

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/ 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. https://twitter.com/Dymaxion https://twitter.com/Dymaxion

deleted 12y ago
[deleted]

zx2c4 12y ago

Notable aspects -- 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."

letstryagain 12y ago
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.
- DSingularity 12y ago
  Why do you say this? I dont think all side channel attack surfaces require local access to the machine.
  - letstryagain 12y ago
    Can you give me an example that would be relevant here?
    - brianmwaters_hn 12y ago
      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 :)

thomasahle 12y ago

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

CPAhem 12y ago
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? [1] http://www.syncdocs.com/google-drive-encryption-faq/ http://www.syncdocs.com/google-drive-encryption-faq/

adrianlmm 12y ago

What about search and indexing? Will GMail be able to find those encrypted e-mails when I search for them?

notatoad 12y ago
no. that would completely defeat the purpose. the subject line remains plain text though.
ikawe 12y ago
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. There is some academic momentum on encrypted search: http://www.cs.berkeley.edu/~dawnsong/papers/se.pdf http://www.cs.berkeley.edu/~dawnsong/papers/se.pdf
- jacquesm 12y ago
  > Google is not a privacy company. Well... they are and they aren't. Google has a real interest in protecting the privacy of their users from anybody but Google.
e12e 12y ago
No. (This from just reading the comments here). 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).

moeedm 12y ago

Encryption. Google. Okay. No thanks.

e12e 12y ago

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? https://code.google.com/p/end-to-end/wiki/BuildInstructions 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...)

cvwright 12y ago

Very cool! I'm assuming this is not just for sending PGP mail, but also for decrypting PGP-encrypted mail that the user receives. Has anyone been able to tell how they protect against the server grabbing the plaintext after it's been decrypted?

zobzu 12y ago

itd be cool to have this like http://www.monkeysphere.info/ http://www.monkeysphere.info/ between browser and server, and not rely on CAs.

plg 12y ago

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.

donniezazen 12y ago

What is the difference between GnuPG and OpenPGP?

zvrba 12y ago
OpenPGP is a standard, GnuPG is one implementation of it.
deleted 12y ago
[deleted]

mentat 12y ago

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). 1. https://webpg.org/ https://webpg.org/

haarts 12y ago

If you want to build the extension and your aliases don't work add "shopt -s expand_aliases" to the compile.sh file.

dave1010uk 12y ago

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.

mike-cardwell 12y ago

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?

reitanqild 12y ago
Seeing that you haven't got a reply in three hours here's what I found: There is mentions of using Closure which is a google JavaScript technology. I think however it is cross browser.
sirdarckcat 12y ago
The core library is in use in many Google products and runs across all browsers.

diasp 12y ago

Take a look at http://openpgpjs.org/ http://openpgpjs.org/ OpenPGP JavaScript Implementation.

drdaeman 12y ago

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.

mox1 12y ago

I worked at a company who has a very similar product, https://www.penango.com/products/penango-for-webmail https://www.penango.com/products/penango-for-webmail