From: "David A. Harding" <dave@dtrt•org>
To: Andrew Poelstra <apoelstra@wpsoftware•net>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Codex32
Date: Sun, 19 Feb 2023 10:13:33 -1000 [thread overview]
Message-ID: <f19acdabd3fbc0ff389669131acbb79e@dtrt.org> (raw)
In-Reply-To: <Y+40gVnMpj0prfQk@camus>
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
next prev parent reply other threads:[~2023-02-19 20:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-16 2:16 Russell O'Connor
2023-02-16 11:50 ` Pavol Rusnak
2023-02-16 13:49 ` Andrew Poelstra
2023-02-19 20:13 ` David A. Harding [this message]
2023-02-19 22:12 ` Andrew Poelstra
2023-02-19 23:05 ` Christopher Allen
2023-02-20 0:52 ` Russell O'Connor
2023-02-22 16:29 ` Peter Todd
2023-02-22 19:01 ` Russell O'Connor
2023-02-23 3:30 ` Russell O'Connor
2023-02-23 16:36 ` Russell O'Connor
2023-02-23 18:26 ` Russell O'Connor
2023-02-22 17:24 ` Russell O'Connor
2023-02-20 18:44 ` Andrew Poelstra
2023-02-20 18:48 ` Pavol Rusnak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f19acdabd3fbc0ff389669131acbb79e@dtrt.org \
--to=dave@dtrt$(echo .)org \
--cc=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox