1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
|
<pre>
BIP: XXXX
Layer: Applications
Title: Shamir secret sharing
Author: Bryan Bishop <kanzure@gmail.com>
Mark Friedenbach <mark@friedenbach.org>
Christopher Allen <ChristopherA@lifewithalacrity.com>
Chris Howe <chris@unchained-capital.com>
Yancy Ribbens
Hank Chu
ChiaWei Tan
Laurence Chen
Status: Draft
Type: Standards Track
Created: 2019-09-04
</pre>
==Abstract==
Social key recovery allows users to collaborate with each other to securely recover their secrets instead of using centralized account reset procedures. Shamir secret sharing can be used as an implementation of social key recovery, where a secret can be split into a number of shares with various threshold requirements or in the future any arbitrary monotone boolean function describing a recovery policy.
SatoshiLabs' SLIP 39 is one proposed implementation of Shamir secret sharing with mnemonics. SLIP 39 implements simple Shamir secret sharing plus a two-level fixed threshold group, including a mnemonic text encoding scheme and an encryption scheme as well.
This proposal is loosely inspired by SLIP 39 but makes some different decisions. In particular, this new proposal includes a binary format, additional metadata (such as birthdate), and greater flexibility of threshold specification. It also has some optional templates for pre-defined or pre-parameterized threshold requirements. The design is intended to make it possible to independently audit the independent parts of the proposal and make the proposal more modular. The proposal is intended to be compatible with future upgrades like verifiable secret sharing and MuSig.
A reference implementation is provided as well.
==Motivation==
Secure storage of secret keys is critically important to bitcoin users. Traditionally, users make at least one backup of their master secret or recovery information. By distributing this backup to multiple other individuals, such as friends and family members, the user is able to increase redundancy and backup integrity at the cost of allowing one of the trusted individuals to abscond with all of the funds. Instead, Shamir secret sharing provides a mechanism for a user to backup a secret split into shards and distribute those shards to a number of custodians in a manner that can prevent loss even if one or a few of those parties become compromised.
**TODO**: add text about why SLIP 39 is insufficient
It is also desirable for a Shamir secret sharing proposal to be forwards compatible with future upgrades like verifiable secret sharing and MuSig.
==Shamir secret sharing==
**TODO**: rewrite
Shamir secret sharing (SSS) is a cryptographic mechanism describing how to split a secret into *N* unique parts, where any *T* of them are required to reconstruct the secret. First, a polynomial *f* of degree *T* − 1 is constructed and each party is given a corresponding point - an integer input *x* to the polynomial and the corresponding output *f*(*x*).
When any *T* points are provided, they exactly define the polynomial. Usually the value of the polynomial *f*(0) is used as the shared secret. In this specification the shared secret is stored as *f*(255). More details on SSS can be found on [Wikipedia](https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing).
Note that it is important to understand that the secret must be reassembled on a single machine or by a single user. Hence, the scheme always reduces to 1-of-n. Ideally this 1-of-n individual is the original user, which makes this scheme particularly useful for password recovery.
==Verifiable secret sharing==
==Key derivation==
==Encryption==
==Shard lifecycle==
==Multisig vs SSS===
**TODO**: insert text about multisig vs SSS, and multisig vs VSS.
==Reference implementation==
==Test vectors==
==Glossary==
Shard dealer: An individual that has a secret that is sharded using this secret sharing scheme. The user makes a number of shards that are dealt out to different users to turn each user into a shard custodian.
Deck: A collection of shards that together can be combined (in at least one way) to reconstruct the sharded secret.
Deck identifier: Derived from the sharded secret. It is the public key derived from the sharded secret unmodified with no derivation and no other modification. The deck identifier is a public key that uniquely identifies the deck. This key can sign each shard.
Script policy: A script that specifies a policy for how the deck's secret (seed entropy) can be reconstructed from some combination of shards.
Quorum: Any set of shards sufficient to meet the script policy for reconstruction.
Shard: A shard includes unencrypted metadata, an unencrypted Y value ("shard value"), checksum, and private encrypted data.
Shard unencrypted metadata (public metadata): Data associated with a shard that describes the shard and the deck among other things. This includes birthdate, deck identifier information, and so on.
Shard value: The mathematical or cryptographic value that can be used in the secret sharing scheme to reconstruct the sharded secret. This is the Y value.
Private data (encrypted) (encrypted blob or deck blob): Encrypted data transferred with each shard. The decryption key can be computed by recombining all the shards.
Shard custodian: A user that holds a number of shards, possibly from multiple different decks.
Shard pool: A shard custodian can use software that implements a shard pool that contains their collection of shards they are responsible for. The shard pool allows for querying over the set of shards to find particular shards to respond to a request.
Sharded secret: Used to create the derived secret. This is used both as symmetric key and as a private key. This is a high entropy secret.
Derived secret: The derived secret is used to decrypt the identical private data associated with each shard.
==References==
|
