So I took a look, and here's a few problems that I found in CryptoCat's elliptic curve crypto library :ġ/ Curve25519.ecdsaGenPrivateKey (line 187) generates private keys that aren't in the correct range. CryptoCat doesn't do any of these, which made me very doubtful of its crypto. I've seen a Javascript implementation of AES that leaks secret keys because it forgets to check that some input is indeed an array of bytes. Failure to do any of these will result in serious bugs. The only ways I know to catch these bugs are: writing more tests, using pseudo typing system provided by Javascript compilers such as Google Closure, and using a single data type such as Uint8Array for all inputs and outputs. The fact that Javascript rarely complains about typing or out-of-bound access issues makes it both hard and interesting to write secure crypto code in this language. Last but not least although I like reading crypto code theirs is so clumsy that I gave up after a few minutes.
#CRYPTOCAT NOT WORKING VERIFICATION#
They mix Curve25519 with P-256, e.g., they call a function Curve25519.ecdsaVerify, but it actually implements (insecurely) ECDSA's signature verification over P-256. They have, let me count, exactly 4 tests for the whole program. It seems that the CryptoCat team just throws together things until it works then move on. A copy of this blog post has been sent to CryptoCat.įirst off, CryptoCat's engineering practices look bad to me.
Note that I just read the code and take notes, but haven't actually verified if the bugs work or their impacts. Hopefully somebody would pick up what I found, and do something useful with them. I thought I'd share my notes, since I have no plan in continuing the audit.
That reminded me of a quick audit of the chat software that I did several weeks ago. A few days ago I saw CryptoCat was featured on the New York Times.
0 kommentar(er)
