Live data from Hacker News

A Crypto Challenge For The Telegram Developers

thoughtcrime.org

21–30 of 136 posts

Re: A Crypto Challenge For The Telegram Developers

#21
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/

This looks like a better alternative, but unfortunately all of their code is closed source as well.

I completely understand the desire for developers to make certain applications closed source, but if your application's main selling point is user privacy and security, you really need to abandon that desire.

Re: A Crypto Challenge For The Telegram Developers

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

They don't need keyloggers on every phone. Having them on a wide range of people's phones (say, people involved with various Occupy stuff) is a very real possibility.

Re: A Crypto Challenge For The Telegram Developers

#23
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?

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)

Re: A Crypto Challenge For The Telegram Developers

#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)

Re: A Crypto Challenge For The Telegram Developers

#25
post #18
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…

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.

Re: A Crypto Challenge For The Telegram Developers

#26
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?

In real life, a lot of breaks in crypto security come from sidechannel attacks, man-in-the-middle attacks, chosen plaintext attacks, etc. Just posting a small number of already-encrypted messages disallows all of these possibilities.

Re: A Crypto Challenge For The Telegram Developers

#27
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?

The problem is not whether the protocol is secure - the problem is that there's no way we can tell. Historically, that means that it's likely not to be secure.

With regards this counter-challenge. The crypto here is known to be poor. If this counter-challenge cannot be broken, then it shows that the challenge issued by Telegram is no proof of security.

SO in short,

* we don't know if no one can read the Telegram-encyphered messages,

* the challenge provides effectively zero evidence that it's secure,

* Telegram will proclaim loudly that no one has broken their crypto,

* non-specialists will be fooled by this.

If I haven't answered your question, perhaps you could be more explicit as to what you're not understanding.

Re: A Crypto Challenge For The Telegram Developers

#28
post #14
post #9

Earlier quoted context omitted.

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

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.

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.

Re: A Crypto Challenge For The Telegram Developers

#29
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?

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

Re: A Crypto Challenge For The Telegram Developers

#30
post #10
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.

This can't be right. Server-side crypto? I.e. client transmits to the server in plaintext? Surely no one is that clueless about cryptography.
Post reply on HN