Was pre-hashed input considered for ECDSA?

[Frosne]

Was it ever considered to allow passing a pre-hashed digest to crypto.subtle.sign() instead of raw data? I went through the issues but I have not found anything related.

[twiss]

I can't find anything in the mailing list archives either but wasn't around at the time so am not sure.

I also think allowing to pass a pre-hashed digest would be useful; especially in combination with #390 it might be a simple way to enable signing/verifying a large amount of data (compared to the proposal in https://github.com/WinterTC55/proposal-webcrypto-streams/blob/main/explainer.md#proposed-api).

Btw, the same also applies to RSA.

[lsd-cat]

Thank you for filing this! We encountered this limitation a couple of times and had to fallback on a pure JS implementation to achieve the goal, specifically when implementing a browser-native Sigstore verifier. The relevant part of the code where we had to do that is here. Besides that, as @twiss says there's cases where we might want to verify a signature early and then hash the data later if needed, or async.

[Frosne]

Now we can have 2 potential options:

Option A is extend hash with { name: "none" } and call it a day. That's quick to implement/extend the standard with, but we'll pay a price of not being able to validata the input data. Important? No idea. But I am sure that there will be someone who will try to put a raw data with hash: none :)

Option B is to add a dedicated preHashedWith: { name: "SHA-256" } (or a better name (: ) parameter: we can already validate the input data, but this is a bit bigger extension of the specification.

[twiss]

Checking the length of the hash digest at least seems like a sensible idea.

If we were doing a greenfield design, I'd suggest { hash: 'SHA-256', preHashed: true }; but the downside of doing that now is that existing implementations (that don't support the preHashed property) will still accept it blindly and just hash the digest again.

The other option could be to use the type system somehow and e.g. introduce a Digest subclass of ArrayBuffer, such that you have to do subtle.sign({ name: 'ECDSA', hash: 'SHA-256' }, key, Digest.from(bufferSource)) or some such. And then subtle.digest could return a Digest directly. But that's of course yet a larger change to the spec.

[Frosne]

extending with {hash : "preHashedSHA-256"}? or even

crypto.subtle.sign(
    {
        name: "ECDSA-PreHashed", // I am bad with names
        namedCurve: "P-256", 
    },
   {...}
)

P.s. we should take an ownership of github.com/diafygi/webcrypto-examples

[Frosne]

signDigest could be also an option..

[twiss]

If we do name: "ECDSA-PreHashed", then you have to decide in advance when generating/importing the key whether it's gonna be used for prehashed signing or not, which seems overly restrictive.

signDigest seems reasonable 👍

[panva]

signDigest / verifyDigest 👍

[Frosne]

Works for me. What do we do now? :)

[panva]

Proposal: #551

[Frosne]

Proposal: #551

Great! Thanks for writing the patch :)