Date: Fri, 28 Feb 2020 13:10:27 +0000
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
Precedence: list

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