-
Notifications
You must be signed in to change notification settings - Fork 547
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace BigInt based elliptic curve library #4027
Comments
We should consider compile time configuration of which curves get instantiated (as pointed out here). Much like the compile-time configuration of having "kyber" and/or "kyber_90s", for instance. Adding one build module per curve should do the trick, and probably provides the best affordance for users. On the other hand, it produces quite a bit of boilerplate due to subdirectories, Alternatively, I could see this as a dedicated compile-time switch: Like:
and then simply |
The [*] I mean right now ECDSA etc still use BigInt, even after both #3979 and #4042 land. There are several more steps here until the whole thing hangs together. But in the end state, we'll have fast ECC for specific curves, plus fallback code for weird curves, application curves, etc. If you disable the fast curve, it doesn't disable the curve, just disables it going fast. That said there may be environments where the code size becomes an issue. I tried out a module per curve and it was not so bad. There are likely to not be more than ~5 new curves added here over time so I don't think it's an issue in an ongoing way. In the end we could consider also having a way of disabling the slowpath BigInt stuff, which would benefit environments that are using just P-256 or something. |
Nice! I saw that you split the curve into compile-time modules. Indeed the boilerplate isn't so bad. Also provides a nice place to keep curve-specific special cases. 👍 I added a few minor suggestions, in which the |
Botan 3.5.0
In this release pcurves is really just used for hash to curve
EC_Scalar
andEC_AffinePoint
types and implement algorithms using them Add EC_Scalar and EC_AffinePoint types #4042BigInt
, egmod_sub
,ct_reduce_below
, many more.Support for providing parameterized curves, where we eg compute Montgomery params at runtime. This is required not just for user provided/application specific curves but also I don't think it's worthwhile to provide the fully parameterized/hardcoded support for obscure curves like secp160r1.In the short term, application curves, secp160r1, etc fall back to the currently used BigInt codeBotan 3.6.0
In this release, we tie together
EC_Scalar
/EC_AffinePoint
to pcurves so that everything goes fast 🚀EC_Scalar
/EC_AffinePoint
and pcurvesEC_Scalar
andEC_AffinePoint
instead ofBigInt
/EC_Point
Botan 3.6.0 or later. Nice optimizations / cleanups but not critical
The text was updated successfully, but these errors were encountered: