diff options
| author | Hugo Nguyen <hugo@nunchuk.io> | 2021-02-11 05:45:33 -0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-02-11 13:45:47 +0000 |
| commit | e09bf31dad6d1138720e0061e5205a724a72e312 (patch) | |
| tree | 28557546ed0151b525fbbbcd7d34c33bd0982776 | |
| parent | a9ba038a1f6cb464b6233f3afe84b66f1a408741 (diff) | |
| download | pi-bitcoindev-e09bf31dad6d1138720e0061e5205a724a72e312.tar.gz pi-bitcoindev-e09bf31dad6d1138720e0061e5205a724a72e312.zip | |
Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
| -rw-r--r-- | 27/fb39ad6c805db91b0e732372fc322887b0c454 | 293 |
1 files changed, 293 insertions, 0 deletions
diff --git a/27/fb39ad6c805db91b0e732372fc322887b0c454 b/27/fb39ad6c805db91b0e732372fc322887b0c454 new file mode 100644 index 000000000..6afa52e67 --- /dev/null +++ b/27/fb39ad6c805db91b0e732372fc322887b0c454 @@ -0,0 +1,293 @@ +Return-Path: <hugo@nunchuk.io> +Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 4D55AC013A + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 11 Feb 2021 13:45:47 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by whitealder.osuosl.org (Postfix) with ESMTP id 3B8678727C + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 11 Feb 2021 13:45:47 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +Received: from whitealder.osuosl.org ([127.0.0.1]) + by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id rhJNI26OA8m7 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 11 Feb 2021 13:45:46 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com + [209.85.222.47]) + by whitealder.osuosl.org (Postfix) with ESMTPS id 21F5687267 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 11 Feb 2021 13:45:46 +0000 (UTC) +Received: by mail-ua1-f47.google.com with SMTP id 67so1743719uao.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 11 Feb 2021 05:45:46 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=nunchuk-io.20150623.gappssmtp.com; s=20150623; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :cc; bh=PtEWSpewu+yZXE/11zsFEgFbz7E1g41LPbnhhiyBZI8=; + b=X8SdKfVhvOPdjraRrvlX4dok1B7OrRHfVgEptS3wsGj1NWASwA06Jyvitj3KJDHcGL + Ef+CBEiQlsugCn3vnLGPIfaMLDVCFoWAqlSBcewPcz3O34in/qgF+yAF2L2FTDNtuJeO + P1hcUq4lVy+jSRi6nt0SFQKGoXxeejuuI5Iyi6EoYoF6MNHM6Y2eQpHGVqAs3ZrdBJyC + zSZiLAdngiHqrBYfevCktr90ZRZzFuLVDD7hVt543MeSIkOErQcAoBL0CzXKQOdp9Vp/ + 6pizZD9sQoofb0aoVLY4bZKDYnzpDZkpdBJWqNMefhbSa4pK+l7ISLreu44qRFEUC6uS + LmhA== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to:cc; + bh=PtEWSpewu+yZXE/11zsFEgFbz7E1g41LPbnhhiyBZI8=; + b=uhBI9bVlVeqT22Lkz9Pe7kr2IifwqcsG5pjK3txpB+XMX4C8Ony3rOBTC0BtHLNQ8D + L1L3eljP3gONGaayN2SsmgLLbUZYvUoTbka7goGgp6WaAW/u0tseIl2ZBln1BaTyio5a + 9iYyR/1Vjnpj2WCuo4I6heU3tpR9zwEcXp442aSYfbY3/WwWy62olHRCnVQ2Hg55y8ys + /fuwcR+w9qvRQAroiHxNW+lW/nc2oJFWStwQ0HvfBXKbHNFn6GEpbZjzSONVq1033068 + z2irKaATQP87yD4xApnG8x6mrXfI1j4/KWUICbar286WahiUtIvFq8JAMGC6qH5+Vax8 + FXdg== +X-Gm-Message-State: AOAM532WdJ38dATfth9fMMuBpezSJT/2QM+sGq0WAh4nggl5lX6TBwam + s0jJkMSM4TGBMYs66lrtXw8qWFPcJPzPcRZxqQkrmHREmNO1HOJ3MdKjXA== +X-Google-Smtp-Source: ABdhPJzmRcT4Bw9quKr5ZHamZfqAAo9/T+1VglLJ3kqpbYoQTWz2fuKko+M6dR8XPBcvzW38maXzykOJ4nOr7qsj8a0= +X-Received: by 2002:ab0:274f:: with SMTP id c15mr5232677uap.12.1613051144952; + Thu, 11 Feb 2021 05:45:44 -0800 (PST) +MIME-Version: 1.0 +References: <CAPKmR9uyY70MhmVCh=C9DeyF2Tyxibux1E_bLPo00aW_h+OjLw@mail.gmail.com> + <CACrqygA1JRA293joYOxxpSepiuFD=uVvQQy3wpuosYyLQHff-A@mail.gmail.com> + <CAPKmR9tcR7gBfJ=EqJ60J=XvsreZgByL+HEfR0_YvwadJRWNhg@mail.gmail.com> + <CACrqygDhuateDtJMBSWd9sGRu1yzrZBw2yZ75OyKD1Xmzix3Cw@mail.gmail.com> + <CAPKmR9sUFJqsxKQS_x9rYZzkEO7hXr6vwAyPnysQPzA91TDjMA@mail.gmail.com> + <CAF90AvkeG53o5H2dZsdsG_c4PxxooMgx-Fv47RWpNNwm_su-hg@mail.gmail.com> +In-Reply-To: <CAF90AvkeG53o5H2dZsdsG_c4PxxooMgx-Fv47RWpNNwm_su-hg@mail.gmail.com> +From: Hugo Nguyen <hugo@nunchuk.io> +Date: Thu, 11 Feb 2021 05:45:33 -0800 +Message-ID: <CAPKmR9vg1BMDQWNDk41N4i4cJ8J6K9GuqSpstFpMFwyiVBYw-w@mail.gmail.com> +To: Pavol Rusnak <stick@satoshilabs.com> +Content-Type: multipart/alternative; boundary="0000000000007ff67a05bb0fbcfe" +X-Mailman-Approved-At: Thu, 11 Feb 2021 14:40:10 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup +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: Thu, 11 Feb 2021 13:45:47 -0000 + +--0000000000007ff67a05bb0fbcfe +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Hi Pavol, + +On Thu, Feb 11, 2021 at 5:25 AM Pavol Rusnak <stick@satoshilabs.com> wrote: + +> > ENCRYPTION_KEY =3D SHA256(SHA256(TOKEN)) +> +> This scheme might be vulnerable to rainbow table attack. +> + +Thank you for pointing this out! Incidentally, Dmitry Petukhov also told me +the same privately. + + +> +> The following scheme might be more secure: +> +> DESCRIPTION =3D ASCII description provided by user +> NONCE =3D 256-bit random number +> ENCRYPTION_KEY =3D hmac-sha256(key=3DNONCE, msg=3DDESCRIPTION) +> +> Coordinator distributes DESCRIPTION (fka TOKEN) together with NONCE to +> the signers. +> + +This does seem to add a lot more entropy. The challenge is to balance the +security requirement with UX. In the absence of some handshake protocol to +exchange the shared secrets (DESCRIPTION / NONCE) , the user will have to +enter these manually on the devices. I'll think about this some more. + + +> +> Also, is there any reason why you'd want to disable encryption? Why not +> keep that as mandatory? +> + +Making it mandatory would be nice, but IMHO not all use cases might require +encryption. For example, if you are setting up the multisig locally under a +safe environment you control, encryption might be an overkill. + +Best, +Hugo + + + +> +> +> On Tue, 9 Feb 2021 at 12:39, Hugo Nguyen via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> wrote: +> +>> +>> +>> On Tue, Feb 9, 2021 at 2:19 AM Christopher Allen < +>> ChristopherA@lifewithalacrity.com> wrote: +>> +>>> +>>> +>>> On Tue, Feb 9, 2021 at 2:06 AM Hugo Nguyen <hugo@nunchuk.io> wrote: +>>> +>>>> +>>>> I don't think reusing XPUBs inside different multisig wallets is a goo= +d +>>>> idea... For starters, loss of privacy in one wallet will immediately a= +ffect +>>>> privacy of other wallets. I think multisig wallets should be completel= +y +>>>> firewalled from each other. That means one unique XPUB per wallet. Thi= +s is +>>>> what we have been doing with the Nunchuk wallet. +>>>> +>>> +>>> To be clear, I have stated repeatedly that xpub reuse into multisig is = +a +>>> poor practice. However, finding a trustless solution when a wallet is +>>> airgapped with no network, or is stateless like Trezor, is quite hard. +>>> +>>> The challenge also includes how does an airgapped or stateless wallet +>>> know that it is talking to the same process on the other side that that= + it +>>> gave the xpub to in the first place. Without state to allow for a +>>> commitment, or at least a TOFU, a cosigner who thought he was part of a= + 3 +>>> of 5 could discover that he instead is in a 2 of 3, or in a script with= + an +>>> OR, as some form of scam. +>>> +>> +>> The shared secret approach that I mentioned in the proposal actually can +>> help you here. The TOKEN doubles as a session ID - thereby establishing = +a +>> common state on both sides. +>> +>> Best, +>> Hugo +>> +>> +>>> +>>> =E2=80=94 Christopher Allen +>>> +>>>> _______________________________________________ +>> bitcoin-dev mailing list +>> bitcoin-dev@lists.linuxfoundation.org +>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>> +> +> +> -- +> Best Regards / S pozdravom, +> +> Pavol "stick" Rusnak +> CTO, SatoshiLabs +> +> + +--0000000000007ff67a05bb0fbcfe +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div>Hi Pavol,</div><br><div class=3D"gmail_quote"><div di= +r=3D"ltr" class=3D"gmail_attr">On Thu, Feb 11, 2021 at 5:25 AM Pavol Rusnak= + <<a href=3D"mailto:stick@satoshilabs.com">stick@satoshilabs.com</a>>= + wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = +0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir= +=3D"ltr">>=C2=A0<span style=3D"color:rgb(0,0,0)">ENCRYPTION_KEY =3D SHA2= +56(SHA256(TOKEN))</span><div><span style=3D"color:rgb(0,0,0)"><br></span></= +div><div><span style=3D"color:rgb(0,0,0)">This scheme might be vulnerable t= +o rainbow table attack.</span></div></div></blockquote><div><br></div><div>= +Thank you for pointing this=C2=A0out! Incidentally, Dmitry Petukhov also to= +ld me the same privately. </div><div>=C2=A0</div><blockquote class=3D"gmail= +_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204= +,204);padding-left:1ex"><div dir=3D"ltr"><div><span style=3D"color:rgb(0,0,= +0)"><br></span></div><div><font color=3D"#000000">The following scheme migh= +t be more secure:</font></div><div><font color=3D"#000000"><br></font></div= +><div><font color=3D"#000000">DESCRIPTION =3D ASCII description provided by= + user</font></div><div><font color=3D"#000000">NONCE =3D 256-bit random num= +ber</font></div><div><font color=3D"#000000">ENCRYPTION_KEY =3D hmac-sha256= +(key=3DNONCE, msg=3DDESCRIPTION)</font></div><div><font color=3D"#000000"><= +br></font></div><div><font color=3D"#000000">Coordinator distributes=C2=A0<= +/font>DESCRIPTION (fka TOKEN) together with NONCE to the signers.</div></di= +v></blockquote><div><br>This does seem to add a lot more entropy. The chall= +enge is to balance the security requirement with UX. In the absence of some= + handshake protocol to exchange the shared secrets (DESCRIPTION / NONCE) , = +the user will have to enter these manually on the devices. I'll think a= +bout this some more.=C2=A0<br></div><div>=C2=A0</div><blockquote class=3D"g= +mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204= +,204,204);padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>Also, is t= +here any reason why you'd want to disable encryption? Why not keep that= + as mandatory?</div></div></blockquote><div><br>Making it mandatory would b= +e nice, but IMHO not all use cases might require encryption. For example, i= +f you are setting up the multisig locally under a safe environment you cont= +rol, encryption might be an overkill.<br><br>Best,<br>Hugo<br><br>=C2=A0</d= +iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord= +er-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>= +<font color=3D"#000000"><br></font></div></div><br><div class=3D"gmail_quot= +e"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, 9 Feb 2021 at 12:39, Hugo = +Nguyen via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat= +ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wr= +ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px= + 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D= +"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><div dir=3D= +"ltr" class=3D"gmail_attr">On Tue, Feb 9, 2021 at 2:19 AM Christopher Allen= + <<a href=3D"mailto:ChristopherA@lifewithalacrity.com" target=3D"_blank"= +>ChristopherA@lifewithalacrity.com</a>> wrote:<br></div><blockquote clas= +s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r= +gb(204,204,204);padding-left:1ex"><div><br></div><div><br><div class=3D"gma= +il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Feb 9, 2021 at 2:06= + AM Hugo Nguyen <<a href=3D"mailto:hugo@nunchuk.io" target=3D"_blank">hu= +go@nunchuk.io</a>> wrote:</div><blockquote class=3D"gmail_quote" style= +=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= +-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"auto"><b= +r>I don't think reusing XPUBs inside different multisig wallets is a go= +od idea... For starters, loss of privacy in one wallet will immediately aff= +ect privacy of other wallets. I think multisig wallets should be completely= + firewalled from each other. That means one unique=C2=A0XPUB per wallet. Th= +is is what we have been doing with the Nunchuk wallet.</div></div></div></b= +lockquote><div dir=3D"auto"><br></div><div dir=3D"auto">To be clear, I have= + stated repeatedly that xpub reuse into multisig is a poor practice. Howeve= +r, finding a trustless solution when a wallet is airgapped with no network,= + or is stateless like Trezor, is quite hard.</div><div dir=3D"auto"><br></d= +iv><div dir=3D"auto">The challenge also includes how does an airgapped or s= +tateless wallet know that it is talking to the same process on the other si= +de that that it gave the xpub to in the first place. Without state to allow= + for a commitment, or at least a TOFU, a cosigner who thought he was part o= +f a 3 of 5 could discover that he instead is in a 2 of 3, or in a script wi= +th an OR, as some form of scam.</div></div></div></blockquote><div><br></di= +v><div>The shared secret approach that I mentioned in the proposal actually= + can help you here. The TOKEN doubles as a session ID - thereby establishin= +g a common state on both sides.<br><br>Best,<br>Hugo</div><div>=C2=A0</div>= +<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= +left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class=3D"gmail_= +quote"><div dir=3D"auto"><br></div><div dir=3D"auto">=E2=80=94 Christopher = +Allen=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = +0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir= +=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"auto"></div></div></div></b= +lockquote></div></div> +</blockquote></div></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= +><div dir=3D"ltr"><div><div dir=3D"ltr"><div></div><div>Best Regards / S po= +zdravom,</div><div><br></div><div>Pavol "stick" Rusnak</div><div>= +CTO, SatoshiLabs</div><div><br></div></div></div></div></div> +</blockquote></div></div> + +--0000000000007ff67a05bb0fbcfe-- + |