oops! should have replied to RT. sorry about noise on list. a. -------- Original Message -------- Subject: Re: [openssl.org #1593] BN_nist_mod_384 gives wrong answers Date: Wed, 09 Apr 2008 14:51:17 +0200 From: Andy Polyakov <[EMAIL PROTECTED]> Reply-To: [email protected] To: [email protected] References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
>> Please verify http://cvs.openssl.org/chngview?cn=16985. A. > > Unfortunately this is still incorrect. Consider for example a = > 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000ffffffffffffffffffffffff000000000000000000000000000000000000000000000000000000000000000000000000. > Then BN_nist_mod_384 yields > 0xffffffffffffffff00000000000000000000000000000000000000000000000000000000000000000000000000000000. > But the correct value (e.g. obtained by BN_mod) is > 0xffffffffffffffff00000000000000000000000000000000000000000000000100000000ffffffffffffffff00000001. http://cvs.openssl.org/chngview?cn=17029 should do it. Note that this commit addresses BN_nist_mod_384 only. Other functions will eventually be fixed too. Presumably 64-bit implementation is also of interest... > I was not able to understand the treatment of the carry. They tried to "cheat" by simply accumulating carry bits and subtract pre-computed carry*modulus value. But carry alone does not qualify for if (intermediate_result >= modulus) for all inputs, therefore trouble. Now it's done "by the book," i.e. modulo reduction is dutifully performed after each operation. It's either that or full blown modulo division. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
