24 words plus salt

[jubalix]

So I just feel safer with 24 words plus a salt, I have also considered 48 + salt, and thus use console

make_seed(256)

or

make_seed(512)

then make a new wallet and used that seed, and chose option my for my own aditional word.

Is there any risk in compatibility or attack vectors by doing this?

Eg it somehow weakens the 24 words becuase of a "jank issue" or any issue in adding the salt and getting the addresses? or creating malformed addresses, or private keys or MPrivK's

Part 2
I did notice that using BIP 39 with a salt via sparrow and colemanns, then importing into electrum, I could get the same addresses, but electurm wont dump the seed, but you can dump the MPrivK, but that MPrivK is different to the one you see in colemans even though the erived addresses are the same and private keys for each address are the same.

This suggests that the derivation to the addresses from the MPrivK is different in electrum....or am I missing something.

[hosemary]

So I just feel safer with 24 words plus a salt, I have also considered 48 + salt, and thus use console

Salt? Do you mean passphrase?

Note that the additional words or characters that are added to the seed phrase are called passphrase, not salt.
The salt in electrum is "electrum + <passphrase>".

Is there any risk in compatibility or attack vectors by doing this?

Assuming your device is safe and is not infected with any malwares, it's fine.
Just note that the seed phrase generated by electrum is not BIP39.

I did notice that using BIP 39 with a salt via sparrow and colemanns, then importing into electrum, I could get the same addresses, but electurm wont dump the seed, but you can dump the MPrivK, but that MPrivK is different to the one you see in colemans even though the erived addresses are the same and private keys for each address are the same.

See "Account Extended Private Key" in iancoleman. That should be same as your "xprv" in electrum.


It may be worth mentioning that you don't really increase your security with having more than 12 words.
A 12 word seed phrase provides the same security as a bitcoin private key.

[jubalix]

See "Account Extended Private Key" in iancoleman. That should be same as your "xprv" in electrum.


It may be worth mentioning that you don't really increase your security with having more than 12 words.
A 12 word seed phrase provides the same security as a bitcoin private key.

Thanks,

I see your point - with the BTC priv key security - it comes from my view that the search space

if you could run through known words you know somewhere they must map.

Using 24 words + salt (passphrase), means it's going to map somwhere a much, much larger keyspace.

So it's like where are you going to look first in any given keyspace.

Eg the edges of the keyspace will all have been attacked, eg all repititons of the same word will have been trialed allready, which imples on a (large) subjset of keys in he possible keyspace are truly protected, and that's linked to haveing a real rng.

[nc50lc]

make_seed(256)

Looks good and will produce the correct number of words but Electrum uses a different method on generating seed phrase than BIP39.
So the entropy should follow the electrum default of 132-bit for 12 words which should be make_seed(264) for 24 words and make_seed(528) for 48 words.
Default bits (12-words): github.com/spesmilo/electrum/blob/master/electrum/mnemonic.py#L205-L206

This suggests that the derivation to the addresses from the MPrivK is different in electrum....or am I missing something.

For BIP39, it's based from what you selected during BIP39 seed restore.
The difference in the extended public/private key is just different encoding which ca be converted in the console via convert_xkey() command.
e.g.:

Code:

convert_xkey(xkey="xprv...GYoys",xtype="standard")

Current available xtypes are: "standard", "p2wpkh" and "p2wpkh-p2sh"

[jubalix]

make_seed(256)

Looks good and will produce the correct number of words but Electrum uses a different method on generating seed phrase than BIP39.
So the entropy should follow the electrum default of 132-bit for 12 words which should be make_seed(264) for 24 words and make_seed(528) for 48 words.
Default bits (12-words): github.com/spesmilo/electrum/blob/master/electrum/mnemonic.py#L205-L206

This suggests that the derivation to the addresses from the MPrivK is different in electrum....or am I missing something.

For BIP39, it's based from what you selected during BIP39 seed restore.
The difference in the extended public/private key is just different encoding which ca be converted in the console via convert_xkey() command.
e.g.:

Code:

convert_xkey(xkey="xprv...GYoys",xtype="standard")

Current available xtypes are: "standard", "p2wpkh" and "p2wpkh-p2sh"

wait wait ---- so I was in error it shoud be make_seed(264)!!!!!, so what did I produe with make_seed(256)?

[hosemary]

wait wait ---- so I was in error it shoud be make_seed(264)!!!!!, so what did I produe with make_seed(256)?

Both make_seed(256) and make_seed(264) generate a 24 word seed phrase for you and provide you more than enough security.
There's nothing to worry about here.

Using make_seed(256), you generate a seed phrase with 256 bits of entropy and using make_seed(264), you generate a seed phrase with 264 bits of entropy.

[jubalix]

wait wait ---- so I was in error it shoud be make_seed(264)!!!!!, so what did I produe with make_seed(256)?

Both make_seed(256) and make_seed(264) generate a 24 word seed phrase for you and provide you more than enough security.
There's nothing to worry about here.

Using make_seed(256), you generate a seed phrase with 256 bits of entropy and using make_seed(264), you generate a seed phrase with 264 bits of entropy.

but did i stuff it up, becuase electrum uses 8 bits for the checksum so 256 bits is not standard, so it should be 264 to be standard. eg 256 + 8 bits

I am kinda surprised that a 256 would not auto add on 8 bits for a checks sum but apprently the code base does not so I should call a 264? make_seed to be standard???

I may be missing something here,

[hosemary]

but did i stuff it up, becuase electrum uses 8 bits for the checksum so 256 bits is not standard, so it should be 264 to be standard. eg 256 + 8 bits

This isn't how electrum generates a seed phrase. You are confusing electrum seed phrase with BIP39 seed phrase.
In a 24 word BIP39 seed phrase, the first 256 bits are generated randomly and the last 8 bits are checksum, but in an electrum seed phrase, all bits are generated randomly.

For generating a 24 word seed phrase in electrum, you need 264 bits of entropy.
When you use make_seed(256) command, only 256 bits out of the 264 required bits are generated randomly.

[Cricktor]

OP, I've a feeling you're overcomplicating things. A wallet derived from 12 mnemonic recovery words is safe, there's not enough time and energy on this planet to crack 128bits or little more entropy.

When you add a mnemonic passphrase to get to your main wallet (decoy wallet possible without the additional mnemonic passphrase), you secure your wallet additionally if your mnemonic recovery words might get exposed for whatever reasons. This implies you never store and backup the mnemonic recovery words together with your additional mnemonic passphrase.

In my opinion what matters more for security of your wallet:
Do you verify everytime that your Electrum is genuine when you install or upgrade it?

Your mnemonic recovery details never touch an online device! No screenshots, no photos, just analog paper or stamping into fire resistant metal.

A hot software wallet isn't protected from malware or hacking. Use a decent hardware wallet properly or hot watch-only / cold offline wallet with your private keys to sign transaction that are created with the hot watch-only side. ("hot" means online, "cold" remains offline all the time)

Have you verified that you can successfully restore your wallet? (Do this in a secured offline environment; I recommend to boot a live Linux into RAM, install wallet software, remove all network connections to make it surely offline, test your recovery, if successful, you can turn of the computer and because all was in RAM there's no persistent data traces on storage media, unless you make horrible mistakes.

Do you have redundant and safe backups of all details required to successfully recover your wallet(s)? Preferably not in one place only to avoid a single point of failure in case a fire or other destructive elements desaster.

Have you documented all well enough, so that you're able in years from now to recover your wallet without having to remember anything (except for the location of your documentation and likely your backup storage places). Assume the worst, can you or your heirs still recover?


This is not exhaustive but the very basics to pay attention to if you're concerned of your wallet's security.

[nc50lc]

Looks good and will produce the correct number of words but Electrum uses a different method on generating seed phrase than BIP39.

wait wait ---- so I was in error it shoud be make_seed(264)!!!!!, so what did I produe with make_seed(256)?

Don't sweat it, I said "it's good".
The correction if for standardization in the command and so that Electrum wont have to do additional steps to increase the num_bits during seed generation.
The process is PRNG so it's as good as if you've set the correct size initially.

I am kinda surprised that a 256 would not auto add on 8 bits for a checks sum but apprently the code base does not so I should call a 264? make_seed to be standard???

I've also mentioned that it's generation is different than BIP39 (in the quote above)
It works like this: Electrum basically bruteforces an already complete set of words that should produce a desired "reserved number" when hashed.
And that reserved number isn't included to the seed phrase but calculated on the fly when the client needs to check the seed phrase for validity and script type to restore.

[BlackBoss_]

OP, I've a feeling you're overcomplicating things. A wallet derived from 12 mnemonic recovery words is safe, there's not enough time and energy on this planet to crack 128bits or little more entropy.

It's impossible to bruteforce Bitcoin wallets with 12 mnemonic seed words, and more impossible with 24 mnemonic seed words, so I don't know how 48 mnemonic seed words are needed.

From my knowledge, there is no Bitcoin wallets with 48 wallet mnemonic seed words.

There are some mnemonic seed word options and corresponding entropies.
https://learnmeabitcoin.com/technical/keys/hd-wallets/mnemonic-seed/
12 words: 128 bit
15 words: 160 bit
18 words: 192 bit
21 words: 224 bit
24 words: 256 bit

Lastly, the entropy should be between 128 and 256 bits, as that's enough to make it impossible for two people to generate the same entropy.

[hosemary]

From my knowledge, there is no Bitcoin wallets with 48 wallet mnemonic seed words.

Electrum allow you to generate seed phrase with any number of words.
To generate a 48 word seed phrase, all you need to do is go to electrum console and use make_seed(528) command.

12 words: 128 bit
15 words: 160 bit
18 words: 192 bit
21 words: 224 bit
24 words: 256 bit

These are entropies provided by BIP39 seed phrase.
For example, a 12 word electrum seed phrase provides 132 bits of entropy.

[jubalix]

OP, I've a feeling you're overcomplicating things. A wallet derived from 12 mnemonic recovery words is safe, there's not enough time and energy on this planet to crack 128bits or little more entropy.

All good points

-  did some back of the envelope calcs and 128 may fall in 10 - 16 years, note I said >MAY<. I dont see 256 (264) falling practically for ever or a really long time.

- I like to be ahead of any possible situation for a variety reason.

- Also conceptualy alot parts of actual key space is not safe key space so its not trully the whole space. I like to feel secure knowing I am much more deeply burried in the randomness.


This may be just me. but thats how I am.

[hosemary]

-  did some back of the envelope calcs and 128 may fall in 10 - 16 years, note I said >MAY<. I dont see 256 (264) falling practically for ever or a really long time.

If it's possible to crack a 12 word seed phrase one day, the attacker will be able to crack your private keys too and they won't need to try finding your seed phrase at all.
As I already said a bitcoin private key provides 128 bits of security which means that you can't have more security even if you generate a seed phrase with more than 12 words.

[jubalix]

-  did some back of the envelope calcs and 128 may fall in 10 - 16 years, note I said >MAY<. I dont see 256 (264) falling practically for ever or a really long time.

If it's possible to crack a 12 word seed phrase one day, the attacker will be able to crack your private keys too and they won't need to try finding your seed phrase at all.
As I already said a bitcoin private key provides 128 bits of security which means that you can't have more security even if you generate a seed phrase with more than 12 words.

I think the maths and atttack vectors do not quite work out the same.

The way  I see it is this

The 12 bit words map to a set of keys in 12 bit space
The 24 bit words map to a larger set of keys in 12 bit space than 12 bit words.

Now sure you could scan the block chain for all addresses with a balanaces and just have a go at it directly, but I think the 12 bitt words will go first, as everthing is known easier than the 24 and ptentially easier that deriving from the address.

[Cricktor]

I don't think your back of the envelope math is any valid. How do you want to find a particular entropy value in a search space of 2¹²⁸ in 10-16 years? Let's be generous and say, 100 years. Genuinely curious!

I'm assuming the challenge to find the correct 12 words of a BIP39 wallet, where you know the first derived public address of a standard derivation path. Other addresses of this wallet hold enough funds and you'll loose a lot if you just focus on one public address. So, we really want to get to know the correct sequence of 12 recovery words.

Search space is 2¹²⁸. Let's assume you only need to search on average half of it, i.e. search space now approx. 2¹²⁷.

BIP39 derivation involves converting a 128bit value to 12 words, because those have to be fed to 2048 rounds of PBKDF2 HMAC-SHA512 hashing, some further derivation to get to first public address of the wallet, which we luckily know.

Let's be generous and we have a computer that can check a billion entropy values per second.

2¹²⁷ is 170,141,183,460,469,231,731,687,303,715,884,105,728 possible values to check.

In a year we can check 365*24*3600*1,000,000,000 = 31,536,000,000,000,000 entropy values. But we're fortunate and have a billion of such computers!

How many years we'll have to search?
170,141,183,460,469,231,731,687,303,715,884,105,728 divided by (31,536,000,000,000,000 times 1,000,000,000) equals roughly 5,395,141,535,403 years... Yikes!

I surely made somewhere a mistake. Point me to it, please. Not sure if we have about 380 times the current age of the universe time, totally neglecting that we need also the energy to operate our one billion computers all that time.  

[jubalix]

make_seed(256)

Looks good and will produce the correct number of words but Electrum uses a different method on generating seed phrase than BIP39.
So the entropy should follow the electrum default of 132-bit for 12 words which should be make_seed(264) for 24 words and make_seed(528) for 48 words.
Default bits (12-words): github.com/spesmilo/electrum/blob/master/electrum/mnemonic.py#L205-L206

This suggests that the derivation to the addresses from the MPrivK is different in electrum....or am I missing something.

For BIP39, it's based from what you selected during BIP39 seed restore.
The difference in the extended public/private key is just different encoding which ca be converted in the console via convert_xkey() command.
e.g.:

Code:

convert_xkey(xkey="xprv...GYoys",xtype="standard")

Current available xtypes are: "standard", "p2wpkh" and "p2wpkh-p2sh"

wait wait ---- so I was in error it shoud be make_seed(264)!!!!!, so what did I produe with make_seed(256)?

Ok I checked the code I am ok
 num_bits = int(math.ceil(num_bits/bpw) * bpw)

will round up using the math.ceil function
Why Electrum uses ceil

Electrum calculates:
num_bits_rounded = ceil(num_bits / 11) * 11
Because every word stores exactly 11 bits, Electrum must round up to the next multiple of 11 so all bits can be encoded into whole words with no loss.

So for

num_bits = 256
256 / 11 = 23.27...
ceil(23.27) = 24
24 * 11 = 264 bits
Thus both make_seed(256) and make_seed(264) → 264 bits → 24 words.

So should be good

24 words is a secure as 24 words from either as function outputs the same

[nc50lc]

Ok I checked the code I am ok

Yep, I mentioned in a later reply that your initial command is good.
But I see that you've done extensive research to clear the remaining doubts since you somehow have to use the current seed phrase.

Reference and link (click the quote):

Don't sweat it, I said "it's good".
The correction if for standardization in the command and so that Electrum wont have to do additional steps to increase the num_bits during seed generation.

[jubalix]

Ok I checked the code I am ok

Yep, I mentioned in a later reply that your initial command is good.
But I see that you've done extensive research to clear the remaining doubts since you somehow have to use the current seed phrase.

Reference and link (click the quote):

Don't sweat it, I said "it's good".
The correction if for standardization in the command and so that Electrum wont have to do additional steps to increase the num_bits during seed generation.

yes you were correct thanks for the code ref,

made me look at the code and understand why. And it round up due to ceil and 256 was close nough to round up to 264