[cryptography] Fwd: [gsc] Fwd: OpenBSD IPSEC backdoor(s)

Peter Gutmann pgut001 at cs.auckland.ac.nz
Sat Dec 18 04:48:39 EST 2010


"James A. Donald" <jamesd at 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.



More information about the cryptography mailing list