Can it be shown that this is a problem at a TLS level? I'd hate to make the proposed change just to discover that it breaks interoperability with other TLS clients and servers.
Unless you can show that this incompatibility (which is very easy to deal with, BTW) creates an error, I can't really see that this should be changed. [[EMAIL PROTECTED] - Mon Nov 4 10:17:04 2002]: > Hi, > > It seems that DH_compute_key is slightly incompatable with PKCS #3, if > the > derived secret z is too small. In particular, section 8.3 of PKCS #3 > "Integer-to-octet-string conversion", specifies that that output of > the > operation should be exactly k bytes long (where k is the number of > bytes in > the prime p). This seems to be regardless of how big the derived > secret > actually is (for example if z ends up being 5, and p is ~ 2^512, the > output > should still be 64 bytes long, with 63 of the leading bytes being 0). > OpenSSL does not do it this way: it coverts the shared secret integer > into > a byte string of a length equivalent to the number of significant > bytes in > the shared integer. > > I initially noticed this while reading the dh manpage, and confirmed > it by > reading dh_key.c as included in openssl-0.9.6g > > I believe this can be fixed by memset'ing the key parameter to all 0s > before doing any operations, then returning DH_size(dh) regardless of > the > size of the resulting integer. > > Regards, > Jack > -- Richard Levitte ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
