So... RFC6979, which specifies derandomized nonces for ECDSA (essentially computing them deterministically from the message and the private key).

It's a good idea, and a success: widely deployed, and it probably actually prevented real-world security problems.

But... it's slow.

Conceptually, it's defining a hash from (message, key) to (nonce).

In more detail, it's instantiating an HMAC-based PRNG, seeding it with message/key, and extracting trial nonces from it. One nonce costs *22* invocations of the SHA256 compression function!

It's easy to think of hashes as "fast things", and the rest of the work involved in creating a signature (which needs elliptic curve arithmetic) as "slow things"... making it easy to forget to look at actual numbers.

With some in-progress improvements (safegcd modular inverses, signed-digit multi-comb multiplication) in libsecp256k1 included, an ECDSA signature takes 32.3 µs on my Zen+ CPU. 4.9 µs of that is spent in the RFC6979 nonce computation.

This isn't an entirely fair comparison. The SHA256 implementation is relatively naive pure C code, while other pieces of code have undergone extensive optimization (including a small bit of x86_64 assembly). Much faster SHA256 code exists, especially on hardware with SHA-NI.

But once you include the possibility of optional hardware support, lots of improvements are possible for all code (e.g. none of it currently uses SSE4/AVX2 at all). So I think it still gives some indication of how wasteful RFC6979 is - computing a nonce should be trivial.

So eh... why is there is no standardized generic solution that e.g. computes the nonce by just hashing key and msg (and possibly iterating if out of range)?

This is pretty much what is done in more modern "all in one" specifications like Ed25519.

So, I love that RFC6979 helped us get rid of the notion of needing high-quality randomness at signing time for ECDSA, but from a performance perspective the specific choices are a bit disappointing.

</rant>