From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4D55AC013A for ; 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 ; 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 ; 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 ; Thu, 11 Feb 2021 13:45:46 +0000 (UTC) Received: by mail-ua1-f47.google.com with SMTP id 67so1743719uao.1 for ; 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: In-Reply-To: From: Hugo Nguyen Date: Thu, 11 Feb 2021 05:45:33 -0800 Message-ID: To: Pavol Rusnak Content-Type: multipart/alternative; boundary="0000000000007ff67a05bb0fbcfe" X-Mailman-Approved-At: Thu, 11 Feb 2021 14:40:10 +0000 Cc: Bitcoin Protocol Discussion 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: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 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 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
Hi Pavol,

On Thu, Feb 11, 2021 at 5:25 AM Pavol Rusnak= <stick@satoshilabs.com>= wrote:
>=C2=A0ENCRYPTION_KEY =3D SHA2= 56(SHA256(TOKEN))

This scheme might be vulnerable t= o rainbow table attack.

= Thank you for pointing this=C2=A0out! Incidentally, Dmitry Petukhov also to= ld me the same privately.
=C2=A0

The following scheme migh= t be more secure:

DESCRIPTION =3D ASCII description provided by= user
NONCE =3D 256-bit random num= ber
ENCRYPTION_KEY =3D hmac-sha256= (key=3DNONCE, msg=3DDESCRIPTION)
<= br>
Coordinator distributes=C2=A0<= /font>DESCRIPTION (fka TOKEN) together with NONCE to the signers.

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

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

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.

Best,
Hugo

=C2=A0
=

On Tue, 9 Feb 2021 at 12:39, Hugo = Nguyen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wr= ote:


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 <hu= go@nunchuk.io> wrote:
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.

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.

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.

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.

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 po= zdravom,

Pavol "stick" Rusnak
= CTO, SatoshiLabs

--0000000000007ff67a05bb0fbcfe--