For what it's worth, Steve Thomas's vulnerability was not the most important in that code. I think Steve Thomas (fair warning: a friend) might dispute the "full disclosure" comment you made, as well.
Thomas, aren't you trying to make security-related products and infosec in general too "reputation-based"? Do you really think that some bad code or design or lack of theoretical background during early career should be an "out-of-profession" sentence for lifetime? Hadn't you ever made such mistakes yourself?
Yeah, whilst I generally agree with the sentiment that nobody should roll their own crypto nor use something you randomly find on the net, if nobodies creating these things, you will have no future professionals.
Good for his consulting rate, no doubt, but probably not good for society.
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.
