path: root/ad/85dfaf2882e974b9552b71add3892b459e0b5e

Return-Path: <pete@petertodd.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 0EE8BC002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 22 Feb 2023 16:29:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id CC9B1611C9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 22 Feb 2023 16:29:14 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org CC9B1611C9
Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key,
 unprotected) header.d=messagingengine.com header.i=@messagingengine.com
 header.a=rsa-sha256 header.s=fm1 header.b=dx3P8IWX
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.704
X-Spam-Level: 
X-Spam-Status: No, score=-0.704 tagged_above=-999 required=5
 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id RVglUlypgHGr
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 22 Feb 2023 16:29:13 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 396BC611C8
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com
 [64.147.123.24])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 396BC611C8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 22 Feb 2023 16:29:13 +0000 (UTC)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
 by mailout.west.internal (Postfix) with ESMTP id 3749E3200920;
 Wed, 22 Feb 2023 11:29:10 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163])
 by compute2.internal (MEProxy); Wed, 22 Feb 2023 11:29:10 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-type:date:date:feedback-id
 :feedback-id:from:from:in-reply-to:in-reply-to:message-id
 :mime-version:references:reply-to:sender:subject:subject:to:to
 :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
 fm1; t=1677083349; x=1677169749; bh=ihWBecgkMGQrzLQnYME2xvPENPGn
 zz1MpAofKskvBM4=; b=dx3P8IWXCvrLk7Mv4HX1/cQqNx1DARiNFt5euJRbDq2n
 8mN+tfsnwTg8daTtFY2kTppW6HSkQcrQz4HRHHdJN3/INGzG4NRFIRER39L9/+Gr
 C++kpWWCH4E3y4Oy2XZ2uAz87D8zuhkC5CMSpvyCPF3LTBDIFRNy0c2bPxUgdiMj
 RKYQz0b/Td8AXkh7xc2UHnl/U30X4/rjxoZiOU5S2zHNpEyLi+iJF08xr8UoO2ZB
 7VX0E+l9ILrXbsTslCxGa9GD90hnQ4AEjchD27/d/9udCt+iarbGkb85Wiuxi3VB
 LQiY7KOliwAOavORL0dwAqw/5V4R/JIJR2e32A8b8Q==
X-ME-Sender: <xms:1UL2Y7MfPjiMARXR6pT1rIkFFtQ6GBK2GGkOqyyqUYLhlIucJnCEDA>
 <xme:1UL2Y19t6H3kqR82f_wqkAdhJzk_zltmWZfpmyYy5i_iozk5UsTDCHBbzyR2jflUi
 Mnu33SK12fjN3sZy_Q>
X-ME-Received: <xmr:1UL2Y6RDLpsh9Rg2USEYNOHkLpZp6juvml2kIAcm0QmbSVIjZRKqpkapDw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudejledgkeekucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtvdenucfhrhhomheprfgvthgv
 rhcuvfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtth
 gvrhhnpeelvdellefftddukeduffejgfefjeeuheeileeftdfgteduteeggeevueethfej
 tdenucffohhmrghinhepphgvthgvrhhtohguugdrohhrghenucevlhhushhtvghrufhiii
 gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvgesphgvthgvrhhtohguugdr
 ohhrgh
X-ME-Proxy: <xmx:1UL2Y_uQi3szzn5__QCZMvLQtBf3WfqYzJmD30k5IYqh7vgi_JpVGw>
 <xmx:1UL2YzcBVoyF6GbopkY3W98jDC4HCGxn8e4X6zPRnSEpi8SaW-it0A>
 <xmx:1UL2Y72KUFcyGZki057an7xoImgecYP_bbCxQ0t-z0iJE6WpOLy24A>
 <xmx:1UL2Y66hss4qwdWcvQGGGMBSjopC8GkotGgn4KA_qrL5Ad6e8t4VzA>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 22 Feb 2023 11:29:08 -0500 (EST)
Received: by localhost (Postfix, from userid 1000)
 id 7C5865F92A; Wed, 22 Feb 2023 11:29:03 -0500 (EST)
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
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: Wed, 22 Feb 2023 16:29:15 -0000


--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--