Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 26C43C013A for ; 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 ; 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 ; 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 ; Thu, 11 Feb 2021 13:48:56 +0000 (UTC) Received: by mail-ot1-f53.google.com with SMTP id d7so5153050otq.6 for ; 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: In-Reply-To: From: Pavol Rusnak Date: Thu, 11 Feb 2021 14:25:08 +0100 Message-ID: To: Hugo Nguyen , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
>=C2=A0ENCRYPTION_KEY = =3D SHA256(SHA256(TOKEN))

<= /span>
This scheme might be vuln= erable to rainbow table attack.

The following scheme m= ight be more secure:

DESCRIPTION =3D ASCII description provided= by user
NONCE =3D 256-bit random = number
ENCRYPTION_KEY =3D hmac-sha= 256(key=3DNONCE, msg=3DDESCRIPTION)

Coordinator distributes=C2= =A0DESCRIPTION (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-d= ev <bitcoin-dev= @lists.linuxfoundation.org> wrote:


<= div class=3D"gmail_quote">
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 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.

=
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.

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>

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
=C2=A0

=E2=80=94 Christopher Allen=C2=A0
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--
Best Regards / S pozdravom,

Pavol "sti= ck" Rusnak
CTO, SatoshiLabs

=
--0000000000006ca5f505bb0f73c3--