I think the criticism of the loop is a bit unfair. If your random number generator returns >250 a thousand times in a row, you have bigger problems than slowness.
Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
11–20 of 128 posts
Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#12Interesting though this is, all it really shows is that there is a bias in the random number generation. I would be more interested to know if this is sufficient to break Cryptocat. Would this really make a brute force attempt much easier?
This isn't a disclosure of a new vulnerability; it's a followup on an earlier article which documented a much more significant problem with key management in Cryptocat.
Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#13Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#14I'm a complete noob when it comes to cryptography. I understand that having a PRNG that doesn't return numbers with even distribution across a range is bad. Extreme example would be something like http://xkcd.com/221/ . But could someone explain how an attacker can take advantage of the fact that 0 is returned ~1% more often than other digits? It this flaw alone sufficient to break cryptocat? Or does it simply make b…
> I understand that having a PRNG that doesn't return numbers with even distribution across a range is bad.
That's (potentially dangerously) oversimplified. Uniformity is one of the consequences rather than the requirement itself. The core requirement is unpredictability. If the output is non-uniform, it means the output isn't fully unpredictable (which may or may not lead to practical attacks depending on the degree of the problem and how the PRNG is actually being used).
Meanwhile, you can also create a uniform PRNG that isn't secure at all (e.g. http://en.wikipedia.org/wiki/Mersenne_twister ).
Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#15Earlier quoted context omitted.
I upvoted this because, of course, it confirms my own biases, but kind of wish I hadn't, because we're not helping with comments like these.
[deleted]
I agree that an off-by-one error is not a huge deal in most cases, but cryptography is one of those places where you cannot get it wrong. The programmers, or a employee well-versed in cryptography, should have ran a Chi-Squared test immediately on the random data to make sure it was random. (That is the first thing I would try, and I only have a working knowledge of statistics and cryptography.)
Cryptography is unforgiving, and when your code could seriously endanger someone else, you have to be constantly vigilant.
Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#16Really drives home what many people were saying about the authors not merely being bad at cryptography but programming in general...
I upvoted this because, of course, it confirms my own biases, but kind of wish I hadn't, because we're not helping with comments like these.
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.
Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#17Really drives home what many people were saying about the authors not merely being bad at cryptography but programming in general...
I upvoted this because, of course, it confirms my own biases, but kind of wish I hadn't, because we're not helping with comments like these.
Sure but the author(s) of Cryptocat have been so uniquely resistant to help/input, over a fairly long period of time. Maybe your euphemism 'unserious' is worth adopting for every time one wants to say 'bad' or 'incompetent', in cases like this.
Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#18Earlier quoted context omitted.
I upvoted this because, of course, it confirms my own biases, but kind of wish I hadn't, because we're not helping with comments like these.
Sure but the author(s) of Cryptocat have been so uniquely resistant to help/input, over a fairly long period of time. Maybe your euphemism 'unserious' is worth adopting for every time one wants to say 'bad' or 'incompetent', in cases like this.
I think the project is worth criticizing, but that the concerns are serious enough to deserve better than snark.
Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#19Earlier quoted context omitted.
I upvoted this because, of course, it confirms my own biases, but kind of wish I hadn't, because we're not helping with comments like these.
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.
I don't think the problem has much to do with how good a programmer you are.
Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#20I'm a complete noob when it comes to cryptography. I understand that having a PRNG that doesn't return numbers with even distribution across a range is bad. Extreme example would be something like http://xkcd.com/221/ . But could someone explain how an attacker can take advantage of the fact that 0 is returned ~1% more often than other digits? It this flaw alone sufficient to break cryptocat? Or does it simply make b…
At a high level of abstraction: If one runs a nuclear power plant, one does not make a practice of tolerating small oil spills. Small oil spills are almost harmless. So are small quantities of sparks. The combination of small oil spills and small quantities of sparks, however, is a severe problem and gets worse in a hurry if it compounds with certain other usually benign properties of nuclear power plants.
Unfortunately, the sort of nuclear power plant operators which tolerate oil spills are often sufficiently not on their A game to tolerate sparks.
This is a very handwavy explanation. In particular, God doesn't hate nuclear powerplants and try to introduce sparks into them at inopportune moments just to see if they happen to find an oil spill, but The Adversary often can and will do this to your cryptosystem.