GHSA-vjpq-xx5g-qvmm: BSV Blockchain SDK has an Authentication Signature Data Preparation Vulnerability
BRC-104 Authentication Signature Data Preparation VulnerabilitySummaryA critical cryptographic vulnerability in the TypeScript SDK's BRC-104 authentication implementation caused incorrect signature data preparation, resulting in signature incompatibility [between SDK implementations](https://github.com/F1r3Hydr4nt/brc104-cross-language-tests) and potential authentication bypass scenarios.DetailsThe vulnerability was located in the `Peer.ts` file of the TypeScript SDK, specifically in the `processInitialRequest` and `processInitialResponse` methods where signature data is prepared for BRC-104 mutual authentication.**Vulnerable Code Locations:**`ts-sdk/src/auth/Peer.ts` lines 527-531 (signing)`ts-sdk/src/auth/Peer.ts` lines 584-590 (verification)**Root Cause:**
The TypeScript SDK incorrectly prepared signature data by:Concatenating base64-encoded nonce strings: `message.initialNonce + sessionNonce`Then decoding the concatenated base64 string: `base64ToBytes(concatenatedString)`This produced ~32-34 bytes of signature data instead of the correct 64 bytes.**Buggy Implementation (Before Fix):****Correct Implementation (After Fix):**
The fix properly decodes each base64 nonce individually, then concatenates the byte arrays:**Why This is Critical:**
BRC-104 authentication relies on cryptographic signatures to establish mutual trust between peers. When signature data preparation is incorrect:Signatures generated by the TypeScript SDK don't match those expected by Go/Python SDKsCross-implementation authentication failsAn attacker could potentially exploit this to bypass authentication checksPoCThe cross-language test suite demonstrates this vulnerability:**Setup**: Use identical nonces and cryptographic inputs across TypeScript, Python, and Go SDKs**Vulnerable behavior**: TypeScript SDK produces different signature data than Go/Python reference implementations**Impact demonstration**: Authentication attempts between TypeScript clients and Go/Python servers fail due to signature mismatch**Test Evidence:****Base64 Padding Short Circuit Analysis:**The vulnerability occurs because base64 padding characters (`=`) act as early termination signals for base64 decoders. When concatenating base64 strings before decoding:**Individual nonces:** Each 44-character base64 string decodes to 32 bytes**Concatenated string:** 88-character string containing padding in the middle**Decoding result:** Base64 decoder stops at the first `=` padding character, producing only 32 bytes instead of 64**Example with test data:**`INITIAL_NONCE_B64`: `"QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUE="` (44 chars → 32 bytes)`SESSION_NONCE_B64`: `"QkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkI="` (44 chars → 32 bytes)**Concatenated:** `"QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUE=QkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkI="`**Buggy decode:** Only 32 bytes (decoder stops at first `=`)**Correct decode:** 64 bytes (32 + 32, decoded separately then concatenated)Impact**Vulnerability Type:** Cryptographic signature verification bypass**Severity:** Critical (CVSS 9.1 - Critical)**Affected Systems:**TypeScript SDK clients attempting to authenticate with Go or Python SDK serversAny BRC-104 implementation relying on cross-SDK compatibilityMutual authentication protocols using the affected signature preparation**Who is Impacted:**Applications using the TypeScript SDK for BRC-104 authenticationSystems requiring cross-language/SDK authentication compatibilityAny peer-to-peer authentication scenarios where TypeScript clients communicate with non-TypeScript servers**Potential Attack Vectors:**Authentication bypass through signature verification failureMan-in-the-middle attacks if authentication is silently ignoredDenial of service through failed authentication attemptsThe fix ensures all SDKs now produce identical cryptographic signatures, restoring proper mutual authentication across implementations.
CVSS v3.1: 5.4