Repository navigation
Conversation
This branch has not been deployed
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
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
Fixes #480:
COSE_Sign1.signedData()rebuilt the Sig_structure by re-encoding the parsed protectedHeaderMapwith canonical CBOR, and the decoder discarded the original protected-header bytes. In COSE (RFC 9052) the protected header is abstrwhose exact bytes are what the signature covers, so verification must operate on the received bytes. Any signer whose protected-header bytes differ from this SDK's canonical re-encode (for example a non-minimal integer encoding) had a valid signature rejected — and, symmetrically, a signature was accepted against transmitted bytes it never covered, because verification used the SDK's own re-encode instead of the wire bytes.Fix
packages/evolution/src/cose/Sign1.ts:WeakMap(protectedBytesCache) captures a copy of the received protected-header bytes at decode time, following theformatCachepattern already used inTransaction.ts. Only the default codec options populate the cache — non-default options opt out, since custom options imply the caller wants re-canonicalization.signedData()replays the preserved bytes when present and falls back to the existing canonical encode for instances built locally (the builder path signs over that same canonical encode, so locally built messages are unchanged).COSESign1FromCBORBytesencode path replays the preserved bytes too, so a decode/encode round trip reproduces the original encoding byte-for-byte. The parsedHeaderMapremains available as the on-demand view of the headers.Tests
New file
packages/evolution/test/Sign1.ProtectedBytes.test.ts(4 tests), each verified RED on main one at a time before the fix:verifyDataaccepts a valid signature over non-minimally encoded protected headers (label1written as the two-byte uint0x18 0x01) — on main it returnedfalse.signedData()replays the original protected-header bytes — on main it produced the canonicala20127…form instead of the receiveda2180127…bytes.true, since verification ignored the wire bytes).GREEN after the fix: the new file passes 4/4, and the full package suite passes from a clean run: 1682 passed / 75 skipped / 0 failed (test files 102 passed / 1 skipped of 103 — exactly main's 1678-test baseline plus the 4 new tests).
tsc --noEmitand eslint are clean, and a patch changeset is included.Independent builder — not affiliated with the Cardano Foundation, IOG or Intersect.
@Kshot9000 (https://x.com/kshot9000) · Tips (ADA): addr1q8hnl6vl5a6k3rw3n5g3jtte696zcl76kfatzv7gpswa9r0dj7fma6klq55y4ffm7tf0em09udnyhuk4ah92pl5x9jpqjae44v