Hacker News Reader

Comment by mds | Hacker News Reader

Cryptography Snake Oil Warning Sign #9: Cracking contests.

https://www.schneier.com/crypto-gram-9902.html (1999)

Our Twofish cryptanalysis contest offers a $10K prize for the best negative comments on Twofish that aren't written by the authors. There are no arbitrary definitions of what a winning analysis is. There is no ciphertext to break or keys to recover. We are simply rewarding the most successful cryptanalysis research result, whatever it may be and however successful it is (or is not). Again, the contest is fair because 1) the algorithm is completely specified, 2) there are no arbitrary definition of what winning means, and 3) the algorithm is public domain.

This Telegram contest may seem superficially similar to that fair contest, but it differs in some important ways. First, this contest isn't rewarding "best effort". Second, this contest doesn't meet those criteria, because their central server isn't being tested here. The goal of a product like Telegram is to defend against adversaries like governments, and hence governments will be able to probe their servers for weaknesses. You may say that we, too, can do the same, but if that's the case, a test server should be made available and the contest should explicitly try to get as many people as possible to break it.

This contest is interesting, but it's too artificial. As just one example of why that's the case: breaking real-world crypto often relies on side channel attacks, for instance timing attacks, and there's no opportunity of employing those attacks here due to the artificial nature of the contest.

Once again, if people here are interested in a secure alternative to Telegram that doesn't rely on public stunts for cryptanalysis, then check out TextSecure. It was designed by cryptographers, is open-source, and has been studied in detail for years. https://whispersystems.org/

EDIT: It appears Telegram is also vulnerable to MITM attacks. This is the NSA's preferred method of gathering info, so this is the most likely attack vector against Telegram. Due to the design of the protocol, there seems to be no defense. https://news.ycombinator.com/item?id=6931892

Telegram's response is "we protect against this because if you've initiated a secret chat previously, then you're protected." However, this isn't true. 1) a global adversary like the NSA can (and will, if they become interested in Telegram) simply MITM every secret chat session when they're first initiated; therefore if you use Telegram, you should assume the government has your data anyway, since this protocol offers no protection against mass snooping. 2) Secret chats aren't even the default type of chat in Telegram anyway, making it very unlikely that users will be protected by it. The defaults need to be secure.

References:

https://news.ycombinator.com/item?id=6931892

https://news.ycombinator.com/item?id=6931961 (Telegram's response, which seems to verify that secret chats can be MITM'd on first initiation.)

https://news.ycombinator.com/item?id=6931903 (Demonstrates that Telegram seems to be misunderstanding why someone breaking into the central server can MITM your chats.)

Moxie is a great researcher and WhisperSystems seem serious. However, I don't understand why you claim that TextSecure is designed by cryptographers.

From what I've seen, they use something called the "Axolotl Ratchet", developed by Trevor Perrin. A quick search of his name didn't yield any crypto papers / research by him.

Also, you write "and has been studied in detail for years"

There are no links/references to code/protocol reviews in the WhisperSystems website.

Again, I have the utmost respect for their research, it's just that from the side of a non-crypto-versed user/coder, Telegram and TextSecure look the same.

I don't understand why you claim that TextSecure is designed by cryptographers. From what I've seen, they use something called the "Axolotl Ratchet", developed by Trevor Perrin.

Here are some resources:

https://www.hnsearch.com/search#request/all&q=by%3Atptacek+t...

https://www.whispersystems.org/blog/advanced-ratcheting/

https://pond.imperialviolet.org/

Trevor Perrin is a cryptographer.

Trevor Perrin worked at Cryptography Research (I mean, the domain name is cryptography.com!) for six years, which alone should probably be enough to call yourself a cryptographer. His other work outside of CRI is also really quite prolific.

> Again, I have the utmost respect for their research, it's just that from the side of a non-crypto-versed user/coder, Telegram and TextSecure look the same.

Yep, it's frustrating to be the quixotically genuine seller in a market for lemons.

I have a question about TextSecure. Do you plan on implementing something like SMP from OTRv3 in the TextSecure protocol?

Perrin appears to be one of the lead authors here: http://tack.io/draft.html

You might also try reading some of his more recent discussion comments on IETF working groups:

- http://www.ietf.org/mail-archive/web/websec/current/maillist...

- http://www.ietf.org/mail-archive/web/tls/current/maillist.ht...

- (from 2002): http://mhonarc.domainunion.de/archive/html/ietf-openpgp/2002...

Just a few things that turned up when I Googled him.

1. register numbers close to the target.

2. wait until sender mistypes destination on one message.

3. claim prize.

A better discussion from him on the topic is linked to from this page: https://www.schneier.com/crypto-gram-9812.html#1

In #5, Schneier says "For public-key cryptography, 2048-bit keys have same sort of property; longer is meaningless."

Back in September, he issued a new public key of 4096 bits[1].

1. https://news.ycombinator.com/item?id=6376954

If there's anything that's certain, it's the progress of compute power. The fact that his statement lasted 14 years is impressive. I mean, 640K ought to be enough for anyone.

No, not at all. Requiring an increase of 2048 bits over 14 years implies that computing power increases by a factor of 216 every year.

You need to factor in speedups due to advances in factoring algorithms, too. And it's possible that the software doesn't have any options between 2048 and 4096. (I have no idea, I didn't check.)

That would be true if RSA keys were brute forced, but they aren't - e.g. 512 bit RSA takes days/weeks to break on commodity hardware these days, whereas 512 bit brute force (as is essentially needed for ECC these days) takes significantly longer than the estimated age of the universe.

See http://en.wikipedia.org/wiki/Integer_factorization_records

Tarsnap has a bug-bounty program [1] which has uncovered numerous bugs, including a critical security bug [2]

It seems to me that offering a bug bounty can significantly improve the security of a system, even when the prize-money is relatively small.

[1] http://www.tarsnap.com/bugbounty.html

[2] http://www.daemonology.net/blog/2011-01-18-tarsnap-critical-...

the difference here is that there's no "fake-world" contest. Tarsnap is asking for a real-world hack of their system.

Telegram, on the other hand, is trying to prove that their algorithm is unbreakable. AES is pretty good too. As is noted in other comments, it's generally the system, not the algorithm, that gets broken.

The nonce-increment bug wasn't found as part of the bug bounty program; it was retroactively included when I set up the bug bounty program a few months later.

From that page:

> [...] the contest is fair because 1) the algorithm is completely specified, 2) there are no arbitrary definition of what winning means, and 3) the algorithm is public domain

Somewhat sad to see people on HN posting the Schneier link to counter the post without even bothering to read what it is about. I mean, it's almost like people have already formed opinions without giving the Telegram people a try. This is not how science works.

When Telegram showed their product on HN a few days ago, they were given constructive criticism and asked to justify the way they implemented their system. They responded by bragging about how many mathematics PHDs worked on the product.

Not satisfied at leaving it there, they then claimed that their crypto system doesn't need to be justified, because their customers aren't concerned about the specifics of their implementation of known broken algorithms.

Finally, they placed the burden of proof on the public, which doesn't work when it comes to cryptography.

They were given the opportunity to explain their design decisions in an environment of mutual respect, and they responded to this offer by stonewalling two of HN's resident security gurus.

Marketing Strategy #724: Create Controversy

(regardless of the product, they succeeded in a cheap way to get launched, very likely at a cost of $0)

"Since key length and key structure vary and since the encryption engine does not use any mathematical algorithms, reverse engineering is impossible and guessing is not an option"

Gold :-)

Expanded here: https://www.schneier.com/crypto-gram-9812.html#contests

This contest isn't a great example of the kind of contests he is talking about.

1) They are giving you the source code, protocol, and a tcpdump of all traffic between the chatters. You can even send messages via the protocol to one of the participants. Its not just here is some encrypted data, decrypt it.

2) They are offering a significant amount of money.

Right, except for

2) there are no arbitrary definition of what winning means

The definition of winning in this contest creates a large class of potential vulnerabilities that would be paid $0.

Wouldn't legitimate cryptography products also tend to offer such challenges? It's not much different than bug bounties, which are common and (at least according to my impression) well-accepted as a legitimate practice.

Reply on news.ycombinator.com