>>> 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.
And so would http://cvs.openssl.org/chngview?cn=17081. Please test and confirm. It's probably easier to download the http://cvs.openssl.org/getfile/openssl/crypto/bn/bn_nist.c?v=1.20 as file instead of patching... >> 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. It was shown by Takanori Yanagisawa that "cheating" is perfectly possible, if carry/borrow from final bn_[sub|add]_words is treated appropriately. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
