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

111–120 of 136 posts

Re: A Crypto Challenge For The Telegram Developers

#111

Post by salient »

moxie wrote: post #37
m-app wrote: post #13

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/

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/

What do you think about Surespot?

https://www.surespot.me/documents/how_surespot_works.html

Re: A Crypto Challenge For The Telegram Developers

#112

Post by moxie »

paveldurov wrote: post #108

As mentioned at 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 Russ…

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

Re: A Crypto Challenge For The Telegram Developers

#113

Post by paveldurov »

moxie wrote: post #112
paveldurov wrote: post #108

As mentioned at 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 Russ…

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

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

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?

Re: A Crypto Challenge For The Telegram Developers

#114

Post by zooko_LeastAuth »

paveldurov wrote: post #108

As mentioned at 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 Russ…

Thanks for sponsoring the Telegram product. (Even though I think what they are trying to do could be done much better.)

Could you please ask the Telegram team to post the exact contents of the first message that Paul sent to Nick, except with the secret email address X'ed out? I explained in https://news.ycombinator.com/item?id=6937631 that if the MT protocol is secure, then there is no risk in posting such a "known plaintext", so the Telegram team should have no problem posting it.

Re: A Crypto Challenge For The Telegram Developers

#115

Post by nardi »

nardi wrote: post #94
pjscott wrote: post #81

Earlier quoted context omitted.

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

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

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.

Re: A Crypto Challenge For The Telegram Developers

#116

Post by meowface »

huhtenberg wrote: post #72
meowface wrote: post #6

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

Open source doesn't imply trustworthiness and it's a very dangerous assumption to make. Any open source system can be screwed with in a variety of ways. The simplest and most effective option is to publish both the source and the binaries, but built latter from the an altered source. This will work in a vast majority of cases, because a lot of people make this ridiculous assumption that publishing the source automati…

I am not saying open source == secure. Rather, closed source == impossible to know if secure. Making something open source doesn't instantly add a "secure" tag to it, but keeping it all closed leaves no chance for the tag to even appear.

With open source you can get intelligent, experienced experts to look through it. And if enough of them look through it and say it's good (for example, as many experts have done with the Bitcoin client and protocol), you can at least gain some degree of assurance, even if the possibility of a critical exploit being found in the future still always remains.

Also, you are right in that in this particular scenario, open source would only be the first step as you couldn't know if their servers are actually running the source they published. Open source + full end-to-end encryption and authentication are both required, as is the case with OTR and Moxie's project.

Re: A Crypto Challenge For The Telegram Developers

#117

Post by vinceguidry »

zellyn wrote: post #71
paulsmith wrote: post #63

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?

The Matasano Crypto Challenge is a fun intro.

I wish it were still open. They want you to send them an email to start the challenge, mine went unanswered.

Re: A Crypto Challenge For The Telegram Developers

#118

Post by meowface »

femto wrote: post #92
objclxt wrote: post #79

Earlier quoted context omitted.

> This will work in a vast majority of cases, because a lot of people make this ridiculous assumption that publishing the source automatically implies that the guy is good, open and trustworthy all over. And won't bother verifying the binaries. Probably worth linking to Ken Thompson's Reflections on Trusting Trust paper, which illustrates exactly what you're saying with a hypothetical (or not) C compiler backdoor. ht…

For me, the following lines also stood out: "I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect." Presumably to would be possible to introduce a bug into every CPU manufactured, that even the manufacturer is…

Even scarier, researchers have shown that there are ways of backdooring CPUs via transistor doping so that even if the manufacturer suspects a backdoor, it may still be very difficult for them to find it: http://www.techrepublic.com/blog/it-security/researchers-cre...

Full paper: http://people.umass.edu/gbecker/BeckerChes13.pdf

Re: A Crypto Challenge For The Telegram Developers

#119

Post by javajosh »

mintplant wrote: post #107
javajosh wrote: post #45

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!

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.

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

Re: A Crypto Challenge For The Telegram Developers

#120

Post by zooko_LeastAuth »

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…

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

Post reply on HN