They just cannot be sustainable long term. There is literally no restriction size-wise on data you can save on their servers. For free. And they have basically no income. They have some new ad program with basically no tracking (which is good for users, sure, but nobody will pay that much for that). They get 0 commissions from payment (and I never heard anyone using their payment thing). TON went nowhere.
You’re repeating weird, but working with both bot api and tg api weekly or so (tg api through a wrapper, but I’ve read about lower level calls and used these in gramjs) I can’t see what do you mean by that.
[1]: https://words.filippo.io/dispatches/telegram-ecdh/ [2]: https://crypto.stackexchange.com/questions/31418/signal-vs-t...
It also seems like files that are not downloaded by many people for a while get moved to slow servers and downloading these is really really really slow. If you have a few GB and want an additional online backup sure you could abuse it for that but realistically the potential to abuse it is low as it simply makes no sense as a could storage + they simply delete accounts from people who abuse the network. "Spam" is very lose defined and if you spam upload/download I'm sure they consider that to be spam and delete your account. Kinda pointless "backup" if you can lose access the moment you use the backup.
>And they have basically no income.
How would you know? They launched ads in public channels.
>TON went nowhere.
TON exists and seems functional just doesn't have anything to do with Telegram anymore due to the SEC.
it is on https://Github.com/SignalApp
and i’ve got my own variant of Signal server and client running. and runs on not only mobile but Linux too.
If you don't need/want that it is clearly superior, but if you do...
Sure, Telegram team used more human resources elsewhere while WA and Signal where doing their E2EE magic, but once they where done - what stopped them from investing into everything else?
The most salient of these is that, if you lose your keys, you may never be able to recover your data.
- Hash the password client-side
- Send the hash to the server. The server treats it as a password, and gives you your blob of encrypted data
- Decrypt the data client-side using the original password
Also, downloading blob to client side and decoding it locally can hardly be done fast enough for user to consider it 'instantly'.
That's a different, further goalpost - we were talking about E2E encryption, weren't we? I.e. the server should not need to decrypt your data to provide it.
Obviously if you want to be able to recover your history from storage with just a password, that does mean the password is the only protection over that history, tautology. So storing your history should be optional, if you're seriously worried about brute-force attacks on data encrypted at rest (indeed, even WhatsApp makes it optional to have a backup of your data!).
In any case, that doesn't compromise future secrecy - i.e. gaining access to the history still doesn't give you access to future messages.
> Also, downloading blob to client side and decoding it locally can hardly be done fast enough for user to consider it 'instantly'.
Off the top of my head, it doesn't have to be a single blob for all your data. You could split the blob into tiny equal-sized chunks, and then have a separate encrypted index file which stores the information of which chunks hold which chats (plus just enough metadata, e.g. chat titles and last messages, to display your homepage properly). The index file is the only one downloaded on first login, then when you want to open a chat it moves the corresponding chunks to the top of the download list.
Exactly, and what is described is not e2ee at all.
> End-to-end encryption (E2EE) is a system of communication where only the communicating users can read the messages. [..] End-to-end encryption is intended to prevent data being read or secretly modified, other than by the true sender and recipient(s). The messages are encrypted by the sender but the third party does not have a means to decrypt them, and stores them encrypted. The recipients retrieve the encrypted data and decrypt it themselves.
Which requirement do you believe is failed by such a system?
This is reasonable, but it's not describing any weakness of encrypted backups. It merely points out that "E2E" isn't the right term to use when there are not two E[nds], but rather only one client and their files.
However, our conversation was about storing chat history. There are two parties to the conversation in that case.
The key property of E2E is that only those parties can read those messages, and nobody else, in particular not the agents running the server. That property is not affected by the existence of backups, as long as those backups are client-side encrypted, because third parties cannot access them.
Therefore, it is possible to have both cloud-stored chat histories and true E2EE. QED.
Please, enlighten me how exactly Element/Matrix practically do that. Thank you in advance.
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?
That stuff confuses every non IT person.
Not caring about it, allows for a more simple UI and UX to provide a easy way for person A to message B. Where B can be a group of thousands of people.
(a really secure way of posting a message to a big group would be way more complicated, even signal makes compromises)
I get that people like its UX, but if you're sacrificing security for UX then basically anything becomes fine?
The police can only make you talk if they know who to make talk in the first place.
Reading your messages tells them who to interrogate, where to find them, who else is involved, etc.
Encryption is important especially in such countries.
The police need to crack the encryption protocol (not impossible, telegram use non-standard crypto), or somehow gain access to telegram's server farm.
>Reading your messages tells them who to interrogate, where to find them, who else is involved, etc.
Why read my messages if they can start from me? Or that other guy who posted something on twitter? Or any other place? Or talked to someone.
I'm not saying encryption is unimportant. I'm saying that it really only matters as long as all parties involved keep their business secure in the first place.
Not to mention that they police don't really work with that kind of precision here.
If you can choose secure communication vs. insecure communication you're better off choosing secure. You're right of course this doesn't protect you 100%, but it's a lot better than not having secure communication.
Does that mean even with Signal your friend could be compelled to unlock their phone and reveal the comms? Sure. It's still better to have that be the requirement than access to all comms by default. It requires more specific and high effort targeting. It makes it harder to just query keywords generally to find people. It's the better default state.
If you want to exchange your private keys, you better not do it using any chat platform.
What countries do you people live in that needs such hiding from the police/state?
In my country they bought Pegasus and what can I do about it? If they want to trace me they can do it.
Edit: but even so, they could verify a phone number by SMS, no need to make anyone install an app.