-
-
Notifications
You must be signed in to change notification settings - Fork 33.8k
Possible Fix: Issue #60263 (Crypto cant sign/verify prehashed inputs) #60458
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Review requested:
|
panva
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not a bug fix. Prehashing, external_mu, or ph variants of ed25519 are simply not supported and they would require a different approach than the one in the PR which already conflicts with ml-dsa, ed25519/448 or defaulting to sha256 for ecdsa/rsa.
|
The only actual pre-hashing usecase in the wild is Perhaps this could be special-cased to allow null digest there, while not affecting all other curves/algos? @panva wdyt? |
|
@ChALkeR generally speaking if there was a sound extension proposal for the existing single-shot APIs that would deal with ml-dsa external_mu, ed25519ph, and prehashed ecdsa/rsa in a non-breaking manner - sure. |
|
@panva I'm thinking more of a change that would only allow prehashed secp256k1 That would way easier to implement/support, and will likely close the reason why people want this I.e. it could be added on curve-by-curve basis, not blocking on a supporting everything at once (and just keep throwing on unsupported) That will also protect against regressions when new algos are introduced |
|
@ChALkeR that approach makes sense for targeted support. The main use case I’m addressing comes from porting Ethereum protocols to node:crypto, which has three specific requirements:
Adding prehashed secp256k1 only for these cases would satisfy this use case, while avoiding regressions and keeping other algorithms unchanged. Adding "raw" as a keyword for the algorithm parameter could handle this cleanly without breaking existing behavior. It would allow signing prehashed or fixed-length data directly, covering the use case while keeping all other algorithms unchanged and consistent. |
|
@codermapuche Do you want to propose that as a PR? It also should check input and reject everything that is not 32-byte (for |
|
@codermapuche Also note that you won't be to plug this in as
|
|
I'm also unsure if signing would be even faster than https://www.npmjs.com/package/@noble/curves for your usecase. |
|
This would be my rough expectation. crypto.sign(algorithm, message, {
key,
messageType: crypto.constants.MESSAGE_TYPE_RAW // RAW is current behaviour & default, other options crypto.constants.MESSAGE_TYPE_DIGEST (covers RSA, ECDSA, Ed25519ph, Ed448ph), crypto.constants.MESSAGE_TYPE_EXTERNAL_MU
})crypto.verify(algorithm, message, {
key,
messageType: crypto.constants.MESSAGE_TYPE_RAW // RAW is current behaviour & default, other options crypto.constants.MESSAGE_TYPE_DIGEST (covers RSA, ECDSA, Ed25519ph, Ed448ph), crypto.constants.MESSAGE_TYPE_EXTERNAL_MU
}, signature)I'm not supportive of singling out |
Use case: