Feedback-ID: i525146e8:Fastmail
Date: Wed, 22 Feb 2023 11:29:03 -0500
From: Peter Todd <pete@petertodd.org>
To: Andrew Poelstra <apoelstra@wpsoftware.net>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y/ZCz2JlYiQ1MvaG@petertodd.org>
References: <CAMZUoKmiwXW50F2onqNUZO8HXQa4+Z=z3s3WyN7-rAMV=KiSgw@mail.gmail.com>
 <CAF90AvmaRYO6HKn9npyfzO6M6FZnN6DRhqopLpeSnHJNK=5i9g@mail.gmail.com>
 <Y+40gVnMpj0prfQk@camus>
 <f19acdabd3fbc0ff389669131acbb79e@dtrt.org>
 <Y/Ke4yV7eV/87Kat@camus>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="MhrDzvwe3R5t77O4"
Content-Disposition: inline
In-Reply-To: <Y/Ke4yV7eV/87Kat@camus>
Subject: Re: [bitcoin-dev] Codex32
Precedence: list


--MhrDzvwe3R5t77O4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Feb 19, 2023 at 10:12:51PM +0000, Andrew Poelstra via bitcoin-dev w=
rote:
> > 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.
> >=20
>=20
> This is good feedback. I strongly agree that this is the big selling
> point for this -- that you can vet shares/seeds which *aren't* being
> actively used, without exposing them to the sorts of threats associated
> with active use.
>=20
> We should make this more prominent in the BIP motivation.

I don't think that use-case is a good selling point. The checksum that Code=
x32
uses is much more complex than necessary if you are simply verifying a shar=
e by
itself.

A *much* simpler approach would be to use a simple mod N =3D 0 checksum, ei=
ther
by creating the seed such that each share passes, or by just storing an
additional word/symbol with the seed in such a way that sum(words) mod N =
=3D 0
passes. This approach is not only possible to compute by hand with a
word/symbol->number lookup table, and pen and paper or a calculator. It's so
simple they could probably *remember* how to do it themselves.


Secondly, if all shares have mod N checksums, it may be sufficient for ever=
yone
to write down the checksums of the *other* shares, to verify they are the
correct ones and a different (otherwise correct) share hasn't accidentally =
been
substituted.

Indeed, with some brute forcing and small checksums, I'd expect it to be
mathematically possible to generate Shamir's secret sharing shards such that
every shard can share the *same* checksum. In which case the share verifica=
tion
procedure would be to simply ask every share holder to verify the checksum
manually using the mod N procedure, and then verify that each share holder =
has
the same checksum. This would be less error prone in terms of leaking
information accidentally if the checksum was obviously *not* part of the sh=
are:
eg by encoding the share with words, and the checksum with a number.

Obviously, small checksums aren't fool proof. But we're probably better off
creating a relatively easy procedure with a 1-in-1000 chance of an error go=
ing
undetected than a complex procedure that people don't actually do at all.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--MhrDzvwe3R5t77O4
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmP2QsAACgkQLly11TVR
Lzc/6g/+NeaE+wotiOv9/wB3CbNy7aBSZpqwqGOEFWciHCBkRAikk9JpdSc2oJht
SqBMTSzhWCyWvbtrvS2Ee5ZO+lOuR8e3aDwacQxD3pe4sDs1ZXAeXyEsKH7WvUyP
g8qcqN060lCXZGAyZhvAWJjHv89yUV6PFMe2qoghyx37SR7GjgT8caBDs1EktTuj
yPC0UE21S9X+sifVD71v63vWGSZpGqvmEYD2LUPsP7cMUR9vx6zl6DRBMZEsPP8x
zT1U66RWnoxEtD19lxFln32GYtEUEVGczTo9MbTNb1Idbp7dYmOLI0jKetUzIiMB
Itb6OU++D56S516ud3bozOhghIjEUNs89bpy1+HIEsVZ1B9cWcvPEzOBHVSP+9L3
s6oEiWUxwajPUFn1fqJeOyEqrp+m+Z7rAz0fGbI23xf6dJMplpMXKcbAcLUKPARk
IgE8WDQbetyWpuVyBvrnslb0B/P5Lc/vIdPsjQWXuqfilr5mi+/09LFXGfADrhpP
mLuzcWaKFJnl70D/B/K0cmuQj4O23gVIuOmt2gTiogkSSsE7dAE7vNBnjSEmJ4jV
LI/O7PjAgSmVSKJNv4Mv0yXBbWdqh4aCsIl/BNDx+khQgxLwbJX4vJCuDEqbAMFV
zv/3+9Q41U8e5tR915vpWxD60w7NHb/d4Z8qX5wFpw3cV8O11Gk=
=sFAi
-----END PGP SIGNATURE-----

--MhrDzvwe3R5t77O4--