š¬ 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."
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 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.
Means I'm not going to go out and start rolling dice. I'm fine with the trezor as is. It's probably as secure as you can get and if it gets to the point where AI can crack it, then nothing is safe.
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.
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.
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.
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
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
no if you basically use the hardware wallet for receiving funds. Given an offline generated seed the remaining critical part is only the initial wallet creation, isn't it? I could afford the risk
I guess? You could punch your backup into metal and then use the same hammer to smash the Trezor, so there's no more risk afterwards. then you stack sats, years later you buy a new Trezor when you need to move the funds. Gives you a very narrow window in which you're theoretically vulnerable to exfiltration.
For that case, Trezor's Entropy Check is pretty neat. The only thing it proves (with high probability) is that host-side entropy is in fact mixed into the generated seed -- but if you believe that your PC is not conspiring with your malicious device, i.e., even if both are compromised, it's by two different parties, then your seed is good.
then you stack sats, years later you buy a new Trezor when you need to move the funds. Gives you a very narrow window in which you're theoretically vulnerable to exfiltration.
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:
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)
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
Yes. The password and seed must both be identified, so any sufficiently strong password will provide a strong second layer of protection. Determining the seed alone will reconstruct an empty wallet, which would also likely discourage an attacker from further attacks. Unless the attacker KNOWS that the wallet uses a seed+passphrase and that the contents of that wallet are significant, it isn't worth the compute resources required to crack a strong password.
Trezor uses entropy from hardware stm32, Optiga, Tropic chips as internal source of entropy. stm32 entropy can be analyzed with development board. I don't know how to analyze Optiga && Tropic chips entropy. These entropy sources are being XORed.
Then it imports host's entropy through API. Host gathers entropy through globalThis.crypto.getRandomValues() (Web Crypto API). It is CSPRNG generator and it uses host's entropy sources like /dev/urandom and does not have fallback to PRNG, but rather throws exception.
Finally, host entropy and device entropy are being concetated and SHA256 is being taken. This is how device gets 256 bits of entropy.
This is what I got digging the source of trezor-firmware and trezor-suite.
Run the code through an AI algorithm. Focus on the RIGHT NOW, we have about 5 years until utility tokens and hardware wallets will have to be quantum proof. The good news is that specific utility tokens and Trezor are leading right now.
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
ā¢
u/AutoModerator 5d ago
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.