Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7BB6BC0177 for ; 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 ; 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 ; 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 ; 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 , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <_sSKoYNq16XrlYLQpr-WnhdB0kgHzhg7tM0lwkh1Lj4gv70jng0WfHs_FmBxVKahR0lz5fxwCXp2okqR02XdW2F2WlQH1nLPTqfHJRqQpjs=@protonmail.com> In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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