The problem with storing private keys on a central server

The easy way - which is what many seemingly secure cloud services do - would have been to store all private keys on our servers. However, a system like this means that you need to trust your provider entirely because the provider can access these keys.

And this is where the problems start: Even if the people running such a service are entirely trustworthy, the encrypted data can be easily compromised when a private key is accessible by others than yourself alone.

If a private key is stored or decrypted on a server, it is an encryption backdoor. Period. For instance, the server could be seized or a hacker could gain access to it. In such a scenario the previously used encryption becomes useless because others now can access all private keys stored on the server to decrypt the data. 'Secure' cloud providers that store their users' private keys on their servers usually argue that they are much more competent to store the keys in a secure way than many users. While this actually might be true, the argumentation lacks a very important aspect: The central server that holds the keys to thousands or even millions of users is of much greater interest to hackers than a personal computer that holds only one or two private keys. Thus, the effort they will put into attacking such a server will also be much higher. Another problem with storing the private key on the server of the provider is that several employees can access these keys. The employees, however, are just people. They can be bribed or blackmailed to turn over private keys, which makes it even easier for hackers or three-letter agencies to gain access. In addition, you need to be absolutely sure that the laws in the country the 'secure' cloud service is operating in will stay privacy-friendly. If this country decides to outlaw encryption - just as it is currently discussed in the USA, the UK and many other countries - the backdoor the politicians are asking for already exists when the private keys are stored centrally at the provider.

All these aspects show why it is not a good idea to store or decrypt private keys centrally on a server giving the provider full access to keys and content.

This is why we actively decided against such a model when we started developing Tutanota.

But how do we solve the contradiction of automatically exchanging private keys between your devices and not having access to them at the same time? The solution sounds simple while the code behind it is rather complex: Encryption.

Challenge accepted: Encrypting the private key so that only the user can access it

At Tutanota we wanted to make sure that our user's data stays private by all means. Just as you write a letter and seal an envelope around it, we wanted to make sure that no one but the appropriate recipient can open and read the content of your encrypted emails.

The system of Tutanota is set up in such a way that your private key is encrypted locally on your device before it is sent to our servers. This makes sure that we never have access to it while your are still able to decrypt your entire mailbox simply by logging in.

For this we use only one password because also your password never touches our servers. A hash is derived from the password on your device, and only this hash is sent to the server. This hash authenticates you as the real user so that the server can send your encrypted data back to your device. Finally, your data is decrypted - locally so that only you have access to your data. Please find details on this in our FAQ.

The code of Tutanota is open source so that anyone can verify it.

Tutanota is the first web-based end-to-end encrypted email system. Our aim is to make encryption so easy that everybody uses it. Ultimately, this will put an end to mass surveillance online and protect our personal right to privacy.