<p>First things first. There are 3 values in play;</p>
<ol>
<li>The entropy</li>
<li>The mnemonic phrase</li>
<li>The seed</li>
</ol>
<p>The entropy is just random data.
The mnemonic is the same random data, but mapped to a wordlist plus a checksum.
The seed is derived from the mnemonic and a password.</p>
<p>A mnemonic can be converted back to the entropy that was used to create it.
But it is the seed that is used to generate your wallet addresses.</p>
<p>When using a different password you are not actually encrypting the mnemonic but just changing the derived seed. The password is used as the salt to pbkdf2.</p>
<p>It is impossible to find the mnemonic+password for a given seed, and therefor it is impossible to find the mnemonic for a given seed and password.
It is what pbkdf2 was explicitly designed for.</p>

CC BY-SA 4.0
2022-01-16T09:55:19.687Z
Hey, I do understand this. There is a specification to add a "passphrase" to the mnemonic phrase, but as you said, it changes the seed. What I need is to encrypt my mnemonic phrase for a paper backup that someone might find, with a password I have in mind without changing the already used seed.
That's what my implementation does.
Tarion
CC BY-SA 4.0
2022-01-16T09:58:30.137Z
"When using a different password you are not actually encrypting the mnemonic but just changing the derived seed. The password is used as the salt to pbkdf2."

That's why the existing password scheme in BIP39 does not work for me.
Tarion
CC BY-SA 4.0
2022-01-16T12:39:14.477Z
You can encrypt the mnemonic whichever way you want, but it is not BIP39 compliant and can only be decrypted by your own implementation. 
I would rather encrypt the mnemonic using an industry standard cipher and store the ciphertext instead of the mnemonic. Store it as an qrcode instead of text for easier recovery.
Ferdy Pruis
CC BY-SA 4.0
2022-01-19T22:18:36.113Z
Well, you are right. One would need to extend BIP39 which probably will not happen. But I like the idea of having the result at least look like BIP39 so you have plausible deniability and someone who finds my backup can just access some empty wallet (could even be filled with some small amount of coins). In the end my implementation does use industry Standard cipher.
Tarion
CC BY-SA 4.0
2022-01-21T06:19:51.563Z
Thats exactly the design of the current BIP39 passphrase; generate a new mnemonic. Use one passsword to generate a wallet with a tiny amount of coins. Use another password for your actual wallet. Should you ever be required to give up your password, give the first one.  But the result of this design is you can not change the passsword afterwards.
Ferdy Pruis
CC BY-SA 4.0
2022-01-13T22:23:30.923Z
2022-01-13T22:23:30.923Z
Ferdy Pruis
<p>I know that you can create a Mnemonic + PW to encode a seed to derive keys. What I want is to encrypt an existing mnemonic with a password that generates the same seed as the unencrypted mnemonic.</p>
<p>Background is, that I have an existing seed sentence that I want to encrypt into an new mnemonic without changing the underlying entorpy.So I can replace my existing paper copy with an encrypted one.</p>
<p>Is this possible already? Or any reasons why it does not make sense at all?</p>
<p><strong>Update</strong><br />
I came up with an proposal implementation:<br />
<a href="https://github.com/Niondir/go-bip39/blob/master/encyrption_test.go" rel="nofollow noreferrer">https://github.com/Niondir/go-bip39/blob/master/encyrption_test.go</a></p>
<p>It uses SHA256(pw) to generate the key for an AES-CTR with an empty IV to encrypt the entropy that is derived from the mnemonic. I'm open for discussion of the parameters and ciphers, but this might not be the best place for that discussion.</p>

CC BY-SA 4.0
2021-05-05T14:08:33.760Z
Why not encrypt it normally, then decrypt before use?
RedGrittyBrick
CC BY-SA 4.0
2021-05-05T14:28:05.393Z
Since there is no "normally" - when encrypting it into some random looking data, it does not have the same backup properties (e.g. error correction). I want to store a mnemonic which needs an additional password to get the "real" mnemonic.
Tarion
CC BY-SA 4.0
2021-05-05T14:32:27.023Z
I came up with an proposal implementation like this: https://github.com/Niondir/go-bip39/blob/master/encyrption_test.go

It uses SHA256(pw) to generate the key for an AES-CTR with an empty IV to encrypt the entropy that is derived from the mnemonic.

I'm open for discussion of the parameters and ciphers, but this might not be the best place for that discussion.
Tarion
CC BY-SA 4.0
2021-05-05T14:37:06.500Z
Your use case is unclear to me, it seems you want `seed(phrase) == seed(enc(phrase, pw))`?
RedGrittyBrick
CC BY-SA 4.0
2021-05-05T14:50:22.677Z
@RedGrittyBrick I guess yes. Take a look into my implementation, it solves what I want.
More like: `seed(plainPhrase) == seed(decrypt(encPhrase, pw))`
Tarion
<mnemonic-seed>
How to encrypt an existing BIP-39 mnemonic with a password without changing the seed?
Tarion
# How to encrypt an existing BIP-39 mnemonic with a password without changing the seed?

(Asked by: username_0 on 2021-05-05)

I know that you can create a Mnemonic + PW to encode a seed to derive keys. What I want is to encrypt an existing mnemonic with a password that generates the same seed as the unencrypted mnemonic.

Background is, that I have an existing seed sentence that I want to encrypt into an new mnemonic without changing the underlying entorpy.So I can replace my existing paper copy with an encrypted one.

Is this possible already? Or any reasons why it does not make sense at all?

**Update**  
I came up with an proposal implementation:  
<https://github.com/Niondir/go-bip39/blob/master/encyrption_test.go>

It uses SHA256(pw) to generate the key for an AES-CTR with an empty IV to encrypt the entropy that is derived from the mnemonic. I'm open for discussion of the parameters and ciphers, but this might not be the best place for that discussion.

**Tags:** mnemonic-seed

> **Comments:**
> **username_1**: Why not encrypt it normally, then decrypt before use?  
> **username_0**: Since there is no "normally" - when encrypting it into some random looking data, it does not have the same backup properties (e.g. error correction). I want to store a mnemonic which needs an additional password to get the "real" mnemonic.  
> **username_0**: I came up with an proposal implementation like this: https://github.com/Niondir/go-bip39/blob/master/encyrption_test.go  It uses SHA256(pw) to generate the key for an AES-CTR with an empty IV to encrypt the entropy that is derived from the mnemonic.  I'm open for discussion of the parameters and ciphers, but this might not be the best place for that discussion.  
> **username_1**: Your use case is unclear to me, it seems you want `seed(phrase) == seed(enc(phrase, pw))`?  
> **username_0**: @username_1 I guess yes. Take a look into my implementation, it solves what I want. More like: `seed(plainPhrase) == seed(decrypt(encPhrase, pw))`  

---

## 1 answers

### Answer by username_2 on 2022-01-13. Score: 1

First things first. There are 3 values in play;

1. The entropy
2. The mnemonic phrase
3. The seed

The entropy is just random data.
The mnemonic is the same random data, but mapped to a wordlist plus a checksum.
The seed is derived from the mnemonic and a password.

A mnemonic can be converted back to the entropy that was used to create it.
But it is the seed that is used to generate your wallet addresses.

When using a different password you are not actually encrypting the mnemonic but just changing the derived seed. The password is used as the salt to pbkdf2.

It is impossible to find the mnemonic+password for a given seed, and therefor it is impossible to find the mnemonic for a given seed and password.
It is what pbkdf2 was explicitly designed for.

> **Comments:**
> **username_0**: Hey, I do understand this. There is a specification to add a "passphrase" to the mnemonic phrase, but as you said, it changes the seed. What I need is to encrypt my mnemonic phrase for a paper backup that someone might find, with a password I have in mind without changing the already used seed. That's what my implementation does.  
> **username_0**: "When using a different password you are not actually encrypting the mnemonic but just changing the derived seed. The password is used as the salt to pbkdf2."  That's why the existing password scheme in BIP39 does not work for me.  
> **username_2**: You can encrypt the mnemonic whichever way you want, but it is not BIP39 compliant and can only be decrypted by your own implementation.  I would rather encrypt the mnemonic using an industry standard cipher and store the ciphertext instead of the mnemonic. Store it as an qrcode instead of text for easier recovery.  
> **username_0**: Well, you are right. One would need to extend BIP39 which probably will not happen. But I like the idea of having the result at least look like BIP39 so you have plausible deniability and someone who finds my backup can just access some empty wallet (could even be filled with some small amount of coins). In the end my implementation does use industry Standard cipher.  
> **username_2**: Thats exactly the design of the current BIP39 passphrase; generate a new mnemonic. Use one passsword to generate a wallet with a tiny amount of coins. Use another password for your actual wallet. Should you ever be required to give up your password, give the first one.  But the result of this design is you can not change the passsword afterwards.  

---

