📅 Original date posted:2014-04-04
📝 Original message:On Friday, 4 April 2014, at 10:51 am, Gregory Maxwell wrote:
> On Fri, Apr 4, 2014 at 10:16 AM, Matt Whitlock <bip at mattwhitlock.name> wrote:
> > 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.
>
> I suggest you go look at some of the other secret sharing
> implementations that use GF(2^8), they end up just being a couple of
> dozen lines of code. Pretty simple stuff, and they work efficiently
> for all sizes of data, there are implementations in a multitude of
> languages. There are a whole bunch of these.
Okay, I will.
> > 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.
>
> It lets you efficiently scale to any size data being encoded without
> extra overhead or having additional primes. It can be compactly
> implemented in Javascript (there are several implementations you can
> find if you google), it shouldn't be burdensome to implement on a
> device like a trezor (much less a real microcontroller).
Those are fair points.
> And yea, sure, it's distinct from the implementation you'd use for
> threshold signing. A threshold singing one would lack the size agility
> or the easy of implementation on limited devices. So I do think that
> if there is to be two it would be good to gain the advantages that
> can't be achieved in an threshold ECDSA compatible approach.
I agree. I'll look into secret sharing in GF(2^8), but it may take me a few days.
Matt Whitlock [ARCHIVE] /
npub17q…upwet
2023-06-07 15:17:08
in reply to nevent1q…t849
Author Public Key
npub17qxssk9sj2r7jswvh3y32e7vwz7mcckhz33gk9nurdmw0lhsfkgswupwetPublished at
2023-06-07 15:17:08Event JSON
{
"id": "651173785d83e459d78759c046e3ffc419c615df7b26b715af62641d05f50cd8",
"pubkey": "f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91",
"created_at": 1686151028,
"kind": 1,
"tags": [
[
"e",
"ec3db7ea61043d2181c683590cc6472afc1e727a155c1437be680d2ee4f9939c",
"",
"root"
],
[
"e",
"90fa75018f5da341fecbef99612ff4c3c12170506e17978c65e4cabe4073709c",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2014-04-04\n📝 Original message:On Friday, 4 April 2014, at 10:51 am, Gregory Maxwell wrote:\n\u003e On Fri, Apr 4, 2014 at 10:16 AM, Matt Whitlock \u003cbip at mattwhitlock.name\u003e wrote:\n\u003e \u003e 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.\n\u003e \n\u003e I suggest you go look at some of the other secret sharing\n\u003e implementations that use GF(2^8), they end up just being a couple of\n\u003e dozen lines of code. Pretty simple stuff, and they work efficiently\n\u003e for all sizes of data, there are implementations in a multitude of\n\u003e languages. There are a whole bunch of these.\n\nOkay, I will.\n\n\u003e \u003e 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.\n\u003e \n\u003e It lets you efficiently scale to any size data being encoded without\n\u003e extra overhead or having additional primes. It can be compactly\n\u003e implemented in Javascript (there are several implementations you can\n\u003e find if you google), it shouldn't be burdensome to implement on a\n\u003e device like a trezor (much less a real microcontroller).\n\nThose are fair points.\n\n\u003e And yea, sure, it's distinct from the implementation you'd use for\n\u003e threshold signing. A threshold singing one would lack the size agility\n\u003e or the easy of implementation on limited devices. So I do think that\n\u003e if there is to be two it would be good to gain the advantages that\n\u003e can't be achieved in an threshold ECDSA compatible approach.\n\nI agree. I'll look into secret sharing in GF(2^8), but it may take me a few days.",
"sig": "9beb89fda7feeb0720747f38050e40dcd448f9da8770969a216274318709fdedc3d4429f0ef9e771b7300a4a0f02427f6c6d85720d8aa3554352391077a392ba"
}