Why 24 words?

[BlackHatCoiner]

I've noticed that on BIP39 total words on mnemonics can be either 3, 6, 9, 12, 15, 18, 21 or 24. Using mnemonic lower than 12 words, has low entropy and can be guessed by an attacker. While most of the wallets use the 12 words option, some others have different philosophy. For example, trezor chooses to use 24 words. Since 12 words are strong enough, why should someone use more than that? Does it offer extra security? I doubt.
(Isn't it 128 and 256 bits?)

Mnemonics tend to be easy to memorize, besides on their writing convenience. If you really want to keep your funds safe, but are afraid of losing them, you can try to memorize the words. I personally haven't, because I don't think I need to, but it's possible with only 12 words. With 24, it isn't.

[HCP]

I've noticed that on BIP39 total words on mnemonics can be either 3, 6, 9, 12, 15, 18, 21 or 24.

To be technically compliant with BIP39... they should be 12, 15, 18, 21 or 24 words. The BIP39 specification says the initial entropy needs to be between 128 and 256 bits.

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.

Anything outside that range is technically not compliant with the BIP39 standard.

Using mnemonic lower than 12 words, has low entropy and can be guessed by an attacker. While most of the wallets use the 12 words option, some others have different philosophy. For example, trezor chooses to use 24 words. Since 12 words are strong enough, why should someone use more than that? Does it offer extra security? I doubt.
(Isn't it 128 and 256 bits?)

Technically, yes... it does offer "more" security... but it's like saying that it's more difficult to get to Pluto than to Jupiter because it's further away... they're both a looooooooong way away and very difficult to get to... but one is technically further away than the other. Same with 128bit vs. 256bit entropy... the latter is theoretically "harder" to bruteforce than the other by sheer fact that it's so much bigger, but the former is already "impossible" to bruteforce anyway.

Mnemonics tend to be easy to memorize, besides on their writing convenience. If you really want to keep your funds safe, but are afraid of losing them, you can try to memorize the words. I personally haven't, because I don't think I need to, but it's possible with only 12 words. With 24, it isn't.

Because attempting to memorise 12 words and keep them memorised over a long period of time is a recipe for disaster. There are countless threads on these forums where people struggle to remember all sorts of things (wallet passwords, words from mnemonics, what software they had installed, when they did things etc)

Human memory is a delicate thing... a simple knock to the head from any manner of things can cause "permanent" memory loss.

IMO, there is no way that memorising a 12 word seed is a way to "really keep your funds safe"... quite the opposite in fact.

[Evilish]

12 words are secure enough on their own. But keep in mind, 24 words provide 256 bit entropy (vs 128 bit entropy that 12 words provide). I imagine that plays a role in 24 words being more preferred, because greater entropy is always better right? But like you mentioned that comes with greater inconvenience.

I wonder if there's a reason behind that other than just 256 > 128 because 128 bit entropy is very secure on its own. IIRC Bitcoin's 256 bit ECDSA signatures also have 128 bit entropy.

One scenario I imagine is if you split your seed into three to store as 2 of 3 factors of authentication, in case of 24 words, attacker would have to crack more words if they get their hands on one copy versus if you were using 12 words.

But then again. If you use a passphrase to secure your seed, then 12 words should be more than enough even taking my above point into consideration.

I myself use 24 words because I am simply not knowledgeable enough in cryptography and don't wanna leave anything up for any potential future risks. I am all for greater security even if it comes with a slight inconvenience.

[NotATether]

12 words are secure enough on their own. But keep in mind, 24 words provide 256 bit entropy (vs 128 bit entropy that 12 words provide). I imagine that plays a role in 24 words being more preferred, because greater entropy is always better right? But like you mentioned that comes with greater inconvenience.

I wonder if there's a reason behind that other than just 256 > 128 because 128 bit entropy is very secure on its own. IIRC Bitcoin's 256 bit ECDSA signatures also have 128 bit entropy.

Hardware wallets use them mainly. Since they intend these to be written down, 24 words provides greater protection in the case some of the words are accidentally exposed without the users' knowledge. The entropy space would still be far to large to attempt any kind of brute-forcing.

I myself use 24 words because I am simply not knowledgeable enough in cryptography and don't wanna leave anything up for any potential future risks. I am all for greater security even if it comes with a slight inconvenience.

You'd be equally safe using 12 words because the entropy space that has to be searched is 2^128. Anything under that is prone to brute-forcing.

And using a random password for the seed multiplies the search space with the password's entropy. Dictionary-based passwords don't really provide any additional protection because everyone has tools for this.

[pooya87]

Hardware wallets use them mainly. Since they intend these to be written down, 24 words provides greater protection in the case some of the words are accidentally exposed without the users' knowledge. The entropy space would still be far to large to attempt any kind of brute-forcing.

If equal number of words were missing from a mnemonic (eg. missing 3 words) then brute forcing a 24-word mnemonic is a lot easier than brute forcing a 12-word mnemonic because of a much bigger checksum used by 256-bit entropy that provides less collision ergo it requires a lot less full checks.

[NotATether]

Hardware wallets use them mainly. Since they intend these to be written down, 24 words provides greater protection in the case some of the words are accidentally exposed without the users' knowledge. The entropy space would still be far to large to attempt any kind of brute-forcing.

If equal number of words were missing from a mnemonic (eg. missing 3 words) then brute forcing a 24-word mnemonic is a lot easier than brute forcing a 12-word mnemonic because of a much bigger checksum used by 256-bit entropy that provides less collision ergo it requires a lot less full checks.

I don't quite understand the underlined part. Are you saying that brute forcing is easier when multiples of 3 words are revealed than other numbers of words?

I'm confused by how this would work in practice since each additional three words adds another checksum bit, but revelation of three words from my intuition still requires you to get all the checksum bits because you're running SHA256 once in both cases anyway.

[pooya87]

Hardware wallets use them mainly. Since they intend these to be written down, 24 words provides greater protection in the case some of the words are accidentally exposed without the users' knowledge. The entropy space would still be far to large to attempt any kind of brute-forcing.

If equal number of words were missing from a mnemonic (eg. missing 3 words) then brute forcing a 24-word mnemonic is a lot easier than brute forcing a 12-word mnemonic because of a much bigger checksum used by 256-bit entropy that provides less collision ergo it requires a lot less full checks.

I don't quite understand the underlined part. Are you saying that brute forcing is easier when multiples of 3 words are revealed than other numbers of words?

I'm confused by how this would work in practice since each additional three words adds another checksum bit, but revelation of three words from my intuition still requires you to get all the checksum bits because you're running SHA256 once in both cases anyway.

3 was just a random example. It means if from a 12 word mnemonic you were missing 3 and had 9 of the remaining words or from a 24 word mnemonic you were missing 3 words and had 21 remaining words it would be a lot faster to find the 3 missing words of 24-word mnemonic.

This behavior is because 12 words use only 4 bits of entropy while 24 use 8 bits. Chance of finding collision is less in the later so you end up having to derive less keys to check so it is faster.

[BlackHatCoiner]

Technically, yes... it does offer "more" security... but it's like saying that it's more difficult to get to Pluto than to Jupiter because it's further away... they're both a looooooooong way away and very difficult to get to... but one is technically further away than the other. Same with 128bit vs. 256bit entropy... the latter is theoretically "harder" to bruteforce than the other by sheer fact that it's so much bigger, but the former is already "impossible" to bruteforce anyway.

But for an attacker, they are both stupidly hard to brute force. If a person can't go to space you don't care if it's Pluto or Jupiter. It doesn't make anything harder for the attacker. Actually 24 words makes it harder for the user, because of possible mistakes.

Because attempting to memorise 12 words and keep them memorised over a long period of time is a recipe for disaster. There are countless threads on these forums where people struggle to remember all sorts of things (wallet passwords, words from mnemonics, what software they had installed, when they did things etc)

I fully agree, I just didn't mention about the back up. Of course you'll have to write down your words too, but trying to memorize them wouldn't be that bad. For example, if you know the first 9 words, but have lost your paper for a million different reasons, you can use a tool to get your mnemonic back.

To be technically compliant with BIP39... they should be 12, 15, 18, 21 or 24 words. The BIP39 specification says the initial entropy needs to be between 128 and 256 bits.

I saw that iancoleman allows you to generate 3, 6 or 9 words and I thought that it is right. He does warn that it may be guessed by an attacker, though.

One scenario I imagine is if you split your seed into three to store as 2 of 3 factors of authentication, in case of 24 words, attacker would have to crack more words if they get their hands on one copy versus if you were using 12 words.

IMO, you should never store anything halved or not completed. Even if someone stoles it, it is your problem to think where to hide it. Whoever finds it must have access and he must not need another factor of authentication to spend the funds.

If equal number of words were missing from a mnemonic (eg. missing 3 words) then brute forcing a 24-word mnemonic is a lot easier than brute forcing a 12-word mnemonic because of a much bigger checksum used by 256-bit entropy that provides less collision ergo it requires a lot less full checks.

I don't get that, why should all seeds have a valid checksum? We generate a random number and then we put a valid checksum, but for what reason?

[casperBGD]

Technically, yes... it does offer "more" security... but it's like saying that it's more difficult to get to Pluto than to Jupiter because it's further away... they're both a looooooooong way away and very difficult to get to... but one is technically further away than the other. Same with 128bit vs. 256bit entropy... the latter is theoretically "harder" to bruteforce than the other by sheer fact that it's so much bigger, but the former is already "impossible" to bruteforce anyway.

But for an attacker, they are both stupidly hard to brute force. If a person can't go to space you don't care if it's Pluto or Jupiter. It doesn't make anything harder for the attacker. Actually 24 words makes it harder for the user, because of possible mistakes.

yeah, and it is much harder if you have more than one wallet, it is hardly possible to memorize few mnemonic phrases for different wallets
for me, that is one of best ways for security, wallet diversification, you use several wallets, and set limit per wallet (amount that is maximal for that particular wallet)

in that case, it is really hard to be hacked for all funds, you can lose part of it, but risk is greatly decreased for total loss

of course, depend on your wallet security, is it web, mobile, browser extension, exchange, hardware wallet or proprietary wallet, you set limit that is useful and you are comfortable with it

[ranochigo]

I don't get that, why should all seeds have a valid checksum? We generate a random number and then we put a valid checksum, but for what reason?

Not needed. Most wallets, like Electrum, actually doesn't care about the checksum (other than the fact that it'll put a small warning) but it won't prohibit the user from continuing. It'll be good to enforce a valid checksum as it'll make missing phrases "slightly" easier to bruteforce and allow the user to identify if their phrases are entered wrongly. Of course, as mentioned, the longer seed phrases has a longer checksum length and thus bring about better error identification.

One scenario I imagine is if you split your seed into three to store as 2 of 3 factors of authentication, in case of 24 words, attacker would have to crack more words if they get their hands on one copy versus if you were using 12 words.

That isn't really 2 of 3 FA since you need the entire seed to use the keys so it'll be theoretically more like 3 of 3.

-snip-

Wow, that's pretty interesting.

[pooya87]

If equal number of words were missing from a mnemonic (eg. missing 3 words) then brute forcing a 24-word mnemonic is a lot easier than brute forcing a 12-word mnemonic because of a much bigger checksum used by 256-bit entropy that provides less collision ergo it requires a lot less full checks.

I don't get that, why should all seeds have a valid checksum? We generate a random number and then we put a valid checksum, but for what reason?

Checksums are always a good and quick way for the application to figure out if the user entered whatever correctly. Whether it is a private key, address, mnemonic or an encrypted string. We also want reproduciblity, if we ignore the checksum and user enters something wrong they can not reproduce the same wallet as they had before.

[LoyceV]

One scenario I imagine is if you split your seed into three to store as 2 of 3 factors of authentication, in case of 24 words, attacker would have to crack more words if they get their hands on one copy versus if you were using 12 words.

That isn't really 2 of 3 FA since you need the entire seed to use the keys so it'll be theoretically more like 3 of 3.

IanColeman's Mnemonic Converter shows how this works:
Sample Mnemonic:

Code:

rule rent thrive soap worry issue east stomach suffer target flame annual unaware wool banner pole flavor limb divorce volume shell they gesture chronic

BIP39 Split Mnemonic:

Code:

Card 1: rule XXXX thrive soap XXXX XXXX east stomach suffer target flame XXXX XXXX XXXX XXXX pole flavor limb divorce volume XXXX they gesture chronic
Card 2: XXXX rent thrive soap worry issue XXXX stomach suffer XXXX XXXX annual unaware wool banner pole XXXX limb divorce volume shell XXXX XXXX XXXX
Card 3: rule rent XXXX XXXX worry issue east XXXX XXXX target flame annual unaware wool banner XXXX flavor XXXX XXXX XXXX shell they gesture chronic

It says: "Time to hack with only one card: 3830854 years".
A thief will need at least 2 cards to restore it. And so do you.

You need 2 out of 3 cards to restore the seed. If you'd do the same with 12 words, it shows: "Time to hack with only one card: 109 seconds".

[witcher_sense]

I don't get that, why should all seeds have a valid checksum? We generate a random number and then we put a valid checksum, but for what reason?

Checksum serves as a detector of data integrity, without a checksum, every small change in our seed phrase would go unnoticed, and we would not be able to assert with certainty that the current seed phrase corresponds to the one we generated earlier. Imagine you made a mistake during the process of writing down your seed. You now got several copies of your seed that are slightly different from each other. Which one is correct? Which one did you use to generate your wallet? You would have no choice but to check them all, one by one.

[BlackHatCoiner]

Checksums are always a good and quick way for the application to figure out if the user entered whatever correctly. Whether it is a private key, address, mnemonic or an encrypted string. We also want reproduciblity, if we ignore the checksum and user enters something wrong they can not reproduce the same wallet as they had before.

Yes, but if we're talking about mnemonics I don't think that it matters that much. You said that with 24 words it's easier to brute force it because of the checksum. If you get to the point of brute forcing, why should you choose the mnemonic way in the first place?

BPIP39 Split Mnemonic

I couldn't stand not to quote this mistake. I've done it so many times.  

Which one did you use to generate your wallet? You would have no choice but to check them all, one by one.

This way, we're making the attacker's brute forcing easier too, not just ours. As far as I've seen, checksums on mnemonics are useful only on brute forcing, because on seed validation you must have written the right words. Even if you've written a wrong word or anything else, how exactly would you get your funds back? Where is checksum going to help?

[witcher_sense]

This way, we're making the attacker's brute forcing easier too, not just ours. As far as I've seen, checksums on mnemonics are useful only on brute forcing, because on seed validation you must have written the right words. Even if you've made a mistake, how exactly would you get your funds back?

Checksums are not preventing us from being hacked by malicious actors, they are meant to make users's life more comfortable. We slightly reduce security by adding additional hints for the hacker (checksum), at the same time the risk of losing funds due to an incorrectly made backup is also greatly reduced, the checksum serves to check the integrity of our backup. This is an example of how convenience and security can balance to achieve the most acceptable outcome.

[ABCbits]

The answer is simple, it's because people feel more secure or other ridiculous reason (e.g. computer hardware will grow faster than ever).

Which one did you use to generate your wallet? You would have no choice but to check them all, one by one.

This way, we're making the attacker's brute forcing easier too, not just ours. As far as I've seen, checksums on mnemonics are useful only on brute forcing, because on seed validation you must have written the right words. Even if you've written a wrong word or anything else, how exactly would you get your funds back? Where is checksum going to help?

Checksum help people to recover mnemonic far faster with very few missing words (as long as it's not last word). You don't need to generate many things (seed, private key, public key & address) to check whether you generate correct mnemonic.

Besides, if attacker already know some words of your mnemonic, that means the attacker already breach your device/home & you have bigger problem to worry about.

[bob123]

IanColeman's Mnemonic Converter shows how this works:
Sample Mnemonic:

Code:

rule rent thrive soap worry issue east stomach suffer target flame annual unaware wool banner pole flavor limb divorce volume shell they gesture chronic

BIP39 Split Mnemonic:

Code:

Card 1: rule XXXX thrive soap XXXX XXXX east stomach suffer target flame XXXX XXXX XXXX XXXX pole flavor limb divorce volume XXXX they gesture chronic
Card 2: XXXX rent thrive soap worry issue XXXX stomach suffer XXXX XXXX annual unaware wool banner pole XXXX limb divorce volume shell XXXX XXXX XXXX
Card 3: rule rent XXXX XXXX worry issue east XXXX XXXX target flame annual unaware wool banner XXXX flavor XXXX XXXX XXXX shell they gesture chronic

It says: "Time to hack with only one card: 3830854 years".
A thief will need at least 2 cards to restore it. And so do you.

You need 2 out of 3 cards to restore the seed. If you'd do the same with 12 words, it shows: "Time to hack with only one card: 109 seconds".

This is an extremely naive approach and shouldn't be used ever. Regardless of whether 12 or 24 word mnemonics are used.
A secret sharing scheme where information is leaked, is not a good scheme at all and should be avoided.

Any other proper scheme (e.g. by using the the chinese remainder theorem or Sharmir's scheme), a person with n-1 shares (where n is the number of required shares) won't learn anything about the secret.

I do understand that this was just for illustration. But never underestimate the ignorance of newbies who might exactly follow this approach after reading it.

So.. for anyone reading this: Don't do the above. If you want to split your mnemonic code (or any other sensitive information), use a proper secret sharing scheme!

[o_e_l_e_o]

If you get to the point of brute forcing, why should you choose the mnemonic way in the first place?

Nobody is trying to brute force wallets by coming up with random combinations of 256 bits and then turning them in to seed phrases, which is essentially just creating endless numbers of new wallets and checking for a collision. Or at least if they are, then they are idiots who are completely wasting their time. The reason people talk about brute forcing seed phrases is because that is generally the format in which people back up their wallets, and so that is generally the format in which we end up with incomplete back ups or partially compromised back ups which require brute forcing.

Even if you've written a wrong word or anything else, how exactly would you get your funds back? Where is checksum going to help?

Let's say I am missing 1 word but I haven't used a checksum. For each of the 2048 possibilities, I have to insert the possible word, run through 2048 rounds of PBKDF2, various rounds of HMAC-SHA512 as dictated by the derivation path to reach the relevant private key, elliptic curve multiplication to derive the public key, and then SHA256, RIPEMD-160, and another two SHA256s to find the address, and then look the address up to check for balance.

Now let's say I am missing 1 word out of a 24 word seed phrase, and I have used a checksum. Out of the 2048 possible words, 2040 will not produce the correct checksum, and so can be immediately discarded. Therefore I only have to perform all the above operations 8 times rather than 2048 times.

The more words you are missing, the large the disparity between checksum and no checksum.

[BlackHatCoiner]

Now let's say I am missing 1 word out of a 24 word seed phrase, and I have used a checksum. Out of the 2048 possible words, 2040 will not produce the correct checksum, and so can be immediately discarded. Therefore I only have to perform all the above operations 8 times rather than 2048 times.

Wait, why 2040 words won't produce the same checksum and how will I know which 8 words are the ones I want?

[o_e_l_e_o]

Wait, why 2040 words won't produce the same checksum and how will I know which 8 words are the ones I want?

For a 24 word phrase, there is 8 bits of checksum. 8 bits is 256 different combinations. So for any specific 8 bits, only 1 in every 256 words will produce a matching checksum. If we take 1 in every 256 words, then for 2048 words there will be 8 possibilities.

We don't know which 8 words are the ones you want. What you do is replace your missing word with each word of the possible 2048 words and calculate the checksum. If the checksum does not match, then you can discard that word. For the 8 words which do producing a matching checksum, you run through the process of PBKDF2, HMAC-SHA512, etc. as I outlined above.

Without a checksum, you would have to run through this lengthy process of PBKDF2, HMAC-SHA512, etc. for all 2048 words.