path: root/27/fb39ad6c805db91b0e732372fc322887b0c454

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=
 &lt;<a href=3D"mailto:stick@satoshilabs.com">stick@satoshilabs.com</a>&gt;=
 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">&gt;=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&#39;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&#39;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 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; 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=
 &lt;<a href=3D"mailto:ChristopherA@lifewithalacrity.com" target=3D"_blank"=
>ChristopherA@lifewithalacrity.com</a>&gt; 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 &lt;<a href=3D"mailto:hugo@nunchuk.io" target=3D"_blank">hu=
go@nunchuk.io</a>&gt; 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&#39;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 &quot;stick&quot; Rusnak</div><div>=
CTO, SatoshiLabs</div><div><br></div></div></div></div></div>
</blockquote></div></div>

--0000000000007ff67a05bb0fbcfe--