Tobtu

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

No love for KeePass in that article? I recall all those password managers being broken by tobtu.com or various users on Hashcat forums. http://www.tobtu.com/lastpass.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-3055164… 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).

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/

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/a17bb1599463e0c079137d82… 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…

His slides to his talk have been posted. I'll like the video to the talk when it's up. https://tobtu.com/blackhat2022/

Relatedly, a recent post on SRP (the most commonly used PAKE) and how it's worse in all cases than PAKEs derived from SPEKE: https://tobtu.com/blog/2021/10/srp-is-now-deprecated/

> At least if you somewhat trust the reviewer we now know that it has no glaring problems and seems to be well designed. I believe OP was making fun of the review. Cryptocat was full of questionable choices (https://tobtu.com/decryptocat.php) as well as widely disputed security claims.

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?

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-…

This is one of the bugs found in CryptoCat. http://tobtu.com/decryptocat.php

Reading about the history of CryptoCat doesn't convince me that it was written by people who knew what they were doing. Look at the RSA key size chronology: 768, 512, 600, 1280, 1024, 1048, ... http://tobtu.com/decryptocat.php

Go read http://tobtu.com/decryptocat.php and earlier sources before deciding he's being extremist.

This is probably a good reason ppl stopped using it http://www.tobtu.com/lastpass.php Plus I wouldn't trust any browser plugin with passwords

http://tobtu.com/decryptocat.php https://blog.crypto.cat/2013/07/new-critical-vulnerability-in-cryptoca… https://news.ycombinator.com/item?id=5989707