path: root/3f/3ce9f7f32002cd606044e8a61e525c349a0af1

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 E1AFAC013A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Feb 2021 19:12:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id C32F6600CC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Feb 2021 19:12:00 +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 NPm6Pd-oMP4k
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Feb 2021 19:11:59 +0000 (UTC)
Received: by smtp3.osuosl.org (Postfix, from userid 1001)
 id 85ACE6F5D8; Thu, 11 Feb 2021 19:11:59 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com
 [209.85.222.45])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 53E28600CC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Feb 2021 19:11:57 +0000 (UTC)
Received: by mail-ua1-f45.google.com with SMTP id i3so2108183uai.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Feb 2021 11:11:57 -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=ZbnIVCEFpRiUgr92TqTmIDNc9wNXPYhbBbQIOJ/X0JY=;
 b=DqX6ajkm9Sz85sn15bCZhnYoFeKbZO5HaFlg3Gyg0G3YPw2grJ1eq6iexbJzykFR2G
 6P86zG39vo/IVnQ73IWc8icZU/50ebvEt0rnqRZ0NBVRjAPorGgss0jRR4N04vcDc5F4
 eXBNwIMhNkDA6ikZPAWJd0OsFuFl347eFSdx382K2WPMxFavOaOXPPjX52wZ8X+k+51l
 2fU22D+Hpryx36DATRYjtC6XdxPp9Bh3xJrjUAq2vuzfCW4UoctU1OZsAWGEzNYo6EVv
 /+QeiEgATFZelC80ubGloma9ka0cTJFLid7DvZJ1dkxjn+qPuhNoQeO29cmCma275Qf7
 2I6A==
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=ZbnIVCEFpRiUgr92TqTmIDNc9wNXPYhbBbQIOJ/X0JY=;
 b=UwiNLS5zZLP2yqX3k6sDN8gzGjYfsKb/NlmMj36Cdr0mBdXlEpwOuT+TUEnpeLvdQL
 yWrf4r2wm+iPHxqJ2a53zVk1wOAdgB2UE4XgRQBhI/INxEG0YbTSzph7jG6XxJUwNg2b
 CiIlkMa/UkvGhhgrC1zAX7jjGRhz4vfn1Btaf7HE4wzjO1s6nUFlmsQLwxKyLZabiXMj
 bMC9/+I7PYeBOUcjnoSBYUUY1uqdZr8jfULBaav0/KLB559npbP4xkV7mZYILNJEZ2Ay
 Cq/RciSZ6BA4uWEkTD6VF2k0mBP3pmLRrFOZkbEE7X0tLyhG29jbD4tDYH1Wu4ON5cT8
 wzOg==
X-Gm-Message-State: AOAM530NSVmK1LULGbK/u60GIFu+sBUpWOqPO5uhES3UfxFYTgIuIAv7
 yu/ubOQyyPrAuKwotgvEQuzohU5WqiZxa6lvwWO8IiJXIfyUsSLSyZE=
X-Google-Smtp-Source: ABdhPJxrWK9RQokRvFqtPXunIJS5og5tY8D39FUGOHp1kOJrDXdZrxQszXRHHmA87W0U7LeogpX8RtsugaUrZcG141U=
X-Received: by 2002:ab0:274f:: with SMTP id c15mr6718189uap.12.1613070716211; 
 Thu, 11 Feb 2021 11:11:56 -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>
 <CAPKmR9udiK+2gC2qUueAfKm7VBf8csM-3WOz1+-bMNR0iVeGew@mail.gmail.com>
In-Reply-To: <CAPKmR9udiK+2gC2qUueAfKm7VBf8csM-3WOz1+-bMNR0iVeGew@mail.gmail.com>
From: Hugo Nguyen <hugo@nunchuk.io>
Date: Thu, 11 Feb 2021 11:11:45 -0800
Message-ID: <CAPKmR9t0hta0n4tAqp1SwH4gJ_5cswh-pg4DDAJ=qMhZjtUgYw@mail.gmail.com>
To: Dmitry Petukhov <dp@simplexum.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000009ab9505bb144b62"
X-Mailman-Approved-At: Thu, 11 Feb 2021 20:29:40 +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: Thu, 11 Feb 2021 19:12:01 -0000

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

*BIP39 seed words list.

On Thu, Feb 11, 2021 at 11:11 AM Hugo Nguyen <hugo@nunchuk.io> wrote:

> Hi Pavol,
>
> 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).
>>
>
> You just gave me a great idea! We can reuse the BIP32 seed words list!
> Perhaps the encryption key can just be 6 words, but it'll be derived the
> same way. BIP39 also uses PBKDF2 as a key derivation function, so it
> matches with what you described here.
>
> And all HWW should have this functionality already.
>
> Best,
> Hugo
>
>
>>
>> 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
>>
>

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

<div dir=3D"ltr">*BIP39 seed words list.</div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 11, 2021 at 11:11 AM Hu=
go Nguyen &lt;<a href=3D"mailto:hugo@nunchuk.io">hugo@nunchuk.io</a>&gt; wr=
ote:<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"><div dir=3D=
"ltr"><div>Hi Pavol,</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" c=
lass=3D"gmail_attr">On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petukhov via bit=
coin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</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">=D0=92 Thu, 11 Feb 2021 0=
5: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></blockquot=
e><div><br>You just gave me a great idea! We can reuse the BIP32 seed words=
 list! Perhaps the encryption key can just be 6 words, but it&#39;ll be der=
ived the same way. BIP39 also uses=C2=A0PBKDF2 as a key derivation function=
, so it matches with what you described here.<br><br>And all HWW should hav=
e this functionality already.<br><br>Best,<br>Hugo<br>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">
<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>
</blockquote></div>

--00000000000009ab9505bb144b62--