Enforce that EC Parameters correspond to a builtin curve

EC parameters are very general. While there are some minimal sanity checks,
for the parameters due to DoS risks found in the last decade, the elliptic
curve code is poorly written and a target rich environment for NULL
dereferences, busy loops, expensive computations and whatever other
nastiness you can think of. It is not too hard to come up with parameters
that reach very ugly code. While we have removed for the worst of it (the
"fast" nist code and GF2m come to mind), the code very much resembles the
Augean Stables.

Unfortunately, curve parameters are still in use - even mandatory in some
contexts - for example in machine-readable travel documents signed by ICAO
country signing certification authorities (see ICAO Doc 9303).

To avoid many of these DoS vectors, start enforcing that we know what the
curve parameters are about, namely that they correspond to a builtin curve.
This way we know that the parameters are at least as good as the standards
we implement and checking this is cheap:

Translate curve parameters into the ad hoc representation in the builtin
curve code and check there's a match. That's very cheap since most curves
are distinguished by cofactor and parameter length and we need to use an
actual parameter comparison for at most half a dozen curves, usually only
one or two.

ok jsing

0 files changed, 0 insertions, 0 deletions