COCKTAIL Distributed Key Generation

• Version: v0.2.1
• Authors:
  • Daniel Bourdrez
  • Soatok Dreamseeker
  • Tjaden Hess, Trail of Bits
  • COCKTAIL is an independent derivative of ChillDKG, which was made by:
    • Tim Ruffing, Blockstream Research
    • Jonas Nick, Blockstream Research

Introduction §

Threshold signature schemes (i.e., FROST (RFC 9591)) allow a secret key be shared among $n$ parties such that any $t$ of the $n$ parties can cooperate to generate a digital signature for the group public key.

Initializing a $t$ of $n$ threshold requires a key generation protocol. This can be a Distributed Key Generation (DKG) protocol or a Trusted Dealer approach. RFC 9591 specifies a Trusted Dealer approach and leaves DKG specification out of scope.

However, the original FROST paper did specify a DKG protocol based on Verifiable Secret Sharing, Pedersen commitments, and Proofs of Possession. This protocol is secure only if communications are performed over a secure channel, with the following requirements:

• Messages are authenticated and encrypted in transit, to prevent man-in-the-middle attacks
• All participants have some consensus mechanism (e.g., a transparency log) so everyone has a consistent view of the protocol messages

To satisfy these requirements in a standalone protocol, Nick and Ruffing proposed ChillDKG as a Bitcoin Improvement Proposal. Because of its tight coupling to the Bitcoin project, ChillDKG was only specified and implemented over the secp256k1 elliptic curve group.

COCKTAIL is a recursive acronym that stands for: "COCKTAIL Orchestrates Cryptographic Key Threshold Agreement for Interoperable Libraries."

COCKTAIL is an independent derivative of ChillDKG intended to be used with any FROST ciphersuite.

Abstract §

COCKTAIL-DKG is a standalone, three-round distributed key generation protocol for threshold signature schemes like FROST.

COCKTAIL-DKG allows a group of $n$ participants to securely generate a shared group public key and individual secret shares for a $t$ of $n$ threshold, without a trusted dealer. The protocol is built on Feldman's Verifiable Secret Sharing (VSS), uses pairwise ECDH to encrypt shares for transport over insecure channels, and includes a final certification round to ensure all participants agree on the outcome. It is designed to be ciphersuite-agile, with specific recommendations for curves like secp256k1, Ed25519 (via Ristretto255), and Ed448.

Design Overview §

COCKTAIL-DKG, like ChillDKG before it, starts off with a simplified variant of a Pedersen Commitment with Proof of Possession protocol, referred to as "SimplPedPop". If SimplPedPop were a standalone protocol, it would depend on an external equality check protocol to ensure all participants received the same messages.

An encryption layer, called "EncPedPop", wraps SimplPedPop with pairwise ECDH to encrypt secret shares.

Finally, an equality check protocol called "CertEq" is built atop EncPedPop to create a standalone protocol.

A coordinator is assumed to facilitate message passing between participants. The coordinator is an untrusted facilitator: it is responsible for receiving messages from all participants, aggregating them where necessary, and broadcasting them to all participants, but it is not trusted with the confidentiality, integrity, or consistency of any protocol message. A malicious coordinator can disrupt availability (a liveness concern: refusing to broadcast, dropping participants, or stalling the protocol; none of which can be prevented by cryptographic mechanisms), but it cannot break confidentiality (it never sees any participant's secret share or the final group secret key) or consistency (any split-view attack, in which different participants receive different messages, causes the CertEq phase to fail safely with all-or-nothing semantics). The coordinator does not need any private key material. The role of the coordinator can be fulfilled by a simple broadcast channel, a peer-to-peer network among the participants themselves, or a dedicated server application; the choice does not change the protocol's security properties.

Supporting Definitions §

This section provides detailed definitions for the notation, message formats, and cryptographic primitives used throughout the COCKTAIL-DKG protocol.

Notation §

• $X \parallel Y$: The concatenation of X followed by Y.
• $n$: The total number of participants in the DKG ceremony.
• $t$: The threshold, i.e., the minimum number of participants required to generate a signature.
• $i, j$: Indices representing participants, where $1 <= i, j <= n$.
• $B$: The generator point of the elliptic curve group.
• $q$: The order of the elliptic curve group.
• $f_i(x)$: The secret polynomial of degree $t-1$ generated by participant $i$.
• $a_{i,k}$: The $k$-th coefficient of $f_i(x)$, which is a scalar. $a_{i,0}$ is the primary secret of participant $i$.
• $C_{i,k}$: The public commitment to the coefficient $a_{i,k}$, where $C_{i,k} = a_{i,k} * B$.
• $C_i$: The VSS commitment for participant $i$, which is the vector of all $C_{i,k}$.
• $s_{i,j}$: The secret share of participant $i$'s polynomial evaluated at $j$, i.e., $s_{i,j} = f_i(j)$.
• $d_i$: The long-term static private key for participant $i$, a scalar.
• $P_i$: The long-term static public key for participant $i$, where $P_i = d_i * B$.
• $e_i$: The ephemeral private key for participant $i$ for a single DKG session, a scalar.
• $E_i$: The ephemeral public key for participant $i$, where $E_i = e_i * B$.
• $PoP_i$: A Proof of Possession signature from participant $i$.
• $x_i$: The final, long-lived secret share for participant $i$, where $x_i = \sum_{j=1}^{n} s_{j,i}$.
• $Y_i$: The public verification share for participant $i$.
• $Y$: The final group public key, where $Y = \sum_{j=1}^{n} C_{j,0}$.
• $payload_{i,j}$: An optional application-defined payload from participant $i$ to participant $j$, which may be empty.
• $S^{\mathrm{e}}\_{i,j}$: The ephemeral-to-static ECDH shared secret, where $S^{\mathrm{e}}\_{i,j} = e_i * P_j$. When $S^{\mathrm{e}}\_{i,j}$ appears as bytes (e.g., inside $x = S^{\mathrm{e}} \parallel S^{\mathrm{d}}$ as an input to $H6$), it is the canonical ciphersuite-specific byte encoding of the elliptic-curve point $e_i \cdot P_j$ as defined in ECDH Shared-Secret Encoding.
• $S^{\mathrm{d}}\_{i,j}$: The static-to-static ECDH shared secret, where $S^{\mathrm{d}}\_{i,j} = d_i * P_j$. Encoded as bytes per ECDH Shared-Secret Encoding.

Operations §

• $Add(P_1, P_2)$: Elliptic curve point addition.
• $RandomScalar()$: Generates a uniform cryptographically secure random scalar in the range $[0, q-1]$.
• $H6()$: A ciphersuite-specific key derivation function.
• $H7()$ and $HashToScalar()$: Ciphersuite-specific tagged hash and hash-to-scalar functions, defined in Schnorr Signature Scheme.
• $Enc()$ / $Dec()$: Ciphersuite-specific AEAD encryption/decryption functions.
• $Sign()$ / $Verify()$: The Schnorr signature scheme defined in Schnorr Signature Scheme, used for both the Proof of Possession and CertEq transcript certification.
• $\mathrm{ecdh\\_encode}(P)$: A ciphersuite-specific canonical byte encoding of an elliptic-curve point $P$, used to serialize ECDH shared-secret outputs before they are fed into $H6$. The encoding is fixed-length per ciphersuite and is defined in ECDH Shared-Secret Encoding. Any reference to the bytes of an ECDH product (e.g., $S^{\mathrm{e}}\_{i,j} = e_i \cdot P_j$ used as an input to $H6$) means $\mathrm{ecdh\\_encode}$ applied to that product.
• $\mathrm{uint64\\_be}(v)$ and $\mathrm{uint64\\_be\\_decode}(b)$: The 8-byte big-endian encoding and decoding of a 64-bit unsigned integer, used for the variable-length-ciphertext length prefixes in $msg\_{1|i}$, $msg\_{2|i}$, and $C^{rec}\_i$.

Message Formats §

All messages exchanged between participants are encoded as byte arrays. The specific encoding of protocol elements is defined below. Implementations MUST adhere to these formats to ensure interoperability.

Primitive Types §

Let $G$ be an elliptic curve group with a standardized name (e.g., "P-256", "Ed25519", "secp256k1").

• Scalar: A scalar is an integer in the range $[0, q-1]$, where $q$ is the order of the group $G$. A scalar is encoded as a fixed-size byte array using the encoding defined by the corresponding FROST ciphersuite in RFC 9591 (or, for ZIP-0312 ciphersuites, the encoding defined in ZIP-0312). The endianness is therefore ciphersuite-specific:

  • Ed25519, Ristretto255, Ed448, JubJub, Pallas: little-endian.
  • P-256, secp256k1: big-endian.

  Scalar sizes are: 32 bytes for P-256, secp256k1, Ed25519/Ristretto255, JubJub, and Pallas; and 57 bytes for Ed448, matching RFC 9591. Implementations MUST reject any decoded scalar value $s$ where $s \geq q$. When a scalar value is the result of arithmetic operations (e.g., polynomial evaluation $f_i(j)$, share summation $x_i = \sum_j s_{j,i}$, or index powers $i^k$), implementations MUST reduce the result modulo $q$ before encoding it to bytes; implementations using arbitrary-precision integer types are particularly susceptible to silently encoding an unreduced value that is larger than $q$.

• Elliptic Curve Point: An elliptic curve point is encoded in its compressed form, as a fixed-size byte array, using the corresponding FROST ciphersuite encoding from RFC 9591 / ZIP-0312. Sizes are: 33 bytes for P-256 and secp256k1; 32 bytes for Ed25519/Ristretto255, JubJub, and Pallas; and 57 bytes for Ed448, matching RFC 9591. Implementations MUST validate that decoded points are valid curve points and (for ciphersuites with non-trivial cofactor) lie in the prime-order subgroup.

• The Point at Infinity: The point at infinity, which is the identity element of the group, is represented by a byte array of the same length as a standard point encoding, but filled with all zero bytes. The point at infinity MUST be rejected when parsing VSS commitment points $C_{i,k}$, ephemeral public keys $E_i$, and static public keys $P_i$. Accepting identity elements in these positions would compromise protocol security.

Protocol Messages §

The following messages are exchanged during the COCKTAIL-DKG protocol. They are constructed by concatenating the byte representations of their constituent parts in the specified order.

1. $msg_{1|i}$ (Participant -> Coordinator, Round 1)

This message contains the participant's VSS commitment, their Proof-of-Possession, their ephemeral public key, and one encrypted share per participant; including a self-share $c_{i,i}$ addressed to participant $i$ themselves. The self-share is encrypted under the same procedure as the others; including it keeps the message structure uniform, makes the recovery procedure symmetric across the $n$ participants, and ensures every entry of the recipient-indexed bundle $C^{rec}_i$ is non-empty.

• $C_i$: The VSS commitment, which is a list of exactly $t$ elliptic curve points. Implementations MUST verify that the commitment contains exactly $t$ points; any other length indicates a malformed message or an attempted threshold elevation attack.

  • Format: $C_{i,0} \parallel C_{i,1} \parallel \cdots \parallel C_{i,t-1}$

• $PoP_i$: The Proof of Possession, which is a signature. The size depends on the signature scheme used by the ciphersuite.

• $E_i$: The ephemeral public key, an elliptic curve point.

  • It does not refer to isogenies. Here, E stands for "ephemeral".

• $c_{i,j}$: An encrypted ciphertext containing the secret share $s_{i,j}$ and an optional application-defined payload $payload_{i,j}$. The plaintext format is $s_{i,j} \parallel payload_{i,j}$, where $payload_{i,j}$ may be empty. The ciphertext size depends on the AEAD scheme and the payload size. The minimum ciphertext size is the scalar encoding size plus the AEAD authentication tag size (e.g., 32 + 16 = 48 bytes for most ciphersuites).

  Implementations MUST configure an upper bound MAX_CIPHERTEXT_SIZE on each individual ciphertext and MUST reject any framed ciphertext whose length prefix exceeds it; this is the resource-exhaustion mitigation referenced in $msg_{1|i}$, $msg_{2|i}$, and $C^{rec}_i$ parsing. The lower bound on MAX_CIPHERTEXT_SIZE itself is also normative:

  • Conformance floor (MUST): MAX_CIPHERTEXT_SIZE MUST be at least scalar_size + AEAD_TAG_SIZE (the exact size of a zero-payload encrypted share). An implementation whose configured MAX_CIPHERTEXT_SIZE setting causes it to reject ciphertexts of exactly this minimum size (and therefore reject zero-payload shares) is non-conformant. (Ciphertexts strictly smaller than this minimum are still MUST-rejected by the protocol-level checks at $msg_{1|i}$ parsing, $msg_{2|i}$ parsing, and recovery, because they cannot decrypt to a valid share at all; this conformance floor concerns the upper-bound cap, not the lower-bound size check.)
  • Interoperability floor (SHOULD): MAX_CIPHERTEXT_SIZE SHOULD be at least 65,536 bytes (64 KiB). This bound covers realistic application-payload sizes for the use cases COCKTAIL-DKG targets and is the recommended setting for general-purpose implementations.

  Above the SHOULD floor, the choice of MAX_CIPHERTEXT_SIZE is implementation- and deployment-defined.

  Each ciphertext is wire-framed as a fixed-width length prefix followed by the AEAD ciphertext bytes: $\widetilde{c_{i,j}} = len(c_{i,j}) \parallel c_{i,j}$, where $len(c_{i,j})$ is the byte length of $c_{i,j}$ encoded as a 64-bit big-endian unsigned integer. The framed form $\widetilde{c_{i,j}}$ is what appears in $msg_{1|i}$, $msg_{2|i}$, and the recovery bundle $C^{rec}_i$. Implementations MUST reject any framed ciphertext whose length prefix exceeds the implementation's MAX_CIPHERTEXT_SIZE.

The full message is the concatenation of these elements:

where each $\widetilde{c_{i,j}}$ is the length-prefixed ciphertext defined above. $C_i$, $PoP_i$, and $E_i$ are fixed-length per the ciphersuite and are concatenated without additional framing.

2. $msg2$ (Coordinator -> All Participants, Round 2)

This message aggregates the public information from all participants and the ciphertexts addressed to the recipient. It is equivalent to an ordered, recipient-specific projection of all Round 1 messages.

• $C_j$: The full VSS commitment from participant $j$, which is a list of exactly $t$ elliptic curve points.
• $PoP_j$: The Proof of Possession from participant $j$.
• $E_j$: The ephemeral public key from participant $j$.
• $c_{j,i}$: The ciphertext from participant $j$ intended for participant $i$.

The message broadcast to participant $i$ is structured as:

where $\widetilde{c_{j,i}}$ is the length-prefixed framed ciphertext defined under $msg_{1|i}$ above. Concrete encodings MUST preserve the participant ordering; $C_j$, $PoP_j$, and $E_j$ are fixed-length per the ciphersuite, and each $\widetilde{c_{j,i}}$ carries its own 64-bit big-endian length prefix, so the full message parses unambiguously.

Implementations MAY instead broadcast the complete ordered list of all $msg_{1|j}$ messages to every participant.

3. $sig_i$ (Participant -> Coordinator, CertEq Phase)

This message contains the participant's signature over the protocol transcript.

• $sig_i$: The signature, created using the participant's static private key $d_i$. The size depends on the signature scheme.

4. Aggregated Signatures (Coordinator -> All Participants, CertEq Phase)

This is the final message, containing all signatures on the transcript.

• $sig_j$: The signature from participant $j$.

The message is structured as:

Cryptographic Primitives §

As COCKTAIL-DKG is intended to be used in conjunction with RFC 9591, we begin our enumeration of named hash functions with "H6".

Protocol Definition §

This section describes the COCKTAIL-DKG protocol in detail.

Setup §

Each participant $i$ is assumed to have:

• A unique identifier $i$ from $1$ to $n$. Identifiers MUST be the contiguous integers $1, 2, \ldots, n$ assigned to participants in a canonical, agreed-upon ordering, and all participants MUST agree on this ordering before the DKG begins; disagreement MUST be treated as a setup failure. The ordering is the same ordering used to list $P_1, \ldots, P_n$ throughout the protocol and the transcript. Identifiers MUST NOT be $0$ or congruent to $0$ modulo the group order $q$, as this would allow a zero share attack.

• The parameters $n$ (total participants) and $t$ (threshold). Both MUST satisfy $1 \le t \le n$ and $n \le 2^{32} - 1$ (the maximum representable in the transcript's uint32_le encoding of $n$ and $t$). $t = 1$ corresponds to a $1$ of $n$ deployment where any single participant can sign on behalf of the group; this is a permitted-but-application-discouraged degenerate case (a single compromised participant can sign unilaterally, which defeats the threshold property). $t > n$, $t = 0$, $n = 0$, and any encoding that exceeds the 32-bit bound are invalid setups and participants MUST abort before Round 1.

• A long-term static key pair $(d_i, P_i)$.

• The ordered list of static public keys of all participants, ${P_1, P_2, \ldots, P_n}$ (including $P_i$ at index $i$). All $P_j$ MUST be distinct, valid prime-order subgroup points; participants MUST abort if any duplicate or otherwise invalid public key is observed during setup.

• A ciphersuite defining the elliptic curve group, hash function, and AEAD scheme.

• A context string. The context is a normative input to several security properties of the protocol, including the freshness of ECDH-derived encryption keys, the prevention of cross-session replay, and the cross-protocol distinctness of PoP and CertEq signatures, so it MUST satisfy three requirements:

  1. Session uniqueness. The context MUST be unique to the DKG session, so that no two distinct DKG sessions ever share the same context value. Implementations typically achieve this by including a high-entropy random byte string, a timestamp, or a session ID in the context construction.
  2. Participant binding. The context MUST cryptographically bind the ordered participant identity set $(P_1, P_2, \ldots, P_n)$, so that an attempt to alter $n$, the participant ordering, or any $P_j$ yields a different context value. This binding is what enables the PoP and CertEq signatures to be domain-separated from any other use of the participants' keys and prevents a malicious coordinator from reusing protocol messages across mismatched participant sets.
  3. Ciphersuite binding. The context MUST cryptographically bind the canonical ciphersuite_id byte string from the Ciphersuite Definitions normative table, so that ciphersuite confusion (the same byte material being reinterpreted under a different ciphersuite) is prevented. Implementations MUST use the exact ciphersuite_id byte string from that table (no whitespace normalization, no case folding, no alternate punctuation) wherever ciphersuite_id appears in the context construction.

  The RECOMMENDED construction that satisfies all three requirements is

  context = H( "COCKTAIL-DKG-CONTEXT"
             || uint64_be(len(session_id))   || session_id
             || uint64_be(len(ciphersuite_id)) || ciphersuite_id
             || uint32_le(n)
             || P_1 || P_2 || ... || P_n )
  

  where $H$ is the ciphersuite's hash function, session_id is the session-unique byte string, the variable-length session_id and ciphersuite_id fields are each prefixed with their 64-bit big-endian byte length (the same wire-framing convention used for ciphertexts elsewhere in this spec), $n$ is included so the participant-list length is unambiguous, and each $P_j$ is encoded in the ciphersuite's compressed point encoding (fixed-length per ciphersuite). Any equivalent construction is permitted provided it satisfies all three MUSTs above; that is, it produces a distinct context per session, it unambiguously binds the ordered participant set with no tuple-boundary ambiguity between any two of its components, and it cryptographically binds the canonical ciphersuite_id byte string verbatim from the Ciphersuite Definitions table. Constructions that omit ciphersuite_id entirely from the hash preimage, normalize its bytes before hashing (e.g., lowercasing, whitespace collapsing, alternate punctuation), or substitute any other representation are non-conformant. Hashing the recommended preimage above, which contains the verbatim ciphersuite_id bytes as one of its length-framed inputs, is the recommended way to satisfy this MUST and is not an "omit/normalize" case. All participants MUST validate that they agree on the exact context byte string before proceeding; disagreement is a setup failure.

Round 1: Commitment and Encryption §

1. Generate Polynomial: Participant $i$ generates a secret polynomial $f_i(x)$ of degree $t-1$: $f_i(x) = a_{i,0} + a_{i,1}x + \cdots + a_{i,t-1}x^{t-1}$.

   The coefficients $a_{i,k}$ are chosen as random scalars via $RandomScalar()$. $a_{i,0}$ is the participant's primary secret share. If any sampled coefficient equals $0$ (probability $\approx 2^{-\lceil \log_2 q \rceil}$ per coefficient, negligible in practice), implementations MUST resample that coefficient before continuing, so that every $C_{i,k} = a_{i,k} \cdot B$ is a non-identity point and the parsing rule at Primitive Types rejecting identity VSS commitment points does not cause an honest abort.

2. Compute VSS Commitment: Participant $i$ computes a VSS commitment $C_i$ to their polynomial by creating a public commitment for each coefficient: $C_i = (C_{i,0}, C_{i,1}, \cdots, C_{i,t-1})$, where $C_{i,k} = a_{i,k} * B$.

3. Generate Ephemeral Key: Participant $i$ generates a fresh ephemeral key pair $(e_i, E_i)$ for this session with $e_i \leftarrow RandomScalar()$ and $E_i = e_i \cdot B$. If $e_i = 0$ (negligible probability), implementations MUST resample, so that $E_i$ is a non-identity point and the parsing rule at Primitive Types rejecting identity ephemeral public keys does not cause an honest abort.

4. Compute Proof of Possession (PoP): Participant $i$ computes a digital signature $PoP_i$ over a concatenation of the context string, their VSS commitment $C_i$, and their ephemeral public key $E_i$. The signature is created using the secret $a_{i,0}$ as the private key and $C_{i,0}$ as the public key. The message to be signed is context || C_i || E_i, where $C_i$ is encoded as the byte concatenation $C_{i,0} \parallel C_{i,1} \parallel \cdots \parallel C_{i,t-1}$ (each point in the ciphersuite's compressed encoding, identical to its encoding in $msg_{1|i}$). The signature algorithm is the Schnorr scheme defined in Schnorr Signature Scheme. If Sign aborts at its step 3 due to $k = 0$ (probability $\approx 2^{-\lceil \log_2 q \rceil}$, negligible), participant $i$ MUST treat this DKG session as locally failed: it MUST NOT send $msg_{1|i}$, MUST NOT publish any partially-derived value, and MUST abandon this session. To retry, participant $i$ joins a fresh DKG session with a different context string (which changes the Sign message $m$ and therefore the deterministic nonce $k$); simply resampling $a_{i,0}$ within the same context would require restarting Round 1 from step 1 and is indistinguishable from the participant dropping out, so a fresh-context retry is the recommended path. This is not a blameable misbehavior. The other participants observe only that participant $i$ failed to deliver $msg_{1|i}$ within the agreed timeout.

5. Compute and Encrypt Shares: For each participant $j$ from $1$ to $n$ (including $j = i$, the self-share):

   1. Compute Share: Participant $i$ computes the secret share $s_{i,j} = f_i(j)$.
   2. Derive Key: Participant $i$ computes two ECDH shared secrets: one with their ephemeral key and the recipient's static public key, and one with their static key and the recipient's static public key: $S^{\mathrm{e}}\_{i,j} = e_i * P_j$ and $S^{\mathrm{d}}\_{i,j} = d_i * P_j$. It then derives a symmetric key and nonce for the AEAD.
      • If the hash function has an output length of at least 56 bytes (448 bits):
        • $tmp = H6(S^{\mathrm{e}}\_{i,j} \parallel S^{\mathrm{d}}\_{i,j}, E_i, P_i, P_j, context)$.
        • $k_{i,j} = tmp[0:32]$
        • $iv_{i,j} = tmp[32:56]$
      • Otherwise:
        • $k_{i,j} = H6(S^{\mathrm{e}}\_{i,j} \parallel S^{\mathrm{d}}\_{i,j}, E_i, P_i, P_j, \mathrm{derive\\_extra}(context, \text{"key"}))$
        • $iv_{i,j} = H6(S^{\mathrm{e}}\_{i,j} \parallel S^{\mathrm{d}}\_{i,j}, E_i, P_i, P_j, \mathrm{derive\\_extra}(context, \text{"nonce"}))[0:24]$
   3. Prepare Plaintext: Participant $i$ prepares the plaintext to encrypt. This consists of the secret share $s_{i,j}$ followed by an optional application-defined payload $payload_{i,j}$: $plaintext_{i,j} = s_{i,j} \parallel payload_{i,j}$. If no application payload is used, $payload_{i,j}$ is empty.
   4. Encrypt Share: Participant $i$ encrypts the plaintext for participant $j$: $c_{i,j} = Enc(plaintext_{i,j}, k_{i,j}, iv_{i,j})$.

6. Broadcast: Participant $i$ sends their $msg_{1|i}$ to the coordinator.

Round 2: Share Decryption and Verification §

The coordinator waits to receive $msg_{1|i}$ from all $n$ participants. It then broadcasts a list of all received messages to every participant. Upon receiving the list of all $msg_{1|i}$ messages, each participant $i$ performs the following steps:

1. Validate Commitments: For each participant $j$ from $1$ to $n$:
   • Participant $i$ verifies that the VSS commitment $C_j$ contains exactly $t$ points. If $|C_j| \neq t$, participant $i$ MUST abort, identifying participant $j$ as malicious. This check prevents threshold elevation attacks.
2. Verify All PoPs: For each participant $j$ from $1$ to $n$:
   • Participant $i$ verifies the proof of possession $PoP_j$ using the Schnorr Verify algorithm. The signature is checked against the message context || C_j || E_j (with $C_j$ encoded as in Round 1), using participant $j$'s public commitment $C_{j,0}$ as the public key.
   • If any $PoP_j$ is invalid, participant $i$ MUST abort, identifying participant $j$ as malicious.
3. Decrypt and Verify Shares: For each participant $j$ from $1$ to $n$ (including the self-share $j = i$):
   1. Derive Key: Participant $i$ computes two ECDH shared secrets: one with the sender's ephemeral public key and their static key, and one with the sender's static public key and their static key: $S^{\mathrm{e}}\_{j,i} = d_i * E_j$ and $S^{\mathrm{d}}\_{j,i} = d_i * P_j$. They then derive the symmetric key and nonce:
      • If the hash function has an output length of at least 56 bytes (448 bits):
        • $tmp = H6(S^{\mathrm{e}}\_{j,i} \parallel S^{\mathrm{d}}\_{j,i}, E_j, P_j, P_i, context)$.
        • $k_{j,i} = tmp[0:32]$
        • $iv_{j,i} = tmp[32:56]$
      • Otherwise:
        • $k_{j,i} = H6(S^{\mathrm{e}}\_{j,i} \parallel S^{\mathrm{d}}\_{j,i}, E_j, P_j, P_i, \mathrm{derive\\_extra}(context, \text{"key"}))$
        • $iv_{j,i} = H6(S^{\mathrm{e}}\_{j,i} \parallel S^{\mathrm{d}}\_{j,i}, E_j, P_j, P_i, \mathrm{derive\\_extra}(context, \text{"nonce"}))[0:24]$
   2. Decrypt Plaintext: Participant $i$ decrypts the ciphertext sent to them from participant $j$: $plaintext_{j,i} = Dec(c_{j,i}, k_{j,i}, iv_{j,i})$. If decryption fails, participant $i$ MUST abort and report a decryption failure for the ciphertext attributed to participant $j$.
   3. Parse Plaintext: Participant $i$ parses the plaintext to extract the secret share $s_{j,i}$ (the first scalar-sized portion) and any optional application payload $payload_{j,i}$ (the remainder). If the plaintext is shorter than the ciphersuite's scalar encoding size, or if the leading scalar-sized portion does not decode to a valid scalar in $[0, q-1]$, participant $i$ MUST abort, identifying $j$ as malicious.
   4. Verify Share: Participant $i$ verifies the decrypted share $s_{j,i}$ against $j$'s VSS commitment: $s_{j,i} * B = \sum_{k=0}^{t-1} i^k * C_{j,k}$ If the check fails, participant $i$ MUST abort, identifying $j$ as malicious.
4. Compute Final Keys: If all shares are successfully decrypted and verified:
   1. Secret Share: Participant $i$ computes their final long-lived secret share by summing all received shares: $x_i = \sum_{j=1}^{n} s_{j,i}$.
   2. Group Public Key: Participant $i$ computes the group public key: $Y = \sum_{j=1}^n C_{j,0}$.
   3. Verification Share: Participant $i$ computes their public verification share $Y_i$. This is done by first computing the aggregated commitment for each coefficient $k$: $C_{agg,k} = \sum_{j=1}^{n} C_{j,k}$. Then, $Y_i = \sum_{k=0}^{t-1} i^k * C_{agg,k}$.
   4. Final Check: Participant $i$ performs a final self-consistency check: $x_i * B = Y_i$. If this check fails, the participant MUST abort. Note: This check is mathematically guaranteed to pass if all VSS share verifications in step 3.4 succeeded. It serves as a defense-in-depth measure to catch implementation bugs in the share summation or verification share computation.

Round 3: Certification §

This round ensures that all honest participants have arrived at the same public state.

1. Construct Transcript: Each participant $i$ constructs a canonical byte representation of the final public transcript, $T$. The transcript MUST be constructed by concatenating the following elements in this exact order:

   1. $\mathrm{len}(\mathtt{ciphersuite\\_id})$: The length of the ciphersuite identifier string (e.g., COCKTAIL(Ristretto255, SHA-512)) as a little-endian 64-bit unsigned integer.
   2. $\mathtt{ciphersuite\\_id}$: The ciphersuite identifier as its UTF-8 byte representation. Including the ciphersuite identifier in the transcript makes the success certificate self-describing and prevents cross-ciphersuite confusion in audit and recovery tooling.
   3. $len(context)$: The length of the context string as a little-endian 64-bit unsigned integer.
   4. $context$: The context string bytes.
   5. $n$: The number of participants as a little-endian 32-bit unsigned integer.
   6. $t$: The threshold as a little-endian 32-bit unsigned integer.
   7. For $j$ from $1$ to $n$: $P_j$ (the static public key of participant $j$, in its standard encoding).
   8. For $j$ from $1$ to $n$: $C_j$ (the full VSS commitment of participant $j$: $C_{j,0} \parallel \cdots \parallel C_{j,t-1}$).
   9. For $j$ from $1$ to $n$: $PoP_j$ (the Proof of Possession signature from participant $j$).
   10. For $j$ from $1$ to $n$: $E_j$ (the ephemeral public key from participant $j$).
   11. $len(ext)$: The length of the application-specific extension as a little-endian 64-bit unsigned integer.
   12. $ext$: The application-specific extension bytes (may be empty).

   All participants MUST produce identical transcripts. Any difference indicates a split-view attack or implementation bug.

2. Sign Transcript: Participant $i$ signs the transcript $T$ with their long-term static private key $d_i$ using the Schnorr Sign algorithm, producing a signature $sig_i$. If Sign aborts at its step 3 due to $k = 0$ (negligible probability), participant $i$ MUST NOT publish any partially-derived value and MUST treat this session as locally failed (analogous to the Round 1 PoP k = 0 handling). Since the transcript $T$ is identical across all honest participants, restarting CertEq within the same DKG session would reproduce the same $(d_i, T)$ inputs to Sign and therefore the same $k = 0$ result; the only safe retry path is a fresh DKG session with a different context (which yields a different $T$).

3. Broadcast Signature: Participant $i$ sends $sig_i$ to the coordinator.

4. Verify Certificate: The coordinator broadcasts the set of all signatures ${sig_1, \cdots, sig_n}$ to everyone. Each participant $i$ verifies every signature $sig_j$ on the transcript $T$ against the public key $P_j$ using the Schnorr Verify algorithm.

5. Success: If all signatures are valid, the DKG is successful. The participant stores their secret share $x_i$ and the group public key $Y$. The collection of $T$ and all $n$ signatures on it is called a "success certificate" and can be stored for auditing.

Application-Specific Extensions §

COCKTAIL-DKG supports an optional application-specific extension that is appended to the transcript before signing. This allows protocols that build atop COCKTAIL-DKG to ensure all parties agree on some application-defined value.

Extension Format:

The extension is appended to the transcript as:

• $len(ext)$: The length of the extension as a little-endian 64-bit unsigned integer.
• $ext$: The extension bytes (may be empty; when empty, $len(ext) = 0$).

Recommended Use Cases:

Applications MAY use the extension field for different purposes. Two common patterns are:

1. Consensus on External State: Ensure all parties commit to some agreed-upon value (e.g., a Merkle tree root, a configuration hash, or a session identifier). The protocol only succeeds if everyone provides the same extension value. This is useful when the DKG must be bound to external application state.

2. Collective Randomness Derivation: All participants hash together independently-contributed random data via the extension. If the transcript hashes all match, the participants can derive a shared random value that no single party could have predicted or biased. This is useful for protocols that need distributed randomness as a byproduct of the DKG.

These use cases are not compatible with each other; an application must choose one approach. The extension semantics are entirely application-defined; COCKTAIL-DKG simply ensures that all participants agreed on the extension value before the protocol completes.

Deriving Extensions from Payloads:

When applications use the optional payloads in the encryption step (see Optional Application Payloads), they MAY derive the extension from those payloads to ensure all participants agree on the exchanged data. A recommended approach is to compute a hash of the participant-ordered payloads:

1. For each participant $j$ from $1$ to $n$, collect their payload contributions. To produce a consistent extension across all participants, the application MUST ensure every recipient observes the same $payload_j$ from participant $j$ (e.g., by having $j$ broadcast the same payload to every recipient).

   In this construction, $payload_j$ denotes the single application payload sent by participant $j$, and is only well-defined when $payload_{j,1} = \cdots = payload_{j,n}$.

2. Compute the extension as: $ext = H(n \parallel len(payload_1) \parallel payload_1 \parallel \cdots \parallel len(payload_n) \parallel payload_n)$ Where $H$ is the ciphersuite's hash function (the same $H$ used by $H6$), $n$ is encoded as a little-endian 64-bit unsigned integer, and each $len(payload_j)$ is a little-endian 64-bit unsigned integer.

This ensures that any disagreement about the payloads will result in different transcripts and failed signature verification.

Security Note:

The extension is included in the transcript and thus covered by all participants' signatures. This provides the same consensus guarantee as the rest of the transcript: if any participant has a different extension value, the signatures will not verify and the protocol will abort safely.

Error Handling §

A robust implementation of COCKTAIL-DKG MUST handle a variety of error conditions. Errors can arise from malformed messages, invalid cryptographic values, or protocol violations. The ability to distinguish between these cases is crucial for security and usability.

Error Categories §

We recommend that implementations define distinct error types to represent different failure modes. This allows applications to react appropriately, whether by retrying an operation, aborting the protocol, or initiating a blame-finding procedure.

The following categories cover the most common errors:

1. Parsing and Deserialization Errors:
   • Description: These errors occur when a received message does not conform to the byte-based format specified in the Message Formats section. This could be due to an incorrect length, an invalid point or scalar encoding, or other structural defects.
   • Action: An honest participant should never produce a malformed message. If a participant receives such a message, it should be treated as evidence of a bug in the sender's implementation or a deliberate protocol violation. The protocol MUST be aborted. If the sender can be identified (e.g., in $msg_{1|i}$), they should be flagged as faulty.
2. Cryptographic Verification Failures:
   • Description: These errors occur when a cryptographic check fails. This category includes:
     • An invalid Proof-of-Possession ($PoP_j$).
     • A VSS share verification failure ($s_{j,i} \cdot B \ne \sum_{k=0}^{t-1} i^k \cdot C_{j,k}$).
     • A failed decryption of an encrypted share ($c_{j,i}$).
     • An invalid signature on the final transcript ($sig_j$).
   • Action: A cryptographic failure is a clear indication that a participant is behaving maliciously or has a serious bug. The protocol MUST be aborted immediately. For public failures such as an invalid PoP, invalid VSS share, or invalid transcript signature, the participant who sent the invalid data MUST be identified and blamed. A decryption failure is locally attributable to the sender's ciphertext, but it is not publicly verifiable in the same way as a VSS or PoP failure: the AEAD key derives from the recipient's static private key. See Differences from ChillDKG for the option set: Options 1 and 2 establish only that a specific ciphertext was sent (ciphertext binding), while only Option 3 provides public verification of the decryption outcome itself.
3. Protocol Logic Errors:
   • Description: These errors relate to violations of the protocol's state machine or rules, such as:
     • A participant sending a message at the wrong time.
     • The coordinator broadcasting an inconsistent msg2 (e.g., omitting a participant's data).
   • Action: These errors indicate a faulty participant or coordinator. The protocol MUST be aborted. If the error can be traced to a specific participant, they should be blamed.

Blame-Finding and Reporting §

A key feature of a secure DKG protocol is the ability to identify malicious participants. When an error occurs, the protocol MUST terminate and, when evidence permits, output information about who caused the failure. This is crucial for accountability in decentralized systems.

• Coordinator's Role: The coordinator is positioned to detect errors in $msg_{1|i}$ messages early, but it is not trusted to attribute those errors, and the spec does not assume the coordinator is honest. When the coordinator receives a malformed $msg_{1|i}$ or one with an invalid PoP from participant $i$, it MUST abort the protocol and broadcast a blame message; however, the public verifiability of that blame depends on which part of $msg_{1|i}$ failed:
  • For an invalid $PoP_i$ or an invalid commitment-length check on $C_i$, the coordinator's blame can be publicly verified by any third party from the broadcast $C_i$, $PoP_i$, $E_i$, and the agreed context (the PoP signs $context \parallel C_i \parallel E_i$ under $C_{i,0}$, and the commitment-length check is purely structural). The coordinator's blame is therefore third-party-checkable evidence in this case.
  • For a malformed ciphertext frame in $msg_{1|i}$ (an out-of-range length prefix, undersize ciphertext, etc.) the coordinator cannot publicly attribute the malformation to participant $i$ without an application-level ciphertext-byte authentication mechanism (see Differences from ChillDKG). The coordinator's blame in this case is unilateral and MUST NOT be relied upon as third-party-checkable evidence; participant $i$ may have sent a well-formed message that the coordinator subsequently modified. Applications requiring publicly-attributable malformed-ciphertext blame MUST layer such authentication.
• Participant's Role and Public Proofs: Participants MUST validate all data they receive.
  • If participant $i$ fails to verify a share $s_{j,i}$ from participant $j$, it MUST abort. To prove that $j$ is cheating, participant $i$ can broadcast a blame message containing $j$'s index and the invalid share $s_{j,i}$. Any third party can then verify this claim by checking the VSS equation ($s_{j,i} \cdot B = \sum_{k=0}^{t-1} i^k \cdot C_{j,k}$) using the public commitment $C_j$. A failure of this equation is a public and undeniable proof of $j$'s misbehavior.
  • Similarly, if a PoP from participant $j$ is invalid, this is also a publicly verifiable proof of misbehavior, since the PoP, the message it signs, and the public key $C_{j,0}$ are all public.
  • In contrast, a decryption failure at recipient $i$ for $c_{j,i}$ is not publicly verifiable in the same way: the AEAD verification requires the key $k_{j,i}$, which is derived from $i$'s static private key $d_i$ and is not public. Recipient $i$ can locally attribute the failure to participant $j$'s ciphertext, but cannot produce a non-interactive proof that any third party can independently check from public data alone. Applications requiring publicly verifiable decryption-failure blame MUST use Option 3 from Differences from ChillDKG (the dispute-evidence channel providing a non-interactive proof of decryption outcome); Options 1 and 2 establish only ciphertext binding and are not by themselves sufficient for public verification of the decryption outcome.
• Resolving Disputes and Coordinator Malice: The final certification round is essential for detecting a malicious coordinator and resolving disputes.

  • Split-View Attack: If a coordinator sends different messages to different participants, their final transcripts $T$ will differ. In Round 3, when participants exchange signatures, these signatures will not verify on the inconsistent transcripts. An honest participant $i$ who fails to verify $sig_j$ can initiate a dispute by broadcasting their $T_i$ and $sig_i$.

    • If participant $j$ responds with a different $T_j$ and a valid $sig_j$ over it, the discrepancy between $T_i$ and $T_j$ serves as undeniable proof of a split-view attack by the coordinator.

  • Framing a Participant: If a coordinator attempts to frame participant $j$ by modifying the PoP-bound portion of $msg_{1|j}$ (i.e., the VSS commitment $C_j$, the ephemeral public key $E_j$, or the PoP itself) before broadcasting it to the other participants, the modified PoP will fail PoP verification for all receivers, who will then abort Round 2 and broadcast a blame message naming $j$. Coordinator modifications restricted to the ciphertext portion of $msg_{1|j}$ (which the PoP does not sign; see Differences from ChillDKG) do not cause PoP failure; they cause Round 2 framing-format or decryption failures whose attribution paths require Option 1 or Option 2 ciphertext-byte authentication for public blame. The rest of this paragraph addresses the PoP-bound-modification case only.

    The protocol does not reach Round 3, so the PoP-framing dispute cannot be resolved via the CertEq transcript-signature pathway. Instead, dispute resolution is out-of-band evidence publication: participant $j$, who locally still holds the original valid $msg_{1|j}$ (including its valid PoP signed under $C_{j,0}$), can publish that original message as a public refutation of the blame. Any third party can then verify the PoP against $C_{j,0}$ using the message bytes participant $j$ published; if it verifies, the conclusion is that the version received by other participants must have been altered in transit, definitively identifying the coordinator as malicious. This dispute-resolution channel is therefore a property of how the DKG embeds in the surrounding system (some broadcast surface participant $j$ can use to publish evidence), not a property of the in-protocol message flow. Applications that require automated, in-protocol dispute resolution SHOULD define such a refutation channel as part of their integration of COCKTAIL-DKG.

Ciphersuites §

This section describes the ciphersuites that are specified for use with COCKTAIL. The current scope includes both RFC 9591 and ZIP-0312.

Each ciphersuite defines a key derivation function $H6(x, E, P_s, P_r, extra)$, an encryption method $Enc(plain, key, iv)$, and a decryption method $Dec(cipher, key, iv)$. Ciphersuites MUST use an AEAD mode for $Enc()$ and $Dec()$. The protocol's confidentiality, ciphertext-integrity, blame-finding, and optional-payload authentication properties all rely on AEAD; a non-AEAD $Enc()/Dec()$ pair is not a valid COCKTAIL-DKG ciphersuite.

The choice of AEAD is guided by the principle of preventing nonce reuse. All COCKTAIL-DKG AEAD nonces are deterministically derived via $H6$ (see Round 1: Commitment and Encryption); implementations MUST NOT sample nonces randomly. The 24-byte (192-bit) nonce width was chosen so that the $H6$-derived nonces have a negligible probability of collision across distinct $(sender, recipient, session)$ triples even though they are not random; i.e., the width is a safety margin for deterministic derivation, not a license to sample nonces independently. For ciphersuites where the underlying hash function provides a large enough output (at least 56 bytes / 448 bits; e.g., SHA-512), we can derive both the 256-bit key and the 24-byte nonce directly from a single $H6$ output.

For ciphersuites based on SHA-256, where the output is smaller than 56 bytes, we use two domain-separated $H6()$ invocations. For the key, $H6$ is called with $\mathrm{derive\\_extra}(context, \text{"key"})$ and the full 32-byte output is used. For the nonce, $H6$ is called with $\mathrm{derive\\_extra}(context, \text{"nonce"})$ and the first 24 bytes are used. The AEAD of choice for the SHA-256 based ciphersuites we specify here is XAES-256-GCM.

The $H6$ function is used to derive a symmetric key and nonce from ECDH shared secrets. Unless otherwise specified, it is defined as:

$H6(x, E, P_s, P_r, extra) = H(prefix \parallel x \parallel E \parallel P_s \parallel P_r \parallel len(extra) \parallel extra)$

• $H$: The specified cryptographic hash function (e.g., SHA-512, BLAKE2b-512).
• $prefix$: A ciphersuite-specific byte string (e.g., COCKTAIL-DKG-Ed25519-SHA512-H6).
• $x$: The concatenation of two ECDH shared secrets: $S^{\mathrm{e}}$ (ephemeral-to-static) and $S^{\mathrm{d}}$ (static-to-static).
• $E$: The sender's ephemeral public key.
• $P_s$: The sender's static public key.
• $P_r$: The recipient's static public key.
• $len(extra)$: The length of the extra data, encoded as a little-endian 64-bit integer.
• $extra$: Additional context-specific data.

The output of $H6$ is used to derive the key and nonce for the AEAD.

For hash functions with output smaller than 56 bytes, $\mathrm{derive\\_extra}(context, label)$ is defined as:

where both lengths are encoded as little-endian 64-bit unsigned integers, and $label$ is the ASCII string "key" or "nonce" (without quotes).

ECDH Shared-Secret Encoding §

Each ECDH shared secret $S = s \cdot P$ (the scalar-mult result that is fed into $H6$ as part of $x = S^{\mathrm{e}} \parallel S^{\mathrm{d}}$) is encoded as a fixed-length byte string per the ciphersuite, so that the concatenation $x$ is unambiguously parsed and reproducible across implementations:

For Curve25519-family ciphersuites (COCKTAIL(Ed25519, SHA-512), COCKTAIL(Ristretto255, SHA-512)), the ECDH shared secret is the canonical 32-byte Ristretto255 encoding of $S = s \cdot P$ as defined in RFC 9496 §4.3.2. Both ciphersuites operate internally over Ristretto255 (see Working with curves with small subgroups) and therefore produce byte-identical ECDH shared secrets for equal scalar/point inputs; the ciphersuites are domain-separated only via their distinct $H6$, $H7$, and nonce prefixes.

For Ed448 ciphersuites (COCKTAIL(Ed448, SHAKE256)), the ECDH shared secret is the 57-byte RFC 8032 compressed Ed448 encoding of $S = s \cdot P$. Because all decoded protocol points are required to be non-identity prime-order subgroup points, $S$ is computed inside the prime-order subgroup and has a unique compressed Ed448 encoding. Decaf448-internal implementations use the deterministic Decaf448-to-Ed448 output mapping defined in the COCKTAIL(Ed448, SHAKE256) ciphersuite definition before feeding $S$ into $H6$.

For Weierstrass-curve ciphersuites (COCKTAIL(P-256, SHA-256), COCKTAIL(secp256k1, SHA-256)), the ECDH shared secret is the SEC1 compressed encoding of $S = s \cdot P$: a one-byte tag $\{0x02, 0x03\}$ indicating the parity of $S$'s $y$-coordinate, followed by the 32-byte big-endian encoding of $S$'s $x$-coordinate.

For Zcash-family ciphersuites (COCKTAIL(JubJub, BLAKE2b-512), COCKTAIL(Pallas, BLAKE2b-512)), the ECDH shared secret is the standard Zcash compressed encoding of $S$, with conventions that differ between JubJub and Pallas:

• JubJub (a twisted Edwards curve): use the Edwards-style 32-byte encoding defined by ZIP-0312 (repr_J / SerializeElement), which encodes the affine $y$-coordinate of $S$ as a 32-byte little-endian integer with the sign bit of $x$ packed into the high bit of the encoded $y$. This is the same encoding used for Jubjub elements throughout Zcash Sapling.
• Pallas (a short-Weierstrass curve on the Pasta cycle): use the Halo2/Orchard to_bytes convention, which encodes the affine $x$-coordinate of $S$ as a 32-byte little-endian integer with the sign bit of $y$ packed into the high bit of the encoded $x$.

Both are 32-byte canonical encodings; implementations MUST use the curve-appropriate convention and MUST NOT confuse them.

In every case, the encoding MUST be canonical (a single byte representation per element); non-canonical encodings MUST be rejected by the recipient on decode of $S$ when $S$ is exchanged outside this protocol. Within COCKTAIL-DKG itself, each side computes its own $S$ locally and encodes it deterministically, so the encoded value is byte-identical on the sender and recipient sides by construction.

Ciphersuite Definitions §

Each ciphersuite is identified by a canonical ciphersuite_id string. The ciphersuite_id is consensus-critical: it is bound into the session context, the canonical transcript $T$, the test-vector labeled-hash derivation, and per-implementation domain separation. Implementations MUST use the exact byte representations below (no whitespace normalization, no case folding, no alternate punctuation); the strings are UTF-8 encoded but happen to be pure ASCII.

Implementations MUST reject any transcript whose ciphersuite_id field, which appears as explicit length-prefixed bytes at the head of $T$ (see Round 3: Certification), does not exactly match one of the byte strings above. For the session context, which under the recommended construction is a hash digest over a preimage that includes ciphersuite_id rather than the raw ciphersuite_id bytes, the corresponding check is structural: implementations MUST ensure their own context preimage uses the exact ciphersuite_id byte string for the ciphersuite they believe they are running, and MUST abort if any participant's reconstructed context value disagrees with the one they themselves derived (cf. Setup, where context-agreement is already a MUST). For implementations using a non-hashing context construction in which ciphersuite_id appears as an explicit substring, the direct byte-string match above applies.

• COCKTAIL(Ed25519, SHA-512)

  • Group (mathematical): the prime-order subgroup of order $L$ of Edwards25519. Implementations MAY realize this group via either of two equivalent strategies: the choice is local and does not affect interoperability, because both produce byte-identical outputs for byte-identical inputs:

    • (a) Ristretto255-internal. Represent group elements as Ristretto255 elements (RFC 9496). All scalar arithmetic and ECDH operations execute over Ristretto255, which mathematically abstracts away Edwards25519's cofactor structure. Inputs received as 32-byte RFC 8032 Ed25519 byte strings are decoded to CompressedEdwardsY, decompressed, and the resulting Edwards point is then required to be in the prime-order subgroup (see "Input requirements" below); only those prime-order-subgroup points have a meaningful Ristretto255 representative. Outputs for Ed25519 consumers are emitted via the deterministic three-step output mapping defined below.
    • (b) Raw-Edwards-with-subgroup-check. Represent group elements as Edwards25519 points directly. All scalar arithmetic and ECDH operations execute on the prime-order subgroup of order $L$, which is closed under the protocol's operations. All decoded input points MUST be checked to be in the prime-order subgroup before use (see "Input requirements" below); raw cofactor-bearing Edwards points are rejected on input. Outputs are emitted via direct RFC 8032 Ed25519 encoding of the resulting prime-order Edwards point.

    Strategies (a) and (b) are byte-equivalent: Ristretto255 is the canonical bijection between the prime-order subgroup of Edwards25519 and the Ristretto255 group, so scalar arithmetic in either form produces the same Edwards point, and the RFC 8032 encoding of that Edwards point is the same in either case. The Ristretto255-internal strategy (a) has the advantage that prime-order safety is structural: non-prime-order elements cannot even be represented as Ristretto255 values, so the subgroup check is implicit; the raw-Edwards strategy (b) is simpler to implement on top of existing Ed25519 libraries but requires explicit subgroup checks on every decoded input.

  • Input requirements: regardless of implementation strategy, every decoded Edwards25519 input point (static public keys $P_i$, ephemeral public keys $E_i$, VSS commitment points $C_{i,k}$, Schnorr commitment points $R$) MUST be verified to lie in the prime-order subgroup of order $L$. The check is either explicit (multiply by $L$ and assert identity, or use a library-provided is_torsion_free predicate) or implicit via the Ristretto255 abstraction (decode failure when the candidate Edwards point is not the canonical Ristretto255 representative). Implementations MUST abort on subgroup-check failure.

  • Output format: the group public key $Y$ and verification shares $Y_i$ are emitted as 32-byte RFC 8032 Ed25519 compressed point encodings (the affine $y$-coordinate as a 32-byte little-endian integer with the sign bit of $x$ packed into the high bit of the last byte). Strategy (b) implementations encode the result directly. Strategy (a) implementations MUST apply the following deterministic three-step output mapping (which produces the same bytes), and MUST NOT substitute an implementation-internal Edwards representative or any older cofactor-clearing formula:

    1. Encode the Ristretto255 element $R$ to its canonical 32-byte Ristretto255 encoding per RFC 9496 §4.3.2.
    2. Decode those 32 bytes per RFC 9496 §4.3.1 (the canonical decoding procedure). RFC 9496's decoding returns a specific Edwards point on Edwards25519 in the prime-order subgroup of order $q$. This Edwards point is the canonical Ed25519 representative of $R$ and is uniquely determined by the Ristretto255 byte encoding from step 1.
    3. Encode that Edwards point as the standard 32-byte RFC 8032 Ed25519 compressed point encoding: the affine $y$-coordinate written as a 32-byte little-endian integer with the sign bit of $x$ packed into the high bit of the last byte.

    Because step 1 and step 2 are both canonical and deterministic, two independent implementations that compute the same Ristretto255 element internally (regardless of their internal Edwards representative) will produce byte-identical 32-byte Ed25519 outputs. The generic cofactor-clearing identity discussed in Working with curves with small subgroups is not part of this output lift and MUST NOT be substituted for the RFC 9496-based procedure above; the Edwards point returned by RFC 9496 §4.3.1 is already in the prime-order subgroup, and using a separate cofactor-clearing step would also fail to pin down a canonical Edwards representative across implementations.

    Secret shares $x_i$ are scalars and MUST be emitted in the 32-byte little-endian RFC 8032 Ed25519 scalar encoding without transformation (the numerical scalar is the same as the underlying Ristretto255 scalar; only the byte ordering matches RFC 8032's little-endian convention).

  • H6 Hash: SHA-512

  • H6 Prefix: COCKTAIL-DKG-Ed25519-SHA512-H6 (distinct from the Ristretto255 ciphersuite below)

  • Key/Nonce: The first 32 bytes of the H6 output are the key, and the next 24 bytes are the nonce.

  • AEAD: XChaCha20-Poly1305

• COCKTAIL(Ristretto255, SHA-512)

  • Group: Ristretto255 (RFC 9496). All scalar arithmetic, ECDH operations, and outputs (group public key, verification shares) are encoded as Ristretto255 elements. No cross-abstraction lift to raw Ed25519 is performed; this ciphersuite is for consumers that natively use Ristretto255.
  • H6 Hash: SHA-512
  • H6 Prefix: COCKTAIL-DKG-Ristretto255-SHA512-H6 (distinct from the Ed25519 ciphersuite above)
  • Key/Nonce: The first 32 bytes of the H6 output are the key, and the next 24 bytes are the nonce.
  • AEAD: XChaCha20-Poly1305

• COCKTAIL(Ed448, SHAKE256)

  • Group: the prime-order subgroup of Edwards448, with RFC 9591 / RFC 8032 encodings. This ciphersuite is intended for interoperability with RFC 9591 FROST(Ed448, SHAKE256) key material. Implementations MAY realize this group via either of two equivalent strategies:

    • (a) Decaf448-internal. Represent group elements internally as Decaf448 elements (RFC 9496). Received 57-byte RFC 8032 Ed448 point encodings are decoded as Edwards448 points, required to be in the prime-order subgroup, and then represented in the Decaf448 quotient. Outputs are emitted via the deterministic output mapping below.
    • (b) Raw-Edwards-with-subgroup-check. Represent group elements as Edwards448 points directly. All decoded input points MUST be checked to be in the prime-order subgroup before use. Outputs are emitted via direct RFC 8032 Ed448 encoding of the resulting prime-order Edwards point.

    Strategies (a) and (b) are byte-equivalent for all protocol outputs. The prime-order Edwards448 subgroup maps isomorphically to Decaf448, and the output mapping below projects the Decaf448 result back to that subgroup before RFC 8032 encoding.

  • Input requirements: every decoded Ed448 input point (static public keys $P_i$, ephemeral public keys $E_i$, VSS commitment points $C_{i,k}$, Schnorr commitment points $R$, group public key $Y$, and verification shares $Y_i$ when imported) MUST be verified to lie in the prime-order subgroup of order $q$ and MUST NOT be the identity. Implementations MUST abort on subgroup-check failure. Cofactor clearing alone is not an acceptable substitute for subgroup validation.

  • Output format: the group public key $Y$ and verification shares $Y_i$ are emitted as 57-byte RFC 8032 Ed448 compressed point encodings, matching RFC 9591 SerializeElement. Strategy (b) implementations encode the result directly. Strategy (a) implementations MUST apply the following deterministic output mapping:

    1. Encode the Decaf448 element $D$ to its canonical 56-byte Decaf448 encoding per RFC 9496 §5.3.2.
    2. Decode those 56 bytes per RFC 9496 §5.3.1. RFC 9496's decoding procedure returns a specific internal Edwards448 representative P = (x, y, 1, t) of the Decaf448 element.
    3. Project that representative into the prime-order Edwards448 subgroup: $P' = [4^{-1} \bmod q] \cdot ([4] \cdot P)$.
    4. Encode $P'$ as the standard 57-byte RFC 8032 Ed448 compressed point encoding.

    Because steps 1 through 3 are canonical and deterministic, two independent Decaf448-internal implementations that compute the same Decaf448 element will produce byte-identical 57-byte Ed448 outputs in the prime-order subgroup. Plain cofactor clearing $[4] \cdot P$ is not this output lift and MUST NOT be substituted for the projection above, because it would multiply the prime-order component by 4 rather than recover the RFC 9591-compatible subgroup representative.

  • Scalar encoding: 57-byte little-endian scalar encoding, matching RFC 9591 SerializeScalar. Encoded scalars MUST be canonical values in $[0, q-1]$.

  • H6 Hash: SHAKE256 invoked at 56-byte output. (SHAKE256 is an XOF; $HashToScalar$ for this ciphersuite invokes SHAKE256 at 114 bytes, which is a separate use of the same primitive. See Schnorr Hash-to-Scalar Reduction.)

  • H6 Prefix: COCKTAIL-DKG-Ed448-SHAKE256-H6

  • Key/Nonce: The 56-byte $H6$ output is the key (first 32 bytes) followed by the nonce (next 24 bytes).

  • AEAD: XChaCha20-Poly1305

  • RFC 9591 compatibility note: the DKG outputs (group public key $Y$, verification shares $Y_i$, and secret shares $x_i$) use the same raw Ed448 point and scalar encodings as RFC 9591. The additional COCKTAIL-DKG Schnorr signatures used for PoPs and transcript certification remain COCKTAIL-specific and are domain-separated from RFC 9591 signing.

• COCKTAIL(P-256, SHA-256)

  • H6 Hash: SHA-256
  • H6 Prefix: COCKTAIL-DKG-P256-SHA256-H6
  • Key/Nonce: Two domain-separated H6 invocations are used.
    • The key MUST be H6(x, E, P_s, P_r, derive_extra(context, "key")) (the full 32-byte SHA-256 output).
    • The nonce MUST be the first 24 bytes of H6(x, E, P_s, P_r, derive_extra(context, "nonce")).
  • AEAD: XAES-256-GCM

• COCKTAIL(secp256k1, SHA-256)

  • Note: This ciphersuite is NOT backwards-compatible with ChillDKG due to our key derivation including both ephemeral-static and static-static ECDH, instead of just ephemeral-static (see Differences from ChillDKG below).
  • H6 Definition: A BIP-340-style tagged hash with the tag COCKTAIL-DKG/H6. The message is $x \parallel E \parallel P_s \parallel P_r \parallel extra$. Note that this deviates from the default H6 formula above by omitting len(extra). For calls that pass context directly, this is safe because context is fixed across every $H6$ call within a session. For SHA-256 key/nonce derivation, derive_extra(context, label) length-prefixes its components before they are passed as extra, so the key and nonce calls remain unambiguous. Applications MUST NOT repurpose this $H6$ with other variable-length extra inputs without re-introducing length prefixing.
  • Key/Nonce: Two domain-separated H6 invocations are used.
    • The key MUST be H6(x, E, P_s, P_r, derive_extra(context, "key")) (the full 32-byte SHA-256 output).
    • The nonce MUST be the first 24 bytes of H6(x, E, P_s, P_r, derive_extra(context, "nonce")).
  • AEAD: XAES-256-GCM
  • Bitcoin Taproot Warning: When using this ciphersuite for Bitcoin Taproot outputs, applications MUST be aware that a malicious participant could attempt to embed a hidden Taproot script-path commitment in the threshold public key. Applications intending to use the group public key $Y$ as a Taproot output MUST apply the BIP-341 unspendable-script-path tweak (as described in ChillDKG) when constructing the Taproot output key from $Y$. This is the only mitigation specified by this document; an operational policy of "only spend via the key path" is not sufficient, because once $Y$ is published as the Taproot output key, an attacker who knows the hidden script path can spend via that path without the operator's involvement. This consideration is specific to Bitcoin Taproot and does not apply to other uses of this ciphersuite.

• COCKTAIL(JubJub, BLAKE2b-512)

  • Note: Compatible with ZIP-0312.
  • H6 Hash: BLAKE2b-512 (full 64-byte output; $H6$ uses the first 56 bytes).
  • H6 Prefix: COCKTAIL-DKG-JubJub-BLAKE2b-H6
  • Key/Nonce: The first 32 bytes of the H6 output are the key, and the next 24 bytes are the nonce. The trailing 8 bytes of the BLAKE2b-512 output are unused for $H6$.
  • AEAD: XChaCha20-Poly1305

• COCKTAIL(Pallas, BLAKE2b-512)

  • Note: Compatible with ZIP-0312.
  • H6 Hash: BLAKE2b-512 (full 64-byte output; $H6$ uses the first 56 bytes).
  • H6 Prefix: COCKTAIL-DKG-Pallas-BLAKE2b-H6
  • Key/Nonce: The first 32 bytes of the H6 output are the key, and the next 24 bytes are the nonce. The trailing 8 bytes of the BLAKE2b-512 output are unused for $H6$.
  • AEAD: XChaCha20-Poly1305

Schnorr Signature Scheme §

COCKTAIL-DKG uses a simple Schnorr signature scheme for both the Proof of Possession (PoP) and the transcript certification in Round 3. The signature scheme is defined as follows:

Schnorr Signature Format §

A signature consists of two components:

• $R$: A compressed elliptic curve point (the commitment)
• $z$: A scalar (the response)

The signature is encoded as the concatenation of the compressed point encoding of $R$ followed by the scalar encoding of $z$. The total signature size is the point size plus the scalar size for the ciphersuite's group:

Schnorr Sign Algorithm §

Given a secret key $sk$ (a scalar) and a message $m$ (a byte string):

1. Compute the public key: $pk = sk * B$
2. Compute a deterministic nonce: $k = HashToScalar(prefix_{nonce} \parallel encode(sk) \parallel m)$
3. Reject $k = 0$: if $k = 0$ (probability $\approx 2^{-\lceil \log_2 q \rceil}$, negligible), implementations MUST abort signing immediately and MUST NOT reveal any further derived value. A $k = 0$ would yield $R = O$ (the identity), which the Verify algorithm rejects at step 2, but the response $z = k + c \cdot sk = c \cdot sk$ would also be computable from the signer's outputs and would directly leak $sk$ to any observer who saw $z$. Since the nonce is deterministic, a signer who hits this branch on a given $(sk, m)$ pair MUST NOT simply retry with the same inputs; this is treated as an unrecoverable signing failure for this $(sk, m)$ pair. Applications MAY introduce an additional disambiguator (e.g., a 32-byte counter mixed into $prefix_{nonce}$) as an out-of-band recovery mechanism, but the base scheme aborts.
4. Compute the commitment: $R = k * B$
5. Compute the challenge: $c = HashToScalar(prefix_{H7} \parallel R \parallel pk \parallel m)$
6. Compute the response: $z = k + c \cdot sk \bmod q$
7. Return the signature $(R, z)$

Where:

• $prefix_{nonce}$ and $prefix_{H7}$ are ciphersuite-specific UTF-8 byte strings (e.g., COCKTAIL-DKG-Ed25519-SHA512-NONCE and COCKTAIL-DKG-Ed25519-SHA512-H7). They provide domain separation between COCKTAIL-DKG signatures and any standard signature scheme that uses the ciphersuite's underlying hash, so that COCKTAIL-DKG signatures cannot be re-verified by a verifier of the ciphersuite's underlying signature scheme (e.g., EdDSA, BIP-340).
• $encode(\cdot)$ uses the ciphersuite's compressed point encoding for points and the ciphersuite's scalar encoding for scalars.
• $B$ is the generator point of the elliptic curve group.
• $HashToScalar$ is defined per ciphersuite in Schnorr Hash-to-Scalar Reduction and has a fully specified, deterministic structure per ciphersuite. For most ciphersuites this is a single hash invocation followed by wide modular reduction; for P-256 specifically, $HashToScalar$ is a 48-byte expansion via two SHA-256 invocations with distinct one-byte prefixes (see the P-256 row of Schnorr Hash-to-Scalar Reduction), and for secp256k1 it is a single SHA-256 invocation reduced modulo $q$ (BIP-340 conventions). In every case, the byte string passed into $HashToScalar$ is consumed by the ciphersuite's defined hash structure exactly once before reduction; no additional outer/inner hash wrap is applied by Sign or Verify.

Schnorr Verify Algorithm §

Given a signature $(R, z)$, a public key $pk$, and a message $m$:

1. Reject if $z$ does not decode to a canonical scalar in $[0, q-1]$.
2. Reject if $R$ does not decode to a valid prime-order subgroup point that is not the identity.
3. Compute the challenge: $c = HashToScalar(prefix_{H7} \parallel R \parallel pk \parallel m)$
4. Compute the left-hand side: $lhs = z * B$
5. Compute the right-hand side: $rhs = R + c * pk$
6. Return true if $lhs = rhs$, otherwise return false

Schnorr Prefix Strings §

The ciphersuite-specific values for $prefix_{H7}$ and $prefix_{nonce}$ are:

For the secp256k1 ciphersuite, the nonce and challenge derivations use BIP-340 tagged hashes directly and MUST override (not wrap) the generic Sign step 2 and step 5 formulas above. The $k = 0$ rejection rule from Sign step 3 also applies (and aborts under the same conditions):

• Nonce (replaces step 2): $k = OS2IP(taggedHash(\text{`COCKTAIL-DKG/NONCE'}, encode(sk) \parallel m)) \bmod q$.
• Challenge (replaces step 5): $c = OS2IP(taggedHash(\text{`COCKTAIL-DKG/H7'}, R \parallel pk \parallel m)) \bmod q$.

Where $taggedHash(tag, msg) = SHA256(SHA256(tag) \parallel SHA256(tag) \parallel msg)$ as defined in BIP-340, $tag$ is encoded as its UTF-8 byte representation, $encode(sk)$ is the 32-byte big-endian secp256k1 scalar encoding, and $OS2IP$ interprets the 32-byte tagged-hash output as a big-endian integer. The same Verify step 3 substitution applies. The resulting scalar bias is approximately $2^{-128}$ (specifically $\approx 1.27 \cdot 2^{-128}$) for secp256k1 because $q \approx 2^{256} - 2^{128}$.

Schnorr Hash-to-Scalar Reduction §

$HashToScalar$ takes a byte string $input$ and reduces it to a scalar in $[0, q-1]$. The construction depends on the ciphersuite's hash output length and on the ratio between $2^{8L}$ (where $L$ is the hash output byte-length) and $q$:

• SHA-512 (Ed25519, Ristretto255): invoke SHA-512 on $input$ to produce 64 bytes; interpret the bytes as the ciphersuite's scalar endianness and apply wide reduction modulo $q$. Bias $\le 2^{-128}$.
• SHAKE256 (Ed448): invoke SHAKE256 on $input$ with a 114-byte output (chosen so the input to the reduction is at least $\lceil \log_2 q \rceil + 128$ bits); interpret as little-endian and apply wide reduction modulo $q$. Bias $\le 2^{-128}$. Note that SHAKE256 is an extendable-output function; H6 invokes SHAKE256 at 56 bytes for AEAD key/nonce derivation, while $HashToScalar$ invokes SHAKE256 at 114 bytes. These are independent uses of the same primitive at different output lengths.
• BLAKE2b-512 (JubJub, Pallas): invoke BLAKE2b-512 on $input$ to produce 64 bytes; interpret as little-endian and apply wide reduction modulo $q$. Bias $\le 2^{-128}$.
• SHA-256, P-256: P-256's order is $q \approx 2^{256} - 2^{224}$, so direct mod $q$ reduction of a 32-byte hash has statistical distance from uniform of $\approx 2^{-32}$, which is too large for a 128-bit security target. $HashToScalar$ for P-256 therefore expands to 48 bytes before reduction: $HashToScalar(input) = OS2IP\bigl(SHA256(\mathtt{0x01} \parallel input) \parallel SHA256(\mathtt{0x02} \parallel input)[0{:}16]\bigr) \bmod q$, where $OS2IP$ interprets the 48-byte string as a big-endian integer. Bias $\le 2^{-128}$. This matches the spirit of hash_to_field from RFC 9380 used by RFC 9591's FROST(P-256, SHA-256).
• SHA-256, secp256k1: secp256k1's order is $q \approx 2^{256} - 2^{128}$, so direct mod $q$ reduction of a 32-byte hash has bias $\approx 1.27 \cdot 2^{-128}$ (i.e., the leftover $2^{256} \bmod q$ divided by $2^{256}$). $HashToScalar(input) = OS2IP(SHA256(input)) \bmod q$, interpreted big-endian. This matches BIP-340 conventions and is acceptable for 128-bit security targets.