Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Just spotted a Reddit thread about Kim Dotcom, of MegaUpload fame, planning to produce a secure webmail system that allows people to communicate securely, without the worry of having their messages sniffed by three-letter agencies.

Considering the debacle over MEGA's crypto, this makes me nervous. Some people in the Reddit thread raised some important points too:

  • If the site holds the private keys, the messages cannot be secure.
  • Using localStorage is problematic due to lack of encryption.
  • It's difficult to tell how secure the site is if it's a black box.

Are there any other major things to worry about with such sites? Are there any reasonable mitigations that allow for this kind of service to be viable?

share|improve this question
up vote 5 down vote accepted

Let's assume here that we are talking about a serious design for emails, i.e. one without a centrally trusted server (we already have Gmail; if we are to trust a potential Evil Overlord, we may as well choose a competent one).

When using a Web site, you use the Web site interface, which can do nasty things behind your back. The same holds for every piece of software, but the Web is especially dynamic: by definition, it is downloaded anew each time you connect. With a locally installed application, you can make some review once (e.g. compiling GnuPG from source); if the application is "clean", it stays clean; and if it was backdoored, then, at least, you may keep a copy as proof for the post mortem analysis. Such things are much harder with a Web site.

Therefore a Web-based solution may cheat on you easily.

Also, we know that key management, including generation and storage, is subtle. Since keys concentrate secret, they are high-value targets, and should be protected accordingly. GnuPG uses mlock() (or its Windows equivalent) to prevent the key from being written to the swap space. You cannot do that in Javascript... Similarly, some cryptographic tasks related to passwords (e.g. password-based encryption of a key ring) kind of need some slow and salted hashing (bcrypt & co) to cope with the inherent weakness of passwords being passwords. Slow hashing requires some muscle. Javascript is very feeble in that respect. And if we want to be serious about key management, then we want smart cards, which again will be hard to access from a Web application.

Therefore I claim that it is very difficult to make a correct Web-based solution for secure emails, even when all the developers are top-notch.

And, of course, how can you know if a given Web site was properly developed, by people knowing their trade ?

share|improve this answer
A competent Evil Overlord, huh? But see this item about G00gle's two-factor auth:… – Deer Hunter Feb 26 '13 at 22:34
See also and for more on delimiting which kinds of web services are and aren't a good match for web-based crypto. – D.W. Jun 10 '14 at 6:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.