Skip to content

Shamir's Secret Sharing (SSS) and Slip39 #407

@thewhaleking

Description

@thewhaleking

From Trexman:
Good morning all! Looking forward to chatting in a bit. What do y'all think of this crazy idea for a BTCLI feature?

What if Shamir's Secret Sharing (SSS) and Slip39 were built right into BTCLI? SSS is a way of splitting a secret (e.g. the seed phrase) into multiple, equally strong secrets, that must be combined as 'shares' to recover the original secret (similar to a multisig, but for private key, not public key). I think this could eliminate the risk of screen reader and key logger malware attacks, since the seed phrase need never be exposed on the screen or entered into the keyboard. It can also reduce the risk of key loss since you can recover the key with some number of shares.
You would create a wallet like:

btcli wallet new-coldkey --to-slip-39-shares --shares= --threshold= --shares-destinations=[,,,}, ...]

And this would generate a new coldkey, but never expose the seed phrase in plaintext, instead using shamir's secret sharing and slip39 to split it into N shares (each in the form of a seed phrase, which is just as cryptographically strong as the original), which could be piped into encrypted drives and optionally encrypted with an additional passphrase. The encrypted drives, each of which contains some number of shares, could then be distributed to separate custody (different teammates or just different secure storage solutions).

To perform any coldkey operation, you would do something like:
btcli stake add --key-from-slip-39-shares --shares-sources=[,,..]

Shares could be combined to recover the seed phrase, recover the coldkey private key and sign the transaction all in memory without ever exposing the seed phrase.

Maybe you could also use --to-slip-shares with --shares-destination=stdout, in order to just write out the seed phrase shares by hand and distribute them to custody that way, if you prefer paper to drives (and for practice/test), but that would have the disadvantage of having the full recovery input exposed in one place (in case of screen reader/camera/over the shoulder attack, and also making the admin that performs the operation a single point of failure). But it would support paper backups without having to put the shares onto USB drives, if that is considered an advantage.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions