Deterministic ECDSA

[shizhMSFT]

RFC 8152 Section 8.1 require ECDSA to be deterministic.

Implementations SHOULD use a deterministic version of ECDSA such as the one defined in [RFC6979]. The use of a deterministic signature algorithm allows for systems to avoid relying on random number generators in order to avoid generating the same value of 'k' (the per-message random value).

However, the current implementation is non-deterministic (i.e. standard).

[thomas-fossati]

Noting that it is a SHOULD, not a MUST. So if an implementation decides to not do it it's OK, as long as there is a rationale for the decision.

Noting also that as we speak there is a debate in CFRG on whether the recommendation on using deterministic signature schemes is potentially harmful: https://datatracker.ietf.org/meeting/113/materials/slides-113-cfrg-signatures-deterministic-vs-randomized-00

[tolginator]

It is known that, as also referenced by Stephen in the deck above, solely relying on a good PRNG for k is harmful. While the spec says SHOULD and not a MUST, I'd encourage adding deterministic ECDSA for applications to choose to avoid cases where a good PRNG may not be available.

[SteveLasker]

Assigning to @thomas-fossati for updating the discussion.

[thomas-fossati]

The rationale behind the recommendation done in RFC8152 is now being reconsidered in the light of fault attacks such as Poddebniak17.

The revised COSE spec, which is sitting in the RFC editor queue, has been recently updated with a note describing the risks associated with fully deterministic ECDSA. (Note that the arguments for "deterministic is still a good idea" have become pretty weak.)

A similar point was raised in the TLS BCP and more broadly in the CFRG.

Add to this that:

1. To avoid the risks associated with a bad CSPRNG, the golang implementation already uses a deterministic+noise construction, see: ECDSA Sign
2. The kind of devices we target typically rely on more than decent CSPRNGs -- the main drive for deterministic was COSE targeting constrained / low-end devices with bad or non-existent CSPRNGs.
3. We allow our users to supply their signer implementation, so if they wanted they could implement https://datatracker.ietf.org/doc/html/rfc8032#section-5.1.6 and plug it into their calls to Sign1.

Overall the situation is pretty fluid, and I'd prefer to wait at least until a new set of recommendations solidifies that we can adopt with confidence.

[qmuntal]

To avoid the risks associated with a bad CSPRNG, the golang implementation already uses a deterministic+noise construction, see: ECDSA Sign

For reference, this is the commit where Go crypto implemented countermeasures for bad CSPRNGs: https://github.com/golang/go/commit/a8049f5

[yogeshbdeshpande]

This issue is not blocking release at all!

[SteveLasker]

Triage: Closing, as we do not plan to support Deterministic ECDSA, because the underlying library doesn't support. May reconsider in the future.

[qmuntal]

Upstream support for deterministic ECDSA has just been seriously proposed: https://github.com/golang/go/issues/64802.

[SteveLasker]

Thanks, @qmuntal As 64802 progresses, we can re-open to be actionable.