Custom parameter for mnemonic seed

[Sanglotslongs]

Hello,

I read this article about a guy that give away a partial mnemonic seed on twitter with 1 BTC reward. Every week he gave 1 word after another, so it become easier to crack.

And here an article about the bitcoin dev that cracked it :
https://medium.com/@johncantrell97/how-i-checked-over-1-trillion-mnemonics-in-30-hours-to-win-a-bitcoin-635fe051a752

When you read this article, you can see that John Cantrell made some hypothesis :

This means the derivation path is in the format m / 49' / coin_type’ / account’ / change / address_index.
Figuring out the derivation path was a huge risk for this project. I assumed that Alistair simply generated a new wallet and the only transaction made was to deposit the 1 BTC. With that assumption it means the derivation path for the first address would be m/49'/0'/0'/0/0.

BIP-39 does this using a Password-Based Key Derivation Function with HMAC-SHA512 as the hash function, the string “mnemonic” as the salt, and the 12-word mnemonic as the password. It also uses 2048 iterations and each iteration requires two SHA512 calculations. This means this step will cost in total ~4096 SHA-512 calculations.

John Cantrell guessed the mnemonic seed because it was quite straight forward, with default parameters. But I can see two customization possibles :

- Custom address_index (but limited to 2B possibilites)
- Custom PBKDF2 iterations (from 2k to 1M)

Is it good security practice to use custom parameters above ? Even if you forget them, you still have your mnemonic seed and will be able to bruteforce address and PBKDF2. It can make your mnemonic seed more secure if someone stole it from you. Give you time to move funds etc.

[1714660826]

1714660826

[NeuroticFish]

Imho you are over-complicate things for no use.
Imho the main point there was that 8 of 12 seed words were known. If you keep safe all your 12 (or 24) seed words you are safe, since the difficulty of finding the result grows exponentially for each new word.


This being said, if you play with the parameters "for security reasons" you give yourself the chance to face bad surprises at some point, for example a wallet you use doesn't recognize something or your family (or even you in 30 years!) no longer(?) understand how to get access to those coins. Keep in mind that you won't be young forever and the brain doesn't remember everything as good as you'd expect. Also accidents (or even death!) do happen. I'd say: keep it simple.

[BlackHatCoiner]

Is it good security practice to use custom parameters above ? Even if you forget them, you still have your mnemonic seed and will be able to bruteforce address and PBKDF2. It can make your mnemonic seed more secure if someone stole it from you. Give you time to move funds etc.

If someone stole them from you, and they didn't know that you changed the custom parameters, it'd be a matter of time until they access your funds. It would surely be more secure since it'd require more computational power for the attacker to successfully find it via brute force, but if you forget them, so do you. You may also are unaware that someone compromised your room and found your phrase. The purpose of the seed would have already lost its point.

Why don't you simply use a strong password if you're afraid that they may break into your place? It isn't that hard to pick a long password that provides you more security than a bunch of additional PBKDF2 iterations.

[pooya87]

Is it good security practice to use custom parameters above ?

Things like this are never considered "security practice" if you ask me. They are false sense of security.

Even if you forget them, you still have your mnemonic seed and will be able to bruteforce address and PBKDF2.

If you can do it, the attacker can too.

It can make your mnemonic seed more secure if someone stole it from you. Give you time to move funds etc.

The thief is not going to leave any traces behind and if they can gain access to a hard copy of a mnemonic (assuming it is for a cold storage and stored the "right way") it is safe to assume they know more about you than you think.

If you want to modify the algorithm them why stop at such a simple change and not make a better change that can actually give you a proper security?
You have a mnemonic that is n-bits (eg. 128-bits for 12 words) take those bits and encrypt them with AES256 with a key derived from a strong passphrase and a salt derived from the address (like BIP38).
Now you get 128-bits of encrypted data (encryption without IV) which you can encode to 12 words using the same BIP39 scheme. All you have to do is write down these words as if they were your mnemonic.

To import to a wallet you just decrypt these words and convert to an un-encrypted BIP39. That is decode 12 words to get the byte[], derive the AES key from the passphrase and address like above, decrypt using AES256. Now you have un-encrypted 128-bit entropy. Encode this using BIP39 scheme and you have the original words.

[BlackHatCoiner]

Things like this are never considered "security practice" if you ask me. They are false sense of security.

Exactly. It's like generating a random 32-bit number, passing it through SHA256 (maybe bunch of times) and consider the result's security 256-bit. It's false sense of security if someone can end up to your number by another way than generating it randomly through a 2²⁵⁶ range.

I hope you have skill and time to write custom brute-force software (or fork and modify existing software) which check generated seed/address on different PBKDF2 iteration number.

That is also a drawback. If you pass away (knock on wood!) your family won't be able to recover your funds somehow unless you've hidden the software in your hard drives. I hope you acknowledge how impractical it may get for no reason.

[Pmalek]

If you want to modify the algorithm them why stop at such a simple change and not make a better change that can actually give you a proper security?
You have a mnemonic that is n-bits (eg. 128-bits for 12 words) take those bits and encrypt them with AES256 with a key derived from a strong passphrase and a salt derived from the address (like BIP38).
Now you get 128-bits of encrypted data (encryption without IV) which you can encode to 12 words using the same BIP39 scheme. All you have to do is write down these words as if they were your mnemonic.

To import to a wallet you just decrypt these words and convert to an un-encrypted BIP39. That is decode 12 words to get the byte[], derive the AES key from the passphrase and address like above, decrypt using AES256. Now you have un-encrypted 128-bit entropy. Encode this using BIP39 scheme and you have the original words.

What if a head injury or senility prevents you from remembering what you did somewhere down the line? You will have to explain that system to your descendants or write down exactly what you did. If someone discovers all that and figures out your system, your security isn't any better than what it would have been if you used a seed extension (passphrase) in the eyes of the thief. Assuming he knows what he found.   

[o_e_l_e_o]

- Custom address_index (but limited to 2B possibilites)

No need to stop there. Your derivation path can have 255 additional levels to it after the master key m, and each level can support 2³² - 1 values if you are including hardened values. There are more valid derivation paths than there are private keys or seed phrases, by many many orders of magnitude. You could pick a derivation path made up of 255 randomly chosen numbers between 0 and 2³² - 1, and no attacker would ever be able to find your coins even if you told them your seed phrase.

The reason people don't do this is because it provides no additional security. Just as an attacker couldn't steal your coins in my made up scenario without knowing your derivation path, an attacker can't steal your coins in a real life scenario without knowing your seed phrase. Why choose to back up something in which it is easy to make a mistake with (long strings of random numbers) when you can back up something much harder to make a mistake with (seed phrases). In both scenarios you end up with the same amount of security and a back up you need to keep secure, but with seed phrases you also are far less likely to make an error and far less likely to lock yourself out of your own wallets.

If you are concerned about someone stealing your seed phrase, then either use an additional passphrase, encrypt it before backing it up, or use a multi-sig wallet. All are far preferable to rolling your own "security".

[pooya87]

What if a head injury or senility prevents you from remembering what you did somewhere down the line? You will have to explain that system to your descendants or write down exactly what you did.

You are right but the method could be published even on the internet as a new BIP similar to BIP38 which is for encrypting private keys. Then there will always be a tool to encrypt/decrypt the words.
Publishing it also has the benefit of others seeing the method and improving it.

If someone discovers all that and figures out your system, your security isn't any better than what it would have been if you used a seed extension (passphrase) in the eyes of the thief. Assuming he knows what he found.   

You can't even begin to compare the security of this method with seed extension! PBKDF2 with such a small number of iterations is not providing any meaningful security not to mention that it is not meant for "encryption" whereas AES256 is a strong encryption algorithm.
Additionally if you look at my explanation again I hinted at using a KDF before deriving the encryption key (eg. scrypt) which will add a huge difficulty against brute forcing.

[Pmalek]

You can't even begin to compare the security of this method with seed extension!...

I think you misunderstood what I was trying to say. I wasn't trying to compare your encryption method to a passphrase. I was stating the fact that if I knew the exact method of encryption that you used and I knew exactly what to do to encrypt decrypt it, the end result is the same as if I found your seed or passphrase. I will take your coins. I just need to perform a few more steps to get there, that's all.  

[Sanglotslongs]

Thanks you for your answers.


Concerning PBKFD2, 2048 iterations was designed to slow up brute-force attack. But 15years after this design, 2048 iterations is quite weak. Do you think we should make more iterations ?

[o_e_l_e_o]

Concerning PBKFD2, 2048 iterations was designed to slow up brute-force attack. But 15years after this design, 2048 iterations is quite weak. Do you think we should make more iterations ?

BIP39 was only proposed in 2013 and the 2048 iterations was still being debated in 2014, so this is only 7 years old, not 15. 2048 was weak then and it is weak now. As a result, the security of seed phrases against brute forcing comes largely from the entropy of the seed phrase.

There are certainly good technical reasons to increase the iteration count, but there are practical reasons not to. BIP39 is now so ubiquitous, that if you started introducing new iteration counts it was cause havoc. There are still plenty of people who think they have lost their coins because they don't know the difference between recovering a legacy wallet and a segwit wallet. Electrum seed phrases cause frequent problems as people do not realize they are different to BIP39 seed phrases. Having the same seed phrase able to recover multiple different wallets of the same type due to different iteration counts will only compound this even more.

[pooya87]

There are certainly good technical reasons to increase the iteration count,

I disagree because the real question we have to ask first is "why are we using a KDF in this scheme?".

• If it is for security, then PBKDF2 should not even be used. There are other mode advanced and memory expensive KDFs such as scrypt that could provide a much better security. Changing PBKDF2 iteration to a safer value (which is above 10 million according to RFC8018 recommendation) would just slow down the derivation process and would harm user experience.
• But if this KDF is there to only provide a way to use the same 12 to 24 words but derive different BIP32 seed by adding and changing a "passphrase" then it makes sense to use such a low iteration of such a weak KDF. Heck, I'd say we shouldn't even use a KDF, just replace it with a simple single HMACSHA512 to act as a Key Derivation Function.

This second case is in my opinion the actual reason for using PBKDF2, which is why I disagreed. The authors also mention the "plausible deniability" as the reason.