Recovery words (mnemonics) display & Extended Master Private Key

[yahiheb]

In this question @nopara73 said:

You can't pull it up on the program. Recovery words are one timer.

and in this question @lontivero said:

The seed is not saved anywhere for security reasons

For the same security reasons shouldn't we not display the Extended Master Private Key in the Wallet Info tab? If we can display it then why can't we display the seed?

[yahiheb]

In TermsAndConditions.txt file:

Encrypted private key information is stored locally on your computer in a wallet file and/or backed up with Recovery Words,

Does it mean that the seed is stored locally?

[yahiheb]

And why not use 'Seed' or 'Seed phrase' instead of 'Recovery Words'?

[MaxHillebrand]

to clear up some vocabulary:

• seed, random number to spawn the HD structure
• private key, derived from seed, with corresponding public key
• mnemonic, human readable word representation of seed
• passphrase, a human readable tweak to the seed

I like the idea of displaying the mnemonic in the Advanced / Wallet Info upon passphrase entry.

[benthecarman]

I like the idea of displaying the mnemonic in the Advanced / Wallet Info upon passphrase entry

I don't think it is possible. AFAIK we do not store the mnemonic and you cannot go from seed to mnemonic.

[MaxHillebrand]

you cannot go from seed to mnemonic.

Really? I thought the mnemonic is a byte for byte representation of the seed?

[davterra]

Both the mnemonic and the seed are preceded in existence in a new wallet by a set of randomly generated bits (entropy). From that entropy, the mnemonic words are mapped from the BIP39 word list, and from the original entropy (not the mnemonic) the seed is created using PBKDF-2 key-stretching. That resulting seed is used to generate the HD wallet. The mnemonic is just a human-readable/recordable/memorizable way to represent the original entropy so that it can be recreated if necessary.

[yahiheb]

@davterra Is it correct to say that if you have: the entropy OR the mnemonic OR the seed OR the extended master private key, then you have full control of the funds?

If the answer is yes, then how do we get the extended master private key on Wasabi Wallet? Is it directly stored somewhere or do we generate it using another stored data?

The point I am trying to say is if we store some data that can lead to full control of the funds, either we don't store this data for security reasons as @lontivero said:

The seed is not saved anywhere for security reasons

or if we must store this data then why not also store the mnemonic and display it when needed.

[davterra]

@yahiheb Yes, if you have any of those 4 things, you have full control over the funds.

I've just recently starting delving into the wasabi code, hoping to be more involved in the future, so I cannot speak with any authority about the app's architecture or code. While the seed may not be stored anywhere for security reasons, the MPrivKey is, and can be retrieved with the wallet password.

I personally would prefer that the MPrivKey be stored than the mnemonic, as I use more than one wallet based on the same 24 word mnemonic, but with different BIP39 mnemonic-extensions (passwords). Bad opsec in theory perhaps, but I am very comfortable with the way that my "base" mnemonic was generated and subsequently secured.

If someone is able to hack one of my wallets and get the MPrivKey, or even the password that created it, there's no way to reverse-engineer the mnemonic and have potential access to other wallets I've created.

[yahiheb]

I personally would prefer that the MPrivKey be stored than the mnemonic, as I use more than one wallet based on the same 24 word mnemonic, but with different BIP39 mnemonic-extensions (passwords).

In your case that makes sense but for most users that do not use the same mnemonic there is no difference in storing the MPrivKey or the mnemonic. In this case maybe storing the mnemonic is better because it is easier to read.

[yahiheb]

I closed this issue by mistake.

[lontivero]

This is how Wasabi works: after generating the mnemonics the user can provide a password that is used as 13rd word (as described in bip 39) and as encryption password (as described in bip38). With the mnemonics + password the extended seed is derived.

                      +-------------+
                      | Entropy     |
                      +-------------+
  +--------------+          |
  | Word list    +--------->+
  +--------------+          |
                      +-----v-------+
                      | Mnemonics   |
                      +-------------+
                            |
                   +-------->
                   |        |
                   |  +-----v-------+
                   |  | Seed        |
                   |  +-------------+
                   |        |
   +-------------  |        |
   | Password    +-+  +-----v-------+
   +-------------+ |  | Entended Key|
                   |  +-------------+
                   |        |
                   |        |
                   |  +-----v-------+
                   |  | Private key |     ** This step is needed to use bip38
                   |  +-------------+
                   |        |               +-------------+
                   +------->+ <-------------+  Network    |
                            |               +-------------+
                      +-----v-------+
                      | Encrtpted   |
                      | secret      |
                      +-------------+
                            |
                            |
                            |
                  +--------------------+
                  | Save encrypted     |
                  | secret+chaincode+  |
                  | Fingerprint+ExtPub |
                  +--------------------+

Note that there is a step that are not reversible: convert the seed to extendedkey

Why bip38?

I don't know the reason behind this decision but I can guess: it is a standard, well-tested and very secure way to encrypt a private key. It is also implemented in the NBitcoin library so, it easy to use. Additionally, there is no standard way (bip) to encrypt HD wallets. Take into account that it is not only encryption what bip38 provides but also a brute-force protection.

Why bip39 and then bip38? Isn't that redundant?

Well... yes, imo it is. Bip39 generates the mnemonic and provides a mechanism for protecting it with a password. Given we generate the private key and save it after encrypting it with the same password use to derive the seed from mnemonic, bip38 doesn't add any significant security.

---

As we can see there are many ways to get our private keys. We can save:

Data	Can be saved in a file
entropy	Yes
mnemonic	Yes
seed	No. We cannot get it without using the password
extendedkey	No. We need password
privatekey+chaincode+fingreprint	No. We need password
encryptedsecret+chaincode+fingreprint	Yes (what wasabi does)

If we can display it then why can't we display the seed?

We cannot display it because with don't know the seed, we don't save it anywhere. We cannot save the seed on disk because it is all what you need to spend. We save the encrypted secret what requires a password to decrypt the private key.

Couldn't we simply save the recovery words? Yes, that would make possible to compute the seed but that would make all our previously generated wallets incompatible and with should add versions to the wallet file and it is too much effort for so small benefit.

[MaxHillebrand]

This is a great explanation @lontivero, thanks!! I've added it to the Wasabi docs, will fine tune it in future commits :+1: https://github.com/zkSNACKs/WasabiDoc/commit/0fb81bd9cb1dc04b206b8197e6310f91724a53ad https://github.com/zkSNACKs/WasabiDoc/commit/67fcf79df2b3b98eabb78ad3976b0c1e86db0a1a

[yahiheb]

@lontivero Thank you, that is a great explanation indeed. One thing I wanted to clarify:

If we can display it then why can't we display the seed?

here I meant the mnemonic, and if I am not wrong people in the mentioned Reddit questions were asking about the mnemonic not the seed, so I think it will be nice to display the mnemonic in Wasabi.

[lontivero]

I think it will be nice to display the mnemonic in Wasabi.

As we know, currently the Wasabi doesn't have any way to recover the mnemonic (recovery words) from the existing data saved in the wallet files. That means that in order to be able to display that info we should persist it first after wallet creation.

Changing/adding the recovery words to the wallet file, even when could be done in a backward compatible way, requires a lot of effort and discussions (it could also add some unknown risks that I don't see now) and the benefit is not clear enough.

[btcpirate]

interesting read, seems to generate difficulties to allow a user to see his mnemonic a second time. although it would be convenient from a user perspective to allow a second look

[MaxHillebrand]

I thought about this some more... Definitely it would be a good feature to allow the user to get the 12 recovery words even after the initial wallet setup. Already now it gives the xpr key after password input, which gives the same level of access.

So, why don't we take the 12 recovery words, and again encrypt it with the 13th word, and store this cyphertext in the wallet file. Then when the user wants to get the 12 recovery words, he has to put in the 13th password, to get the mnemonic, which in it self is not enough to spend the coins [cause missing 13th word]. This way, if you do not have the password, then you don't even get the 12 words [which you would need the password in addition anyhow].

I don't understand how this could be a security concern... Again, if the user has the password he can get the xpriv anyhow...

[nopara73]

Encrypting with the same password 2 things weaken security.

[yahiheb]

Encrypting with the same password 2 things weaken security.

Which two things?

If I am not wrong the main problem here is the backwards compatibility. https://github.com/zkSNACKs/WalletWasabi/issues/2049#issuecomment-520481205

[MaxHillebrand]

Encrypting with the same password 2 things weaken security.

I do not know about the nuances here, so probably better to not roll my own crypto.

But here another approach... Just put the 12 words in the wallet file in cleartext. They alone cannot be used to spend the funds, it also requires the 13th word password. So this is the same security as having the [13th word] encrypted xpriv in the wallet file. Assuming the password is secure, that encrypted xpriv or the 12 words cannot be used to spend the funds.

[nopara73]

Which two things?

The master privkey and the mnemonics.

[nopara73]

@MaxHillebrand that's creative, but that ruins the security model in the exact same way.

An attacker right now can test passwords against the encrypted secret. What you are proposing is for the attacker to be able to test passwords on the 12 mnemonic words if they give you back the encrypted secret.

So that's pretty much like "encrypting with the same password 2 things."

[MaxHillebrand]

I really don't know how this would weaken security... I thought encryption is made so that you can encrypt multiple messages with the same password...

[nopara73]

Don't mess with security until you know exactly what you do.

[lontivero]

This issue started with a question and I think it was answered. Lets summarize the discussion here (I will repeat myself a bit, sorry):

1. It is not possible to recover the mnemonics from the available data stored in the wallet file so,
2. In order to be able to display the mnemonics we would need to store it,
3. We can only store it if it is encrypted,
4. Encryption should be using bip38, otherwise it could be easier to brute force,
5. Encryption requires a password
6. The password cannot be the same used to encrypt extended master key, we don't understand exactly how that affects the security but by sure it does it.

All this also means that we have to:

1. Store more info in a secure way
2. Ensure backward compatibility
3. Require additional passwords (what could be a disaster from UX and security)

Note: we are already using the password for two different goals, and that is already confusing.

[yahiheb]

If there will be a hard fork, shouldn't we take the opportunity to consider adding this feature.

Encrypting with the same password 2 things weaken security.

Which two things?

The master privkey and the mnemonics.

Are they really two things? They are more like two sides of the same coin.

[davterra]

Well, isnt the master privkey the outcome of the mnemonic + password, which = spendable wallet, whereas the mnemonic alone cannot recreate the same master privkey / spendable wallet? At least in BIP39 password context.

[nopara73]

@davterra that is correct.

@yahiheb While I'm not sure exactly what feature you are referring to, I don't see how a hardfork could help, as a hardfork does not force the user to create a new wallet.

[yahiheb]

@davterra that is correct.

Since that is correct I don't see any security concerns to encrypt the recovery words using the same password. It is like encrypting half of the master privkey using the same password. Does that weaken the security?

@yahiheb While I'm not sure exactly what feature you are referring to

I am referring to making it possible to display the recovery words in the wallet info tab by saving the recovery words encrypted with the password at generation.

I don't see how a hardfork could help, as a hardfork does not force the user to create a new wallet.

That is true. In that case wallets that were created prior to adding this feature will not be able to display the recovery words.

[davterra]

@davterra that is correct.

Since that is correct I don't see any security concerns to encrypt the recovery words using the same password. It is like encrypting half of the master privkey using the same password. Does that weaken the security?

@yahiheb While I'm not sure exactly what feature you are referring to

I am referring to making it possible to display the recovery words in the wallet info tab by saving the recovery words encrypted with the password at generation.

I don't see how a hardfork could help, as a hardfork does not force the user to create a new wallet.

That is true. In that case wallets that were created prior to adding this feature will not be able to display the recovery words.

Seems to me like that would lessen security, as it creates a single point of failure for an "evil maid" attacker to get all the info needed to recreate and empty the wallet.

And, if the single point of failure is the password, for the vast majority of users it will have significantly less entropy than the seed words.

Having said that, similar could be said for being able to get the master privkey with only the wallet password, which is a reason why I use a ColdCard.

[yahiheb]

Seems to me like that would lessen security, as it creates a single point of failure ...

Having said that, similar could be said for being able to get the master privkey

Which means this doesn't weaken security.

[davterra]

Seems to me like that would lessen security, as it creates a single point of failure ...

Having said that, similar could be said for being able to get the master privkey

Which means this doesn't weaken security.

Yeah, I forgot about the ability to recover the master privkey until after I'd posted the first two sentences.

[MaxHillebrand]

I think I have an idea on how this can be done...

Problem

The user sees the recovery words only one time at wallet generation. However, it is commonly requested to be able to see the recovery words again during the wallet is in use. Maybe the user wants to do another backup or whatever.

Question / possible solution

The wallet file already stores the "EncryptedSecret": "foobarfuz". With this cyphertext alone, the bitcoin cannot be spent. It requires the password in order to generate the master private key. If there is no password or an insecure one, then with knowledge of the EncryptedSecret the bitcoin can be spent.

As far as I understand it, even with knowledge of the EncryptedSecret and password, the recovery words cannot be generated.

The 12 RecoveryWords function in a similar way, knowledge of only them is not sufficient to generate the private key. It also requires the password to be able to generate the private key and spent the bitcoin, and if the password is weak or non-existent, the bitcoin can be spent.

If my intuition is correct here, then this would mean that both the EncryptedSecret and the RecoveryWords have the same protection and are essentially equivalent to the same information. BOTH require the password to be spent. Knowing either one, or both of the EncryptedSecret and the RecoveryWords gives no information of the master private key.

Thus, the RecoveryWords could be saved in the wallet file, and displayed in the GUI.

[nopara73]

Thus, the RecoveryWords could be saved in the wallet file, and displayed in the GUI.

[the-metalworker]

Adding a +1 for the feature to reveal the mnemonic phrase after generating a wallet. The use case is, a user has lost the mnemonic or did not write it down when creating the wallet. However they do still have the wallet on their computer and now they want to save the mnemonic for convenient backup or transfer to another computer.

Every other bitcoin wallet I've ever used that shows a mnemonic backup allows the user to see the mnemonic again after creating the wallet. There is no harm in this, at least no more harm then Wasabi's existing key security model. Why? Because if an attacker can get onto your computer and steal whatever file is storing the mnemonic then they can also steal your keys when you enter your password to start a new mix or send coins to another wallet.

If we're going to be storing our bitcoin in a hot wallet we have to trust that the machine the wallet is stored on is minimally secure. If we don't trust that then we shouldn't be using a hot wallet at all.

[lontivero]

This thread became so long that i suspect that new commenters are not reading it all and that's why we are walking circles. The discussion is not whether it is possible to display the words or not, it is not about the convenience nor about what other wallets do.

We all know it is possible to do, we all know other wallets do it and some think it is convenient but the point is about how the security assumptions could be impacted by the changes needed to implement this feature. It is clear that we can not assume the users machine are secure! That's why we encrypt the extended master key; otherwise why would we do such a thing?

Clearly we have to encrypt things (extended master key, seed, recovery words or whatever can be used to spend the money). But if we encrypt the recovery words then what algorithm should we use and what password? Is it wise to encrypt two different things with the same password? Should we use the same encryption technology (bip38) for something that is not a private key?

I personally have no good answers for these (an many many others) questions. So, the cost if well is unknown is big, the risks are also unknown to me however, the benefit is pretty clear: a small benefit.

Personally I would like to stop this discussion because nobody in their mind will implement this anytime soon.

[nopara73]

So, the cost if well is unknown is big, the risks are also unknown to me however, the benefit is pretty clear: a small benefit.

Well said.