path: root/27/e7252ae41fbf80d029c40cdff9225fb926bae1

Return-Path: <hugo@nunchuk.io>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 617B9C013A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Feb 2021 16:56:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 3A53E6F518
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Feb 2021 16:56:12 +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 inpICSV8QQ-c
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Feb 2021 16:56:10 +0000 (UTC)
Received: by smtp3.osuosl.org (Postfix, from userid 1001)
 id CEAFF6F6DE; Fri, 12 Feb 2021 16:56:10 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com
 [209.85.217.43])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 6D0CF6F769
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Feb 2021 16:56:08 +0000 (UTC)
Received: by mail-vs1-f43.google.com with SMTP id t23so5159074vsk.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Feb 2021 08:56:08 -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;
 bh=xaYw6OuN9uTxwIeOVKf3gJdfUutGd7NQf2BUJxUUNIA=;
 b=QyTYj0fOPcV0cuteYQlfAxum8brTSE7sed9IbkyOFlGWCK2h9I3Mij0aPMzij/6Nt5
 +mG93gk007hd+fOVXIOGeLR+U9EUtiU3ufi0efn33fjrPzip/3nfJs0oJfrhXGG9Z/WU
 7Rm/ym6KEH+RpRhnUu9EdTbbk+5FZc/o/SuRNkWGdqwm6fN4vCLjUMWzMJiJ5ux7X6L1
 dtkJRU8yiQJf9Cokdnt14WQA7SJ8O3dZROOXPXukL9ze3uNoVcF8OpT5e/m1hK/Zb381
 xXUa/b3xX8/vSuhkV4kGEliqysrfRe4ZUomQZvd0p9SsjHsBuoen/cQU1FAlQ/VfhoA1
 Qizg==
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;
 bh=xaYw6OuN9uTxwIeOVKf3gJdfUutGd7NQf2BUJxUUNIA=;
 b=Qf2AVbaUjgQlWEhRV/aWZXCmP4NS580isk0fAQbh0d7RR1oDlh8QQX0p/FZ/QcUTkG
 d21DyKsnWJjSZHfDF3RvEP46JZe9b9amJlY5qCa7u/xQWLRWlDHKQwcEPKPtsh0fn3sN
 aVua+vI2tR2FSgkm39CHyciCpD/qcQshSUWjadSE58Z9brHbmyhHU60A1nNk5TQlkOTh
 xvxunzvLa32aYVXBtIuPFqJWfXgLc+h8AsOPjGy2hsJVIbh4ed/dxhcQw+PkSxtX+WuI
 GRoGBvz1TmnJqtOBBv19h5vZsFFbFfN+boEPP3BNwYZ/W1p+GCFxZQ2sxHEmZV53PgEr
 ktAA==
X-Gm-Message-State: AOAM530Q7YkCj3tKvxTLij062+2gSDfjkige1hc1J1V7QzOFNSZYD75T
 RMRFkuad0XqLllvOLIVlYWpAgKxVCmmfBp42Y1vK0nV9x7lo5Kuaob6DTA==
X-Google-Smtp-Source: ABdhPJzR4MCTu49s9Mo0m7yFI3/ROrT2M+P3yl0xZx8wzB6pFyETdZN/Zek/jQtDQx+YQCsFTbH1PfUqz2/h48JCZoA=
X-Received: by 2002:a67:f887:: with SMTP id h7mr2097768vso.57.1613148966945;
 Fri, 12 Feb 2021 08:56:06 -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>
In-Reply-To: <20210211172910.3b550706@simplexum.com>
From: Hugo Nguyen <hugo@nunchuk.io>
Date: Fri, 12 Feb 2021 08:55:55 -0800
Message-ID: <CAPKmR9v5jzsu7siuyAu42XOCdtXqMXmKzmiDzjEy_bVNbSPyyw@mail.gmail.com>
To: Dmitry Petukhov <dp@simplexum.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002577e205bb2683d0"
X-Mailman-Approved-At: Fri, 12 Feb 2021 18:29:59 +0000
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 16:56:12 -0000

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

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 shou=
ld
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 leng=
th
=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
>

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

<div dir=3D"ltr"><div>Thanks everyone who has provided inputs so far!=C2=A0=
<br><br>This is the new proposal for the encryption aspect of the scheme, b=
ased on all the feedback.<br><br>The key derivation=C2=A0function=C2=A0woul=
d be=C2=A0PBKDF2, with PRF =3D SHA512. This should be readily available on =
today&#39;s hardware already, as they are used for BIP39.<br><br>DK =3D PBK=
DF2(PRF, Password, Salt, c, dkLen)<br>PRF =3D SHA512<br>Pwd =3D HUMAN_READA=
BLE_TITLE<br>Salt =3D NONCE<br>c =3D 2048<br>dkLen =3D 256<br><br>HUMAN_REA=
DABLE_TITLE is in ASCII format, minimum=C2=A0length =3D 8, maximum length =
=3D 20.<br>NONCE is a 64-bit number.<br><br>Reason for going with SHA512 is=
 due to legacy support on some hardware. c=3D2048 also mimics=C2=A0BIP39. I=
t takes about ~3 seconds to derive the=C2=A0encryption key on a 80Mhz MCU. =
We feel like this is a good enough tradeoff for this use case. The assumpti=
on here is that the secure session is only needed temporarily for a few hou=
rs, maybe up to one day.<br><br>The Coordinator and Signers agree and excha=
nge these 2 secrets prior to the setup. The NONCE can be converted to eithe=
r:<br>(a) a 6-word phrase using BIP39 wordlist<br>(b) a 20-digit decimal nu=
mber<br>(c) a QR code<br><br>Depending on the vendor. This flexibility in t=
he data format allows each vendor to customize the UX based on their respec=
tive device capabilities.<br><br>Best,</div>Hugo<br><br><div class=3D"gmail=
_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 11, 2021 at 8:25 =
AM Dmitry Petukhov via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<b=
r></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">=D0=92 Thu, 11 Fe=
b 2021 05:45:33 -0800<br>
Hugo Nguyen via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t;<br>
wrote:<br>
<br>
&gt; &gt; &gt; ENCRYPTION_KEY =3D SHA256(SHA256(TOKEN))=C2=A0 <br>
&gt; &gt;<br>
&gt; &gt; This scheme might be vulnerable to rainbow table attack.<br>
&gt; &gt;=C2=A0 <br>
&gt; <br>
&gt; Thank you for pointing this out! Incidentally, Dmitry Petukhov also<br=
>
&gt; told me the same privately.<br>
<br>
My thought was that if TOKEN has the characteristics of a password<br>
(short ASCII string), then it would be better to use key derivation<br>
function designed for passwords, like PBKDF2.<br>
<br>
The counter-argument to this is that this adds another code dependency<br>
for vendors, if the device firmware does not already have the required<br>
key derivation function.<br>
<br>
Maybe this could be solved by going into opposite direction - make the<br>
&quot;token&quot; even longer, use the mnemoic.<br>
<br>
The issue is that entering long data of the shared key into the device<br>
manually is difficult UX-wise.<br>
<br>
Hww vendors that allow to enter custom keys into their device already<br>
have to face this issue, and those who allow to enter custom keys via<br>
mnemonic probably tackled this somehow.<br>
<br>
Maybe the shared key for multisig setup can be entered in the same way<br>
? (with maybe additional visual check via some fingerprint).<br>
<br>
Although we would then have another issue of potential confusion<br>
between two procedures (entering the main key and entering the shared<br>
key for multisig setup), and the measures has to be taken to prevent<br>
such confusion.<br>
<br>
The approaches can be combined - specify a key derivation function<br>
suitable for passwords; via secure channel, share a password and/or the<br>
derived key. If hww supports derivation function, it can derive the key<br>
from password. If hww supports only keys, the key can be entered raw or<br>
via mnemonic.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--0000000000002577e205bb2683d0--