The problem isn't one of demeanor it's that I can't tell what's going on with this project. Meanwhile: I cannot immediately tell from the record which of the independently discovered vulnerabilities in Cryptocat correspond to which CVEs or which advisories and which severity descriptions. This was, as is evident from the thread, a problem for Cryptocat's uninvolved, un-implicated lead developer. Handling a coordinated disclosure on a Github pull request is tricky under the best of circumstances, but the Silent Circle team was dealing with an unplanned partial disclosure and was, with Dowd's cooperation, trying to get the genie back into the bottle long enough for (from what I can tell) their competitors to get patched. In the process of handling an embargoed disclosure, Silent Circle groomed (perhaps aggressively) a Github pull request thread. The project should meet the standards that it has loudly set for others, and I don't think it has. Mark had gone public with those vulnerabilities quickly as a result of a miscommunication with the Silent Circle team, but then redacted his disclosure and agreed to embargo the findings while Silent Circle coordinated fixes with all of the Silent Circle competitors that relied on that library what you see in that thread is, apparently, the lead developer of Cryptocat, which doesn't use ZRTPCPP, repeatedly criticizing Silent Circle's handling of the incident.) (Cryptocat is "kaepora" in that thread the context there is that Mark Dowd had reviewed ZRTPCPP, an open source implementation of the ZRTP protocol that Silent Circle funds and relies on, and found several memory corruption vulnerabilities. Pointing this out would be be gratuitous, except that Cryptocat's project leader has very high standards when it comes to the disclosure behavior of that project's competitors: I can't be the only one confused, and I do wonder whether that confusion is strategic. I am totally, completely in the dark as to which coding errors (there have been several in the past few months) attach to which CVEs and which versions, and about when these vulnerabilities were reported to the project and when they were subsequently disclosed. v2.1.11 which was supposed to fix this problem has this 'incorrect radix' bug in it? Please tell me I'm wrong, or do we need another CVE and another release? Var rand = Cryptocat.randomString(64, 0, 0, 0, 1)ĮDIT EDIT: So just to be clear.
It wasn't until July 4th until it finally became: Cryptocat.randomString(64, 0, 0, 1, 0) returns a 64 character string of 0-9, why are they calling str2bigInt with a hex radix? Did they add the last '0' in the wrong place? Or maybe I'm looking at the wrong check in.ĮDIT: Ok, it WAS still wrong as of June 4th. Įven now looking at this code, for me it just doesn't pass the 'WTFs per minute' test. Also the least significant 3 bits are zeroed giving you a key space of 2*10^16 (2^54.15). So each of those "15 bit integers" were only the values 0 to 9 (3.32 bits). Each character was considered an element in the array. This made the ECC private keys ridiculously small because they passed a string of decimal digits into a function expecting an array of 17, 15 bit integers. > The bug that lasted 347 days was the confusion between a string and an array of integers. MyPrivateKey = BigInt.str2bigInt(rand, 16) Rand = Cryptocat.randomString(64, 0, 0, 1, 0) MyPrivateKey = BigInt.str2bigInt(rand, 10)
Rand = Cryptocat.randomString(32, 0, 0, 1) MyPrivateKey = Cryptocat.randomString(32, 0, 0, 1) However, the off-by-one bias was actually the least of the problems with Cryptocat's random numbers.įrom reading Steve's write-up, the problem was that their keys were ridiculous undersized, because they called their own function wrong: First, this is a great article showing the bias in Cryptocat's very awkward PRNG code.
0 kommentar(er)
