7 ms·

Telegram, a.k.a. “Stand back, we have Math PhDs”

93 points by nwh 13y ago

sturmeh 13y ago
Well that escalated quickly. Still, nowhere near as bad as Whatsapp I'm assuming?
- josh2600 13y ago
  Just use RedPhone. Moxie knows what he's doing and it's auditable + good technology. Whatsapp is a joke, but lower friction matters much more for their market.
  - sleepybrett 13y ago
    Wickr seems like a good goto, though I haven't had the need for it yet, so I haven't done all the research I could.
    - jlund 13y ago
      Wickr is closed source. TextSecure is where it's at. Hopefully the iOS release comes out soon.
  - mst 13y ago
    I'm a happy user of whatsapp. Then again, I'm a happy user under the assumption that everybody everywhere could read my messages if they actually made an effort. I just don't send anything over whatsapp that I really care about - if the world discovers that I regularly tell my girlfriends I love them, that really doesn't bother me.
raphaelcaixeta 13y ago
Ouch.
fleitz 13y ago
Typical NIH syndrome. They hired some smart people who are not cryptographic experts and now their cryptography is broken. Which is pretty much the story for anyone who has ever created a custom cryptographic system (and the story of SSL for the first few years).
- trycatch 13y ago
  Read the comments under TFA. Nothing was broken. The author was quick to write the article without understanding protocol first.
  - fleitz 13y ago
    Analysis looks sound to me, using msg content to derive the key is generally bad form, especially messages are known to attackers and sent repeatedly. (eg. Hi) It looks like a bunch of convoluted code that doesn't actually accomplish anything. Why is sha1_a = SHA1 (msg_key + substr (auth_key, x, 32)); sha1_b = SHA1 (substr (auth_key, 32+x, 16) + msg_key + substr (auth_key, 48+x, 16)); sha1_с = SHA1 (substr (auth_key, 64+x, 32) + msg_key); sha1_d = SHA1 (msg_key + substr (auth_key, 96+x, 32)); aes_key = substr (sha1_a, 0, 8) + substr (sha1_b, 8, 12) + substr (sha1_c, 4, 12); aes_iv = substr (sha1_a, 8, 12) + substr (sha1_b, 0, 8) + substr (sha1_c, 16, 4) + substr (sha1_d, 0, 8); better than sha1_a = SHA1 (msg_key + auth_key); sha1_b = SHA1 (sha1_a); sha1_с = SHA1 (sha1_b); sha1_d = SHA1 (sha1_C); aes_key = SHA1(sha1_a+sha1_b+sha1_c); aes_iv = SHA1(aes_key+sha1_d); and more importantly why is it better than aes_key = RANDOM aes_iv = RANDOM Are there special properties of the random bits of parts of various hashes that makes it more 'random'? To me it looks like repeatedly sending the same message, or a message whose hash varied by a few bits, would leak part of the auth key, basically the person probably doesn't know what they are doing and are just adding extra 'stuff' to assure themselves it's secure.
  - h0cked 13y ago
    The comments from TFA doesn't say a shit but full of "you are wrong, because you don't understand it" without debating the technical details.
saraid216 13y ago
There is also a dialogue between author and Telegram happening in the comments as of right now.
- MichaelGG 13y ago
  Yes, with gems like this one: " We grew tired of “experts” too lazy to read the full documentation. " When asked about a diagram. With their attitude, it seems incredibly unlikely they'll ever have a secure product.
  - zwdr 13y ago
    The author isn't exactly friendly either...
- pmelendez 13y ago
  And after reading that conversation, I can't avoid to feel sympathy for Telegram.
igravious 13y ago
Why so smug? I've seen this attitude in all types of IT heads (sys admins easily being the worst of the bunch) over the years. What is it about techies that they come over so smug when pointing out deficiencies in others? I still have the shame and anger provoking memory of two techies sniggering not-so-openly at me because I didn't know about name service switch in UNIX because guess what, I don't know everything. What happened to good grace and manners or is there no space left in your brain after it is filled up with all the l33t tech guru knowledge? You may be right, but it galls me that you are. Rant over. I wish Telegram all the success in the world. I hope they bulletproof their crypto and add another slick option to the growing list out there to stick it to the man. Must have gotten out of the wrong side of the bed this morning.
- sheepz 13y ago
  This has nothing to do with smugness. If you market your product as a secure alternative, it better be secure.
  - igravious 13y ago
    I understand the importance of security. I do hope Telegram can get it right. I acknowledge it is probably not as secure as they claim right now. I still maintain the article author's attitude just rubs me up the wrong way because of the mood I'm in - the smugness (and I hope I'm not imagining it) is definitely a side issue but one I felt I had to get off my chest. I don't want to make a big issue of it and detract too much from the critique but I felt I had to say it even though HN may not be the bestest place in the world to voice such things. I hear you though.
    - MichaelGG 13y ago
      Given their attitude, it's unlikely they'll get it right. They'll keep telling people "that's not a real attack" and making up excuses. Then someone will publish a real attack, and they'll patch over it. Repeat. The "smugness" is pointing out problems in their implementation, despite them going on about having "ACM champions" that took two years to design it, so it obviously must be perfect. If someone pitched a database that simply mmap'd a file and then called it "fully transactional and safe", they'd get a lot of strong criticism.
andrewflnr 13y ago
They could have made something like: the client generates a key pair, encrypts the public key with the server’s public key, sends it to the server with a nonce, and the server sends back the nonce encrypted with the client’s public key. Simple and easy. Just out of curiosity, is it really that easy if you're using verified components? I would naively assume (and hope) so, but then everyone tells me that crypto is fraught with subtle ways to shoot your users in the feet, including if you misuse verified primitives. If yes, I'll continue making pie-in-the-sky plans using the magic of public-key cryptography. :)
- fleitz 13y ago
  Not really, that is also vulnerable to man in the middle attacks. You need cert pinning or a fool proof trust system to verify the server key.
  - comex 13y ago
    Not if the server key is just hardcoded into the app, which can be appropriate in some cases; of course, that raises the question of how to secure the app download, but that's usually done over a separate protocol anyway.
  - geal 13y ago
    In fact, the app ships with a bunch of RSA 2048 keys that are used for that part. But there is no revocation support.
    - fleitz 13y ago
      Yeah that's generally the downside of cert pinning / hardcoding. The upside is people can't install extra certs.
forgottenpass 13y ago
What's the business model? The app is free, I'm not going to install it but they claim to be ad free too. Are they a charity designed to squirt cyphertext around the globe? Monitoring my behavior to monetize it? freemium? This bit clears it up: PRIVACY: We take your privacy very seriously and will never give third parties access to your data! Oh. So they're marketing an app under the banner of privacy, but architected to enable data collection from me. I can opt into having slightly less data collectable with additional encryption (of questionable quality) on top of their standard service. In an age where the greatest threats to privacy are corporate surveillance and the NSA's legal authority to collect data form businesses, they protect my privacy on exactly zero fronts. Their messaging is either oblivious or underhanded: "We built Telegram to make messaging safe again so you can take back your right to privacy."
Totient 13y ago
Smugness aside, I am actually concerned about this implementation and Telegram's response: > The rest looks like matters of taste as opposed to objective reasoning. Can you name an actual attack? The response to that is, "I shouldn't have to!" Anything that replaces a proven secure component with something that we haven't (yet) found an attack on is grounds for suspicion at the very least. SHA-1 isn't a MAC. It's not that hard to make it so (HMAC), but Telegram hasn't. > Again, we do not use MAC-then-encrypt. Our scheme is closer to MAC-and-encrypt with some essential modifications. Out of the three options: MAC then encrypt, encrypt then MAC, and MAC and encrypt, only encrypt then MAC is secure (http://cseweb.ucsd.edu/~mihir/papers/oem.pdf http://cseweb.ucsd.edu/~mihir/papers/oem.pdf) I don't care if they've made "essential modifications", they're replacing a component that is provably secure, with one that may or may not be secure.
- ispivey 13y ago
  Agreed. To quote Colin Percival's excellent article which addresses both topics: "Assessing the security of software via the question "can we find any security flaws in it?" is like assessing the structure of a bridge by asking the question "has it collapsed yet?" -- it is the most important question, to be certain, but it also profoundly misses the point. Engineers design bridges with built-in safety margins in order to guard against unforeseen circumstances (unexpectedly high winds, corrosion causing joints to weaken, a traffic accident severing support cables, et cetera); secure software should likewise be designed to tolerate failures within individual components. Using a MAC to make sure that an attacker cannot exploit a bug (or a side channel) in encryption code is an example of this approach: If everything works as designed, this adds nothing to the security of the system; but in the real world where components fail, it can mean the difference between being compromised or not. The concept of "security in depth" is not new to network administrators; but it's time for software engineers to start applying the same engineering principles within individual applications as well." http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac....
h0cked 13y ago
The Math PhD who designed the should write the protocol up as a paper, submit to top conferences like CCS and S&P. And he will see how badly the reviewers will dump on his protocol.
vinceguidry 13y ago
That they have not made available a threat model is the kicker for me. Every time people start talking about security, whether it's their email or their house, inevitably they start going nuts with all the possibilities. They then leave real security against real threats at the door in order to deal with imagined ones that require far greater resources to secure against. I'd bet that many fortunes were made by security 'professionals' catering to these whims. The threat model is the antidote to this tomfoolery. Before you even start to touch a primitive, sit down and think very hard about who you're trying to be secure against and what their available options for attacking you are. Then write this analysis down and make it a living document, referring to it constantly to make sure that what you're writing is actually protecting you from something and what and how it's doing that. I'd go so far as to say that without such a document, a system cannot possibly be secure because it doesn't know what it's doing. What's more, the poor team in charge of maintaining and updating it is going to be forever behind the curve, reduced to putting out fires whenever they pop up, be it from external actors actually breaking their code or from their own ignorance introducing vulnerabilities that weren't there before because their updates didn't take into account the non-existent threat model.

93 points by nwh 13y ago

sturmeh 13y ago

Well that escalated quickly. Still, nowhere near as bad as Whatsapp I'm assuming?

josh2600 13y ago
Just use RedPhone. Moxie knows what he's doing and it's auditable + good technology. Whatsapp is a joke, but lower friction matters much more for their market.
- sleepybrett 13y ago
  Wickr seems like a good goto, though I haven't had the need for it yet, so I haven't done all the research I could.
  - jlund 13y ago
    Wickr is closed source. TextSecure is where it's at. Hopefully the iOS release comes out soon.
- mst 13y ago
  I'm a happy user of whatsapp. Then again, I'm a happy user under the assumption that everybody everywhere could read my messages if they actually made an effort. I just don't send anything over whatsapp that I really care about - if the world discovers that I regularly tell my girlfriends I love them, that really doesn't bother me.

raphaelcaixeta 13y ago

Ouch.

fleitz 13y ago

Typical NIH syndrome. They hired some smart people who are not cryptographic experts and now their cryptography is broken. Which is pretty much the story for anyone who has ever created a custom cryptographic system (and the story of SSL for the first few years).

trycatch 13y ago
Read the comments under TFA. Nothing was broken. The author was quick to write the article without understanding protocol first.
- fleitz 13y ago
  Analysis looks sound to me, using msg content to derive the key is generally bad form, especially messages are known to attackers and sent repeatedly. (eg. Hi) It looks like a bunch of convoluted code that doesn't actually accomplish anything. Why is sha1_a = SHA1 (msg_key + substr (auth_key, x, 32)); sha1_b = SHA1 (substr (auth_key, 32+x, 16) + msg_key + substr (auth_key, 48+x, 16)); sha1_с = SHA1 (substr (auth_key, 64+x, 32) + msg_key); sha1_d = SHA1 (msg_key + substr (auth_key, 96+x, 32)); aes_key = substr (sha1_a, 0, 8) + substr (sha1_b, 8, 12) + substr (sha1_c, 4, 12); aes_iv = substr (sha1_a, 8, 12) + substr (sha1_b, 0, 8) + substr (sha1_c, 16, 4) + substr (sha1_d, 0, 8); better than sha1_a = SHA1 (msg_key + auth_key); sha1_b = SHA1 (sha1_a); sha1_с = SHA1 (sha1_b); sha1_d = SHA1 (sha1_C); aes_key = SHA1(sha1_a+sha1_b+sha1_c); aes_iv = SHA1(aes_key+sha1_d); and more importantly why is it better than aes_key = RANDOM aes_iv = RANDOM Are there special properties of the random bits of parts of various hashes that makes it more 'random'? To me it looks like repeatedly sending the same message, or a message whose hash varied by a few bits, would leak part of the auth key, basically the person probably doesn't know what they are doing and are just adding extra 'stuff' to assure themselves it's secure.
- h0cked 13y ago
  The comments from TFA doesn't say a shit but full of "you are wrong, because you don't understand it" without debating the technical details.

saraid216 13y ago

There is also a dialogue between author and Telegram happening in the comments as of right now.

MichaelGG 13y ago
Yes, with gems like this one: " We grew tired of “experts” too lazy to read the full documentation. " When asked about a diagram. With their attitude, it seems incredibly unlikely they'll ever have a secure product.
- zwdr 13y ago
  The author isn't exactly friendly either...
pmelendez 13y ago
And after reading that conversation, I can't avoid to feel sympathy for Telegram.

igravious 13y ago

Why so smug? I've seen this attitude in all types of IT heads (sys admins easily being the worst of the bunch) over the years. What is it about techies that they come over so smug when pointing out deficiencies in others? I still have the shame and anger provoking memory of two techies sniggering not-so-openly at me because I didn't know about name service switch in UNIX because guess what, I don't know everything. What happened to good grace and manners or is there no space left in your brain after it is filled up with all the l33t tech guru knowledge? You may be right, but it galls me that you are. Rant over. I wish Telegram all the success in the world. I hope they bulletproof their crypto and add another slick option to the growing list out there to stick it to the man. Must have gotten out of the wrong side of the bed this morning.

sheepz 13y ago
This has nothing to do with smugness. If you market your product as a secure alternative, it better be secure.
- igravious 13y ago
  I understand the importance of security. I do hope Telegram can get it right. I acknowledge it is probably not as secure as they claim right now. I still maintain the article author's attitude just rubs me up the wrong way because of the mood I'm in - the smugness (and I hope I'm not imagining it) is definitely a side issue but one I felt I had to get off my chest. I don't want to make a big issue of it and detract too much from the critique but I felt I had to say it even though HN may not be the bestest place in the world to voice such things. I hear you though.
  - MichaelGG 13y ago
    Given their attitude, it's unlikely they'll get it right. They'll keep telling people "that's not a real attack" and making up excuses. Then someone will publish a real attack, and they'll patch over it. Repeat. The "smugness" is pointing out problems in their implementation, despite them going on about having "ACM champions" that took two years to design it, so it obviously must be perfect. If someone pitched a database that simply mmap'd a file and then called it "fully transactional and safe", they'd get a lot of strong criticism.

andrewflnr 13y ago

They could have made something like: the client generates a key pair, encrypts the public key with the server’s public key, sends it to the server with a nonce, and the server sends back the nonce encrypted with the client’s public key. Simple and easy. Just out of curiosity, is it really that easy if you're using verified components? I would naively assume (and hope) so, but then everyone tells me that crypto is fraught with subtle ways to shoot your users in the feet, including if you misuse verified primitives. If yes, I'll continue making pie-in-the-sky plans using the magic of public-key cryptography. :)

fleitz 13y ago
Not really, that is also vulnerable to man in the middle attacks. You need cert pinning or a fool proof trust system to verify the server key.
- comex 13y ago
  Not if the server key is just hardcoded into the app, which can be appropriate in some cases; of course, that raises the question of how to secure the app download, but that's usually done over a separate protocol anyway.
- geal 13y ago
  In fact, the app ships with a bunch of RSA 2048 keys that are used for that part. But there is no revocation support.
  - fleitz 13y ago
    Yeah that's generally the downside of cert pinning / hardcoding. The upside is people can't install extra certs.

forgottenpass 13y ago

What's the business model? The app is free, I'm not going to install it but they claim to be ad free too. Are they a charity designed to squirt cyphertext around the globe? Monitoring my behavior to monetize it? freemium? This bit clears it up: PRIVACY: We take your privacy very seriously and will never give third parties access to your data! Oh. So they're marketing an app under the banner of privacy, but architected to enable data collection from me. I can opt into having slightly less data collectable with additional encryption (of questionable quality) on top of their standard service. In an age where the greatest threats to privacy are corporate surveillance and the NSA's legal authority to collect data form businesses, they protect my privacy on exactly zero fronts. Their messaging is either oblivious or underhanded: "We built Telegram to make messaging safe again so you can take back your right to privacy."

Totient 13y ago

Smugness aside, I am actually concerned about this implementation and Telegram's response: > The rest looks like matters of taste as opposed to objective reasoning. Can you name an actual attack? The response to that is, "I shouldn't have to!" Anything that replaces a proven secure component with something that we haven't (yet) found an attack on is grounds for suspicion at the very least. SHA-1 isn't a MAC. It's not that hard to make it so (HMAC), but Telegram hasn't. > Again, we do not use MAC-then-encrypt. Our scheme is closer to MAC-and-encrypt with some essential modifications. Out of the three options: MAC then encrypt, encrypt then MAC, and MAC and encrypt, only encrypt then MAC is secure (http://cseweb.ucsd.edu/~mihir/papers/oem.pdf http://cseweb.ucsd.edu/~mihir/papers/oem.pdf) I don't care if they've made "essential modifications", they're replacing a component that is provably secure, with one that may or may not be secure.

ispivey 13y ago
Agreed. To quote Colin Percival's excellent article which addresses both topics: "Assessing the security of software via the question "can we find any security flaws in it?" is like assessing the structure of a bridge by asking the question "has it collapsed yet?" -- it is the most important question, to be certain, but it also profoundly misses the point. Engineers design bridges with built-in safety margins in order to guard against unforeseen circumstances (unexpectedly high winds, corrosion causing joints to weaken, a traffic accident severing support cables, et cetera); secure software should likewise be designed to tolerate failures within individual components. Using a MAC to make sure that an attacker cannot exploit a bug (or a side channel) in encryption code is an example of this approach: If everything works as designed, this adds nothing to the security of the system; but in the real world where components fail, it can mean the difference between being compromised or not. The concept of "security in depth" is not new to network administrators; but it's time for software engineers to start applying the same engineering principles within individual applications as well." http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac....

h0cked 13y ago

The Math PhD who designed the should write the protocol up as a paper, submit to top conferences like CCS and S&P. And he will see how badly the reviewers will dump on his protocol.

vinceguidry 13y ago

That they have not made available a threat model is the kicker for me. Every time people start talking about security, whether it's their email or their house, inevitably they start going nuts with all the possibilities. They then leave real security against real threats at the door in order to deal with imagined ones that require far greater resources to secure against. I'd bet that many fortunes were made by security 'professionals' catering to these whims. The threat model is the antidote to this tomfoolery. Before you even start to touch a primitive, sit down and think very hard about who you're trying to be secure against and what their available options for attacking you are. Then write this analysis down and make it a living document, referring to it constantly to make sure that what you're writing is actually protecting you from something and what and how it's doing that. I'd go so far as to say that without such a document, a system cannot possibly be secure because it doesn't know what it's doing. What's more, the poor team in charge of maintaining and updating it is going to be forever behind the curve, reduced to putting out fires whenever they pop up, be it from external actors actually breaking their code or from their own ignorance introducing vulnerabilities that weren't there before because their updates didn't take into account the non-existent threat model.