[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.