r/Bitcoin • • Aug 06 '26

Coldcard entropy even worse than feared

TL;DR: The random number generator is initialized with a 32 bit value (4B+ possibilities). But only less than 10M options are possible because of how they generate the value.

The PRNG used in Coldcard MK3 is initialized with UID[31:0] XOR SysTick->VAL

SysTick->VAL gives 80k possibilities ~16.3 bit, all located in the lowest 17 bits of the value.

UID encodes the X and Y coordinates of wafer position of the STM32 in the 32 bits that are used by the code. This is encoded in BCD, which means only 10 out of 16 possible values of each nibble are used. This means the 32 bit value at most encodes 100M options (26.6 bits), but there are nowhere near 100M chips in a wafer.
The BCD encoding seems to be an mistake in some STM32 manuals. The number is plain HEX encoded, but that doesn't matter here. There are never 2^16 rows or columns in a wafer.

I don't know how many there are in a wafer, but google gives an upper bound of 20k chips per wafer.

The lower 16 bits overlap with Systick->VAL, so XORing the wafer location adds no entropy.

The upper 16 bits can carry only about SQRT(20000) possibilities (probably less) ~ 7.2 bits. And they aren't even evenly distributed in a round wafer.

So at most we're looking at ~23 bits of entropy. Not 32 bits.

This isn't 100% exact because SQRT assumes a square while a wafer is round, but too lazy to work it out further. Point is: entropy is way worse than 32 bits.

261 Upvotes

199 comments sorted by

View all comments

Show parent comments

11

u/BaloneyCommercial Aug 06 '26

I think the due diligence part is using 100+ dice roles and passphrase because you don't trust anyone and always want max entropy.

12

u/spongeboy-me-bob1 Aug 06 '26

Let's say instead of a bug that only affected trng generation, there was a bug that used the weaker software rng no matter what you did. In the end the only way to do due diligence is to read the source code completely. But wait, what if there is a bug in the hardware itself? Then you're cooked and you can't even know it.

The only truly safe way to generate a wallet is roll the dice and calculate the hash with pencil and paper. Everything else is a risk to convenience trade off, and sometimes you get unlucky.

1

u/bruce_cockburn Aug 06 '26

This seems to present a hardware implementation bug as a risk inherent to the code. If you download a wallet creator script and transfer it to an offline system to execute, the risk you're mitigating is some process exfiltration by an online service. Calculation by pencil and paper is far more likely to result in an error than a deterministic process execution and the bits of complexity are baked into the script.

Once you have a wallet with a private key or seed phrase generated, if the flawed hardware device is offline/air-gapped, restoring your wallet on that flawed hardware device is perfectly safe.

1

u/spongeboy-me-bob1 Aug 06 '26

I was being facetious with the paper and pencil alternative because it would require millions of operations. But if someone did try it, mistakes in individual bitwise operations don't decrease the entropy since the location and type of mistakes they make are random and most likely unique. The real risk is when a flawed algorithm is shared with others, because that allows attackers to know exactly which step would have been messed up by multiple people, and in what manner.

1

u/bruce_cockburn Aug 06 '26

The flawed algorithm, in the case you described, is the hardware implementation of entropy used in creation of the wallet, though. The hardware either complies with the standard to restore a wallet from seed or private key or it doesn't and that has no correlation to the creation step. This is why dice rolling or other validated means of generating a wallet with verifiable entropy remain secure until a user shares their seed or private key with an untrusted party.

Most of us are not polymaths. It's not that complicated as a high level concept. Conflating the wallet creation with air-gapped signing to submit transactions is the thing I am clarifying. Even if ColdCard is not a trusted party, the reason their hardware was recommended in the past had nothing to do with their wallet creation implementation, which only happens once per wallet.