Previously: <a href="https://news.ycombinator.com/item?id=25726068" rel="nofollow">https://news.ycombinator.com/item?id=25726068</a> (2021)<p>I am moving my newsletter archives to my blog, and the issues must have hit the RSS feed, even if the pages are not well annotated yet.
I remember seeing this bug years ago. As Filippo mentions at the end, I'm still not sure whether to attribute this to malice or incompetence as per Hanlon's razor. I have not really followed what's up with Telegram lately, but I recall they had a rather brusque attitude towards the cryptography community at the time: "we have maths PhDs!", "Here's an encrypted message with no other context whatsoever: 0x459457453494530453409abc74f, $1 million if you can break it. No? Didn't think so!". To be honest, their consistent hubris at the time combined with (as far as I'm aware?) no other suspicious code (in the sense of backdoors, not just weird crypto) since, actually leads me to think it might genuinely be incompetence rather than a deliberate backdoor. I do think it's true that the security community can be a little outraged and not very welcoming to newcomers in the space if they get anything wrong: even Signal, pretty much the gold standard, receives constant (in my opinion, unfair) criticism for not being federated. Though, given the high stakes, I suppose this can be forgiven.
> Can we talk about how cool the Wayback Machine Compare feature is?<p>I consider myself an Internet Archive power-user; I spend hours playing with CDX queries, t̶r̶o̶l̶l̶i̶n̶g̶ trawling the archive for interesting tidbits that have been lost to time. I have spent countless evenings building scripts based on the internetarchive (<a href="https://github.com/jjjake/internetarchive" rel="nofollow">https://github.com/jjjake/internetarchive</a>) and iamine (<a href="https://github.com/jjjake/iamine" rel="nofollow">https://github.com/jjjake/iamine</a>) tools (along with a host of others).<p>I am utterly ashamed I had never heard of the /diff/ feature between pages until I read your article. Thank you for bringing this to my attention! I am continuously impressed by the work they do at IA.
> The Telegram key exchange is described in the "Key Generation" section of Telegram's end-to-end API docs. Concretely, Alice requests the DH parameters (p, g) from Telegram, painstakingly verifies them, computes a random a value, and sends g^a mod p to Telegram. Bob receives (p, g, g^a mod p), similarly computes b and g^b mod p, and sends the latter back (along with a truncated hash of the derived key, for some reason).<p>I assume the reason is that the recipient of the truncated hash can validate that they've derived the same key without exposing it. This makes it way more straightforward to reject invalid keys. Truncating the hash is pointless but I get why they'd do it - it doesn't "hurt" since ultimately decryption will (hopefully) fail with an invalid key and this is just a shortcut to commit to a specific key.<p>Otherwise, a really interesting example of thinking "I'll add a nonce here, that'll make things safer!" and getting the exact opposite result.
If you're trying to hide a backdoor in a more subtle way than leaving a telnet port open, disguising it as a bug is not a bad way to go. Much less work than, say, finagling your own magic numbers into a new crypto standard.<p>Anyway, Telegram MTProto backdoored; this never was a surprise to anyone I guess.
>In a normal PitM, the server negotiates two separate Diffie-Hellman sessions with Alice and Bob, who end up with different shared keys, which they could detect by comparing fingerprints.<p>I think that normally A and B would compare whatever they were using for long term identity and not the shared key they got from a DH exchange. So that would be the fingerprint of some sort of public key from some signature scheme. There is a tendency to throw away the results of the DH exchange as part of a forward secrecy scheme and the users would not want to have to compare fingerprints constantly.<p>Does Telegram do something different?<p>Edit: Sort of answering my own question. Apparently each secret chat is self contained. You are supposed to verify your fingerprints when you start one. If you start another one you then would have to check the fingerprint again. This suggests that Telegram secret chats are indefinite and can stick around for a long time. I guess that is one way to simplify identity management. That also suggests that the forward secrecy is per secret chat session. It only kicks in when you end the secret chat.
What's an action that two people on different sides of a mirror can take in order to demonstrate a common commitment towards progress (despite mistakes)?