Require deterministic ECDSA rather than random ECDSA

[jimsch]

The move has been towards using deterministic ECDSA rather than random ECDSA as described in RFC6979. This is a better signature algorithm in that it does not suffer from the problems of bad random number generators and it is cleaner to test as the results are not random.

I am happy if this is marked as next version.

[hhalpin]

Interesting. Earlier, we had come to consensus that we'd allow well-specified algorithms into the spec if they were implemented. I'm pretty sure deterministic ECDSA is not going to be in WebCrypto in the next few months (any reaction from browser vendors)? Regardless, we should write up deterministic ECDSA and with the Ed/Curve25519 docs, ship them as WG notes so the future WG can easily add them in as implementation appears. Jim, would you be willing to write it down?

[LeviSchuck]

Adoption of RFC6979 is increasing and it may be warranted to consider this topic anew now that Curve25519 implementations are reaching end users (see WICG/webcrypto-secure-curves#20 )

FIPS 186-5 § 6. The Elliptic Curve Digital Signature Algorithm now includes recommendations to apply a deterministic ECDSA algorithm as specified in RFC6979.

Deterministic ECDSA is a "SHOULD" recommendation in CBOR Object Signing and Encryption (COSE) § 8.1: ECDSA.

Other w3c proposals, such as Data Integrity ECDSA Cryptosuites v1.0, a part of Verifiable Credential Data Integrity 1.0, reference deterministic ECDSA as well.

[twiss]

Hey 👋 Apologies for the delayed response.

FIPS 186-5 § 6. The Elliptic Curve Digital Signature Algorithm now includes recommendations to apply a deterministic ECDSA algorithm as specified in RFC6979.

I can see it says:

Deterministic ECDSA may be desirable for devices that do not have a good source of quality random numbers for generating the per-message secret number.

Is that a concern for any Web Crypto API runtimes? And if it is, wouldn't they have issues with implementing many other parts of the API, like generating keys and random bytes?

And - from the perspective of a web app, what's the advantage of deterministic ECDSA, assuming that the random ECDSA has been implemented correctly by the runtime? Is it just to conform with the recommendations of the quoted specifications, or are there other benefits as well?

---

Separately: if it is needed / advantageous to add deterministic ECDSA, would you propose adding it as a separate algorithm, or as an option of the existing one? I assume we can't outright replace the existing algorithm at this point, like this issue title seems to suggest, since some (admittedly obscure) protocols might assume the random variant for one reason or another.

[LeviSchuck]

Hello,

Is that a concern for any Web Crypto API runtimes? And if it is, wouldn't they have issues with implementing many other parts of the API, like generating keys and random bytes?

Should the user agent, worker, or other runtime have unsuitable randomness, such as crypto.getRandomValues(new Uint8Array(10)) returning 0's or a value from Mersenne Twister, I believe that cryptographic dependent applications on that runtime would not meet expectations in other ways. That said, the risk should be kept in mind.

from the perspective of a web app, what's the advantage of deterministic ECDSA, assuming that the random ECDSA has been implemented correctly by the runtime?

There are applications where a canonical signature is desirable. That is, for a given input, at most one signature exists. This quality is common in distributed consensus applications.

would you propose adding it as a separate algorithm, or as an option of the existing one?

I would propose this being an optional boolean property on EcdsaParams, where it would only be considered in the sign operation. The verify operation will ignore this optional property, as the verification operation is the same for random and deterministic. Also, the verify operation cannot distinguish deterministic ECDSA from random ECDSA.

[twiss]

such as crypto.getRandomValues(new Uint8Array(10)) returning 0's or a value from Mersenne Twister

For what it's worth, this behavior wouldn't be allowed by the spec. I would posit that a runtime that does not have access to cryptographically strong random data should not implement the Web Crypto API at all.

There are applications where a canonical signature is desirable. That is, for a given input, at most one signature exists. This quality is common in distributed consensus applications.

But the stated property wouldn't be verifiable by the proposed API, because random signatures for the same input would also verify, right? So I imagine a more specialized implementation would be required for such applications, that I think is a bit too specific for a general cryptography API, to be perfectly honest.