"James A. Donald" <jam...@echeque.com> writes: >> That took all of ten seconds to get. Result: A completely FIPS 186-compliant >> digsig implementation that leaks the private key. > >And one that would take someone checking the code about an hour or so to >detect.
And on what do you base that apart from "arbitrary assertion"? It's a fully correct implementation of FIPS 186, how would anyone know that there's a problem? This bug was present in a number of implementations for many years - and we're talking more than a decade here - before being fixed, and even then it was only because someone published a paper on it, people specifically looked in exactly the right location in the code, and found that many implementations were affected. Unless you know an awful lot about undocumented properties of DSA implementations and know exactly where to look in the code for it, you'll never find this even now. To illustrate how hard this is without 20:20 hindsight, and to put your money where your mouth is, download a copy of cryptlib 3.3.3, say from http://mirror.leaseweb.com/gentoo-x86-portage/metadata/cache/dev-libs/cryptlib-3.3.3, and find the problem in the ECDSA code, *without* looking at any newer version for comparison (just for reference, the ECDSA code was completely disabled in 3.3.3 because it was still a work in progress at the time of release, it was never shipped in a dysfunctional state. This should be really easy to find because the code doesn't work at all, say 15 minutes if you think the DSA one would take an hour to find?). Other crypto library authors are welcome to chime in here with see-if-you-can-find-it bugs. For OpenSSL, take a release around 0.9.5 and find the problem in the bignum code... well, one of them anyway :-). Peter. _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
