Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

End-To-End – OpenPGP Chrome extension from Google

code.google.com

Post reply on HN
Print view View original

31–40 of 173 posts

Re: End-To-End – OpenPGP Chrome extension from Google

#31

Post by res0nat0r »

nilved wrote: post #20
specialp wrote: post #12

Earlier quoted context omitted.

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…

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.

Re: End-To-End – OpenPGP Chrome extension from Google

#32

Post by declan »

DoubleMalt wrote: post #22
infogulch wrote: post #7

Earlier quoted context omitted.

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 localS…

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.

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.

Re: End-To-End – OpenPGP Chrome extension from Google

#33

Post by declan »

1345 wrote: post #26

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

Re: End-To-End – OpenPGP Chrome extension from Google

#34

Post by 1345 »

declan wrote: post #33
1345 wrote: post #26

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 star…

That sounds like NIH syndrome.

Re: End-To-End – OpenPGP Chrome extension from Google

#35

Post by mixedbit »

nilved wrote: post #10

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?

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.

Re: End-To-End – OpenPGP Chrome extension from Google

#36

Post by sroerick »

nilved wrote: post #20
specialp wrote: post #12

Earlier quoted context omitted.

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…

Well, they could just serve privacy ads to people who were encrypting their communication.

Re: End-To-End – OpenPGP Chrome extension from Google

#38

Post by dragonwriter »

orik wrote: post #14
dfc wrote: post #11

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?

Why would attachments be considered part of the body? Encrypt them before uploading them, and send the decrypting key in the body.

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

Re: End-To-End – OpenPGP Chrome extension from Google

#39

Post by declan »

1345 wrote: post #34
declan wrote: post #33

Earlier quoted context omitted.

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 star…

That sounds like NIH syndrome.

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... 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? :)

Re: End-To-End – OpenPGP Chrome extension from Google

#40

Post by mixedbit »

opendais wrote: post #4

"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.
Post reply on HN