Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG

nakedsecurity.sophos.com

Post reply on HN
Print view View original

111–120 of 128 posts

Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG

#111

Post by tptacek »

davidw wrote: post #106
jdiez17 wrote: post #103

Earlier quoted context omitted.

I don't think he meant to "involve the government." I do agree with his sentiment though, an inexperienced programmer should not be allowed to write critical software. This is, of course, very difficult to implement in practice.

I don't know much about writing "critical software" - because it's not something I've ever done. However, my guess would be that with proper processes, you should be able to let a junior programmer write the code, because bugs and errors and mistakes will come out in the wash. It's not like experienced programmers don't make mistakes! Perhaps it simple doesn't make sense to turn a junior guy loose, but my thinking is…

I agree. I think the problem isn't how the code is implemented; I think it's how it's designed and verified.

Most of the time, generalist developers can severely (sometimes even completely) mitigate the expense of competent design and verification by adopting trusted components and adapting the application requirements to those components (instead of the other way around, which is the usual way developers incorporate third party components).

If you don't do that, though, you're looking at the 10x-1x-10x problem: however much time it takes you to build your system, you're looking at a 1:20 ratio of effort for non-implementation work, and that's serialized.

(Lest anyone thing I'm talking my own book here: we do what I think is an atypically good job at handling the ancillary crypto stuff that comes up in normal applications, but I don't think we're well qualified to do formal reviews of cryptosystems.)

Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG

#112

Post by DanBC »

kunil wrote: post #99
baq wrote: post #83

Earlier quoted context omitted.

this is crypto. there were 'less serious' bugs like initializing arrays to zeros (see debian) that led to catastrophic results, which is what the explanation is about.

I am not saying if bug is critical or not. It is just pages of explanations, charts and stuff. I was expecting a video explanation by the end. If they are targeting non-crypto people (which includes me), explaining how a bad random algorithm affects cryptology would be better instead of showing that algorithm is bad in 5 different ways. Also any link to articles about that Debian bug?

Random numbers are used for different things, but mostly generating keys. An attacker that knows everything about your system (all the hardware, and the software, all the sourcecode, everything) should not be able to predict the next bit output by a prng.

Errors include:

i) using a source that is not random. As mentioned elsewhere some hardware devices provide skewed numbers, and even de-skewing doesn't help too much.

ii) using a poor seed.

The Debian bug is an example of ii -

> This vulnerability was caused by the removal of two lines of code from the original version of the OpenSSL library. These lines were used to gather some entropy data by the library, needed to seed the PRNG used to create private keys, on which the secure connections are based. Without this entropy, the only dynamic data used was the PID of the software. Under Linux the PID can be a number between 1 and 32,768, that is a too small range of values if used to seed the PRNG and will cause the generation of predictable numbers. Therefore any key generated can be predictable, with only 32,767 possible keys for a given architecture and key length, and the secrecy of the network connections created with those keys is fully compromised.

(http://en.wikinews.org/wiki/Predictable_random_number_genera...)

(www.schneier.com/blog/archives/2008/05/random_number_b.html)

Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG

#113

Post by danielweber »

aortega wrote: post #22
magikarp wrote: post #16

Earlier quoted context omitted.

Whether Cryptocat programmers suck or not, I've seen worse errors from better programmers. I'm not sure what's the metric to follow here when it comes to correlating these two items.

You are dangerously fooling yourself by minimizing the importance of those bugs. Cryptography software is not like regular software. It is critical software, like the kind used to run planes or nuclear power plants: People's lives depends on it. People with no programming experience should be literally banned by law from writing critical software. You should take those bugs way more seriously. PS: I have seen a progr…

I may have bombed an interview a few weeks ago when they asked me to design a security protocol on the fly. I really didn't want to answer that question (because anything I'd say would be vulnerable in some way) and ended up rambling on about certificates for a while.

I guess next time I'll be ready to say "that's not something you do during an interview."

Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG

#114

Post by afreak »

autodidakto wrote: post #42

I thought cryptocat was independently audited. Who audited it and why didn't they find these problems?

Cryptocat was audited by Veracode but it is my understanding that they just audited the functionality of it (IE: the interface and all that is related) but not the cryptography, as it was out of scope.

Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG

#115

Post by pessimizer »

kunil wrote: post #99
baq wrote: post #83

Earlier quoted context omitted.

this is crypto. there were 'less serious' bugs like initializing arrays to zeros (see debian) that led to catastrophic results, which is what the explanation is about.

I am not saying if bug is critical or not. It is just pages of explanations, charts and stuff. I was expecting a video explanation by the end. If they are targeting non-crypto people (which includes me), explaining how a bad random algorithm affects cryptology would be better instead of showing that algorithm is bad in 5 different ways. Also any link to articles about that Debian bug?

http://wiki.debian.org/SSLkeys#Technical_Summary

Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG

#117

Post by zaroth »

marshray wrote: post #69
zaroth wrote: post #54

First, this is a great article showing the bias in Cryptocat's very awkward PRNG code. However, the off-by-one bias was actually the least of the problems with Cryptocat's random numbers... From reading Steve's write-up, the problem was that their keys were ridiculous undersized, because they called their own function wrong: May 7, 2012 (switched from DH to ECC): myPrivateKey = Cryptocat.randomString(32, 0, 0, 1); Ap…

Maddening isn't it?

It's so bad I want to put on my tin foil hat and believe the NSA made them do it.

How do you go back to the same mission-critical single line of code again, and AGAIN and keep getting it wrong?

Any change to that line of code raises extreme red flags. As a developer, if you're making a change to that line after it shipped, you're in complete "wow I fucked up bad" mode. Instead it looks like they're just changing it randomly, month after month, like it's some inconsequential debug flag. Really, this just blows my mind.

Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG

#118

Post by IsThisObvious »

z-factor wrote: post #91
IsThisObvious wrote: post #49

Earlier quoted context omitted.

I know people who write crypto software that must conform to formal verification of the algorithm, requires detailed design documentation before a single line of code, etc.

Funny thing is that code is then compiled with a compiler was not formally verified, so it's still a 'fingers crossed' situation.

The code generator we use (at my job; not crypto) was written in Coq and formally verified to generate code with certain properties, given properties of the input.

I assume that the crypto group I know, who developed most of the code generator I use, takes similar measures to make sure that their verified "theorems" translate correctly to code.

The unverified stage is actually the hardware, which is an open problem.

Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG

#119

Post by damarquis »

aortega wrote: post #22
magikarp wrote: post #16

Earlier quoted context omitted.

Whether Cryptocat programmers suck or not, I've seen worse errors from better programmers. I'm not sure what's the metric to follow here when it comes to correlating these two items.

You are dangerously fooling yourself by minimizing the importance of those bugs. Cryptography software is not like regular software. It is critical software, like the kind used to run planes or nuclear power plants: People's lives depends on it. People with no programming experience should be literally banned by law from writing critical software. You should take those bugs way more seriously. PS: I have seen a progr…

Cryptography software is usually critical but I think unlike the code for planes and nuclear power plants it doesn't necessarily have to be. Typically cryptography software is advertised as secure against an adversary has unlimited resources. However, the designers of the software can choose whatever threat model they want as long as they make that clear to their users.

I am thinking of a disclaimer like "We believe our product is secure enough that the minimum cost for to an adversary to decrypt a message is at least $ 10^k" for some k and the cost is an estimate of the total cost of factors like number of hours of cryptanalysis, number of cycles, etc.

This way, if the code is found to be completely broken at some point then the error is considered relative to the level of security the designers intended.

Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG

#120

Post by agrona »

JunkDNA wrote: post #28

Seems like at a minimum, if you are doing your own random number generator, you should have a test harness that runs the chi squared test and compare against a known good random number source. I wonder how many other automated tests one could stack up against a crypto codebase to do that kind of basic checking.

John Cook has some interesting material on testing PRNGs in his chapter for the book Beautiful Testing. His material is (was?) online free, here: http://www.johndcook.com/blog/2010/12/06/how-to-test-a-rando...
Post reply on HN