[Frost] Key Conversion & Key Derivation Function

[kuksag]

In context of (Shamir) Secret Sharing we have a polynomial f(x) = a_0 * x^0 + a_1 * x^1 + ... + a_n * x^n,
where f(0) = a_0 is a group secret.

Each of participants has its own x_i-coordinate, f(x_i) – i-th participant's secret.

G_s – group generator of secp256k1, G_e – group generator of Ed25519. * – group operation

Key Conversion

Formally, in an ideal world we would want to have something like From trait for cait_sith::KeygenOutput -> frost::keys::{SecretShare, PublicKeyPackage}.

Let's look closely on what we have in cait_sith (link):

pub struct KeygenOutput<C: CSCurve> {
    pub private_share: C::Scalar,
    pub public_key: C::AffinePoint,
}

Where private_share is f(x_i) and public_key – G * f(0)

On Frost we have the following object that is a part of key management
(link)

pub struct SecretShare<C: Ciphersuite> {
    ...
    /// The participant identifier of this [`SecretShare`].
    identifier: Identifier<C>,
    /// Secret Key.
    signing_share: SigningShare<C>,
    /// The commitments to be distributed among signers.
    commitment: VerifiableSecretSharingCommitment<C>,
}

Where identifier is x_i, signing_share is f(x_i), and commitment is [G_e * a_0, G_e * a_1, ..., G_e * a_n] as can be seen here.

Immediate problem is that we don't have such values for commitment.

One of the distributed approaches would be to have G_e * f(x_i) as a part of public information (config/chain).
Then we would have n points of polynom G_e * f(x), we can interpolate it to get the coefficients, which is [G_e * a_0, G_e * a_1, ..., G_e * a_n], which is exactly what we need.

This requires adding two things:

1. Access G_e * f(x_i) information runtime
2. Do interpolation. Probably it can be found in dalek-cryptography or other primitives, research needed

Key Derivation Function

To hold invariants VSSC[0] += G * tweak do the trick

[chelseakomlo]

I think VerifiableSecretSharingCommitment would just be used during the DKG. For signing, it can't be used. Can this value just be set to empty?

[kuksag]

Ok, agree. We actually can not make it zero, since internal checks will fail, but we can supply "fake" commitments to each of participants, such that the property still holds. Thus we break invariant that commitment is the same amongst all participants, but we are fine with that, since we trust in previously occurred DKG.

But still, we need to calculate a group public key. I don't see an easier way rather than interpolate on G * f(x_i) values, find F(x) and take F(0). Is it so?

[kuksag]

I don't see an easier way rather than interpolate on G * f(x_i) values, find F(x) and take F(0)

It works only in the case when threshold=number_of_signers.

Moreover, is it actually possible to reuse DKG result? The reason for doubt is following.
Suppose we have n participants, with threshold t. When DKG for ECDSA has occurred, we have built n values f_i(x_i) – secret shares for each participant, such that deg(f) = t - 1 ... in the field secp256k1. Now we want to somehow map those elements into ed25519 field, but we can not guarantee that the mapped values are still going to be lying on some polynomial g(x) with deg(g) = t - 1.

@chelseakomlo Am I missing something?

[chelseakomlo]

What do you mean that internal checks will fail?

But yes, if our ECDSA library is defined over secp256k1, we can't convert to ed25519. We'll need to either use FROST over secp256k1 or generate new ed25519 keys.