Hacker News Reader

Comment by more_corn | Hacker News Reader

meh. This doesn't seem very interesting. What would be really interesting is gmail support for public key encryption. They're perfectly positioned to roll out a user-friendly key management system.

View on HN

Webmail struggles to offer security reassurances when utilising public key encryption. For example if Google allowed you to upload your private key and email would be transparently decrypted, that would be a great user experience, but now you have no way of knowing if the NSA/GCHQ/etc forced Google to give them your private key.

If you didn't upload your private key to Google now you need your browser to decrypt your message in-line but preventing the website with the encrypted version from stealing the resulting decrypted version from the secure container. So that requires every browser to add these secure containers, for content to be marked for decryption, and for key storage.

If you aren't worried about usability then you could just write a Word document, encrypt it and attach it to an unencrypted email. No browser support, or website support needed.

Yep surprised they haven't rolled one out yet. Ideally placed.

And by ideally placed, you mean for the NSA, right?

I'd never put any GPG keys of mine in an American cloud provider. That sort of voids the entire point of it.

More importantly, end-to-end encryption means that your desktop/laptop/tablet/phone/TI-83 is doing the crypto, especially signatures.

On a somewhat related note, I remember reading some documentation on a one-time password scheme, which I can't find anymore. It briefly mentioned something about using DES calculators to handle crypto signatures (for what reason i cannot remember). For our purposes, a PGP/GPG hand-held device would be neat, though perhaps cumbersome to actually user.

> phone/TI-83 is doing the crypto

Phone? Can we remotely trust nowadays smartphones not to have a number of backdoors?

I don't think that phones are secure, but people do use them for things like 2-factor authentication. I suppose that it is the form-factor that is more relevant, since most phones are smaller than a TI-83, so much so that people are willing to carry them around everywhere.

Ultimately, what I envision would be a cross between a Blackberry (size, QWERTY keyboard) and the TI-83 (focus on being a simpler, lower-end computer). Heck, one may as well give it a unix-like OS and leave out wireless communications and sophisticated graphics. I think this is feasible, but the market would be quite small.

Why do you believe non-American cloud providers aren't compromised?

In the short run, they're simply a smaller and more diverse attack surface. There's pretty valid "security through obscurity" reasoning to apply here (though that is, of course, not a train of thought one should bet the whole farm upon).

They've been working on a browser extension for it:

https://googleonlinesecurity.blogspot.com/2014/06/making-end...

https://github.com/google/end-to-end

I don't know what they might do in the future to encourage people to use this, or if they feel that there's a point at which it would be sensible or useful to actively promote it.

It's still not ready for production use. One problem with e2e is that it's JavaScript based and runs in he browser, so there is a certain attack vector present there. To defend against this, ideally e2e needs to work with a smartcard (such as the yubikey neo) so that the private key cannot be stolen.

There was an issue I was tracking a while back to integrate this support, but it's still a work in progress.

It doesn't even need the hardware part in most cases. OS keyrings support pkcs11 interface with signing exposed. That means you can just send data to be encrypted for example by gnome-keyring and the browser never sees the actual key.

But e2e doesn't use the OS keyring. It uses it's own JavaScript keyring that runs in the browser and uses localstorage for storing private keys.

> Yep surprised they haven't rolled one out yet. Ideally placed.

In fact, they will fight tooth and nail against it since their business model relies on having access to the plain text of the message. It's the very reason they are releasing this technology: a user sees a padlock icon that's confusing similar to other "encrypted" mail offerings, for example OpenPGP. For Google, it's essential that end-to-end encryption does not become the norm and that plain text emails are kept inside their walled garden.

That being said, as a form of opportunistic encryption, TLS on the SMTP layer is great and there are really no excuses not to use it in 2016. Google could push it aggressively and add an (user optional) delay against servers that try to deliver email over a plain connection: "472 Try again in 30 sec or use STARTTLS"

How would I search my encrypted inbox? Either Google knows my private key, in which case this doesn't seem to buy us anything, or I can't search.

I search a lot.

With encrypted indexes maintained on the client end. Web search is a complex problem, but searching a single user's mailbox is child's play, you don't need Google for that. Client end processing could work for advertising too, but at that point you have an information leak that severely weakens security, the client will ask for adds relevant to terms found in the message.

Reply on news.ycombinator.com