Refactor Proposal: Split FROST Share Generation into Two Operations

frost-refactor.md

Refactor Proposal: Split FROST Share Generation into Two Operations

Motivation

The current implementation of the secp256k1_frost_share_gen function combines the generation of Verifiable Secret Sharing (VSS) coefficient commitments and the generation of shares. This proposal aims to split these two operations into separate functions, which will provide a safer and more flexible API.

Motivations for this refactor include:

1. The session_id parameter was confusing and easy to misuse.
2. The FROST paper requires coefficient commitments and a proof-of-knowledge for the first commitment be distributed prior to shares. This change updates the APIs to conform to the paper specification, which it did not before.
3. The updated share generation function now requires the VSS, including the proof-of-knowledge, to ensure the share is not generated until those items have been received, commited to, and the proof-of-knowledge has been verified.
4. Using a dedicated authentication key for the recipient_pk instead of using the first coefficient commitment is safer; otherwise, the authentication key's private key is split and distributed in the process, which might not be desired or expected.

Proposed Changes

1. Introduce a new data structure, secp256k1_frost_vss, to store the VSS commitments and proof-of-knowledge.
2. Introduce a new function, secp256k1_frost_vss_gen, to generate a secp256k1_frost_vss struct.
3. Modify the existing secp256k1_frost_share_gen function to generate a share for a participant if their secp256k1_frost_vss struct verifies.

New Data Structure: secp256k1_frost_vss

typedef struct {
    secp256k1_pubkey *vss_commitments;
    size_t num_commitments;
    const unsigned char *sig64;
} secp256k1_frost_vss;

New Function: secp256k1_frost_vss_gen

SECP256K1_API int secp256k1_frost_vss_gen(
    const secp256k1_context *ctx,
    secp256k1_frost_vss *vss,
    const unsigned char *seed,
    size_t threshold
) SECP256K1_ARG_NONNULL(1) SECP256K1_ARG_NONNULL(2) SECP256K1_ARG_NONNULL(3);

Description

Generates the VSS coefficient commitments and a proof-of-knowledge.

Parameters

• ctx: Pointer to a context object initialized for verification.
• vss: A VSS struct.
• seed: A random seed.
• threshold: The minimum number of signers required to produce a signature.

Original Function: secp256k1_frost_share_gen (for reference)

SECP256K1_API int secp256k1_frost_share_gen(
    const secp256k1_context *ctx,
    secp256k1_pubkey *vss_commitment,
    secp256k1_frost_share *share,
    const unsigned char *session_id32,
    const secp256k1_keypair *keypair,
    const secp256k1_xonly_pubkey *recipient_pk,
    size_t threshold
) SECP256K1_ARG_NONNULL(1) SECP256K1_ARG_NONNULL(3) SECP256K1_ARG_NONNULL(4) SECP256K1_ARG_NONNULL(5) SECP256K1_ARG_NONNULL(6);

Modified Function: secp256k1_frost_share_gen

SECP256K1_API int secp256k1_frost_share_gen(
    const secp256k1_context *ctx,
    secp256k1_frost_share *share,
    const secp256k1_frost_vss *vss,
    const secp256k1_xonly_pubkey *recipient_pk,
    const unsigned char *seed,
    size_t threshold
) SECP256K1_ARG_NONNULL(1) SECP256K1_ARG_NONNULL(2) SECP256K1_ARG_NONNULL(3) SECP256K1_ARG_NONNULL(4) SECP256K1_ARG_NONNULL(5);

Description

This original function combined the generation of VSS coefficients and the generation of shares into a single operation. The proposed refactor aims to separate these two operations into different functions, resulting in a safer and more flexible API that conforms more closely to the FROST protocol as described in the paper.

This function is also updated to verify the VSS proof-of-knowledge prior to generating shares for a participant. In addition, a seed is used to generate coefficients, like in secp256k1_frost_vss_gen, which removes the need for a keypair that is overextended in the existing APIs where it serves as an authentication key, Shamir secret, and a component of the coefficient generation seed.

Parameters

• ctx: Pointer to a context object initialized for verification.
• share: Pointer to the key generation share.
• vss: The VSS struct for the recipient.
• recipient_pk: Pointer to the public key of the share recipient.
• seed: The random seed of the participiant generating the share. This must be the same one used by the participant in secp256k1_frost_vss_gen.
• threshold: The minimum number of signers required to produce a signature.

Additional Enhancement: Encrypt Shares with ChaCha20-Poly1305

To further enhance the security of the share generation and distribution process, the authentication key is used to encrypt the shares with the ChaCha20-Poly1305 encryption scheme. This symmetric encryption provides confidentiality and integrity, helping ensure that only the intended recipient can decrypt and access the share.

Thanks for bringing up space efficiency - I hadn't considered that. But I don't think that minor space efficiency improvements during the DKG are particularly important. In that case, I think it makes sense to prefer the simpler variant that stays closer to the paper.

In that case, I think it makes sense to prefer the simpler variant that stays closer to the paper.

Ok cool, that's what I was thinking as well.

About the seed variable in secp256k1_frost_vss_gen it should probably be named seed32 to say that it's 32 bytes.

I like that by reusing the seed32 variable in secp256k1_frost_vss_gen we can re-generate the private coefficients without storing them in a dynamically sized array in some struct.

Overall, I really like this refactor; it aligns the implementation with the paper itself.
I'm not sure I understand the comment at the end about the encryption, what is the DH that you plan on doing?
I do like the idea of us doing the encryption, even though we can't do the broadcast (although we could add some API for transcript verification that will show the users that they need to make sure all the transcripts are the same)

I'm not sure I understand the comment at the end about the encryption, what is the DH that you plan on doing?

It would be a DH between the participant authentication keys. For example, when Alice sends a share to Bob, Alice would derive a shared secret from her private auth key and Bob's public auth key, and use that to encrypt the share.