Personal site of a security researcher who breaks cryptography and password software, including Cryptocat, LastPass and PRNGs.
HN commenters cite it for cracking password managers and exposing Cryptocat's flawed random number generation and key weaknesses.
First, this is a great article showing the bias in Cryptocat's very awkward PRNG code.
However, the off-by-one bias was actually the least of the problems with Cryptocat's random numbers...
From reading Steve's write-up, the problem was that their keys were ridiculous undersized, because they called their own function wrong:
May 7, 2012 (switched from DH to ECC):
myPrivateKey = Cryptocat.randomString(32, 0, 0, 1);
April 19, 2013:
rand = Cryptocat.randomString(32, 0, 0, 1);
myPrivateKey = BigInt.str2bigInt(rand, 10);
June 3, 2013:
rand = Cryptocat.randomString(64, 0, 0, 1, 0);
myPrivateKey = BigInt.str2bigInt(rand, 16);
> The bug that lasted 347 days was the confusion between a string and an array of integers. 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. Each character was considered an element in the array. So each of those "15 bit integers" were only the values 0 to 9 (3.32 bits). Also the least significant 3 bits are zeroed giving you a key space of 2*10^16 (2^54.15). -- http://tobtu.com/decryptocat.php
See for yourself here: https://github.com/cryptocat/cryptocat/commit/a17bb1599463e0c079137d8200eb32002ac1afc7#src-core-js-lib-multiparty-js-P4
Even now looking at this code, for me it just doesn't pass the 'WTFs per minute' test... It still looks fucking wrong to me... Cryptocat.randomString(64, 0, 0, 1, 0) returns a 64 character string of…
LOL. http://tobtu.com/decryptocat.php
On a serious matter, javascript (eg all browsers) absolutely needs to change to make the web more trustworthy. I agree with some of the Matasano points[0], but these are the minimum, exhaustively complete changes that would improve browser security:
i. js that can be cryptographically signed and verified, a trust model and a browser security policy to enforce it.
Think ascii armored GPG signature as a comment for the code it encloses.
ii. js native extensions: able to talk to native code that was previously installed
iii. js objects that can be made immutable (can't change them in any way)
iv. js objects that can be made un-protypable (can't copy or "subclass" them)
v. js properties that can be made read-only
vi. js properties that can be made private (only the object itself can use them)
With folks pushing to make this happen across all browsers, javascript theft of bank passwords and credit card numbers would be much harder. Crypto stuff like the Stanford library would benefit.
References:
0. http://www.matasano.com/articles/javascript-cryptography/
1. https://crypto.stanford.edu/sjcl/
I am the original author of the software you refer to. Before its complete rewrite (released two months ago), Cryptocat was based on a codebase that I wrote starting in my early undergrad and that was notorious for containing many high-severity vulnerabilities. The most important was "Decryptocat", documented by Steve Thomas [0] but we also had:
* AES-CTR counter-reuse (2012)
* Biased Fortuna CSPRNG implementation [1] (2013)
To be sure, Cryptocat's substandard reputation was well-deserved; but all the same, I think that every vulnerability that did pop up was addressed responsibly and with full disclosure.
Since then, there has been a major rewrite that I am conversely quite happy with.
[0] https://tobtu.com/decryptocat.php
[1] https://nakedsecurity.sophos.com/2013/07/09/anatomy-of-a-pseudorandom-number-generator-visualising-cryptocats-buggy-prng/
One of the problems I face when somebody comes along and tells me that they're now on Telegram, Cryptocat, Wire, or whathaveyou is that I might recall an issue but there doesn't seem to be a good up-to-date overview that answers the questions (1) should I trust these people (how bad was it; was it in their code or a dependency?) and (2) is it known to be far less secure than it advertises? (still?)
I recall e.g. that Moxie reviewed Telegram's security, found that none of it made any sense and that its authors didn't know what they were doing. https://tobtu.com/decryptocat.php looks like the cryptocat analogue of that. Have the two projects improved somehow? Have some people joined or others left?
Could you please also provide links for the claim that CryptoCat and Telegram are being used by governments to hunt down activists?
In my experience, most malware creators are pretty terrible. Even in 2015 it's common for malware to communicate with C&C servers that have classic SQL injection vulnerabilities.
More specifically on the topic of ransomware, have a look at this gem [1], which uses RSA, but the key is 128 ASCII digits. Very similar to the cryptocat disaster. [2]
[1] http://blog.cassidiancybersecurity.com/post/2014/02/Bitcrypt-broken
[2] http://tobtu.com/decryptocat.php
That's a pretty amazing hyperbole from kaepora (twitter description of incident vs actual e-mail response from Apple). And later, Apple accepted the fix: https://github.com/cryptocat/cryptocat/issues/542#issuecomment-30551640
Kaepora is so full of himself, I'm not sure how anyone takes what he says or the apps he writes seriously. Glad that people are putting stock in more consistent developers these days (http://tobtu.com/decryptocat.php).