Live data from Hacker News

End-To-End – OpenPGP Chrome extension from Google

code.google.com

131–140 of 173 posts

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

#132

Earlier quoted context omitted.

Why do you say this? I dont think all side channel attack surfaces require local access to the machine.

Can you give me an example that would be relevant here?

How about BEAST or CRIME?

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

#134
post #66

Earlier quoted context omitted.

But as I'm typing, Gmail is saving my draft automatically to Google servers. Normally, at least. This means Google would have a copy of my email as it existed before I encrypted it. In your testing, do you see any evidence that this extension prevents Gmail's automatic draft saving?

In the FAQ they mention "End-To-End doesn’t trust any website's DOM or context with unencrypted data. We have tried to ensure that the interaction between the extension and websites is minimal and does not reveal secrets to the website." I'm curious about this too. Does that mean they somehow insert a textbox that the host page can't see? I didn't realize extensions could do that. Edit: ah, this appears to be where i…

But when displaying the cleartext of a previously sent email or received email... they must be able to decipher the encrypted text in order to display it to the viewer, no?

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

#135
post #95

Earlier quoted context omitted.

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…

Thanks.

I considered using OpenPGP.js in one project, I didn't go so deep though. Thanks for the information.

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

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

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

#138
post #95

Earlier quoted context omitted.

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…

I'm a contributor to OpenPGP.js. I understand your choice as the code was indeed in quite bad shape several months ago. I do want to point out though, that the code has gone through a big refactoring an cleanup since then: https://github.com/openpgpjs/openpgpjs/releases

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

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

#139

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?

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 :)
Post reply on HN