When you login, you provide that password, and Element can use that to decrypt the keys and use these to decrypt the messages stored in the cloud
Alternatively, you can solely rely on syncing keys between verified devices.
Only you as a recipient can decrypt the messages, because they are sent e2ee to you.
And this stays true if you use the backup, as only you know that password.
Regarding the security theater, the backups encrypted with your password are far more vulnerable to being compromised than any of the popular e2e encryption protocols.
But then again, most users do not need real security, they are fine with a warm comforting feeling of safety, provided by a sincere promise that everything is really safe, as demonstrated by Telegram users.
> Regarding the security theater, the backups encrypted with your password are far more vulnerable to being compromised than any of the popular e2e encryption protocols.
How, so? Are you aiming weak passwords? (One is provided for you ("security key"), however you can opt into a custom one that is not directly used for encryption ("security passphrase"))? Or are you referring to PFS, which isn't a property of all popular e2e protocols either, and "far" would be quite a stretch.
How does all that disprove that Element uses true e2ee?
What is "it" that in your opinion should reduce the users privacy?
> I don't know what else to argue about here.
I don't know what you are arguing about right now. What I know, is that I have disproven your original thesis (visible messages right after login through a password is not possible with e2ee) by explaining how it works and providing an example that has put that concept into practice.
If you feel there is anything to discuss, or if you have any further questions, don't hesitate to respond though.
I'll add link that adds technical Implementation details, in case you are interested: https://matrix.org/docs/guides/implementing-more-advanced-e-...
https://www.whatsapp.com/security/WhatsApp_Security_Encrypte...
Overall, the concept seems to be the same: use a secret, only known to the client to secure data stored at a untrusted location.
The major differences include:
- closed vs open source (it's easy to validate the mechanism in the implementation whereas you pretty much need to trust WhatsApp that they don't leak the key)
- WhatsApp uses a third party provider for storing the data whereas with Matrix your Homeserver is responsible for messaging and the backup
- only the main app can access the backup whereas with Matrix any of your clients can independently read and write to the backup (because there is no main client)
- WhatsApp stores everything in the backup, a Matrix client only the keys, because the messages are stored somewhere else
Hmm? How so? Surely this depends on the strength of your password.
> Break one key, and all messages will be accessible to an attacker.
How do you propose breaking that one key, though? The attacker also needs to somehow acquire access to the key backup and to the encrypted messages, so it's a multi-step process.
The encryption protocol does rotate message keys. In fact it uses the same cryptographic primitives as Signal, that is the double ratchet algorithm.
I think you're conflating the message encryption protocol with cold storage, which is the purpose the key backup serves. It's completely typical for backups to be encrypted with a single symmetric key.
Finally, the key backup is completely optional and can be disabled.
Then, how do you break the key?
Brute force? If you break one key that way, it's likely you could break equally secure keys as well.
Access to the device? Well then you have access to everything anyways
This wikipedia entry? So client-side encrypted backups are not called end-to-end encrypted, because the backup service is not a messenger?