On Fri, Apr 4, 2014 at 9:36 AM, Matt Whitlock <b...@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). ------------------------------------------------------------------------------ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
