Live data from Hacker News

End-To-End – OpenPGP Chrome extension from Google

code.google.com

141–150 of 173 posts

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

#141
post #20

Earlier quoted context omitted.

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

Advertise tinfoil?

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

#142
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…

IIRC, openpgp.js is what both Lavaboom and Protonmail use.

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

#143
post #61
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?

It depends on whether they use PGP/MIME or inline PGP. Without installing the tool, I'm guessing they use PGP/MIME, because you pretty much can't use html email with inline PGP, and I doubt they're going to default to plain/text mails.

For this to be able to send PGP/MIME emails, the webmail service would have to allow the client to uploaded a body which is not tampered with at all, and also to specify the mime type of the email. That way, you could upload a pre-built MIME structure to be used as the body, generated by the OpenPGP extension, which includes the encryted attachments.

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.

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

#146

Earlier quoted context omitted.

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?

Sure, the extension can read the encrypted text from the DOM. But it then displays it in an iframe which the original site doesn't have access to.

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

#147
post #132

Earlier quoted context omitted.

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

How about BEAST or CRIME?

BEAST is a design bug, insecure use of CBC mode. CRIME is a side channel attack, but the side channel that leaks information (compressed cleartext size) is not related to the language used, but again to the design of the algorithm.

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.

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

#149

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?

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.

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

#150

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

On which platform did you build it? On Windows (via cygwin) I'm getting compilation errors from bootstrap.js.

Pointers to the proper forum to talk about this appreciated.

Post reply on HN