: How to Fingerprint a Wallet's Key Path in Three Steps
On July 30, 2026, Coinkite disclosed that Coldcard firmware shipped since March 2021 derived seeds from a software fallback RNG instead of the hardware entropy source — effective randomness estimated at 40 to 72 bits instead of the intended 128. Attackers swept funded addresses the same day; Galaxy Research puts confirmed losses near 1,596 BTC (~$100M) from ~7,300 addresses, with a suspected fourth wave under review. All of this is public record — Coinkite's advisory and technical backgrounder, plus independent analyses by Block and Wizardsardine. What follows is a method any team can run, plus our own reproducible evidence.
The uncomfortable precision
What is genuinely out of reach for a remote black-box attacker: key generation that calls the platform CSPRNG directly in native code — iOS SecRandomCopyBytes/getentropy, Android SecureRandom backed by /dev/urandom. Kernel CSPRNG state is not recoverable from outputs; there is no finite state to reconstruct. Only kernel exploits or local side-channels touch this — a different track. If a wallet does this, say so: the "immune by design" stamp is worth real money to insurance and compliance teams.
Where doors remain, even in modern wallets:
-
JS key paths inside native shells (RN/Flutter/WebView bridges). A broken polyfill chain silently falls back to
Math.random. Precedent: a single 2014 iOS commit swapped a secure RNG for an insecure one across 200+ downstream wallets. - Signing nonces. Key generation can be perfect; a repeated or biased ECDSA nonce still recovers the private key on the spot, entropy source irrelevant. Several documented thefts were exactly this — not generation.
- Bundled third-party or cross-chain SDKs that ship their own RNG inside an otherwise-clean app.
- Custom entropy mixing — blending timestamps or sensor noise into platform CSPRNG output can end with less randomness than the platform offered. (The Coldcard fallback itself was seeded from device UID plus power-on timer state.)
- Backup/KDF layers — weak KDF parameters, hardcoded IVs, exportable keys.
The three-step fingerprint
- Locate the generation path. Find where mnemonics/seeds are produced; follow every call into bundled SDKs.
- Classify the entropy source. Platform CSPRNG direct? JS-engine path (check every polyfill)? Custom mixing? Record the exact call chain.
- Assign the verdict tier. Immune-by-design / JS-bridge / nonce / SDK / custom-mixing / KDF — each with its reproduction class.
Generation and signing must be fingerprinted separately: a clean generation path tells you nothing about nonce handling.
What "reproducible" means here
We publish our own capability the same way we fingerprint others: with an evidence pack, not adjectives.
Weak-entropy key recovery, end to end, hash-anchored: a simulated vulnerable seed source (the low-effective-entropy class), table sweep, private-key recovery, and an ECDSA proof-of-possession — canonicalized with RFC 8785 JCS, SHA-256 anchored, Ed25519 signed. The demonstration runs in a reduced key space for runtime (details inside); the class it models is the one that just produced the largest self-custody loss event of 2026. Anyone can re-run and re-verify it.
The bundle's core record is SHA-256 anchored (f5df38c1…, re-derivable) and Ed25519-signed; verification instructions ship with it.
Why 40–72 bits is fatal, briefly
A 2^40 sweep is hours-to-days on commodity compute; 2^72 is nation-scale. Between those bounds sits ordinary theft economics. The disaster was not exotic — it was a quantifiable, preventable configuration that survived five years of public firmware.
What we do
For wallet vendors, custodians, and AI-infrastructure teams: private key-path fingerprinting. Every engagement produces either the immune-by-design stamp or a reproduction-class report — with the evidence pack, not a slide.
Top comments (0)