Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Crypto Challenge For The Telegram Developers

thoughtcrime.org

Post reply on HN
Print view View original

81–90 of 136 posts

Re: A Crypto Challenge For The Telegram Developers

#81

Post by pjscott »

conformal wrote: post #53

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…

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

Re: A Crypto Challenge For The Telegram Developers

#82

Post by rmc »

wodenokoto wrote: post #20
ge0rg wrote: post #3

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…

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?

There are attacks that are possible in the real world that Telegram's (& this example) contest deny. It's like tying a person to a chair, and challenging them to run a marathon, to prove that humans can't run marathons. In the real world, people aren't tied to chairs and humans can run marathons.

Re: A Crypto Challenge For The Telegram Developers

#83

Post by danielweber »

sdevlin wrote: post #32

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 encrypti…

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?

Re: A Crypto Challenge For The Telegram Developers

#84

Post by lawnchair_larry »

danielweber wrote: post #83
sdevlin wrote: post #32

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 encrypti…

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?

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.

Re: A Crypto Challenge For The Telegram Developers

#85

Post by sdevlin »

danielweber wrote: post #83
sdevlin wrote: post #32

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 encrypti…

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?

To be clear, I'm describing problems with Moxie's hypothetical broken protocol, not with Telegram. Telegram does not (as far as I know) use Dual_EC_DRBG.

Re: A Crypto Challenge For The Telegram Developers

#86

Post by mathattack »

asolove wrote: post #29
wodenokoto wrote: post #20

Earlier quoted context omitted.

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?

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

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

Re: A Crypto Challenge For The Telegram Developers

#87

Post by saraid216 »

huhtenberg wrote: post #62

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…

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

The contest they set up actually makes me think they did. I am willing to see them pay out for it and thus prove me wrong, though.

Re: A Crypto Challenge For The Telegram Developers

#88

Post by robryk »

sdevlin wrote: post #32

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 encrypti…

I don't understand 5. RSA is used there to encrypt a random value that is used as a KDF input. I do get it that the size of the random value together with lack of any padding and poor choice of KDF causes issues, but can you explain why do we care about malleability (or did you mean something else) here?

Re: A Crypto Challenge For The Telegram Developers

#89

Post by djm_ »

zooko_LeastAuth wrote: post #68

Dear makers and backers of Telegram: Perhaps in response to my requests ( https://news.ycombinator.com/item?id=6933179 , https://twitter.com/zooko/status/413552420522708993 , https://twitter.com/zooko/status/413552466748133376 ), your FAQ ( 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 ea…

A simple way to understand the gravity of this: the Nazi's Enigma machine was broken with a known-plaintext attack a.k.a a Turing Bombe break. Furthermore, it was the known plain text of previously decrypted messages that was used in further attacks against new keys issued by the Nazis.

Re: A Crypto Challenge For The Telegram Developers

#90

Post by sdevlin »

robryk wrote: post #88
sdevlin wrote: post #32

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 encrypti…

I don't understand 5. RSA is used there to encrypt a random value that is used as a KDF input. I do get it that the size of the random value together with lack of any padding and poor choice of KDF causes issues, but can you explain why do we care about malleability (or did you mean something else) here?

You're right and I'm wrong. Mea culpa. I dashed these off quickly.

Unfortunately I can't edit anymore, so the erroneous #5 will have to stay there.

The main bad thing here is the null padding (covered in #4). This gives the attacker a lot of knowledge of the plaintext (the most significant bytes are all null), which can be used to decrypt if this format is validated on the other end. Bleichenbacher's attack only requires knowledge of one plaintext byte (the leading 02h), and we have many.

Post reply on HN