Say order is m bits. Then k+order is either m or m+1 bits. The condition fixes it at m+1. (You're right that for most standardized curves the branch is either negligibly taken or overwhelmingly taken, depending on what the order looks like.)
BBB On Apr 23, 2014 12:52 PM, "Dmitry Olshansky" <[email protected]> wrote: > 23-Apr-2014 20:48, Billy Brumley пишет: > >> Please read CVE-2011-1945. You need to propagate the fix in >> gost2001_do_sign. If you're unsure, check the comments in >> crypto/ecdsa/ecs_ossl.c. >> >> I see the place you refer to. What I can't quite get in this piece is > adding `order` 2 times. Shouldn't the first BN_add get us where we want > (that is a number as wide as `order`)? > > /* We do not want timing information to leak the length of k, > * so we compute G*k using an equivalent scalar of fixed > * bit-length. */ > > if (!BN_add(k, k, order)) goto err; //<---here I would expect k > to be > order afterwards > if (BN_num_bits(k) <= BN_num_bits(order)) // then this is > trivially false? > if (!BN_add(k, k, order)) goto err; //and this should not > even be reached? > ... > > BBB >> >> >> > > -- > Dmitry Olshansky > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [email protected] > Automated List Manager [email protected] >
