Is encrypted mnemonic technically possible?

[ABCbits]

Since encrypted private key (BIP 38 which usually used by paper wallet) is possible, i wonder if encrypted mnemonic is technically possible?

If it's possible, it could reduce attack vector where attacker could stole your Bitcoin immediately after stole paper or file which contain your mnemonic phrase.
If it's possible and there's draft or implementation of it, please let me know

P.S. i'm not talking about extended mnemonic phrase.

[1714030099]

1714030099

[1714030099]

1714030099

[HeRetiK]

Since mnemonics are a direct mapping of binary data to common, memorizable words you can theoretically encode any digital file as mnenomics. So, sure, I guess?

I'm not sure where the benefit would lie over extended mnemonic phrases though.

[nc50lc]

P.S. i'm not talking about extended mnemonic phrase.

"Extended mnemonic phrase" is kinda misleading term since you can type other words outside BIP39 word list, it's really a passphrase;
the same passphrase used by some hardware wallets that changes the keypool depending on the user's passphrase (ex. Trezor).

If it's possible, it could reduce attack vector where attacker could stole your Bitcoin immediately after stole paper or file which contain your mnemonic phrase.

When creating backup, that extra word shouldn't be included in the print.
If used correctly (like above sentence), it will definitely reduce the attack vector of any attacker/thief who came across your mnemonic phrase since it will create a different set of keys.
That approach is good enough or currently the best solution.

[Coding Enthusiast]

Since encrypted private key (BIP 38 which usually used by paper wallet) is possible, i wonder if encrypted mnemonic is technically possible?

Under the hood I don't see that much difference.
BIP38 takes as input a key (practically a 256 bit data) and a password, then extends the password and uses it as AES key, builds a block based on that "data" and encrypts it. Finally returns the 256 bit result with a special encoding (base58). So all the steps could be the same except the data part which is the entropy (that user knows as mnemonic).

I don't know of any proposals but you could do a very similar thing:
- Instead of the private key you use the "entropy" here*.
- Get a password, extend it like BIP38.
- Create the AES block (XOR of key and extended password), like BIP38
- Perform the encryption same as BIP38
- Encode the result using your favorite encoding technique.

* I have to think more about the case when entropy is not 256 bit (in user's eye, the mnemonic length is anything except 24).

Example:

Code:

mnemonic: hamster diagram private dutch cause delay private meat slide toddler razor book happy fancy gospel tennis maple dilemma loan word shrug inflict delay length
entropy: 68a79eaca2324873eacc50cb9c6eca8cc68ea5d936f98787c60c7ebc74e6ce7c
address at m/44'/0'/0'/0/0: 18CquoRzbEYzK9LaNigoukKj4z3cY6Gy9g
scrypt salt (first 4 byte of double SHA256 of address): 579a20b9
scrypt key (an example password): 0x010203
AES encrypted result: c7f4f0da86146cf6f6147963423a7b99b78e2b4b614c1d7c34cba972ef419b2a

Now that you have your encrypted result you can encode it however you like, for example the same base58 technique used in BIP38 or the same encoding technique used in BIP39 to convert an entropy to a mnemonic:

Code:

6PYPJnPZPszy1fUjw6WnBCrCxDWMkafLy2pe7CpyJghivSXF2nd2m2DjXr

or:

Code:

side pole cute around egg kiwi success monkey globe balcony page cricket jump between collect civil buddy ticket cream fancy confirm patch hole fantasy

Disclaimer: I am using my own code not any library or online tool so the results may contain errors, some parts of my code such as BIP38 aren't fully tested. This is posted as an example to show the similarity of the techniques.

[HCP]

P.S. i'm not talking about extended mnemonic phrase.

But this is exactly what you are looking for... read the BIP39:

A user may decide to protect their mnemonic with a passphrase. If a passphrase is not present, an empty string "" is used instead.

To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes).

The "25th word" or "passphrase" is being used as a salt... without that salt, you'll never recover the same binary seed, even if you have all 12/24 words of the original mnemonic. So, by simply adding this in, you are effectively "encrypting" your seed.

Why is this not enough? Why do you need/want another layer?

[Coding Enthusiast]

Why is this not enough? Why do you need/want another layer?

I don't know OP's reasons and I'm not a cryptography expert, but these are arguments against "using BIP39's passphrase for encryption" that I could think of:
- According to the proposal the passphrase used doesn't seem to be meant for encryption, instead it was meant for what the proposal refers to as "plausible deniability".
- The passphrase is used in a key derivation function which is not considered the strongest or the most expensive compared to its alternative such as scrypt.
- The settings of this KDF is not the best either (which makes sense only if not used for encryption):
-- According to RFC-8018 the recommended salt length (the passphrase used here) should be at least 64 bits and according to NIST it should be 128 bits at least. That translates into a password that must be at least 16 characters long to be strong.
-- The iteration count of 2048 used to be high, in 2019 anything below 10,000 should be considered weak. The standard suggests iteration of 10 million for security critical cases where performance doesn't matter.

[Dabs]

It's possible, but what is the goal and what is the format of the end result that you want?

Would you like something that looks like an encrypted private key that starts with 6? Then you can grab either the mnemonic or the master extended private key and encrypt that.

Or were you looking for something like Coding Enthusiast mentioned and come up with another mnemonic 12 word phrase?

I'm guessing you want the second one, where it looks like any other seed word phrase.

BIP38 is kinda overkill in my opinion, it takes several seconds to minutes to decrypt a single private key. In this case, it would only need to do that for the master private key then derivation for each one should be as normal.

There are BIP39 tools that encrypt each private key derived from the master, but again, that's going to take minutes for each one.

As, it's a shower thought, ... well .... it's good to think of things like this, but I guess there's not much else to it.

[DaCryptoRaccoon]

More people are looking at things like ssss now to hide there seeds I do think some encrypted method would be highly beneficial to the space adding that extra layer of security over the seed may prevent quite a lot of issues.

Another thought would be to split your seed with SSSS.

Below I have taken some words and split them into 10 parts with a combining threshold of 3 meaning I only require any 3 of the 10 shares to reconstruct the data.

try it yourself pick any 3 of the values below and enter them here and set the threshold to 3.
Word of warning DO NOT enter LIVE keys onto this site it is for demo purposes only!!

http://point-at-infinity.org/ssss/demo.html

Code:

01-05f0a55bbd4773ae14a6d5ea2c4a59f1a1f41b1caa9eb84f00a12e0f129b7b89e66a3e5df81c24ce9a4eb5269761a1c8cd9d863a090e16f9d13789dff0c4f1debb8fbb8a9124
02-560e5744f324269f5552a0bee7133dc4e8d1dfdbb4d6efa7a7124e520bb5981118ad907fb6ea67144220ebe2cd6676841b70a51d5b64bb4c827d7ea36f2c158ebf633e1ef19b
03-09ecf96b12670069fff2e2d1239bf030b40f5fead7a9ce112e67677d5abd77f8fc7e86d5029ea7dc25b675e16f31585d232a6e4377730ea1d69bcc83d83579350a5eb798c3cd
04-8d4eb2a8b4dc4a7d90fc3661ec610f2167c50093dcaba18924e8f9777b00c209785a0e90f0c1e82a417e59a8366deca450a1668240aa5dae330d35320d33cac103b85650cb6c
05-d2ac1c87559f6c8b3a5c740e28e9c2d53b1b80a2bfd4803fad9dd0582a082de09c89183a44b528e226e8c7ab943ac27d68fbaddc6cbde84367eb8712ba2aa67ab685dfd6f928
06-8152ee981bfc39ba7ba8015ae3b0a6e0723e4465a19cd7d70a2eb0053326ce78624eb6180a436b38fe86996fce3d1531be168efb3ed745f634a1706e25c2422ab2695a4299b3
07-deb040b7fabf1f4cd108433527386b142ee0c454c2e3f661835b992a622e2191869da0b2be37abf09910076c6c6a3be8864c45a512c0f01b6047c24e92db2e910754d3c4abf1
08-c93b7e3b57d789b902b8ea058d8680d60c91e51a5fe6ba2b116c494091c8029fcc5639e1138ad47889cb0234fc6a0a035f2cf6fa8b59664b0e7b37b1be342be0ae070b57531e
09-96d9d014b694af4fa818a86a490e4d22504f652b3c999b9d9819606fc0c0ed7628852f4ba7fe14b0ee5d9c375e3d24da67763da4a74ed3a65a9d8591092d475b1b3a82d16106
10-c527220bf8f7fa7ee9ecdd3e82572917196aa1ec22d1cc753faa0032d9ee0eeed6428169e908576a3633c2f3043af396b19b1e83f5247e1309d772ed96c5a30b1fd607450151

Good Luck.

[BrewMaster]

Another thought would be to split your seed with SSSS.

although it could work but Shamir's Secret Sharing (3 S not 4) is designed for when you want to "share" a secret between multiple people so it is more suitable for cases when more than one person is involved. not for the case where 1 person wants to encrypt and store 1 secret (mnemonic) in a safe way.

[DaCryptoRaccoon]

Another thought would be to split your seed with SSSS.

although it could work but Shamir's Secret Sharing (3 S not 4) is designed for when you want to "share" a secret between multiple people so it is more suitable for cases when more than one person is involved. not for the case where 1 person wants to encrypt and store 1 secret (mnemonic) in a safe way.

I was under the impression it was called Shamir's Secret Sharing Scheme as the official name hence SSSS.

It can also work with a single person.

Lets say I wanted to split a seed down and store the split shares in seperate locations.

Ie  split1 - Keep in home safe.
    split 2 - Keep at bank safety depo box
    slipt 3 - Kept at friends home in safe.

you are correct in saying it works best with other partys but it is possible to use it to split your seed and store it in multiple parts.

It would be nice to see some kind of encrypted container for seeds like true crypt where user generates a new seed, the seed is then encrypted and output as a secure container file that could be backed up and stored somewhere secure.

Or something like the mouse movements for entropy that truecrypt uses could be usefull in the space.

[PrimeNumber7]

Why is this not enough? Why do you need/want another layer?

I don't know OP's reasons and I'm not a cryptography expert, but these are arguments against "using BIP39's passphrase for encryption" that I could think of:
- According to the proposal the passphrase used doesn't seem to be meant for encryption, instead it was meant for what the proposal refers to as "plausible deniability".
- The passphrase is used in a key derivation function which is not considered the strongest or the most expensive compared to its alternative such as scrypt.
- The settings of this KDF is not the best either (which makes sense only if not used for encryption):
-- According to RFC-8018 the recommended salt length (the passphrase used here) should be at least 64 bits and according to NIST it should be 128 bits at least. That translates into a password that must be at least 16 characters long to be strong.
-- The iteration count of 2048 used to be high, in 2019 anything below 10,000 should be considered weak. The standard suggests iteration of 10 million for security critical cases where performance doesn't matter.

What is the difference in time it takes to compute the xpriv key when using '0x010203' as the BIP 39 '25th seed word' verses using '0x010203' as the script above given the same resources?

At the end of the day, in both situations, a user starts with the same seed, and passphrase, and ends up with a private key allowing him to spend his coin. If both methods take approximately the same amount of time to calculate the xpriv key, there isn't any reason to complicate an already working process. An attacker who has the encrypted seed will need to take the seed and many guesses of the passphraise to check if an xpriv key is calculated that can spend coin, and I believe the salt will only need to be calculated once.

I also don't believe a BIP38 incorrect password will produce a valid private key, whereas an incorrect BIP 39 passphraise will produce a valid xpriv key, forcing an attacker to use additional resources to compare the results of a BIP 39 guess to the blockchain, and would probably need to calculate more than the xpriv key. 

[Coding Enthusiast]

What is the difference in time it takes to compute the xpriv key when using '0x010203' as the BIP 39 '25th seed word' verses using '0x010203' as the script above given the same resources?

I don't have Visual Studio right now (my HDD is failing!) to benchmark it but it is obvious that the extra word in BIP39 is a lot faster because it doesn't include AES, scrypt.

An attacker who has the encrypted seed will need to take the seed and many guesses of the passphraise to check if an xpriv key is calculated that can spend coin, and I believe the salt will only need to be calculated once.

That is brute forcing and when brute forcing BIP38, the attacker is mostly facing AES encryption and that is not possible to brute force assuming the password is strong. The scrypt KDF is there to add an additional expense memory-wise (since it takes ~134 MB to derive the key) to this process.

I also don't believe a BIP38 incorrect password will produce a valid private key, whereas an incorrect BIP 39 passphraise will produce a valid xpriv key, forcing an attacker to use additional resources to compare the results of a BIP 39 guess to the blockchain, and would probably need to calculate more than the xpriv key. 

That's a good point and the cost is high assuming the password is strong but it is not comparable with the cost of previous case. Here the cost is computing a bunch of HMAC-SHA512 (2048 for PBKDF2 + ~4 for BIP32) and an elliptic curve point multiplication, both are quite fast compared to above.

there isn't any reason to complicate an already working process.

Actually in cryptography the goal is to complicate the process as much as you can in order to make different kinds of attack as expensive as possible while keeping the time that it requires for the user himself to encrypt/decrypt his data to a reasonable amount.

[DaCryptoRaccoon]

After having a search I did find a Github project that is aimed at Bitcoin keys and the secret sharing I wonder if this might be something the space should explore in further detail it would be nice to see something like Electrum add something like this from wallet creation screen I think it would make a nice addition.

Please note this is a public repo and I am posting for reference only.

https://github.com/blockstack/secret-sharing


Splitting into reliably printable base58 shares

Code:

>>> from secretsharing import BitcoinToB58SecretSharer
>>> shares = BitcoinToB58SecretSharer.split_secret("5KJvsngHeMpm884wtkJNzQGaCErckhHJBGFsvd3VyK5qMZXj3hS", 2, 3)
['2-Bqni1ysZcXhFBhVVJLQgPimDUJrjBrzuvBmc6gPNPh1jyDcvM6uYUuH', '3-9xpMBerBCdHLKzCQ82fjVLfZ3Qt4

Recovering from base58 shares

Code:

>>> BitcoinToB58SecretSharer.recover_secret(shares[0:2])
'5KJvsngHeMpm884wtkJNzQGaCErckhHJBGFsvd3VyK5qMZXj3hS'

Splitting into reliably transcribable base32 shares

Code:

>>> from secretsharing import BitcoinToB32SecretSharer
>>> shares = BitcoinToB32SecretSharer.split_secret("5KJvsngHeMpm884wtkJNzQGaCErckhHJBGFsvd3VyK5qMZXj3hS", 2, 3)
['B-RJ6Y56OSUWDY5VAAGC6XLSTM64CAJ2LPBNB7NKATJCWC7VSHIP5DQIVMR6OGJ4GB', 'C-CT5R24XAR5B732JWYQKSYOYBSF5VHI73HLY24QCFRJR5XUW64C4JWYN6SRGWVCUG', 'D-T54KX27OPEAGZ7TNK5WOFK4WFPZKEXUHNKPWLWDXZQNYPT3WPV3P5IGQTD7HAJDG']

Recovering from base32 shares

Code:

>>> BitcoinToB32SecretSharer.recover_secret(shares[0:2])
'5KJvsngHeMpm884wtkJNzQGaCErckhHJBGFsvd3VyK5qMZXj3hS'