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>
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] Codex32
Precedence: list

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