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
|
Return-Path: <dave@dtrt.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 99A26C002B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 19 Feb 2023 20:13:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 613D1408BA
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 19 Feb 2023 20:13:39 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 613D1408BA
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id I8BvqoADzgej
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 19 Feb 2023 20:13:37 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org D1D4C40895
Received: from smtpauth.rollernet.us (smtpauth.rollernet.us
[IPv6:2607:fe70:0:3::d])
by smtp4.osuosl.org (Postfix) with ESMTPS id D1D4C40895
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 19 Feb 2023 20:13:37 +0000 (UTC)
Received: from smtpauth.rollernet.us (localhost [127.0.0.1])
by smtpauth.rollernet.us (Postfix) with ESMTP id 788B92800864;
Sun, 19 Feb 2023 12:13:33 -0800 (PST)
Received: from webmail.rollernet.us (webmail.rollernet.us
[IPv6:2607:fe70:0:14::a])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client did not present a certificate)
by smtpauth.rollernet.us (Postfix) with ESMTPSA;
Sun, 19 Feb 2023 12:13:33 -0800 (PST)
MIME-Version: 1.0
Date: Sun, 19 Feb 2023 10:13:33 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Andrew Poelstra <apoelstra@wpsoftware.net>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <Y+40gVnMpj0prfQk@camus>
References: <CAMZUoKmiwXW50F2onqNUZO8HXQa4+Z=z3s3WyN7-rAMV=KiSgw@mail.gmail.com>
<CAF90AvmaRYO6HKn9npyfzO6M6FZnN6DRhqopLpeSnHJNK=5i9g@mail.gmail.com>
<Y+40gVnMpj0prfQk@camus>
User-Agent: Roundcube Webmail/1.4.10
Message-ID: <f19acdabd3fbc0ff389669131acbb79e@dtrt.org>
X-Sender: dave@dtrt.org
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy:
http://www.rollernet.us/policy
X-Rollernet-Submit: Submit ID 51ed.63f282ed.9b87.0
Subject: Re: [bitcoin-dev] Codex32
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: Sun, 19 Feb 2023 20:13:39 -0000
On 2023-02-16 03:49, Andrew Poelstra via bitcoin-dev wrote:
> the draft lists several benefits over SLIP-0039.
The only benefit over SLIP39 that I see explicitly mentioned in the
draft BIP is "simple enough for hand computation". In the FAQ[1] on the
project's website, I see some additional reasons:
| This scheme is essentially the same as SLIP39, with the following
differences:
|
| - The checksum is longer, slightly stronger, and designed to be
| computable by hand.
|
| - Our encoding is more compact, giving us room for a bit of more
| metadata, which is also designed to be readable by hand.
|
| - Unlike SLIP39, we do not support passphrases or hardening of any
| form.
|
| - Unlike SLIP39, we have no hardware wallet support. But we hope that
| will change!
From having perused the extended documentation myself, I think I would
personally note the following differences.
- Alphabet: Codex32 uses the bech32 alphabet rather than SLIP39's
alphabet consisting of English words. The benefit to human-language
words is easier memorization for those proficient in the particular
language (in this case, SLIP39 only allows the use of English). A
disadvantage, IMO, is that it encourages the practice of memorization
(which does have a few advantages but also a lot of drawbacks).
Interestingly, Codex32 addresses what I think is the main problems of
memorization: difficult-to-prove successful recollection. Someone who
wants to reliably keep seed-related material only in their head
needs to practice recalling it on a regular basis, but for BIP39,
SLIP39, Aezeed, etc... there's no way for them to confirm they
successfully recalled it short of going through the entire recovery
process; they probably just judge how confident they feel about the
recollection and assume that feeling like they recalled it correctly
is the same thing as recalling it correctly.
Codex32 allows the individual to periodically perform their
recollection on paper in a private room without electronics and use
nothing but a pen and some loookup tables (or a paper device) to
verify that they recalled the string correctly (and its checksum can
help with correcting up to several errors, although you might need a
computer for error location and correction assistance).
- Hierarchy: Codex32 does not natively provide support for nested SSSS
whereas SLIP39 does. E.g., in SLIP39, you can require 2-of-3 for
{me, family, friends} where me is 2-of-3 {fire_safe, bank_safe,
buried_in_woods}, family is 1-of-3 {alice, bob, carol}, and friends
are 2-of-5 {d, e, f, g, h}. I assume you can do the same with Codex32
by using the share for one level as the secret for the next level,
although this is not described in the protocol.
- Versioning: Codex32's metadata can store version information for
wallets that use implicit BIP32 paths (e.g. BIP44/49/84/86), although
this would cut into the space available for users to set their own
metadata and it is not specified in the draft BIP. SLIP39 also
doesn't specify anything about implicit path versioning and, AFAICT,
doesn't have any room to store such metadata without reducing seed
entropy.
- Plausible deniability dummy wallets: Codex32 doesn't support this;
SLIP39 does. Much has been written by other people about whether
dummy wallets are a good idea or not, with strong opinions on both
sides, so maybe we can just leave it at that.
---
When I first saw the post about this, it was unclear to me that it was a
serious project, but I've become increasingly interested as I researched
it. I'm not personally that interested in generating entropy from dice
or encoding shares by hand---it's already imperative that I acquire a
trustworthy computer and load it with trustworthy software in order to
use my seed securely, so I might as well have it generate my seeds and
my
recovery codes for me.
What really did catch my attention, but which was kind of buried in the
project documentation, is the ability to verify the integrity of each
share independently without using a computer. For example, if I store a
share with some relative who lives thousands of kilometers away, I'll be
able to take that share out of its tamper-evident bag on my annual
holiday visit, verify that I can still read it accurately by validating
its checksum, and put it into a new bag for another year. For this
procedure, I don't need to bring copies of any of my other shares,
allowing them (and my seed) to stay safe.
---
I do have one question after watching an excellent video[2] about the
motivation for this system. In the video, one of the threat models
described is a disarrangement of the words in a metal backup system.
The implication seems to be that this would be an accidental
disarrangement, which obviously the Codex32 checksum would catch during
periodic offline verification. But what about deliberate modification
of a recovery code? For example, Bob doesn't keep his seed loaded on
any computer; it only exists in Codex32 shares which Bob plans to
combine together in 20 years when he retires, although he makes regular
deposits to the pubkeys derived from the seed's master xpub. Mallory is
able to obtain access to Bob's shares, allowing her to immediately steal
his current funds---but also allowing her to replace them with
similar-looking
shares with the same metadata and valid checksums so that Bob
continues making deposits to the wallet.
I'm curious about whether there's a way to prevent this attack without
otherwise compromising the properties of the code? For example, some
extra data that Bob can carry around (or memorize) for verifying the
shares haven't changed, but which is not otherwise needed for recovery
(so there's no problem if it's lost).
Thanks,
-Dave
[1] https://secretcodex32.com/faq/index.html
[2]
https://www.youtube.com/watch?v=kf48oPoiHX0&list=PLyOGyBytgcuQLi9DC5g88DOEGnqBDPmq1&index=2
|
