<p>There is a lot to unwrap here. I'll go over the points that need addressing, most important first:</p>
<h2>Don't try to invent your own cryptographic scheme</h2>
<p>If you read the manual to your wallet, it most certainly says to generate a <strong>random</strong> mnemonic, and explains why you might (and might not) want to use a passphrase. The manufacturer/developer knows very well why they tell you this, and unless you are an expert (and probably even if you are), deviating from these instructions means your security will range from suboptimal to nonexistent.</p>
<h2>Security level</h2>
<p>3,54 × 10<sup>19</sup> works out to be just under 2<sup>65</sup>, which means you're only getting 65 bits of security at best. A 12-word seed phrase has 128 bits of security, which is the same as the security level of the Bitcoin protocol itself. If your scheme doesn't achieve at least that, your security level is degraded, and 65 bits is low enough to be breakable in practice with enough computing power.</p>
<h2>Brainwallets</h2>
<p>65 bits of security assumes that the 8-character passphrase was generated randomly, i.e. something like <code>by7rkf0a</code>, <code>2xp5u7wf</code> or <code>63tf3sv5</code>. But that's not what most people would like to use as a passphrase. In a more realistic scenario they'd use e.g. a fairly common word (assume top 10,000 English words) and three random digits, reducing the security level to just 47 bits, which could be brute forced in a reasonable amount of time on a regular PC.</p>
<p>A wallet generated from a human input is called a brainwallet, and much has been said and written on why brainwallets are bad. If you want to learn more, <a href="https://bitcointalk.org/index.php?topic=311000.msg3345309#msg3345309" rel="noreferrer">this 2013 BitcoinTalk post</a> by Greg Maxwell is an excellent starting point.</p>
<h2>Checksum</h2>
<p>Small detail: the last word of a 12-word seed phrase contains checksum information. It just so happens that &quot;true kid&quot; repeated six times is a valid seed phrase, but this only works with around 1 out of 16 pairs of words.</p>

CC BY-SA 4.0
2023-01-18T14:53:34.923Z
About the security level, I used a very small/simple passphrase example just to illustrate the number of combinations can quickly get huge. Although you're right it's not really random.
room101
CC BY-SA 4.0
2023-01-18T06:44:17.247Z
2023-01-18T06:44:17.247Z
Vojtěch Strnad
<p>Very bad idea.  Relying on a number that 'seems quite large to me' is insecure.</p>
<p>There were several recent cases of brute forcing vanity addresses, or mnemonics that were generated using a insecure pseudo random generator with a random 32 bit seed (resulting in 2^32 possible results).</p>
<p>If passphrase is human-generated, it has less entropy than you compute. If it is proper random, why not go with the regular BIP39 scheme?</p>

CC BY-SA 4.0
2023-01-18T14:55:26.750Z
It's not just relying on a number that "seems" big, but also on the fact that an attacker (apparently) wouldn't have a starting point. I'd really like to be told how this could be attacked in practice.
room101
CC BY-SA 4.0
2023-01-20T23:27:37.757Z
The attack here is based on the probability of attacker trying simple keys rather than BIP39 safe keys, the overall fact is that this results in the attacker needing to try LESS combinations -> keys to cover the attack (even though that is not likely in itself) than they would if you had just used the normal specification. There is something to say about brain wallets, and adding your own highly controlled entropy to your key in a valid way that you fully understand and can remember. That being said, it is likely that this will result in survivorship bias. The priority is scalable standards
Poseidon
CC BY-SA 4.0
2023-01-24T21:50:58.250Z
@Poseidon your comment was the only reply that had any value. The rest either said "don't do it" or clinged  to the specific numbers I mentioned, which were purposely weak.
room101
CC BY-SA 4.0
2023-01-24T22:12:18.583Z
As far as I can tell, and Im no expert, there are a lot of things to consider if making a simpler more memorable mnemonic key. For one using the BIP32 specification is not a good idea IN THIS CASE because it just leads any attacker closer to a specification for which combinations to try. You would need to create your own word list, make sure they are ordered fundamentally differently than the BIP32 sheet, maintain that order in some way that you wont lose, then generate a memorable mnemonic from the list, you can even add a pass as bytes to the byte string before hashing it to get the pvtkey.
Poseidon
CC BY-SA 4.0
2023-01-24T22:13:16.123Z
Now please dont do this with real coins, this is just my own theories for how it can be done it is 100% UNTESTED. That being said, I do think something like this could be valuable but it needs to have some heavy standardization which is hard for something meant to be manipulated by each user differently.
Poseidon
CC BY-SA 4.0
2023-01-24T22:17:08.947Z
In general I believe the complexity of managing personalized keys is the reason we stick to BIP32, makes it simpler for anyone to make a key regardless if they understand what is happening in the backend when they do it
Poseidon
CC BY-SA 4.0
2023-01-18T10:54:11.460Z
2023-01-18T10:54:11.460Z
OptOut
<p>Suppose someone chooses to use a seed (mnemonic) that is easy to memorise, like <code>true kid true kid true kid true kid true kid true kid</code> - using a passphrase, of course.</p>
<p>The benefit is clear: he'd only have to memorise 2 words and the passphrase (and he already memorises his current passphrase). If the person forgets what were the 2 words, he can still easily brute force it, provided he remembers the passphrase and that there were 2 alternating words.</p>
<p>Now, how unsafe/safe is that? I can't really imagine there's someone trying to brute force passphrases of simplistic seeds out of nowhere. If my math is right, 2 alternating words mean 2048 * 2047 * 3 possible combinations (1st word, 2nd word and 12/18/24 length).</p>
<p>Considering a relatively short 8 alphanumeric character passphrase, the number of possibilities is 2048 * 2047 * 3 * 36<sup>8</sup> = 3,54 × 10<sup>19</sup>, which is a huge number. For comparison, it cost this guy <a href="https://medium.com/@johncantrell97/how-i-checked-over-1-trillion-mnemonics-in-30-hours-to-win-a-bitcoin-635fe051a752" rel="nofollow noreferrer">~425 USD and 30 hours to brute force 1 trillion seeds</a>, and not only he knew there was a prize, but also had an address to look for.</p>
<p>Are the any flaws in these thoughts? Any pattern in the seed inner workings that could shorten the brute force job?</p>
<p>Edit: if you can, please specify a theoretical scenario in which an attacker could attempt to steal funds.</p>

CC BY-SA 4.0
2023-01-18T11:55:16.143Z
Presumably you would be doing this in order to remember the seed and not having to write it down. In that case the passphrase is going to be something memorable too? If you need to write it down then why not write down the whole thing? So the math doesn’t check out, especially the 36^8 part because this is not a random string.
Mike D
CC BY-SA 4.0
2023-01-18T14:52:14.590Z
The passphrase is already memorized and being used with a written seed.
room101
CC BY-SA 4.0
2023-01-18T16:28:38.120Z
@user253751 but either that was a single private key (no password or anything) or a seed without passphrase, right?
room101
<bip32-hd-wallets><mnemonic-seed><hacking><safety><brain-wallet>
How (un)safe is it to use non-random seed words?
room101
# How (un)safe is it to use non-random seed words?

(Asked by: username_0 on 2023-01-17)

Suppose someone chooses to use a seed (mnemonic) that is easy to memorise, like `true kid true kid true kid true kid true kid true kid` - using a passphrase, of course.

The benefit is clear: he'd only have to memorise 2 words and the passphrase (and he already memorises his current passphrase). If the person forgets what were the 2 words, he can still easily brute force it, provided he remembers the passphrase and that there were 2 alternating words.

Now, how unsafe/safe is that? I can't really imagine there's someone trying to brute force passphrases of simplistic seeds out of nowhere. If my math is right, 2 alternating words mean 2048 \* 2047 \* 3 possible combinations (1st word, 2nd word and 12/18/24 length).

Considering a relatively short 8 alphanumeric character passphrase, the number of possibilities is 2048 \* 2047 \* 3 \* 368 = 3,54 × 1019, which is a huge number. For comparison, it cost this guy [~425 USD and 30 hours to brute force 1 trillion seeds](https://medium.com/@johncantrell97/how-i-checked-over-1-trillion-mnemonics-in-30-hours-to-win-a-bitcoin-635fe051a752), and not only he knew there was a prize, but also had an address to look for.

Are the any flaws in these thoughts? Any pattern in the seed inner workings that could shorten the brute force job?

Edit: if you can, please specify a theoretical scenario in which an attacker could attempt to steal funds.

**Tags:** bip32-hd-wallets, mnemonic-seed, hacking, safety, brain-wallet

> **Comments:**
> **username_1**: Presumably you would be doing this in order to remember the seed and not having to write it down. In that case the passphrase is going to be something memorable too? If you need to write it down then why not write down the whole thing? So the math doesn’t check out, especially the 36^8 part because this is not a random string.  
> **username_0**: The passphrase is already memorized and being used with a written seed.  
> **username_0**: @user253751 but either that was a single private key (no password or anything) or a seed without passphrase, right?  

---

## 2 answers

### Answer by username_2 on 2023-01-18. Score: 7

There is a lot to unwrap here. I'll go over the points that need addressing, most important first:

## Don't try to invent your own cryptographic scheme

If you read the manual to your wallet, it most certainly says to generate a **random** mnemonic, and explains why you might (and might not) want to use a passphrase. The manufacturer/developer knows very well why they tell you this, and unless you are an expert (and probably even if you are), deviating from these instructions means your security will range from suboptimal to nonexistent.

## Security level

3,54 × 1019 works out to be just under 265, which means you're only getting 65 bits of security at best. A 12-word seed phrase has 128 bits of security, which is the same as the security level of the Bitcoin protocol itself. If your scheme doesn't achieve at least that, your security level is degraded, and 65 bits is low enough to be breakable in practice with enough computing power.

## Brainwallets

65 bits of security assumes that the 8-character passphrase was generated randomly, i.e. something like `by7rkf0a`, `2xp5u7wf` or `63tf3sv5`. But that's not what most people would like to use as a passphrase. In a more realistic scenario they'd use e.g. a fairly common word (assume top 10,000 English words) and three random digits, reducing the security level to just 47 bits, which could be brute forced in a reasonable amount of time on a regular PC.

A wallet generated from a human input is called a brainwallet, and much has been said and written on why brainwallets are bad. If you want to learn more, [this 2013 BitcoinTalk post](https://bitcointalk.org/index.php?topic=311000.msg3345309#msg3345309) by Greg Maxwell is an excellent starting point.

## Checksum

Small detail: the last word of a 12-word seed phrase contains checksum information. It just so happens that "true kid" repeated six times is a valid seed phrase, but this only works with around 1 out of 16 pairs of words.

> **Comments:**
> **username_0**: About the security level, I used a very small/simple passphrase example just to illustrate the number of combinations can quickly get huge. Although you're right it's not really random.  

---

### Answer by username_3 on 2023-01-18. Score: 1

Very bad idea. Relying on a number that 'seems quite large to me' is insecure.

There were several recent cases of brute forcing vanity addresses, or mnemonics that were generated using a insecure pseudo random generator with a random 32 bit seed (resulting in 2^32 possible results).

If passphrase is human-generated, it has less entropy than you compute. If it is proper random, why not go with the regular BIP39 scheme?

> **Comments:**
> **username_0**: It's not just relying on a number that "seems" big, but also on the fact that an attacker (apparently) wouldn't have a starting point. I'd really like to be told how this could be attacked in practice.  
> **username_4**: The attack here is based on the probability of attacker trying simple keys rather than BIP39 safe keys, the overall fact is that this results in the attacker needing to try LESS combinations -> keys to cover the attack (even though that is not likely in itself) than they would if you had just used the normal specification. There is something to say about brain wallets, and adding your own highly controlled entropy to your key in a valid way that you fully understand and can remember. That being said, it is likely that this will result in survivorship bias. The priority is scalable standards  
> **username_0**: @username_4 your comment was the only reply that had any value. The rest either said "don't do it" or clinged  to the specific numbers I mentioned, which were purposely weak.  
> **username_4**: As far as I can tell, and Im no expert, there are a lot of things to consider if making a simpler more memorable mnemonic key. For one using the BIP32 specification is not a good idea IN THIS CASE because it just leads any attacker closer to a specification for which combinations to try. You would need to create your own word list, make sure they are ordered fundamentally differently than the BIP32 sheet, maintain that order in some way that you wont lose, then generate a memorable mnemonic from the list, you can even add a pass as bytes to the byte string before hashing it to get the pvtkey.  
> **username_4**: Now please dont do this with real coins, this is just my own theories for how it can be done it is 100% UNTESTED. That being said, I do think something like this could be valuable but it needs to have some heavy standardization which is hard for something meant to be manipulated by each user differently.  
> **username_4**: In general I believe the complexity of managing personalized keys is the reason we stick to BIP32, makes it simpler for anyone to make a key regardless if they understand what is happening in the backend when they do it  

---

