📅 Original date posted:2014-04-04
📝 Original message:On Fri, Apr 4, 2014 at 9:36 AM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> Are you proposing to switch from prime fields to a binary field? Because if you're going to "break up" a secret into little pieces, you can't assume that every piece of the secret will be strictly less than some 8-bit prime modulus. And if you're going to do a base conversion, then you have to do arbitrary-precision integer math anyway, so I don't see that the small field really saves you any code.
Yes, I'm proposing using the binary extension field of GF(2^8). There
are many secret sharing and data integrity applications available
already operating over GF(2^8) so you can go compare implementation
approaches without having to try them our yourself. Obviously anything
efficiently encoded as bytes will efficiently encode over GF(2^8).
> Weren't you just clamoring for implementation *simplicity* in your previous paragraph? :)
I do think there is a material difference in complexity that comes in
layers rather than at a single point. It's much easier to implement a
complex thing that has many individually testable parts then a single
complex part. (Implementing arithmetic mod some huge P is quite a bit
of work unless you're using some very high level language with
integrated bignums— and are comfortable hoping that their bignums are
sufficiently consistent with the spec).
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 15:17:07
in reply to nevent1q…7fhs
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 15:17:07Event JSON
{
"id": "71456e9dd3218b266c23e69d0f905cbc8c946d6139378ddad07744424846cffe",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686151027,
"kind": 1,
"tags": [
[
"e",
"ec3db7ea61043d2181c683590cc6472afc1e727a155c1437be680d2ee4f9939c",
"",
"root"
],
[
"e",
"d2cb22de447fb52d55ceeb65f68891750fa54c7c4c1bc25738e8993ceb7884c8",
"",
"reply"
],
[
"p",
"f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91"
]
],
"content": "📅 Original date posted:2014-04-04\n📝 Original message:On Fri, Apr 4, 2014 at 9:36 AM, Matt Whitlock \u003cbip at mattwhitlock.name\u003e wrote:\n\u003e Are you proposing to switch from prime fields to a binary field? Because if you're going to \"break up\" a secret into little pieces, you can't assume that every piece of the secret will be strictly less than some 8-bit prime modulus. And if you're going to do a base conversion, then you have to do arbitrary-precision integer math anyway, so I don't see that the small field really saves you any code.\n\nYes, I'm proposing using the binary extension field of GF(2^8). There\nare many secret sharing and data integrity applications available\nalready operating over GF(2^8) so you can go compare implementation\napproaches without having to try them our yourself. Obviously anything\nefficiently encoded as bytes will efficiently encode over GF(2^8).\n\n\u003e Weren't you just clamoring for implementation *simplicity* in your previous paragraph? :)\n\nI do think there is a material difference in complexity that comes in\nlayers rather than at a single point. It's much easier to implement a\ncomplex thing that has many individually testable parts then a single\ncomplex part. (Implementing arithmetic mod some huge P is quite a bit\nof work unless you're using some very high level language with\nintegrated bignums— and are comfortable hoping that their bignums are\nsufficiently consistent with the spec).",
"sig": "09d0d8822877ce195dea5e6830fe1059a272777da1345ebceab5a04227ccba11b5cfd01601da401c9c65a8948e415913d5e9cc6e9f56fcb508a126c1bbd03c69"
}