Apparently Trezor is to a HSM what MtGox is to a bank. Given the ecosystem, I'm not really surprised...

The recovery key isn’t just used for recovery - every operation is derived from the recovery key. The device has to know it, in plaintext, in order to actually do anything.

From the Trezor MCU source code on Github, it looks like I was right, and the PIN check is literally a string comparison.

Yeah, I don't know why they do that. I was just responding to the decrypted key being stored in memory.

> The device has to know it, in plaintext, in order to actually do anything

How so? You can use pins for encryption, I believe that's what tptacek was referring to.

If you use a strong key derivation function with an efficient hardware (i.e. within a few orders of efficiency limits of current generation), while using maybe 10J of energy, will economically protect at least about $1000, or $16000 with an 8 character pin. In practice significantly more because of hardware costs for a parallel attack, and the casual cracker wouldn't be willing to spend that much on a totally uncertain reward. At moderate hardware costs it could take years to crack.

That's how they work - the PIN decrypts the encrypted seed key. However, after decryption, the seed key ("recovery key") is kept around in memory in order to actually be able to sign transactions/etc.

There are a few methods in which they could avoid keeping direct plaintext entries in memory that are difficult to extract without knowing the ROM code.

Maybe he's looking for one-way encryption ;)

Here I am sweating about if my hkdf and onioning different aes modes is future-proof enough. It's a good reminder that time to market is the only thing that matters.