đź“… Original date posted:2014-04-04
đź“ť Original message:On Friday, 4 April 2014, at 10:08 am, Gregory Maxwell wrote:
> 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).
Honestly, that sounds a lot more complicated than what I have now. I made my current implementation because I just wanted something simple that would let me divide a private key into shares for purposes of dissemination to my next of kin et al.
> > 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).
I already have a fairly polished implementation of my BIP, and it's not written in a "very high-level language"; it's C++, and the parts that do the big-integer arithmetic are basically C. I'm using the GMP library: very straightforward, very reliable, very fast.
Do you have a use case in mind that would benefit from byte-wise operations rather than big-integer operations? I mean, I guess if you were trying to implement this BIP on a PIC microcontroller, it might be nice to process the secret in smaller bites. (No pun intended.) But I get this feeling that you're only pushing me away from the present incarnation of my proposal because you think it's too similar (but not quite similar enough) to a threshold ECDSA key scheme.
Matt Whitlock [ARCHIVE] /
npub17q…upwet
2023-06-07 15:17:07
in reply to nevent1q…z7re
Author Public Key
npub17qxssk9sj2r7jswvh3y32e7vwz7mcckhz33gk9nurdmw0lhsfkgswupwetSeen on
wss://relay.nostr.bandPublished at
2023-06-07 15:17:07Event JSON
{
"id": "ce308ee6fca30a0d59e0bdfaca1df8bcc6d893b8f5ab7c81d076ae53ec0a8022",
"pubkey": "f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91",
"created_at": 1686151027,
"kind": 1,
"tags": [
[
"e",
"ec3db7ea61043d2181c683590cc6472afc1e727a155c1437be680d2ee4f9939c",
"",
"root"
],
[
"e",
"71456e9dd3218b266c23e69d0f905cbc8c946d6139378ddad07744424846cffe",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2014-04-04\n📝 Original message:On Friday, 4 April 2014, at 10:08 am, Gregory Maxwell wrote:\n\u003e On Fri, Apr 4, 2014 at 9:36 AM, Matt Whitlock \u003cbip at mattwhitlock.name\u003e wrote:\n\u003e \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\u003e \n\u003e Yes, I'm proposing using the binary extension field of GF(2^8). There\n\u003e are many secret sharing and data integrity applications available\n\u003e already operating over GF(2^8) so you can go compare implementation\n\u003e approaches without having to try them our yourself. Obviously anything\n\u003e efficiently encoded as bytes will efficiently encode over GF(2^8).\n\nHonestly, that sounds a lot more complicated than what I have now. I made my current implementation because I just wanted something simple that would let me divide a private key into shares for purposes of dissemination to my next of kin et al.\n\n\u003e \u003e Weren't you just clamoring for implementation *simplicity* in your previous paragraph? :)\n\u003e \n\u003e I do think there is a material difference in complexity that comes in\n\u003e layers rather than at a single point. It's much easier to implement a\n\u003e complex thing that has many individually testable parts then a single\n\u003e complex part. (Implementing arithmetic mod some huge P is quite a bit\n\u003e of work unless you're using some very high level language with\n\u003e integrated bignums— and are comfortable hoping that their bignums are\n\u003e sufficiently consistent with the spec).\n\nI already have a fairly polished implementation of my BIP, and it's not written in a \"very high-level language\"; it's C++, and the parts that do the big-integer arithmetic are basically C. I'm using the GMP library: very straightforward, very reliable, very fast.\n\nDo you have a use case in mind that would benefit from byte-wise operations rather than big-integer operations? I mean, I guess if you were trying to implement this BIP on a PIC microcontroller, it might be nice to process the secret in smaller bites. (No pun intended.) But I get this feeling that you're only pushing me away from the present incarnation of my proposal because you think it's too similar (but not quite similar enough) to a threshold ECDSA key scheme.",
"sig": "73aa2b94dd422a5e67b13ad02786d27159b84cc9553f36d3b0db4450b16d8c48e77c93e8a27491531595d108e37c08e005795f6835a00bd549262e9a94adfb93"
}