[cflee]

Does anyone have an opinion on the new "three-message modification of the standard DH key exchange" they introduced for calls?

From their API doc: https://core.telegram.org/api/end-to-end/voice-calls#key-ver...

> Party A will generate a shared key with B — or whoever pretends to be B — without having a second chance to change its exponent a depending on the value g_b received from the other side; and the impostor will not have a chance to adapt his value of b depending on g_a, because it has to commit to a value of g_b before learning g_a.

> The use of hash commitment in the DH exchange constrains the attacker to only one guess to generate the correct visualization in their attack, which means that using just over 33 bits of entropy represented by four emoji in the visualization is enough to make a successful attack highly improbable.

[lucb1e]

I like it. I tried to explain it in slightly simpler terms to some friends in a group chat like this:

> reading about the emoticon generation thingy, it's actually worth a read

> they use a DH KEX[1], but wrapped with something which is interesting. Client A generates a, client B generates b, and g seems to be an already-exchanged finite group generator. That's all standard.

[1] diffie-hellman key exchange

> now before A sends g^a to B, it will send hash(g^a) to B. B responds as normal (with g^b) to which A will respond with what it normally would send first: g^a.

> after receiving g^a, B can check whether the initially received hash(g^a) matches. This means that A can't brute force a specific value of a, so it doesn't matter that it's only 33 bits of entropy in that emoticon thingy. Any brute forcing will change the hash (unless you collide, iirc, sha256) and B will go "dude wtf" and kill the connection

> I tried to summarize in more understandable terms, but if it's too shortened or something, the original thing is here: https://core.telegram.org/api/end-to-end/voice-calls#key-ver...

[stouset]

I haven't personally reviewed it, but based on their previous inability to make principled cryptographic choices and resistance to critical feedback from actual cryptographers… I'm skeptical.

[cyphunk]

can you point to some examples where the resisted critical feedback? I've heard people mention this but haven't actually seen anything convincing yet

[ecthiender]

Read up the comments on the telegram announcement post here on HN. From couple of years back, IIRC.

PS: on mobile. Could not.search.

[cyphunk]

Found it [1].

tldr: First message from TelegramApp has some marketing copy ("acm winner phds") but not horrible. The TelegramApp user remains calm/careful and mostly polite in every message after that. There are only a few cases of sideways slapping and they come from HN users. Despite this the conversation between TelegramApp and HN users remain informative debate and discussion.

1. https://news.ycombinator.com/item?id=6913456

[stouset]

Being cordial and polite on Hacker News wasn't my concern. My concern is their repeated dismissal of feedback from experienced cryptographers.

Cryptographers can't seem to make sense of a lot of their design decisions in the MTProto protocol. Their response to criticism has mostly been in the form of: if you can't demonstrate a break directly, then we don't care.

Given how fragile cryptography can be, this is an absurdly irresponsible way to maintain a cryptosystem. Modern cryptographic designs try to be very principled, and steps are taken to prevent any kind of theoretical weakness, even if we don't know how to break it in practice. This is because cryptographic breaks only ever get stronger — never weaker.

As an example, TLS 1.0 using doing authentication for CBC modes with MAC-then-Encrypt was known to be weak, but it was only years later when researchers were able to turn this into a plaintext-leaking break. And MTProto is absolutely littered with unconventional or known-weak constructs, giving a lot of potential levers attackers can use to break it.

You might argue that it's fine for this to be the case, as long as they respond quickly to protocol breaks. The problem is, the good guys only learned how to break TLS 1.0 CBC when the attack was published. Did the NSA/CIA/GRU/FSB know about these attacks before we did? There's no way to know. But if it had conservatively chosen an Encrypt-then-MAC scheme to begin with, such an attack would have never been possible in the first place.

That's not to throw the TLS 1.0 authors under the bus here. The weaknesses of that type of scheme were yet to be widely known. In the case of MTProto, weaknesses in their use of certain constructs are widely known, and they don't seem o care.

[cyphunk]

I read through the linked thread in my previous post and I think it gives a good idea of the rift between the in-house-HN-cryptographers and those at Telegram. One will find the exact same disconnect between cryptographers that worked under heavy computational constraints, and those that have not. For example, in the Satellite TV industry.

The Telegram designers built a protocol with anticipation of some constraints. But rather than debate the plausability of the percieved constraints, the HN-crowd just dug into whatever they already knew and threw in a lot of snark in their response to close the door.

> Their response to criticism has mostly been in the form of: if you can't demonstrate a break directly, then we don't care.

I haven't seen that. I went looking for it. If you have the patience and time please dig up a link or quote.

> That's not to throw the TLS 1.0 authors under the bus here. The weaknesses of that type of scheme were yet to be widely known. In the case of MTProto, weaknesses in their use of certain constructs are widely known, and they don't seem o care.

I did see a good bit of discussion about the feasability of some of the weakness pointed out. They responded in a way that seemed to indicate they fully understood the issue but "chose" to take the risk. I'm not sure this means "they don't care". Perhaps it does. But this is where I started to see that the rift here was really about the perception of constraints, not lack of knowledge or, in my opinion, lack of care.

[magic_quotes]

https://news.ycombinator.com/threads?id=paveldurov

By the way, it is also worth noting that Nikolai Durov, designer of MTProto, is completely absent from any public discussions of that protocol. Doesn't like talking to the plebs, I suppose.

[StavrosK]

That just sounds like ZRTP to me, from the short description in your comment.

[Johnny_Brahms]

If it is it will be interesting to see if they managed to get zrtp correct. It is a pretty complicated protocol with many use cases.