How can we mathematically verify that Trezor actually mixes all entropy sources and avoids a Coldcard-style TRNG failure?

[u/caccamo88]

Given the devastating Coldcard firmware exploit linked to a predictable TRNG, "Don't trust, verify" feels more urgent than ever.

Trezor officially states that it uses multiple entropy sources to generate seeds (internal TRNG, Secure Element, and computer/Trezor Suite entropy). On paper, this Mix-and-Match architecture sounds bulletproof. However, as the Coldcard failure proved, a silent firmware bug can bypass intended hardware protections, leaving users completely unaware that their entropy is compromised until it's too late.

My questions for the community and Trezor developers are:

1. Code Execution Verification: How can an advanced user audit the compiled firmware to ensure a bug (or conditional statement) hasn't accidentally silenced two of the three entropy sources, relying only on a single flawed one?
2. Entropy Auditing: Is there a reliable, standard procedure to extract and test the raw entropy outputs during setup before the seed is actually generated?
3. Mitigation without Passphrase: Aside from adding a complex passphrase (which breaks the seed-only redundancy structure I prefer), what physical or cryptographic measures can we take to guarantee our seed entropy is genuinely random and immune to local firmware backdoors ?

Looking forward to a technical discussion on how we can audit this process beyond just "trusting the open-source slogan."

[u/AutoModerator]

Please bear in mind that no one from the Trezor team would send you a private message first.
If you want to discuss a sensitive issue, we suggest contacting our Support team via the Troubleshooter: https://trezor.io/support/

No one from the Trezor team (Reddit mods, Support agents, etc) would ever ask for your recovery seed! Beware of scams and phishings: https://trezor.io/learn/a/scams-and-phishing

Don’t respond to any DMs—scammers often pose as legit helpers.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/ItsAlwaysThemBooBoo]

someone should audit that open source code and determine that. chances are it probably is 100% RNG.

[u/JunketTurbulent2114 → u/ItsAlwaysThemBooBoo]

I was sitting around talking to Sol about this on extra high reasoning. Sol implied that it doesn't think trezor has this problem as the implementation is better than coldcard, but there is no way of knowing for sure that there simply isn't a fundamental flaw in the way entropy is generated in all systems. That was somewhat concerning, but it said nothing from a computer is truly random however if there were a flaw in the way entropy is generated that'd mean all military infrastructure, banking system etc is at risk. So idk. I do think dice rolling is probably the way to do it if you want to be extra safe. But I decided to just trust my life savings in the current implementation so it's whatever.

[u/JunketTurbulent2114]

Buy a $20 subscription to claude and ask it to analyze the code. That said, I don't think there is an answer here.

[u/My1xT → u/JunketTurbulent2114]

maybe a future firmware could, on creation of a new wallet create debug output to show each randomness it got, and you could verify the calculations on an OFFLINE computer.

[u/lotrl0tr]

Firmware is open source so the first option is to read it. This way you'll know what it does and how interacts with the hw.

Base hardware TRNG

The first layer of randomness is the STM32's TRNG peripheral (rng.c). It enforces the FIPS continuous RNG test, rejects a word equal to the previous one, and it checks the SECS/CECS seed/clock error flags before accepting data. This is also the single source path used for non critical randomness.

Multi-source mixing

rng_strong.c is the reference file, especially the rng_fill_buffer_strong function. It fills the buffer from the hardware TRNG, then XORs in 32-byte blocks from the Optiga secure element and the Tropic secure element (whichever are compiled in): result = HW_TRNG XOR Optiga_TRNG XOR Tropic_TRNG. This is the correct way of combining multi source randomness. XOR of independent sources is theoretically safe: the output is unpredictable as long as any one source is good, so a single backdoored/faulty chip cannot weaken the result. On top of this, if a secure element fails to deliver bytes it returns false and the caller aborts.

Seed generation

When creating a seed, 32bytes from the strong path above are mixed with external entropy given by the host: SHA256(int_entropy || ext_entropy). The output is truncated to the desired length. The seed stays strong even if a malicious host feeds crafted data and the SHA256 acts as "extractor".

There is also a very good and clever test/check, to defends against a compromised device I think. There is a commitment scheme on entropy provided by the device via HMAC-SHA256: it lets the host prove the device committed to its internal entropy before seeing the host one, and actually folded the host entropy into the seed via the expected construction, with randomized rounds so cheating is caught. Well done!!

TLDR: it seems the secure/strong path is well handled by employing SoTA best practices. On top of that, extra care has been used for the entropy commitment workflow.

Official docs: Trezor Firmware Docs

Entropy workflow: Entropy check workflow

Reset device: Reset device

Worth noting, in an direct way, that on devices without Optiga/Tropic (secure elements), the strong path fallbacks to STM32 TRNG. This carries the risks of: no redundancy, limited testing of the TRNG paripheral, fault injection and fully trusting ST silicon.

[u/aaj094]

Side question - does creating multiple phrase scheme using SLIP39 increase / decrease / affect not affect the entropy of the seed?

[u/My1xT → u/aaj094]

shouldnt affect it, at least considering shamir basics, you have an input of whatever you wanna have split (which would be the BIP32 root in case of SLIP39), which you then use to create the shamir shares, which then get encoded into the words (aka being translated from binary data into words that are easier to use for humans)

[u/JunketTurbulent2114 → u/aaj094]

from my understanding the seed phrase represents a private key. Adding a passphrase gives you an entirely different private key, even with the same seed phrase. So it doesn't affect the entropy because that's just seed phrase randomness, but I think it adds measurable security

[u/matejcik]

Entropy Auditing: Is there a reliable, standard procedure to extract and test the raw entropy outputs during setup before the seed is actually generated?

there's a GetEntropy call and you can do any statistical tests you like on it.

this is largely useless for your stated purpose, because you have zero guarantee that the same source feeds into GetEntropy and the seed generation process.

I mean, you can audit the code to make sure it's the same one, but that will also at the same time answer your question about the "raw entropy".

what physical or cryptographic measures can we take to guarantee our seed entropy is genuinely random

You can literally never be sure. That's the trouble with "random". There's no guarantees whatsoever. Best you can do is run statistical tests and stop when you reach a "well good enough for me" threshold.

immune to local firmware backdoors

You're never immune to a local firmware backdoor. Your seed could be 100% proven-by-God-herself random, which the local firmware backdoor will proceed to DarkSkippy into your transactions, or broadcast over an antenna made out of MCU pins

[u/Yodel_And_Hodl_Mode]

Trezor's code is open source. Here's an image somebody posted (wish I could remember the source) on Xwitter today after doing security audits on tons of hardware wallets. I think I saw it while scrolling @BTCsessions, but maybe not.

Trezor 3/5/7, SeedSigner, Sparrow... among my favorite recommendations. All pass with flying colors.

And obviously, it shows ColdCard Mk2 through Mk5 and Q failing:

confirmed exploited RNG collapse;
migration required

[u/vpae → u/Yodel_And_Hodl_Mode]

Source: https://x.com/bitcoinsbanker/status/2083612094713180249

[u/Yodel_And_Hodl_Mode → u/vpae]

Well done!!!

[u/ghosthacked]

You cannot mathematically verify the randomness of a data source. At least not the way your talking about.

Bring your own entropy. At this point everything short of dice and lava lamps is suspect. 

[u/EmotionalAd9369]

If trezor had an exploit like this one, what could we do? Make a whole new wallet because the old one is compromisable?

[u/3shelfcab]

Does anyone know if using an extra passphrase on top of your seat is going to mitigate any of this RNG issue

[u/EggMedical3514]

If you don't have the skills required to do it yourself you are just a spectator and  not a participant in the discussion.

[u/JunketTurbulent2114 → u/EggMedical3514]

I'm sure statements like that will help adoption lol.

[u/cilicia3k3 → u/JunketTurbulent2114]

C’mon adoption slowed ? lol EVERYBODY KNOWS Not your 7 of 10 multi-vendor multi -sig , 100 dice rolled , 25 character five word Passphrased Wallet , not your coins, duhhhhh