From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0EE8BC002B for ; 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 ; 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 ; 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 ; 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: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudejledgkeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtvdenucfhrhhomheprfgvthgv rhcuvfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtth gvrhhnpeelvdellefftddukeduffejgfefjeeuheeileeftdfgteduteeggeevueethfej tdenucffohhmrghinhepphgvthgvrhhtohguugdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvgesphgvthgvrhhtohguugdr ohhrgh X-ME-Proxy: 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 To: Andrew Poelstra , Bitcoin Protocol Discussion Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MhrDzvwe3R5t77O4" Content-Disposition: inline In-Reply-To: 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 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--