There are two very good reasons why nobody should bother doing this. 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…
Not that I have any interest in this as a startup idea, but could the issues with Javascript be avoid by using Flash instead?
So basically, you'd be taking all the security obstacles of browser Javascript, and adding to them: having two Javascript interpreters to worry about, having an additional set of interfaces to secure (between the browser and the plugin), and never being entirely sure of what the attack surface for the Flash plugin is, since it's closed-source.
I have been working on this for few months now. It is a CR/FF/SF browser extension which should work with gmail/yahoomail/hotmail. Please get in touch with me if you like to be notified - skommoori (at) gmail.com 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…
When you talk about "RSA, AES, HMAC", you leave me to wonder whether you're actually implementing a standard like PGP or S/MIME, or whether you've invented your own encryption scheme. I hope for your sake it's former, and not the latter. Know that most large companies do use encrypted mail, and have a standard that their partners must use.
It's hard to implement securely. 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…
I don't know why anyone would have downvoted this comment; clientside hashing is also bad, and CSRF isn't really the dealbreaker that XSS is, but it's a decent survey of the issues.
Not that I have any interest in this as a startup idea, but could the issues with Javascript be avoid by using Flash instead?
So basically, you'd be taking all the security obstacles of browser Javascript, and adding to them: having two Javascript interpreters to worry about, having an additional set of interfaces to secure (between the browser and the plugin), and never being entirely sure of what the attack surface for the Flash plugin is, since it's closed-source. No, probably not a win.
I have been working on this for few months now. It is a CR/FF/SF browser extension which should work with gmail/yahoomail/hotmail. Please get in touch with me if you like to be notified - skommoori (at) gmail.com 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…
When you talk about "RSA, AES, HMAC", you leave me to wonder whether you're actually implementing a standard like PGP or S/MIME, or whether you've invented your own encryption scheme. I hope for your sake it's former, and not the latter. Know that most large companies do use encrypted mail, and have a standard that their partners must use.
Yes. I am going to support OpenPGP. As you said, inventing own encryption is not a smart thing to do.
Because if you're actually concerned about the privacy and security of your messages then webmail ain't ever gonna cut it.
I don't care at all about the privacy and security of the already encrypted and signed blobs that I would be sending to webmail, in this hypothetical scenario. Why would I? They're already encrypted and signed. The trick is getting encrypted webmail that's actually secure, without also being so hard to use that almost nobody actually does it.
It would be trivial for anyone with access to the webmail provider's server to steal your password and decrypt your mail. So you don't really gain much by having it encrypted there in the first place.
You can start a new startup from technology or from a market need. Start with market first, the question you should be asking is "who needs to communicate privately, wants to pay for it, and was not able to do that so far in a satisfactory manner?". Once you figure it out you might realize that most of the "it's impossible to do perfect, hence no point in doing it at all" concerns while generally valid do not apply to your target market. And from there it's perfectly doable and might be a good business too.
edit: doesn't have to be about email either - the need is first and foremost. it could be well just a private messenger platform.
I don't care at all about the privacy and security of the already encrypted and signed blobs that I would be sending to webmail, in this hypothetical scenario. Why would I? They're already encrypted and signed. The trick is getting encrypted webmail that's actually secure, without also being so hard to use that almost nobody actually does it.
It would be trivial for anyone with access to the webmail provider's server to steal your password and decrypt your mail. So you don't really gain much by having it encrypted there in the first place.
I was assuming that my private key would be stored locally. And the encryption code, too. As I said, doing this securely and usably would be hard.
I have been working on this for few months now. It is a CR/FF/SF browser extension which should work with gmail/yahoomail/hotmail. Please get in touch with me if you like to be notified - skommoori (at) gmail.com 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…
Great to know someone is working on it. If it is in C/C++, the user has to download a program, and it is not simple webmail. Secondly, what about the private keys? Do we have to remember them? The reason pgp has not caught on for most people is because we dont want to go through a complicated mail client installation. If your solution is simpler/easier to install, that's a plus. However, I should be able to access my secure mail through computers not my own. Is your compiled solution open source or can it be certified secure? i.e., that it is not sending the unencrypted private key or passphrase to some backdoor? These are all issues to keep in mind. Would love to see your product. Good luck!
There are two very good reasons why nobody should bother doing this. 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…
I'm not worried about Google being compromised by a third party. I believe my mail host should not be able to read my email. VPN to a private mail server is good, but I dont want to have to trust the mailserver. It might be a bad startup idea if you expect people to pay you 5 bucks a month for an account (may be). But what if it runs like any other mail host, and lives through advertising? Or better still is build on top of one the free vanilla insecure hosts?