diff options
| author | David A. Harding <dave@dtrt.org> | 2023-02-19 10:13:33 -1000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-02-19 20:13:39 +0000 |
| commit | b5b1d8e31909e9c07fece98592b18a849795a185 (patch) | |
| tree | 7ef0cbb1e1097f7b629451af564d7ec79f0ceef6 | |
| parent | 5df993bbcddc081faacc54470c758c1616ae0d81 (diff) | |
| download | pi-bitcoindev-b5b1d8e31909e9c07fece98592b18a849795a185.tar.gz pi-bitcoindev-b5b1d8e31909e9c07fece98592b18a849795a185.zip | |
Re: [bitcoin-dev] Codex32
| -rw-r--r-- | 3b/9e53c32ad41df317269a47261f2f90f6eeff72 | 193 |
1 files changed, 193 insertions, 0 deletions
diff --git a/3b/9e53c32ad41df317269a47261f2f90f6eeff72 b/3b/9e53c32ad41df317269a47261f2f90f6eeff72 new file mode 100644 index 000000000..94917e82a --- /dev/null +++ b/3b/9e53c32ad41df317269a47261f2f90f6eeff72 @@ -0,0 +1,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 + |