Live data from Hacker News

A Crypto Challenge For The Telegram Developers

thoughtcrime.org

131–136 of 136 posts

Re: A Crypto Challenge For The Telegram Developers

#131

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?

If you're open to an online course, there's a Stanford intro one coming up on Coursera - https://www.coursera.org/course/crypto

I did the course about 1 year ago (or maybe 2? not sure now).

The only thing I really remember from top of my head is don't implement your own crypto.

I guess I remembered the most important lesson.

Re: A Crypto Challenge For The Telegram Developers

#132
post #123

Earlier quoted context omitted.

Dual EC was not particularly common. Here's a metric: name a couple of products that you or I use regularly that ever used it. It's not as if you could design a system with Dual EC instead of HMAC DRBG and not know it; Dual EC requires bignum math. It is incredibly slow for a CSPRNG.

This is disingenuous. RSA used it as a default in a commercial crypto library, as you must know. End users won't generally be aware that it's being used in a product, but that doesn't mean it isn't out there. It is unlikely that most developers changed the default unless it was having a noticeable impact on performance, which wouldn't be the case if it was just used for key generation. http://www.wired.com/threatleve…

You probably don't use any product that uses BSAFE.

For whatever it's worth, for people who think this point is all part of some elaborate edifice of sticking up for NSA: I am now 99.9% convinced that Dual EC is in fact a backdoor, and while it's clumsy in a tradecraft sense (you can just look at it and see the problem), I've heard compelling scenarios in which it would have been effective.

I just don't think it's a backdoor that's relevant to modern software, or, even for its time (the early 00's), software that was in popular use.

Re: A Crypto Challenge For The Telegram Developers

#133
post #124

Earlier quoted context omitted.

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

Interesting. The "doping" attack seems to be aimed specifically at random number generating circuits. Presumably such attacks could be definitively detected by using the RNG to generate a long sequence and checking that the distribution of probabilities is as expected [1]? Is my understanding correct? [1] http://www.johndcook.com/Beautiful_Testing_ch10.pdf

Reading the paper, it sounds like the attacker can make the trojan arbitrarily hard to detect, in exchange for making the resulting encryption harder to crack.

In the attack they describe, Intel's hardware RNG is supposed to return the results of encrypting 128 random bits using a 128-bit random key with the AES cipher. So an attacker trying to guess the random number returned would have to try 2^256 options. Instead, the attacker modifies the chip so it returns the results of a known key used to encrypt n random bits and 128-n known bits. They therefore only have to try 2^n options -- they can make guessing the random number as easy or hard as they want for themselves.

Now the AES part makes the results of the hacked chip appear random -- the results of AES(0), AES(1), AES(2) ... will have a random distribution in the 2^256 range. (The whole point of a cipher is that it should be impossible to draw any conclusions about the inputs by examining a bunch of outputs, even if the inputs are predictable.) To detect it in software, we'll have to generate enough numbers to start to see a suspicious number of repeated results. So if the attacker sets n==2, they'll have a really easy time cracking the resulting encryption, but we'll easily detect it -- we'll quickly notice that the RNG always returns one of four numbers. On the other hand if they set n==32, they'll have to try n^32 options to crack the resulting encryption, but there will be few enough repeats that we'll give up testing before we notice anything is wrong. (Of course if they're more paranoid and have better resources, they could go with n==64 or whatever -- it's like a dial they can use to set the difficulty where they want it.)

The neat thing here, of course, is that this backdoor is only valuable if you know the bits that have been hardcoded into the chip. So it remains secure against everyone in the world, except the one three-letter agency that managed to modify the chip.

Or their private contractors and consultants, I suppose.

Re: A Crypto Challenge For The Telegram Developers

#134
post #123

Earlier quoted context omitted.

This is disingenuous. RSA used it as a default in a commercial crypto library, as you must know. End users won't generally be aware that it's being used in a product, but that doesn't mean it isn't out there. It is unlikely that most developers changed the default unless it was having a noticeable impact on performance, which wouldn't be the case if it was just used for key generation. http://www.wired.com/threatleve…

You probably don't use any product that uses BSAFE. For whatever it's worth, for people who think this point is all part of some elaborate edifice of sticking up for NSA: I am now 99.9% convinced that Dual EC is in fact a backdoor, and while it's clumsy in a tradecraft sense (you can just look at it and see the problem), I've heard compelling scenarios in which it would have been effective. I just don't think it's a…

What do you make of the list given in this other comment that includes copy machines and game consoles?

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

Re: A Crypto Challenge For The Telegram Developers

#135
post #127

Earlier quoted context omitted.

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

I really don't know how well the required operations execute on a GPU. I've only skimmed the RSA 768 paper to find that line.

Fair enough. I've read that using CUDA (or another GPU-based language) you can get at least a 10x the GFLOPS of a 4-CPU Xeon [1], though, and RSA cracking should easily parallelize, if I'm understanding the process correctly. And the high-end NVidia cards in the G2 instances have 1,536 CUDA cores each. No, I'm not kidding. The one benchmarked in the link above is about 1/3 the GFLOPS of the one in the G2 instances.

And it looks like a reserved G2 instance is 0.65/hour (though can be lower on the spot market and in the reserved instance marketplace). So if there's a 120x speed improvement over the "single core 2.2GHz AMD Opteron" (and that's assuming each core is as fast as the Xeon core above), for only 11x the cost...well, it gets a lot cheaper.

In fact, it ends up, if I haven't done my math wrong, at about $94,900 of full instance time (less if you get spot or reserved instances). [2] To win the $200k prize. Hmm....

[1] http://archive.benchmarkreviews.com/index.php?option=com_con...

[2] "the equivalent of almost 2000 years of computing on a single core 2.2GHz AMD Opteron": That's 17,520,000 hours. If the G2 instance gets you 120x performance improvement, that's 146,000 hours. At 0.65/hour, that's $94,900.

Re: A Crypto Challenge For The Telegram Developers

#136
post #129

Earlier quoted context omitted.

I don't keep up on everything, but I thought Dual_EC_DRBG was used by nobody else for any real world crypto. Did these guys look over the Wiki page and decide it would be fun to be the first?

Dual_EC_DRBG is used: http://security.stackexchange.com/questions/43164/which-prod... > Since we know the RSA BSAFE library uses Dual_EC_DRBG (...) by default, I would guess that this would be the main vector. > As for the use of BSAFE, I can easily find (hint: use your favourite search engine to search for the terms "This product includes" "RSA BSAFE") implementations, oddly skewed towards imaging and gaming devices…

I thought the problem was the recommended implementation of Dual EC PRNG that was broken - the specific point selection that was mandated to be suitable for government use - the one that RSA used?
Post reply on HN