From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5D764C002B for ; Wed, 22 Feb 2023 17:24:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 384C582094 for ; Wed, 22 Feb 2023 17:24:33 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 384C582094 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=blockstream-com.20210112.gappssmtp.com header.i=@blockstream-com.20210112.gappssmtp.com header.a=rsa-sha256 header.s=20210112 header.b=dA4SBy1m X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhYxFiiX7giw for ; Wed, 22 Feb 2023 17:24:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 7926F81F12 Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) by smtp1.osuosl.org (Postfix) with ESMTPS id 7926F81F12 for ; Wed, 22 Feb 2023 17:24:31 +0000 (UTC) Received: by mail-pj1-x1031.google.com with SMTP id na9-20020a17090b4c0900b0023058bbd7b2so8987377pjb.0 for ; Wed, 22 Feb 2023 09:24:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rhdHUNOtTrMJQ17QsAzZcHBsIKc9jax4hA8ETjZ9xx0=; b=dA4SBy1mwWA/MuTvE+3DyoLfveO1SFXqsLNv9lhdz2zpoteMVMGTYnXkRX1J5cbodt 4++df1f+bsyG1sGkyiM8ieeib7/cSDOSSJ8T7V1XihWm1tf3ohbmr08Wyyo2S8eplYOk ads4UOb1dWng5B1eoQtGEgo1v3W7kqvQyhP+Ey8mJoH6llSH5QQfwoHRNE/kQy7/c4QW PIL8EvL2R10LWflc/TRR9dXGAMusyrLqsToFhJUsBwIjpNQyehhTVplZJPx+GoF4+4Ku gArj/IoagwyfkNNsV4wJlTaaTHXB+y1VJm8jl/XHO9w2JQcSD1fFs33WuwuPQ1/NDGov bYjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rhdHUNOtTrMJQ17QsAzZcHBsIKc9jax4hA8ETjZ9xx0=; b=SPMwKLbzw5PiKob4mfIPBVtPNXKMXq6ztfmzYC8sAYGPA+DIrkmBLhLWYMpU2Wr2aD OwdWRWv7Ofs5WzQFrPADR9pcMBHVrZ7pToowV5Ij8GLoU4G9OFCP68c5aU24wKtZE+q9 T4znc13lmtomFzY1Lv919DTp3RR5LoUvnRP+lxJv6GmZl4HMs1XqwIR8bNn/De+AhMvV sBZx7Tfdp3CpXQEZA7W1NcDSU4rypU6WNvRM/6EVzqbgeXZ4FRJtKtfIe/M41CVbKOx0 2CGk0UxddXAKSFEP1LtARO+R3XHzNVOeGyDdiq6l20CHk6Im8cordx4VLiNdAMG90qcv gy+w== X-Gm-Message-State: AO0yUKXyRWnxi6mAPck1EEuObP4075GT9i0gy70+LyheE0JyoW3hARdR dGOtvYFahjWTD2Bv5uF11Nf6XTboR9jAfG+dEUZ84A== X-Google-Smtp-Source: AK7set+f8JiAERiR/HemjstfAM25jJvjT2OBQcjPqHnzcH6diY6TYklJDu1beyK7b9vS46nemx3MWe5T1MUcG1QOdEk= X-Received: by 2002:a17:90b:4cd0:b0:234:690:cf7c with SMTP id nd16-20020a17090b4cd000b002340690cf7cmr2183261pjb.37.1677086670668; Wed, 22 Feb 2023 09:24:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Russell O'Connor" Date: Wed, 22 Feb 2023 12:24:19 -0500 Message-ID: To: "David A. Harding" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000043708a05f54d2b68" 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: Wed, 22 Feb 2023 17:24:33 -0000 --00000000000043708a05f54d2b68 Content-Type: text/plain; charset="UTF-8" On Sun, Feb 19, 2023 at 3:13 PM David A. Harding via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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). > While perhaps not entirely impossible, doing error correction by hand is far more difficult than just the error detection process. Fortunately, error correction can be aided by a computer needing very little trust. When doing hand computation of the checksum, there is an error if the final "residue" is different from the value given in the codex32 spec. After double checking your hand computation by redoing it, if you still get the same incorrect residue, there is an error in your share data somewhere. What you can do is plug in the residue that you did compute into a computer, and have it produce an error correction string. You can then, by hand, add this error correction string to your share to get a corrected share. If it were the case that all types of character errors were equally likely (as in during an error any character is equally likely to be transformed into any other character), then the computer would gain zero information about your actual share data. Of course, it is not in fact the case that all transcription errors are equally likely, and so the computer can learn a little bit about your share. The fewer errors that are made, the less data it can recover. If you only have one character in error, then 5 bits is the most data it can recover, and that is assuming that it can somehow infer your error perfectly from the delta of the error correction, which isn't actually going to be the case. Of course, a single share from a split secret has no information about your master seed (the master seed is hidden in the correlation between different shares). So learning partial information about one share isn't going to be enough by itself to even begin compromising your master key. This all still needs to be written up in more detail, but I figured I would give a preview here. - 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. > There was a design for a second level share scheme floating around somewhere. I'll have to dig it up. As I recall this is made slightly more complicated by needing to incorporate share metadata (i.e. the share index) when doing a second split, but it seemed doable at the time. > - 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. > Personally, I don't consider the derivation path / descriptor data as that sensitive, and I would recommend making wide backups of that data. It certainly would make sense to store descriptor data alongside wherever you keep your shares, and more places beyond that. On the other hand, if you are trying to keep your shares innocuous somehow, perhaps you won't be able to keep the descriptor data alongside your shares. 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. > I do think hardware wallets are great, and overall provide a lot of practical protection. What is notable is that once the secrets are loaded onto a hardware wallet, as long as that wallet remains isolated, it cannot leak any secrets. Of course, a wallet needs to interact with the Bitcoin protocol and P2P network, at least indirectly, in order to function, so we must break that isolation. However, if we can limit the communication capabilities of a hardware wallet, even a malicious wallet shouldn't be able to leak the secret data. There are three main vectors a hardware wallet can try to communicate that I am aware of: 1. Compromise at seed/master secret (or in this case shares of the master secret) during generation time. 2. Lie about public keys at public key generation time. 3. Exfiltrate data though signature data or otherwise during signature generation time. #3 is largely mitigated through using anti-exfil signing and air gapping the hardware wallet (e.g. using QR codes, or using RS-232 if you consider that air gaping). Using multiple wallets from different vendors doing deterministic signing is another possibility, but I consider the method deprecated in favour of anti-exfil. Addressing #1 is where codex32 lies, by taking master secret handling functions out of the hardware wallet. My understanding is that it is difficult for digital hardware, which tries very hard to be deterministic, to generate randomness, especially for isolated hardware devices like hardware wallets. Also it is hard for hardware to tell if their hardware random number generator is broken. Generally I don't trust small pieces of isolated digital hardware to generate master seeds, even when they are not malicious. This may just be due to my ignorance of how they operate. #2 seems to be the hardest issue to address. My current thinking is to generate addresses on a diverse set of hardware and/or using public derivations. Perhaps an alternative to BIP-32 could be designed to make it easy to generate zero-knowledge proofs of pubkey derivations. Of course there are other ways for a hardware wallets to exfiltrate data: The wallet can blink lights, make noise, or it can try to use radio broadcasts, etc. These other attack vectors seem to require physically local support, which is a fairly big hurdle to overcome. I suppose even these vectors could be mitigated through various levels of tinfoil. --00000000000043708a05f54d2b68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Feb 19, 2023 at 3:13 PM David A. Harding via bitcoin-dev <= ;bitcoin-dev@lists= .linuxfoundation.org> wrote:
=C2=A0 =C2=A0Codex32 allows the individual to periodically perform their =C2=A0 =C2=A0recollection on paper in a private room without electronics an= d use
=C2=A0 =C2=A0nothing but a pen and some loookup tables (or a paper device) = to
=C2=A0 =C2=A0verify that they recalled the string correctly (and its checks= um can
=C2=A0 =C2=A0help with correcting up to several errors, although you might = need a
=C2=A0 =C2=A0computer for error location and correction assistance).

While perhaps not entirely impossible, doing = error correction by hand is far more difficult than just the error detectio= n process.
Fortunately, error correction can be aided by a comput= er needing very little trust.

When doing hand comp= utation of the checksum, there is an error if the final "residue"= is different from the value given in the codex32 spec.
After dou= ble checking your hand computation by redoing it, if you still get the same= incorrect residue, there is an error in your share data somewhere.

What you can do is plug in the residue that you did compu= te into a computer, and have it produce an error correction string.
You can then, by hand, add this error correction string to your share to= get a corrected share.

If it were the case that a= ll types of character errors were equally likely (as in during an error any= character is equally likely to be transformed into any other character), t= hen the computer would gain zero information about your actual share data.= =C2=A0 Of course, it is not in fact the case that all transcription errors = are equally likely, and so the computer can learn a little bit about your s= hare. The fewer errors that are made, the less data it can recover. If you = only have one character in error, then 5 bits is the most data it can recov= er, and that is assuming that it can somehow infer your error perfectly fro= m the delta of the error correction, which isn't actually going to be t= he case.

Of course, a single share from a split se= cret has no information about your master seed (the master seed is hidden i= n the correlation between different shares).=C2=A0 So learning partial info= rmation about one share isn't going to be enough by itself to even begi= n compromising your master key.

This all still nee= ds to be written up in more detail, but I figured I would give a preview he= re.

- Hierarchy: Codex32 does not natively provide support for nested SSSS
=C2=A0 =C2=A0whereas SLIP39 does.=C2=A0 E.g., in SLIP39, you can require 2-= of-3 for
=C2=A0 =C2=A0{me, family, friends} where me is 2-of-3 {fire_safe, bank_safe= ,
=C2=A0 =C2=A0buried_in_woods}, family is 1-of-3 {alice, bob, carol}, and fr= iends
=C2=A0 =C2=A0are 2-of-5 {d, e, f, g, h}.=C2=A0 I assume you can do the same= with Codex32
=C2=A0 =C2=A0by using the share for one level as the secret for the next le= vel,
=C2=A0 =C2=A0although this is not described in the protocol.

There was a design for a second level share scheme fl= oating around somewhere. I'll have to dig it up. As I recall this is ma= de slightly more complicated by needing to incorporate share metadata (i.e.= the share index) when doing a second split, but it seemed doable at the ti= me.
=C2=A0
- Versioning: Codex32's metadata can store version information for
=C2=A0 =C2=A0wallets that use implicit BIP32 paths (e.g. BIP44/49/84/86), a= lthough
=C2=A0 =C2=A0this would cut into the space available for users to set their= own
=C2=A0 =C2=A0metadata and it is not specified in the draft BIP.=C2=A0 SLIP3= 9 also
=C2=A0 =C2=A0doesn't specify anything about implicit path versioning an= d, AFAICT,
=C2=A0 =C2=A0doesn't have any room to store such metadata without reduc= ing seed
=C2=A0 =C2=A0entropy.

Personally, I don= 't consider the derivation path / descriptor data as that sensitive, an= d I would recommend making wide backups of that data.
It certainl= y would make sense to store descriptor data alongside wherever you keep you= r shares, and more places beyond that.
On the other hand, if you = are trying to keep your shares innocuous somehow, perhaps you won't be = able to keep the descriptor data alongside your shares.

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 researche= d
it.=C2=A0 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.

I do think hardw= are wallets are great, and overall provide a lot of practical protection.= =C2=A0 What is notable is that once the secrets are loaded onto a hardware = wallet, as long as that wallet remains isolated, it cannot leak any secrets= .

Of course, a wallet needs to interact with the B= itcoin protocol and P2P network, at least indirectly, in order to=C2=A0 fun= ction, so we must break that isolation.=C2=A0 However, if we can limit the = communication capabilities of a hardware wallet, even a malicious wallet sh= ouldn't be able to leak the secret data.

There= are three main vectors a hardware wallet can try to communicate that I am = aware of:

1. Compromise at seed/master secret (or = in this case shares of the master secret) during generation time.
=
2. Lie about public keys at public key generation time.
= 3. Exfiltrate data though signature data or otherwise during signature gene= ration time.

#3 is largely mitigated through using= anti-exfil signing and air gapping the hardware wallet (e.g. using QR code= s, or using RS-= 232 if you consider that air gaping).
Using multiple wallets = from different vendors doing deterministic signing is another possibility, = but I consider the method deprecated in favour of anti-exfil.

Addressing #1 is where codex32 lies, by taking master secre= t handling functions out of the hardware wallet.

M= y understanding is that it is difficult for digital hardware, which tries v= ery hard to be deterministic, to generate randomness, especially for isolat= ed hardware devices like hardware wallets.
Also it is hard for ha= rdware to tell if their hardware random number generator is broken.=C2=A0 G= enerally I don't trust small pieces of isolated digital hardware to gen= erate master seeds, even when they are not malicious. This may just be due = to my ignorance of how they operate.

#2 seems to b= e the hardest issue to address.=C2=A0 My current thinking is to generate ad= dresses on a diverse set of hardware and/or using public derivations.
=
Perhaps an alternative to BIP-32 could be designed to make it easy to = generate zero-knowledge proofs of pubkey derivations.

<= div>Of course there are other ways for a hardware wallets to exfiltrate dat= a:=C2=A0 The wallet can blink lights, make noise, or it can try to use radi= o broadcasts, etc.=C2=A0 These other attack vectors seem to require physica= lly local support, which is a fairly big hurdle to overcome.=C2=A0 I suppos= e even these vectors could be mitigated through various levels of tinfoil.<= br>

--00000000000043708a05f54d2b68--