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
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7BB6BC0177
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Feb 2020 13:10:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 769DC20471
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Feb 2020 13:10:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id yBnTEX3JgEZS
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Feb 2020 13:10:34 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
[185.70.40.132])
by silver.osuosl.org (Postfix) with ESMTPS id 4924E2002A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Feb 2020 13:10:34 +0000 (UTC)
Date: Fri, 28 Feb 2020 13:10:27 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1582895431;
bh=g6Ehf0INwdsfI6kWp8SjCGq6wghKWIacqlWh1rNyoY4=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=BamhcaCiiGSPEWL7/xvByL3/H/mjpmD8dx0QZmeziEtIPXeQ1i4iZjHNdUYfaOExM
XtNqJvvyHD5zCIlOKj/TVJ5R5iRgOy/6S5KfLgjBoE8QuT5hpGcn1LV4GSWcrxAMSV
8aseLB0O6/mKswV8kTo7IXeEnthJeNQ8bzt4QsPE=
To: Christopher Allen <ChristopherA@lifewithalacrity.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <_sSKoYNq16XrlYLQpr-WnhdB0kgHzhg7tM0lwkh1Lj4gv70jng0WfHs_FmBxVKahR0lz5fxwCXp2okqR02XdW2F2WlQH1nLPTqfHJRqQpjs=@protonmail.com>
In-Reply-To: <CACrqygC0ONobnotfoM60F88xY-vm+v9kjO-A1_brMfSayjQKXg@mail.gmail.com>
References: <CAEcfjBRCA1sKcFC5M++WECsgYD-jDBYGuwxLfh0PSzRkCehEDA@mail.gmail.com>
<CAD5xwhgP=9-AvMOVO+-b9c3DZ_vYd-bPLYM26Qvawmcj28UOZw@mail.gmail.com>
<CACrqygC0ONobnotfoM60F88xY-vm+v9kjO-A1_brMfSayjQKXg@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Removing Single Point of Failure with Seed Phrase
Storage
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2020 13:10:36 -0000
Good morning Christopher,
>
> > As a replacement for paper, something like this makes sense v.s. what y=
ou do with a ledger presently.
> >
> > However, shamir's shares notoriously have the issue that the key does e=
xist plaintext on a device at some point.
> >
> > Non-interactive multisig has the benefit of being able to sign transact=
ions without having keys in the same room/place/device ever.
>
> I agree that that interactive multisig is best for transactional recovery=
, but there is still a place in our tool chest for Shamir split backups esp=
ecially in operational security scenarios, but as you state, you must be aw=
are of the limitations of Shamir, not only from the fact that there is vuln=
erability in that you must restore keys in one place, but also there are de=
nial edge cases where when you only have k-1 of n, someone can deny you kno=
wledge of who gave you the corrupted share.=C2=A0
>
> Right now the best C-library for Shamir sharding of recovery seeds is at =
the Blockchain Commons Github=C2=A0https://github.com/BlockchainCommons/sss=
/blob/master/README_slip39.md=C2=A0however, this code base needs refactorin=
g to be a good standalone library. This requires us separating out the Sham=
ir portions from the SLIP-39 mnemonic elements and command-line elements. W=
e also want to separate out the randomness portions of the code so you can =
test different implementations against deterministic randomness to ensure t=
hey give the same value (but don't use this for production!) Once this is c=
omplete, we will be submitting this library for formal review.
>
> We are also working on air-gapped open-source open hardware for seed crea=
tions and Shamir restoration. For instance, this device has no wifi, Blueto=
oth, or persistent memory, and the serial port is disabled. It is sized to =
fit in a bank safe deposit box. See=C2=A0https://twitter.com/ChristopherA/s=
tatus/1175465994644574208?s=3D20
>
> Longer-term for seed sharding, we want to leverage the VSS (Verifiable Se=
cret Sharing) that future Bitcoin musig uses, which we believe has advantag=
es over Shamir Secret Sharing. It can be used for both traditional sharding=
, but also for musig transactional recovery without restoring of master see=
ds on a single device, and it is easier to prove that shares are live and a=
void denial use cases.
>
> All this being said, we recommend Bitcoin multisig transactions as the be=
st solution for self-sovereign recovery of funds vs using Shamir (or SLIP39=
). Lately, we've been working on PSBT and bitcoind descriptor support in ou=
r alpha bitcoin wallet for iOS, FullyNoded 2=C2=A0https://github.com/Blockc=
hainCommons/FullyNoded-2=C2=A0=E2=80=94 in theory, this iOS wallet can faci=
litate any scenario that bitcoind supports as a descriptor as it communicat=
es with your own private full-node over Tor v3.
>
> P.S. If you've not seen it yet, our free #SmartCustody book http://bit.ly=
/SmartCustodyBookV101 offers what we think are current best practices for s=
ingle seed recovery. We did not include multisig scenarios in v1 of this bo=
ok as at the time they were too difficult and error-prone for most people. =
We are now working on v2 of the book which will cover multisign and fiducia=
ry scenarios now that PSBT is maturing and more wallets are improving multi=
sig support.
I believe you missed a point that Jeremy was making:
* In a Shamir Secret Sharing Scheme, at some point in the past, some device=
had to contain the actual original pre-shared secret, and that device migh=
t have had backdoors you were unaware of at the time that you were doing th=
e secret sharing.
* Thus the entire secret might already be compromised long before you rec=
over the secret again.
Verifiable Secret Sharing seems to be better in this regard, as each signer=
device can generate its own share independently of every other and effecti=
vely do an interactive setup to determine their public key (as I understand=
it --- I am not a mathist, and while I do have some notes regarding this f=
rom gmax, I confess I still have only a vague grasp of this math).
It may be better to outright forget Shamir Secret Sharing even exists, and =
prefer to use Verifiable Secret Sharing instead.
Regards,
ZmnSCPxj
|
