5 ms·

Verification in band seems pretty meaningless, approaching security theatre.

by RL_Quine 5y ago

nitrogen 5y ago
For voice? It's hard to fake the voice of someone you know.
- Muromec 5y ago
  you don't have to fake the voice, just mitm and record cleartext
  - ajsnigrutin 5y ago
    But they have to fake the voice, if I call the other person and say "my emoji sequence is this, this and that" for the other person to verify and vice-versa.
    - wizzwizz4 5y ago
      Person A calls you. I intercept the call, so person A is calling me, and then I call you (spoofing so I look like Person A). When you pick up, I pick up, then I transmit what you're saying to Person A (and vice versa). How do you know I'm intercepting the transmission? Does the emoji sequence verify the call, perhaps?
      - summm 5y ago
        Both connections would show different emojis on both sides then. So you would need to somehow deep fake the voice of the one telling their emojis to the other one.
      - tshaddox 5y ago
        The emoji sequence is a hash of the secret key values generated as part of a modified/extended version of the Diffie-Hellman key exchange. The emoji sequence is generated and displayed independently on both devices before the final necessary key exchange message is transmitted over the wire, so a man-in-the-middle has no way of modifying messages in flight to ensure that both parties end up generating the same emoji sequence. I'm not a cryptographer, but that's what I glean from their explanation: https://core.telegram.org/api/end-to-end/video-calls#key-verification https://core.telegram.org/api/end-to-end/video-calls#key-ver...
      - marcan_42 5y ago
        The emoji sequence represents the secret key exchange between you and the other party. If you intercept the call, you are making one key exchange with person A, and another key exchange with person B. Due to the mathematics involved, there is no way for you to force both key exchanges to yield the same result. For a "standard" DH key exchange it would be possible to brute force the emoji sequence to be the same (since it's too short to be resistant to brute forcing), but the protocol that Telegram uses specifically defends against that by having both sides commit to their share of the key ahead of time, so they cannot try different numbers. https://core.telegram.org/api/end-to-end/video-calls#key-verification https://core.telegram.org/api/end-to-end/video-calls#key-ver... So person A and person B are going to see different emojis no matter what you do. To fake a phone verification while performing a main-in-the-middle attack you'd also have to fake their voices to each other. That's hard.
      - ajsnigrutin 5y ago
        If i'm talking to a person I know in person, I'd recognise their voice.
Andrew_nenakhov 5y ago
Real privacy is too burdensome for most users, so they feel just fine if the service owner promises in a stern voice that their chats are really secure. It is not necessary to provide real security, do fingerprint verification, etc if the users are already happy with the level of security they are promised.
- marcan_42 5y ago
  The emoji comparison thing is mathematically solid. Assuming the clients aren't backdoored (and the Telegram client is open source, so that's not that easy), there is no way for an attacker to make both sides show the same emoji. If they want to convince two users that they have en E2EE connection while performing a man in the middle attack, they'd have to fake their voices to each other to change what emoji sequence they each read out. That's hard, and therefore this is real, meaningful privacy.
  - Andrew_nenakhov 5y ago
    Telegram can potentially perform mitm at any time and generate matching emoji images for both sides of conversation, since you can't really trust the app code to be the same they put on GitHub. If you've built it yourself, that'd reduce the risk, but nobody does that because blind trust is much more easy.
    - to11mtm 5y ago
      This is true, and IMHO somewhere that App-Stores could potentially assist in building trust for OSS Apps being distributed. What I'm envisioning is a 'build hash' that is reproducible based on the public source code with a given set of compiler settings (i.e. same used for publish.) The systems app-management widget could then display this build hash in the app-check menu. This would likely require more care in packaging, as well as some form of secure config API that allows companies to provide certain bits of configuration (i.e. remote servers to contact) without impacting the build output. This would mean that yes, people would still need to audit the code, but at least it's easy for anyone to canary out to the internet that the hashes are mismatching, same for when someone does find something on an audit. OTOH, I'm sure Telegram's competitors in the chat space would love a reason to de-legitimize them, so it wouldn't surprise me if -someone- out there was already doing some sort of compare on published builds.

Verification in band seems pretty meaningless, approaching security theatre.

nitrogen 5y ago

For voice? It's hard to fake the voice of someone you know.

Muromec 5y ago
you don't have to fake the voice, just mitm and record cleartext
- ajsnigrutin 5y ago
  But they have to fake the voice, if I call the other person and say "my emoji sequence is this, this and that" for the other person to verify and vice-versa.
  - wizzwizz4 5y ago
    Person A calls you. I intercept the call, so person A is calling me, and then I call you (spoofing so I look like Person A). When you pick up, I pick up, then I transmit what you're saying to Person A (and vice versa). How do you know I'm intercepting the transmission? Does the emoji sequence verify the call, perhaps?
    - summm 5y ago
      Both connections would show different emojis on both sides then. So you would need to somehow deep fake the voice of the one telling their emojis to the other one.
    - tshaddox 5y ago
      The emoji sequence is a hash of the secret key values generated as part of a modified/extended version of the Diffie-Hellman key exchange. The emoji sequence is generated and displayed independently on both devices before the final necessary key exchange message is transmitted over the wire, so a man-in-the-middle has no way of modifying messages in flight to ensure that both parties end up generating the same emoji sequence. I'm not a cryptographer, but that's what I glean from their explanation: https://core.telegram.org/api/end-to-end/video-calls#key-verification https://core.telegram.org/api/end-to-end/video-calls#key-ver...
    - marcan_42 5y ago
      The emoji sequence represents the secret key exchange between you and the other party. If you intercept the call, you are making one key exchange with person A, and another key exchange with person B. Due to the mathematics involved, there is no way for you to force both key exchanges to yield the same result. For a "standard" DH key exchange it would be possible to brute force the emoji sequence to be the same (since it's too short to be resistant to brute forcing), but the protocol that Telegram uses specifically defends against that by having both sides commit to their share of the key ahead of time, so they cannot try different numbers. https://core.telegram.org/api/end-to-end/video-calls#key-verification https://core.telegram.org/api/end-to-end/video-calls#key-ver... So person A and person B are going to see different emojis no matter what you do. To fake a phone verification while performing a main-in-the-middle attack you'd also have to fake their voices to each other. That's hard.
    - ajsnigrutin 5y ago
      If i'm talking to a person I know in person, I'd recognise their voice.

Andrew_nenakhov 5y ago

Real privacy is too burdensome for most users, so they feel just fine if the service owner promises in a stern voice that their chats are really secure. It is not necessary to provide real security, do fingerprint verification, etc if the users are already happy with the level of security they are promised.

marcan_42 5y ago
The emoji comparison thing is mathematically solid. Assuming the clients aren't backdoored (and the Telegram client is open source, so that's not that easy), there is no way for an attacker to make both sides show the same emoji. If they want to convince two users that they have en E2EE connection while performing a man in the middle attack, they'd have to fake their voices to each other to change what emoji sequence they each read out. That's hard, and therefore this is real, meaningful privacy.
- Andrew_nenakhov 5y ago
  Telegram can potentially perform mitm at any time and generate matching emoji images for both sides of conversation, since you can't really trust the app code to be the same they put on GitHub. If you've built it yourself, that'd reduce the risk, but nobody does that because blind trust is much more easy.
  - to11mtm 5y ago
    This is true, and IMHO somewhere that App-Stores could potentially assist in building trust for OSS Apps being distributed. What I'm envisioning is a 'build hash' that is reproducible based on the public source code with a given set of compiler settings (i.e. same used for publish.) The systems app-management widget could then display this build hash in the app-check menu. This would likely require more care in packaging, as well as some form of secure config API that allows companies to provide certain bits of configuration (i.e. remote servers to contact) without impacting the build output. This would mean that yes, people would still need to audit the code, but at least it's easy for anyone to canary out to the internet that the hashes are mismatching, same for when someone does find something on an audit. OTOH, I'm sure Telegram's competitors in the chat space would love a reason to de-legitimize them, so it wouldn't surprise me if -someone- out there was already doing some sort of compare on published builds.