From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Christopher Allen <ChristopherA@lifewithalacrity•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Removing Single Point of Failure with Seed Phrase Storage
Date: Fri, 28 Feb 2020 13:10:27 +0000 [thread overview]
Message-ID: <_sSKoYNq16XrlYLQpr-WnhdB0kgHzhg7tM0lwkh1Lj4gv70jng0WfHs_FmBxVKahR0lz5fxwCXp2okqR02XdW2F2WlQH1nLPTqfHJRqQpjs=@protonmail.com> (raw)
In-Reply-To: <CACrqygC0ONobnotfoM60F88xY-vm+v9kjO-A1_brMfSayjQKXg@mail.gmail.com>
Good morning Christopher,
>
> > As a replacement for paper, something like this makes sense v.s. what you do with a ledger presently.
> >
> > However, shamir's shares notoriously have the issue that the key does exist plaintext on a device at some point.
> >
> > Non-interactive multisig has the benefit of being able to sign transactions 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 especially in operational security scenarios, but as you state, you must be aware of the limitations of Shamir, not only from the fact that there is vulnerability in that you must restore keys in one place, but also there are denial edge cases where when you only have k-1 of n, someone can deny you knowledge of who gave you the corrupted share.
>
> Right now the best C-library for Shamir sharding of recovery seeds is at the Blockchain Commons Github https://github.com/BlockchainCommons/sss/blob/master/README_slip39.md however, this code base needs refactoring to be a good standalone library. This requires us separating out the Shamir portions from the SLIP-39 mnemonic elements and command-line elements. We also want to separate out the randomness portions of the code so you can test different implementations against deterministic randomness to ensure they give the same value (but don't use this for production!) Once this is complete, we will be submitting this library for formal review.
>
> We are also working on air-gapped open-source open hardware for seed creations and Shamir restoration. For instance, this device has no wifi, Bluetooth, or persistent memory, and the serial port is disabled. It is sized to fit in a bank safe deposit box. See https://twitter.com/ChristopherA/status/1175465994644574208?s=20
>
> Longer-term for seed sharding, we want to leverage the VSS (Verifiable Secret Sharing) that future Bitcoin musig uses, which we believe has advantages over Shamir Secret Sharing. It can be used for both traditional sharding, but also for musig transactional recovery without restoring of master seeds on a single device, and it is easier to prove that shares are live and avoid denial use cases.
>
> All this being said, we recommend Bitcoin multisig transactions as the best solution for self-sovereign recovery of funds vs using Shamir (or SLIP39). Lately, we've been working on PSBT and bitcoind descriptor support in our alpha bitcoin wallet for iOS, FullyNoded 2 https://github.com/BlockchainCommons/FullyNoded-2 — in theory, this iOS wallet can facilitate any scenario that bitcoind supports as a descriptor as it communicates 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 single seed recovery. We did not include multisig scenarios in v1 of this book 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 fiduciary scenarios now that PSBT is maturing and more wallets are improving multisig 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 might have had backdoors you were unaware of at the time that you were doing the secret sharing.
* Thus the entire secret might already be compromised long before you recover 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 effectively 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 from 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
next prev parent reply other threads:[~2020-02-28 13:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-26 13:02 Contact Team
2020-02-26 19:56 ` Jeremy
2020-02-26 20:26 ` Christopher Allen
2020-02-28 13:10 ` ZmnSCPxj [this message]
2020-03-06 11:11 ` Russell O'Connor
2020-08-03 22:49 ` [bitcoin-dev] On the compatibility of Bech32 and Shamir's Secret Sharing Russell O'Connor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='_sSKoYNq16XrlYLQpr-WnhdB0kgHzhg7tM0lwkh1Lj4gv70jng0WfHs_FmBxVKahR0lz5fxwCXp2okqR02XdW2F2WlQH1nLPTqfHJRqQpjs=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=ChristopherA@lifewithalacrity$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox