Live data from Hacker News

End-To-End – OpenPGP Chrome extension from Google

code.google.com

101–110 of 173 posts

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

#101
post #32

Earlier quoted context omitted.

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…

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.

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

#102
post #95
post #92

Earlier quoted context omitted.

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

Hello, maybe a stupid question, but any reason why not use OpenPGP.js? Is it even worse for your case than SJCL?

Not a stupid question at all. We actually considered this option, but OpenPGP.js looked pretty bad back then.

Security-wise the library wasn't in good shape. One of our cryptographers would "classify [OpenPGP.js] as trash". It has been audited recently, but the result doesn't look very good either [1]. I don't know the current status though.

OpenPGP.js didn't actually implement most of the ciphers - it just imported them from various sources. This made the library inconsistent, i.e., some functions expect string, while others expect byte array, which in turn made it harder to use correctly in a language like Javascript. If we chose OpenPGP.js, we needed to change these ciphers anyway, so we thought it's just better to write them from scratch.

[1] https://cure53.de/pentest-report_openpgpjs.pdf.

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

#103

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

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

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

#104

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

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?

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

#105
post #39
post #34

Earlier quoted context omitted.

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

> Also, the account you're posting from was created 22 minutes ago and has done nothing but post criticisms of today's announcement. Coincidence? :)

Declan, nothing but respect for all your writings but he's got to make an account one day and if he's critical but otherwise polite and seems to be willing to concede the point why attack like that? It might be an account created specifically to protect a reputation. As far as I can see his concerns are valid and the answers are to the point. I'd rather see someone be extra critical when it comes to new crypto stuff than too lax.

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

#106
post #100

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

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

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

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

#107
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

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

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

#108
post #88
post #87

Earlier quoted context omitted.

SJCL does not support all of the primitives needed for OpenPGP.

I guess I should have been more clear. Why not add the primitives to SJCL and leverage an existing code base--a code base authored by someone who is considered to set a very high standard in crypto--instead of reinventing everything? Setting a higher standard than Prof. Boneh seems like a tough thing to do. Why not stand on Boneh et. al's shoulders?

It would be useful to have someone from Google elaborate on the summary they posted today. But I do recall that at least one of Prof. Boneh's postdocs mentioned in the original 2009 SJCL whitepaper is now at Google working on encryption...

[edit: Looks like that elaboration did happen elsewhere in the discussion -- just noticed it now.]

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

#110

With the risk of sounding fanboy, this is really fantastic! This could actually be a viable, secure answer to mail encryption. And this is aawesome too: "we have specifically expanded the scope of our Vulnerability Rewards Program to include End-To-End. This means that reports of exploitable security bugs within End-To-End are eligible for a reward."

This seems like a fantastic idea. We currently use Syncdocs [1] to encrypt our Google Drive folders. It is also end-to-end encryption, but it uses AES, not PGP, which means the key exchange is separate.

If the email is drafted online, do the drafts get deleted and wiped after encryption on the Gmail server?

[1] http://www.syncdocs.com/google-drive-encryption-faq/

Post reply on HN