{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 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)."}