Ledger Nano Mnemonic Generation and Questions

Question

From the ledger documentaion we have

1. The device generates a sequence of 256 random bits using the true random number generator (TRNG) built into the device’s Secure Element.
2. The first 8 bits of the SHA-256 hash of the initial 256 bits is appended to the end, giving us 264 bits.
3. All 264 bits are split into 24 groups of 11 bits.
4. Each group of 11 bits is interpreted as a number in the range 0 - 2047, which serves as an index to the BIP 39 wordlist, giving us 24 words.

The result of this process is that your device will generate a single mnemonic seed out of 2^256 possible mnemonic seeds (That’s one of 115 792 089 237 316 195 423 570 985 008 687 907 853 269 984 665 640 564 039 457 584 007 913 129 639 936 possible mnemonic seeds). Note that while the first 23 words are completely random, the final word was derived from 3 random bits and 8 calculated bits from the SHA-256 hash. This means that the final word can act like a checksum - if you input an incorrect seed into the device while recovering it, it is possible for the device to detect that the inputted seed is invalid.

1. What was the motivation to move 8 bits to the end and use 2^11 possible words instead of move no bits and use 2^8 words with a 32 word mnemonic resulting in a bijective correspondance between the set of permutations of words and the set of possible 256 bit sequences.
2. Because of the dependence of the last word on the first 8 bits, there are (2048)^24 - 2^256 \approx 2.95 x 10^79 invalid 24 word mnemonics. Does anyone know what would happen if you tried to input on of these into a ledger during recovery mode? Mathematically it should give a random 264 bit sequence and then either 1) check that the first and last 8 bits are the same - if not, error. 2) throw the last 8 bits away to obtain a valid 256 bit seed that would correspond to a different mnemonic, where the # corresponding to the 24th word began with the same 3 digits.
3. "The device generates a sequence of 256 random bits using the true random number generator (TRNG) built into the device’s Secure Element." This is the only part that startles me a little. I feel like I remember reading in the past that a lot of attacks happen because random number generators can be exploited because they are not truly random. How is the randomness of this TRNG tested?

Answer 1

1. What was the motivation to move 8 bits to the end and use 2^11 possible words instead of move no bits and use 2^8 words with a 32 word mnemonic resulting in a bijective correspondance between the set of permutations of words and the set of possible 256 bit sequences.

Typical word lists are 2048 entries, and that seems to be well established as usable. Using 256-entry lists would mean significantly longer seed phrases, which are presumably less optimal in terms of convenience. Deviating from that just so that the bits align with 256 would seem very strange.

2. Because of the dependence of the last word on the first 8 bits, there are (2048)^24 - 2^256 \approx 2.95 x 10^79 invalid 24 word mnemonics. Does anyone know what would happen if you tried to input on of these into a ledger during recovery mode? Mathematically it should give a random 264 bit sequence and then either 1) check that the first and last 8 bits are the same - if not, error. 2) throw the last 8 bits away to obtain a valid 256 bit seed that would correspond to a different mnemonic, where the # corresponding to the 24th word began with the same 3 digits.

The text you quoted says the 8 checksum bits at the end are computed using SHA256 of the 256 entropy bits; not just a copy of the first 8 bits.

I don't actually know what happens if you enter a seed with mismatching checksum, but I suspect the device will just reject it.

3. "The device generates a sequence of 256 random bits using the true random number generator (TRNG) built into the device’s Secure Element." This is the only part that startles me a little. I feel like I remember reading in the past that a lot of attacks happen because random number generators can be exploited because they are not truly random. How is the randomness of this TRNG tested?

Randomness is indeed hard, but you buy a hardware wallet because you trust its security more than you trust a software wallet running on general purpose hardware. If that's not true for the RNG in it, don't use it - you can always generate it elsewhere and import.