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

31–40 of 136 posts

Re: A Crypto Challenge For The Telegram Developers

#31

Post by [deleted] »

finnn wrote: post #10
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…

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

[deleted]

Re: A Crypto Challenge For The Telegram Developers

#32

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

Re: A Crypto Challenge For The Telegram Developers

#33

Post by jagermo »

MagicWishMonkey wrote: post #19
alonium wrote: post #4

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

People need to stop posting his shit here, it's basically linkbait he's using to pimp his Whisper service. He's the worst kind of troll.

Moxie? He is kind of a real expert in everything crypto and, instead of using the phrase "military grade encryption", WhisperSystems actually explains what they do and how they do it.

His posts are very well written and understandable, even for non pros (with a pinch of sarcasm, but that's how I like it). So, where exactly is he trolling?

Re: A Crypto Challenge For The Telegram Developers

#34

Post by nwh »

moxie wrote: post #25
xnyhps wrote: post #18

Earlier quoted context omitted.

Well, not entirely the same framing. For $200k one could probably brute-force an 896-bit RSA key. ;)

I don't actually think that's true. At least, not within the time limits they defined. The $75k 896bit RSA factoring prize went unclaimed for 20 years, for instance.

Presumably if you made the prize large enough you wold get to the point where it would be economical and profitable to start fabricating your own hardware like the EFF did for DES.

http://en.wikipedia.org/wiki/EFF_DES_cracker

Re: A Crypto Challenge For The Telegram Developers

#35

Post by im3w1l »

meowface wrote: post #17
im3w1l wrote: post #11

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.

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

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

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

Re: A Crypto Challenge For The Telegram Developers

#36

Post by sdevlin »

jweir wrote: post #23
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?

Because the contest eliminates many vulnerabilities that exist in the real world. The contest framework is identical to Telegram’s (no MITM perspective, no known plaintext, no chosen plaintext, no chosen ciphertext, no tampering, no replay access, etc)

Also no side channel observations.

Re: A Crypto Challenge For The Telegram Developers

#37

Post by moxie »

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/

Re: A Crypto Challenge For The Telegram Developers

#38

Post by gregschlom »

guyht wrote: post #24

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)

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

Re: A Crypto Challenge For The Telegram Developers

#39

Post by sdevlin »

nwh wrote: post #34
moxie wrote: post #25

Earlier quoted context omitted.

I don't actually think that's true. At least, not within the time limits they defined. The $75k 896bit RSA factoring prize went unclaimed for 20 years, for instance.

Presumably if you made the prize large enough you wold get to the point where it would be economical and profitable to start fabricating your own hardware like the EFF did for DES. http://en.wikipedia.org/wiki/EFF_DES_cracker

This is true, but you could easily respond by increasing the RSA key size. This would make the protocol Telegram-secure without meaningfully improving its actual security profile in any way.

Re: A Crypto Challenge For The Telegram Developers

#40

Post by djcapelis »

nwh wrote: post #34
moxie wrote: post #25

Earlier quoted context omitted.

I don't actually think that's true. At least, not within the time limits they defined. The $75k 896bit RSA factoring prize went unclaimed for 20 years, for instance.

Presumably if you made the prize large enough you wold get to the point where it would be economical and profitable to start fabricating your own hardware like the EFF did for DES. http://en.wikipedia.org/wiki/EFF_DES_cracker

Ship yourself custom ASICs in the few months allowed by the contest guidelines and you'd earn it. FPGAs are another possibility, but even that would be a bit of an undertaking in a short timeframe and it might not actually get you much.

Also the DES hardware is slightly different than prime number factorization in terms of workload. Supercomputers are fairly well optimized for some of the types of matrix operations you'd need to do for a GNFS, which is generally the method of choice for factoring large numbers on a classical computer. Custom hardware isn't going to give you the huge boost like you'd see for brute forcing DES.

Custom hardware isn't a silver bullet and it is a large engineering problem that takes usually more time than the telegraph contest allows.

Post reply on HN