Ask HN: Why doesn't someone provide JS encrypted webmail

Of course some super-companies might require encrypted mail, but that might not be a good enough use case to base a business on.

Technically I think a purely passphrase-encrypted webmail would not be very secure, because if you used an asymmetric algorithm, the private keys would no longer be private, and if you used a symmetric algorithm you'd either have to change the pass-phrase each time or deal with a key-vulnerability. But I might be wrong.

Finally the demand could probably be created if it were implemented in a user-friendly way. I think it has to, somehow, eventually. It will not be difficult to convince people to use it once it works in a simple, transparent way. After all, everyone got used to logging in everywhere, as well.

In the long run, now matter how cool clients like GMail are, we should not leave our private communication to others and especially not to companies.

Perhaps it requires a person similar to Mark Shuttleworth with a lot of resources and a philantropic drive to start thinking about a solution.

edit: complemented with a web-service storing your keys in the 'cloud'.

Is that what you mean ?

Edit: Oh, you mean we never know the plaintext of the email.

You mean like this : http://www.hanewin.net/encrypt/

http://46dogs.blogspot.com/2007/11/encrypting-to-pgp-gnupg-g...

http://stackoverflow.com/questions/2802541/pgp-encryption-in...

tl;dr - too slow

Then there's the question, which someone alluded to, of how to distribute new credentials to a browser that hasn't logged on before, and how to make sure they're deleted securely after I leave. Do you store the private keys encrypted and send them to the browser so they can be decrypted with my passphrase? I probably don't trust you to store even an encrypted version of my private keys, but I guess I can use a throwaway key for your service.

What I'm most worried about is the question: who is doing the encrypting? Are people sending mail to this address required to encrypt email to me? If not, are you going to encrypt my email as soon as it hits your servers? Not good enough, you may as well leave it in plaintext and use it to serve me ads.

The biggest problem with encrypted email today is that nobody uses it, and this doesn't fix that. It makes it easier (if it works, and I'm still not convinced it does) for people who already use it to do so, but it doesn't convince people that don't use the service (which is going to be a vast percentage of the people that don't use pgp now) that they should want encrypted mail.

(Typing their passphrase into the hoster's provided JS/DOM, even in a browser under their own control, is essentially the same as sending it to their server. Maybe you could work out something with a bookmarklet, which scrapes ciphertext from one page but then displays the plaintext in another window entirely, but at that point, are you still enjoying the convenience of webmail?)

Also, the number of people who even know what you're talking about is vanishingly small, and few of them would pay.

The issue of JavaScript being manipulated by the operator to steal your passphrase/key is tricky, as mentioned by others. You might be able to do the crypto part in a separate scripting context via code stored in HTML5 local storage after you've reviewed it once, and using window.postMessage() in some way? The plaintext could be displayed in an IFrame running in that local context.

Then there's the issue of unencrypted incoming mail. You'd need to trust the SMTP server operator to encrypt any incoming mail with your public key and then destroy any record of the plaintext.

Metadata is also an issue: you'd want to encrypt headers as well as the body, as knowing when you communicate with whom is almost as valuable as knowing the content of said communication. Encrypting it is easy, indexing it for efficient access less so.

Still, this could exist as a self-hosted package for the more paranoid as well as SaaS.

Think about this: if encryption/decryption is performed client-side (JavaScript), then any cross-site scripting (XSS) or cross-site request forgery (CSRF) could potentially leak sensitive information to an attacker. (Where are private keys stored? How can Javascript prevent client-side attacks from leaking keys/passphrases?)

That said, client-side hashing and sending of passphrases is not a new concept. This HN post (http://news.ycombinator.com/item?id=1750468) from a few days ago goes over some of the intricacies and possible security implications of client-side hashing.

As far as actual client-side crypto (meaning the algorithm itself): Javascript is simply too prone to tampering. The problem is that, let's say the user is phished or man-in-the-middled. They will then implement (edited and flawed) crypto that will appear to them to be genuine, while in fact their passphrase and ciphertext were probably just leaked all over the Russian hacker underground.

Now, I'm not saying that it's impossible to implement client-side crypto or even that those that do will immediately get hacked... I just think this is why someone hasn't really provided it as a service yet.

Oh, and one more thing--if it's client-side encrypted email, how does the plaintext get from the email server to the client? Over the web in plaintext or HTTPS?

First: browser Javascript is the most hostile possible environment in which to implement cryptography. From actual experience: you are better off trying to implement crypto in a microcontroller, with kilobyte-denominated space for code storage, no cold-start entropy, and a few tens of bytes headroom for negotiation. Seriously: do that first, before trying (and inevitably failing) to run the Javascript gauntlet[1].

Second: the security economics of mail drastically favor Google over anything you come up with, even if you're really good. That's because the cost of a sitewide compromise at Google is stratospheric. Google is maximally incented to protect their service and has the resources and mindshare to do so. Nobody cares about someone else's bespoke mail service. People who care about mail security but don't trust Google just VPN to a private mail server.

Incidentally, Fortune 500 companies grappled with this problem many moons ago, and have adopted the strategy of "things that need to be sent over secure email will instead send links to an HTTPS web application we run onsite and call 'secure email' even though it's really just 'private file sharing'". Which makes it doubly hard to pitch this as a product idea: most of your market has already rejected the model you're considering.

This is a bad startup idea. Avoid it.

[1] For starters: in browser JS, every function call can be redefined arbitrarily many times before it gets key material, web content is allowed to influence or even rewrite that code, there's no effective way to verify code before running it, code is pulled from multiple sites, there are browser "chrome"-level security flaws still being discovered, there's no solid secure random number generation, functions are timeable, there are solid implementations of only a very few algorithms, and what remains to be implement is hazard-prone. Writing crypto code in JS is hubris, pure and simple.

Recently, I have pitched the idea to few people both in angel community and some of my friends and tc disrupt visitor friends that I met. As few users have mentioned in the comments, it really boils down to people having awareness. People who are familiar with the encryption see the value immediately and people with no knowledge start to question why they need security. I have decided to go release the product. It is encouraging to see someone really cares about this stuff.

When I saw the gmail/china hacking fiasco, it is so much frustrating to see how dumb found we as users are left even though matured standards (rfc822, SMIME, OpenPGP)exist. Hopefully, what I am working would solve the exact issue we have been facing and no one is working on this non sexy item.

On the technical/details side, not just encrypting the text, it is more important to encrypt the whole message including attachments. Rightnow I have the prototype which works for text message and trying to expand it to cover attachments. The problem with FireGPG or few other things that I tried include how painful it is to setup and maintain - I also think, that being the reason for not getting popularity. There are already quite a few libraries for RSA, AES, HMAC(pick your language of choice). Implementing the plugin with Javascript has serious performance and security (good luck supporting OpenPGP). So core items need to be implemented in compiled language - for me they are in C/C++. I would love to share more details about the core crypto stuff if you want to.

edit: doesn't have to be about email either - the need is first and foremost. it could be well just a private messenger platform.