>>> Note in particular that, IIUC, ecp_nistz256_neg will never get an >>> unreduced input when applied to the the based point multiples, because >>> those are already fully reduced. But, when it is used in >>> ecp_nistz256_windowed_mul, it isn't clear whether or how the input Y >>> coordinate is fully reduced mod P before passed to ecp_nistz256_neg. >> >> Is it correctly understood that concern is that input to >> ecp_nistz256_windowed_mul, which in turn can be *user* input, would be >> not fully reduced? > > Let's assume, for the purpose of this discussion, that the coordinates > of the user input point `p` is already reduced, or that we will reject > it or reduce it. > > Given that input point, we calculate multiples 1*p, 2*p, ... 16*p > using ecp_nistz256_point_double and ecp_nistz256_point_add. Let's look > at how ecp_nistz256_point_double and ecp_nistz256_point_add calculates > the Y coordinate: > > double: > ... > ecp_nistz256_mul_mont(S, S, M); > ecp_nistz256_sub(res_y, S, res_y); > > add: > ... > ecp_nistz256_mul_mont(res_y, R, res_y); > ecp_nistz256_sub(res_y, res_y, S2); > memcpy(r->Y, res_y, sizeof(res_y)); > > Now, I was told by one of the authors of the original code that all > the ecp_nistz256_* field operations return a result in the range [0, > 2**256), not [0, P). This can be seen in the reduction code, e.g. in > ecp_nistz256_sub. It uses the result of "sbb \$0, $t4" to determine if > the result is larger than 2**256 - 1. If the result is larger than > 2**256 - 1 then it subtracts P. Otherwise, it returns the result. But, > in the case where it doesn't subtract P, the result might be in the > range [P, 2**256); i.e. not fully reduced.
No, it subtraction subroutine uses *borrow* to determine if modulus is to be added. I.e. (a >= b) ? (a - b) : (P - (b - a)). If both a and b are less than P, then result is less than P. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev