How does this encrypted webmails works?

Question

In the last days I was looking on Tutanota, ProtonMail, LavaBoom, and others webmails that promise to respect users privacy. For all those, the one I most liked was Tutanota.

I did few tests with this one, sending e-mail for some account outside it, what I saw was: It encrypts a symmetric key with a chosen password, and sends a link for the recipient e-mail address. Ok, but if I change the password for another message, it keeps decrypting the old ones with the new password. I asked them and they told me that 'indirections' are used.

My question is: let's suppose we have hybrid encryption on all this e-mails (when communicating between them, for example: tutanota sender/tutanota recipient), it's encrypted with AES random key, and the random key is encrypted with the recipienr's RSA public key.

They can encrypt the RSA private key, with user password, the user will be able to change this password, they will just re-encrypt the RSA private key with the new password, but the key will be the same. When user log-in, they send the encrypted key to the user, and the user decrypts it with the secret password, on JavaScript only.

But the entire scheme still depending the same RSA key, time after time, even when user change his password. If this key, sometime gets compromised, the user cannot fix his problem just changing his password, right? If things are like this, I believe that this is a implementation problem (maybe just a concept problem), because if the system grows up, and have 100 millions users, and become a standard, in some years RSA 1024/2048, what they should use right now, will become overdue and easily crackable. The millions of users will have millions of data encrypted with overdue encryption, and they will need to re-encrypt everything.

I'm missing some point, or this will happen? I know that every encryption will become overdue in the future as the processing power increases. But most of the systems, can easily update their encryption and make the new algorithm the standard for the entire system, this is not the case of a webmail system.

Answer 1

I'm unfamiliar with the details of the systems you specify but understand email encryption in general. Once a message is encrypted, the system cannot re-encrypt it with a stronger algorithm without user intervention as the system can't decrypt the email to re-encrypt it. So you're email is frozen in time in terms of the encryption that was used.

Even if the system did re-encrypt the emails with user help, that doesn't guarantee security as the encrypted email can have had many copies made of it that can't be retroactively re-encrypted.

In fact, your concern about emails becoming insecure as stronger processing power becomes available is true for all encryption. Consider an SSL connection between a browser and a website. If I could record all of the traffic and was really patient, I could come back with my wizzy-fast quantum-plus whatever processor and decrypt it quickly. Given enough time, my password safe will become hackable and SHA-512 will be easy to crack.

The solution is that cryptographers have crystal balls (or at least they pretend to) that allow them to predict how fast computing power is likely to be N-years from now. When determining what crypto algorithm to use, one is selected that will be secure for at least as many years as the data is expected to continue to be sensitive.

Some assumptions are made here that may or may not be true:

1. Cryptographers can predict processing power. This is made easier by the fact that they don't need to be accurate. They only need to figure out the worst case for increase in processing power.
2. Data becomes less sensitive over time. If the data is always going to be sensitive then you are going to need to do more than just encryption to secure it. For example, encrypt it and never put it on a public network and burn the computers that handled it when you're done.
3. The strength of a crypto algorithm is accurate. Unfortunately, sometimes crypto algorithms are less secure than we think and cracks can be found that require less computing resources than a brute-force attack.

As an example of this timeout, this statement is made about 3DES:

This is not currently practical and NIST considers keying option 1 to be appropriate through 2030

This is why 3DES is considered weak encryption. 2030 is just too soon to be interesting.

So no crypto lasts forever. Secure email is just one example of this.