There might be a secure scheme that non-interactively generates a n-of-n FROST key and from there you can interactively turn it into a t-of-n by issuing new shares (i.e. enrolment).
I don't really know if this is a useful contribution even if it works. There might be some utility in not having multiple schemes but rather a one size fits all approach.
MuSig takes a "multiset" of n public keys and outputs a single aggregated key which takes n-of-n secret keys to sign.
Set z_i = H(X_1,.. X_i, .. X_n, X_i) for i = 1,2, .. n.
The form of the final key is the sum of z_i * X_i for all i = 1,2, .. n.
Interestingly we can take a n public keys and generate structurally valid a n-of-n FROST key in
a similar way. Set X as the Lagrange interpolation for the first term of a polynomial with points
(z_1, X_1), (z_2, X_2), .. (z_n, X_n). This leaves us with a formula for X as the sum of L_i(0) * X_i for i = 1,2, .. n and L_i is the ithe Lagrange basis polynomial for the above points.
L_i(0) is a function of z_i (and the other z values) so it should do a good
of delinearizing as z_i by itself.
This of course creates an n-of-n FROST key which is not all that useful.
But we know how to turn an n-of-n key into an t-of-n (where t is equal to the old n) i.e. turn a 2-of-2 into a 2-of-3 etc.
I lost the best citation for this but here's one [1]. A simple way to think about it is that you field MPC to generate the share for the new participant.
I was wondering whether this unification could make a FROST miniscript easier to describe.
You could have a fragment like frusig(X1,X2,X3) which would define a 3-of-n (not n is not encoded in the fragment). Via enrollment you could issue more keys and there'd be no need to change the descriptor. If I have a some aux_id and key X* I can check whether I can sign for this fragment:
- Check if
X*is equal toX1,X2, orX3. - If not check whether it's on the polynomial defined by the lagrange interpolation of
X1,X2, andX3at the right spot i.e. with x coordH(X1, X2, X3, aux_id)
Unforunetly it looks hard to do this without this aux_id to uniquely define your share. I guess it would be up to the application to define this or it could just be some counter which is incremented for each auxilliary signer you add to the key.
This does not imply the above scheme is secure. It just appears to be structurally valid (i.e. correct). You would need to prove:
- the
n-of-nnon-interactively generated FROST key is a secure FROST key (i.e. the non-interactive protocol cannot be distinguished from the interactive keygen protocol in terms of the adversarial view in the random oracle model). - Enrolment schemes are secure in combination with FROST.
There's quite a bit of work to do there and I think that proving (1) might be hard without some extra tricks or maybe choosing a different benchmark for security.