5 ms·
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
by cflee 9y ago
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-verification 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.
- StavrosK 9y agoThat just sounds like ZRTP to me, from the short description in your comment.
- Johnny_Brahms 9y agoIf 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.
- lucb1e 9y agoI 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-verification https://core.telegram.org/api/end-to-end/voice-calls#key-ver...
- stouset 9y agoI 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 9y agocan 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 9y agoRead up the comments on the telegram announcement post here on HN. From couple of years back, IIRC. PS: on mobile. Could not.search.
- cyphunk 9y agoFound 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 https://news.ycombinator.com/item?id=6913456
- magic_quotes 9y agohttps://news.ycombinator.com/threads?id=paveldurov 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.
- stouset 9y agoBeing 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.