corona/TRUSTED-COMPUTING-BASE.md

# TRUSTED-COMPUTING-BASE — Corona implementation TCB

> **What you must trust to rely on Corona's construction-level
> correctness claim.** Companion to `PROOF-CLAIMS.md` (proof scope)
> and `CONSTANT-TIME-REVIEW.md` (per-path CT audit).
>
> **HONESTY NOTE**: Corona's TCB is structurally simpler than Pulsar's
> because Corona ships NO mechanized refinement layer (no EasyCrypt,
> no Lean, no Jasmin). That removes those tools from the TCB but
> increases the trust placed in the Go reference implementation
> review, KAT cross-validation, and the academic Boschini et al.
> construction analysis. See `PROOF-CLAIMS.md` for the honest framing.

## §0 Layered trust bases

The Corona construction-level claim rests on three layered trust
bases:

1. **The academic construction** — Boschini, Kaviani, Lai, Malavolta,
   Takahashi, Tibouchi. *Practical two-round threshold signatures
   from learning with errors.* IACR ePrint 2024/1113, IEEE S&P 2025.
   This is the spec.
2. **The Go reference implementation** — `sign/`, `threshold/`,
   `dkg2/`, `reshare/`, `primitives/`, `hash/`. Reviewed by code
   inspection + KAT cross-validation + fuzz.
3. **The trusted-computing base (TCB) below the implementation** —
   this document.

If any element of the TCB is unsound, the implementation's correctness
is unsound regardless of how clean the code review was.

## §1 Implementation TCBs

### §1.1 Reference implementation (Go)

| Component | Trust | Mitigations |
|---|---|---|
| Corona Go reference (this repository) | Standard library correctness, `crypto/rand` randomness quality, lattigo NTT/Montgomery/Gaussian-sampler primitives | Reviewed by code inspection; KAT cross-validation Go ↔ C++ (luxcpp port); fuzz harnesses on round-based protocols |
| `github.com/luxfi/lattice/v7` (lattigo fork) | Upstream `tuneinsight/lattigo/v7` NTT, Montgomery reduction, discrete-Gaussian sampler. Documented constant-time per upstream README; relevant routines are byte-stable. | Version pinned in `go.mod`. The fork carries Lux-specific extensions for hash-suite injection but the cryptographic kernels are unchanged from upstream. |
| `github.com/luxfi/math/codec` | LP-107 Phase 4 wire codec. Validates `Vector[Poly]` frame before lattigo `ReadFrom`. | Version pinned in `go.mod`. |
| `golang.org/x/crypto/sha3` | cSHAKE256, KMAC256, TupleHash256 primitives (Go-stdlib-style). | Version pinned in `go.mod`. |
| `crypto/subtle` | Constant-time byte-blob compare. Standard library. | Standard library; bundled with the Go toolchain. |
| `github.com/zeebo/blake3` | Legacy BLAKE3 hash suite (cross-port byte-check only; NOT the normative production profile). | Version pinned in `go.mod`. Legacy use only. |

### §1.2 Production targets (out of scope for v0.2)

| Target | Status |
|---|---|
| Optimized Rust crate | TODO — not in this submission |
| C library + FFI | C++ port at `~/work/luxcpp/crypto/corona/` is the de-facto C-ABI; clean C wrapper TODO |
| WASM build | TODO |
| no_std embedded | TODO |

For each future target, an independent constant-time audit + KAT
cross-validation + binding-level fuzzing is required before
considering it "production." The construction-level correctness
claim does NOT automatically transfer to these targets — each
target's correctness must be re-verified.

## §2 Build TCBs

| Layer | What you trust | Reproducibility |
|---|---|---|
| **Go toolchain** | The Go compiler used to build the reference. Version pinned to `go 1.26.4` in `go.mod`. | Hard-pinned in `go.mod`; `go.sum` enforces module checksums. |
| **`scripts/build.sh`** | The build orchestrator's correctness — that it produces deterministic outputs from a fresh checkout. | CI runs the script on every commit. |
| **`scripts/test.sh`** | The test harness's correctness — that KAT vectors compare bit-by-bit, not just lex-equal. | Reviewed; uses `bytes.Equal` for byte-level KAT comparison. |
| **`scripts/gen_vectors.sh`** | Deterministic regeneration of KAT vectors. | Wraps `scripts/regen-kats.sh`; the manifest at `scripts/regen-kats.manifest.sha256` pins SHA-256 of every regenerated file. |
| **`scripts/regen-kats.sh --verify`** | Cross-runtime byte-equality enforcement (Go ↔ C++). | Manifest is regenerated and compared; diff = build bug. |

## §3 What the TCB does NOT include

Corona's TCB is **structurally simpler** than Pulsar's because Corona
ships no mechanized refinement layer. The following are NOT in the
Corona TCB:

- **EasyCrypt prover** (Pulsar trusts it; Corona has no EC theories)
- **Lean 4 + Mathlib** (Pulsar uses Lean-bridged algebraic axioms;
  Corona has none)
- **Jasmin verified compiler** (Pulsar's threshold layer is in Jasmin;
  Corona is pure Go)
- **OCaml runtime** (EC is OCaml; Corona has no EC)
- **jasmin-ct** (Corona's CT evidence is static per-path audit, not
  jasmin-ct analysis)

What IS in the Corona TCB but NOT in Pulsar's:

- **Greater dependence on Go reference review.** Pulsar can fall
  back to the EC refinement chain if a Go reviewer misses a bug;
  Corona's only line of defense is reviewer + KAT + fuzz.
- **Greater dependence on the academic Boschini et al. paper.**
  Pulsar's spec target (FIPS 204) is an extensively-cryptanalyzed
  NIST standard; Corona's spec target is a 2024 academic paper with
  less cryptanalytic surface area at this writing.

## §4 What the TCB does NOT cover

These are explicitly NOT part of the trust base for Corona's
construction-level correctness claim:

- **Specific operating system** (Linux, macOS, BSD, Windows) — the
  Go reference is OS-independent.
- **Specific CPU architecture** — Go compiles to amd64/arm64; both
  exercised in CI.
- **Network protocol stack** — Corona's transport is out of scope.
- **Storage layer** — how `sk` shares are stored at rest is out of
  scope. Production deployments use HSM-backed share material; see
  `DEPLOYMENT-RUNBOOK.md`.
- **Key management policies** — key lifecycle is application-level
  (governed by the consuming consensus layer, e.g. Quasar).
- **Application code calling Corona** — Corona's API contract is the
  trust boundary.

## §5 TCB risks and mitigations

### §5.1 Construction-soundness risk

| Risk | Mitigation |
|---|---|
| The Boschini et al. ePrint 2024/1113 EUF-CMA reduction has a latent bug | Construction has been published and reviewed by the cryptographic community via IEEE S&P 2025 + IACR ePrint discussion. Lux tracks cryptanalysis literature; any flaw would prompt a parameter-set re-tune and a new key-era. Patent-bump policy and `DESIGN.md` "Reanchor" capability allow operational response. |
| Corona's production lifecycle additions (Pedersen DKG, reshare, activation cert) have a latent bug | Per-path tests in `dkg2/`, `reshare/` (45+ tests including `full_integration_test.go`). Independent third-party audit is roadmap item v0.8.0. |

### §5.2 Implementation-correctness risk

| Risk | Mitigation |
|---|---|
| Go reference implementation diverges from the construction | KAT cross-validation Go ↔ C++ (`scripts/regen-kats.sh --verify`); the C++ port is independently implemented from the same spec by a different engineer. Divergence = test failure. |
| KAT vectors are subtly wrong | Deterministic generation from fixed seeds; `cross_runtime_oracle/` and `cross_runtime_verify/` enforce Go ↔ C++ byte-equality. Both implementations would have to be wrong in the same way to escape this check. |
| Hash-suite implementation bug (cSHAKE256 / KMAC256 / TupleHash256) | `golang.org/x/crypto/sha3` is a widely-used standard library implementation; bugs are rare and quickly patched. NIST SP 800-185 KAT verification in `hash/hash_test.go` (`TestKMAC256NISTVector`, `TestTupleHash256NISTVector`). |

### §5.3 Build / reproducibility risk

| Risk | Mitigation |
|---|---|
| `scripts/build.sh` produces non-deterministic output | The build is deterministic from fixed seeds; reproducible-build property is checked on CI. Drift triggers a CI failure. |
| Toolchain version drift between commits | `go.mod` pin + `go.sum` enforcement. |
| KAT manifest drift across runs | `scripts/regen-kats.manifest.sha256` is the gate; `--verify` mode compares manifest hashes. |

### §5.4 Side-channel risk

| Risk | Mitigation |
|---|---|
| Timing leakage on secret-dependent paths | Static per-path audit in `CONSTANT-TIME-REVIEW.md` — zero `(c)` (must-fix) findings; two `(b)` entries with documented mitigations (one closed in `dkg2/`; one in lens-specific paths off the Corona threshold path). |
| Statistical timing leakage (dudect-style) | Roadmap item v0.8.0. Not validated at this submission. |
| Memory-access / cache-timing leakage | Not addressed. Production deployments should use TEE attestation (SGX, SEV-SNP, TDX) per `DEPLOYMENT-RUNBOOK.md`. |

## §6 Independent verification protocol

To independently verify Corona's claims, a reviewer should:

1. Clone the repo at the submission tag.
2. `scripts/build.sh` — expect deterministic output.
3. `scripts/test.sh` — expect KAT + integration + unit tests all green.
4. `scripts/gen_vectors.sh && scripts/regen-kats.sh --verify` — expect
   byte-equal KAT manifest agreement.
5. `scripts/bench.sh` — expect performance within `docs/evaluation.md`
   published bounds.
6. Read the Go reference implementation:
   - `sign/sign.go` — single-party + threshold signing kernel
   - `threshold/threshold.go` — threshold orchestration
   - `dkg2/dkg2.go` — Pedersen DKG over `R_q`
   - `reshare/reshare.go` + `reshare/activation.go` — proactive
     resharing + activation cert
   - `primitives/hash.go` + `hash/sp800_185.go` — Corona-SHA3 hash
     suite
7. Cross-reference with Boschini et al. ePrint 2024/1113 §3 for the
   2-round signing construction.
8. Cross-reference with `papers/lp-073-pulsar/` for the production
   lifecycle additions (Pedersen DKG, resharing).

If all 8 steps pass, the trust base reduces to the TCB enumerated
in this document.

## §7 What this means for downstream consumers

For a downstream consumer (e.g., a Quasar consensus chain
incorporating Corona):

- **The construction-level claim is conditional on the TCB.** If
  you change the Go toolchain, port to a different runtime, or
  modify the hash suite, the claim's transferable guarantees
  attenuate.
- **For FIPS 140-3 module validation**, Corona is NOT a candidate
  — Module-LWE threshold has no NIST standard, so no FIPS 140-3 module
  can claim FIPS 204-style algorithm validation for it. For
  FIPS-validation pathways, use Pulsar (M-LWE / FIPS 204) instead.
- **For NIST MPTC review**, Corona's role is the algorithm-level
  reference + production lifecycle artifacts; module packaging +
  external audit are downstream.
- **For threshold signing in a Quasar deployment**, Corona is the
  Module-LWE kernel; the consuming consensus layer is responsible for
  the chain-of-custody and validator-rotation orchestration (the
  LSS adapter at `~/work/lux/threshold/protocols/lss/lss_pulsar.go`
  is the canonical orchestrator).

## §8 Honest comparison to Pulsar's TCB

| TCB element | Pulsar | Corona |
|---|---|---|
| EasyCrypt prover | YES (foundation of refinement proof) | NO (no EC theories) |
| Lean 4 + Mathlib | YES (5 Lean-bridged axioms) | NO |
| Jasmin verified compiler | YES (threshold layer in Jasmin) | NO (pure Go) |
| OCaml runtime | YES (EC is OCaml) | NO |
| Go toolchain | YES (Go reference) | YES (Go reference; primary) |
| lattigo / `luxfi/lattice/v7` | NO (Jasmin path) | YES (Module-LWE primitives) |
| `crypto/subtle` | YES (Go reference path) | YES (primary CT helper) |
| `golang.org/x/crypto/sha3` | YES | YES |
| Academic construction paper | FIPS 204 (NIST standard) | Boschini et al. ePrint 2024/1113 (2024 academic) |
| Third-party FIPS-validated verifier | YES (BoringSSL FIPS / AWS-LC / OpenSSL 3.0) | NO (none exists for Module-LWE threshold) |

**Net effect**: Corona's TCB is smaller (fewer proof-tool
dependencies) but the trust per-component is higher (no fall-back
to a mechanized refinement chain if a Go reviewer misses a bug).

---

**Document metadata**

- Name: `TRUSTED-COMPUTING-BASE.md`
- Version: v0.1 (initial submission-package scaffolding)
- Date: 2026-05-18
- Go toolchain pin: `go 1.26.4` (per `go.mod`)
- `luxfi/lattice/v7` pin: `v7.1.0` (per `go.mod`)