People living in countries with totalitarian, oppressive and other threatening regimes should be able to use this system and have some degree of privacy when communicating.


  • Encryption is hard to understand for non-technical people, it should be easy to use.
  • Client side encryption with OpenPGP.JS
  • Code should be minimal and maintainable.
  • Should consider anonimity
  • Should be yubikey compatible


  • Is storage of the (encrypted) private keys on a server that is reached out to via TLS a good solution?
  • Should the keys be stored just on the local storage?
  • Is there something we are missing here?


Please keep your general advice and be as specific as possible, be useful.

  • 2
    These two statements seem to be in direct conflict: "encryption is done on the client side" and "Private keys are stored ... on the SERVER". – Digital Chris Dec 8 '14 at 20:33
  • Hey @digitalchris, the point I need to clarify here is that this should also be EASY TO USE (by people who lack the deep knowledge). Also what is wrong by storing the armoured (encrypted) keys on the server? – Herr Dec 8 '14 at 20:44
  • 1
    "secure" against what? I'm seeing mostly encrypted channel and encrypted messages, but the encryption keys are on the server, so they are exposed. – schroeder Dec 9 '14 at 0:28
  • 1
    More secure than unencrypted e-mail services. If the keys are transferred only on a encrypted connection, where is the problem than? – Herr Dec 9 '14 at 6:19
  • You might want to take note that in most of those countries merely having an encryption key that is not shared with the government is a crime. – MCW Dec 10 '14 at 19:58

The biggest difficulty you will have in building this system is not a technical one, but more political, and legal. You are going to be targeted by every government in the world. Government's will be your biggest threat, and I cannot see where you could possibly get proper hosting without some form of “backdoor/channel” for government agencies.

For example, here in the United States, you’d likely receive a National Security Letter which means you won’t even be able to acknowledge being forced to hand over keys. The government will likely tout terrorism, and crime as the reasoning for the NSL so you will spend a lot of time trying to get it off the ground in any country anywhere in the world. So onto the technical portions of this, along with the hurdles you will need to overcome to make it truly secure.

I will begin by answering your last question: “Is there something we are missing here?” Here is essentially what you are looking to do

PersonUsingService —> connects to your systems —> encrypt/decrypt email 

Scenario 1) PersonUsingService’s machine is out of control. Any malicious software (rootkits, keystroke loggers, etc) means your system failed, even though it did its job. Imagine you built something got the attention of say EFF/ACLU, they used the service only to discover, their communications ended up on Pastebin. All they’ll know is it went through your systems, and in the end, your reputation suffers.

Scenario 2) PersonUsingService’s is MITM before reaching your server. In fact, governments place Narus taps at IXP’s, and or outright steal your certificate, or pay heavily to a CA. Your system fails.

Scenario 3) You take the time to create a wonderful schema but never secured your internal infrastructure, someone accidentally clicks a link while on your dev team. Allows governments, or rogues to access your key system.

I can give dozens of examples of why this is a losing battle. While I understand where you would come from in asking for such a system, the reality is, it is very complex not from the technological side, but from the legal scope.

Back to your questions: “Is storage of the (encrypted) private keys” (stopped here) NO ONE but the key owner should have access to their private key otherwise the system fails. The entire purpose of encryption were to keep private keys private. In an ideal world, there would be trust however, in what you initially stated: “People living in countries with totalitarian, oppressive and other threatening regimes” you need to remember these types of regimes have no problems using “Rubber Hose crypto" to access to your systems (and keys).

From the technical perspective, it is perhaps best to have a look at Vanish and the model put forth from them, and build around that. For example:

PersonUsingService —> log in —> create disappearing (24-48hr key) —> encrypt message
System —> 24-48 expiry —> erase keys

In something like this model, you needed worry about storing keys as the likelihood of a “rapid response raid” to get a hold of crypto keys is low. My perception of why no one isn’t spending time answering this, is because companies have tried this in the past (Hushmail) and burned through a lot of money doing so. Not to mention in the end, law trumps personal opinions, beliefs, etc. If a government declares you give up the keys, you have a lifelong fight trying to prove your point.

  • Thank you very much sir for your detailed answer. My basic motivation is to build something as (technically) simple as possible that would provide the (very) basics of encryption to people who would otherwise have this stuff flying around unencrypted. I agree mostly on all points, especially on Rubber Hose crypto, which is obvious in hindsight. But if you take for example a person living in Iran using this system, wouldn't he be better off(in technical terms) if we keep his keys in Swiss and he is accessing them over TLS? – Herr Dec 11 '14 at 5:53
  • Are there any services around who already beat Scenario 2 and 3? Thank you again for the detailed answer – Herr Dec 11 '14 at 5:56
  • Beating Scenario 2 and 3 make you a developer for others' products. E.g., how do you solve say MS having an exploit in IE. How do you solve OpenSSL or another project from having buggy code. – munkeyoto Dec 12 '14 at 13:07

The biggest point you're missing is a threat model. You've got a bullet-point list of security decisions you've made (some of them rather questionable), but you don't have any idea who you're defending against or what their capabilities (both technical and legal) are. The appropriate precautions for defending against your little brother are very different from those for defending against the FBI, which in turn differ from those for defending against the Russian Mafia.

  • Hey I've updated the question and also added a bounty, thank you! – Herr Dec 11 '14 at 11:21

I think you have a fair point here. In the current thread model the only thing you should consider is where and HOW the keys are stored.

Storing the keys -as long as they are encrypted- on the server and transferring them ONLY via TLS shouldn't be an issue.

You should research how the big players in this area did it before, like the services you mentioned yourself, fastmail, lavabit & etc.

  • Whatever you do, don't use LavaBit as a model. The architecture and implementation was very poor. – Xander Dec 9 '14 at 14:05
  • @xander, thank you, how about a model where encryption is done on the client side and keys are kept encrypted on the server and are only transferred via TLS like johnyfittizio described? – Herr Dec 9 '14 at 17:09
  • @HerrK, any system where the keys are stored on the server (in whatever form) is vulnerable to an attacker who can compromise the server. – Mark Dec 9 '14 at 22:26
  • 1
    @HerrK, deciding where the vulnerable points are is part of the reason for developing a threat model. – Mark Dec 9 '14 at 22:54
  • 1
    @HerrK I think Adam Shostack's book Threat Modeling: Designing for Security is quite good. – Xander Dec 10 '14 at 20:40

Perhaps you want pairing-based cryptography (a subset of ID-based encryption) to solve the keying and key storage problems.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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