Live data from Hacker News

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

nakedsecurity.sophos.com

31–40 of 128 posts

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

#31
post #5

Really drives home what many people were saying about the authors not merely being bad at cryptography but programming in general...

I wouldn't say they're bad at programming - everyone makes mistakes. I think the issue is more a weakness in (or lack of) tests and oversight. The fact the code is open source at least gives it some accountability and the error did get spotted eventually.

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

#32
post #5

Really drives home what many people were saying about the authors not merely being bad at cryptography but programming in general...

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.

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

#33
This reminds me of the IBM RANDU PRNG on which I gave an undergrad presentation (w/ visualization). RANDU was legendarily bad; all you had to do was plot triples in a 3-D volume to see that all of the generated points would fall within one of 15 (Edit: 15, not 11) planes.

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

#34
post #24

I can mostly grok the scope of the error and the theory behind it...what's more interesting to me is to hear, preferably from the Cryptocat developers, what led to this error? An accidental regression? A deliberate decision? Cryptocat and what it aims to do is respectable, but I think what concerns people outside of the project is the prospect of unknown unknowns in the rest of the code: are the recent bug revelation…

Off-by-one errors are very common (and they have a long history). My best guess is "an honest mistake."

As for the "endemic blind spots," any crypto software needs professional reviews and a good deal of time before it can be used in critical situations.

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

#35

Cryptocat's hacktivist credibility was cemented in 2012 when its Canadian developer, Nadim Kobeissi, was stopped at the US border and interviewed about his Cryptocat-related programming activities. s/was/claimed to be/. This software clearly is not Ft. Knox, and its becoming less and less believable that US intelligence would ever feel the need to interrogate the author of an open source project, and with such brittl…

[deleted]

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

#36
post #22

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

With normal software you can load up on the unit and integration tests to make yourself more confident with your software. When the concern is with the integrity of a cryptographic system, things are not quite so simple. You can write tests, sure, but your overall confidence afterwards is going to be much different.

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

#37
post #34
post #24

I can mostly grok the scope of the error and the theory behind it...what's more interesting to me is to hear, preferably from the Cryptocat developers, what led to this error? An accidental regression? A deliberate decision? Cryptocat and what it aims to do is respectable, but I think what concerns people outside of the project is the prospect of unknown unknowns in the rest of the code: are the recent bug revelation…

Off-by-one errors are very common (and they have a long history). My best guess is "an honest mistake." As for the "endemic blind spots," any crypto software needs professional reviews and a good deal of time before it can be used in critical situations.

Yes. A pro friend of mine is fond of saying: budget 10x to design, 1x to implementation, and 10x to verification.

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

#38
post #17
post #9

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

[deleted]

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

#39
post #32
post #5

Really drives home what many people were saying about the authors not merely being bad at cryptography but programming in general...

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?

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

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

You are running the chi-square against the claimed distribution of the RNG, not against another RNG. Which is just about enough to use the RNG for simulating dice rolls ( sometimes, if the players are not too passionate). RNG can have a lot more subtile flaws, for example the RNGs from the ANSI C rand() with the suggested parameters lie in just a few thousand planes, if you construct points in some vector space out of the random numbers. ( That is bad, if you want to run Monte Carlo integration, because your error estimate improves, but not the accuracy of the result.)

So even for simulation you can have rather subtle effects, even though there you get bitten just by bad luck. The task for cryptographically secure random number generators is actually quite a bit harder, because a attacker tries to exploit any weakness in your RNG, but your tests do only tell you which specific attacks do not work.

Post reply on HN