Design verifiable encryption for DKG share payloads

[p0mvn]

Context

The current DKG share transport uses ECIES because the original requirement was confidential delivery of each scalar share to the recipient validator's registered Pallas public key.

The protocol has since grown into a more complex DKG flow where recipients can detect bad shares locally, but the chain cannot verify that encrypted payloads match the published Feldman commitments. A malicious dealer can publish valid-looking commitments and encrypt an invalid share to one or more recipients, causing those validators to fail local verification and withhold acks. This is a liveness risk for the ceremony.

Current Baseline

Feldman commitments only

• Publicly verifies shares after the share is known.
• The recipient can detect if their decrypted share does not match the published polynomial commitments.
• The chain cannot verify encrypted payload correctness before recipients decrypt.

Feldman commitments + polynomial Schnorr PoK

Schnorr POK POC: #304

• Proves the dealer knows openings for their commitment polynomial.
• Prevents unknown-opening / poisoned-aggregate attacks where a contributor publishes commitment points shaped to cancel or poison the aggregate without knowing the scalar polynomial.
• Does not prove anything about the encrypted payloads.
• A dealer can still encrypt a valid share to validator A and garbage to validator B while having a valid polynomial PoK.

Design Goal

Add verifiable encryption for DKG shares so each contribution proves that every encrypted payload decrypts to the scalar share matching the dealer's published Feldman commitments.

A valid contribution should prove, for each recipient index i:

• The ciphertext decrypts to plaintext scalar s_i.
• s_i * G = Eval(C, i), where C is the dealer's Feldman commitment polynomial.
• The proof is bound to the round, dealer, recipient, recipient index, and ciphertext context.

Option Space

Option A: Paillier-style scalar verifiable encryption

Use an encryption scheme with scalar plaintexts and a proof that the encrypted scalar matches the Feldman evaluation.

Open questions:

• Dependency and implementation complexity.
• Proof size and verification cost per recipient.
• Trusted setup or parameter requirements.
• Integration with existing Pallas-based DKG code.

Option B: Feldman commitments + DH/Poseidon scalar encryption + Halo2 proof

Use an encryption construction designed for circuit verification:

• Encrypt each scalar share with a fresh ephemeral DH secret.
• Derive a scalar mask using Poseidon or another circuit-friendly primitive.
• Ciphertext carries masked scalar payload.
• Prove in Halo2 that the ciphertext decrypts to s_i and that s_i * G = Eval(C, i).

Open questions:

• Exact transcript/domain separation.
• Circuit constraints and proving/verification cost for n-1 recipient payloads.
• Whether proofs are per-recipient or batched per dealer contribution.
• How to version/migrate from current ECIES payloads.

Non-goals / Caveats

Plain curve ElGamal over points is not sufficient by itself: it can verifiably encrypt the share point, but validators need the scalar share for threshold decryption. Recovering a full-field DKG scalar from a point would require discrete log; BSGS only works for small plaintext ranges and is unsuitable for full-field shares.

Acceptance Criteria

• A concrete protocol design is documented for verifiable DKG share encryption.
• The design explains how proofs bind to round/dealer/recipient/index/ciphertext context.
• The design compares proof size, verification cost, implementation complexity, and circuit requirements.
• The chosen design prevents a dealer from committing to one polynomial while encrypting non-matching shares to recipients.
• Tests or adversarial fixtures cover a dealer encrypting garbage to one recipient while publishing otherwise valid commitments/proofs.

[p0mvn]

Related attacks / prior work to account for in this design:

1. Addressed: degenerate / poisoned aggregate DKG keys, where individually valid Feldman commitments combine into an identity aggregate ea_pk or identity derived VK_i.

   • Fixed by Reject degenerate DKG aggregate keys #300

2. Open: corrupted encrypted DKG shares can stall the ceremony. Recipients can detect bad shares locally after decrypting and verifying against Feldman commitments, but the chain cannot verify encrypted payload correctness before accepting the contribution. This needs either verifiable encryption or a complaint / skip-set design.

3. Existing tracking issue for the corrupted-share DoS vector:

   • DKG: corrupted-share DoS vector (liveness-only, deferred) #80