rich1.0npub17qxssk9sj2r7jswvh3y32e7vwz7mcckhz33gk9nurdmw0lhsfkgswupwethttps://nostr.ae/npub17qxssk9sj2r7jswvh3y32e7vwz7mcckhz33gk9nurdmw0lhsfkgswupwetnjumphttps://nostr.ae📅 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.