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

101–110 of 136 posts

Re: A Crypto Challenge For The Telegram Developers

#101

Post by jacobolus »

decasteve wrote: post #98
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…

> 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. They are using SHA-1, which is indeed broken, not as broken as MD5 and its predecessors yet, but still less than a birthday attack. > The message key is defined as the 128 lower-order bits of the SHA1 of the message body (including session, message ID, etc.). A reduced SHA-1 cut down from 160 to…

I think you missed: “Both Alice and Bob now compute message_key = MD2(super_secret) (we know you like dated crypto, so we thought you’d like the MD2 hash function).”

Re: A Crypto Challenge For The Telegram Developers

#102

Post by Guvante »

chetanahuja wrote: post #42
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…

"but their servers do all of the actual processing and cryptography" I realize t'is the season to to piling on to the hapless Telegram folks, but I think that assertion is wrong.

Do you consider an HTTPS connection to be "their servers do all of the actual processing and cryptography"? Most people would (even though there are subtleties to reality) and Telegram certainly qualifies under whatever you consider HTTPS doing.

The only real difference is the usage of client keys and a custom protocol.

Re: A Crypto Challenge For The Telegram Developers

#103

Post by sdevlin »

decasteve wrote: post #98
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…

> 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. They are using SHA-1, which is indeed broken, not as broken as MD5 and its predecessors yet, but still less than a birthday attack. > The message key is defined as the 128 lower-order bits of the SHA1 of the message body (including session, message ID, etc.). A reduced SHA-1 cut down from 160 to…

Sorry, I'm afraid my original post wasn't very clear. I was describing potential problems with Moxie's intentionally weak protocol, not with Telegram.

The hash in question is MD2 used to reduce the 32-byte random secret to a 16-byte shared encryption key. MD2 is weak, but I'm not sure if it matters in this context. As I said above though, I'm also not sure that it doesn't matter.

Re: A Crypto Challenge For The Telegram Developers

#104

Post by Guvante »

andy112 wrote: post #2

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.

Two alternatives

* Have a special message that does not contain the email address and makes it's contents public. * Take whatever the first message happened to be and replace any characters in the email address with the character X and release that. Giving away the length of the email address wouldn't do anyone any good.

Re: A Crypto Challenge For The Telegram Developers

#105

Post by 6d0debc071 »

utnick wrote: post #50
finnn wrote: post #10

Earlier quoted context omitted.

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

its not done server side

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

--------------------------

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.

Re: A Crypto Challenge For The Telegram Developers

#106

Post by belorn »

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.

You want to use other peoples software, modify then and distribute it. Afterward, you then want to sue users who dare to modify or share your version?

How can anyone except authors to accommodate this, when the license choice explicit states the opposite?

Re: A Crypto Challenge For The Telegram Developers

#107

Post by mintplant »

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.

Re: A Crypto Challenge For The Telegram Developers

#108

Post by paveldurov »

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

Re: A Crypto Challenge For The Telegram Developers

#109

Post by SomeCallMeTim »

xnyhps wrote: post #43
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.

Yeah, when I started actually trying to back it up, I noticed I was probably a factor 5 off. Namely, if you look at the keylength.com values for asymmetric key sizes, 768 in 2009 ago should come close to the difficulty of 896 today. The RSA 768 challenge was broken in 2009 ( http://eprint.iacr.org/2010/006 ), which cost them "the equivalent of almost 2000 years of computing on a single core 2.2GHz AMD Opteron". Renti…

>Amazon EC2

I'm not sure how they compare in practice, but it might be worth calculating how many hours an Amazon G2 instance would take, using their high-end graphics cards as CUDA processors. I think the cost per performance ratio is much lower, and that could change the equation in the other direction.

Re: A Crypto Challenge For The Telegram Developers

#110

Post by salient »

napoleond wrote: post #99
moxie wrote: post #97

Earlier quoted context omitted.

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…

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.

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.
Post reply on HN