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
|
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 D258BC013A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 Feb 2021 16:23:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id BF23987447
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 Feb 2021 16:23:30 +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 MvEp0sabpeo0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 Feb 2021 16:23:29 +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 554E287431
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 Feb 2021 16:23:29 +0000 (UTC)
Received: from mail.ruggedbytes.com (localhost [127.0.0.1])
by mail.ruggedbytes.com (Postfix) with ESMTPS id 88CA1260023D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 Feb 2021 16:23:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com;
s=mail; t=1613060606;
bh=qR6v+1SqM5lH5g2gVxxV1D7ZDQVj15Lu/fpSVpinvLE=;
h=Date:From:To:Subject:In-Reply-To:References;
b=P+pfPZJWbb3sFubyImZYgjgAgLWF37PnUI/Mhe3CGm2pt3Qkws4XAAMQIXqACTQDI
e/1mIFwzCY4hCWnwyEerT+1prYRpiOlBPJ8ZXO8NTVUhLizH3i03ya3irhuqO53NU5
bupRRHlu4WlSRJNhueiuXzE+ucEgQRmvECHuWjWs=
Date: Thu, 11 Feb 2021 17:29:10 +0100
From: Dmitry Petukhov <dp@simplexum.com>
To: Hugo Nguyen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210211172910.3b550706@simplexum.com>
In-Reply-To: <CAPKmR9vg1BMDQWNDk41N4i4cJ8J6K9GuqSpstFpMFwyiVBYw-w@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>
Organization: simplexum.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 11 Feb 2021 16:25:14 +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 16:23:30 -0000
=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)) =20
> >
> > This scheme might be vulnerable to rainbow table attack.
> > =20
>=20
> 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.
|
