rng: TRNG timeout returns zeros silently; no sanity check in src/rng.py

[helmchen1968]

I reviewed the entropy path after the Coldcard Mk3 advisory (July 2026) to check whether Specter shares that failure class. It does not — and the design is notably more robust:

• boards/STM32F469DISC/mpconfigboard.h sets MICROPY_HW_ENABLE_RNG (1), so the Yasmarang software fallback in ports/stm32/rng.c is compiled out entirely.
• There is no second rng_get() implementation competing for the same symbol, which was the root cause on Coldcard.
• If the macro were ever misconfigured, os.urandom would not exist at all (moduos.c), so src/rng.py would fail loudly instead of silently degrading.
• Touchscreen entropy is fed automatically on every PRESSING event via the decorators in src/gui/decorators.py, not as an opt-in step.

While reading, I noticed two related gaps that I think are worth closing.

1. rng_get() returns 0 on timeout

In f469-disco/micropython/ports/stm32/rng.c:

while (!(RNG->SR & RNG_SR_DRDY)) {
    if (HAL_GetTick() - start >= RNG_TIMEOUT_MS) {
        return 0;
    }
}

If the RNG peripheral stops responding, rng_get() returns zero without signalling an error. os_urandom() then fills its buffer with those zeros, and src/rng.py receives them as if they were entropy.

This is upstream MicroPython behaviour rather than Specter's code, but it is on the seed-generation path.

2. No sanity check in get_random_bytes()

In src/rng.py, the output of get_trng_bytes() is used and fed into the pool without any check:

def get_random_bytes(nbytes):
    global entropy_pool
    d = get_trng_bytes(nbytes)
    feed(d)  # why not?
    ...

Combined with (1), a dead or stalled peripheral is indistinguishable from a working one.

Impact

Low, and I want to be clear about that. The entropy pool mixes in touchscreen timing (time.ticks_cpu() at 180 MHz), so a failed TRNG would not make seeds predictable — it would silently reduce them to whatever the touch entropy contributed. That is defence in depth working as intended.

But it is a side effect rather than a guaranteed property. entropy_pool starts from the constant b"7" * 64, so the residual strength depends entirely on how many touch events happened to be accumulated beforehand — which is not measured anywhere.

Suggestion

Something minimal in get_random_bytes() would close both gaps, e.g. rejecting all-zero or single-repeated-byte TRNG output and surfacing a visible error rather than continuing.

A second, optional idea: track how many entropy contributions the pool has received and require a minimum before allowing seed generation — perhaps by prompting the user to draw on the screen if the count is low.

Happy to open a PR if the maintainers agree on the approach. Thanks for the careful design here; the layering is what makes this a minor issue rather than a serious one.

[3rdIteration]

Thanks for the issue and for double checking the codebase :)

I don't think anyone is working on a PR as yet, so if you can put one together, we can review it and take it from there. :)

[White7hat7]

I built the firmware and checked this at the object level to confirm it isn't the Coldcard class, and it isn't: rng_get has a single definition across the whole build (nm shows only rng.o), and the disassembly reaches RNG->DR at 0x50060800, so the Yasmarang fallback in modurandom.o is compiled with internal linkage and can't be resolved from the seed path. Agreed on the two gaps.

I'd be glad to open the PR. My preference is to put the check in src/rng.py rather than the vendored ports/stm32/rng.c, so it stays application-side and doesn't diverge from upstream MicroPython. The check rejects all-zero / single-repeated-byte TRNG output with a visible error, and skips buffers under 4 bytes so the get_random_bytes(1) call in input.py isn't affected. I'll leave the b"7" * 64 pool seeding (your point about accumulated touch entropy) for a separate PR to keep this one focused.

[helmchen1968]

@White7hat7 Thanks for building it and checking at the object level — a single rng_get definition confirmed against the linked binary is a stronger result than my source read, and it settles the Coldcard question properly.

Please go ahead with the PR. Your approach is the one I'd have taken: keeping the check in src/rng.py avoids diverging from upstream, and the sub-4-byte exemption is necessary rather than optional — for a single byte every possible value is a repeated byte, so the check would fire on every get_random_bytes(1) call in input.py. Splitting off the pool seeding also makes sense.

[White7hat7]

Opened #372 with the check. Kept it in src/rng.py as @helmchen1968 suggested, with the sub-4-byte exemption so get_random_bytes(1) isn't affected. Native tests pass (5/5). Thanks @3rdIteration for the go-ahead — happy to adjust based on review.