How secure is Trezor’s restore process?

A consulting client wanted to know if it was safe to do the trezor restore process on a possibly virus infested computer.  Here’s my answer.

Trezor hardware wallets start with a bip39 24 word seed with 256 bits of entropy.

(2048 words in the dictionary -> 11 bits of entropy
11 * 24 = 264. The 8 additional bits are a checksum.

If you lose the device, the restore process involves typing the words in to a possibly non-secure computer.  Trezor scrambles the words.

If the computer you used for the restore was hacked, how hard would it be for the hacker to steal the wallet?

There are 24 factorial possible orderings.  This is 79 bits of entropy.

logBase 2 ( factorial 24) => about 79

But there’s an 8 bit checksum, so only 1/256 of these orderings would pass the checksum. This leaves us with 71 bits of entropy, down from 256.  We leaked 185 bits of entropy… ouch.


Our attacker now has 2^71 xprivkeys to search for possible live bitcoin addresses, so he can steal the wallet.  Each xprivkey has an unlimited number of possible addresses in the bip32 tree, but let’s simplify and say the attacker checks only 1.  This involves at least 1 sha256 operation.

2^71 is about 10^21

According to

One can buy hashing power for $0.5/gigahash second. Round down to $0.1/ghs.

10^21 is a trillion gigahashes.

So, a napkin estimation on lower bound on cracking the trezor after the entropy leakage of a restore process is a hundred billion dollars.  Probably secure enough.

That being said, trezor could avoid the leakage by having users enter the 24 word passphrase by entering four digit codes (1-2048) from a dictionary, using the pin pad entry trick where the numbers are scrambled.  This would be more tedious, but more secure, but then again maybe overkill.  Perhaps it could be made available as an option.

Please correct my math if I missed anything!

About thomashartman1

I am a crypto currency enthusiast, trader, and software developer. Contact: thomas AT standardcrypto DOT com.
This entry was posted in Uncategorized. Bookmark the permalink.

8 Responses to How secure is Trezor’s restore process?

  1. TQ Hirsch says:

    You were pretty good, up until the very end, where you calculate the cost to guarantee a crack in one second, which is entirely unrealistic. Consider a targeted attacker who only wants to attack a hundred wallets. Waiting a day per result seems reasonable, so you only need ~$1.1M of equipment. Except that on average, a brute force search finishes in half worst case, so you only need $550k of equipment to start. Even better, you can amortize the cost of that equipment over the supposed hundred wallets, costing ~5.5k per wallet. (I’m not even considering the potential income from reselling the equipment.)

    Now consider that everybody who has a Trezor has spent $100 on security hardware to protect their wallet. It seems likely that the vast majority of people so selected would be protecting more than $5k/wallet, making cracking them a clear winning proposition.

    • thomashartman1 says:


      So perhaps my suggestion for avoiding leakage by using pin pad entry is a good one after all.

  2. anon says:

    Mnemonic seed words can repeat, so 24! is incorrect.

    Earlier firmwares had 50% false words, even for 24 word seeds, this was subsequently deemed un-necessary

  3. thomashartman1 says:

    Thanks for pointing that out.

    Most pass phrases don’t repeat words.

    If they do repeat words, in the case of a targetted attack where the words are known but the under is unknown, that’s now less entropy. So factorial is an upper limit on entropy, but a common enough case.

    Taking factorial as an estimate seems like a close enough, so I am leaving it. I don’t know how to fix the math to improve the estimate. (Suggestions welcome.)

  4. aperture17 says:

    This is a good topic. Hope the conversation can still proceed. I am figuring out a good method using 12 word BIP39. And wonder how safe, and how easy or possible if anyone just simply generate new keys on Mycelium and tried to brute-force find private keys with coins in it? Is this even practical, possible? – my page with research on Bitcoins.

  5. Michael says:

    Thanks for the article! A potentially more interesting question is how long it would take to brute force a random wallet. Let’s assume cryptocurrency gains traction and in 10 years everyone in the world has a single wallet (for simplicity). That’s approx 8 billion addresses. How long until the cost of computing power exceeds the average expected gain from cracking a random person’s wallet? If people try to avoid this by creating multiple wallets they also increase their surface area to this kind of attack. Wouldn’t be surprised it at least 1 person out there has a system running 24/7 attempting a random wallet crack — perhaps it runs 5 years before cracking anything, but that first random crack will be a story and inevitably attract more attention. Not familiar enough with cryptography to determine whether cracking a random wallet is less infeasible than a wallet with scrambled words.

  6. thomashartman1 says:

    24 words (256 bits) is not bruce forceable. I think 128 bits and up is generally considered safe for long lived keys.

    You can do the math on this by looking at the bitcoin hash rate, and how much dollars/watts are flowing into this. And then determine how long the entire bitcoin mining network would have to mine to brute force a 128 bit key. I think it is some ridiculous answer like 80 million years or something. Sorry I don’t have the napkin math, but at least that is the approach.

    Trezor bip32 keys use the same kind of hash that bitcoin does, so the approach is valid.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s