Topic: Custom parameter for mnemonic seed (Read 202 times)

Rather than enable more iterations, we might as well as creating new BIP as successor of BIP 39. There are few improvement that could be added such as,
1. Versioning system
2. More iteration during converting mnemonic to seed if passphrase isn't empty.

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.

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.

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 ?

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.  

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.

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.

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

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.   

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.

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.

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

If you can do it, the attacker can too.

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.

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.

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.

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 :



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.