# Minimal, secure and reasonably efficient P384 implementations

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:

1. I want to make a serious attempt at defending against side channel & timing leaks.
2. 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.
3. I would like the option to use RFC 6979-style deterministic $$k$$ values (or some other deterministic nonce derivation scheme).
4. 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!