This commit fixes a theoretical bug in the base point multiplier model. The

model does multiplication using the double-and-add algorithm. When adding two
points P and Q on curves P-256 and P-384, four special cases must be
considered. One of them is P = Q, in that situation the explicit addition
formulae don't work and either 2*P or 2*Q must be returned from the addition
routine. In this model Q is always the base point G, so when P = G, then 2*G
must be returned. Since G is fixed, this model stores precomputed point H = 2*G
and returns it when adding G+G for true constant-time operation. The problem is
that the currently stored coordinates of the point H are wrong. I think I used
the doubling routine (which returns in projective Jacobian coordinates) to
calculate H = 2*G, but then screwed up and forgot to convert it to affine
coordinates before storing x and y.

During multiplication the bits of k are scanned left-to-right, so doubling is
done before addition. This way the only situation when both inputs to the
addition routine are equal to G is when after doubling the result is G. This in
its turn is only possible when k = n + 2 (where n is the order of the base
point G). ECDSA requires integer k to be [1, n-1], so the current wrong
coordinates should never be used in practice. I'm not aware of any attacks
based on this bug, but I feel that it must be fixed, moreover the fix is
straightforward and only involves changing two lines of code used to initialize
arrays. One of the side effects is that the model has a code path that will
never be used under normal operation. This code path can be verified by first
multiplying by k = 2 (special handling for P = G not triggered), then
multiplying by k = n+2 (special handling for P = G triggered). Both
multiplications should produce the same output. In the former case the output
will be calculated on-the-fly, in the latter case the pre-computed coordinates
of H will be used.

0 files changed, 0 insertions, 0 deletions