
Telegram, a.k.a. “Stand back, we have Math PhDs” - nwh
http://unhandledexpression.com/2013/12/17/telegram-stand-back-we-know-maths/
======
igravious
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.

~~~
nwh
The issue is that they claim their system is secure. Peoples lives can
literally depend on encryption actually doing what it says on the tin; this
software does not. It's the epitome of home grown encryption.

~~~
igravious
I hear you. Agreed. Surely every decent crypto system started off home-grown?

~~~
nwh
There's a line with this sort of stuff, and the crossing of it is what I have
an issue with.

If they presented it as an attempt and asked for critique, then this would
have been a fine thing to publish. They would have got chewed out by a
professional, fixed it or removed it, and everyone would go away learning
something new.

The issues comes when they don't accept critique, and make claims that don't
stack up in actuality. Doing that is how people get hurt.

~~~
smacktoward
Exactly. Being wrong is fine. Being _stubbornly_ wrong is not.

------
Totient
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
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....](http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html)

------
forgottenpass
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."

------
fleitz
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
Read the comments under TFA. Nothing was broken. The author was quick to write
the article without understanding protocol first.

~~~
fleitz
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.

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

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

~~~
MichaelGG
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
The author isn't exactly friendly either...

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

------
andrewflnr

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

~~~
geal
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
Yeah that's generally the downside of cert pinning / hardcoding. The upside is
people can't install extra certs.

------
sturmeh
Well that escalated quickly.

Still, nowhere near as bad as Whatsapp I'm assuming?

~~~
josh2600
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
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
Wickr is closed source.

TextSecure is where it's at. Hopefully the iOS release comes out soon.

------
raphaelcaixeta
Ouch.

