Earlier quoted context omitted.
Data that is transmitted or stored along with the keys is effectively plaintext, which Telegram does. The data is effectively plaintext on my device, at Telegram, and on the group members' devices, even if it is not plaintext in-between. Data I send to a website over TLS is effectively plaintext on my computer and on the other side; in transit, it is not. It all comes down to your threat model. Encryption does not pr…
> stored along with the keys It's not. They use a split-key encryption system so it's not exactly the same as storing the keys where the data is. > It all comes down to your threat model. Encryption does not protect information from entities who hold the keys to decrypt that information. I agree, which is why I'll say that the bottom line is: Are auditable E2EE algorithms stronger in security than cloud encryption? Y…
Yes, again, it all comes down to your threat model. No one can kick down the door and get to the keys.
But Telegram can get to all the keys, and thus can be legally expected to. The data is effectively plaintext to Telegram.
> Is MTProto 2.0 Cloud Encryption plaintext? No.
Just to note: "effectively plaintext" has been in use for a couple of decades as a term of art. We don't say it's plaintext, because it's not. It means there's effectively no security properties lent by the encryption.
For example, my web browser encrypts a few passwords for me and stores them on disk, but doesn't need a cryptographic secret from me to decrypt them; they're effectively plaintext, because no one has to break any encryption to read them.
Indeed, here's a thread on HN from 2013, where Durov is participating, where people are using "effectively plaintext" in exactly this way to describe exactly what we're talking about: https://news.ycombinator.com/item?id=6937097