From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 99A26C002B for ; 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 ; 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 ; 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 ; 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" To: Andrew Poelstra , Bitcoin Protocol Discussion In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.10 Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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