Live data from Hacker News

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

nakedsecurity.sophos.com

21–30 of 128 posts

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

#21
Nice article, I can certainly vouch for creating a visualization to clue you in that there may be a problem.

One of the things I built out of Java when I was hanging out on the cypherpunks list was a 'Noise Sphere' applet. Basically this is a way of testing a PRNG visually. It was fun to put various ideas through it to see how they panned out (most really sucked) One of the cool things was using the alpha emitter RNG from a smart card and finding out that it too was slightly biased in the presence of foil on one side (never did find out why that was, but it did stick out)

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

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

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 programmer's face fear when asked to write crypto software. They know enough to be shit scared. You need that kind of people.

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

#23
post #7

I'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…

If you are interested this webpage does some really neat stuff with visualizing PRNGs.

http://lcamtuf.coredump.cx/oldtcp/

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

#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 revelations indicative of endemic blind spots?

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

#25
post #7

I'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…

There's a nice article "Cryptography is a science, not engineering" [0] that gives an overview of cryptography that might help with your question as well.

The essence is that in modern cryptography you're creating a provably secure system. One of those proofs is that your prng outputs a uniform distribution.

[0] http://www.daemonology.net/blog/2013-06-17-crypto-science-no...

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

#27
post #22

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

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

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

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

#29
post #18
post #17

Earlier quoted context omitted.

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.

Maybe at some point a project exhausts whatever potential goodwill/snarklessness is available and just becomes an object of snark - and at that point and beyond, perhaps the benefits of the project having a reputation of being a snarkmagnet outweigh negatives of the inevitable snark it generates.

Makes it a lousy, toxic topic for message boards but that seems a comparatively small price for a defense against the notion that Cryptocat is (or likely, ever will be) secure.

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

#30

  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 brittle security, about the cryptography techniques used therein.

I find it far more believable that the young developer with a penchant for dramatics and a reply for everything has a talent for PR. And a shallow understanding of the grave consequences of faulty crypto software.

Post reply on HN