> Anyway, it’s been a while, the world is a different place now, and maybe Hanlon’s razor cuts deeper than I thought.<p>I don't think people give credit for just how deep this actually does cut. On one project I worked on, which stored obscenely sensitive information, their product manager gave a speech about password security and told us he had a better algorithm than bcrypt. You couldn't explain why this was a bad idea - he wasn't taking feedback. When it landed, I found the botched the algorithm so this "sql injection detection code" basically changed every character to a ' mark. You just needed the right number in a password and it would always match.
So I logged a bug, used it to push that they just use bcrypt, I got a big story about how he knows exactly what he was doing and he would fix the bug. It was "fixed" for a few days. Apparently what happened was, the developer didn't know how to use git properly and copied an older file on top the repo and brought the bug back. After it was known, disclosed, and every one was told it was fixed.
The algorithm turned out to only handle a-z, and every other character was left in place. So I went though this again. Same speech about incredibly great design. They could have easily snuck a backdoor in because I never looked at 90% of the code, but this ongoing nonsense was 100% Hanlon's razor.
The most backdoor-looking feature for me in supposedly encrypted systems are cloud backups. They are “optional” yet most users will agree (especially when given software constantly nags about it until you give up) and their backups will leak both sides of conversations, despite all end-to-end encryption attempts.
- Clickbait title: Check.<p>- Half-admission that the clickbait title might not apply (at the end of the article by mentioning Hanlon's Razor): Check.<p>- Actual good criticism on "don't roll your own crypto": Check (this is not a sarcasm, I liked that part of the article very much).<p>- Casual mention that the incident is from 7 years ago but implying that <i>today</i> there's a backdoor: Check.<p>- HN going crazy negative when Telegram is mentioned, as it always happens: Check.<p>---<p>I am not shilling for Telegram. I have no reason to. I can switch to Signal with my most important contacts in the space of one hour if I wanted to. I never invested any money in them either. I won't get sad if they get nuked from orbit tomorrow.<p>But it's really baffling how non-constructive most Telegram HN coverage is, both articles and comments. Sure, they have no bulletproof end-to-end encryption of messages. So, like 99.9% of all apps on all app stores then? Some generic marketing on the homepage using vaguely non-accurate language ("secure chats")? So, again, like 99.9% of the apps that have a page and put marketing lingo on them?<p>What's so uniquely awful about Telegram?<p>It's legitimately intriguing how hostile HN gets at the mention of Telegram. There might be some interesting sociological study hidden there somewhere.
Does anyone have any inside info on this? If we don't assume malice, what is the reason Telegram is rolling its own non-standard crypto like this? Were there no widely publicized E2E protocols that would fit the bill at the time Telegram was being developed? (i.e. was it started before Signal had become known, or does that protocol have limitations that Telegram found unacceptable?) Or did the team have someone in charge with a bit of not-invented-here-syndrome that was just gung-ho on rolling their own no matter what? (wouldn't be the first time something like that has happened). And has any effort been made to validate the protocol, despite being a bit weird, so we might eventually trust it as much as Signal?
If any clients had been logging that nonce, we could retrospectively catch any person in the middle.<p>Far too few services do strategic logging of data useful to catch attackers like this. Many attackers won't attack if they know traces will be left which can point to them.
> Most backdoor looking bug<p>While a backdoor is not a bug but a feature, it helps to disguise a backdoor as a bug (i.e. plausible deniability). I know of one instance (in MS Windows) where the backdoor feature was not even hidden so much:<p><a href="https://en.wikipedia.org/wiki/NSAKEY" rel="nofollow">https://en.wikipedia.org/wiki/NSAKEY</a><p>That's why we need opensource. It's a hedge against tyranny.
And obligatory reference to Backdoored Streebog cipher : <a href="https://eprint.iacr.org/2016/071" rel="nofollow">https://eprint.iacr.org/2016/071</a> <a href="https://www.sstic.org/media/SSTIC2019/SSTIC-actes/RussianStyleRandomness/SSTIC2019-Article-RussianStyleRandomness-perrin_bonnetain.pdf" rel="nofollow">https://www.sstic.org/media/SSTIC2019/SSTIC-actes/RussianSty...</a><p>The backdoor was hidden in the plain sight: the s-box was said to be randomly picked, but years long evasive answers of authors about cryptographic properties of the box made people to think that there was something really not right with it.<p>If not for that specifically putting aim at the s-box, there would have been no chance anybody found that.<p>3 years later, and Perrin's paper comes, and it is discovered that almost a new domain of math is buried in that s-box.<p>Nobody yet discovered what unusual math properties of that s-box do, but nobody now doubts it being a backdoor of some kind.
TL;DR<p>A TG server was sending a "salt" to clients in order to randomize keys (telegram claim) when in fact the "salt" turned out useless in terms of encryption and the only reasonable explanation for the "nonce" was using it as a backdoor to perform MITM attack.<p>You decide whether it was done intenionally or because of lack of sleep/understanding<p>PS. an original author got 100k$ for finding/exposing a potential backdoor.
Another libelous post by US government affiliated "cryptographer". Perhaps next we will see other familiar faces chipping in like tptacek from matasano )<p>Impossible to succeed at this level without making a few enemies.