It backups your keys encrypted with a password only you know at server side (opt in)

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.

That is not 'true e2ee' at all, and more of a security theater.

How is that?

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.

Encrypted backups are just that, encrypted backups. They are called end-to-end encrypted backups only by people who are ignorant of correct terminology. Even the Wikipedia entry on e2ee addresses this.

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.

I have nowhere called them end-to-end encrypted Backups, that's a straw man.

> 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?

It is proven beyond doubt that whatever Element fetches from their own servers and decodes on application launch are not messages encrypted using e2ee protocols. It is also completely clear that it does reduce the privacy of user messages. I don't know what else to argue about here.

Element does not fetch any message from their servers in general. If you use a server hosted by Element and don't disable encryption, e2ee encrypted messages will be fetched from their servers.

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-...

Maybe what people like to know is how Matrix's backup encryption is different from WhatsApp encrypted backups:

https://www.whatsapp.com/security/WhatsApp_Security_Encrypte...

Thanks for the link. Actually, didn't even know that WhatsApp changed their backup mechanism, which previously used a mechanism that allowed e.g. google to obtain the messages.

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

>Some encrypted backup and file sharing services provide client-side encryption. The encryption they offer is here not referred to as end-to-end encryption, because the services are not meant for sharing messages between users[further explanation needed].

This wikipedia entry? So client-side encrypted backups are not called end-to-end encrypted, because the backup service is not a messenger?

>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.

Hmm? How so? Surely this depends on the strength of your password.

All messages are encrypted with one key. Break one key, and all messages will be accessible to an attacker. Proper encryption protocols rotate encryption keys and compromising one message will not compromise the rest.

The situation is a bit more nuanced, given the large feature set that Matrix is trying to implement.

> 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.

So PGP and the encryption protocol of Threema aren't proper encryption protocols?

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