Master Passphrase Feedback

Hey @fresheneesz -- One area I've been thinking a fair bit about lately is the master passphrase.

On generating the master passphrase, I found option 1 here on Trezor's blog pretty compelling to ensure enough randomness in the password -- A number of the links on the Basic master passphrase file mention option 1 in passing, but maybe it's worth explicitly including in the guides (e.g. Choosing a Passphrase Methods).

https://blog.trezor.io/is-your-passphrase-strong-enough-d687f44c63af

I've also been thinking about backing up a master passphrase. Your guides make a great case for not doing this and my concerns are probably unfounded, but it does seem potentially beneficial to have some sort of backup here. That's how I stumbled into secret sharing and I wonder if there's a place in your guide to at least discuss secret sharing and slip39 -- If only to say... You probably don't want to do this.

Anyways -- Some rambling thoughts there. Thanks for the great work on this protocol!

I think that Trezor article summarizes ways of creating a password pretty well. The philosophy I take with these guides is twofold:

For the guides I create and recommend, I want to provide options that allow the user to choose between various tradeoffs. But I don't want to recommend an option that has no attributes that improve on another option, to minimize cognitive load on the reader/user. I currently have the line of thinking that option 1 there is an ideal way to create a password, and that the other couple options don't have advantages over option 1. So unless there's reason to believe that's not true, I think sticking with Option 1 alone is best. However, it would certainly be useful to mention the other options and why they were not chosen (ie because they have no material benefits and additionally possible material deficiencies).
I want to make these protocols parameterizable, so that someone who has conflicting recommendations can reuse them and "pass in" other things. So if we don't agree for some reason on what methods have what pros and cons, I'm certainly up for ensuring the guides are written in a way that allows for their reuse within the context of another guide with alternate recommendations.

it does seem potentially beneficial to have some sort of backup

Well, my line of thinking is that if you're going to write something down and you don't need to remember it, then you should just go ham on entropy and ensure its super strong and super future proof. As soon as its "something you have" vs "something you know", extra length that prevents effective memorization is useful.

However other people certainly advoate having a passphrase and backing it up. I definitely can see the potential usefulness in terms of having a seed + passphrase both backed up in different locations is sort of a mid-way between actual multisig, which is more secure than a passphraseless single-seed backup and just as easy to use as a single-seed backup + remembered passphrase but less secure than a true multi-sig setup. I'm certainly open to discussing it. I was mulling it over a few months ago and I can't remember if I came to a hard conclusion (which probably means I didn't).

The trouble with a seed + passphrase however is that it emulates a 2-of-2 multisig wallet. There's a reason these guides don't recommend 2-of-2 wallets. The reason is that in order to store the seeds both securely and redundantly, you need to have 4 storage locations. I view finding and maintaining secure storage locations as the most difficult and time consuming part of a wallet protocol, because they need to be things that are physically secured like home safes, safe deposit boxes, etc and they need to be checked up on periodically and paid for. A 2-of-3 multisig wallet by contrast only needs 3 secure storage locations, and has just as good or probably better security and redundancy.

secret sharing and slip39

I don't quite follow how Shamir fits in here. Are you talking about Sharmiring a passphrase?

Another consideration is that I tend to think about the future a few years out. Multisig is currently a bit cumbersome and expensive on chain. Schnorr signatures and taproot will change this. So if current technology didn't evolve, using Shamir's Secret Sharing would be an ok option for a few reasons. However, because there's currently limited support for SSS and it will beome obsolete in the next year or two, I kind of can't find the motivation to incorporate it. SSS also has the problem of a necessary single-point-of-failure, since you need to bring all shamir secret pieces together in order to recover the data.

Thanks for explaining your philosophy on the guides.

In response to the first paragraph I'd like to focus on this portion of the guide:

Choose a passphrase with 3-5 random words and a few numbers. It MUST be memorable to you but should NOT use words that are meaningful to you or associated with your identity, even things you think are secret. The more words it has, the more secure it is, however the harder it will be to remember. It is NOT recommended to use any punctuation, special characters, letter/number substitution, nor to use capitalization.

My piece of feedback here is that I think it would benefit readers to note that: Humans are not very good at making random choices so check the See also section for recommendations on how to pick your password effectively.

On paragraph 2, I agree 100%. The context I have been considering a master passphrase backup is in 3-of-5 redundancy focused protocol...

Consider a scenario where I would like my extended family to be able to access my Bitcoin in the event of my death -- As an example, consider a natural disaster like a hurricane.

In this event, my home location is destroyed and my wallets and backups can't be recovered. This leaves my 2 safe deposit boxes. Perhaps I was not considering this scenario and one of my safe deposit boxes is in the city impacted by the natural disaster and was also destroyed.

In thinking through this scenario, I tend to lean towards this being a scenario of a poor storage location; but on the flipside having at least one safe box in close geographical proximity might be advantageous (after all, you need to check on it yearly) or it might be a necessity depending on where you live (e.g. Hawaii)

Regardless, my extended family finds out about my holdings in the will with instructions to access -- In this case, they cannot access my bitcoin because we only have double redundancy in this scenario with no master passphrase.

My idea was to have one last fail-safe backup of the master passphrase that is split w/ SSS with instructions for accessing in the will.

I haven't thought through this much, but one could split the master passphrase into say 5 parts and require 3 parts to recreate the password. These parts would be stored in 100% independent locations (separate from the wallets) and IMO I would feel comfortable making these much more geographically diverse as well as drop the requirement that I check on these backups yearly -- The likelihood that these backups will ever be needed is near zero.

tl;dr: the idea is to have a split master passphrase to avoid a disaster scenario where the owner dies and 2 locations are destroyed -- they can be stored in locations that are significantly less accessible and more geographically/politically diverse (e.g. in another country, buried in a forest lands)

Curious to hear your thoughts on that :)

On the 3rd paragraph, I was talking about shamir sharing a passphrase and expanded on it above. Very cool stuff re: schnorr and taproot. I agree with all your points about SSS being suboptimal compared to multisig and I think it's definitely best to steer folks towards multisig generally.

That being said, I do think a reasonable person might consider the following set up an improvement over the multisig protocols It's intentionally inconvenient and highly resilient. Depending on the person and who the intended recipients are it also might be considered less complex as its a single signature wallet (debatable how true this is now).

Shamir Secret Split your master seed into 7 parts, require 4 to restore. Say you have 1 part on you, 1 part at home, 1 part at your second home, 4 parts at 4 different safe deposit boxes. (I haven't thought through these numbers much)

What do you think about the general concept of that scheme?

It's not something I would personally advocate for, but if a colleague told me this was the strategy they had chosen... I'd think they just have different priorities and made different tradeoffs.

Thanks for engaging @fresheneesz

Humans are not very good at making random choices so check the See also section ...

I think that's a good idea. Mind creating a pull request for that?

e.g. Hawaii

Hey that's where I'm living at the moment!

thinking through this scenario

home location - X
safe deposit box A - X
safe depsoit box B - ./
you - X

So yeah, this would certainly be a bad scenario, but you're right, not an impossible one. Given enough people and time, its pretty likely to happen to someone.

have one last fail-safe backup of the master passphrase that is split w/ SSS .. say 5 parts and require 3 parts to recreate the password

So I'll have to write out my thoughts to really evaluate it:

3 nearbyish storage locations
5 disperse storage locations, checked on less frequently (every 5 years?). Let's say 1 is store in each of your nearby(ish) storage locations, and 2 are stored in more geographically distant locations. So this means 2 additional storage locations that are harder to setup and check on, but checked on less frequently.
The Shamir split key is still only useful with one of the storage locations containing two key-protected wallets, so their compromise isn't as bad as compromise of any of the 3 nearbish storage locations.

The passwordless redundancy here would be double (vs single in the current version).

So my proxy for difficulty as number of storage locations means I think this would be rather more difficult than the protocol as it stands. The question is: could we come up with an alternative that is less difficult and just as redundant? Eg what if we simply increased the multisig from 3-of-5 to 4-of-7 (and seeds from 3 to 4)? Let's say the last storage location stored HW Seed 3 and the Mobile seed, and we added HW Seed 3 into the Home safe as well.

This would add only a single additional storage location, while also increasing the redundancy to double. It would increase the effort needed to sign transactions, since you'd need an additional signature, but it would safe from the trouble and cost of managing an additional storage location. So there are some arguably minor trade offs here. I would lean towards fewer storage locations and take the hit in terms of the additional annoyance of needing an additional signature to sign transactions.

In the future, when bitcoin covenants are available, the redundancy will we very much amped up and make the downsides of additional seeds vs your proposed password sharding even less. Check out the Time-locked three-seed cold wallet for an example of what could be possible in the future. Basically, as long as you're willing to wait, funds will be recoverable with a single seed, while still maintaining just as good security as your standard 3-of-5.

I gtg right now, but I'll answer your third part later.

Shamir Secret Split your master seed into 7 parts, require 4 to restore.

It's intentionally inconvenient and highly resilient .. also might be considered less complex as its a single signature wallet

If you were to compare this to a 4 of 7 multisig wallet, I'd say its just as inconvenient to spend and it has the single-point-of-failure problem inherent to shamir. I think in general that would be less secure but I'm not sure if would have any significant upsides.

fresheneesz / TordlWalletProtocols

Master Passphrase Feedback #3