4 ms·
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
by zwily 9y ago
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.
- Scoundreller 9y agoMaybe he's looking for one-way encryption ;)
- darkmighty 9y ago> 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.
- zwily 9y agoThat'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.
- Scoundreller 9y agoThere 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.
- tptacek 9y agoFrom the Trezor MCU source code on Github, it looks like I was right, and the PIN check is literally a string comparison.
- zwily 9y agoYeah, I don't know why they do that. I was just responding to the decrypted key being stored in memory.