Shamir Secret Sharing Scheme feature

[iancoleman]

See this reddit thread:

https://www.reddit.com/r/Bitcoin/comments/6fw565/using_shamirs_secret_sharing_scheme_ssss_with/

[aChrisYouKnow]

This would be a fantastic feature. I wouldn't be opposed to chipping in for it's development. Any estimate as to where this sits priority wise compared to other potential features? Thanks.

[iancoleman]

This is not high priority.

Bitcoin wallet backups have been getting progressively better, from random keypool, to hd bip32 keys, to bip39 mnemonics. Each one has made creating backups safer and simpler.

Introducing ssss is a step backward in usability, so it's not a high priority job.

In the meantime there's this tool - https://iancoleman.github.io/shamir/

It's most likely I'll improve the existing shamir tool and provide an easy way to utilise it from the bip39 tool, rather than incorporate shamir directly.

The other reason I'm hesitant is ssss doesn't have a standard implementation or export format, so there's no interoperability. This is a massive downside. There's no point being dependent on some esoteric piece of software as part of the [in]security of secrets.

Glad to see there's interest though. Thanks for commenting.

[aChrisYouKnow]

The main benefit I see regarding the reddit thread above vs. your existing SSSS tool, is the human readable aspect. The use case I envision is on an air gapped machine, using SSSS to split a hardware wallet's bip39 mnemonic into pieces which are also human readable and easy to write down. Currently the pieces can't simply be written down without lots of care and high likelihood of making a mistake. Saving the pieces to a flash drive is the best bet. I see a number of small downsides with that both from a security standpoint, but also an ease of storage standpoint. Its easier to determine if written or etched text is still legible instead of checking to make sure a flash drive is still operating properly.

The lack of standard implantation is certainty the largest downside. Saving multiple copies of the software used and making sure those were accessible long-term would be key.

I really wish trezor/ledger/keepkey/etc. would integrate a way to export m of n pieces of a key during the initial wallet creation. Granted, that would still require some sort of standard method to be agreed one.

Thanks for your contributions to the space. Your tools are great.

[iancoleman]

I did some basic prototyping.

Assume an original mnemonic of 15 words, which is 165 bits.

This 165 bits is split using ssss into 3 of 5.

Each part is 176 bits (44 hex chars, not including the shamir metadata).

Depending how each part is encoded into a mnemonic, each part will have 16 words (19 including metadata)

So a 15 word mnemonic split into 3 of 5 shamir parts makes a total of 95 words to record.

It's not a terrible idea, but 95 words is quite a lot. Still, the main barrier is a lack of a standard.

[thinkloop]

Bitcoin wallet backups have been getting progressively better, from random keypool, to hd bip32 keys, to bip39 mnemonics. Each one has made creating backups safer and simpler. Introducing ssss is a step backward in usability, so it's not a high priority job.

BIP39/BIP32 seem complimentary to ssss since the process of distributing shamir parts to trusted people is time-consuming, and thanks to those bips, it only has to be done once. Without them, new shamir parts would have to be created and distributed after every pool of transactions.

Once you have a mnemonic encrypted with a passphrase, how do you backup the passphrase in case of death/incapacitation? If you keep it with the mnemonic you create a single-point of theft. Storing 1 at home and 1 at the office is weak. Storing it in a safety deposit box exposes you to banks and politics. Isn't ssss one of the safest ways to backup, and complimentary to HD et al? What options are there besides shamir?

[iancoleman]

I've developed a prototype and draft specification for this which I'll have up in the next day or two.

But to answer the question about options besides shamir... I think something like BIP45 is a good alternative (multisig using separate mnemonics for each part). But BIP45 has already been abandoned by the creators (see copay issue 2866) so ... there's still no accepted standard for this.

This is a section from the unpublished draft proposal for shamir mnemonics I've been working on:

Alternatives

A scheme such as BIP45 (HD multisig wallets) targets separation of secrets at the transaction layer, whereas this proposal targets the key storage layer. Multisig wallets have the benefit of not requiring the secrets to be merged, ie a transaction can be signed progressively in isolation by each party until enough signatures have been accumulated to broadcast the transaction. In contrast, SSSS requires parties to combine their secrets into a single secret, which must then be handled by a 'leader' of the group to finally sign any transactions using the combined secret.

[aChrisYouKnow]

Just wanted to chime in and say thanks again for your continued efforts on this.

[iancoleman]

Prototype is online: https://iancoleman.github.io/shamir39/

Please continue any further discussions at https://github.com/iancoleman/shamir39/issues

Thanks to everyone for the motivation to make this happen. Even if nothing comes of it, it's been a really interesting tangent to explore.

[yonderblue]

@iancoleman I appreciate your work here, and with your other tools. Have you considered a BIP to get this formalized to spark some other implementations?

I am wondering why you are suggesting multisig as an alternative? For backing up a hardware wallet (or cold storage) seed this seems ideal, but perhaps you meant a different use case? To securely store coins I know it's possible to use m of n multisig with n seeds being stored instead of shamir shares of a single seed. In the case one of the parts is compromised and there is a desire to move the coins, multisig seems to have some tradeoffs. Any time you spend you have to do it multisig fashion, just to get the benefit of storing multiple seeds. You don't have to bring together all the parts on a single machine like shamir, but if using an airgapped machine just for restoring a hardware wallet it seems easier. Plus I don't think there is enough support out there for multisig tools.

Trying to safely backup a seed offline is a challenge to me and being able to use shamir without printing anything out or hand copying large hex seems valuable.

[iancoleman]

Thanks for the feedback.

Have you considered a BIP to get this formalized to spark some other implementations?

There is work already underway to establish a bip for this. No idea when it'll be ready to publish though.

I am wondering why you are suggesting multisig as an alternative?

This is mostly with respect to managing handover in a multiuser situation. For a single user situation shamir39 is fine.

For example consider a hostile situation such as the owner dies suddenly and shares are distributed among several now-dysfunctional business partners. It's much simpler and safer to coordinate progressive signing of a multisig transaction than it is to coordinate the combination of shamir shares. So I probably recommend multisig over shamir in the case where handover may be required (which it always will if considered over a long enough timeframe).

if using an airgapped machine just for restoring a hardware wallet it [shamir] seems easier

Agreed, assuming sufficient parties will cooperate and trust each other.

I don't think there is enough support out there for multisig tools.

Definitely agree. I should spend more time expanding the functionality of my multisig tool. Having a simple offline multisig preview and signing tool would be really handy in lots of situations.