Does FROST allow you to BYOK (make that meme for bring your own key)?
nostr:npub1j8d6h8mzvc8f2fvysrf09nlkmn7m2ylj32zl5na4tm5e8fd5dqysrg26k2 nostr:npub1mxrssnzg8y9zjr6a9g6xqwhxfa23xlvmftluakxqatsrp6ez9gjssu0htc
Discussion
nostr:npub1jss47s4fvv6usl7tn6yp5zamv2u60923ncgfea0e6thkza5p7c3q0afmzy
You can take an existing secret key and Shamir Secret Share it, then use those shares for FROST signing. We will feature this for loading an existing Nostr key into Frostsnap devices.
You could also use an existing key to seed your secret polynomial in FROST key generation. You'll still need to backup the inputs you receive during key generation such that you can recover this secret share. Perhaps this can be a single shared transcript.
https://github.com/BlockstreamResearch/bip-frost-dkg/issues/6
Or bring your own key in another sense?
Nope. This covers what I was thinking. Could I use my existing nostr key to join a FROST quorum. Sounds like I could by using the key as the polynomial secret.
You can't really take an existing secret key and "join" with that key being your secret share in FROST. Your secret polynomial is only an input to key generation and not what you sign with.
Undertaking key generation with the other parties will give you a secret share that depends on their (and your own) contributions
But would using an existing priv key as the input for key generation be advisable or doable?
Actually bringing your own key is possible, but there are limitations.
A FROST signing share is a polynomial evaluation. If, say, 3 people join together each bringing their own fixed signing shares, there exists some quadratic polynomial that interpolates their shares. However, it's impossible to find a linear (degree-one) polynomial which does the same.
In practice, this means if `n` people BYOK, they can definitely create an `n` of `n` threshold key with FROST. They can then issue new shares to add more people to the FROST group if they wanted, to make it an `n` of `m` threshold.
I'm not sure about the security implications of what a DKG would look like if only SOME keys are fixed and others can be variable. That's a different ball game 😅
How would one go about discovering the security implications of such a DKG?
You sit down, put pencil to paper and work it out!
There is likely a way to do the DKG so that some cosigners have fixed keys and others have fresh random keys. It'd probably just take some clever math and a security proof that malicious cosigners couldnt bias the DKG to do evil stuff like backdoor the group key.
Lol. Learning cryptography still! Might have to give it a try. Its just math, right?
Yep! I have some links to some more beginner-friendly ECC stuff here:
Great point they can just interpolate existing keys, but yes i believe the security is weakened - maybe ok in certain contexts. By omitting the commitment round, you allow for a misbehaving participant to bias the distribution of key generation outcomes by selectively complaining/failing (mentioned in FROST paper sec 2.3).
nostr:npub1l6uy9chxyn943cmylrmukd3uqdq8h623nt2gxfh4rruhdv64zpvsx6zvtg thanks again for these great posts , nostr:npub160t5zfxalddaccdc7xx30sentwa5lrr3rq4rtm38x99ynf8t0vwsvzyjc9 you might be interested in checking them out:
My pleasure 😄 i wonder if the DKG could be run securely (incl commitment round) if the participants sampled random evaluations instead of random coefficients when building their keygen polynomial f_i(x)...
Damn, times like now, i really wish nostr had LaTeX support 🥲 stay tuned and maybe i'll write something up for this
"Securely" does it that have any special meaning in this context? Or just the general computer terminology?
nostr:npub1zswjq57t99f444z6485xtn0vfyjjfu8vqpnyj6uckuyem2446evqnxgc6x worked on an implementation that uses fedimint nodes for DKG. (https://github.com/EthnTuttle/fedimint/tree/nostrmint-cli)
nostr:npub1j8d6h8mzvc8f2fvysrf09nlkmn7m2ylj32zl5na4tm5e8fd5dqysrg26k2
nostr:note1pr9682453najqgfrc746pgu6rtntd3ugnyy4srt5cesapnf42nuspfmkpy
nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn
This question was too tempting.
nostr:note15nsyy4d5ck4804w0tp75v5sjd3raq68rsqxc3jjztkg3kselnfpqvkqpgn
So I wrote this:
