Building Blocks of Threshold Cryptography: Distributed Key Generation

Threshold cryptography is usually described in terms of what a group can do with a shared secret key: jointly sign a message, authorize a transaction, or decrypt data without giving any one participant unilateral control. But those outcomes come later. Before any of that works, the system has to solve an earlier problem: how is the shared secret created in the first place?

That is where distributed key generation (DKG) comes in. DKG gives a group a way to generate shared key material without trusting a single dealer to create and distribute it. It belongs to a larger family of threshold cryptography protocols that determine how shared secrets are generated, used, verified, and protected against faulty or malicious participants.

To make the ideas behind threshold cryptography easier to understand, we recently launched a new Threshold Cryptography course; you can visit Rialo Learn to check out the lesson on Distributed Key Generation. This article is a companion guide to the DKG tutorial that:

• Introduces the core ideas behind threshold cryptography
• Explains the mathematical and logical intuitions behind DKG
• Shows how Rialo applies DKG to threshold signing and trust-minimized workflows
• Explains how DKG can be made more robust in adversarial settings

A crash course in threshold cryptography

Threshold cryptography distributes control over a secret rather than entrusting it to a single entity. A secret usually grants access to some protected resource or the authority to perform a specific action. For example:

• A private key can move funds out of a wallet
• A password can grant access to protected information
• A validator key can let its holder propose or attest to blocks in a blockchain network

In ordinary systems, one entity controls that secret. Threshold cryptography changes the model: instead of assigning the secret to a single participant, control over it is distributed among multiple participants, so that no single participant holds the full secret or can exercise authority alone.

Threshold cryptography systems revolve around a threshold: the minimum number of key shares that must be combined to produce a valid cryptographic output in a particular context. Take, for example, a distributed private key represented by five key shares. If the threshold is 3-of-5, any three participants can combine their shares to produce a valid signature without any single person controlling the private key. 

One obvious way to set up such a system would be to rely on a trusted dealer to generate the secret, split it into shares, and distribute them. But that would reintroduce the very risk threshold cryptography is meant to eliminate. If the dealer is compromised, behaves maliciously, or retains a copy of the secret, then a single entity still has complete access to the underlying cryptographic authority. DKG removes that dealer and lets the group generate secret material collectively instead.

The mathematical intuitions behind DKG

Under the hood, DKG relies on a simple mathematical idea: a secret can be hidden inside a polynomial. You can think of a polynomial as a curve, where the hidden secret sits at one special point, namely at x = 0. In polynomial form, that is the constant term, written as 𝒇(0). For example, in 𝒇(x) = 42 + 7x + 3x², the number 42 is the constant term, so 𝒇(0) = 42.

More generally, a degree 𝒕 − 1 polynomial looks like this:

𝒇(x) = a_₀ + a_₁x + a_₂x^² +...+ a𝒕_₋₁x𝒕^⁻¹

The key insight is that you need exactly 𝒕 points on the curve to reconstruct it and recover the secret embedded as the constant term.

A few core ideas make DKG work:

1. Each participant chooses a private polynomial.

If there are five participants, there are five separate private polynomials: P_₁ chooses 𝒇_₁(x), P_₂ chooses 𝒇_₂(x), and so on. For example, P_₁ might choose 𝒇_₁(x) = s_₁ + a_₁x + b_₁x^², where s_₁ is P_₁’s secret value. Since the hidden secret sits at x = 0, 𝒇_₁(0) = s_₁. That is, the constant term represents the secret value hidden in the polynomial curve.

2. Shares are distributed privately.

Each participant evaluates its polynomial at every other participant’s index and sends the resulting values over a private channel. If P₁ chooses 𝒇_₁(x), it computes 𝒇_₁(2), 𝒇_₁(3), 𝒇_₁(4), and 𝒇_₁(5) and sends those values to P_₂, P_₃, P_₄, and P_₅. If there are 𝒏 participants, each participant sends 𝒏 − 1 shares and receives 𝒏 − 1 shares, for 𝒏(𝒏 − 1) messages in total.

3. The final group secret is the sum of all private contributions.

The protocol combines each private polynomial into an aggregate polynomial, 𝒇(x) = 𝒇_₁(x) + 𝒇_₂(x) + ... + 𝒇_ₙ(x). Because each participant’s secret appears as the constant term of its own private polynomial, the constant term of the aggregate polynomial is the sum of those secret values: 𝒇(0) = 𝒇_₁(0) + 𝒇_₂(0) + ... + 𝒇_ₙ(0) = s_₁ + s_₂ + ... + s_ₙ = s.

4. Key shares are computed collectively.

Participants do not directly hold the group secret key s; instead, each participant computes a final share of it. P_₁, for example, receives 𝒇_₁(1) from itself, 𝒇_₂(1) from P_₂, 𝒇_₃(1) from P_₃, 𝒇_₄(1) from P_₄, and 𝒇_₅(1) from P_₅, then adds them together:

𝒙_₁ = 𝒇_₁(1) + 𝒇_₂(1) + 𝒇_₃(1) + 𝒇_₄(1) + 𝒇_₅(1)

Because the aggregate polynomial is the sum of all private polynomials, 𝒙₁ is exactly the aggregate polynomial evaluated at x = 1. In general, each participant’s final key share is 𝒙ᵢ = 𝒇(i). The intermediate share is a share of one participant’s secret value; the final key share is a share of the group secret.

5. The secret can be recovered or used through key shares.

Participants recover the group secret from their key shares using Lagrange interpolation, which reconstructs a polynomial from sufficiently many of its points. Given 𝒕 shares, (i_₁, 𝒙_ᵢ₁), (i_₂, 𝒙_ᵢ₂), ... , (i_ₜ, 𝒙_ᵢₜ), the secret is 𝒇(0) = Σ_ₖ 𝒙_ᵢₖ · λ_ₖ, where each λ_ₖ is a Lagrange coefficient.

For a 3-of-5 example, if you use 𝒙_₁, 𝒙_₂, and 𝒙_₃, then 𝒇(0) = 𝒙_₁ · λ_₁ + 𝒙_₂ · λ_₂ + 𝒙_₃ · λ_₃, with λ_₁ = 3, λ_₂ = −3, and λ_₃ = 1, so 𝒇(0) = 3𝒙_₁ − 3𝒙_₂ + 𝒙_₃ = s.

The logic is simple: each participant keeps one final key share 𝒙ᵢ = 𝒇(i); a threshold number of key shares, 𝒕, can reconstruct 𝒇(x); and once 𝒇(x) is reconstructed, the secret is 𝒇(0) = s. Many threshold cryptography protocols do not explicitly reconstruct the secret. Instead, a threshold number of participants can combine key shares to produce cryptographic data that confirms access to the secret without revealing it.

6. Threshold key operations verify against one public key.

Once the hidden group secret s has been defined, the protocol derives a corresponding group public key, Y = gˢ, where 𝑔 is a fixed public base element.

In a threshold signature scheme, participants sign data with key shares to derive partial signatures, which they combine into a final threshold signature that verifies against Y = gˢ. To illustrate, consider a Schnorr-style signature on a message m with the form (R, z), where R = gᵏ, c = H(R, Y, m), and z = k + c · s.

No single participant knows s; instead, each participant i holds a key share 𝒙ᵢ and uses it to produce a partial signature zᵢ = kᵢ + c · 𝒙ᵢ. These partial signatures are then combined using Lagrange weights: z = Σₖ zᵢ · λₖ.

The verifier checks the signature by verifying that gᶻ = R · Yᶜ, confirming that z is consistent with the commitment R, the public key Y, and the challenge c. Expanding gives z = (Σₖ kᵢ · λₖ) + c · (Σₖ 𝒙ᵢ · λₖ) = k + c · s, so the final signature has the same form as a normal signature and satisfies gᶻ = R · Yᶜ.

The resulting signature verifies against the group public key Y, even though it was generated from distributed key shares rather than a single private key. From the verifier’s perspective, the signed data is indistinguishable from data signed by a conventional private key.

The mathematics above give DKG its useful properties in practice:

• Secret values remain hidden below the threshold, including the secret values chosen by participants and the final group secret
• The secret generation process is trust-minimized because no dealer creates or distributes the secret
• Threshold-based cryptographic outputs can be verified independently against the derived public key

The DKG tutorial on Rialo Learn makes these details visible. As you step through the simulation, the protocol executes in four steps: (i) choose the number of participants and threshold, (ii) generate private polynomials, (iii) distribute intermediate shares, and (iv) compute final key shares and derive the public key. There is no trusted dealer at any point in the process.

How Rialo uses DKG in practice

Rialo applies the same idea of distributed control of a shared key to trust-minimized protocol workflows. One example is cross-chain financial workflows that are automatically triggered by user-defined conditions and secured by validator quorums. This use case combines two things: conditional transactions, which execute automatically when user-defined conditions are satisfied; and threshold signing, in which validators each hold a key share of a threshold private key, and a subset can come together to produce a valid threshold signature.

Suppose a stablecoin protocol uses Rialo as a hub to coordinate workflows across multiple blockchains. It has a master account on Rialo that controls other accounts deployed on destination chains, including accounts responsible for minting and burning. Rialo’s role is to let the protocol control those remote deployments through the onchain master account in a deterministic and secure flow.

Now consider a basic workflow that the stablecoin protocol may want to synchronize across chains: minting. The protocol admin first defines a conditional transaction that mints X units of stablecoins across different chains once a specific condition (e.g., a particular block height) is met. To improve security, the admin may specify that each cross-chain mint should execute only if the associated payload is signed by a quorum of validators. 

Here is how that workflow might execute:

• Submission and validation: Validators verify the transaction upon submission and confirm the sender's authority before storing it onchain. Once the condition is satisfied, the transaction is queued for execution.
• Payload generation and threshold signing: Transaction payloads for the destination chains are derived from the original transaction. Validators sign each payload with their key shares to produce partial signatures, which are then combined into a threshold signature.
• Delivery and execution: Each payload is delivered to the destination chain by a relayer or keeper. The attached threshold signature looks like a normal private-key signature, so the payload is indistinguishable from one signed by a conventional single private key. If the signature passes verification, the destination-chain account executes the requested action, such as minting the specified amount of stablecoins.

The process is both seamless and secure: the cross-chain mint is scheduled in advance, executes automatically once the condition is satisfied, and requires a quorum of validators to approve final execution. None of those validators can authorize the transaction on their own, and the secret itself is generated in a decentralized manner, without a trusted dealer.

Cross-chain operations are just one use case. The same setup can support many other trust-minimized workflows, including scheduled multi-step execution, quorum-gated authorizations, shared validator control over sensitive operations, and coordinated signing for asynchronous or cross-domain actions.

Making DKG more robust

Our discussion of DKG has implicitly assumed that participants are honest. Honest participants correctly construct their private polynomials, send valid intermediate shares to others, and follow the intended protocol during reconstruction and threshold signing.

Real-world systems cannot assume that every participant will behave correctly. A malicious participant might send garbage shares, send inconsistent shares to different recipients, or try to corrupt reconstruction later without being caught immediately. Vanilla secret sharing based on DKG principles assumes honest behavior and cannot detect or mitigate adversarial actions.

This is where VSS (Verifiable Secret Sharing) comes in. VSS adds verification to the sharing process: participants do not just send shares privately; they also publish commitments to the coefficients of the polynomial they used to create those shares. Other participants can then check whether the share they received is actually consistent with what was publicly committed.

The next lesson in the Threshold Cryptography course will cover VSS and explain how it combines with DKG to enable functional, secure threshold cryptography systems. For now, head over to the tutorial page to try out the DKG simulation and apply the ideas you have learned from this article.