📅 Original date posted:2023-02-22
🗒️ Summary of this message: A simpler approach to verify the integrity of each share independently without using a computer is suggested, using a simple mod N = 0 checksum.
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230222/b56aa2ec/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-07 23:19:44
in reply to nevent1q…hvlf
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 23:19:44Event JSON
{
"id": "87a12f1d42a02de7ef5d995f4dc13a0c6167424a01d2fa3eb1b4663f9e9d88c0",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686179984,
"kind": 1,
"tags": [
[
"e",
"a3a3f4bb7a4f76a4dd4ffb9bad737c4cf2aefb0496fa4b312d6d5bf1fd8cde22",
"",
"root"
],
[
"e",
"cff4c9f19a4aa870ada00970fb7f00c98067b06ded6987bb8f2a6cf1d15e6c5f",
"",
"reply"
],
[
"p",
"6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d"
]
],
"content": "📅 Original date posted:2023-02-22\n🗒️ Summary of this message: A simpler approach to verify the integrity of each share independently without using a computer is suggested, using a simple mod N = 0 checksum.\n📝 Original message:On Sun, Feb 19, 2023 at 10:12:51PM +0000, Andrew Poelstra via bitcoin-dev wrote:\n\u003e \u003e What really did catch my attention, but which was kind of buried in the\n\u003e \u003e project documentation, is the ability to verify the integrity of each\n\u003e \u003e share independently without using a computer. For example, if I store a\n\u003e \u003e share with some relative who lives thousands of kilometers away, I'll be\n\u003e \u003e able to take that share out of its tamper-evident bag on my annual\n\u003e \u003e holiday visit, verify that I can still read it accurately by validating\n\u003e \u003e its checksum, and put it into a new bag for another year. For this\n\u003e \u003e procedure, I don't need to bring copies of any of my other shares,\n\u003e \u003e allowing them (and my seed) to stay safe.\n\u003e \u003e \n\u003e \n\u003e This is good feedback. I strongly agree that this is the big selling\n\u003e point for this -- that you can vet shares/seeds which *aren't* being\n\u003e actively used, without exposing them to the sorts of threats associated\n\u003e with active use.\n\u003e \n\u003e We should make this more prominent in the BIP motivation.\n\nI don't think that use-case is a good selling point. The checksum that Codex32\nuses is much more complex than necessary if you are simply verifying a share by\nitself.\n\nA *much* simpler approach would be to use a simple mod N = 0 checksum, either\nby creating the seed such that each share passes, or by just storing an\nadditional word/symbol with the seed in such a way that sum(words) mod N = 0\npasses. This approach is not only possible to compute by hand with a\nword/symbol-\u003enumber lookup table, and pen and paper or a calculator. It's so\nsimple they could probably *remember* how to do it themselves.\n\n\nSecondly, if all shares have mod N checksums, it may be sufficient for everyone\nto write down the checksums of the *other* shares, to verify they are the\ncorrect ones and a different (otherwise correct) share hasn't accidentally been\nsubstituted.\n\nIndeed, with some brute forcing and small checksums, I'd expect it to be\nmathematically possible to generate Shamir's secret sharing shards such that\nevery shard can share the *same* checksum. In which case the share verification\nprocedure would be to simply ask every share holder to verify the checksum\nmanually using the mod N procedure, and then verify that each share holder has\nthe same checksum. This would be less error prone in terms of leaking\ninformation accidentally if the checksum was obviously *not* part of the share:\neg by encoding the share with words, and the checksum with a number.\n\nObviously, small checksums aren't fool proof. But we're probably better off\ncreating a relatively easy procedure with a 1-in-1000 chance of an error going\nundetected than a complex procedure that people don't actually do at all.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230222/b56aa2ec/attachment.sig\u003e",
"sig": "af72318886e3aff63e03ee650a648c1b07c3fb1db3afae743692802810d130f65bc7ca60c27dd7fa65f38e660e5c2e686dc5a74262697c6fbe01057368f5c380"
}