Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id E6CB6C002B for ; Thu, 23 Feb 2023 03:30:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id ADBE281264 for ; Thu, 23 Feb 2023 03:30:24 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org ADBE281264 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=WCCcDydf 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 GQJbDSDR02eD for ; Thu, 23 Feb 2023 03:30:23 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org D0F5D8125A Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) by smtp1.osuosl.org (Postfix) with ESMTPS id D0F5D8125A for ; Thu, 23 Feb 2023 03:30:22 +0000 (UTC) Received: by mail-pg1-x529.google.com with SMTP id y19so5320988pgk.5 for ; Wed, 22 Feb 2023 19:30:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=rBBqA4AsNNOzdgbAhLb7/EWyu50pZ4w4/fsdsg74eIk=; b=WCCcDydfezwItyVSoU+oobezGOayRMjC1XidTLO5+VsPcp5uEPfeKKxnSrwzyeaYCZ Cw85IQpB8EyUkcdD8BCzrVwn4NqB9lxwv928u3lkqD0x3wGXRQX2X8gQ1wQiaYpjG/N/ fHa1WITnR1eG3+uhzcNYOSspZ61aXqERPI7wGfYZ8Eu+a8g01Hs/7ynAxu7SLeD6DW6K FOnP5t6K6f8rVXnM3JExk7fSifHiDywk3DSi9LIe9yU+R5bafqQ3oLtO/ByDNJqR4GUT Fn1+5D/RxrFdnwCuEaujO8OwZyEneWUSPuQ2F1meZBvhpE+yI46BMADQGSGSJx90DFx1 hJ9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=rBBqA4AsNNOzdgbAhLb7/EWyu50pZ4w4/fsdsg74eIk=; b=zgEpVzvLqlfG6X8ImI+6R4TO87SGzW9ynnrNWok1FzhbyEfer90Z9H5ZGoL6/sFBp7 iqGK17UxfM8j+3YbpQ35AQpwqrEDpZIR06lM6jNOwCvDcCi3GId6/mctoGOqWB+WvcnY 2djh7J4lZxYrs0ebXaexnbcQO93rxlA/3OhE/weWRShpKNK/rFgkcYu0CSdu0KVnMZhv 4Om+lQeC8041+I2aLsfIUndsasa/+7lHx8R4bIMlFwi291dnON44gGU/ZjJlcmzU6cKP MlMTCKdfEFjJ62ioRAJVWVXTjov3pk4v+I7ZwdjYvkXSc5Oez7nEmbBqJJAfIfqnrWEN uRKg== X-Gm-Message-State: AO0yUKXPTgBA1kX63sq0bT7HO0mHAwhZQFOGht48w/j7+igrScckajms 1wn2lWltHsB8Hu7chjds19ULygaz3EvxRoqyog6DuMUMXohT3192 X-Google-Smtp-Source: AK7set+VHJgONfkCoI2sP+zPazK0yv1a7w+C84uREyjnAYSD+AubjEUvvCEb+7c0o3FXy0dbQSgGsbjggadzOZiQ9Dw= X-Received: by 2002:a63:6d4a:0:b0:501:26b5:f0d2 with SMTP id i71-20020a636d4a000000b0050126b5f0d2mr1455455pgc.3.1677123021728; Wed, 22 Feb 2023 19:30:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Russell O'Connor" Date: Wed, 22 Feb 2023 22:30:10 -0500 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000f48d2305f555a137" 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: Thu, 23 Feb 2023 03:30:25 -0000 --000000000000f48d2305f555a137 Content-Type: text/plain; charset="UTF-8" After some consultation, I now see that generators for all degree 2 BCH codes, such as ours, are smooth and factor into quadratic and linear components. Anyhow the upshot of all this is that you can perform a "quickcheck" verification of the codex32 strings for whatever size of verification you want to do, 1 character, 2 characters, 3 characters, upto the full 13 characters. Each of these partial verifications will have BCH properties. A 1 character quickchecksum will guarantee to detect any 1 character error. A 3 character quickchecksum will guarantee to detect any 2 character error, etc. There remains a 1 in 32^n chance of failing to detect larger numbers of errors where n is the size of your quickcheck. To illustrate, let's consider a quickcheck of size 2. This can detect any 1 character error and will only have a 1/1024 chance of failing to detect other random errors. Let's take the second test vector as our example: " MS12NAMEA320ZYXWVUTSRQPNMLKJHGFEDCAXRPP870HKKQRM" You start in a specified initial state with a pair of bech32 characters. For MS1 strings and a size 2 quickcheck it would be the pair of Bech32 characters 'AS'. Next we "add" the first character after the prefix, which is '2' by using the addition volvelle or lookup table. "Adding" '2' to 'S' yields '6' and our state becomes 'A6'. Next we have to look up 'A6' in a lookup table. This table is too big to fit in the margin of this email, so I will have to omit it. But it would have an entry mapping 'A6' -> 'QM'. Our state becomes 'QM' From this point we have an even number of remaining characters in the input string and we can work 2 characters at a time. We "add" the next two data characters from our string, which are 'NA'. Again, using the volvelle or lookup table we get that adding 'N' to 'Q' yields 'N', and adding 'A' to 'M' yields 'X'. So our state is now 'NX' Next we look up 'NX' in this table I haven't given you and we will find an entry mapping 'NX' -> 'DX', making 'DX' our new state. We keep repeating this process alternating between adding pairs of characters and using this unstated lookup table all the way until the end where we will reach a final state which will be 'H9'. If you follow this procedure with any string (upto 400 bit master seeds) you will always end up in the state 'H9'. A specialized worksheet would help guide the process making the process easier to follow. This process is somewhat close to Peter Todd's suggestion of using a lookup table on "words", which in this case would be pairs of bech32 characters, and adding values together. The catch is that the addition is done with Bech32 addition rather than calculator addition, which I accept is a moderately large catch. Anyhow, the point is that you can do this sort of partial verification by hand to whatever degree you like, if you are in a rush and are willing to accept larger chances of failing to catch random errors. On Wed, Feb 22, 2023 at 2:01 PM Russell O'Connor wrote: > After some poking around at the math, I do see that the 13 character > generator (for regular sized shares) is reasonably "smooth", having roots > at T{11}, S{16}, and C{24}. > > This means we could build a "quick check" worksheet to evaluate the string > modulo (x - T) to verify a 5 bit checksum, whose operation would be similar > to the existing checksum worksheet in structure but significantly less work. > > Perhaps 5 bits is too short, and it is more reasonable working modulo (x - > T)*(x - S) to get a 10 bit checksum. A worksheet for a 15 bit checksum is > also an option, and possibly others well depending on the size of the other > factors. I think this process is would be about as simple as any other > comparable hand operated checksum over the bech32 alphabet would be. > > I haven't looked into the smoothness of the long generator for seeds that > are greater than 400 bits. If it isn't smooth and smoother options are > available, perhaps it should be changed. > > On Wed, Feb 22, 2023 at 11:29 AM Peter Todd via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> On Sun, Feb 19, 2023 at 10:12:51PM +0000, Andrew Poelstra via bitcoin-dev >> wrote: >> > > 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. >> > > >> > >> > 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. >> > >> > 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 >> Codex32 >> uses is much more complex than necessary if you are simply verifying a >> share by >> itself. >> >> A *much* simpler approach would be to use a simple mod N = 0 checksum, >> either >> 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 >> = 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 >> everyone >> 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 >> verification >> 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 >> share: >> 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 >> going >> undetected than a complex procedure that people don't actually do at all. >> >> -- >> https://petertodd.org 'peter'[:-1]@petertodd.org >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > --000000000000f48d2305f555a137 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
After some consultation, I now see that generators fo= r all degree 2 BCH codes, such as ours, are smooth and factor into quadrati= c and linear components.

Anyhow the upshot of all = this is that you can perform a "quickcheck" verification of the c= odex32 strings for whatever size of verification you want to do, 1 characte= r, 2 characters, 3 characters, upto the full 13 characters.=C2=A0 Each of t= hese partial verifications will have BCH properties.=C2=A0 A 1 character qu= ickchecksum will guarantee to detect any 1 character error.=C2=A0 A 3 chara= cter quickchecksum will guarantee to detect any 2 character error, etc.=C2= =A0 There remains a 1 in 32^n chance of failing to detect larger numbers of= errors where n is the size of your quickcheck.

To= illustrate, let's consider a quickcheck of size 2.=C2=A0 This can dete= ct any 1 character error and will only have a 1/1024 chance of failing to d= etect other random errors.=C2=A0 Let's take the second test vector as o= ur example: "MS12NAMEA320ZYXWVUTS= RQPNMLKJHGFEDCAXRPP870HKKQRM"

You start in a specified = initial state with a pair of bech32 characters.=C2=A0 For MS1 strings and a= size 2 quickcheck it would be the pair of Bech32 characters 'AS'.<= /div>

Next we "add" the first character after = the prefix, which is '2' by using the addition volvelle or lookup t= able.=C2=A0 "Adding" '2' to 'S' yields '6'= ; and our state becomes 'A6'.

Next we have= to look up 'A6' in a lookup table.=C2=A0 This table is too big to = fit in the margin of this email, so I will have to omit it.=C2=A0 But it wo= uld have an entry mapping 'A6' -> 'QM'.=C2=A0 Our state = becomes 'QM'

From this point we have a= n even number of remaining characters in the input string and we can work 2= characters at a time. We "add" the next two data characters from= our string, which are 'NA'.=C2=A0 Again, using the volvelle or loo= kup table we get that adding 'N' to 'Q' yields 'N',= and adding 'A' to 'M' yields 'X'.=C2=A0 So our sta= te is now 'NX'

Next we look up 'NX= ' in this table I haven't given you and we will find an entry mappi= ng 'NX' -> 'DX', making 'DX' our new state.

We keep repeating this process alternating between add= ing pairs of characters and using this unstated lookup table all the way un= til the end where we will reach a final state which will be 'H9'.

If you follow this procedure with any string (upto = 400 bit master seeds) you will always end up in the state 'H9'.

A specialized worksheet would help guide the process = making the process easier to follow.


This process is somewhat close to Peter Todd's suggestion of usin= g a lookup table on "words", which in this case would be pairs of= bech32 characters, and adding values together.=C2=A0 The catch is that the= addition is done with Bech32 addition rather than calculator addition, whi= ch I accept is a moderately large catch.

Anyho= w, the point is that you can do this sort of partial verification by hand t= o whatever degree you like, if you are in a rush and are willing to accept = larger chances of failing to catch random errors.

<= div>
On Wed, Feb 22, 2023 at 2:01 PM Russell O'Connor <roconnor@blockstream.com> wrote:
After some poking around at the math, I do see that the 13 character gener= ator (for regular sized shares) is reasonably "smooth", having ro= ots at T{11}, S{16}, and C{24}.

This means we coul= d build a "quick check" worksheet to evaluate the string modulo (= x - T) to verify a 5 bit checksum, whose operation would be similar to the = existing checksum worksheet in structure but significantly less work.
=

Perhaps 5 bits is too short, and it is more reasonable = working modulo (x - T)*(x - S) to get a 10 bit checksum.=C2=A0 A worksheet = for a 15 bit checksum is also an option, and possibly others well depending= on the size of the other factors.=C2=A0 I think this process is would be a= bout as simple as any other comparable hand operated checksum over the bech= 32 alphabet would be.

I haven't looked int= o the smoothness of the long generator for seeds that are greater than 400 = bits.=C2=A0 If it isn't smooth and smoother options are available, perh= aps it should be changed.

On Wed, Feb 22, 2023 at= 11:29 AM Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.= org> wrote:
On Sun, Feb 19, 2023 at 10:12:51PM +0000, Andrew Poelstra via bitcoin-de= v wrote:
> > 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.=C2=A0 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 annua= l
> > holiday visit, verify that I can still read it accurately by vali= dating
> > its checksum, and put it into a new bag for another year.=C2=A0 F= or this
> > procedure, I don't need to bring copies of any of my other sh= ares,
> > allowing them (and my seed) to stay safe.
> >
>
> 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* bei= ng
> actively used, without exposing them to the sorts of threats associate= d
> with active use.
>
> 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 = Codex32
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&= #39;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 accidenta= lly been
substituted.

Indeed, with some brute forcing and small checksums, I'd expect it to b= e
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<= br> 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 be= tter 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 al= l.

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000f48d2305f555a137--