Allow user to choose entire 256 bit seed

[crwatkins]

The current implementation of seedpicker only allows a user to choose 253 of the 256 bits of potential entropy used. It should allow the user to choose all 256 bits. GUIDE.md states:

The last word of a 24 word seed is a checksum word, calculated using the other 23 words as input.

This is not correct. The last word of a 24 word seed contains three bits of entropy and eight bits of checksum. This last word is not a checksum word, but rather contains the checksum (over 25% of the last word is entropy). Now this may seem all rather pedantic, but since one of the main purposes of this project seems to be to allow the user to create their own entropy seed, shouldn't it allow the user to create the entire seed?

I have a good appreciation that I am speaking of only three bits out of 256 and how insignificant that is to the secure functioning of ECDSA. However, this is very slippery slope. For example, I also have a good appreciation for how little 11 bits out of 256 is. That being true, maybe seedpicker should only ask the user for 22 words. Or maybe 21 words. You see where I'm going.

[merland]

Thanks for your interest in SeedPicker.

I don't agree that the line you quote is incorrect, the 24th word is a checksum word. And this is something that is stipulated in the BIP39 standard. Are you suggesting that we should not follow the standard?

SeedPicker does indeed try to not lose any entropy in any of the steps in the guide. Having said that, there is one thing that SeedPicker does that "throws away" a tiny bit of entropy, but it's very deliberate and for a good cause:

As stated in the tooltip next to the resulting 24th word, there are multiple words (not many) that are valid as checksums for the 23 words, but SeedPicker always selects the first one - alphabetically. The entropy loss for doing this is very small but the deterministic behavior is good for simplicity and usability. As a result, the risk of making a mistake is decreased. You can read more about this in issue #13. If you have an opinion on that decision, you are more than welcome to comment on that issue.

[crwatkins]

@merland

I don't agree that the line you quote is incorrect, the 24th word is a checksum word. And this is something that is stipulated in the BIP39 standard. Are you suggesting that we should not follow the standard?

On the contrary, I'm specifically suggesting that we do follow BIP39 which specifies:

The mnemonic must encode entropy in a multiple of 32 bits. With more entropy security is improved but the sentence length increases. We refer to the initial entropy length as ENT. The allowed size of ENT is 128-256 bits.

First, an initial entropy of ENT bits is generated.

We are asking the user to generate 253 bits of entropy (supplied to us in 23 words) which is not a multiple of 32 bits as the BIP specifies.

My recommendation would be to have the user generate 24 words instead of 23 which would provide 264 bits of entropy, of which 256 could be used to generate the 8 bit checksum according to the specification and re-encode the 24th word. This makes all the first word/last word/random word discussions moot by simply following the BIP.

I want to reiterate that I do not believe that the current implementation introduces any vulnerabilities nor any incompatibilities. I'm just pointing out that we are not following the intent of BIP39.

[merland]

I welcome this discussion, just because it is pedantic :) It is at the edge cases where the interesting things happen!

Could you clarify two things to me:

1. I'm struggling to understand why it would be beneficial to let the user first "generate 24 words" and then "re-encode the 24th word". Since the standard stipulates that the 24th word is a checksum and therefore not part of the entropy, the seed phrase can only hold as much entropy as can be represented by 23 words (numbers, really). As a result, aren't you forced to discard any "extra" entropy you add as input?

2. You did not comment about the decision made in #13. Is that decision related or unrelated to your reasoning?

[crwatkins]

Since the standard stipulates that the 24th word is a checksum and therefore not part of the entropy, the seed phrase can only hold as much entropy as can be represented by 23 words (numbers, really).

According to BIP39 that's just not true. Could you reference where in BIP39 you see that?

You did not comment about the decision made in #13. Is that decision related or unrelated to your reasoning?

As I alluded in my last comment, it's all moot if we do it correctly, but note that @mflaxman suggested that #13 might be controversial for just this reason.

[merland]

According to BIP39 that's just not true. Could you reference where in BIP39 you see that?

Not from the spec, it was meant as a much more general truth, as in:
"How much entropy can a 23 digit long number hold? - Less than a 24 digit long number."

As I alluded in my last comment, it's all moot if we do it correctly, but note that @mflaxman suggested that #13 might be controversial for just this reason.

And I conceded right away that we do throw away a tiny amount of entropy there. That may be controversial (I don't think so) but it's for a good cause. The fact that you stick to your guns after that concession makes the whole discussion moot :) I may have misunderstood this of course, please elaborate if that's the case.

[mflaxman]

If the user picks 24 words out of a hat, > 99% of the time that 24th word is going to be an invalid choice. It will make no sense to non-experts why their 24th word was "re-encoded". The whole point of SeedPicker is to make the validation of entropy -> seed words -> pubkey verifiable/intuitive for non-experts; if it were just about entropy then dice/cards might be better as people already have those (no need to print + cut out 2,048 words).

253 bits of entropy is already massive overkill, is there any conceivable situation where this might not be enough entropy? The BIP39 spec gives entropy calculations for 12-24 words: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#generating-the-mnemonic

I don't mind that SeedPicker is so cautious (especially since this is typically used as a deep cold storage emergency recovery key), but I could certainly understand complaints that 24 words is too much entropy.

For expert users, you can always use a tool like my humanRNG library in -verbose mode to see all the valid checksum words):

$ go run *.go -firstWords="zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo" -verbose
Input Flags (DEBUG ONLY):
checksum word number to pick: 0
testnet: false
mnemonicFirstWords: zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo
--------------------------------------------------------------------------------
SECRET INFO:
Full mnemonic (with checksum word):  zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo buddy
Full mnemonic length (# words):  24
--------------------------------------------------------------------------------
PUBLIC INFO:
SLIP132 Extended Pubkey: Zpub74sb5KB3Ak1RwabGr8SHQnMTkd2mC3boVDgPf1jBFNxcXh7Nx4KV3XakPDtWLN5RpszdM7qcBN4wm7xreh8Ys2xYUBqQ9GtkTN8h5kRVecc
Root Fingerprint: 669dce62
Network: mainnet
Derivation Path: m/48'/0'/0'/2'
Specter-Desktop Input Format:
  [669dce62/48h/0h/0h/2h]Zpub74sb5KB3Ak1RwabGr8SHQnMTkd2mC3boVDgPf1jBFNxcXh7Nx4KV3XakPDtWLN5RpszdM7qcBN4wm7xreh8Ys2xYUBqQ9GtkTN8h5kRVecc
--------------------------------------------------------------------------------
  Advanced Details:
  childXpub: xpub6EJyLk6mJRN6pR3fEkQ4AXpegthc6SwDLizHAxfs7bNSoJv1gLc5iHQYY71rn7Ygn8h2yaeNNpyLsP7xv59a85Ufu3L9a3nn2BjXieKhb6W
  childXpriv: xprvA1KcwEZsU3oobvyC8is3oPsv8rs7gzDMyW4gNaGFZFqTvWas8oHqAV64gocZ5xMDicGECgfpi3EMpNc6bh3StwynbNHBrw8adprentFd4jL
  childZpriv: ZprvAqtEfoe9LNT8j6Wok6uH3eQjCbCGnasx7zknrdKZh3RdetnEQX1EVjGGXvVCeCsxmMZpaDs4WaKxi7SzLK2RduTfAWnSSAEZ51Fp9z1htUS
  8 valid checksums: [buddy cash gap leaf move party sudden vote]

(you'd then pick one of those words out of a hat and re-run the tool with the -checksum=N flag, where N corresponds to the Nth word you chose)

To be explicit in case anyone is reading this thread and is confused: I do NOT recommend you use my tool this way, as there is little upside to choosing your own checksum, but it's free open source software and you can obviously do whatever you like with it. I only added the feature to make it possible for experts to verify their existing BIP39 seed phrases (that will only match seedpicker.net ~1/8 of the time) and for educational purposes (I didn't even know there was a checksum in BIP39 when I first used it).

[merland]

Thanks for a good explanation @mflaxman . Yes, the most important aspect of Seedpicker is definitely the transparency and verifiability; Before you start using Seedpicker, you have a piece of paper with 23 words, when you are done you still have the same piece of paper, with only one word added. If this is done on an offline computer which is wiped afterwards, anyone can convince themselves that no hacker has had an opportunity to interfere. I was searching for something that did exactly this. When I couldn’t find anything, I decided to create it myself :)

[crwatkins]

253 bits of entropy is already massive overkill, is there any conceivable situation where this might not be enough entropy?

Not using existing signature algorithms!

I don't mind that SeedPicker is so cautious (especially since this is typically used as a deep cold storage emergency recovery key), but I could certainly understand complaints that 24 words is too much entropy.

I don't mind either. I'm personally OK with 128 bit seeds, but I wouldn't want to force that decision on others and asking "non-experts" to decide 12 vs. 24 themselves is silly. The only downside to 24 words that I see here is a little extra effort, and the slightly increased chance of recording something wrong. I'll close this issue, but I would be glad to re-open it if anyone desires any further discussion.