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:
- The
session_id
parameter was confusing and easy to misuse. - 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.
- 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.
- 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.
- Introduce a new data structure,
secp256k1_frost_vss
, to store the VSS commitments and proof-of-knowledge. - Introduce a new function,
secp256k1_frost_vss_gen
, to generate asecp256k1_frost_vss
struct. - Modify the existing
secp256k1_frost_share_gen
function to generate a share for a participant if theirsecp256k1_frost_vss
struct verifies.
typedef struct {
secp256k1_pubkey *vss_commitments;
size_t num_commitments;
const unsigned char *sig64;
} secp256k1_frost_vss;
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);
Generates the VSS coefficient commitments and a proof-of-knowledge.
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.
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);
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);
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.
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 insecp256k1_frost_vss_gen
.threshold
: The minimum number of signers required to produce a signature.
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.
The proposal makes sense to me overall. In particular, I think it's much better to do POK proving and verification inside of the API instead of asking the user to come up with something. Not sure if this feature implies that we need to split the function as you suggest (since PoK verification could also happen in secp256k1_frost_share_verify). Also, the current API is somewhat clunky because you only want to provide
vss_commitment
toshare_gen
once (as e.g. demonstrated in the example).In what way is it better now? How does a user create the
seed
, or is it justsession_id
renamed?In what way is it more flexible? It seems to imply an additional communication roundtrip.
Another consideration with the new API is what happens if you give different arguments to
vss_gen
andshare_gen
. But as far as I can see that's not a problem for security.I don't see how
vss
struct is supposed to work. How doesvss_gen
know where to place the data in thevss_commitments
andsig64
arrays. And similarly, how doesshare_gen
know which entry invss
it should verify against? This would also imply an order on the signers which iirc we tried to avoid.