Bridge pcurves into the main elliptic curve arithmetic #4143
Conversation
|
Without a full picture, yet: I think it would make sense to allow disabling the BN-based ECC implementation at compile time. |
In principle yes I agree. However it's greatly complicated by the fact that we have large swaths of public API which expose various BigInt based ec functionality ( |
|
To be able to get an idea of the big picture, I extended the diagram I started at some point. Feedback appreciated. :) Edit: updated with the added structures from #4203. Note that excalidraw isn't a shared collaboration space. To publish any modifications, one has to re-create a new snapshot via "save as... > shareable link" |
randombit
force-pushed
the
jack/bridge-pcurves-and-ec
branch
4 times, most recently
from
45b7e82
to
f5c09c6
Compare
|
Comparing |
randombit
force-pushed
the
jack/bridge-pcurves-and-ec
branch
5 times, most recently
from
51c9ee0
to
ace1146
Compare
randombit
force-pushed
the
jack/bridge-pcurves-and-ec
branch
2 times, most recently
from
40f0073
to
a6a4dd2
Compare
randombit
force-pushed
the
jack/bridge-pcurves-and-ec
branch
from
a6a4dd2
to
6a5a364
Compare
|
@reneme Ready for another look |
There was a problem hiding this comment.
Some minor documentation inconsistencies, a suggestion for more explicit memory management and some C++ Klugscheißerei.
| const size_t fe_bytes = this->field_element_bytes(); | ||
| BOTAN_ARG_CHECK(bytes.size() == fe_bytes, "Invalid output size"); | ||
| copy_mem(bytes, m_x_bytes); |
There was a problem hiding this comment.
Nit: copy_mem does that size check internally, same in some methods that follow. Obviously, with a less clear error message.
Please bear with me if I did point that out before and you decided against it. 😓
There was a problem hiding this comment.
Intentional for the error message - this function is (at least through several layers) reachable by user code, and while they could probably figure it out just from a generic error message it seemed nicer to be a bit more explicit. TBH I think of copy_mems check as more of a fallback for cases we forget.
randombit
force-pushed
the
jack/bridge-pcurves-and-ec
branch
3 times, most recently
from
fcdeba9
to
f76300f
Compare
Now any uses of the standard (public) interfaces for elliptic curve arithmetic automatically use the faster implementation, whenever a supported group is used. Co-authored-by: René Meusel <github@renemeusel.de>
randombit
force-pushed
the
jack/bridge-pcurves-and-ec
branch
from
f76300f
to
1fca425
Compare
This results in roughly a 2x-3x speedup for all elliptic curve algorithms, when using a supported curve.