source

This comment from ColdCard's micropython:

 #else // MICROPY_HW_ENABLE_RNG

// For MCUs that don't have an RNG we still need to provide a rng_get() function,
// eg for lwIP and random.seed().  A pseudo-RNG is not really ideal but we go with
// it for now, seeding with numbers which will be somewhat different each time.  We
// don't want to use urandom's pRNG because then the user won't see a reproducible
// random stream.

Why Existing Review Did Not Catch It (the real answer)

Nobody at coinkite is attacking their code with AI, case-in-point:

A few weeks ago, we used one of the best available AI models to review our code for security issues, and it did not find this bug or anything serious.

AI is not just a consultant you book for a weekly review. It can be a 24/7 watchdog that isn't just looking for vague "security issues" whenever someone feels like checking the code. It can wake up automatically every hour and re-write it's own prompts to attack the problem from different sides.

This is how AI-powered attackers find these kinds of vulns. So the defenders should probably get with the times!

actually, entropy was the feature you were missing

Why Existing Review Did Not Catch ItWhy Existing Review Did Not Catch It

Both RNG implementations had the same function signature, and the intended board-specific TRNG code was present in the binary. Existing review verified that code but did not verify end-to-end symbol resolution and call reachability from wallet seed generation.

The relevant preprocessor guard is visible in this section of code:

random.c:22-31

The guard used #ifndef, which tests whether MICROPY_HW_ENABLE_RNG is defined, rather than whether its value is nonzero. We defined that macro as zero, so the #error did not stop the build.

The hotfix now explicitly excludes MicroPython’s fallback PRNG object and adds a build-time RNG symbol check. The build fails unless the board-specific object defines the global rng_get() symbol and the upstream fallback object defines no symbols.

I feel like that last bit should've been part of the package from the beginning. The process should error out if it can't hardware rng generation. There shouldn't have been a fallback to begin with.

Dice rolls are optional and are not required to address this issue.

I'd ignore that "advice" and do them regardless. Even though the RNG gives 32 bits worth of data at a time, it doesn't mean you get 32 bits of actual entropy; any bias in the RNG weakens entropy but not the length of the data it returns. This is tricky to detect.

With dice rolls, preferably with a set not a single one, 99 times, you basically add a whole 256 bits of random that is completely separate from any hardware RNG. More separate sources of entropy = better, as long as the combination mechanism is hardened (i.e. stream it through sha256, which is what coldcard does.)

Milk Sad 2.0

You beat me by 16 seconds. #1536740

I have issues too