From: "Russell O'Connor" <roconnor@blockstream•com>
To: "David A. Harding" <dave@dtrt•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Codex32
Date: Wed, 22 Feb 2023 12:24:19 -0500 [thread overview]
Message-ID: <CAMZUoKnV6gGBY1_zzAdPyzHLhNAMzM1PiLAHDwiPdBQds3MAxA@mail.gmail.com> (raw)
In-Reply-To: <f19acdabd3fbc0ff389669131acbb79e@dtrt.org>
[-- Attachment #1: Type: text/plain, Size: 6926 bytes --]
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
<https://en.wikipedia.org/wiki/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.
[-- Attachment #2: Type: text/html, Size: 8412 bytes --]
next prev parent reply other threads:[~2023-02-22 17:24 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
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 [this message]
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=CAMZUoKnV6gGBY1_zzAdPyzHLhNAMzM1PiLAHDwiPdBQds3MAxA@mail.gmail.com \
--to=roconnor@blockstream$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dave@dtrt$(echo .)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