DecryptoCat

TLDR: If you used group chat in Cryptocat from October 17th, 2011 to June 15th, 2013 assume your messages were compromised. DSA is probably broken in one-to-one chat over OTR. ECDSA is probably broken in group chat. You must update Cryptocat to at least 2.1.12 to be safe from known problems... As soon as it comes out. Here is the old post where I was less nice (it is a longer read with a little more detail).

A lot of the dates are misunderstood:
October 17th, 2011 Diffie-Hellman private keys were reduced to crackable.
May 7th, 2012 ECDH introduced and is broken with DecryptoCat.
April 19th, 2013 ECDH is no longer easy to break, but still crackable by governments and large companies.
June 3rd, 2013 I patched ECDH now private keys are uncrackable.
June 15th, 2013 FireFox approves first 2.x version of Cryptocat that is not using short ECDH private keys.
July 4th, 2013 s hits the f.

DecryptoCat v0.1 cracks the group chat ECDH public keys generated by Cryptocat versions 1.1.147 through 2.0.41. Cryptocat version 2.0.42 was released Feb 19, 2013 which increased the key space from 2^54.15 to 2^106.3. Decryptocat takes advantage of a meet-in-the-middle attack called baby-step giant-step you can effectively square root the key space. So 2^54.15 turns into 2^27.08 and 2^106.3 to 2^53.15. For Cryptocat versions before 2.0.42, doing a split of 2*10^9 and 10^7 it takes about a day to calculate data needed to crack any key in few minutes. This only requires tens of gigabytes to store. Doing a 2*10^8 and 10^8 split it will take an hour to generate and half an hour to crack any private key with that data. I suggest doing a 2*10^8 and 10^8 split unless you actually have a bunch of captured conversations or you want to test if the people you are talking to have upgraded. If there is a next version I'll probably "steal" some code from curve25519-donna and add support for GPUs.

Yes this is scary but I believe everything is/was over https. So this just means that it was host based security. Meaning we have to trust that Cryptocat didn't store/transfer encrypted messages or leak their SSL private key. They have generated a new private key, to prevent someone from breaking into their server and stealing it. Which might let them decrypt old captured messages.

I found three bugs small private keys for group chat, bad random generation, and improper use of random (this is in a library they use called BigInt). When I looked at their commit history I found that the small private key bug was worse because the key was a decimal string masquerading as an array of 17, 15 bit integers. The masquerading bug was added May 7th, 2012 when they switched to ECDH and fixed April 19th, 2013. This caused keys to be super easy to crack (2^27.1 time and memory). The bug I found and fixed on June 3rd, 2013 was the private key only being 10^32 instead of 256^32. A private key that is 10^32 can be broken with 10^16 (2^53.2) time and memory. Which is roughly 1500 computer-years and 40 petabytes. So doable but hard.

The bad random generation was a slight bias towards zero when they converted good random data into ASCII characters 0 through 9. Well I didn't really look at the good random data part but let's assume it's good. Zero had a 26/251 chance and all the others had a 25/251 chance. Some people with limited math background might think it is odd to drop random data not in a range, but this is actually correct. Such as in this case dropping 6 out of 256 values. The probability of a loop that goes through more than 24 values is 1 in 2^129.1 ((6 / 250) ^ 24). The heat death of the Universe will happen before then. Crazy as it might seem dropping 56 out 256 values to get two decimal digits per byte is actually faster. The expected amount of decimal digits per byte is 1.5625 (2 * (1 - 56 / 256)) vs 0.9766 (1 * (1 - 6 / 256)). Which is exactly 60% faster. Anyways this really doesn't not hurt security that much... I think. Oops forgot to mention, there is a timing attack possibility here, but if it is a good PRNG then knowing any part of its output will not let you determine any other part of its output.

The bug in the BigInt library affects DSA in OTR and ECDSA in group chat. Every 15th bit in the generated random numbers are zero. This bug is not specific to Cryptocat. They just happened to use a library with a bug. Good news is DSA in OTR was patched on June 15th, 2013 and ECDSA in group chat was patched on July 4th, 2013. As of July 7th, 2013 the official BigInt library is still not patched. I sent them him an email on July 4th. Now the bad news, the variable "k" in DSA was generated like this. And if you know how to Google like I do you'll find this. If any bit is predicable in "k" you can break DSA. It might take a few signatures, but it should be possible. You should update Cryptocat to at least 2.1.6 for one-to-one messages. I believe ECDSA has the same problem with "k" as DSA has. So ECDSA is also broken, but there has not been a release yet. I'm not that familiar with DSA and ECDSA but this is just from what I gather from searching.

Cryptocat tried PBKDF2, RSA, Diffie-Hellman, and ECC and managed to mess them all up because they used iterations or key sizes less than the minimums.
Here's the short version with basic changes to the hardness to crack group chat private keys:

Here's the long version that describes each change: