Hello, I have uncovered what I believe to be a bug in b_print.c.
The problem turned up when I tried to convert to openssh, which is dependent upon openssl. The ssh-keyscan program returned garbage SSH1 keys when it was executed from an IRIX platform. When the same versions of the code were built and executed on a Solaris or Linux platform, it worked correctly. Investigation led me to the conclusion that b_print.c does not properly set HAVE_LONG_LONG and HAVE_LONG_DOUBLE. The setting of HAVE_LONG_LONG is dependent upon the setting of BN_LLONG, but it is explicitely noted that this must be undefined for 64-bit builds. I have no idea what should set HAVE_LONG_DOUBLE which is only referenced in b_print.c and never set. The bug causes _dopr in b_print.c to handle all integer values as 32 bit quantities. I believe that this would cause all 64-bit builds to produce an incorrect output. I have not tested this on Solaris, beyond configuring a solaris64-sparcv9-cc build, which sets the same values. I don't have access to a 64 bit Linux platform. The symptoms of the problem appear with an SSH1 public key being reported with a large number of zeroes and incorrect digits for the remaining key positions - with the exception of the leading few digits. The groups of zeroes and gibberish are in blocks of 19 digits, which corresponds to the 19 digit segments printed in bn_print.c via BIO_snprintf, which works through _dopr. The problem also exists in 0.9.7e. I have not tried 0.9.8a. I can work around the problem by hacking b_print.c as follows: cerebus[77]$ diff -c crypto/bio/b_print.c* *** crypto/bio/b_print.c Mon Apr 3 20:44:10 2006 --- crypto/bio/b_print.c.dist Thu May 12 17:13:40 2005 *************** *** 85,99 **** # endif #endif - - /* CSUR Hack for SGI which has long long and long double */ - - #ifdef sgi - #define HAVE_LONG_LONG 1 - #define HAVE_LONG_DOUBLE 1 - #endif - - /***************************************************************************/ /* --- 85,90 ---- cerebus[78]$ Note that this won't fix other 64-bit builds, but Solaris and Linux will happily do a 32-bit build. The problem manifests itself by incorrectly reporting an openssh SSH1 key as: /u/openssh.432/bin/ssh-keyscan mercury # mercury SSH-1.99-3.2.9.1 SSH Secure Shell (Academic) mercury 1024 37 1317200000000022121745750000000002115977005000000000163920906400 00000002221485369000000000042713727700000000017684217590000000003132720403000000 00032230190070000000002443045337000000000313076903300000000028828656600000000002 87614735400000000008113440410000000001922015885000000000346147632400000000015904 92149 The correct key is: /u/openssh.432/bin/ssh-keyscan mercury # mercury SSH-1.99-3.2.9.1 SSH Secure Shell (Academic) mercury 1024 37 1317220721954161339338079625192261308333869934561131745380567283 03360713941396793843768397178847871787877165363741310710302311738802013459678062 69010594606070039384835367496153615384051791296884193853634572250670044261352458 16112911489361148409741395614095992582768665229166340220826641610097970147725114 72629 As requested, here is the test log from 'make report': OpenSSL self-test report: OpenSSL version: 0.9.7i Last change: Wrapped the definition of EVP_MAX_MD_SIZE in a #ifdef O... Options: threads shared no-krb5 OS (uname): IRIX cerebus 6.5 07010238 IP32 OS (config): mips3-sgi-irix Target (default): irix-mips3-gcc Target: irix-mips3-cc Compiler: MIPSpro Compilers: Version 7.4 Test passed. Note that the problem exists with both the MIPSpro compiler and with GCC 3.4.5. I have also tried downloading pre-built binaries from several sources and they also exhibit this symptom. Here's hoping you can provide a more permanent cure, -- Robert ________________________________________________________________________ Robert I. Cowles e-mail: [EMAIL PROTECTED] System Administrator Phone: Office (306) 585-4974 Department of Computer Science Fax (306) 585-4741 University of Regina Office: CL124.2 3737 Wascana Parkway Regina, Saskatchewan Canada S4S 0A2 "System Administrators like to think of their lives as a series of challenges, rather than one 'dang' thing after another!" ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
