summaryrefslogtreecommitdiff
path: root/f6/3ce69b655e08d670e0d624407d469b69dd4857
blob: 307f66a4aa2a838a0fd447c1df5a1b0a21a793d7 (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
Return-Path: <keatonatron@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id BA1E8A7A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 25 Dec 2018 00:30:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com
	[209.85.221.51])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3F3F234F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 25 Dec 2018 00:30:55 +0000 (UTC)
Received: by mail-wr1-f51.google.com with SMTP id c14so12738123wrr.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 24 Dec 2018 16:30:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=ktsIx73RvoWyqshTIIrVgPg9ZTgKcjYfUC4E+l4f7wo=;
	b=vU4ppj8MiNRv3lv6TZ1YRVa8i567OmPZ/8fPN3a7nxTil55JnB+uY07RiMouXJ6idj
	qmFVBHm73F5KVX+HkVr6pQEuOrj1D151Jz1SX3jlK1bB+hSRT+i+dBeylvBqVcXyMmPv
	twV9Exk3CJOcw/GEpe/NwegEDjFoNy3xaTBkXKCnqd7/KaM2B/eimtpOiY2Wz8oWC2y5
	qkJDhwUmUemPkwFBYECD4rienyNpXhPEhImAPYQfV4EEalJVKw/iLHTRQ7CtDnFQ/o/d
	lOMXL+T/cO6k0KbfEJCMb7dw2kwB7MljN+n9kMvwv05/TcqH8lZtJkuQmQwtHGrC4CTM
	6GZg==
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=ktsIx73RvoWyqshTIIrVgPg9ZTgKcjYfUC4E+l4f7wo=;
	b=FITVmv/s9TIIoyaursfyUGra/IPncrDetoaFJ9MthTkQHdmakN1yoNeraxWxIP8l0u
	aMs+Jt+c7Lsb5JdJVEH4Xo7I6JinMWn8d4Ncxx6YtffaMXDkkU+y+TKcNY5YP//kDEse
	rZfwwKK90AEQP3DX7EffGtAXrQqIufIusVWU+g1y7Xqt9l6ZExeun5HaseyOLue+GflA
	2ZmmJ4sDU2KkZXD+L0A/pDHqxcy6Lt7bEuiUGiO5o14D58Jm9L2RawU55IjyAEhe5G26
	G+qzn2pf7Ij22xdbDA0AlJsrMO/IqOPLmH3cBuGd2Ow881zL9BaIwlOzhTuZyZRpjIWM
	mv5A==
X-Gm-Message-State: AJcUukfQu551Z3GEv0D/lF45OlkLlB3r81qyoZq0cWYPzaGmPWxUru4g
	URDgQWRKC0XRam9A3qshBmsNzTa8D0Z9WW7EtsY=
X-Google-Smtp-Source: ALg8bN79W1bcjkjSUBY0xI4pXaHyhW4vbHuoigMAN6JiSd8hjCq6ioNe24gOfYcgxywEFcCwIHjSIIoOuYTfcxOGJdc=
X-Received: by 2002:a5d:5089:: with SMTP id a9mr13610980wrt.327.1545697853552; 
	Mon, 24 Dec 2018 16:30:53 -0800 (PST)
MIME-Version: 1.0
References: <68330522-7e7c-c3b4-99a9-1c68ddb56f23@gmail.com>
	<f2d73a92-e1c5-9072-e255-fa012a9f9d1b@satoshilabs.com>
	<db184306-7ec0-322e-5637-7889b51f50bf@gmail.com>
In-Reply-To: <db184306-7ec0-322e-5637-7889b51f50bf@gmail.com>
From: James MacWhyte <macwhyte@gmail.com>
Date: Tue, 25 Dec 2018 00:30:26 +0000
Message-ID: <CAH+Axy6dKDOkE6cQYZUusTUxxOSwWchOWxYh6ZkhnOgXuELaYg@mail.gmail.com>
To: vitteaymeric@gmail.com, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000007dbdb1057dcdd32e"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 25 Dec 2018 04:23:07 +0000
Subject: Re: [bitcoin-dev] BIP39 seeds
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Tue, 25 Dec 2018 00:30:59 -0000

--0000000000007dbdb1057dcdd32e
Content-Type: text/plain; charset="UTF-8"

On Mon, Dec 24, 2018 at 2:48 PM Aymeric Vitte via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> I don't see very well why it's easier to write n words that you cannot
> choose rather than a 32B BIP32 hex seed, and I have seen many people
> completely lost with their wallets because of this
>

In practice it has quite a few qualities that make it a bit more resilient
for physical (written) storage.

If a few letters of a word get rubbed off or otherwise become illegible, it
is pretty easy for a native speaker to figure out what the word is supposed
to be. Even a non-native speaker could look through the word list and
figure out which word fits. Missing characters in a hex string require more
advanced brute force searching, which the average user isn't capable of.

Additionally, having the bits grouped into words makes a more serious
recovery easier. If you lose one entire word, it can be brute forced in
about 5 minutes on a normal pc, even if you don't know which position the
missing word is in (I have published a tool that does just this:
https://jmacwhyte.github.io/recovery-phrase-recovery). If you are missing
two words, you can brute force it in about a week (napkin math).

If you were missing a random chunk of a hex string, I don't know how you'd
go about brute forcing that in a timely manner.

As an aside, from a UX standpoint we've seen that the 12 words don't *look*
important so people don't take them seriously (and they get lost). A hex
string or equivalent would look more password-y, and therefore would most
likely be better protected by users.

James

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

<div dir=3D"ltr"><div dir=3D"ltr"><div><br></div><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr">On Mon, Dec 24, 2018 at 2:48 PM Aymeric Vitte via bit=
coin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-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 rg=
b(204,204,204);padding-left:1ex"><br>I don&#39;t see very well why it&#39;s=
 easier to write n words that you cannot choose rather than a 32B BIP32 hex=
 seed, and I have seen many people completely lost with their wallets becau=
se of this<br></blockquote><div><br></div><div>In practice it has quite a f=
ew qualities that make it a bit more resilient for physical (written) stora=
ge.</div><div><br></div><div>If a few letters of a word get rubbed off or o=
therwise become illegible, it is pretty easy for a native speaker to figure=
 out what the word is supposed to be. Even a non-native speaker could look =
through the word list and figure out which word fits. Missing characters in=
 a hex string require more advanced brute force searching, which the averag=
e user isn&#39;t capable of.</div><div><br></div><div>Additionally, having =
the bits grouped into words makes a more serious recovery easier. If you lo=
se one entire word, it can be brute forced in about 5 minutes on a normal p=
c, even if you don&#39;t know which position the missing word is in (I have=
 published a tool that does just this:=C2=A0<a href=3D"https://jmacwhyte.gi=
thub.io/recovery-phrase-recovery">https://jmacwhyte.github.io/recovery-phra=
se-recovery</a>). If you are missing two words, you can brute force it in a=
bout a week (napkin math).<br><br>If you were missing a random chunk of a h=
ex string, I don&#39;t know how you&#39;d go about brute forcing that in a =
timely manner.</div><div><br></div><div>As an aside, from a UX standpoint w=
e&#39;ve seen that the 12 words don&#39;t *look* important so people don&#3=
9;t take them seriously (and they get lost). A hex string or equivalent wou=
ld look more password-y, and therefore would most likely be better protecte=
d by users.</div><div><br></div><div>James</div></div></div></div>

--0000000000007dbdb1057dcdd32e--