Skip to main content

Module sign

confium_tc_frost_ed25519

Module sign 

Source
Expand description

FROST threshold signing over ed25519.

Implements the FROST signing protocol (draft-irtf-cfrg-frost §4 + the ed25519 ciphersuite) so that the produced signature (R, z) is a standard RFC-8032 ed25519 signature verifiable by any conformant verifier (e.g. ed25519-dalek, libsodium, Go crypto/ed25519).

§Protocol

Three rounds, each producing the same final signature on every party:

  • Round 1 — each party generates a nonce pair (d_i, e_i) and broadcasts its hiding / binding commitments D_i = d_i·B, E_i = e_i·B. No incoming messages.

  • Round 2 — each party receives all commitments, computes the per-party binding factor ρ_i, the group commitment R = Σ_i (D_i + ρ_i·E_i), and the challenge c = SHA-512(R ‖ A ‖ M) mod ℓ. Each party then emits its share response z_i = d_i + ρ_i·e_i + λ_i·s_i·c where λ_i is the Lagrange coefficient over the participating set and s_i is this party’s long-term secret share.

  • Round 3 — each party receives every other party’s z_i, verifies each against its commitment (proof-of-byzantine detection), and aggregates z = Σ_i z_i. The final signature is (R, z). The party verifies z·B == R + c·A before emitting it.

Because every party observes the same commitment set and computes the same R, c, and λ_i weights, the aggregated signature is identical across all parties — exactly what the threshold property demands.

§Deviations

  • Three rounds, not two. FROST is a “two-round” protocol in the sense that there are two communication rounds (commit, respond). The framework’s round model treats aggregation as a separate local round, so we expose three rounds here. Parties that only need the signature from a coordinator could fold round 3 into the coordinator’s logic; this implementation makes every party an aggregator so the test harness can assert cross-party agreement.

  • Nonce generation is not deterministic. The spec recommends deriving nonces deterministically from (secret, nonce_seed, msg) via H3; this implementation uses OsRng for simplicity. A future revision should add the deterministic path so signing sessions are reproducible and side-channel-resistant under repeated inputs.

Structs§

FrostEd25519
FROST-ed25519 threshold signing scheme.

Constants§

SCHEME_NAME
Canonical scheme name advertised through the registry.