summaryrefslogtreecommitdiff
path: root/b0/0c2f163cbdae02cd5ab56c70aef81d67aa4986
blob: 2835d1c53fe39800e8ffdfee2a58fe70c4561f85 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
Return-Path: <hugo@nunchuk.io>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A11A8C013A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Feb 2021 19:11:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 8817386E44
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Feb 2021 19:11:24 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id L2jgTUCUnx2F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Feb 2021 19:11:23 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com
 [209.85.222.43])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 92A5586DDA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Feb 2021 19:11:23 +0000 (UTC)
Received: by mail-ua1-f43.google.com with SMTP id f10so2099587uaa.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 11 Feb 2021 11:11:23 -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=lWBXfKjbhg8wyx4OGGCHy2R6SZaIrwTaeXjq1SwyJtE=;
 b=zeipiAzP/VUkUFmw0zdyGrEBJdojNuFCZGIg6wSVmze7BCA3broWuwMXqIK7lQ/7er
 CXUiRDUjj1yJiIRJxo/cHAXnfJaSe4AXS8B31nIxfm83g303abStiLCaKTIbaSW6hen+
 0ISKqe3g2eAlxyyie6Ld9u1iVUkAbuZ1j3F92G5y1Yfzv3i31XR/RcYxmH9QW2G0+KFx
 QhlyN2DoQ5pifUGxTLOsagGqqjja//mXZGcg65dCRwwBzCq9lY9hn1ADzfGXM9nQIBHV
 Q5IP76RFUi7NxlznkeRQoRbkS7UaOmIbaRLewEGvXo3BNPUJXGZT9MRlbeqCoMr9MaBv
 sEkg==
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=lWBXfKjbhg8wyx4OGGCHy2R6SZaIrwTaeXjq1SwyJtE=;
 b=evbTJ1qxAVuGZxLlBwBHaREbefJEhZz76jCTgXm1MvSTS7DzZOY0VCILEXs2D5pFv0
 LfYSUEAwQtLX71+pbfI+FVyoIZ6bJ3f9hrzKqzo+5mU39NH60BLE+CKVYv3zfCEGuWEZ
 eQwACHdk8qPYJkJor/PyAxxxVEMC4ptSBoeZ0HwOke7OhxDt0UnqkcyBY1zWhWBm4F1d
 PJ3pQ1areG8crSreSxf+VIRdKphF1/swR4VYT7CTypJk6FKfrT2wvXaPk4tM8/TCcoqR
 +Eca3Gh/8QH/xObuc4JjaqB66nHbhAHyLEGAloa14LnYEO1/BJT8qziEhbfKl9XbI4Ke
 gnoA==
X-Gm-Message-State: AOAM532jixhUAkQ+amNr8gsUFsc1oE97pGsncwWSIDzhd3nJ1ofwaYs4
 CUcEoplW+WXNb3k0sc/mvvXMpd3bSzZaG1ecmWFYZGKvH7EJBOgqK6DWog==
X-Google-Smtp-Source: ABdhPJwVjqcj6+e0T8F6r6vb59r6q3vyOHN7Yq4/GJpRn7Qznibt3DhBMI8F38AE513vtNVeNa5d4B8wUEwSUBDe9gM=
X-Received: by 2002:ab0:41e3:: with SMTP id 90mr6278285uap.128.1613070682658; 
 Thu, 11 Feb 2021 11:11:22 -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: Thu, 11 Feb 2021 11:11:11 -0800
Message-ID: <CAPKmR9udiK+2gC2qUueAfKm7VBf8csM-3WOz1+-bMNR0iVeGew@mail.gmail.com>
To: Dmitry Petukhov <dp@simplexum.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000009b13005bb144908"
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:11:24 -0000

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

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
>

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

<div dir=3D"ltr"><div>Hi Pavol,</div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr" class=3D"gmail_attr">On Thu, Feb 11, 2021 at 8:25 AM Dmitry Petuk=
hov via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">=D0=92 Thu, 11 Feb 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></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>

--00000000000009b13005bb144908--