
A Crypto Challenge For The Telegram Developers - mjn
http://thoughtcrime.org/blog/telegram-crypto-challenge/
======
sdevlin
For reference, here's a list (probably incomplete? (EDIT: and feel free to
add!)) of ways this protocol is broken:

    
    
      1. There's no authentication at any point. The whole thing is trivially MITM-able.
      2. The RNG is Dual_EC_DRBG, which is backdoored.
      3. The RSA public key is small enough that an attacker of sufficient means could break it.
      4. The RSA plaintext is unpadded. Proper padding is critical for safe RSA encryption. See e.g. Bleichenbacher '98.
      5. RSA is used to encrypt semantic data. Dangerous for the same reasons as above.
      6. The hash function is broken. I'm not sure if this matters too much here, but I'm also not sure that it doesn't matter.
      7. The ciphertext seems to be restricted to messages of exactly 128 bits. It's not clear how or if the plaintext is padded if it's too short, and it's not clear how the protocol handles a longer message. These are noteworthy considerations.
    

And yet it's still (basically) safe against the kind of contest Telegram has
outlined. Someone could win by factoring the RSA public key, but I'm not sure
if that would be cheaper than the $200k prize. This vulnerability can also be
mitigated trivially by using bigger RSA keys, making the protocol Telegram-
secure.

~~~
danielweber
I don't keep up on everything, but I thought Dual_EC_DRBG was used by nobody
else for any real world crypto. Did these guys look over the Wiki page and
decide it would be fun to be the first?

~~~
lawnchair_larry
They aren't using it, but Dual_EC_DRBG is fairly widely used actually. There
was a false meme denying that this was the case, but RSA and others proved
that wrong.

~~~
tptacek
Dual EC was not particularly common. Here's a metric: name a couple of
products that you or I use regularly that ever used it.

It's not as if you could design a system with Dual EC instead of HMAC DRBG and
not know it; Dual EC requires bignum math. It is incredibly slow for a CSPRNG.

~~~
tveita
This is disingenuous. RSA used it as a default in a commercial crypto library,
as you must know. End users won't generally be aware that it's being used in a
product, but that doesn't mean it isn't out there.

It is unlikely that most developers changed the default unless it was having a
noticeable impact on performance, which wouldn't be the case if it was just
used for key generation.

[http://www.wired.com/threatlevel/2013/09/rsa-advisory-nsa-
al...](http://www.wired.com/threatlevel/2013/09/rsa-advisory-nsa-algorithm/)

> In its advisory, RSA said that all versions of RSA BSAFE Toolkits, including
> all versions of Crypto-C ME, Micro Edition Suite, Crypto-J, Cert-J, SSL-J,
> Crypto-C, Cert-C, SSL-C were affected.

> In addition, all versions of RSA Data Protection Manager (DPM) server and
> clients were affected as well.

> “Every product that we as RSA make, if it has a crypto function, we may or
> may not ourselves have decided to use this algorithm,” said Sam Curry, chief
> technical officer for RSA Security. “So we’re also going to go through and
> make sure that we ourselves follow our own advice and aren’t using this
> algorithm.”

Here's someone who has dug up a decent amount of real-world products:

[http://security.stackexchange.com/questions/43164/which-
prod...](http://security.stackexchange.com/questions/43164/which-products-are-
affected-by-nsas-ability-to-crack-pseudo-random-number-gener)

~~~
tptacek
You probably don't use any product that uses BSAFE.

For whatever it's worth, for people who think this point is all part of some
elaborate edifice of sticking up for NSA: I am now 99.9% convinced that Dual
EC is in fact a backdoor, and while it's clumsy in a tradecraft sense (you can
just look at it and see the problem), I've heard compelling scenarios in which
it would have been effective.

I just don't think it's a backdoor that's relevant to modern software, or,
even for its time (the early 00's), software that was in popular use.

~~~
nitrogen
What do you make of the list given in this other comment that includes copy
machines and game consoles?

[https://news.ycombinator.com/item?id=6940993](https://news.ycombinator.com/item?id=6940993)

------
ge0rg
tl;dr: moxie uses ancient, known broken crypto primitives (Dual_EC_DRBG, RSA
with 896 bits, MD2 and XOR) to construct a chat protocol which is unbreakable
if framed in the same way the Telegram developers did with their challenge. _"
If they can’t demonstrate a break in this obviously broken protocol using the
same contest framework they’ve setup, then we’ll know that their contest is
bullshit."_

Also, a call to arms to improve the OSS TextSecure implementation.

~~~
wodenokoto
I still don't get it.

If an insecure protocol with an insecure implementation can send messages that
others can't read, how is it insecure?

~~~
asolove
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."

~~~
mathattack
Thanks - this is the best analogy I've heard so far.

------
meowface
Even if Telegram's explanation _did_ stand up to scrutiny and was ran by
experienced cryptographers, the fact that its core code is closed source makes
it utterly worthless from a security perspective. They can tout their own
security all they like, but if no one else can independently verify it then it
means nothing.

So far they've only published the source to their client, but their servers do
all of the actual processing and cryptography.

All of Moxie's projects, on the other hand, have always been completely open
source.

~~~
finnn
Wait the crypto is done server side? I haven't really looked into Telegram
much, but that's fucking silly. Lavabit all over again.

~~~
utnick
its not done server side

~~~
6d0debc071
Eh, yes and no. It's not sent in plain text to the server. However, in the
sense that it's 'Lavabit all over again', or at least a procedure that
produces isomorphic problems, the encryption seems to be being done server-
side:

\--------------------------

 _' The difference between messages in Secret Chats and ordinary Telegram
messages is in the encryption type: client-client in case of Secret Chats,
client-server/server-client for ordinary chats. This enables your ordinary
Telegram messages to be both secure and available in the cloud so that you can
access them from any of your devices — which is very useful at times.'_

[https://telegram.org/faq#q-why-not-just-make-all-chats-
secre...](https://telegram.org/faq#q-why-not-just-make-all-chats-secret)

\--------------------------

I have trouble construing that other than in you use the server's key to
encrypt the message you send and then server encrypts it with the public key
associated with the addressees' device at the time.

...

This seems to produce the same problem LB had in that you can be asked to turn
over the keys to the messages on your server. And for similar reasons, you're
doing encryption on your server.

#

Given that LB had that trouble, I also have difficulty seeing any non-
malicious reason for solving the key distribution problem this way. Since you
can set up secret chats that are end to end encrypted you could equally have
asked the client's devices to exchange a private key using each others' public
keys.

I'm tempted to explain it away in terms of the user being expected not to be
technically savy enough to press the buttons on both devices when asked to do
so. - But the client knowing about and using encryption in the first place
implies at least some sort of technical competence which I would imagine is
great enough to press two buttons when a prompt comes up saying something
like:

'The device DEVICE NAME is asking for the key to read your messages.

If you did not try to set up your mail on another device within the last
minute, press the REPORT ATTACK button.

Else press the ALLOW button.'

Still, I've overestimated the average intelligence of people before.

------
paveldurov
As mentioned at
[http://core.telegram.org/contestfaq](http://core.telegram.org/contestfaq) if
more tools to interact with the traffic are needed for the contestants to
crack Telegram, they will be provided in the next contest right after 1 March,
2014. The current contest has an important practical task of deciphering
traffic that is being intercepted in real time. This is the basic concern of
regular users like myself (me and lots of other people in Russia had to stop
using WhatsApp because of easily decipherable intercepted traffic). If
Telegram proves to be robust in this respect, more tools to manipulate traffic
and wider contests with similar prizes are to follow. Like all startups, this
contest by Telegram starts from solving a basic but most important problem,
then gradually gets more complicated in functionality and scope.

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.

~~~
moxie
Does this mean that you were unable to recover Alice's message?

~~~
paveldurov
Alas, I am not a cryptographer and not even a member of the Telegram team. I'm
just a guy who backs Telegram financially and proposed to start their contest.
I described my motives behind it here
[https://news.ycombinator.com/item?id=6938622](https://news.ycombinator.com/item?id=6938622)

As for your contest, I will make sure the Telegram team will have a look at it
once they are awake. As far as I understand, you designed it to be similar to
Telegram's contest. How do you send messages that affect traffic in real-time?
How large is the prize? Is there a deadline?

~~~
ash
Have you taken part in Telegram contest design?

> How large is the prize?

I think the "prize" is obvious. Breaking this "unbreakable" 896bit-RSA + no
auth + no signature + MD2 + XOR is a necessary condition for the Telegram
contest to be taken seriously.

------
huhtenberg
This is counter-productive.

Whichever way you view Telegram, they haven't developed it to make a quick
buck on the ignorance of the masses, nor are they in it to deceive people and
entice them to use a knowingly broken crypto.

Granted, they have an attitude problem, they clearly have _no_ experience
talking to the crypto community and they made dumb move with this contest
thing, but in the end of the day they and Moxie(s) are on the same damn side.

Antagonizing things further is just plain stupid.

~~~
josephlord
They have a blindness and an arrogance that could prove fatal to anyone
trusting them. Until they lose the arrogance and catch up with the published
state of the art crypto they are dangerous and are likely to do more harm than
good.

This is a very clear explanation of the limitations of their challenge and
hopefully will open their eyes and help them on the road to getting a better
understanding. If not it will help to limit the damage they can do by publicly
clarifying the limitations and the lack of understanding that they currently
have.

------
paulsmith
Is there a decent “Crypto Not For Dummies But For Reasonably Competent
Programmers Who Have Thus Far Taken It For Granted But Want To Get Up To Speed
Fairly Quickly On Concepts And Implementation” text?

~~~
bjt
I've heard this one's OK. [https://www.schneier.com/book-
applied.html](https://www.schneier.com/book-applied.html)

~~~
helper
NO! Applied Crypto is at times a fascinating book, but it is terrible for a
developer that wants to learn the fundamentals of crypto and how to avoid the
most common mistakes people make. Its also really old at this point.

A much better book is Schneier, Ferguson and Kohno's "Cryptography
Engineering"[1]. It covers what makes for strong crypto primitives and why
weaker ones are considered broken. Note that is book is starting to get a bit
out dated (I don't remember it covering ECC at all, for example), but I don't
know of any better book.

I also endorse the Matasano Crypto challenges and the Coursera Crypto class
taught by Dan Boneh as excellent learning resources.

[1] : [https://www.schneier.com/book-ce.html](https://www.schneier.com/book-
ce.html)

------
zooko_LeastAuth
Dear makers and backers of Telegram:

Perhaps in response to my requests
([https://news.ycombinator.com/item?id=6933179](https://news.ycombinator.com/item?id=6933179)
,
[https://twitter.com/zooko/status/413552420522708993](https://twitter.com/zooko/status/413552420522708993)
,
[https://twitter.com/zooko/status/413552466748133376](https://twitter.com/zooko/status/413552466748133376)
), your FAQ
([http://core.telegram.org/contestfaq](http://core.telegram.org/contestfaq))
now says:

\------- Q: Does Paul send the same message to Nick every day?

No, just as in real life, Paul‘s messages to Nick can be different each time.
The only thing that doesn’t change is the secret email address in his daily
messages.

Q: Could you provide an example of a Paul's message to Nick?

Sure. The message may look like “Hey Nick, so here is the secret email address
for the bounty hunters – {here goes the email}”. \-------

There are some things that I don't understand about the structure of this
contest. Why is the target secret an email address rather than a magic word
like "squeamish ossifrage"?

I asked for an “examples of the actual message”, and you posted an possible
example, but what I meant to ask for was _actually the exact text_ of one of
the messages. Except, of course with the target string (the email address)
replaced by X's.

For redditors following along, getting a (partial) copy of the exact message
that was sent would be an example of what cryptographers call (partial) "known
plaintext". If your cryptosystem is secure against Known Plaintext Attack,
then it doesn't matter if an attacker (me) gets copies of some of the
messages. If your cryptosystem is insecure in this model, then your users have
to be careful with what they type into their messages. For example, they might
need to be careful not to cut and paste long strings from other sources, or to
otherwise insert strings into their messages that their attacker might guess.

All good, modern cryptosystems are secure in the Known Plaintext Attack model!
(And, in fact, all good, modern cryptosystems are secure in much more rigorous
models in which attackers get more powers beyond peeking at plaintext.)

So if the makers of Telegram are confident in the security of their protocol,
they should have no problem posting the complete, verbatim text of the first
message that Paul sent to Nick, with the target email address replaced by
"XXX"'s.

~~~
zooko_LeastAuth
Taylor Hornby has written a good introductory explanation of the Known
Plaintext Attack model and the more powerful attack models, in the context of
the Telegram cracking contest:

[http://www.cryptofails.com/post/70546720222/telegrams-
crypta...](http://www.cryptofails.com/post/70546720222/telegrams-
cryptanalysis-contest)

------
m-app
I have been saying this a couple of times in similar threads, but I think
Threema [1] deserves a little more attention. Complete end-to-end encryption
using NaCl. The interface they created is simple and gets the point across.
Also, they're actually saying "don't trust us!", which ironically makes me
trust them.

[1]: [https://threema.ch/en/](https://threema.ch/en/)

~~~
moxie
Their protocol doesn't provide any forward secrecy. It uses the PGP protocol
model, which is increasingly being seen as an architectural dead end
(particularly given the recently revealed ciphertext recording capabilities of
NSA):

[https://whispersystems.org/blog/asynchronous-
security/](https://whispersystems.org/blog/asynchronous-security/)

~~~
napoleond
That's not what their FAQ says:
[https://threema.ch/en/faq.html](https://threema.ch/en/faq.html) (scroll down,
they specifically claim to provide forward secrecy)

Do you have additional information?

~~~
moxie
Yikes, that actually looks like potentially deceptive marketing to me.

 _> "Yes, Threema provides forward secrecy on the network connection. Client
and server negotiate temporary random keys, which are only stored in RAM and
replaced every time the app restarts (and at least once every 7 days). An
attacker who has captured the network traffic will not be able to decrypt it
even if he finds out the long-term secret key of the client or the server
after the fact."_

My reading is that they have an end-to-end secure protocol that _does not_
provide forward secrecy, which happens to be routed through a server which
uses HTTPS w/ an ephemeral cipher suite for the _network transport_ , with a
TLS session ticket that they rotate the key on every 7 days.

We should ask them for more details, but if true, that would be pretty
deceptive of them.

~~~
napoleond
Wow, ok. So, just to be clear, what you're saying is that you're interpreting
their claims here as being exclusively related to the network transport; the
underlying end-to-end protocol does _not_ use ephemeral keys as far as you
know.

If I'm understanding you correctly, and you're understanding them correctly,
that is quite deceptive indeed.

~~~
salient
Yes, that's what they're doing. I checked them out earlier this year and I
remember being disappointed they didn't offer forward secrecy like OTR.

------
javajosh
Funny. But actually, the simplest contest that accurately describes Telegram's
insanity is simply this:

::Given an unknown function _f_ and a single output _y_ , compute the input
_x_ that maps to _y_.::

Ready? Here's the output: ROSEBUD. Now I'll give $100k to anyone who can tell
me x. Good luck!

~~~
mintplant
The function is known--they publish how their algorithm works. The problem is
that their contest doesn't account for the main problem with their system: its
vulnerability to MITM attacks.

~~~
javajosh
Okay, then let f XOR the input with a randomly generated integer. There is no
loss of generality here.

------
guyht
Whats to stop Telegram tampering with the messages and just displaying random
bytes in the 'output'? This would make it impossible to crack. You cant test
the security of a system without 1 - full access to the system or 2 - complete
trust in the people controlling the system (which we dont have)

~~~
gregschlom
They said if no one wins the contest they would publish the keys allowing
anyone to decrypt the data, proving it was not garbage.

~~~
guyht
Ah, I missed this part. Thanks

------
im3w1l
Using an NSA backdoored RNG is pretty redundant. A cell phone cannot be
secured against NSA. They'll just activate their keylogger and grab the
plaintext before it has even been encrypted.

~~~
meowface
That's making the assumption that all phones in the US have NSA keyloggers on
them, which is pretty unlikely.

~~~
im3w1l
While they probably don't have keyloggers on them from the start, it is with
high probability child's play for them to push it to your phone over the air,
and make your phone run it

[http://www.osnews.com/story/27416/The_second_operating_syste...](http://www.osnews.com/story/27416/The_second_operating_system_hiding_in_every_mobile_phone)

"What makes it even worse, is that every baseband processor inherently trusts
whatever data it receives from a base station (e.g. in a cell tower). Nothing
is checked, everything is automatically trusted. Lastly, the baseband
processor is usually the master processor, whereas the application processor
(which runs the mobile operating system) is the slave. So, we have a complete
operating system, running on an ARM processor, without any exploit mitigation
(or only very little of it), which automatically trusts every instruction,
piece of code, or data it receives from the base station you're connected to.
What could possibly go wrong? "

~~~
derefr
Yep. And you can build your own (low-power) GSM base-station:

[http://www.thinksmallcell.com/Technology/build-your-own-
open...](http://www.thinksmallcell.com/Technology/build-your-own-opensource-
femtocell.html)

So anyone with a little time on their hands can be that "trusted party" for
everyone in radio vicinity.

------
cybernytrix
<Rant> After reading all the blogs and replies that are abuzz talking about
Telegram, I realized they are the best guerrilla marketers I have seen in a
while! They might as well throw away their PhD. papers and stop calling
themselves as Engineers/Cryptographers/whatever... marketing monkeys...

</Rant>

------
StavrosK
I must be missing something, but isn't this easy to attack by exploiting the
periodicity of the XOR function? Or is the message 32 bytes long as well?

~~~
anonymoushn
The plaintext is the same length as the hash, so each byte of the hash is
xored into only one other byte.

~~~
StavrosK
Ah, well, that's pretty secure, then.

------
ef47d35620c1
If the prize was similar to this one, I think the challenge would be taken
more seriously:

[http://16s.us/software/FreeOTP/freeotp_challenge.txt](http://16s.us/software/FreeOTP/freeotp_challenge.txt)

    
    
        * Prize
    
            One small Slurpee or its equivalent monetary value.

------
andy112
If they were to release the plaintext of Alice's (or, in their case, Paul's)
message, wouldn't that include the secret email address?

FWIW, I agree the contest is a sham for the reasons moxie & others listed here
and elsewhere.

~~~
nwh
The contest is only set up that way to make it look more secure, there's
really no reason that you would have to prove yourself in that way. If there's
an actual cryptographic break then a researcher can prove it without all of
the "send email to this address" nonsense.

------
conformal
this is a reminder that prizes or cash for breaking crypto products is a silly
PR stunt. mega did the same thing, ended up paying out some money, then their
product is "secure" by the same sort of argument. same deal with cryptocat and
several other cryptoturds.

i do find it amusing to hear moxie ranting about how much better textsecure is
when the license on it is such shit. can't argue with the fact that it's open
source, but there is no point in contributing the codebase due to the
licensing.

~~~
pjscott
The license on the TextSecure app is GPLv3. What would you like to do with
TextSecure that this license prohibits?

~~~
nardi
Integrate it and distribute it with non-open-source software. So, any
commercial use whatsoever.

~~~
nardi
I understand the down votes, and kind of expected it. But this is the actual
practical reality, guys. Large software companies avoid GPLv3 like the plague.
If you want your software to be used widely, then you need to use
BSD/MIT/Apache/etc.

~~~
belorn
Since when is Google and Oracle not defined as "large software companies"?

Companies that avoid GPLv3 (but not GPLv2) do so because of either the patent
clause, or the DRM clause. That is, they either want to by pass the license
with legal restrictions, or hardware restrictions.

This is only relevant for external products, and says nothing about internal
use. the actual practical reality, _dead seriously_ , is that gplv3 is used by
most large software companies that exist in the world. It would surprise me if
Microsoft did not have some debian machines laying around somewhere hosting
some website.

------
anonymoushn
public key plz

------
alonium
Another guy has butthurt from Telegram. As I read somewhere telegram guys said
that after 1st march 2014 they somehow will allow to perform MITM in that
crypto challenge

~~~
nwh
If they allow man in the middle attacks then the system is completely and
demonstrably broken. The out of band public key verification uses
deterministic images to confirm that the keys are the same, which can be easy
forged given the relatively bad comparison engines in use (humans describing
what a pixelated 16px image looks like). At no point is the real key shown to
the user, so it's impossible to verify that they're identical through a
description.

[http://telegram.org/img/key_image.jpg](http://telegram.org/img/key_image.jpg)

I wager that if they did allow a tampering eavesdropper in their bounty
contest, it would be in the same conversation that has already done a key
exchange and verification, making it yet more snake oil. You can hardly call
something secure when you don't allow real-world MITM attacks in testing.

~~~
utnick
How is the key image impossible to describe?

There are only 4 possible colors per cell. You just describe it like
0,1,2,3,2,0, etc Just as if you were reading off the real key.

~~~
nwh
From just asking around, most people described the key image to me in terms of
the darkest portions and ignored the parts that were lighter. It's easier for
the example image to say that there's a dark L and lighter X shape in the
center and then assume that the rest is the same. At least, that's how people
did when I presented it to them as a challenge.

~~~
velis_vel
> There's also not that many possible images anyway, there's 8 rows with 8
> columns, and 4 possible colours for each pixel. Even not assuming any fuzzy
> matching (human comparison) it's still very possible to generate keys with
> colliding image hashes.

Uh, 4^(8*8)=2^128 is a pretty large number.

~~~
nwh
So it is, I've removed that. I need to sleep more.

