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 https://www.genesis-mining.com/pricing
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!