I wonder - if you took in aggregate the time people spent complaining about Cryptocat could a more secure alternative have already been built? :-)
Anyway, I really enjoyed this article. Informative, interesting, and free of snark.
Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
41–50 of 128 posts
Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#42I thought cryptocat was independently audited. Who audited it and why didn't they find these problems?
Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#43Seems 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.
Just run NIST DieHard or similar. Of course that is only a statistical test which is necessary but not sufficient for CSPRNG but it can help find problems like this.
Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#44Earlier quoted context omitted.
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 help write microcontroller code for pressure equipment management. If something goes sufficiently wrong in heating/fails to properly vent, an explosion can occur, endangering everyone in the area. Even unrelated code is heavily audited to make sure that it can't somehow impact the main control loop and cause an invalid state. Cryptography software should be much the same.
The problem is no one would volunteer to write crypto code under those constraints.
Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#45Why doesn't the article include updated graphs with the bug fixed?
Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#46>The code above is certainly an inelegant solution, since it is, in theory, at least, a potentially infinite loop.
As far as I know, it is the only solution for generating unbiased random numbers in a range that does not divide the native range of the PRNG you're using.
What I don't understand is why they're working in decimal in the first place. The obvious solution is to generate a random integer in the range [0, 2^53) (which does not require an unbounded-time loop, since 2^53 divides 2^64) and then divide by 2^53. I am open to the possibility that there's some quirk of floating point arithmetic that means that won't work [edit: less so now that I see it's how Java implements it¹], but I can hardly imagine that it's worse than this crazy business of generating 16 decimal digits because, hey, log₁₀(2^53) is pretty close to 16.
¹http://docs.oracle.com/javase/7/docs/api/java/util/Random.ht...
Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#47I don't understand much of crypto...
But I am game developer, and game developers (specially RPG fans) love random numbers.
Some games of mine, I suspected something was off with the PRNG, and did something like they did on the ending, I used the random number generator to draw pictures.
Biased generators were quite obvious, because they made obvious patterns (one of the worst offenders was C default random function on the mingw that came with Dev-Cpp, instead of drawing noise, or weird noise, it drew diagonal lines... yes, LINES, it became clear to me that it was terrible...)
In the end I choose Mersenne Twister, it is a very good PRNG... For games that is, although the Mersenne Twister does generate random looking numbers, its author claim it is bad for crypto, Mersenne Twister, I don't remember why, can be predictable enough for anti-crypto.
Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#48Earlier quoted context omitted.
Well a fencepost/off-by-one error is hardly unique to bad programmers. There are certainly instances of poor crypto implementation, but I don't think this particular example is worthy of the appellation of poor programming .
It's not just the errors that were made though. I mean, ignoring the off-by-one error: repeat byte250 = randomSalsaByte() until byte250 I am not sure what sort of code-review process they had in place if someone saw that and thought "Yup, brilliant. Ship it." I am sure we have all written code like that at one point in our lives, but code that is shipping to the general public?
How else do you generate an unbiased random number between 0 and 250? As far as I know, that's the standard algorithm.
Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#49Earlier quoted context omitted.
I help write microcontroller code for pressure equipment management. If something goes sufficiently wrong in heating/fails to properly vent, an explosion can occur, endangering everyone in the area. Even unrelated code is heavily audited to make sure that it can't somehow impact the main control loop and cause an invalid state. Cryptography software should be much the same.
The problem is no one would volunteer to write crypto code under those constraints.
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.
Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#50Earlier quoted context omitted.
Well a fencepost/off-by-one error is hardly unique to bad programmers. There are certainly instances of poor crypto implementation, but I don't think this particular example is worthy of the appellation of poor programming .
It's not just the errors that were made though. I mean, ignoring the off-by-one error: repeat byte250 = randomSalsaByte() until byte250 I am not sure what sort of code-review process they had in place if someone saw that and thought "Yup, brilliant. Ship it." I am sure we have all written code like that at one point in our lives, but code that is shipping to the general public?
It's not the most elegant code I've ever seen - but I don't otherwise see a red flag. What's your problem with it ? I don't think the worry that a semi-infinite string of legitimate values >250 is going to come out of randomSalsaByte() is a real, practical problem. You may as well worry that the complete works of Shakespeare asciified might come out of the PRNG. In theory it could happen. In practice, it won't happen even once in 10^100 universe lifetimes. The transistors in the CPU are going to spontaneously fail whilst executing the code zillions of times more often.