Generate Final Word: does it present all 8 candidates or resolve the 3 entropy bits internally?

[so7ow]

Hi, question about Generate Final Word on Passport Core (2.3.0+).

I generate my seed entropy by hand with dice and want the device only to compute the checksum, contributing no randomness of its own. Word 24 of a 24-word seed carries 3 entropy bits alongside the 8 checksum bits, which means 8 valid completions exist for any 23 words.

When I enter 23 words and choose Generate Final Word, does Passport present all 8 candidates, offer a way for me to supply those 3 bits, or pick one itself? And if it picks, is the choice zero-padded or random?

The docs say "a valid final word," singular, which is why I'm unsure. Thanks.

---

Answer from the code, 2026-08-02

Passport picks one. It does not present all 8, and it does not offer a way to supply the 3 bits. The choice is random, not zero-padded.

ports/stm32/boards/Passport/modules/predictive_utils.py, get_last_word:

index_bytes = bytearray(4)
common.noise.random_bytes(index_bytes, common.noise.ALL)
index = int.from_bytes(index_bytes, "little") % SEED_WORD_LIST_LENGTH
mock_last_word = trezorcrypto.bip39.get_word(index)
copy_words = ' '.join(seed_words) + ' ' + mock_last_word
entropy = get_seed_from_words(copy_words)
(final_words, error) = get_words_from_seed(entropy)
return final_words[-1]

The device draws 4 bytes from the full three-source entropy mixer, picks a random word index from it, then recomputes the checksum and returns the single valid completion. No modulo bias (2^32 mod 2048 = 0).

So the reporter's concern is correct. Someone supplying their own dice entropy for 23 words is receiving 3 bits of device entropy in the final word whether they want them or not, and has no way to opt out or to see the other 7 valid completions.

Whether that matters is a judgement call. It is 3 bits out of 256, and it comes from the same hardware mixer as everything else, so it does not weaken the seed. But it does mean the device is not purely computing a checksum, which is what the docs imply and what a dice-only user is trying to achieve.

Two things worth deciding

1. Docs. "A valid final word" is accurate but incomplete. Worth saying the device selects one of the 8 valid completions at random.
2. Feature. Offering all 8 candidates, or a way to supply the 3 bits, would satisfy users who want the device to contribute nothing. Design question rather than a bug.

Related

This same line is covered from two other angles: the return value of random_bytes is discarded here (SFT-7320), and the 4-byte buffer receives no secure element contribution (SFT-7321). Also raised independently in the AnchorWatch/Kimi report as ENT-003 and the Mike Andrews report as Finding 6, both tracked in SFT-7330 and SFT-7344.

[FoundationKen]

Hi. Great question.

“Generate Final Word” randomly selects one of the eight valid completions; it does not display all eight or let you provide the three missing entropy bits directly.

• Passport generates a random 11-bit BIP39 word index.
• It keeps the first 3 bits to complete the 256-bit entropy.
• It ignores the other 8 random bits.
• It calculates the actual 8-bit checksum and displays the resulting final word.
• Selecting Retry lets you generate another random completion, although it may repeat a word rather than cycling through all eight.

So, if you want Passport to contribute no randomness, you’ll need to calculate the complete 24th word separately and enter it manually. The relevant code is in:

• ports/stm32/boards/Passport/modules/predictive_utils.py:63
• ports/stm32/boards/Passport/modules/utils.py:1361
• ports/stm32/boards/Passport/modules/flows/random_final_word_flow.py:28)

[so7ow]

Understood, thanks.

Before I leave you alone about this: is enforcing the contribution of those three bits intentional? I can see an argument for it. Passport has no way to know whether a user's 23 words were generated well, and your 2.3.0 notes are explicit about the risk of seeds created outside the device, so mixing in a little of your own entropy could be seen as a reasonable default.

If that's the intent, understood. If not, presenting the eight valid completions would let Passport handle the whole process end to end for users who brought their own entropy, and it would close out issue #69 from the v1 repo properly.

Either way, appreciate the thorough answer and the source pointers.

[FoundationKen]

I think the user experience is the main issue. It's pretty clear that users can pick their own 23 words from drawing names from a hat or maybe manually mapping dice rolls to words, but what would the UX be on the final word?

If the user draws another from a hat and it is "bacon" and we let them enter it but then we swap it to something else to properly complete the checksum, that might seem very weird.

Open to other ideas if you have them.

Side note: If we add direct support for dice rolls, this will not be an issue. We are still discussing the best way we might offer this.

[so7ow]

Simplest: prompt for the 3 bits, perhaps nudging the user to flip a coin 3 times, and show the resulting word. Or display the eight valid completions numbered 000 to 111 and let the user pick one. Either could keep "let the device choose" as another option.

If you want to keep a word-entry path, SeedSigner accepts a word and uses its most significant bits, showing what it resolved to rather than swapping quietly.

One thought on the dice plan. It might be a real usability win, but it wouldn't solve this particular problem. Entering 23 words means I did the bits-to-words mapping myself. Entering dice rolls hands over the entire pipeline to the device. That relocates the trust rather than reducing it. Both of the options above serve people trying to avoid trusting arithmetic they can't verify, which is why I'd rather have either one than dice support.