fix: correctly handle computation of k with leading zeros (RFC 6979) — CVE-2025-14505 - #351
Open
zuzukobaladze wants to merge 1 commit into
Open
fix: correctly handle computation of k with leading zeros (RFC 6979) — CVE-2025-14505#351zuzukobaladze wants to merge 1 commit into
zuzukobaladze wants to merge 1 commit into
Conversation
The per-iteration ECDSA nonce k is generated as a fixed-width buffer of this.n.byteLength() bytes, but was then truncated using BN#byteLength(), which drops leading zero bytes. That yields the wrong RFC 6979 (sec. 2.3.2) bits2int shift and produces incorrect signatures for the affected k values; given a faulty and a correct signature over the same input the private key can be recovered. Pass the full generated bit length explicitly, mirroring the existing message-truncation path (msgBitLength). _truncateToN is unchanged. Adds a regression test on p521 that pins r to the value derived from the correctly full-width-truncated k (a plain sign/verify round-trip cannot detect this, since a single signature is self-consistent for whatever k was used). Co-authored-by: Cursor <cursoragent@cursor.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
ECDSA's per-iteration nonce
kis generated as a fixed-width buffer ofthis.n.byteLength()bytes, but is then truncated withthis._truncateToN(k, true), which derives the bit length fromBN#byteLength(). For values whose fixed-width representation has leading zero byte(s), those bytes are dropped, giving the wrong RFC 6979 §2.3.2bits2intshift and an incorrectk.This produces faulty signatures for the affected
kvalues; combined with a correct signature over the same input, it can leak the private key (CVE-2025-14505 / GHSA-848j-6mx2-7j84).The fix passes the full generated bit length explicitly, mirroring the existing message path (
options.msgBitLength):_truncateToNitself is unchanged.Test
Adds a p521 regression test that pins
rto the value derived from the correctly full-width-truncatedk. A plain sign/verify round-trip cannot detect this bug, since a single signature is always self-consistent for whateverkwas actually used. The test fails onmasterand passes with the fix.Note
This is an already-public advisory, so disclosure here is appropriate. Consumers who produced signatures with a vulnerable build should rotate affected keys.
Made with Cursor