Since Cryptocat’s core PRNG function, Cryptocat.random(), returns a JavaScript number, the coders made sure they extracted all possible variability every time it was called.
Usefully, 8-byte floats allow you to represent integers up to and beyond 32 bits, though annoyingly this numeric range doesn’t extend all the way to 64 bit integers.įor technical reasons, IEEE-754 numbers run out of integer precision at 2 53, which corresponds to nearly, but not quite, 16 decimal digits of precision. Cryptocat random numbers, old-styleĬryptocat is written in JavaScript, which represents numbers internally as 8-byte IEEE-754 floating point numbers. With this in mind, I thought it might be interesting, and educational, to drill into one of Cryptocat’s now-patched PRNG bugs. So, to generate a steady supply of unpredictable, unguessable, one-use encryption keys, Cryptocat needs a steady supply of high-quality random numbers.
PRNGs are a key component of cryptographic softwareįor the same reason that you don’t use the same password on more than one website, so that one cracked password doesn’t open up your whole online life, Cryptocat generates new keys every time you chat to someone. One of these flaws was found in the heart of Cryptocat’s PRNG (pseudo-random number generator). It turned out that the Cryptocat code had for some time contained a number of cryptographic flaws that made it measurably less secure than its users might reasonably have assumed. The software enjoyed a surge in popularity as a result, which made last week’s Fourth-of-July vulnerability announcement all the more worrying. We recently wrote about a security advisory from Cryptocat, an open-source web-based secure messaging project.Ĭryptocat’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.