8 ms·

Do Signal, Wire, or Matrix do this transcript consistency thing, or is there some other way by which they prevent message reordering? From what I know, encrypte

by lucb1e 5y ago

Do Signal, Wire, or Matrix do this transcript consistency thing, or is there some other way by which they prevent message reordering? From what I know, encrypted messengers almost never implement that. At least in Wire I noticed reordering at some point and it uses an implementation of what is now called the Signal protocol. And that's the most severe vulnerability from the article. The second one is "mostly of theoretical interest" according to the researchers themselves, the third requires "an attacker [to] send many carefully crafted messages to a target, on the order of millions of messages", and the fourth "requires sending billions of messages to a Telegram server within minutes". So while this is not bad research, not at all (it's really great that people take this close a look!), the title sounds rather more severe and people will obviously jump to the conclusion that "See, MTproto is bad like we said all along!" without reading anything. Good research, bad article? «Obligatory notice in Telegram comment threads: the real issue in Telegram is that end-to-end encryption is optional and made extremely inconvenient to use: no implementation at all in TDesktop, can't use it across multiple devices, doesn't work for group chats at all... That is the main reason Telegram isn't secure: they can read all your chats except when you use this stupid inconvenient mode.»

okdjnfweonfe 5y ago
https://signal.org/docs/specifications/doubleratchet/#out-of-order-messages https://signal.org/docs/specifications/doubleratchet/#out-of...
- lucb1e 5y ago
  i.e. messages can be out of order, so no transcript consistency, is that what you're saying?
  - deleted 5y ago
    [deleted]
  - baby 5y ago
    transcript consistency is usually something that matters in group chat, and signal/matrix/and pretty much all group chat apps rely on a trusted server to order messages.
  - tsegers 5y ago
    I think that the linked article described that messages that arrive out of order can still be decrypted despite the decryption keys being generated in a strict order. As far as I know, the order of the keys that are used to decrypt incoming messages also indicate the order in which the decrypted messages were sent.
    - joecool1029 5y ago
      So would a potential fix be just to add some metadata in the message somewhere that says when it was sent?
      - hutzlibu 5y ago
        That would at least arrange the messages later on in the right order(I think they do this actually), but still means, they might get received in the wrong order. So you get the notification and look on your phone, but see only one of the later messages without context or knowing that there is missing information yet to arrive. That can be very irritating and annoying.
        gsich 5y ago
        This is also annoying because you are seeing your messages on your end instantly, so your chat history order is not the same as everyone elses. This is most noticeable in a group with lots of messages. Not a crypto issue, but a UI one though.
stryan 5y ago
>Do Signal, Wire, or Matrix do this transcript consistency thing, or is there some other way by which they prevent message reordering? Rooms in Matrix are directed graphs[0], so if I'm understanding right, transcript consistency should be the default. [0] https://matrix.org/docs/spec/#id14 https://matrix.org/docs/spec/#id14
- deleted 5y ago
  [deleted]
perardi 5y ago
Mm-hmm. iMessage and WhatsApp are encrypted “out of the box”—it’s the default. Telegram requires an explicit choice.
- codedokode 5y ago
  Unlike Telegram, iMessage and WhatsApp are closed source apps. How can you verify that they really encrypt the messages?
  - maqp 5y ago
    Here's the thing. There's perhaps a 0.0001% chance that iMessage or WhatsApp contains a backdoor that does not really encrypt a message. There's a 100% chance that every cloud message, every Windows/Linux desktop message, and EVERY message by default, is sent to Telegram servers, where the vendor, and any intelligence agency, organized crime unit etc., can steal them from. Telegram is a for-profit company. It can also be sold, and that will include billions of messages stored on their server. The only thing stopping them from selling out is "they don't feel like it". Telegram is not backdoored, but, it is proven to be frontdoored, and this is extremely dangerous because "it's nothing new, we knew this, it's obvious". Yes. It's blindfully obvious to your average crypto anarchist who's spent a year reading about cryptographic protocols. It's anything but obvious to your average user. To give some idea, I did a survey at my university computer science department: the students have lots of Telegram users. These students study cryptography as part of their network course, number theory course, and there's even a grad-level cryptography course run by Valtteri Niemi. Here's what I found: less than 20% even knew what secret chats were, let alone used them. Everyone just winged it, assumed Telegram was safe by default. Now, if a computer science student body whose field this is don't know about it, what chance is there a hair stylist, a political major, a dissident/activist, or journalist, knows about it. But I can't blame them: I've long since lost the count of how many times I've seen news media bundle apps together: "Signal, Telegram, Threema ... are secure replacements for WhatsApp". This kind publishing is incredibly irresponsible, and it's no wonder people get the wrong idea. So yes, Telegram is open source with reproducible builds. But that confirms nothing but the existence of the front door to technical people, that the app doesn't end-to-end encrypt anything, by default.
eitland 5y ago
> Obligatory notice in Telegram comment threads: Sadly, obligatory notice in Telegram threads: Telegram is encrypted by default and has always been unlike a certain big competitor that has been pushed here. The issue isn't if it is encrypted but if it is end to end encrypted and also the quality of the encryption. Saying it is not encrypted is directly misleading. Your point that they can read your messages if they want still stands. This however is also true for mail, banking and about everything else except the most secure instant messaging networks.
- axaxs 5y ago
  Encrypted, as it's used with messengers, means E2E encrypted. Anyone who is calling Telegram 'encrypted by default' while technically correct, is being very, very misleading.
  - eitland 5y ago
    Well, calling it "unencrypted" is equally misleading ... and technically wrong as well. In a somewhat technical community we should strive to communicate correctly and not invent new meanings for well-defined terms. By all means come up with a new nasty sounding term, but don't lie and excuse it with "it means something else now", that is borderline childish/sleazy salesman-ish.
    - maqp 5y ago
      > Well, calling it "unencrypted" is equally misleading Encryption implies it protects message content from third parties. Show me someone who agrees its bad if the third party is some random guy from ISP, but it's good if its some random guy from Telegram LLC. Telegram is effectively unencrypted, because the messages are by default readable by someone else, like is the case if there was no encryption at all. Third parties are not just your average script kiddie capturing packets at your internet cafe, third parties are also everyone who hacks Telegram server, every intelligence agency that hacks Telegram servers, and a possible parent company that buys Telegram.
alerighi 5y ago
> can't use it across multiple devices The reason is that. You have to choose between something you can use from whatever device you want, that you can simply log in into a web interface on whatever computer, or end2end encryption. Telegram made a choice of usability, you are able to use Telegram from whatever device, mobile app, desktop app, web app, smartwatch app, command line client, third party clients, without any problem, notifications arrive on every device, you can start a conversation on one device and continue it on another, they are synchronized in real time. It's in theory less secure? Yes, since whoever has access to Telegram servers can in theory read your messages. Is it in practice a problem? No, it's not. Telegram doesn't, as far as we know, give access to government or other third parties to the data of the users. WhatsApp does for example, not for the message content but for the metadata (that they can read). What is more secure, in the real world and not in theory? Signal is more secure, yes, but it's more inconvenient that both Telegram and WhatsApp. I prefer a convenient and slightly less secure messaging service than a super secure one (in theory) but inconvenient to use.
- LordDragonfang 5y ago
  >You have to choose between something you can use from whatever device you want, that you can simply log in into a web interface on whatever computer, or end2end encryption. >Telegram made a choice of usability Bullshit. Plenty of services have e2ee and cross-device usage. All you need for multi-platform e2ee is to sync an encryption key across devices. Either through a "trusted" party (like iMessage) or by literally syncing the key locally (Signal). You can even have one device act as the message store so you don't even keep store the encrypted messages in the cloud. Telegram did not choose usability, they chose the opposite.
  - snotrockets 5y ago
    iMessage doesn't share private keys between devices. Each device has its own secret key, and when you send a message to a person with multiple devices, you encrypt multiple copies, one for each (source: https://support.apple.com/guide/security/how-imessage-sends-and-receives-messages-sec70e68c949/1/web/1 https://support.apple.com/guide/security/how-imessage-sends-...) An issue here is that the software doesn't show the user the list of keys used to encrypt a given message. If an attacker can inject their own keys into the identity service records for a given user, they would then receive a copy of all messages sent to that user.
enkid 5y ago
From what I've seen of this type of research, a vulnerability like these may be worked on and some one will refine it to make it exploitable, so even if it's not possible to use it in it's current form, it's important to be aware to prevent future attacks.
martinralbrecht 5y ago
See Appendix C of https://mtpsym.github.io/paper.pdf https://mtpsym.github.io/paper.pdf (the underlying research paper). Reordering of messages (in one direction) and "causality preservation" (both directions) are two different things.
toast0 5y ago
> Do Signal, Wire, or Matrix do this transcript consistency thing, or is there some other way by which they prevent message reordering? From what I know, encrypted messengers almost never implement that. At least in Wire I noticed reordering at some point and it uses an implementation of what is now called the Signal protocol. If I'm reading this right, the issue is that a network MITM can reorder the messages in the client to server connection (without being able to read them). This would likely reorder messages in the chat transcript too, but that's a different issue. TLS or Noise protocol are open alternatives here, and IIRC both require that you have received all previous packets in order to validate a new packet, which means either you've received all the packets in order or the MITM has compromised the handshake. Signal protocol is the end to end protocol between clients; those messages do not require reception in order. Because the messages go through a server and may be retried, there's lots of ways things could go wrong and some messages may be dropped or delayed and can arrive out of order. You could refuse to display message N until you've displayed N - 1, but if the server dropped N for whatever reason, you need to get the sender to resend it, and that depends on availability of the sender which is limited (their phone may be off, out of coverage, or execution may be denied/delayed by the OS, or the user may have removed the app by the time the receiving app notices the message is missing, etc).
- jb_s 5y ago
  At the UI can potentially indicate discrepancies around message ordering.
JulianMorrison 5y ago
Generally, the thing with cryptography is the first breaks tend not to be useful. Crafted messages, terabytes of data, a compromise in one round of several in the key, etc. Theoretical stuff. But they then tend to get worse rapidly, building on those useless cracks to drive the wedge deeper. And so in general it's best to assume that if something's slightly broken, soon it will be all the way broken.
- Siira 5y ago
  Care to give some sources for this claim? Even with some examples, it seems very vulnerable to the survival bias (examples where small flaws did not lead to a big blowdown are not paid attention to).
  - lucb1e 5y ago
    They're not wrong in principle: attacks do often start as implausible and then some other shortcut or weakness is found and bam, there is a realistic exploit out of something that was deemed completely infeasible. I think in this context, it's a bit more nuanced. These shortcomings are fixed (I can't personally vouch for the correctness of the fix as I haven't looked at the source diff, but let's assume it's solid), so they're not left to linger and build on. There was also a more serious bug in the past though I forgot the details. If this is the worst they're finding now, I'm not so worried. What I hear of mtproto doesn't sound like bugs are compounding but rather like they're ironing our small (but not completely unimportant, of course) flaws. But of course we won't truly know if it's secure until someone finds a devastating attack.
    - bjoli 5y ago
      The old attack was that the server provided the client with randomness when generating keys for private chats, allowing the server to effectively MITM all private chats. Pretty weird design decision.
  - martinralbrecht 5y ago
    > As an aside, Jakobsen and Orlandi wrote: “We stress that this is a theoretical attack on the definition of security and we do not see any way of turning the attack into a full plaintext-recovery attack.” Similarly, the Telegram “FAQ for the Technically Inclined (MTProto v.1.0)” provides the following analogy: “A postal worker could write ‘Haha’ (using invisible ink!) on the outside of a sealed package that he delivers to you. It didn’t stop the package from being delivered, it doesn’t allow them to change the contents of the package, and it doesn’t allow them to see what was inside.” In hindsight, we think that this is incorrect. As explained above, our timing side channels essentially exploit this behaviour in order to do message recovery (but we need to “chain” two “exploits” to make it work, even ignoring practicality concerns). https://mtpsym.github.io/ https://mtpsym.github.io/

by lucb1e 5y ago

okdjnfweonfe 5y ago

https://signal.org/docs/specifications/doubleratchet/#out-of-order-messages https://signal.org/docs/specifications/doubleratchet/#out-of...

lucb1e 5y ago
i.e. messages can be out of order, so no transcript consistency, is that what you're saying?
- deleted 5y ago
  [deleted]
- baby 5y ago
  transcript consistency is usually something that matters in group chat, and signal/matrix/and pretty much all group chat apps rely on a trusted server to order messages.
- tsegers 5y ago
  I think that the linked article described that messages that arrive out of order can still be decrypted despite the decryption keys being generated in a strict order. As far as I know, the order of the keys that are used to decrypt incoming messages also indicate the order in which the decrypted messages were sent.
  - joecool1029 5y ago
    So would a potential fix be just to add some metadata in the message somewhere that says when it was sent?
    - hutzlibu 5y ago
      That would at least arrange the messages later on in the right order(I think they do this actually), but still means, they might get received in the wrong order. So you get the notification and look on your phone, but see only one of the later messages without context or knowing that there is missing information yet to arrive. That can be very irritating and annoying.
      - gsich 5y ago
        This is also annoying because you are seeing your messages on your end instantly, so your chat history order is not the same as everyone elses. This is most noticeable in a group with lots of messages. Not a crypto issue, but a UI one though.

stryan 5y ago

>Do Signal, Wire, or Matrix do this transcript consistency thing, or is there some other way by which they prevent message reordering? Rooms in Matrix are directed graphs[0], so if I'm understanding right, transcript consistency should be the default. [0] https://matrix.org/docs/spec/#id14 https://matrix.org/docs/spec/#id14

deleted 5y ago
[deleted]

perardi 5y ago

Mm-hmm. iMessage and WhatsApp are encrypted “out of the box”—it’s the default. Telegram requires an explicit choice.

codedokode 5y ago
Unlike Telegram, iMessage and WhatsApp are closed source apps. How can you verify that they really encrypt the messages?
- maqp 5y ago
  Here's the thing. There's perhaps a 0.0001% chance that iMessage or WhatsApp contains a backdoor that does not really encrypt a message. There's a 100% chance that every cloud message, every Windows/Linux desktop message, and EVERY message by default, is sent to Telegram servers, where the vendor, and any intelligence agency, organized crime unit etc., can steal them from. Telegram is a for-profit company. It can also be sold, and that will include billions of messages stored on their server. The only thing stopping them from selling out is "they don't feel like it". Telegram is not backdoored, but, it is proven to be frontdoored, and this is extremely dangerous because "it's nothing new, we knew this, it's obvious". Yes. It's blindfully obvious to your average crypto anarchist who's spent a year reading about cryptographic protocols. It's anything but obvious to your average user. To give some idea, I did a survey at my university computer science department: the students have lots of Telegram users. These students study cryptography as part of their network course, number theory course, and there's even a grad-level cryptography course run by Valtteri Niemi. Here's what I found: less than 20% even knew what secret chats were, let alone used them. Everyone just winged it, assumed Telegram was safe by default. Now, if a computer science student body whose field this is don't know about it, what chance is there a hair stylist, a political major, a dissident/activist, or journalist, knows about it. But I can't blame them: I've long since lost the count of how many times I've seen news media bundle apps together: "Signal, Telegram, Threema ... are secure replacements for WhatsApp". This kind publishing is incredibly irresponsible, and it's no wonder people get the wrong idea. So yes, Telegram is open source with reproducible builds. But that confirms nothing but the existence of the front door to technical people, that the app doesn't end-to-end encrypt anything, by default.

eitland 5y ago

> Obligatory notice in Telegram comment threads: Sadly, obligatory notice in Telegram threads: Telegram is encrypted by default and has always been unlike a certain big competitor that has been pushed here. The issue isn't if it is encrypted but if it is end to end encrypted and also the quality of the encryption. Saying it is not encrypted is directly misleading. Your point that they can read your messages if they want still stands. This however is also true for mail, banking and about everything else except the most secure instant messaging networks.

axaxs 5y ago
Encrypted, as it's used with messengers, means E2E encrypted. Anyone who is calling Telegram 'encrypted by default' while technically correct, is being very, very misleading.
- eitland 5y ago
  Well, calling it "unencrypted" is equally misleading ... and technically wrong as well. In a somewhat technical community we should strive to communicate correctly and not invent new meanings for well-defined terms. By all means come up with a new nasty sounding term, but don't lie and excuse it with "it means something else now", that is borderline childish/sleazy salesman-ish.
  - maqp 5y ago
    > Well, calling it "unencrypted" is equally misleading Encryption implies it protects message content from third parties. Show me someone who agrees its bad if the third party is some random guy from ISP, but it's good if its some random guy from Telegram LLC. Telegram is effectively unencrypted, because the messages are by default readable by someone else, like is the case if there was no encryption at all. Third parties are not just your average script kiddie capturing packets at your internet cafe, third parties are also everyone who hacks Telegram server, every intelligence agency that hacks Telegram servers, and a possible parent company that buys Telegram.

alerighi 5y ago

> can't use it across multiple devices The reason is that. You have to choose between something you can use from whatever device you want, that you can simply log in into a web interface on whatever computer, or end2end encryption. Telegram made a choice of usability, you are able to use Telegram from whatever device, mobile app, desktop app, web app, smartwatch app, command line client, third party clients, without any problem, notifications arrive on every device, you can start a conversation on one device and continue it on another, they are synchronized in real time. It's in theory less secure? Yes, since whoever has access to Telegram servers can in theory read your messages. Is it in practice a problem? No, it's not. Telegram doesn't, as far as we know, give access to government or other third parties to the data of the users. WhatsApp does for example, not for the message content but for the metadata (that they can read). What is more secure, in the real world and not in theory? Signal is more secure, yes, but it's more inconvenient that both Telegram and WhatsApp. I prefer a convenient and slightly less secure messaging service than a super secure one (in theory) but inconvenient to use.

LordDragonfang 5y ago
>You have to choose between something you can use from whatever device you want, that you can simply log in into a web interface on whatever computer, or end2end encryption. >Telegram made a choice of usability Bullshit. Plenty of services have e2ee and cross-device usage. All you need for multi-platform e2ee is to sync an encryption key across devices. Either through a "trusted" party (like iMessage) or by literally syncing the key locally (Signal). You can even have one device act as the message store so you don't even keep store the encrypted messages in the cloud. Telegram did not choose usability, they chose the opposite.
- snotrockets 5y ago
  iMessage doesn't share private keys between devices. Each device has its own secret key, and when you send a message to a person with multiple devices, you encrypt multiple copies, one for each (source: https://support.apple.com/guide/security/how-imessage-sends-and-receives-messages-sec70e68c949/1/web/1 https://support.apple.com/guide/security/how-imessage-sends-...) An issue here is that the software doesn't show the user the list of keys used to encrypt a given message. If an attacker can inject their own keys into the identity service records for a given user, they would then receive a copy of all messages sent to that user.

enkid 5y ago

From what I've seen of this type of research, a vulnerability like these may be worked on and some one will refine it to make it exploitable, so even if it's not possible to use it in it's current form, it's important to be aware to prevent future attacks.

martinralbrecht 5y ago

See Appendix C of https://mtpsym.github.io/paper.pdf https://mtpsym.github.io/paper.pdf (the underlying research paper). Reordering of messages (in one direction) and "causality preservation" (both directions) are two different things.

toast0 5y ago

> Do Signal, Wire, or Matrix do this transcript consistency thing, or is there some other way by which they prevent message reordering? From what I know, encrypted messengers almost never implement that. At least in Wire I noticed reordering at some point and it uses an implementation of what is now called the Signal protocol. If I'm reading this right, the issue is that a network MITM can reorder the messages in the client to server connection (without being able to read them). This would likely reorder messages in the chat transcript too, but that's a different issue. TLS or Noise protocol are open alternatives here, and IIRC both require that you have received all previous packets in order to validate a new packet, which means either you've received all the packets in order or the MITM has compromised the handshake. Signal protocol is the end to end protocol between clients; those messages do not require reception in order. Because the messages go through a server and may be retried, there's lots of ways things could go wrong and some messages may be dropped or delayed and can arrive out of order. You could refuse to display message N until you've displayed N - 1, but if the server dropped N for whatever reason, you need to get the sender to resend it, and that depends on availability of the sender which is limited (their phone may be off, out of coverage, or execution may be denied/delayed by the OS, or the user may have removed the app by the time the receiving app notices the message is missing, etc).

jb_s 5y ago
At the UI can potentially indicate discrepancies around message ordering.

JulianMorrison 5y ago

Generally, the thing with cryptography is the first breaks tend not to be useful. Crafted messages, terabytes of data, a compromise in one round of several in the key, etc. Theoretical stuff. But they then tend to get worse rapidly, building on those useless cracks to drive the wedge deeper. And so in general it's best to assume that if something's slightly broken, soon it will be all the way broken.

Siira 5y ago
Care to give some sources for this claim? Even with some examples, it seems very vulnerable to the survival bias (examples where small flaws did not lead to a big blowdown are not paid attention to).
- lucb1e 5y ago
  They're not wrong in principle: attacks do often start as implausible and then some other shortcut or weakness is found and bam, there is a realistic exploit out of something that was deemed completely infeasible. I think in this context, it's a bit more nuanced. These shortcomings are fixed (I can't personally vouch for the correctness of the fix as I haven't looked at the source diff, but let's assume it's solid), so they're not left to linger and build on. There was also a more serious bug in the past though I forgot the details. If this is the worst they're finding now, I'm not so worried. What I hear of mtproto doesn't sound like bugs are compounding but rather like they're ironing our small (but not completely unimportant, of course) flaws. But of course we won't truly know if it's secure until someone finds a devastating attack.
  - bjoli 5y ago
    The old attack was that the server provided the client with randomness when generating keys for private chats, allowing the server to effectively MITM all private chats. Pretty weird design decision.
- martinralbrecht 5y ago
  > As an aside, Jakobsen and Orlandi wrote: “We stress that this is a theoretical attack on the definition of security and we do not see any way of turning the attack into a full plaintext-recovery attack.” Similarly, the Telegram “FAQ for the Technically Inclined (MTProto v.1.0)” provides the following analogy: “A postal worker could write ‘Haha’ (using invisible ink!) on the outside of a sealed package that he delivers to you. It didn’t stop the package from being delivered, it doesn’t allow them to change the contents of the package, and it doesn’t allow them to see what was inside.” In hindsight, we think that this is incorrect. As explained above, our timing side channels essentially exploit this behaviour in order to do message recovery (but we need to “chain” two “exploits” to make it work, even ignoring practicality concerns). https://mtpsym.github.io/ https://mtpsym.github.io/