tree 76394e8848cb1d9e43724faf07281aca12b89b06
parent 73e0401e3d434b17c6799d6ce2dcd4de76e885b1
author David Benjamin <davidben@google.com> 1587581480 -0400
committer CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> 1588697718 +0000

Introduce an EC_AFFINE abstraction.

PMBTokens ends up converting the same point to affine coordinates
repeatedly. Additionally, it converts many affine coordinates at once,
which we can batch. Introduce an EC_AFFINE type to store affine points
and move the inversion to the Jacobian -> affine conversion.

This does mean we lose the (negligible) Montgomery reduction
optimization in EC_GFp_mont. point_get_affine_coordinates no longer
breaks the EC_FELEM abstraction around Montgomery form.

Unfortunately, this complicates hardening of the callers not checking
return values because EC_AFFINE cannot represent the point at infinity
and, due to OpenSSL's API limitations, groups may not have generators
available and the generator is not affine at the type level. (EC_AFFINE
cannot represent the point at infinity.) Thus this CL:

- Tidies up some duplicate code in setting up the generator and ensures
  it always has Z = 1.
- ec_point_set_affine_coordinates hardens against unused results if the
  generator is configured. But this is ultimately an internal function.
- Retains the hardening on the public APIs by adding calls to
  ec_set_to_safe_point in two places.

This CL does not apply the optimization to Trust Tokens, only introduces
the EC_AFFINE abstraction. It additionally continues to store EC_POINTs
(used in ECDH and ECDSA) in Jacobian form. See
https://crbug.com/boringssl/326#c4 for a discussion on why this is
tricky. Those protocols are hopefully simple enough that they don't need
complexity around inversions.

Having an EC_AFFINE type will also be useful for computing custom tables
for Trust Token public keys, which gives a nice speedup.

Bug: 326
Change-Id: I11b010a33f36a15bac9939351df5205bd35cc665
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41084
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>