For a project I'm working on, I need to implement ECDSA over the NIST P-384 curve (AKA secp384r1). For what it's worth, the choice of curve is beyond my control in this particular case.
While I already have a working implementation, and this is (so far) just a low-stakes pet project, I was wondering how I could take care of this in the most effective way, especially for the signing part.
Rough wish list:
- I want to make a serious attempt at defending against side channel & timing leaks.
- Since I only care about the P-384 curve and ECDSA, I'd like a codebase with a relatively small footprint (also because I'll need to supply bindings for non-C code). P384-specific optimisations are certainly welcome, though.
- I would like the option to use RFC 6979-style deterministic $k$ values (or some other deterministic nonce derivation scheme).
- The scheme I'm implementing also requires support for point compression.
I can handle 3 and 4 myself if the codebase lends itself to modification.
After some looking around, here's what I found:
- OpenSSL (and its forks like LibreSSL/BoringSSL/...): the obvious choice, but bulky, and I'm also not a fan of OpenSSL's baroque calling conventions
- Android includes a cute minimalist P-256 implementation. I'm not sure how secure that specific one is, but it's a good example of the kind of thing I'm looking for (replacing P-256 with P-384).
- Thomas Pornin's BearSSL has a portable-yet-constant-time (to the extent that that's possible) P-384 implementation, and looks simple enough to strip out the functionality that I don't need. It doesn't appear to use any curve-specific optimisations, but does already use deterministic $k$ values out of the box.
Obviously I'd prefer to avoid having to roll my own implementation. Right now, I'm tempted to go down the "stripping down BearSSL" route, but I wanted to ask if there was anything more plug-and-play, or if there were any concerns I missed. Thanks!
