Identical r Values in a Nine-Bank Consortium's ECDSA Signatures

What it proves. In ECDSA, a signature is (r, s) with r = x(kG) mod n and s = k⁻¹(z + r·d) mod n, where d is the private key and z the message hash. If two different messages use the same k, the r values are identical by construction. Given two signatures (r, s₁) on z₁ and (r, s₂) on z₂, anyone can compute k = (z₁ − z₂)/(s₁ − s₂) mod n and then d = (s₁·k − z₁)/r mod n. So an identical r is not a statistical curiosity - it is a mathematically sufficient proof that the nonce repeated, and therefore that the private key is recoverable by anyone who reads the ledger. The FIPS certificate on the RNG is irrelevant to this conclusion: a certified RNG can still be misused (a forked process, a snapshot-restored VM, a faulty entropy path, or a library that bypasses the HSM's generator). The evidence, not the certificate, governs.

Assume full key compromise. The consortium should treat every signature by that key since the earliest exposure as forged-capable and untrustworthy for dispute resolution.

First actions (0–48 hours):

1. Freeze the key: stop accepting new attestations from Bank C's certificate and suspend its endorsement rights via a configuration change.
2. Scan the whole ledger, not just the two hits, for repeated r values per public key; the collision is likely to recur on other keys using the same library.
3. Reconstruct whether the exposed key could sign value-moving operations (token transfers, collateral releases) or only document attestations, and reconcile balances accordingly.
4. Preserve HSM logs and library versions; do not let the vendor rotate anything before forensics are captured.
5. Notify counterparties and the legal team with a clear statement that document content is unaffected but the attestation must be re-executed under a new key.

The argument confuses component certification with protocol safety. ECDSA's security proof assumes a uniformly random, single-use k per signature; RFC 6979-style deterministic nonce derivation removes the dependence on an entropy source entirely by deriving k from (d, z) via HMAC-DRBG, and hedged variants add fresh randomness on top so that a faulty RNG cannot alone cause a repeat. A certified RNG tells you nothing about whether the process calling it was cloned, whether the VM was snapshotted and rolled back, or whether the library reused a buffer.

Prevention:

• Require deterministic or hedged nonce generation (RFC 6979 plus auxiliary randomness) in every signing library; treat a library that refuses as non-compliant.
• Where the value justifies it, move treasury-grade keys to threshold signing (e.g., FROST 2-of-3 across separate HSMs and vendors) so that no single device ever holds a complete key and a single nonce fault is not fatal.
• Pin library and firmware versions; forbid VM snapshot/restore of signing hosts.

Detection:

• Run a continuous ledger scan that groups signatures by public key and flags any repeated r, plus a low-entropy test on r values (e.g., leading-zero bias) that catches partial nonce leakage before a full repeat.
• Alert on any signing operation whose HSM audit log lacks a matching application request.

Acceptance evidence: a re-run of the historical scan showing zero repeats, a signed test-vector report where two identical messages produce different r values under the hedged scheme, and a red-team exercise in which a deliberately faulty RNG is injected and the monitoring fires within one block.

Separate two questions that are often merged: is the signature secure today (yes - secp256k1 gives roughly 128-bit classical security) and will it still be trustworthy in 2040 (not something you can assert). The relevant threats are (a) cryptanalytic advance against the curve, (b) quantum forgery via Shor's algorithm, and (c) loss of the verification toolchain. Records with a 15-year horizon sit squarely in the window where 'harvest now, forge later' is a rational adversary strategy, especially for USD 22 million instruments.

Recommendation - hybrid, with re-anchoring:

1. Sign normally with ECDSA today so existing verifiers work.
2. Additionally anchor each document hash with a hash-based signature (LMS/XMSS, or SLH-DSA once the parameter sets your auditors accept are settled). Hash-based schemes rest only on preimage/collision resistance and are the conservative long-lived option. The signatures are large (kilobytes), which is irrelevant for a few thousand documents per day but disqualifying for per-transaction use.
3. Re-anchor the Merkle root of the document set annually under the then-current algorithm, producing a chain of evidence that does not depend on any single algorithm surviving 15 years.
4. Design for crypto-agility now: store the algorithm identifier and key epoch alongside each signature; never hard-code a curve or verifier address in an immutable contract; keep a documented migration path (and the ability to re-attest historical documents) in the consortium's operating procedures.
5. For enforceability, pair the on-chain signature with a legal attestation that names the algorithm and the re-anchoring policy, so a 2038 court is not asked to guess intent.