Someone posted this great question on Nostr the other day:
Does FROST allow you to BYOK (make that meme for bring your own key)?
…And being the nerd I am, I couldn’t resist the challenge of working out how to actually do it.
Prerequisites
This article will assume quite a bit of background knowledge.
If you’re not already familiar with elliptic curve cryptography, this article is not for you. Check out my ECC resources page for more beginnerfriendly guides.
I’ll assume you’re familiar with the polynomialdriven mathematics which underlies Shamir Secret Sharing, as FROST relies on very closely related principles.
Background
FROST is a threshold multisig protocol which allows a group of mutually distrusting parties to cosign a message in unison, producing an aggregated Schnorr signature. This signature can be validated using a single public key which is controlled collectively by the whole group, so thirdparty verifiers don’t need to care how the signatures are produced  only that they are valid Schnorr signatures.
Sounds a lot like MuSig, right? Well, in MuSig, all signers in the group must be online to sign a message (
The FROST protocol is split into two subprotocols:
 The distributed key generation (or “DKG”) protocol
 The signing protocol
The DKG protocol sets up the signing group so that each party receives a fairlycomputed and verifiable signing share. The signing protocol utilizes at least
For this article, we won’t look to hard at the signing protocol. We really only need to care about the DKG, and whether it outputs secure signing shares in different use cases.
Notation
Just so we’re all on the same page:
Notation  Meaning 

The basepoint of the secp256k1 curve.  
The SHA256 hash function.  
The order of the secp256k1 curve. There are 

Sampling 

Define the set of all 

Inclusive range notation, i.e. all numbers between 

The union of sets 
DKG Review
This section is mostly a review of Section 5.1 Figure 1 in the FROST whitepaper. Feel free to skip ahead to the new stuff if you're already familiar with FROST.
The canonical FROST DKG protocol (also known as a Pedersen DKG) starts with each of the prospective signing group members generating
denotes the index of the signer, which should never be zero. denotes coefficient indexes starting from zero.  Each
denotes the random coefficient at index chosen by signer . is the polynomial defined by these coefficients.
Each signer then computes a commitment polynomial
Each signer computes a proof that they know
is a random nonce. is a context string unique to this DKG execution, which prevents replay attacks. is the resulting proof  AKA signature  which demonstrates the signer knows .
Each signer publishes the proof
Once all proofs have been verified, and all commitment polynomials are available and consistent across the group, each signer computes evaluations using their secret keygen polynomial
For instance, signer
If there are
Each evaluation must then be verified. Every signer has the full set of commitment polynomials,
Let’s say we’re signer
If that holds, then we know the evaluation we received from signer
If it holds for every evaluation received from all
The FROST group also has a public verification polynomial
outputs the FROST public verification share for signer . outputs the FROST group’s collective public key.
The DKG succeeds if all signers correctly verified their new signing shares, and can all agree on the same verification polynomial
What’s Going On Here?
This has a surprising result.
Every FROST signer in the group ends up with a Shamir Secret Share
Here’s an analogy for you. Every signer rolls a die and puts their die in a hat. The shared secret is the sum of all those dice, mod 6. If even one player rolls their die fairly, then it’s impossible to guess what that shared secret is with any better than a
FROST keygen is kind of like Shamir Secret Sharing, except where the group’s shared secret is constructed randomly, and collectively, instead of by a trusted dealer.
How did Shamir Secret Sharing sneak in there? Well FROST signing shares are exactly the same mathematical objects as Shamir Secret Shares. Each signing share is an input/output tuple
This works because the group’s collective keygen polynomial
Summing two polynomials is just a matter of adding their terms together. Graphically, this feels like adding up the distance from the Xaxis between the graphs of both functions.
By adding up the evaluations they received
The only difference between SSS and FROST is that FROST provides an interactive signing protocol to sign messages without reconstituting
Now that we understand how FROST’s DKG works within its intended domain of usage, let’s examine how we might modify it to support BringYourOwnKey (BYOK). In pursuit of such lofty goals, we’re going to be bending FROST’s DKG in ways it wasn’t intended. With that in mind, here’s a big fat disclaimer.
Hypothetical Crypto Ahead ⚠️
Everything you’re about to read below is completely hypothetical cryptography which I completely made up myself. Nobody has peer reviewed this. Nobody has audited this. As far as I know, there is no precedent for the operations I’m doing here (If there is, please let me know!). I’m not a PhDbearing expert. Even if I were, you shouldn’t implement cryptography you read about on some guy’s blog. I’m writing this to spur discussion and to theorize, not as reference material for productiongrade crypto. Stick to battletested and peerreviewed protocols.
BYOK
To BYOK, some subset
Limitations
One corollary of the Fundamental Theorem of Algebra is that any
The group keygen polynomial
In practice, this simply means no more than
Flipping the DKG
Let
Without loss of generality, I’ll assume that signers
We need a way to guarantee that
The FROST DKG assumes each signer generates their keygen polynomial
The most obvious way to do this is to have every signer
This sounds challenging, but it’s actually relatively easy to design polynomials in this way, by using methods like Lagrange Interpolation, and none of this requires apriori knowledge of the public keys being brought to the group (meaning we should still be safe against rogue key attacks).
Interpolating
Assume we have some black box interpolation algorithm
Each FROST signer
They can compute their individual keygen polynomial
is the set of evaluations chosen by the signer which contribute to the randomness of is the set of zero evaluations which enable BYOK for some signers. is the union (that’s the operator) of and is an interpolation mechanism which spits out our signer’s desired keygen polynomial
For a signer
Other differences from the standard DKG process:
 Each signer constructs their keygen polynomial
by interpolating a set of points in total. This is to ensure (and by extension, ) will have degree , but it also has an interesting security implication. If (the threshold is the same as the number of signers who BYOK), then is an empty set. This implies that a group of signers who BYOK are entirely determining everyone’s keygen polynomials, and thus also determining the final group keygen polynomial .
This sounds pretty bad. Couldn’t those BYOK signers collude to poison the group key? Well if
 When sending evaluations, signers can skip the BYOK indexes
, because those have already been fixed ahead of time.
Other than this, the protocol runs exactly the same as the standard FROST DKG.
 Commitment polynomials are still
 The knowledgeofsecretkey signature
is still required and must be verified.  Evaluations must still be sent to those who did not BYOK.
 Individual signing shares (which are not BYOK) are still computed as
 The group verification polynomial
is still constructed by summing all commitment polynomials.  The group’s public key is still computed as
.
The math works out correctly. The big question is whether this is secure or not.
Security
The main approach I considered when trying to attack this protocol was whether a colluding subset of
Far be it from me to authoritatively declare whether this approach is secure or not. Intuitively it feels secure, because I can’t think of a way to attack it effectively with less than
But this is not a solid metric. These days, cryptographic security is best when it can be proven definitively under clear assumptions. I would love if those more experienced than myself could inspect this idea and possibly prove whether the approach is secure.
Use Cases
If FROST BYOK is secure, what can you do with it? Well there’s one thing it might be very handy for.
BYOK would allow us to build hierarchical FROST groups from the bottomup, in the same way we can currently do with MuSig key aggregation. A hierarchical FROST group is one where signing shares are themselves split among a threshold of “subsigners”. For example, this diagram illustrates a 2of3 multisig with nested subwallets, each of them a FROST wallet.
1  ┌───────────────────┐ 
If each of the signers marked with an X
agreed to sign some data, then in theory they could trustlessly sign as the toplevel wallet A
. Signer 1A can sign as subwallet 1, while signers 3A and 3B can sign as subwallet 3.
This is not anything new: Normal FROST signing shares from the DKG can be split into Shamir Secret Shares and distributed to new keyholders to form such a hierarchy. The signing protocol becomes more complicated, but it’s completely doable. However, with standard FROST, participants must always generate a completely fresh signing share when creating a new FROST group. Preexisting FROST groups cannot join together trustlessly into a higherorder FROST hierarchy without abandoning their existing group keys.
What’s novel about this approach I described above is that BYOKing allows existing FROST or MuSig group keys to be composed into hierarchical FROST groups, albeit with an upper limit on the number of allowed BYOKs (
As to how this could be used in the realworld, I’m not sure. Perhaps BYOK could enable things like higherorder Fedimints, to enable composing multiple Fedimint instances together into a SuperMint™.
Contact
Hit me up via email, or on Nostr to chime in on this subject! You’re also welcome to file a pull request or issue for this website if you notice any mistakes or would like to add something.