4 ms·

The Telegram team's response to this isn't very encouraging: https://telegra.ph/LoU-ETH-4a-proof-07-16 https://telegra.ph/LoU-ETH-4a-proof-07-16 They don't see

The Telegram team's response to this isn't very encouraging: https://telegra.ph/LoU-ETH-4a-proof-07-16 https://telegra.ph/LoU-ETH-4a-proof-07-16 They don't seem to go into technical details, relying on analogies like bags of sand - maybe this is comforting enough to the general public, but I'm skeptical. I didn't read the technical details of the exploits though, so Telegram might be entirely in the right to be so dismissive.

capableweb 5y ago
Here is the comments from the Telegram team for the technically inclined: https://core.telegram.org/techfaq/UoL-ETH-4a-proof https://core.telegram.org/techfaq/UoL-ETH-4a-proof Linked in the third paragraph of the submission: > The researchers also highlighted several traits of MTProto that were changed as the result of our discussions before the paper was published. This document provides an accessible overview of these changes. For more technical details, see here.
eitland 5y ago
I don't like the way they communicate regarding security, but for context: So far there has been an extreme amount of FUD thrown their way from people who pushed WhatsApp and Signal.
- teawrecks 5y ago
  > from people who pushed WhatsApp So Facebook?
  - eitland 5y ago
    No, I'm thinking about well meaning security people who focused a bit too much on E2E-encryption and forgot that WhatsApp sent metadata in bulk to Facebook and uploaded backups unencrypted to Google and/or iCloud.
    - Ar-Curunir 5y ago
      As opposed to Telegram, where chats are unencrypted by default, and synced to the cloud?
      - eitland 5y ago
        are we a community of technical people or sleazy sales people? What you say about being synced to the cloud in a way that can be decrypted is correct and can be problematic for some people but calling it unencrypted is wrong and detracts from your message.
        maqp 5y ago
        Saying the database is encrypted when the database key has to sit in the RAM of the server is as disingenuous as saying this is proper way to lock up gems: https://i.imgur.com/0gBOPoQ.png https://i.imgur.com/0gBOPoQ.png You're basically arguing that "you can't say it's not locked when the lock is right there"
        Dah00n 5y ago
        Your comment says nothing about what GP actually stated.
        maqp 5y ago
        Calling Telegram unencrypted isn't practically wrong when the key is stored right next to the data.
        eitland 5y ago
        > Saying the database is encrypted when the database key has to sit in the RAM of the server First you are replying to something I didn't say. Secondly, going down that path and applying it as strictly to everything you'll find that nothing is encrypted: not your communication with the bank, certainly not WhatsApp as it stores temporary databases unencrypted (not only with a password stored in ram) and probably not much else either. In fact I guess if we apply your criteria to Signal clients they are not encrypted either.
- joecool1029 5y ago
  > I don't like the way they communicate regarding security In general they are cocky but in an expressive way. It is heartening that when papers like this are published they fix the issues despite the PR spin. I've had one email thread interaction with Telegram and it was to unban my account that got banned for messing around with old clients, I can't say they were pleasant but they did answer many of my questions. >So far there has been an extreme amount of FUD thrown their way from people who pushed WhatsApp and Signal. Signal's people did not inform their Android users of the potential for backdoored IME's in places like China for over a year (thankfully their site does mention it now). It was telling that the app was available and usable there until word got out that this was a very obvious/easy surveillance target for such regimes. Personally I think it's possible the Signal Foundation was under a gag order and could not report on this. But I would not rule out cockiness in their own way, to date I've never received a single response to the most basic of questions (back when I was an active user/promoter of their apps) from any of their team dating all the way back to Textsecure days. HN discussed the IME issue around 6 months ago: https://news.ycombinator.com/item?id=25758995 https://news.ycombinator.com/item?id=25758995
mirekrusin 5y ago
Why you're saying this? Bags of sand is fantastic analogy, no?
isatty 5y ago
I would like you, or someone more knowledgeable in the field to argue that the response is not accurate: > Re-ordering Exposed no information about the plaintext and needs additional work to become a fully fledged exploit, patched anyway. > Re-sending: This is a purely theoretical point that has no bearing on the security of messages but is inconvenient for researchers who want to formally analyze the protocol. Researchers being able to analyze the protocol to find faults - good thing. But can't this also work against people trying to break the protocol? > Implementation problems - "For an analogy, imagine a door with multiple locks, one of which could be unlocked — the door to your messages could still not be opened because it had more than one lock" I think this contradicts with the summary above, which is "recover some plaintext", which does not make sense given the analogy. Can someone explain? Possibly the only serious issue found. > RSA Decryption: "This may sound scary but was not possible in practice" If it's not possible in practice that seems like a bunch of other well established crypto protocols I know where it's just infeasible to brute force with currently available non state resources.
- martinralbrecht 5y ago
  1. Re: "needs additional work to become a fully fledged exploit": We have verified this attack in practice, see the paper. 2. We give an example application where it has some "bearing on the security of messages" at the end of https://mtpsym.github.io/ https://mtpsym.github.io/ under the heading "Did we really break IND-CPA?" and in the paper. 3. Perhaps a better analogy is: the remaining door requires the date of birth but luckily they kept that secret. But analogies aside: "Luckily, it is almost impossible to carry out in practice. In particular, it is mostly mitigated by the coincidence that certain metadata in Telegram [a salt and an id] is chosen randomly and kept secret." https://mtpsym.github.io/ https://mtpsym.github.io/ 4. By cryptographic standards the strongest attack as it would imply full compromise if successful. It costs in the order of 2^32 noise-free queries within minutes where it is not clear how many noisy queries are needed to get "one noise-free query" since we didn't want to test it against Telegram's servers. This falls significantly short of "well established crypto protocols [...] where it's just infeasible to brute force" NB: these provide guarantees also against state resources. This does not mean it is a practical concern. The key contribution of our paper, however, is that we prove that MTProto's symmetric cryptography (with some fixes and when implemented carefully) can give you something comparable to TLS (well, it's Record protocol) which is it's closest "competitor". This proof comes with some caveats, though: MTProto is tricky to implement correctly (as highlighted by our attacks on the official clients). Secondly, MTProto relies on unstudied assumptions that you do not need to make if you use just TLS. See "A Somewhat Opinionated Discussion" at https://mtpsym.github.io/ https://mtpsym.github.io/

capableweb 5y ago

Here is the comments from the Telegram team for the technically inclined: https://core.telegram.org/techfaq/UoL-ETH-4a-proof https://core.telegram.org/techfaq/UoL-ETH-4a-proof Linked in the third paragraph of the submission: > The researchers also highlighted several traits of MTProto that were changed as the result of our discussions before the paper was published. This document provides an accessible overview of these changes. For more technical details, see here.

eitland 5y ago

I don't like the way they communicate regarding security, but for context: So far there has been an extreme amount of FUD thrown their way from people who pushed WhatsApp and Signal.

teawrecks 5y ago
> from people who pushed WhatsApp So Facebook?
- eitland 5y ago
  No, I'm thinking about well meaning security people who focused a bit too much on E2E-encryption and forgot that WhatsApp sent metadata in bulk to Facebook and uploaded backups unencrypted to Google and/or iCloud.
  - Ar-Curunir 5y ago
    As opposed to Telegram, where chats are unencrypted by default, and synced to the cloud?
    - eitland 5y ago
      are we a community of technical people or sleazy sales people? What you say about being synced to the cloud in a way that can be decrypted is correct and can be problematic for some people but calling it unencrypted is wrong and detracts from your message.
      - maqp 5y ago
        Saying the database is encrypted when the database key has to sit in the RAM of the server is as disingenuous as saying this is proper way to lock up gems: https://i.imgur.com/0gBOPoQ.png https://i.imgur.com/0gBOPoQ.png You're basically arguing that "you can't say it's not locked when the lock is right there"
        Dah00n 5y ago
        Your comment says nothing about what GP actually stated.
        maqp 5y ago
        Calling Telegram unencrypted isn't practically wrong when the key is stored right next to the data.
        eitland 5y ago
        > Saying the database is encrypted when the database key has to sit in the RAM of the server First you are replying to something I didn't say. Secondly, going down that path and applying it as strictly to everything you'll find that nothing is encrypted: not your communication with the bank, certainly not WhatsApp as it stores temporary databases unencrypted (not only with a password stored in ram) and probably not much else either. In fact I guess if we apply your criteria to Signal clients they are not encrypted either.
joecool1029 5y ago
> I don't like the way they communicate regarding security In general they are cocky but in an expressive way. It is heartening that when papers like this are published they fix the issues despite the PR spin. I've had one email thread interaction with Telegram and it was to unban my account that got banned for messing around with old clients, I can't say they were pleasant but they did answer many of my questions. >So far there has been an extreme amount of FUD thrown their way from people who pushed WhatsApp and Signal. Signal's people did not inform their Android users of the potential for backdoored IME's in places like China for over a year (thankfully their site does mention it now). It was telling that the app was available and usable there until word got out that this was a very obvious/easy surveillance target for such regimes. Personally I think it's possible the Signal Foundation was under a gag order and could not report on this. But I would not rule out cockiness in their own way, to date I've never received a single response to the most basic of questions (back when I was an active user/promoter of their apps) from any of their team dating all the way back to Textsecure days. HN discussed the IME issue around 6 months ago: https://news.ycombinator.com/item?id=25758995 https://news.ycombinator.com/item?id=25758995

mirekrusin 5y ago

Why you're saying this? Bags of sand is fantastic analogy, no?

isatty 5y ago

I would like you, or someone more knowledgeable in the field to argue that the response is not accurate: > Re-ordering Exposed no information about the plaintext and needs additional work to become a fully fledged exploit, patched anyway. > Re-sending: This is a purely theoretical point that has no bearing on the security of messages but is inconvenient for researchers who want to formally analyze the protocol. Researchers being able to analyze the protocol to find faults - good thing. But can't this also work against people trying to break the protocol? > Implementation problems - "For an analogy, imagine a door with multiple locks, one of which could be unlocked — the door to your messages could still not be opened because it had more than one lock" I think this contradicts with the summary above, which is "recover some plaintext", which does not make sense given the analogy. Can someone explain? Possibly the only serious issue found. > RSA Decryption: "This may sound scary but was not possible in practice" If it's not possible in practice that seems like a bunch of other well established crypto protocols I know where it's just infeasible to brute force with currently available non state resources.

martinralbrecht 5y ago
1. Re: "needs additional work to become a fully fledged exploit": We have verified this attack in practice, see the paper. 2. We give an example application where it has some "bearing on the security of messages" at the end of https://mtpsym.github.io/ https://mtpsym.github.io/ under the heading "Did we really break IND-CPA?" and in the paper. 3. Perhaps a better analogy is: the remaining door requires the date of birth but luckily they kept that secret. But analogies aside: "Luckily, it is almost impossible to carry out in practice. In particular, it is mostly mitigated by the coincidence that certain metadata in Telegram [a salt and an id] is chosen randomly and kept secret." https://mtpsym.github.io/ https://mtpsym.github.io/ 4. By cryptographic standards the strongest attack as it would imply full compromise if successful. It costs in the order of 2^32 noise-free queries within minutes where it is not clear how many noisy queries are needed to get "one noise-free query" since we didn't want to test it against Telegram's servers. This falls significantly short of "well established crypto protocols [...] where it's just infeasible to brute force" NB: these provide guarantees also against state resources. This does not mean it is a practical concern. The key contribution of our paper, however, is that we prove that MTProto's symmetric cryptography (with some fixes and when implemented carefully) can give you something comparable to TLS (well, it's Record protocol) which is it's closest "competitor". This proof comes with some caveats, though: MTProto is tricky to implement correctly (as highlighted by our attacks on the official clients). Secondly, MTProto relies on unstudied assumptions that you do not need to make if you use just TLS. See "A Somewhat Opinionated Discussion" at https://mtpsym.github.io/ https://mtpsym.github.io/