Deniable authentication and witnesses

Why a sealed signature is still a signature

The released initial contains an authenticated signed transcript inside encryption. Sealing keeps the signature out of the ordinary server-visible envelope. The recipient can open it and obtain a publicly verifiable signature. Hiding that transcript from a routing service therefore does not establish deniability to a later third party.

Deniability itself needs a definition: offline transcript simulation, participation deniability and resistance to an online judge are different games. A useful statement names what the judge sees and which party’s secret state a simulator may use.

Research: authenticate with KEM confirmation

The candidate exchanges two KEM ciphertexts and confirms knowledge of their shared secrets. In the abstract model, the confirmation transcript binds both public keys, both ciphertexts and the participant roles.

1. A → B : pk_A, ct_1 = Encaps(pk_B).ciphertext
2. B → A : ct_2 = Encaps(pk_A).ciphertext, confirmation_B
3. A → B : confirmation_A

confirmation key: derived from ss_1 and ss_2
confirmed transcript: roles, pk_A, pk_B, ct_1, ct_2

The initiator’s KEM-based authentication completes at message three. The first message alone does not supply that authentication. Revision 0.1 records six symbolic authentication results; revision 0.2 adds a symbolic differential-equivalence experiment and a signed-initial distinguishing control. These are project-reported results for the candidate.

Computational deniability, concrete KEM binding, identity provisioning, maliciously generated keys and composition with the existing sealed initial remain obligations. A successful symbolic experiment is not a proof of all deniability notions, a novelty claim or a deployment result.

KEMTLS is prior work on KEM-based authentication. Keeping Up with the KEMs studies binding notions beyond ordinary KEM secrecy. K-Waay and RingXKEM’s bundled key-exchange analysis are relevant post-quantum handshake research; their models and trade-offs must be compared directly before making any priority claim.

Research: cosign a directory checkpoint

A witness can promise not to sign two conflicting roots for one epoch. Clients then accept a root with signatures from a threshold of distinct witnesses. The elementary intersection bound is:

|Q₁ ∩ Q₂| ≥ 2t − n
Guaranteed honest overlap with at most f corrupt witnesses requires:
2t − n > f

Here n is the witness count and t the acceptance threshold. This is a set-theoretic bound for two size-t quorums, plus the premise that an honest witness durably refuses conflicting signatures. It says nothing by itself about availability, freshness or discovery of a fork.

A counterexample worth keeping

For a 2-of-3 system, any two accepted quorums intersect in at least one witness. That does not guarantee an honest intersection when one witness is corrupt:

Neither honest witness signs twice. The corrupt witness signs both. Thus one corrupt cosigner is enough for this fork; showing an example with two corrupt witnesses never proved two were necessary. If both checkpoints are later compared, the two W1 signatures provide accountability under the signature/binding assumptions. That is different from preventing the fork.

A 3-of-4 threshold satisfies 2 × 3 − 4 = 2 > 1, giving honest overlap against one corrupt witness under the stated rules. It still needs durable witness state, independently controlled operators, checkpoint freshness, client comparison and an availability analysis. This page does not approve a production design from that inequality alone.