Is encrypted mnemonic technically possible?

Rowan

Member
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
Smiley


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

Niko

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

Edison

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

Izaiah

Member
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
Smiley


P.S. i'm not talking about extended mnemonic phrase.
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).
 

Jerry

Member
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?
Huh
 

Gustavo

Member
Why is this not enough? Why do you need/want another layer?
Huh
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.
 

Marvin

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

Mauricio

Member
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
 

Ahmad

New member
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.
 

Justice

New member
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.
Smiley


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.
 

Elian

New member
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.
 

Arturo

New member
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
 
Top