diff options
| author | Dmitry Petukhov <dp@simplexum.com> | 2021-02-14 11:37:52 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-02-14 10:32:15 +0000 |
| commit | ebc78db25e2c00f947a6b021e4e6c81bbe0bee4c (patch) | |
| tree | 3f36f49dc76fa89553097db6d37080fd5858aadd | |
| parent | 40eb5e8660c3f5a65ccc27140901969df546cd84 (diff) | |
| download | pi-bitcoindev-ebc78db25e2c00f947a6b021e4e6c81bbe0bee4c.tar.gz pi-bitcoindev-ebc78db25e2c00f947a6b021e4e6c81bbe0bee4c.zip | |
Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
| -rw-r--r-- | 25/2cb6b9f444a9c10ec4174af8efeb1adae697ec | 242 |
1 files changed, 242 insertions, 0 deletions
diff --git a/25/2cb6b9f444a9c10ec4174af8efeb1adae697ec b/25/2cb6b9f444a9c10ec4174af8efeb1adae697ec new file mode 100644 index 000000000..d5e2c7e0e --- /dev/null +++ b/25/2cb6b9f444a9c10ec4174af8efeb1adae697ec @@ -0,0 +1,242 @@ +Return-Path: <dp@simplexum.com> +Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id B78D9C013A + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 14 Feb 2021 10:32:15 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by hemlock.osuosl.org (Postfix) with ESMTP id AAB6A8711D + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 14 Feb 2021 10:32:15 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +Received: from hemlock.osuosl.org ([127.0.0.1]) + by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id qYpc0GZZjJbc + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 14 Feb 2021 10:32:13 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from mail.ruggedbytes.com (mail.ruggedbytes.com [88.99.30.248]) + by hemlock.osuosl.org (Postfix) with ESMTPS id 4EB5687018 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 14 Feb 2021 10:32:13 +0000 (UTC) +Received: from mail.ruggedbytes.com (localhost [127.0.0.1]) + by mail.ruggedbytes.com (Postfix) with ESMTPS id 545F9260023D; + Sun, 14 Feb 2021 10:32:09 +0000 (UTC) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com; + s=mail; t=1613298729; + bh=VjVhMhbvgr0IW4XZO8b8ZdXL9U5WJ7PicAT5hs4Oz10=; + h=Date:From:To:Cc:Subject:In-Reply-To:References; + b=e2PT+VpJxEP5ZyCp2lQiQaZadxj8lqLvneVyInqxWKuHTdR/ocZkozd1lqrkR09eK + 9uaq4di/uGojC3hsLSoupJ/26e+6lXBphX87NnZL8irb1umoS+ogdMosrLkLVlQP0Y + Xf25s3szOqXMEPwXQVRnZZRemYJVqktxEQrMzms4= +Date: Sun, 14 Feb 2021 11:37:52 +0100 +From: Dmitry Petukhov <dp@simplexum.com> +To: Hugo Nguyen <hugo@nunchuk.io> +Message-ID: <20210214113752.0a255161@simplexum.com> +In-Reply-To: <CAPKmR9uUv32AbSUv9C-JvzEQo5WQb+a6iPSBWTnY1wwKwGaDng@mail.gmail.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> +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 10:32:15 -0000 + +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). + +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. + +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 + +`wsh(or(multi(2, <Alice>, <Bob>, <Carol>), older(1000, <Dylan>))` + +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. + +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 + +=D0=92 Fri, 12 Feb 2021 09:54:57 -0800 +Hugo Nguyen <hugo@nunchuk.io> wrote: + +> 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 + + |