You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 23, 2020. It is now read-only.
Because of the prevalence of libsecp256k1 with bitcoin/ethereum, more and more people are using those libraries for ecdsa. When verifying signatures, libsecp256k1 enforces a signature's s to be in lower-s form to essentially help protect signature malleability.
See the comment in its include header for more info:
Because of this, I would propose a feature be added that either converts the s value of ECSignatures to their lower-s form automatically upon signature creation (if necessary), or at least provide a public api function to do so for easier compatibility with creating signatures that can be consistently verified by these libraries.
Here's some pseudocode that would do the latter option:
Sure, that makes sense. I would have a method on ECSignature called normalize() that just normalizes the signature so no new signature has to be created.
An ECSignature doesn't contain data about its ECDomainParameters which are required for doing this calculation. Would a better alternative be providing an optional normalize boolean when actually creating the signature? Or should a normalize() function be added to ECSignature which simply requires taking in an ECDomainParameters object? (Or as a 3rd alternative, simply add a reference to the ECDomainParameters on the ECSignature object itself when creating it, so it can have that information already available to call a normalize() function with no additional params)
That's a good point. I would not add a ref to the signature for sure.
Of the other two options, it seems like we could do both. normalize(ECDomainParameters) seems fine, but a bool to normalize from the start seems better. They can both exist, though.
Btw, I'm about to move this project to a new repo, so keep your PR branch around in case you'd have to re-do.
Because of the prevalence of libsecp256k1 with bitcoin/ethereum, more and more people are using those libraries for ecdsa. When verifying signatures, libsecp256k1 enforces a signature's
s
to be in lower-s form to essentially help protect signature malleability.See the comment in its include header for more info:
https://github.com/bitcoin-core/secp256k1/blob/d644dda5c9dbdecee52d1aa259235510fdc2d4ee/include/secp256k1.h#L483-L513
Because of this, I would propose a feature be added that either converts the
s
value of ECSignatures to their lower-s form automatically upon signature creation (if necessary), or at least provide a public api function to do so for easier compatibility with creating signatures that can be consistently verified by these libraries.Here's some pseudocode that would do the latter option:
The text was updated successfully, but these errors were encountered: