6 ms·
Really drives home what many people were saying about the authors not merely being bad at cryptography but programming in general...
by jlgreco 13y ago
Really drives home what many people were saying about the authors not merely being bad at cryptography but programming in general...
- tptacek 13y agoI 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 13y ago[deleted]
- omra 13y agoI 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.
- magikarp 13y agoWhether 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.
- tptacek 13y agoI don't think the problem has much to do with how good a programmer you are.
- aortega 13y agoYou 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.
- IsThisObvious 13y agoI 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.
- jlgreco 13y agoWith 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.
- IsThisObvious 13y agoWe go beyond unit tests to verify that the algorithms can't create certain states by any execution path, etc. Formal verification of software properties is an interesting field.
- DanBC 13y agoA blog post about the process would be fascinating, and probably something that many on HN would be interested in.
- glurgh 13y agoSure 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.
- tptacek 13y agoI think the project is worth criticizing, but that the concerns are serious enough to deserve better than snark.
- glurgh 13y agoMaybe 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.
- deleted 13y ago[deleted]
- damian2000 13y agoI 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.
- mpyne 13y agoWell 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.
- jlgreco 13y agoIt's not just the errors that were made though. I mean, ignoring the off-by-one error: repeat byte250 = randomSalsaByte() until byte250 <= 250 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?
- mistercow 13y agoHow else do you generate an unbiased random number between 0 and 250? As far as I know, that's the standard algorithm.
- jlgreco 13y agoMy concern is with why they are doing that in the first place. It is possible that I am missing something here, I haven't looked at their actual code, but it seems to me that this concern would have been entirely avoided if they went with 0-F instead of 0-9.
- mistercow 13y agoYes, I definitely agree with that, and I don't understand why they did it that way. Generating a float in the [0,1) range by producing decimal digits seems utterly perverse. The sane, naive, and correct way to do it is to generate an integer between 0 and 2^53 and then divide by 2^53.
- marshray 13y agoOr use an array of integers 0 <= n < 2^x. Some of the Javascript libraries involved are even using such a format.