Fix a bug in ecp_nistp224.c.
authorDavid Benjamin <davidben@google.com>
Wed, 28 Mar 2018 16:21:45 +0000 (12:21 -0400)
committerDavid Benjamin <davidben@google.com>
Tue, 3 Apr 2018 20:09:20 +0000 (16:09 -0400)
commitdc55e4f70f401c5869410d6a0c068c18c3fd53ec
tree194f3026ac5e25a6bcfcd0a2a812ab31d021254d
parentb2b4dfcca6cf2230107a711f7af1cd8ee3f74229
Fix a bug in ecp_nistp224.c.

felem_neg does not produce an output within the tight bounds suitable
for felem_contract. This affects build configurations which set
enable-ec_nistp_64_gcc_128.

point_double and point_add, in the non-z*_is_zero cases, tolerate and
fix up the wider bounds, so this only affects point_add calls where the
other point is infinity. Thus it only affects the final addition in
arbitrary-point multiplication, giving the wrong y-coordinate. This is a
no-op for ECDH and ECDSA, which only use the x-coordinate of
arbitrary-point operations.

Note: ecp_nistp521.c has the same issue in that the documented
preconditions are violated by the test case. I have not addressed this
in this PR. ecp_nistp521.c does not immediately produce the wrong
answer; felem_contract there appears to be a bit more tolerant than its
documented preconditions. However, I haven't checked the point_add
property above holds. ecp_nistp521.c should either get this same fix, to
be conservative, or have the bounds analysis and comments reworked for
the wider bounds.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5779)
crypto/ec/ecp_nistp224.c
test/ectest.c