
Telegram’s Cryptanalysis Contest - svv
http://www.cryptofails.com/post/70546720222/telegrams-cryptanalysis-contest
======
venomsnake
Is there a reason why all fad "secure" products lately default to custom
protocols and exotic solutions instead of using well tested and trusted
solutions?

Designing a protocol so that is does not leak is very hard.

~~~
peteretep
Unique Selling Point

~~~
venomsnake
Well create metadata resistant protocol that communicates on set intervals of
time with set length of random data when there is no real payload. This could
be done on TLS with little or no effort. The math behind the crypto is strong
enough. No need to harden it further.

Every client sends and receives 16KB blob every 30 seconds - this way you
could prevent analysis that you are communicating with someone. You could
learn a lot just from the size and frequency of packets in a normal chat
program.

~~~
oakwhiz
It seems like there is a 'No-Free-Lunch' tradeoff between bandwidth efficiency
and traffic analysis resistance.

~~~
venomsnake
I prefer the later to the former in a heartbeat.

------
xerophtye
With all the publicity TextSecure is getting from all this Telegram Debacle, I
am beginning to suspect telegram isn't even a real company, and just a very
elaborate publicity stunt by Moxie and the rest of the TextSecure team!! :P

~~~
vitalyny
By the comments it seems that most of the active haters of Telegram are
TextSecure team. Yes, they want publicity and funding - and who doesn't?

~~~
chris_wot
"Haters" is a very emotive term. There is no real hate I can detect form the
TextSecure team. They have just pointed out flaws and why they feel that the
solution is flawed.

You wouldn't be associated with Telegram, by any chance?

~~~
vitalyny
Alright, haters is probaby a too strong term. TextSecure team pointed out
flaws in the first topic about Telegram on HN and these flaws were answered by
Telegram team: they updated FAQ, they commented in twitter and here on HN.
Every post with Telegram's flaws explicitly mentions TextSecure as an
alternative, and that is suspicious - they seem to find it a great way to get
publicity.

~~~
jaxb
So are you associated with telegram, just to be clear?

~~~
vitalyny
Sorry I didn't respond to that. No, I'm not associated with Telegram in any
way. And I'm not crypto professional :)

I totally understand what Telegram critics are saying, but in every article
there's always a note "Please use TextSecure, don't use Telegram". By how it
looks, it seems to be a way to market TextSecure and not to discover
Telegram's security flaws. And critics rarely respond to Telegram team's
comments where they say that the claims are wrong.

~~~
B-Con
> but in every article there's always a note "Please use TextSecure, don't use
> Telegram".

This is very common in the security field.

Good crypto/security software is often not very straight-forward for the
public to find. They're usually run by competent developers doing the work for
free and don't tend to have big PR budgets or do a lot of advertising. The
product is findable, but they can be overshadowed by snake-oil products that
focus on the business aspects.

Whenever a security project or service is attacked as insecure, the natural
question is "what do you use instead?", particularly if the functionality was
niche or unique. It's just a part of the community that an alternative _good_
one is recommended. We try to avoid saying "don't use X" and instead say
"don't use X, but do use Y".

Yes, it helps Y piggie-back a bit off the popularity of X, but that's Y's
fault being being bad enough to be disparaged. It isn't just the TextSecure
team doing this, it's everyone who cares about this type of service.

~~~
xerophtye
>Yes, it helps Y piggie-back a bit off the popularity of X, but that's Y's
fault being being bad enough to be disparaged.

Correction: Yes, it helps Y piggie-back a bit off the popularity (or
notoriety) of X, but that's X's fault being being bad enough to be disparaged.

------
sillysaurus2
I wish there was an article that succinctly conveys to potential users why
Telegram is snakeoil and why TextSecure is the real deal.

~~~
tptacek
That would be nice. But, for what it's worth: don't use Telegram. It's a mess.
TextSecure was built much, much more carefully.

~~~
seertaak
Is TextSecure only for SMS messages, or does it use the internet? I'm asking
because of the need to send text messages abroad (at a reasonable price).
Also, is there a desktop client for TextSecure? I would love something like
WhatsApp -- but secure and with a desktop client.

~~~
girvo
XMPP + OTR will do what you want. I asked moxie the same question re the
internet vs text, but he hasn't replied yet. As far as I'm aware it uses text
for insecure stuff, and I think for initial key exchange to start the ratchet
then uses the internet for secure messaging. Its quite user friendly. No
desktop client, and the messages are of ephemeral so keep that in mind and see
whether that's okay for your use case (it is for mine).

------
rkangel
Forgetting the discussion of the merits or otherwise of Telegram - I just
wanted to say that that is a very written article. A clear argument built on
clear explanations of the various models.

------
xnyhps
I think it's a brilliant move from the people behind Telegram: all
cryptographers will now keep the vulnerabilities they find to themselves until
March 1st. This saves them from a lot of bad press now, and probably doesn't
cost them anything.

If they were serious about using their $200k for their security they should
have either: a) Hired an actual independent cryptographer to do an audit. b)
Set up a bug bounty program that rewards any weakness found, not just this
"all-or-nothing" contest they have now.

------
wgx
Best quote: "Telegram’s design seems to disregard all of the important crypto
research from the past two decades."

------
TelegramApp
The contest, as proposed by Pavel, while limited for the moment, does cover an
important issue as far as our users are concerned. And the scope will
naturally expand with time, should Telegram be invulnerable under the current
conditions (see contest FAQ:
[http://core.telegram.org/contestfaq](http://core.telegram.org/contestfaq)).

Quoting a post by Pavel here on HN: "Telegram will always be interested in
creating incentives for the crypto-community to check its security and provide
feedback. So if you are waiting for tools to try, e.g., a MITM on Telegram and
get your $200К, please stay tuned. It's @telegram on Twitter."
([https://news.ycombinator.com/item?id=6938987](https://news.ycombinator.com/item?id=6938987))

As for general critique of the protocol, please allow us to add a few vital
corrections regarding the article (unfortunately, the author chose a platform
that would not permit a direct comment).

> They use the broken SHA1 hash function.

SHA-1 isn't exactly broken. There is a theoretical paper from 2005 that
describes a way to narrow down collision search from 2^80 to approx. 2^69
operations
([http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersio...](http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersion.pdf))
with subsquent improvement to 2^63, but collisions won't help in the case at
hand. In order to break the implementation in MTProto you would require
generating a text with chosen SHA-1 (to our knowledge, this problem was not
yet solved) — and even that wouldn't get one far, because of the server salt,
session id and time.

More on our SHA-1 implementation here:
[http://core.telegram.org/techfaq#q-are-you-doing-encrypt-
the...](http://core.telegram.org/techfaq#q-are-you-doing-encrypt-then-mac-mac-
then-encrypt-or-mac-and-enc)

and here: [http://core.telegram.org/techfaq#q-why-do-you-use-
sha-1-in-t...](http://core.telegram.org/techfaq#q-why-do-you-use-sha-1-in-the-
place-of-a-mac)

> they are trying to do “Mac and Encrypt” which is not secure.

We are not doing this. We are doing this:
[http://core.telegram.org/techfaq#q-are-you-doing-encrypt-
the...](http://core.telegram.org/techfaq#q-are-you-doing-encrypt-then-mac-mac-
then-encrypt-or-mac-and-enc)

> They rely on an obscure cipher mode called “Infinite Garble Extension.”

Yes, we do. The setup goes like this: [http://core.telegram.org/techfaq#q-do-
you-use-ige-ige-is-bro...](http://core.telegram.org/techfaq#q-do-you-use-ige-
ige-is-broken)

> Some really weird stuff about factoring 64-bit integers as part of the
> protocol.

This weird stuff can be pretty effective as part of our DoS-protection scheme.

Meanwhile, we've expanded our Tech FAQ with responses to most common questions
concerning MTProto's robustness against certain types of active attacks:

[http://core.telegram.org/techfaq#protection-against-known-
at...](http://core.telegram.org/techfaq#protection-against-known-attacks)

Thank you for your comments,

Telegram Team

~~~
tptacek
I'm worried that to people unfamiliar with modern crypto, the diagram of your
protocol and the "technical FAQ" might sound credible or even convincing. But
it is not.

The message integrity protection this system describes is not up to modern
standards. The system seems to use SHA1, which is a fault for a new system (no
new system should use SHA1), but that's not the biggest problem; the biggest
problem is that the SHA1 digest of a message is not an authenticator of that
message, because an attacker can generate the same digest given only the
contents of the message. Your FAQ makes a claim that is simply false when it
says that the SHA1 of a message is a MAC. It simply is not. Moreover, the
process of using a secure hash to generate a MAC isn't simple. HMAC-SHA1 and
SHA1 are not comparable functions; HMAC-SHA1 goes through a series of
elaborate steps to remediate vulnerabilities that come from trying to use SHA1
directly.

AES-IGE is an anachronism. Candidly: most of the Internet crypto practitioners
who looked at this system learned about IGE for the first time because you
decided to use it. IGE is a block cipher mode that was designed in 1977 and
forgotten about in 1978. It's so archaic that academic cryptographers joke
about how many times it has been reinvented and then rebroken. The last time
your cryptosystem was discussed on HN, I provided a link to a thread in which
Jutla laid out a simple, devastating attack on the mode in ASCII text in a
mailing list post. You didn't respond.

Your use of RSA seems naive and ineffective. Your system "resists" MITM
attacks by "allowing" clients to trust servers you operate. No other modern
secure messaging protocol has this characteristic. Every OTR user in the world
runs software that was designed not to trust central servers. Not only that,
but the technical attributes of your RSA usage appear incompetent. RSA padding
is not optional; Nate Lawson has argued for years that RSA "padding" should be
renamed "armoring" for exactly this reason: because developers like those on
your team assume that it is a minor detail. It is not. 80% of the RSA
implementations on the Internet are insecure because they use the default
padding (PCKS1v1.5) which was carefully designed (in the 90s) to resist
attacks, but missed some. You use ad-hoc padding.

I don't understand why any professional in the world would spend any time on
your contest. Moxie Marlinspike's response to that contest was devastating: he
laid out a comically broken messaging protocol, one no professional would ever
knowingly use, and showed that your contest rules would make that broken
system survivable. Your contest appears to be a cynical attempt to prey on the
misconceptions of uninformed users.

You have deliberately chosen the NSA as your adversary in your promotional
content. You have deliberately chosen to give yourself no margin of error in
designing this system. You've deliberately chosen a problem domain that
requires profound trust in your team. You are not living up to the constraints
you've set for yourself. I fear that the damage you've done to your project
may be unrecoverable.

~~~
Smirnoff
I hope Durov brothers are taking notes. Making a half-baked Facebook clone is
not the same as making a fully-secured messaging system.

PS: These guys are still copying Facebook. Facebook released a messaging app,
so these guys did the same. But, hey, Telegram is different because it uses
MITM and it's "secure".

~~~
DavidShahoumian
> half-baked Facebook clone

It is better than Facebook in every possible way.

Have you actually ever used VK (both the site and the mobile apps)?

~~~
new_test
> It is better than Facebook in every possible way.

Even if it were true, your statement still doesn't contradict GP's assertion.

~~~
DavidShahoumian
By that logic one could state that, for instance, Chrysler cars are "Ford
clones" because Ford was the first manufacturer to become very popular and
commercially successful.

------
tucson
> They use the broken SHA1 hash function

They answer this point on the website: "Q: Why do you use SHA-1 in the place
of a MAC? [...] since this means still requiring at least 2^128 operations
(instead of 2^256 with, say, SHA-2) to even begin trying to break this scheme,
the trade-off seems fair."

Why not break the crypto (and take the money) if it's so amateurish?

~~~
testing12341234
The easiest to understand response to this question that I've seen so far is
from this comment [0]:

 _The contest limitations rule out most of the likely attack vectors for
breaking the protocol in the real world. It 's like saying "Our bank vans are
100% secure. Just try stealing money from them without puncturing our tires or
bribing one of our employees."_

[0] -
[https://news.ycombinator.com/item?id=6936949](https://news.ycombinator.com/item?id=6936949)

~~~
simias
In particular none of the attacks described in TFA (Known Plaintext, Chosen
Plaintext and Chosen Ciphertext) are possible within the frame of their
contest (since Telegram controls all inputs).

Yesterday someone blogged an example of a completely broken cryptosystem that
would still pass Telegram's challenge with the same limitations:
[http://www.thoughtcrime.org/blog/telegram-crypto-
challenge/](http://www.thoughtcrime.org/blog/telegram-crypto-challenge/)

~~~
StavrosK
That's Moxie Marlinspike, developer of TextSecure.

~~~
Beltiras
With a very valid challenge.

------
utnick
If the crypto is broken, then break the crypto and collect the 200k.

Or if its vulnerable to a MITM, then explain how.

Or if its vulnerable to chosen plaintext/ciphertext or known plaintest,
explain how.

There has been so much piling on of telegram, but nobody has actually proven
any problems with their code or protocol. Meanwhile telegram is trying to do
the right thing by being open source and taking the time to respond here and
elsewhere to misconceptions and criticisms about them.

I really don't get the hostility towards them so far.

~~~
girvo
Well, the severe issues highlighted by better cryptographers than me (although
I do understand why and how they are issues) show that the protocol can't be
trusted. These issues have caused other protocols to be broken, so aeeinf
similar issues again from the get go, coupled with heir marketing spiel means
that it shouldn't be trusted.

Which is what it's about: cryptography is mostly about trust with a bit of
math thrown in. If you can't trust that it won't be broken (see: all the
issues 'moxie and 'tptaeck bring up for an example) then it shouldn't be used.

------
mcguire
Not necessarily on topic, but...

" _... will give $200,000 in BTC to the first person ..._ "

Is that $200,000 in BTC _at the time the contest was announced_ , or _at the
time the winner is announced_? Or at some other point?

(This comment brought to you by the Committee For Pointing Out That A Currency
That Wildly Fluctuates In Value Is Not Particularly Useful
(CFPOTACTWFIVINPU).)

~~~
thedufer
Ugh. There are a lot of reasons not to participate in this contest, but that's
not one of them. The FAQ explicitly says that they'll just give you USD if
you'd like, so it doesn't really matter when they pin the USD/Bitcoin exchange
rate.

------
mangeletti
Has anyone else noticed that their protocol sounds a _lot_ like "empty
proto"... [http://core.telegram.org/mtproto](http://core.telegram.org/mtproto)

[thinks of null key encryption]

------
theg2
Good idea, lets keep attacking the marketing team. It's a PR stunt, can we
stop acting like it's anything else?

------
ibudiallo
So everyone is mad cause they used their own approach to security. Now no one
managed to break their crypto so far. Don't say it is bad unless you can break
it. Don't go around write a full paper about how bad it is while you still
can't break it.

I still don't get why there is all this hostility toward telegram.

~~~
dcalacci
>So everyone is mad cause they used their own approach to security

No, that's not why people are upset at all.

People are upset because whether or not someone has been able to break their
system under the constraints of the contest means almost nothing.

Did you even read the article?

------
blahbl4hblahtoo
Wow...this thing just keeps on giving. It's Christmas in crypto-fail land!

------
infocollector
I think people should keep quiet if they cant break their system. What good is
a cryptographer, if its only good for pointing fingers?

~~~
yalogin
Did you read the blog post? This is precisely what the OP is saying, that the
contest is flawed. They are basically saying if you can break my new fancy
lock you win but you can only see the lock over the webcam and not touch it.

------
releod
I don't understand why this is such a massive problem (front page news for
days now, really?). Mind you, I am not a crypto expert, but enough with the
bitching already.

Crypto experts, just crack it then.. who cares about the special conditions in
the contest which make it so difficult. Just do it, prove your point and carry
on.

$200k is PR, everyone knows that already.

~~~
Nursie
It may well be impossible to crack within the terms of the contest.

This does not make it secure in the slightest, as the terms are set up
specifically to exclude most of the attacks that are used in crypto validation
these days. See - [http://www.thoughtcrime.org/blog/telegram-crypto-
challenge/](http://www.thoughtcrime.org/blog/telegram-crypto-challenge/)

------
kayoone
Some strong claims in there for not really proving that the protocol is indeed
"terrible".

~~~
Confusion
An expert on trees:

    
    
      This oak is probably diseased. It has discolorations on 
      some of the leaves and the bark is much looser than 
      normal. I think it should be thoroughly investigated or 
      perhaps just cut it down to be safe.
    

kayoone, knowing nothing of trees: "some strong claims in there for not really
proving that the tree is indeed diseased."

~~~
kayoone
And you obviously know that i know nothing of on the subject?

~~~
skj
With respect, at first glance it seems that way. The burden of proof lies with
the claim to security, not the claim of insecurity.

~~~
tucson
The contest actually puts the burden of proof on the "claim of insecurity"
side.

~~~
forgottenpass
The contest is a stunt that appears to a casual observer to shift the burden
of proof because they wrote a long winded "PROVE ME WRONG BRO."

------
raverbashing
Funny how they say "oh but the attack possibilities are limited" then proceed
to mention all the weaknesses in the algorithm.

Well, if the algorithm is so broken then it should be trivial to break it even
with their limitations.

Isn't that what they say? "Oh SHA-1 is broken", great, show it.

Of course, the capability to do that may be worth more than getting the $200k
from the contest

~~~
Confusion

      Well, if the algorithm is so broken then it should be 
      trivial to break it even with their limitations.
    

Well, if the house is so badly protected, it should be trivial to break in,
even with their limitations[1].

[1] Limitations include: not being allowed within 200m of the house.

~~~
raverbashing
I disagree

You are allowed access to the encrypted data.

In a real attack you may, depending on the circumstances, only have access to
that (at first, at least).

Probably more like "you aren't allowed to destroy any locks or doors to enter
the house". Hard, but much different than staying 200m from the house.

~~~
Drakim
> In a real attack you may, depending on the circumstances, only have access
> to that (at first, at least).

You misunderstand the whole deal.

When imagining different potential attacks on your house you can't go laying
down rules that the burglars have to follow. What if there are special
circumstances (that you weren't aware of) that allows the burglars to bypass
your restrictions under certain conditions? You plan for the worst case
scenario, always!

Take password hashing+salting for instance. You could say that it's actually
safe to store plaintext passwords because outsiders don't have credentials to
access the database.

You could even run a contest where to say that you will give a million dollars
to anybody who can get access and steal the passwords, and then insist that
since nobody has claimed that million dollars yet, plaintext passwords are
clearly safe.

But we all see how foolish that would be. You plan for the worst case scenario
and hash+salt your passwords. You don't plan for the "average case scenario"
where "normally attackers don't have access to the database".

~~~
raverbashing
"When imagining different potential attacks on your house you can't go laying
down rules that the burglars have to follow"

Of course. But everything is limited and for each scenario there's a specific
chance that will happen. Some RSA key sizes are breakable if you can put a lot
of computing power behind.

For example, a house may not be built to withstand tanks, so there's your
limitation.

On the other hand, there's a huge likelihood someone will walk past your house
and see the door ajar, or try to open it.

So, again, everybody is right to secure against KPA, CPA, etc, BUT don't
forget that there may be something easier, and yes, if it resists the deeper
attacks it's probably safe against capture of cyphertext.

"But we all see how foolish that would be. You plan for the worst case
scenario and hash+salt your passwords"

Sure. But _in practice_ the plaintext + strong DB security may be safer
"overall" than a hash + salt on a MySQL with the credentials forgotten in some
config.php somewhere.

(It's not an excuse to not hash the passwords, though)

~~~
Drakim
> Of course. But everything is limited and for each scenario there's a
> specific chance that will happen. Some RSA key sizes are breakable if you
> can put a lot of computing power behind.

I can agree with you that bruteforce attacks should not be within the scope of
such a bug bounty prize or competition (unless somebody has exposed a flaw
that allows for very easy brute forcing).

But that's not what's happening here. What's happening here is that the people
running the show are handing out a few pieces of encrypted information and
saying that since nobody can crack their stuff using that handed out
information, their system is secure. It's easy to be confident in a controlled
sterilized environment.

The blogger is pointing out that an attacker could very well have access to a
lot more information and functionality than what they are handing out. They
are only demonstrating that their system is safe in a "good case scenario"
when everything goes as planned. They have not demonstrated that their system
is secure if everything doesn't go as planned, if suddenly the attacker found
a way to spoof the email messages and send his own prodding cypher, or
something to that flavor, which isn't part of the neat little package they
have arranged as part of competition.

Saying that "that's most likely not the case, the hackers wouldn't have
anymore information or access" just is not a rebuttal to that. It's not a
rebuttal to anything, it's just a brain fart.

