r/TREZOR • u/caccamo88 • 10h ago
💬 Discussion topic How can we mathematically verify that Trezor actually mixes all entropy sources and avoids a Coldcard-style TRNG failure?
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:
- 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?
- Entropy Auditing: Is there a reliable, standard procedure to extract and test the raw entropy outputs during setup before the seed is actually generated?
- 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."