Repository navigation
Allow creating hedged ECDSA signatures? #430
Description
Similarly to #424, we may want to allow generating hedged ECDSA signatures, as per draft-irtf-cfrg-det-sigs-with-noise.
Unlike in EdDSA, there should be essentially no observable difference to doing so, since ECDSA signatures are already randomized today.
Activity
ChALkeR commentedon Mar 17, 2026
Per nodejs/node#62252 (comment), implementations using OpenSSL are already effectively hedged, as they not just do direct CSRPNG->nonce, but mixin input and the key during nonce generation:
https://github.com/openssl/openssl/blob/67b5686b4419b4cb8caa502711c41815f5279751/crypto/bn/bn_rand.c#L285-L395
Also, the difference is unobservable from the API surface
Hedged signatures are already "allowed" in that sense
And there hardly needs to be an API that switches the underlying impl between e.g. what OpenSSL is currently doing and draft-irtf-cfrg-det-sigs-with-noise.
So if "allow" means introducing new APIs to switch between something random-looking/hedged then I don't think that's needed?
If that (what OpenSSL is doing) is the status in all platforms, then the spec could be just updated to prohibit CSRPNG->nonce specifically / urge the implementers to use a nonce generation method that survives a broken CSRPNG.
twiss commentedon Mar 17, 2026
No, that's indeed not what I meant. The only thing that needs to be done is to change the reference for ECDSA from RFC6090 to "RFC6090 or <whatever RFC draft-irtf-cfrg-det-sigs-with-noise ends up being>".
I'm not sure what other implementations are doing but I somewhat doubt everyone implemented this draft; perhaps @Frosne knows for NSS, for example?
I'm also not sure we need to mandate it; IMHO it also depends a bit on the platform and the quality of the source of randomness there whether this is needed.
Frosne commentedon Mar 19, 2026
(I am alive, gonna take a look a bit later)