path: root/54/30c185b0aad5450b4ada427a466ca2f3cc92cf

Return-Path: <hugo@nunchuk.io>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 50772C013A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Feb 2021 18:01:23 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 3DF8286F75
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Feb 2021 18:01:23 +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 ej+JtCC2BmbU
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Feb 2021 18:01:22 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com
 [209.85.217.46])
 by whitealder.osuosl.org (Postfix) with ESMTPS id D8ECC86EC8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Feb 2021 18:01:21 +0000 (UTC)
Received: by mail-vs1-f46.google.com with SMTP id u7so16899vsp.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Feb 2021 10:01:21 -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=NwI2mqILTAR+G7QSJjr9zD2obeF5KytGpxFnMbcvIHc=;
 b=lR+YAKQH1PALqUp/R9z6vN1nMUoX4+j/GNp6ItGdWKDhPrAHj4uQ+laXD51QS0Q2z+
 T3hCcrLk0k5rX9e01qfQEpoyA1H05B+Lk+rcgVGtsH5OF8YahB6s1vbgIp4IrIpIB8RZ
 tKVX9yFGPNr4FGHaCIWLGMaU/R5kbxx+YefKfC0VzddSLXrJAHTWG01qntd8FZ69ti89
 269ct/C/8wQ4FhP3FsU9AQs3nT4a5kUtbjGTfgxeg11WT/yVqaeO/4aGBqOiJ/ZW1eVm
 bnsj6wZvy3aHAuc3X2tTiO9TVAjam5dzTwyF+rQU6SUglo+FfZJKJS395Y8ALWlEJ1SF
 6i5A==
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=NwI2mqILTAR+G7QSJjr9zD2obeF5KytGpxFnMbcvIHc=;
 b=RH4SM1rtprAFbhjAFodk53lATzKbLht+VlcHGG4IpjF2dX1maEeUqtl6BJ71vkDqU3
 oigmGazVKreUzQNPatAN9pidQ/2TzCMJqq1P61xiPAAtTYTQMgufuZQ4daI4iPiMPwDA
 KfAcVNKiAyPQgCrw//jw1kOuay+BUlueVlWU7vhRqkgLIptYL34SpkDba3ioj00mOXju
 BrT9169fW4EFgrgQO0xaizqmZlmbV7NMGPE+e3yZsYJcp80KeybGX7BDq1er4xGbGnMo
 2xL/J32wcmjSVj1NEp9QAUei62VjSFXaQcsn4zsjchXzM+hYmJnaGYUJ2E4jrsJ/KRzw
 vtmw==
X-Gm-Message-State: AOAM530v0NcL4yNz5UjY8MjZFz7SwgYG7HqZjNCCHJz4+2jTamZftyPQ
 cWZY8dvNd6iCTm1NGJOG4UZjAc+KJ74k8Bpi8f9dT0i2JeaSJcRAsuAArQ==
X-Google-Smtp-Source: ABdhPJzuGXdxjFuW6VEpt49k8FNoTeuI2nGW9KnhOBOInyYJiZ2p7dUjAz49pRS2L+OOH9tq6/RaBvcK43odJp6QUeg=
X-Received: by 2002:a1f:5606:: with SMTP id k6mr2573099vkb.6.1613152509023;
 Fri, 12 Feb 2021 09:55:09 -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>
 <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>
In-Reply-To: <20210212184231.22b517aa@simplexum.com>
From: Hugo Nguyen <hugo@nunchuk.io>
Date: Fri, 12 Feb 2021 09:54:57 -0800
Message-ID: <CAPKmR9uUv32AbSUv9C-JvzEQo5WQb+a6iPSBWTnY1wwKwGaDng@mail.gmail.com>
To: Dmitry Petukhov <dp@simplexum.com>
Content-Type: multipart/alternative; boundary="00000000000044e9c005bb27564f"
X-Mailman-Approved-At: Fri, 12 Feb 2021 18:29:59 +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: Fri, 12 Feb 2021 18:01:23 -0000

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

On Fri, Feb 12, 2021 at 9:36 AM Dmitry Petukhov <dp@simplexum.com> wrote:

> 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 ?
>
>
Good question. If we don't need the extra entropy, we can fix
the HUMAN_READABLE_TITLE string.

Something like "No SPOF". (No Single Point Of Failure).



> 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)
>

> Or simply allow bigger entropy (more than 6 mnemonic words), if
> the coordinator feels that 64 bit of entropy is not enough.


That could work. Allowing variable iteration count is probably better
UX-wise.

Best,
Hugo


>
> =D0=92 Fri, 12 Feb 2021 08:55:55 -0800
> Hugo Nguyen <hugo@nunchuk.io> wrote:
>
> > 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:
> >
> > > =D0=92 Thu, 11 Feb 2021 05:45:33 -0800
> > > Hugo Nguyen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> > > 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.
> > >
> > > 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
> > >
>
>

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

<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 Fri, Feb 12, 2021 at 9:36 AM Dmitr=
y Petukhov &lt;<a href=3D"mailto:dp@simplexum.com">dp@simplexum.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">If HUMAN=
_READABLE_TITLE is the additional secret, the user would need<br>
to enter it on the device in addition to the nonce, wouldn&#39;t it defeat<=
br>
the advantage in UX that was gained by using (relatively) short nonce ?<br>
<br>
Is 64 bit nonce not enough ?<br>
<br></blockquote><div><br></div><div>Good question. If we don&#39;t need=C2=
=A0the extra entropy, we can fix the=C2=A0HUMAN_READABLE_TITLE string.<br><=
br>Something like &quot;No SPOF&quot;. (No Single Point Of Failure).</div><=
div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">
It seems that to crack this with fixed Pwd and 64 bit nonce, the<br>
attacker will need to be about 10^15 more powerful than 80Mhz MCU:<br>
(2^64)/(0.3*10^15)/3600 =3D 17 hours. I don&#39;t know if 10^15 is realisti=
c<br>
scale. Average desktop cpu seems to be about 10^3 more powerful than<br>
the mentioned MCU for this task.<br>
<br>
Maybe for the UX it would be better to choose the number of rounds to<br>
use in PBKDF2, instead of using variable Pwd. Number of rounds will be<br>
easier to enter on the device (or just choose it from a set of<br>
pre-defined values). The more money is at stake, the higher number of<br>
rounds could the coordinator choose (taking into account the<br>
characteristics of the participant devices)<br></blockquote><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><br>Or simply allow bigger entropy (more=
 than 6 mnemonic words), if<br>the coordinator feels that 64 bit of entropy=
 is not enough.</blockquote><div><br>That could work. Allowing variable ite=
ration count is probably better UX-wise.<br><br>Best,<br>Hugo<br>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
=D0=92 Fri, 12 Feb 2021 08:55:55 -0800<br>
Hugo Nguyen &lt;<a href=3D"mailto:hugo@nunchuk.io" target=3D"_blank">hugo@n=
unchuk.io</a>&gt; wrote:<br>
<br>
&gt; Thanks everyone who has provided inputs so far!<br>
&gt; <br>
&gt; This is the new proposal for the encryption aspect of the scheme,<br>
&gt; based on all the feedback.<br>
&gt; <br>
&gt; The key derivation function would be PBKDF2, with PRF =3D SHA512. This=
<br>
&gt; should be readily available on today&#39;s hardware already, as they a=
re<br>
&gt; used for BIP39.<br>
&gt; <br>
&gt; DK =3D PBKDF2(PRF, Password, Salt, c, dkLen)<br>
&gt; PRF =3D SHA512<br>
&gt; Pwd =3D HUMAN_READABLE_TITLE<br>
&gt; Salt =3D NONCE<br>
&gt; c =3D 2048<br>
&gt; dkLen =3D 256<br>
&gt; <br>
&gt; HUMAN_READABLE_TITLE is in ASCII format, minimum length =3D 8, maximum=
<br>
&gt; length =3D 20.<br>
&gt; NONCE is a 64-bit number.<br>
&gt; <br>
&gt; Reason for going with SHA512 is due to legacy support on some<br>
&gt; hardware. c=3D2048 also mimics BIP39. It takes about ~3 seconds to<br>
&gt; derive the encryption key on a 80Mhz MCU. We feel like this is a good<=
br>
&gt; enough tradeoff for this use case. The assumption here is that the<br>
&gt; secure session is only needed temporarily for a few hours, maybe up<br=
>
&gt; to one day.<br>
&gt; <br>
&gt; The Coordinator and Signers agree and exchange these 2 secrets prior<b=
r>
&gt; to the setup. The NONCE can be converted to either:<br>
&gt; (a) a 6-word phrase using BIP39 wordlist<br>
&gt; (b) a 20-digit decimal number<br>
&gt; (c) a QR code<br>
&gt; <br>
&gt; Depending on the vendor. This flexibility in the data format allows<br=
>
&gt; each vendor to customize the UX based on their respective device<br>
&gt; capabilities.<br>
&gt; <br>
&gt; Best,<br>
&gt; Hugo<br>
&gt; <br>
&gt; On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bitcoin-dev &lt;<b=
r>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; <br>
&gt; &gt; =D0=92 Thu, 11 Feb 2021 05:45:33 -0800<br>
&gt; &gt; Hugo Nguyen via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt;<br>
&gt; &gt; wrote:<br>
&gt; &gt;=C2=A0 <br>
&gt; &gt; &gt; &gt; &gt; ENCRYPTION_KEY =3D SHA256(SHA256(TOKEN))=C2=A0 <br=
>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; This scheme might be vulnerable to rainbow table attack=
.<br>
&gt; &gt; &gt; &gt;=C2=A0 <br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Thank you for pointing this out! Incidentally, Dmitry Petukh=
ov<br>
&gt; &gt; &gt; also told me the same privately.=C2=A0 <br>
&gt; &gt;<br>
&gt; &gt; My thought was that if TOKEN has the characteristics of a passwor=
d<br>
&gt; &gt; (short ASCII string), then it would be better to use key derivati=
on<br>
&gt; &gt; function designed for passwords, like PBKDF2.<br>
&gt; &gt;<br>
&gt; &gt; The counter-argument to this is that this adds another code<br>
&gt; &gt; dependency for vendors, if the device firmware does not already<b=
r>
&gt; &gt; have the required key derivation function.<br>
&gt; &gt;<br>
&gt; &gt; Maybe this could be solved by going into opposite direction - mak=
e<br>
&gt; &gt; the &quot;token&quot; even longer, use the mnemoic.<br>
&gt; &gt;<br>
&gt; &gt; The issue is that entering long data of the shared key into the<b=
r>
&gt; &gt; device manually is difficult UX-wise.<br>
&gt; &gt;<br>
&gt; &gt; Hww vendors that allow to enter custom keys into their device<br>
&gt; &gt; already have to face this issue, and those who allow to enter<br>
&gt; &gt; custom keys via mnemonic probably tackled this somehow.<br>
&gt; &gt;<br>
&gt; &gt; Maybe the shared key for multisig setup can be entered in the sam=
e<br>
&gt; &gt; way ? (with maybe additional visual check via some fingerprint).<=
br>
&gt; &gt;<br>
&gt; &gt; Although we would then have another issue of potential confusion<=
br>
&gt; &gt; between two procedures (entering the main key and entering the<br=
>
&gt; &gt; shared key for multisig setup), and the measures has to be taken =
to<br>
&gt; &gt; prevent such confusion.<br>
&gt; &gt;<br>
&gt; &gt; The approaches can be combined - specify a key derivation functio=
n<br>
&gt; &gt; suitable for passwords; via secure channel, share a password and/=
or<br>
&gt; &gt; the derived key. If hww supports derivation function, it can deri=
ve<br>
&gt; &gt; the key from password. If hww supports only keys, the key can be<=
br>
&gt; &gt; entered raw or via mnemonic.<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; bitcoin-dev mailing list<br>
&gt; &gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bit=
coin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundatio=
n.org/mailman/listinfo/bitcoin-dev</a><br>
&gt; &gt;=C2=A0 <br>
<br>
</blockquote></div></div>

--00000000000044e9c005bb27564f--