luxfi/corona
1
0
Fork 0
mirror of https://github.com/luxfi/corona.git synced 2026-07-27 02:50:34 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
main
corona/TRUSTED-COMPUTING-BASE.md
T
zeekay df1db68bd0 docs/comments: correct lattice-family label Ring-LWE -> Module-LWE (Corona is Module-LWE) 
Corona is Module-LWE (threshold-Raccoon/Ringtail), NOT Ring-LWE. Confirmed in code: sign/sign.go samples A in R_q^{8x7} (sign.go:87 SamplePolyMatrix M=8,N=7), secret s a rank-7 ring vector, b=A*s+e (sign.go:106-107) over R_q=Z_q[X]/(X^256+1) (LogN=8), q=0x1000000004A01 -- rank>1 module structure, not rank-1 ring-LWE. threshold/threshold.go:4-5 already said Module-LWE.

Fixed the family label across README, SPEC, SUBMISSION, NIST-SUBMISSION, PATENTS, LLM, CONTRIBUTING, SECURITY, CHANGELOG, DEPLOYMENT-RUNBOOK, Makefile, AXIOM-INVENTORY, PROOF-CLAIMS, BLOCKERS, CRYPTOGRAPHER-SIGN-OFF, FIPS-TRACEABILITY, TRUSTED-COMPUTING-BASE, AUDIT-2026-05/06, docs/mptc/*, jasmin/README, 3 Go comments + cli help string.

Also corrected the downstream false claim that Corona (Ring-LWE) and Pulsar (Module-LWE) are 'different lattice families' giving 'structural/family diversity': both are Module-LWE, so the Double-Lattice defense is construction/implementation diversity (threshold-Raccoon vs ML-DSA), not hardness-family diversity; a Module-LWE break affects both legs (hash-based Magnetar is the assumption-diversifier). Fixed companion R-SIS -> Module-SIS where it was the module scheme's SIS assumption; added the Langlois-Stehle (DCC 2015) Module-LWE citation alongside LPR 2010.

Delicate artifacts: proof identifiers (rlwe_sign_op, RLWE_Functional theory/file, *_eq_rlwe bridges, CentralRLWESign, RLWESign, rlwe_compute_*) were NOT renamed -- EasyCrypt/jasmin toolchains are absent here so a rename cannot be compile-verified, and .assurance/ gates parse those names. Added clarifying naming notes to the 5 prominent .ec files, proofs/easycrypt/README.md, AXIOM-INVENTORY.md, and jasmin/rlwe/sign.jazz. .assurance/*.txt left untouched (already say Module-LWE/Module-SIS; rlwe tokens are gate-parsed identifiers). Left AUDIT-2026-06.md:463 historical rename-log and the ProtoStar-LWE paper-title substring untouched.

go build ./... and go test ./... green (GOWORK=off; all packages ok).
2026-06-27 16:12:24 -07:00

12 KiB
Raw Permalink Blame History

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)
Reference in New Issue View Git Blame Copy Permalink