path: root/01/018ba9081af5cc1959e1ca73206e997260d797

Return-Path: <stick@satoshilabs.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 26C43C013A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Feb 2021 13:49:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 0037F6F4D6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Feb 2021 13:48:59 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id bplxZAOntnpU
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Feb 2021 13:48:58 +0000 (UTC)
Received: by smtp3.osuosl.org (Postfix, from userid 1001)
 id 6EB3D6F4F8; Thu, 11 Feb 2021 13:48:58 +0000 (UTC)
X-Greylist: delayed 00:23:37 by SQLgrey-1.8.0
Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com
 [209.85.210.53])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 509E66E987
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Feb 2021 13:48:56 +0000 (UTC)
Received: by mail-ot1-f53.google.com with SMTP id d7so5153050otq.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Feb 2021 05:48:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=satoshilabs.com; s=google;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=e5aejiMcvYueVdkQbSiDAUbsjwOluDEeMSRR6W93IhE=;
 b=hs2f+berlux2AZR3kL0GgqscjasofrQEGkenQdFuSkK/V6PAeOkYWOVMvR5+2CPY/Q
 CrQbzEu/kSjfC4poO3dGB4bFFvO8hNbTI3w0ANKcfQAlaS6g2ChyrLEoADHUxt48uUHi
 vWVshKF3JPYhrmKxnzY0YpXZBCATEveIrndkf/GageU6CEgDVA8wd62tRzEo7+Pysvx1
 UCFD5/1Y9Y2PG9AmHZdK3GLwFvtl31UfUHEsgxCh3wb7Pn2a/WTP7M1T0hnJscJcNDrX
 Ql5SwBPaDGem0NYxsIFEq/Z9FlqArI1msoOHhTxT1gU0yCHFGtoxjBwzdBbOMfUnwzCb
 0xTg==
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=e5aejiMcvYueVdkQbSiDAUbsjwOluDEeMSRR6W93IhE=;
 b=FLUdkzm3dDoLTIbtUS155Fp2ILC3z9vld0deCIeMM78lBb6jSE6yI1VOzajl6XnD5l
 j5lXeXI0O/mkQJTP9fcLF/z0V8xIw6R/r+bjksUXl990SpvQl7NVRal4r/uK9vlobA0F
 SYZOnbJYQ98cNlNMC/45ZSW/6APZ7mYfe3gWhU3MF8NH6bOq3aDQ+Qn2ps8K4EvPN9Ud
 2bmZErtQcVuobYFJL1h9CjrOT2BXXuxQiQtPIDSdlRtYmeZZVm9O4AMdVlqSzfb9SrmB
 lcXHO7/Cd2wYlyuumXWPTr9Xx9ete0J5C3u7TWx7GBwBhV+p28IqDK61NWc4ZCbqScfp
 XvSQ==
X-Gm-Message-State: AOAM530DYbkXl5ZWg5Tl7LecAsvJEo9iDk0SHSJyk4OyZfS9KJekQtJS
 2AGO4XnWO+p4qKeSk2OXrAG74PFlp7d+t0pomfj/xmSXgPwl9FeG
X-Google-Smtp-Source: ABdhPJy7zH2rLyAc9v7+ZJWLC6mnXaHBD+Xr5JebBg5cHhCacgWlSYZQPe3s8ejLfEQps2mVcVfZy5p6MzbDzcGWTlU=
X-Received: by 2002:a05:6830:1d63:: with SMTP id
 l3mr5672811oti.314.1613049918951; 
 Thu, 11 Feb 2021 05:25:18 -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>
In-Reply-To: <CAPKmR9sUFJqsxKQS_x9rYZzkEO7hXr6vwAyPnysQPzA91TDjMA@mail.gmail.com>
From: Pavol Rusnak <stick@satoshilabs.com>
Date: Thu, 11 Feb 2021 14:25:08 +0100
Message-ID: <CAF90AvkeG53o5H2dZsdsG_c4PxxooMgx-Fv47RWpNNwm_su-hg@mail.gmail.com>
To: Hugo Nguyen <hugo@nunchuk.io>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000006ca5f505bb0f73c3"
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:49:00 -0000

--0000000000006ca5f505bb0f73c3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> ENCRYPTION_KEY =3D SHA256(SHA256(TOKEN))

This scheme might be vulnerable to rainbow table attack.

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.

Also, is there any reason why you'd want to disable encryption? Why not
keep that as mandatory?


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 good
>>> idea... For starters, loss of privacy in one wallet will immediately af=
fect
>>> privacy of other wallets. I think multisig wallets should be completely
>>> firewalled from each other. That means one unique XPUB per wallet. This=
 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
>


--=20
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs

--0000000000006ca5f505bb0f73c3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;=C2=A0<span style=3D"color:rgb(0,0,0)">ENCRYPTION_KEY =
=3D SHA256(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 vuln=
erable to rainbow table attack.</span></div><div><span style=3D"color:rgb(0=
,0,0)"><br></span></div><div><font color=3D"#000000">The following scheme m=
ight 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 =
number</font></div><div><font color=3D"#000000">ENCRYPTION_KEY =3D hmac-sha=
256(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>=
<div><br></div><div>Also, is there any reason why you&#39;d want to disable=
 encryption? Why not keep that as mandatory?</div><div><font color=3D"#0000=
00"><br></font></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Tue, 9 Feb 2021 at 12:39, Hugo Nguyen via bitcoin-d=
ev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev=
@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,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@li=
fewithalacrity.com" target=3D"_blank">ChristopherA@lifewithalacrity.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=
><br></div><div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gm=
ail_attr">On Tue, Feb 9, 2021 at 2:06 AM Hugo Nguyen &lt;<a href=3D"mailto:=
hugo@nunchuk.io" target=3D"_blank">hugo@nunchuk.io</a>&gt; wrote:</div><blo=
ckquote 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"><br>I don&#39;t think reusing XPUBs insi=
de different multisig wallets is a good idea... For starters, loss of priva=
cy in one wallet will immediately affect privacy of other wallets. I think =
multisig wallets should be completely firewalled from each other. That mean=
s one unique=C2=A0XPUB per wallet. This is what we have been doing with the=
 Nunchuk wallet.</div></div></div></blockquote><div dir=3D"auto"><br></div>=
<div dir=3D"auto">To be clear, I have stated repeatedly that xpub reuse int=
o 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.</div><div dir=3D"auto"><br></div><div dir=3D"auto">The challenge als=
o includes how does an airgapped or stateless wallet know that it is talkin=
g to the same process on the other side that that it gave the xpub to in th=
e 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 inst=
ead is in a 2 of 3, or in a script with an OR, as some form of scam.</div><=
/div></div></blockquote><div><br></div><div>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.<br><br=
>Best,<br>Hugo</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div><div class=3D"gmail_quote"><div dir=3D"auto"><br></div><di=
v 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(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><d=
iv dir=3D"auto"></div></div></div></blockquote></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"=
 class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div></di=
v><div>Best Regards / S pozdravom,</div><div><br></div><div>Pavol &quot;sti=
ck&quot; Rusnak</div><div>CTO, SatoshiLabs</div><div><br></div></div></div>=
</div></div>

--0000000000006ca5f505bb0f73c3--