Really drives home what many people were saying about the authors not merely being bad at cryptography but programming in general...
Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
31–40 of 128 posts
Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#32Really drives home what many people were saying about the authors not merely being bad at cryptography but programming in general...
Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#33Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#34I 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…
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
#35Cryptocat'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…
Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#36Earlier 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.
Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#37I 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
#38Earlier 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.
Re: Anatomy of a pseudorandom number generator – visualising Cryptocat's buggy PRNG
#39Really 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 .
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
#40Seems 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.
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.