Venu Bojanapalli

Web1 – read Web2 – read / write Web3 – read / write / own

If you hold on an affected device, go to the vendor advisory, not to threads. Fixed firmware is out, updating does not repair an existing seed, and 50+ private dice rolls at generation time means you were never exposed to this. blog.coinkite.com/coldcard-m…

Custody assurance tests perimeter, operations, ceremony documentation and signing policy. It does not test whether keys were random when they were made. That gap is about to sit underneath tokenized treasuries, funds and stablecoin reserves.

Now the part relevant beyond Bitcoin. Entropy is a generation-time property. Afterwards it is unobservable. A 40-bit key and a 256-bit key look identical in every log you have. There is no monitoring rule for this. You learn when the funds move.

The vendor's own explanation deserves reading. The source was always public. They assume someone used AI to review old firmware versions. They had run a leading model over the code weeks earlier and it found nothing. Their line: both sides have the same tools.

The blast radius is wider than seeds. The same stream fed paper-wallet private keys, random seed-XOR masks, device cloning and USB session keys, key transfer material, 2FA secrets and generated passwords. One weak source, many consumers.

Newer devices were not clean. They added a secure-element reseed, but only four bytes of the digest reached the reseed function, and it overwrote one 32-bit state word. Vendor's own number: ~72 bits of entropy where 128 was intended.

The final seed was SHA256d hashed. Hashing makes output look uniform. It cannot enlarge the input family. ≤2^32 candidate inputs → hash → ≤2^32 candidate seeds. The BIP39 checksum adds nothing either.

A health check rejected repeated adjacent outputs. A deterministic PRNG passes that trivially. It produces different values every call. They are just the wrong kind of different. Statistical randomness and cryptographic unpredictability are not the same test.

Three things that look like safety nets and were not. The output was XORed with a second software generator seeded from public constants. XOR of two reproducible streams is reproducible. Entropy is not created by mixing predictable things.

None of those is a secret. The chip ID is factory metadata, partly exposed in the USB serial number. The timers are constrainable. On a cold boot the RTC may be static. Block's ceiling for the worst-affected devices is under 2^40.7, narrowing to roughly 2^16.3.

So instead of the STM32 hardware RNG, key generation bound to MicroPython's software fallback. Its seed inputs: • low 32 bits of the fixed chip serial number • a millisecond countdown timer • two real-time-clock registers Collected once. Never refreshed.

Root cause, per Block's Bitcoin engineering team. The board config defined MICROPY_HW_ENABLE_RNG as 0, because the vendor had its own hardware RNG wrapper. The key-generation library checked #ifndef. Defined-as-zero passed the check.

$70M in BTC left 1,196 wallets in 41 minutes on 30 July. Nothing was hacked. The keys were guessable the day they were made. A build flag set to zero, shipped March 2021, live for ~1,900 days. Thread on what this actually means. 🧵

The vendor's own explanation deserves reading. The source was always public. They assume someone used AI to review old firmware versions. They had run a leading model over the code weeks earlier and it found nothing. Their line: both sides have the same tools.

The blast radius is wider than seeds. The same stream fed paper-wallet private keys, random seed-XOR masks, device cloning and USB session keys, key transfer material, 2FA secrets and generated passwords. One weak source, many consumers.

Newer devices were not clean. They added a secure-element reseed, but only four bytes of the digest reached the reseed function, and it overwrote one 32-bit state word. Vendor's own number: ~72 bits of entropy where 128 was intended.

The final seed was SHA256d hashed. Hashing makes output look uniform. It cannot enlarge the input family. ≤2^32 candidate inputs → hash → ≤2^32 candidate seeds. The BIP39 checksum adds nothing either.

A health check rejected repeated adjacent outputs. A deterministic PRNG passes that trivially. It produces different values every call. They are just the wrong kind of different. Statistical randomness and cryptographic unpredictability are not the same test.

Three things that look like safety nets and were not. The output was XORed with a second software generator seeded from public constants. XOR of two reproducible streams is reproducible. Entropy is not created by mixing predictable things.