path: root/b2/cb01ee41b86ff4fe78af089e7e1dd8c85d9e4d

Return-Path: <dp@simplexum.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D5A29C013A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 14 Feb 2021 11:23:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id BCD306F4F0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 14 Feb 2021 11:23:22 +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 zhSVOPxI2SJT
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 14 Feb 2021 11:23:21 +0000 (UTC)
Received: by smtp3.osuosl.org (Postfix, from userid 1001)
 id 38F6D6F500; Sun, 14 Feb 2021 11:23:21 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail.ruggedbytes.com (mail.ruggedbytes.com [88.99.30.248])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 417626F4F0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 14 Feb 2021 11:23:18 +0000 (UTC)
Received: from mail.ruggedbytes.com (localhost [127.0.0.1])
 by mail.ruggedbytes.com (Postfix) with ESMTPS id 870AF260023D;
 Sun, 14 Feb 2021 11:23:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com;
 s=mail; t=1613301796;
 bh=tYOJW0y4RXQNhXvjHewP7gU6PrjoY685aoRH65U8lDs=;
 h=Date:From:To:Cc:Subject:In-Reply-To:References;
 b=iFLWgh473NLRRqUqMMV0CxSPqm0Mc6HBsTISPnrGdBaC/OWFfqZi7Y2zrse0azNJR
 hir1ee5E6NHZ6Us+Ow0dqJfdkwBNGckXPqTRwnOtPtSaVY5JeTsKUoEuUBTNIeZ9tP
 PJI000aI1s1J1GFiC52okAXyChBUdvoGcJLrtSN4=
Date: Sun, 14 Feb 2021 12:28:58 +0100
From: Dmitry Petukhov <dp@simplexum.com>
To: Hugo Nguyen <hugo@nunchuk.io>
Message-ID: <20210214122858.54de7bcc@simplexum.com>
In-Reply-To: <20210214113752.0a255161@simplexum.com>
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>
 <CAPKmR9vg1BMDQWNDk41N4i4cJ8J6K9GuqSpstFpMFwyiVBYw-w@mail.gmail.com>
 <20210211172910.3b550706@simplexum.com>
 <CAPKmR9v5jzsu7siuyAu42XOCdtXqMXmKzmiDzjEy_bVNbSPyyw@mail.gmail.com>
 <20210212184231.22b517aa@simplexum.com>
 <CAPKmR9uUv32AbSUv9C-JvzEQo5WQb+a6iPSBWTnY1wwKwGaDng@mail.gmail.com>
 <20210214113752.0a255161@simplexum.com>
Organization: simplexum.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sun, 14 Feb 2021 12:07:16 +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: Sun, 14 Feb 2021 11:23:22 -0000

After off-list discussion with Hugo, I'm convinced that
adding a requirement for signers to derive participant ids is
unnecessary complication that only buys slight convenience for
coordinator, and this is not a net positive tradeoff.

And since the coordinator can choose to generate unique TOKEN per
participant without participants even knowing about this, there's
probably no reason to mention this possibility in the spec, either.

=D0=92 Sun, 14 Feb 2021 11:37:52 +0100
Dmitry Petukhov <dp@simplexum.com> wrote:

> I think that it is better to issue individual TOKEN for each
> participant. Otherwise it will be possible for one participant to
> attack another (intercept and replace their xpub sent to the
> coordinator).
>=20
> It will also be convenient to have a public 'participant id', derived
> from the token. It can be derived from the same token, but with
> different (but fixed) `Pwd`. With unique token per participant, such
> derivation will uniquely identify each participant, so the coordinator
> won't need to try all the tokens to decrypt the data.
>=20
> It will also be easier to deal with more elaborate setups where the
> position of the xpub in the descriptor does matter - for example, with
> miniscript-extended descriptors. With a descriptor template such as
>=20
> `wsh(or(multi(2, <Alice>, <Bob>, <Carol>), older(1000, <Dylan>))`
>=20
> The coordinator will be able to store the map between the participant
> labels (Alice, Bob, Carol, Dylan) and their participant ids (and the
> TOKENs). When the data from Alice comes with participant id attached,
> the coordinator will immediately know which TOKEN to use, and which
> place in the descriptor the xpub should be put in.
>=20
> Of course this is all possible without 'participant id' derived from
> token, as long as there's unique TOKEN per participant - the
> coordinator can always try all the tokens to decrypt the data from
> participant. But implementors will likely invent their own ways to
> introduce 'participant id' anyway, as this is more convenient, and it
> might make sense to have this standardized, for interoperability.=20
>=20
> =D0=92 Fri, 12 Feb 2021 09:54:57 -0800
> Hugo Nguyen <hugo@nunchuk.io> wrote:
>=20
> > On Fri, Feb 12, 2021 at 9:36 AM Dmitry Petukhov <dp@simplexum.com>
> > wrote:
> >  =20
> > > If HUMAN_READABLE_TITLE is the additional secret, the user would
> > > need to enter it on the device in addition to the nonce, wouldn't
> > > it defeat the advantage in UX that was gained by using
> > > (relatively) short nonce ?
> > >
> > > Is 64 bit nonce not enough ?
> > >
> > >   =20
> > Good question. If we don't need the extra entropy, we can fix
> > the HUMAN_READABLE_TITLE string.
> >=20
> > Something like "No SPOF". (No Single Point Of Failure).
> >=20
> >=20
> >  =20
> > > It seems that to crack this with fixed Pwd and 64 bit nonce, the
> > > attacker will need to be about 10^15 more powerful than 80Mhz MCU:
> > > (2^64)/(0.3*10^15)/3600 =3D 17 hours. I don't know if 10^15 is
> > > realistic scale. Average desktop cpu seems to be about 10^3 more
> > > powerful than the mentioned MCU for this task.
> > >
> > > Maybe for the UX it would be better to choose the number of rounds
> > > to use in PBKDF2, instead of using variable Pwd. Number of rounds
> > > will be easier to enter on the device (or just choose it from a
> > > set of pre-defined values). The more money is at stake, the higher
> > > number of rounds could the coordinator choose (taking into account
> > > the characteristics of the participant devices)
> > >   =20
> >  =20
> > > Or simply allow bigger entropy (more than 6 mnemonic words), if
> > > the coordinator feels that 64 bit of entropy is not enough.   =20
> >=20
> >=20
> > That could work. Allowing variable iteration count is probably
> > better UX-wise.
> >=20
> > Best,
> > Hugo
> >=20
> >  =20
> > >
> > > =D0=92 Fri, 12 Feb 2021 08:55:55 -0800
> > > Hugo Nguyen <hugo@nunchuk.io> wrote:
> > >   =20
> > > > Thanks everyone who has provided inputs so far!
> > > >
> > > > This is the new proposal for the encryption aspect of the
> > > > scheme, based on all the feedback.
> > > >
> > > > The key derivation function would be PBKDF2, with PRF =3D SHA512.
> > > > This should be readily available on today's hardware already, as
> > > > they are used for BIP39.
> > > >
> > > > DK =3D PBKDF2(PRF, Password, Salt, c, dkLen)
> > > > PRF =3D SHA512
> > > > Pwd =3D HUMAN_READABLE_TITLE
> > > > Salt =3D NONCE
> > > > c =3D 2048
> > > > dkLen =3D 256
> > > >
> > > > HUMAN_READABLE_TITLE is in ASCII format, minimum length =3D 8,
> > > > maximum length =3D 20.
> > > > NONCE is a 64-bit number.
> > > >
> > > > Reason for going with SHA512 is due to legacy support on some
> > > > hardware. c=3D2048 also mimics BIP39. It takes about ~3 seconds to
> > > > derive the encryption key on a 80Mhz MCU. We feel like this is a
> > > > good enough tradeoff for this use case. The assumption here is
> > > > that the secure session is only needed temporarily for a few
> > > > hours, maybe up to one day.
> > > >
> > > > The Coordinator and Signers agree and exchange these 2 secrets
> > > > prior to the setup. The NONCE can be converted to either:
> > > > (a) a 6-word phrase using BIP39 wordlist
> > > > (b) a 20-digit decimal number
> > > > (c) a QR code
> > > >
> > > > Depending on the vendor. This flexibility in the data format
> > > > allows each vendor to customize the UX based on their respective
> > > > device capabilities.
> > > >
> > > > Best,
> > > > Hugo
> > > >
> > > > On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev
> > > > < bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > >   =20
> > > > > =D0=92 Thu, 11 Feb 2021 05:45:33 -0800
> > > > > Hugo Nguyen via bitcoin-dev
> > > > > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > > >   =20
> > > > > > > > ENCRYPTION_KEY =3D SHA256(SHA256(TOKEN))   =20
> > > > > > >
> > > > > > > This scheme might be vulnerable to rainbow table attack.
> > > > > > >   =20
> > > > > >
> > > > > > Thank you for pointing this out! Incidentally, Dmitry
> > > > > > Petukhov also told me the same privately.   =20
> > > > >
> > > > > My thought was that if TOKEN has the characteristics of a
> > > > > password (short ASCII string), then it would be better to use
> > > > > key derivation function designed for passwords, like PBKDF2.
> > > > >
> > > > > The counter-argument to this is that this adds another code
> > > > > dependency for vendors, if the device firmware does not
> > > > > already have the required key derivation function.
> > > > >
> > > > > Maybe this could be solved by going into opposite direction -
> > > > > make the "token" even longer, use the mnemoic.
> > > > >
> > > > > The issue is that entering long data of the shared key into
> > > > > the device manually is difficult UX-wise.
> > > > >
> > > > > Hww vendors that allow to enter custom keys into their device
> > > > > already have to face this issue, and those who allow to enter
> > > > > custom keys via mnemonic probably tackled this somehow.
> > > > >
> > > > > Maybe the shared key for multisig setup can be entered in the
> > > > > same way ? (with maybe additional visual check via some
> > > > > fingerprint).
> > > > >
> > > > > Although we would then have another issue of potential
> > > > > confusion between two procedures (entering the main key and
> > > > > entering the shared key for multisig setup), and the measures
> > > > > has to be taken to prevent such confusion.
> > > > >
> > > > > The approaches can be combined - specify a key derivation
> > > > > function suitable for passwords; via secure channel, share a
> > > > > password and/or the derived key. If hww supports derivation
> > > > > function, it can derive the key from password. If hww supports
> > > > > only keys, the key can be entered raw or via mnemonic.
> > > > > _______________________________________________
> > > > > bitcoin-dev mailing list
> > > > > bitcoin-dev@lists.linuxfoundation.org
> > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > > >   =20
> > >
> > >   =20
>=20