Of course, I was only referring to vulnerabilities I could verify are real.
Steve was paid two separate bug bounties and invited to a Cryptocat hackathon in NYC. I also consider him a friend and never heard a complaint from him regarding the project's disclosure policies.
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 210^16 (2^54.15).*
When they fixed that bug the commit message was: "Fix private key format to match curve25518-donna. THIS BREAKS COMPATIBILITY WITH PREVIOUS CRYPTOCAT VERSIONS." Even though this does not break compatibility at all. I don't know if they knew what they fixed and just wanted to slide this under the radar or they legitimately believe that. Both are scary one is violating their principles "Cryptocat is developed under a principle of radical transparency" and the other is just incompetence. There is a blog post by them saying this is inaccurate. Apparently they have too many serious bugs to keep straight. That they don't know which one breaks compatibility. The other error in the change log for version 2.0.42 is a bug where the counter in AES-CTR is reused. This means the first 32 bytes of your messages are easy to decipher with no effort at all. Which breaks compatibility, but everywhere they mention compatibility they say key generation.
Steve was paid two separate bug bounties and invited to a Cryptocat hackathon in NYC. I also consider him a friend and never heard a complaint from him regarding the project's disclosure policies.