Proposal Details
Summary
From my discussions with the Go security team on mails regarding signature malleability in the crypto/ecdsa package, I propose introducing a new VerifyStrict function for stricter ECDSA signature verification. Since Modifying the existing Verify function could break compatibility, as many valid signatures historically do not enforce s < n/2. A separate VerifyStrict function would allow applications to opt into stricter validation without disrupting existing use cases.
This proposal aims to improve the security and usability of the crypto/ecdsa package in Go by formally documenting the signature malleability issue and considering API changes that allow developers to opt into stricter verification.
Background
ECDSA signatures have a well-known malleability property, where for a given valid signature (r, s) the alternative (r, n - s) is also valid. While Go crypto/ecdsa package already mitigates this during signing, the verification function does not enforce this constraint. This means that consumers of the library may unknowingly accept alternative signatures, which could have security implications depending on the use case.
Proposed Changes
-
Document the Issue Clearly in the crypto/ecdsa Package
- A clear explanation of ECDSA signature malleability should be added to the package documentation as an immediate solution. Developers should be informed that
crypto/ecdsa Verify function does not reject high-s signatures, making it their responsibility to enforce this if needed.
-
Introduce an Optional Strict Verification Mode
- A new function (e.g.,
VerifyStrict) could be introduced that enforces s < n/2. This allows applications requiring stricter security guarantees to opt in while preserving backward compatibility.
Proposal Details
Summary
From my discussions with the Go security team on mails regarding signature malleability in the
crypto/ecdsapackage, I propose introducing a newVerifyStrictfunction for stricter ECDSA signature verification. Since Modifying the existingVerifyfunction could break compatibility, as many valid signatures historically do not enforce s < n/2. A separateVerifyStrictfunction would allow applications to opt into stricter validation without disrupting existing use cases.This proposal aims to improve the security and usability of the
crypto/ecdsapackage in Go by formally documenting the signature malleability issue and considering API changes that allow developers to opt into stricter verification.Background
ECDSA signatures have a well-known malleability property, where for a given valid signature
(r, s)the alternative(r, n - s)is also valid. While Gocrypto/ecdsapackage already mitigates this during signing, the verification function does not enforce this constraint. This means that consumers of the library may unknowingly accept alternative signatures, which could have security implications depending on the use case.Proposed Changes
Document the Issue Clearly in the
crypto/ecdsaPackagecrypto/ecdsaVerify function does not reject high-s signatures, making it their responsibility to enforce this if needed.Introduce an Optional Strict Verification Mode
VerifyStrict) could be introduced that enforces s < n/2. This allows applications requiring stricter security guarantees to opt in while preserving backward compatibility.