Topic: Why 24 words? (Read 537 times)

It's explained nicely in this post:
https://www.reddit.com/r/TREZOR/comments/9tfl38/trezor_t_24_word_seed/

The entire command is
-t256 generates a 24-word recovery phrase.

Someone else pointed out that you can generate your seed on a Ledger hardware wallet or another hardware wallet that supports 24-words seeds, and than import that seed into your Trezor.

It generates 12 words by default... but as I understand it, you can override that and select 24 words if you want, but it requires using the "trezorctl" commandline tools

In fact both devices are able to use 12, 18 or 24 word seeds.


source: https://wiki.trezor.io/Recovery_seed#Recovery_seed_and_Trezor

The Trezor Model T generates 12-word seed phrase.

Keep in mind that the number of valid checksums with different combinations are an estimate because we are talking about collision and it can technically be between 0 collisions and maximum possible ones meaning 2048 with 1 missing word.
Probabilistically we say with 1 missing in 24 words there can be 8 valid combinations on average.

Example:
Only 5 are valid here:
While there are 9 valid combinations here:
And 13 here:

With 12 words:
135:
130:
128

You really, really don't want to do that!!  Have a good read about creating/using Shamir backup if you want to spread your seed words around to add security!  Its very easy to generate Shamir Backup SEED using my Trezors.

I understood how it works. Thank you. On 12 words I guess that you have 4 bits with 16 different combinations. If we take 1 in every 16 words, we end up with... Oh.. 128 possibilities. This was what pooya87 trying to say. Brute forcing with 24 words is 128/16=8 times faster than with 12 words.

Even if all these are true, I still have my doubts that I'll ever use this in the future. Once you write down your mnemonic, you only have one job. Do it right.

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.

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

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.

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.

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!

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


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.

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.

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?

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

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 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.

IanColeman's Mnemonic Converter shows how this works:
Sample Mnemonic:
BIP39 Split Mnemonic:
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".

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.

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.
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.


Wow, that's pretty interesting.

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

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.

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.

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.

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.

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?

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.

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.

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.

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.


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.

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.

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.

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.


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.

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.