# PROOF-CLAIMS — Corona (assurance-vocabulary, HONEST)

> **What this submission proves, and — critically — what it does NOT.**
> Every claim carries one assurance-vocabulary tag that MATCHES the
> artifact's actual state. Companion to `AXIOM-INVENTORY.md` (bucketed
> axiom census), `BLOCKERS.md` (open findings),
> `TRUSTED-COMPUTING-BASE.md` (TCB), `SUBMISSION.md` (cover sheet).
>
> Read this before reading the Corona code. The framing matters as
> much as the implementation.

## §0 Assurance vocabulary (canonical) + the two load-bearing disclosures

| Tag | Meaning |
|---|---|
| **machine-checked** | A proof assistant verifies it; the named file has ZERO real `sorry`/`admit`/`:= True` tactics. The EasyCrypt toolchain **is live on the host** (opam switch `proofs`: easycrypt + why3 + alt-ergo, z3 solver) — all 14 theories compile under `easycrypt compile`, enforced every run by `security/framework/checks/ec-machine-check.sh`. (`combine_abs_op_lifted_eq_rlwe` is now a machine-checked **lemma**; its residual is the narrow public `threshold_public_commitment_eq_central`.) |
| **sound-by-reduction** | Pen-and-paper reduction to a stated assumption; not mechanized. |
| **interop-tested** | Validated against ≥2 INDEPENDENT implementations. |
| **asserted-axiom** | Taken as an axiom in EC; bucketed in AXIOM-INVENTORY.md (A/B). |
| **fail-closed-pending-review** | Implemented but gated to REFUSE until external review. |
| **open-research** | Multi-month roadmap; not done. |

**Disclosure 1 — TWO models; reconstruct-then-sign is the idealised one,
NOT the production residual (RE-SCOPED this pass).**

*Model 1 (idealised correctness).* `corona_n1_byte_equality` /
`_extracted` prove the threshold combine equals `CombineAbs.combine`, whose
body reduces — via `combine_abs_op_lifted_bridge` and
`sign_abs_op_lifted_eq_rlwe` — to `rlwe_sign_op (reconstruct quorum
shares) …`: the centralised Module-LWE signer applied to the
**Lagrange-reconstructed master secret**. The Boschini combine steps 2–6 are
opened inside `combine_body_spec`, not proved. So Model 1 is machine-checked
(0 admits) modulo a C-cone that **reconstructs-then-signs** — an idealised
*correctness* statement, NOT how production runs and NOT a leak-freeness
proof.

*Model 2 (the HONEST production residual, `Corona_N1_NoLeak.ec`).* The
production path's per-party masked responses
`z_i = R_i·u + maskPrime_i + c·λ_i·s_i − mask_i` aggregate to `R·u + c·s`
because the pairwise-PRF masks **telescope to zero** (`mask_telescope_zero`)
— the master secret is **never formed** and no per-party `c·s_i` is ever
exposed (`no_leak_z_aggregate`). The CORRECTNESS core of Model 2 is
**machine-checked in Lean 4 + Mathlib on this host** (`lake build` green, 0
sorry): `Crypto.Corona.NoLeakAggregate` (`pairwise_mask_telescopes`,
`summed_response_is_mask_free`, `secret_aggregate_no_reconstruct`,
`no_leak_under_standard_assumptions`) + `Crypto.Threshold_Lagrange`. The
ONLY open assumption is `no_leak_reduction`: under **Module-LWE +
Module-SIS** (the SAME substrate §ProofSubstrate / AXIOM-INVENTORY.md §1
already lists) the public transcript leaks nothing about `s` beyond one
single-party Boschini signature — a STANDARD PQ assumption, **not** an
implementation reconstruct. Model 2's EC side is **written, machine-recheck
pending EasyCrypt**; its Lean core is machine-checked now.

*Code-level conformance gate (added v0.10.0).* The same no-reconstruct
property is pinned at the IMPLEMENTATION level by
`threshold/no_reconstruct_sign_test.go`: (GATE A) a `go/ast` scan of every
signing/verify function proving none calls an across-party reconstruction
primitive (`reconstruct`/`interpolate`/`combineShares`/`recover*`/
`ShamirSecretSharing`/`lagrangeAtZero`) nor the trusted-dealer keygen
(`Gen`/`GenerateKeysTrustedDealer`) — per-party `party.Lambda` on the party's
OWN share is the legitimate no-reconstruct mechanism and is deliberately NOT
forbidden; the gate's teeth are negative-control-verified (injecting a
reconstruct call into `SignFinalize` trips it); (GATE B) a `reflect` gate
proving the inter-party messages `Round1Data`/`Round2Data` and the final
`Signature` carry no share/sk/seed/λ, so the aggregator never holds a second
party's secret; (GATE C) a real (3,5) no-reconstruct ceremony verifying under
the independent Corona verifier. This is a **test gate** (assurance tag:
code-review/interop-tested at the construction level), NOT a proof-assistant
artifact — it complements, and does not replace, the Lean core.

**Disclosure 2 — the no-leak property is NOT independently interop-tested.**
Corona's KAT cross-validation is **Go↔C++ of the SAME construction**
(`luxcpp/crypto/corona`), not against an independent verifier. There is no
CIRCL/pq-crystals analog for Module-LWE (no NIST target). So Corona's combine
output byte-equality is **asserted + same-construction-KAT-tested**, NOT
interop-tested in the ≥2-independent-implementations sense (unlike Pulsar's
CIRCL + pq-crystals). We therefore do NOT claim Corona byte-equality is
"proven/verified" anywhere in this document.

## §1 The narrow claim Corona makes at this submission

The strongest precise statement supported by Corona v0.4.1:

> **Construction-level interchangeability (Class N1).** Every
> signature byte string produced by the Corona threshold finalize
> procedure (`sign.Party.SignFinalize`, exposed as
> `threshold.Signer.Finalize`, which aggregates the Round-2 `z` shares)
> on inputs `(group_pk = (A, bTilde), m, ctx, quorum, shares)`
> satisfying the protocol's well-formedness invariants verifies under
> the Corona reference verifier `sign.Verify(group_pk, m, σ)` with
> outcome `OK`.

> **Public-key preservation across resharing (Class N4).** Every
> Corona Refresh or ReshareToNewSet ceremony on input `(group_pk =
> (A, bTilde), old_shares, old_committee, new_committee)` satisfying
> the protocol's honest-majority assumption produces `new_shares`
> such that any subsequent threshold signing under those new shares
> verifies under the **byte-identical unchanged** `group_pk`.

**Formal-statement status**: these are stated in prose, validated by
test, and inherited from the Boschini et al. ePrint 2024/1113 §3
analysis for the underlying construction. They are **NOT mechanized**
in EasyCrypt, Lean, Jasmin, or any other proof assistant at this
submission. See §3 below for the explicit non-claims list.

## §2 What IS provided

| Aspect | Status | Source |
|---|---|---|
| Implementation matches the Boschini et al. ePrint 2024/1113 construction | ✓ by code review + KAT cross-validation | `sign/`, `threshold/`, `primitives/` |
| Class N1 (construction-level output verifies under same verifier) | ✓ by test (no mechanized refinement) | `sign/sign_test.go`, `sign/sign_roundtrip_test.go`, `threshold/threshold_test.go` |
| Class N4 (reshare preserves `(A, bTilde)`) | ✓ by test (45+ tests in `reshare/`, integration tests assert byte-equal `(A, bTilde)` post-reshare) | `reshare/full_integration_test.go`, `reshare/refresh_test.go`, `reshare/reshare_test.go` |
| Constant-time on threshold + dkg2 verification paths | ✓ by per-path static audit | `CONSTANT-TIME-REVIEW.md` |
| KAT cross-runtime byte-equality (Go ↔ C++ luxcpp port) | ✓ by manifest enforcement | `scripts/regen-kats.sh --verify` + `scripts/regen-kats.manifest.sha256` |
| Fuzz coverage on round-based protocols | ✓ harnesses wired (operational fuzz budgets are deployment-level) | `reshare/fuzz_*_test.go`, `dkg2/fuzz_round_test.go`, `threshold/fuzz_round_test.go` |
| Hash-suite injection for Corona-SHA3 production profile | ✓ by code (F22 closure) | `hash/sp800_185.go`, `primitives/hash.go` |
| Identifiable-abort evidence | ✓ by test | `reshare/complaint_test.go`, `dkg2/complaint.go` |
| Activation cert as circuit-breaker | ✓ by test (verifies under unchanged GroupKey) | `reshare/activation_test.go` |

## §3 What is NOT proved (HONEST)

This section is the load-bearing honesty disclosure. Read it.

### §3.1 v0.7.0: EC + Lean + Jasmin scaffolding LANDED — but the EC byte-equality is reconstruct-then-sign (asserted-axiom cone)

**Assurance: machine-checked structure (0 admits) MODULO the C-cone of
asserted axioms (reconstruct-then-sign).** The 13 EC theories are
structurally complete, but `corona_n1_byte_equality` rests on the open
bucket-C axioms in `AXIOM-INVENTORY.md` §C (the `combine_body_spec`
byte-walk with Boschini steps 2–6 inside it, and the
`combine_abs_op_lifted_bridge` / `sign_abs_op_lifted_eq_rlwe` wrapper
bridges that pin the lifted op to `rlwe_sign_op` on the **reconstructed**
secret). See §0 Disclosure 1.

**v0.7.0 update**: Corona now ships:
- **13 EasyCrypt theories** compiling clean with admit budget **0/0**
  (`proofs/easycrypt/Corona_N1.ec` + `Corona_N4.ec` + Layout +
  Refinement + Wrapper + Extracted + `lemmas/RLWE_Functional.ec` +
  `lemmas/Corona_CT.ec`).
- **5 Lean <-> EC bridges** (Shamir, OutputInterchange,
  Unforgeability, dkg2 -- see `proofs/lean-easycrypt-bridge.md`).
- **3 Jasmin threshold-layer sources** (round1.jazz, round2.jazz,
  combine.jazz) with `#ct` annotations + 1 centralized rlwe/sign.jazz
  reference + a `lib/` of shared primitives.
- **dudect harness** at `ct/dudect/` for Verify + Combine.
- **CI orchestrator** `scripts/check-high-assurance.sh` with 7 per-push
  gates (mirroring Pulsar's exactly).

**What's still operational** (roadmap v0.8.0):
- Jasmin extraction filling out the byte-walk refinement obligations
  in `Corona_N1_{Combine,Sign}_Refinement.ec`.
- dudect submission-grade 10^9-sample runs on pinned hardware.
- External cryptographic audit engagement.

The implementation-backed N1 byte-equality theorem to cite is
`Corona_N1_Extracted.corona_n1_byte_equality_extracted`.

Module-LWE threshold signing has no NIST standard target. The Boschini
et al. ePrint 2024/1113 construction IS the spec; the EC theories
refine the Go implementation against the in-house mechanization of
that spec (`lemmas/RLWE_Functional.ec`), which is the analog of
Pulsar's libjade dependence on FIPS 204.

### §3.2 NOT proved: lattice-hardness of Module-LWE

This submission says nothing about the post-quantum hardness of
Module-LWE itself. Module-LWE security rests on Lyubashevsky-Peikert-Regev
(2010), the Langlois-Stehlé (2015) module generalisation, and follow-up
cryptanalytic analysis. The parameter set
(`N = 256`, `q = 0x1000000004A01`, 48-bit prime) was chosen to
provide ≥ 128 bits of post-quantum security per lattice-estimator
methodology — but Corona ships no parameter-set worksheet at this
revision; that is roadmap item v0.6.0.

**The defensible PQ-safety claim**:
> Corona implements a published academic Module-LWE threshold signature
> construction (Boschini et al. ePrint 2024/1113) on a parameter
> set chosen to provide ≥ 128 bits of post-quantum security against
> known Module-LWE attacks per the lattice-estimator methodology of
> Albrecht-Player-Scott. The construction's EUF-CMA reduction is in
> the cited paper.

**NOT defensible**:
> Corona is proved post-quantum secure.

### §3.3 NOT proved: byte-equality with FIPS 204 ML-DSA

Corona signatures are NOT byte-equal to FIPS 204 ML-DSA signatures.
The two constructions are different schemes within the Module-LWE
family (Corona is the Raccoon/Ringtail line; ML-DSA is the Dilithium
line), with different moduli, module dimensions, and parameter sets.
Any reviewer expecting FIPS 204 byte-equality
should look at the Pulsar sibling at `~/work/lux/pulsar/`.

### §3.4 NOT proved: statistical constant-time validation (dudect)

`CONSTANT-TIME-REVIEW.md` documents a per-path static audit with
zero `(c)` (must-fix) findings. **It does NOT include statistical
validation via dudect-style timing measurements.** A dudect-style
harness is roadmap item v0.8.0; at submission scaffolding time the
constant-time evidence is the static audit + the upstream lattigo
constant-time claims.

### §3.5 NOT proved: implementation-side covert-channel safety

The static constant-time audit does NOT address:
- Memory-access leakage (cache-timing side channels)
- Power side-channels
- EM side-channels
- Fault attacks
- Microarchitectural leakage (Spectre / Meltdown class)
- Statistical timing under realistic deployment conditions

Production deployments MUST follow the hardening checklist in
`DEPLOYMENT-RUNBOOK.md` (mlock pinning, core-dump disable, ptrace
disable, dedicated host, etc.).

### §3.6 NOT proved: protocol-level adversarial robustness

The construction-level claim in §1 is **honest-quorum correctness**.
It says: "when all parties follow the protocol, the output verifies
and resharing preserves the group key." It does NOT prove:

- **Unforgeability** under adaptive corruption — inherited (with
  caveats) from Boschini et al. §3; no Corona-specific mechanization.
- **Identifiable abort** under network partition — synchronous network
  assumptions hold; async abort is out of scope.
- **Robust completion** under `f < t/2` Byzantine parties.
- **DKG soundness** under adversarial dealer — Pedersen DKG (`dkg2/`)
  provides hiding and binding under standard assumptions; full
  reduction is in the LP-073 paper but not mechanized here.

### §3.7 v0.7.0: 5 Lean-bridged algebraic axioms LANDED (was: NOT proved)

**v0.7.0 update**: Corona now has 5 Lean-bridged algebraic axioms,
in 1:1 correspondence with Pulsar's:

| Corona EC axiom | Lean theorem |
|---|---|
| `lagrange_inverse_eval` (Corona_N1.ec) | `Crypto.Corona.Shamir.shamir_correct_at_target` |
| `threshold_partial_response_identity` (Corona_N1.ec) | `Crypto.Threshold.Lagrange.threshold_partial_response_identity` |
| `add_share_zeroR` (Corona_N4.ec) | Mathlib `AddCommMonoid` instance |
| `reconstruct_linear` (Corona_N4.ec) | `Crypto.Threshold.Lagrange.combine_distributes_over_sum` |
| `shamir_correct` (Corona_N4.ec) | `Crypto.Corona.Shamir.shamir_correct_at_target` |

The bridge document is `proofs/lean-easycrypt-bridge.md`. The CI
guard `scripts/check-lean-bridge.sh` verifies every EC axiom has the
required citation comment + that the cited Lean theorem still exists
in the named Lean file.

## §4 Refinement chain (what's connected to what)

```
Go implementation (sign/, threshold/, dkg2/, reshare/, primitives/, hash/)
       implements (by code review + KAT)
Boschini et al. ePrint 2024/1113 §3 algorithmic spec
  + Corona production-lifecycle additions in SPEC.md §§6, 9, 10, 13
       conforms to (by inspection)
DESIGN.md invariants ("what is preserved across resharing")
```

Each "implements" / "conforms" relation is by **inspection and
test**, NOT machine-checked. Compare to Pulsar's refinement chain, which
is machine-checked (0-admit) at the EC level **but only modulo the same
reconstruct-then-sign asserted-axiom cone** — Pulsar's EC byte-equality is
also relative to `combine_body_axiom` / `S_functional_spec` (its
`AXIOM-INVENTORY.md` §C). The honest difference is degree of
*decomposition* (Pulsar splits the byte-walk into ~10 narrow per-stage
sub-axioms; Corona keeps one `combine_body_spec`) and *interop*: Pulsar's
final signature is interop-tested vs CIRCL + pq-crystals, Corona's is
same-construction Go↔C++ KAT only (§0 Disclosure 2).

## §5 What an auditor verifying this submission should do

1. **Read** the `SUBMISSION.md` cover sheet for context.
2. **Read** this document (`PROOF-CLAIMS.md`) for what's proved vs not.
3. **Read** `TRUSTED-COMPUTING-BASE.md` for the implementation TCB.
4. **Read** `CONSTANT-TIME-REVIEW.md` for the per-path CT audit.
5. **Read** Boschini et al. ePrint 2024/1113 for the underlying
   construction analysis (academic prior art).
6. **Run** `scripts/test.sh` — expect Go unit + integration + KAT
   tests all green.
7. **Run** `scripts/gen_vectors.sh && scripts/regen-kats.sh --verify`
   — expect byte-equal KAT manifest agreement.
8. **Read** the Go reference implementation: `sign/sign.go`,
   `threshold/threshold.go`, `dkg2/dkg2.go`, `reshare/reshare.go`,
   `reshare/activation.go`, `primitives/hash.go`, `hash/sp800_185.go`.
9. **Run** `scripts/bench.sh` — expect performance numbers within
   `docs/evaluation.md` published bounds.

## §6 The honest one-paragraph version

> Corona's submission package establishes that the Go reference
> implementation faithfully implements the Boschini, Kaviani, Lai,
> Malavolta, Takahashi, and Tibouchi 2-round Module-LWE threshold
> signature construction (IACR ePrint 2024/1113, IEEE S&P 2025) on a
> fixed parameter set, plus production lifecycle additions (Pedersen
> DKG over `R_q`, proactive resharing with Refresh + ReshareToNewSet
> primitives, identifiable abort, activation certs as the
> resharing circuit-breaker, KAT-deterministic Corona-SHA3 hash
> suite). Unlike the Pulsar sibling submission (which ships a
> mechanized EasyCrypt + Lean + Jasmin refinement chain against
> FIPS 204), Corona ships NO machine-checked refinement at this
> submission — Module-LWE has no NIST standard target, the construction
> IS the spec, and mechanizing the construction itself is a multi-
> month research roadmap item. Corona's correctness evidence
> reduces to code review of the Go reference against the published
> construction, KAT cross-validation (Go ↔ C++ byte-equality
> manifest), the per-path constant-time static audit in
> `CONSTANT-TIME-REVIEW.md` (zero must-fix findings), fuzz harness
> coverage, and the academic security analysis in the cited paper.
> The proof tier is intentionally less mature than Pulsar's; the
> roadmap items in `NIST-SUBMISSION.md` lay out the multi-version
> path to mechanized refinement.

## §7 Roadmap (multi-version closure path)

| Milestone | Target version | Status |
|---|---|---|
| Single-document `spec/corona.tex` consolidating LaTeX | v0.6.0 | shipped |
| EasyCrypt theory shell for the construction-level interchangeability claim | v0.7.0 | **shipped (13 files, admit 0/0)** |
| Lean 4 / Mathlib mechanization of Lagrange-aggregation over `R_q` | v0.7.0 | **shipped (5 Lean-bridged axioms)** |
| Jasmin sources + jasmin-ct CT gates on the threshold layer | v0.7.0 | **shipped (3 threshold + 1 rlwe + lib/)** |
| dudect harness wired (smoke-budget) | v0.7.0 | **shipped (Verify + Combine)** |
| dudect submission-grade 10^9-sample runs on pinned hardware | v0.8.0 | roadmap |
| External cryptographic audit (engaged lab) | v0.8.0 | roadmap |
| Parameter-set worksheet (lattice-estimator concrete bounds) | v0.6.0 | shipped |
| Jasmin extraction filling out byte-walk refinement | v0.8.0 | roadmap |

The closure path is real but long. The honest framing at this
submission: production-hardened implementation of a published
academic construction, with production lifecycle additions, NOT
machine-checked refinement of a NIST standard.

---

**Document metadata**

- Name: `PROOF-CLAIMS.md`
- Version: v0.2 (v0.7.0 EC + Lean + Jasmin scaffold landed)
- Date: 2026-05-18