Quote from: gmaxwell on January 31, 2015, 12:19:17 PM

Quote from: colinistheman on January 31, 2015, 04:16:07 AM

If the squaring bug referenced is not a concern for Bitcoin implementations, then why was a new library required? It sounds like the bug affects things other than bitcoin, but bitcoin is safe from it.

Independent of any particular bugs, OpenSSL is maintained in a way which is unsafe for consensus ( http://sourceforge.net/p/bitcoin/mailman/message/33221963/ ). OpenSSL is also on the order of >>300k lines of messy, difficult to review code (even for someone who is familiar with the algorithms in use), which-- for Bitcoin's narrow use-- can be replaced with <10k lines and get a 6-8x speed-up at the same time (and 21% of that 10k is testing code; compared to 0.9% in OpenSSL-- another reason for the reason to believe, coupled with the basically 100% branch coverage of the libsecp256k1 tests). OpenSSL also has huge timing/cache side-channel leaks (http://eprint.iacr.org/2014/161.pdf), and can't be used with best-practices derandomized DSA without moving part the low level cryptographic code into your own application. The point about the BN squaring bug wasn't that that particular issue was a problem for Bitcoin (though it narrowly dodged being a trivial attack to fork the network), but that the tests for libsecp256k1 found it without even trying to test OpenSSL is some level of evidence that the library may be practically better tested already.

I see. I agree it's better to avoid depending on outside libraries because those could be compromised in the future too. If everything is done "in-house" then it's safer and simpler to review (in this case). I feel pretty much like it was the right decision. It's just a matter of testing and really making sure it's got no mathematical bugs like OpenSSL's had, which Snowden said could take years to fully verify for any new crypto tools.

Thanks for the explanations. I can see lots of thought went into it.