How it broke

A COLDCARD exposes two hardware randomness sources to its firmware: the STM32 hardware RNG, which is an analogue noise circuit, and one or two secure elements that can also emit random bytes. The intended flow is short.

COLDCARD's documentation describes that mechanism in enough detail to compare it with the implementation. The FAQ captured on 1 August 2026 says the device primarily uses the STM32 hardware TRNG, XORs a PRNG seeded from SE1 and SE2 into that output, and then applies SHA-256 whitening. It describes the hardware source as measuring analogue transistor noise.

A hash cannot create entropy: whitening can make a weak source's output look balanced, but it cannot expand the set of candidates an attacker must enumerate. The same FAQ describes the value present before optional dice rolls are added:

"the entropy (about 2.5 bits per roll) will be added to the 256 bits of entropy already picked." COLDCARD documentation

That sentence states a runtime property that was not true for affected device-generated seeds; the published candidate-space estimates sit far below it, and none is a measured per-device figure. This archive verifies the wording as it appeared on 1 August 2026, after disclosure; when it first appeared, and whether it was present during the affected period, remain open here. V2 In pure-dice generation, sufficient fair and secret rolls bypass the affected generator; in mixed mode the affected value remains a prefix and the rolls add a separate source of uncertainty. The dice code hashes roll symbols directly rather than feeding them through the 32-bit reseed path, and the dice record distinguishes the two workflows.

The path before March 2021

Up to v3.2.2 the seed came straight from the hardware RNG. Block's published analysis quotes the v3.2.2 generation code, seed = bytearray(32) followed by rng_bytes(seed), and reports that this path reached ckcc.rng_bytes and the board-local STM32 hardware RNG.

What changed in March 2021

In March 2021 seed generation moved to a random.bytes() wrapper backed by ngu.random.bytes(). Block date the change to commit b18723dd of 1 March 2021, first released in v4.0.0 on 17 March 2021, and quote the new call, seed = random.bytes(32), with shared/random.py mapping it to ngu.random.bytes. Coinkite describe the same migration: it "resolved rng_get() to MicroPython's software fallback instead of COLDCARD's hardware RNG implementation."

Block also quote the surrounding wallet-generation code, including the check assert len(set(seed)) > 4. In their reading it detects only trivial failures, which ordinary Yasmarang output passes, and the same is true of the libngu repetition check quoted further down: neither shape check can establish that the bytes came from a hardware source.

The board configuration disables the module

COLDCARD disables MicroPython's RNG module and supplies a board-specific replacement, whose random_buffer() reads the STM32 RNG peripheral and fails on timeout or repeated samples. The module is disabled with a board-configuration macro, quoted here as Block's analysis presents it from the production board headers:

// We have our own version of this code.
// LATER: when zero, this selected some PRNG code we really didnt want.
#define MICROPY_HW_ENABLE_RNG       (0)

The guard tests macro presence

The macro is defined with the value zero. The board replacement tests that value; the libngu guard on the affected seed path tests only whether the macro exists. That guard was replaced by a value test upstream on 6 August 2026, five days after this capture was taken; the version that governed the affected builds is the one below.

#ifdef MICROPY_PY_STM
// ports/stm32/rng.c
extern uint32_t rng_get(void);
#define CHIP_TRNG_SETUP()
#define CHIP_TRNG_32()         rng_get()

#ifndef MICROPY_HW_ENABLE_RNG      <-- tests DEFINED, not VALUE
#error "get a HW TRNG plz"
#endif
#endif

What CHIP_TRNG_32 resolves to

CHIP_TRNG_32() resolved to rng_get(). With the board macro at zero, MicroPython's rng_get() was the software fallback rather than the hardware peripheral. Block's analysis quotes the selection and the fallback's one-time initialisation:

#if MICROPY_HW_ENABLE_RNG
    // STM32 hardware RNG
#else
    // Yasmarang fallback
#endif

// with the macro at zero, rng_get() initializes Yasmarang with:
pad = UID_low32 ^ SysTick->VAL;
n = RTC->TR;
d = RTC->SSR;

In Block's reading the UID is fixed device metadata and the SysTick and RTC registers are observable or constrainable timing state; none is a cryptographic entropy source, and no further entropy is collected after the first call.

Two PRNGs and one XOR

There is a second Yasmarang. libngu keeps its own state, started from published constants, and XORs its output with the MicroPython stream:

// TODO should be marked as confidential memory
static uint32_t yasmarang_pad = 0x0a8ce26f, yasmarang_n = 69, yasmarang_d = 233;
static uint8_t yasmarang_dat = 0;

void my_random_bytes(uint8_t *dest, uint32_t count)
{
    uint32_t last = 0;
    while(count) {
        uint32_t chip = CHIP_TRNG_32();          // = MicroPython Yasmarang

        if(chip == last) {
            // maybe TRNG is not clocked? Fail hard
            mp_raise_OSError(MP_EFAULT);
        }
        last = chip;

        chip ^= my_yasmarang();                   // = libngu Yasmarang

        int here = MIN(4, count);
        memcpy(dest, &chip, here);
        dest += here; count -= here;
    }
}

Block's analysis states what the XOR contributes: "XOR does not create entropy. If both inputs are reproducible, their XOR is reproducible."

On 7 August 2026 the COLDCARD account published what it headed an "Extremely important correction" to how the mechanism was being described, addressed to Jack Mallers, whose post is not held here. It says the weak PRNG "wasn't Coinkite's fallback" but "MicroPython's built-in general-purpose RNG, introduced upstream in May 2018", that it "didn't become part of Coldcard's seed generation until the libNgU migration in March 2021", and that setting MICROPY_HW_ENABLE_RNG=0 "was intended to disable that software path" rather than to select it, so what is being called a fallback was "inherited behavior from the underlying platform that became active because of a link-time error". R3

On the point that correction makes, it and the published analyses quoted on this page agree. The generator reached through rng_get() is MicroPython's, quoted above as Block's analysis presents it; the defect described here is the guard that tested macro presence rather than value, which is the mechanism Coinkite's own technical backgrounder describes in the passage quoted higher up this page. The second Yasmarang is a separate matter: it lives in libngu/ngu/random.c and starts from the three constants shown above, and the correction does not address it. R4 V5

The 32-bit reseed path and its scope

In March 2022 a reseed API was added. On the normal successful boot path, Mk4, Mk5 and Q call it with values returned by their secure elements. U6