Files
corona/NIST-SUBMISSION.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

9.6 KiB
Raw Blame History

NIST MPTC Submission — Corona (one-page executive summary)

Executive summary of the Corona package for the NIST Multi-Party Threshold Cryptography (MPTC) project. The full cover sheet is in SUBMISSION.md; the package contents map is below.

Submission metadata

Field Value
Submission name Corona
Submitting organisation Lux Industries, Inc.
Algorithm Threshold Module-LWE 2-round signing + Pedersen DKG + proactive resharing
MPTC classes N1 (construction-level threshold signing) + N4 (multi-party key generation with public-key preservation across resharing)
Underlying construction Boschini, Kaviani, Lai, Malavolta, Takahashi, Tibouchi. Practical two-round threshold signatures from learning with errors. IACR ePrint 2024/1113, IEEE S&P 2025
Lattice family Module-LWE over R_q = Z_q[X]/(X^N + 1), N = 256, module dims M = 8 × N = 7, q = 0x1000000004A01 (48-bit NTT-friendly prime)
Round count 2 rounds per signature
Hash suite Corona-SHA3 (cSHAKE256 / KMAC256 / TupleHash256, FIPS 202 + SP 800-185)
Repository https://github.com/luxfi/corona
Submission tag submission-2026-11-16 (planned)
Latest tagged release v0.4.1 (next: v0.5.0 accompanying the submission package)
License Apache-2.0 (code) + CC-BY-4.0 (PATENTS.md)

Headline claim

Every signature produced by a Corona threshold ceremony (DKG → Round-1 → Round-2 → Combine) verifies under the Corona verifier (sign.Verify) on the same message and group public key (A, bTilde) as a single-party Corona run would. The group public key is preserved bit-identically across proactive resharing events within a key era (Class N4 invariant).

Theorem framing: construction-level interchangeability. Corona implements the published Boschini et al. 2-round Module-LWE threshold signature scheme (IACR ePrint 2024/1113) on a fixed parameter set; Corona's contribution beyond the academic paper is the production lifecycle (Pedersen DKG over R_q, proactive resharing, identifiable abort, activation certs, KAT-deterministic Corona-SHA3 hash suite).

Verifier-side reality. Module-LWE threshold signatures have no NIST standard at submission time. The Boschini et al. construction verifier is the spec. Corona's sign.Verify is the canonical implementation of that verifier; there is no third-party FIPS-validated Module-LWE verifier to cross-check against. This is the honest framing distinction from Pulsar (M-LWE / FIPS 204), which DOES cross-check against BoringSSL FIPS / AWS-LC / OpenSSL 3.0 PQ.

Package contents (mapped to NIST IR 8214C requirements)

NIST requirement Corona artifact
Technical specification SPEC.md + papers/lp-073-pulsar/ LaTeX sections + DESIGN.md
Open-source reference implementation sign/ + threshold/ + dkg2/ + reshare/ + primitives/ + hash/ (Apache-2.0)
Experimental evaluation report docs/evaluation.md
Test vectors cmd/{reshare,dkg2,activation,cross_runtime}_oracle*/, manifest at scripts/regen-kats.manifest.sha256
Security analysis SPEC.md §15 + Boschini et al. ePrint 2024/1113 §§34
Patent / IP statement PATENTS.md (royalty-free grant) + docs/patent-claims.md (attorney prep)
Known limitations SUBMISSION.md §"Does NOT claim" + DESIGN.md §"What this isn't"
Contact / maintainers SUBMISSION.md §Contact

What makes this submission different

  1. Production-hardened Module-LWE threshold — beyond the Boschini et al. academic construction, Corona adds Pedersen DKG over R_q (dkg2/), proactive resharing with two distinct primitives (Refresh for same-set; ReshareToNewSet for set rotation), identifiable-abort evidence pipeline, and activation certificates (the circuit-breaker that gates new-epoch acceptance).

  2. KAT-deterministic Corona-SHA3 profile — every Sign-path primitive takes a hash.HashSuite argument. Production deployments use cSHAKE256 / KMAC256 / TupleHash256 per FIPS 202 + SP 800-185. The legacy BLAKE3 suite remains available for cross-port byte checks.

  3. Cross-runtime byte-equality — Go reference at sign/ + threshold/; C++ port at ~/work/luxcpp/crypto/corona/. KAT manifest (scripts/regen-kats.manifest.sha256) enforces byte-equal round-trip via scripts/regen-kats.sh --verify.

  4. Constant-time audit completeCONSTANT-TIME-REVIEW.md shows zero (c) (must-fix) entries. Two (b) entries are documented with mitigations (one closed in dkg2/; one in lens-specific secp256k1 paths not on the Corona threshold path).

  5. Reproducibility-firstscripts/build.sh, scripts/test.sh, scripts/gen_vectors.sh are deterministic. KAT regeneration is byte-equal across runs; CI enforces drift = build bug.

  6. Honest gap disclosure — Corona does NOT ship a mechanized refinement proof. See PROOF-CLAIMS.md for the narrow claim and the roadmap. The honest framing: production-hardened implementation of a published academic construction, not machine-checked refinement of a NIST standard.

Trust footprint (one-screen summary)

After Corona v0.4.1:

Category Count / Status
EasyCrypt files 0 (no mechanized refinement — see PROOF-CLAIMS.md)
Lean ↔ EC bridge files 0
Jasmin source files 0 (libjade does not target Corona parameter set)
Go reference test coverage sign + threshold + dkg2 + reshare + primitives + hash — 45+ tests in reshare/, 10+ in dkg2/, comprehensive sign roundtrip + threshold tests
Fuzz harnesses reshare/fuzz_*_test.go, dkg2/fuzz_round_test.go, threshold/fuzz_round_test.go
KAT cross-runtime byte-equality enforced by scripts/regen-kats.sh + regen-kats.manifest.sha256
Constant-time audit CONSTANT-TIME-REVIEW.md — 0 (c), 2 (b) mitigated

The trust base for Corona at submission time reduces to:

  • The Boschini et al. ePrint 2024/1113 construction analysis (academic prior art).
  • The Go reference implementation correctness (reviewed by code + KATs + fuzz).
  • The luxfi/lattice/v7 (lattigo fork) NTT / Montgomery / Gaussian sampler primitives — documented constant-time per upstream.
  • The crypto/subtle standard library constant-time helpers.
  • The Go toolchain.

What this submission does NOT claim

Out-of-scope claim Why
Byte-equality with FIPS 204 ML-DSA That is Pulsar's claim. Both are Module-LWE, but Corona is the Raccoon/Ringtail-line threshold, not FIPS-204 ML-DSA.
Mechanized refinement proof Multi-month research project. No FIPS standard target exists for Module-LWE threshold. See PROOF-CLAIMS.md.
Post-quantum hardness of Module-LWE Assumed from Lyubashevsky-Peikert-Regev (2010), the Langlois-Stehlé (2015) module generalisation, and follow-up analysis.
ACVP/CAVP algorithm validation certificate Not applicable — NIST has no ACVP test vector set for Module-LWE threshold.
FIPS 140-3 module validation Downstream — applies to packaged modules.
Asynchronous identifiable abort Synchronous only.
1-round signing Construction is 2-round by design (Boschini et al.).
DKG without external randomness beacon Honest-majority unbiased; production binds a beacon at the consensus layer.

Reproducibility commitment

git clone --branch submission-2026-11-16 https://github.com/luxfi/corona
cd corona
scripts/build.sh                # builds reference impl
scripts/test.sh                 # runs unit + KAT + integration tests
scripts/bench.sh                # performance (expect within 5% of REPORT.md)
scripts/gen_vectors.sh          # regenerate KAT vectors deterministically

Drift between submission tarball and reproduced output is a build bug — please file at the GitHub issues link above. NIST reviewers should obtain byte-identical artifacts on reproduction.

Patent / IP posture (TL;DR)

  • Code: Apache-2.0.
  • Patents: Royalty-free grant to any implementation of the Corona construction released under Apache-2.0 or compatible OSI license, OR any NIST MPTC/PQC/ACVP submission/validation/interoperability test.
  • Defensive termination: license terminates against any party asserting patents against Corona, the underlying Boschini et al. construction, FIPS 204 ML-DSA, or any other NIST-standardized PQ signature scheme.
  • Full text: PATENTS.md §3.

Contact

Purpose Contact
Submission coordination mptc@lux.network
Patent / IP inquiries legal@lux.network
Security disclosure See SECURITY.md
Public discussion https://github.com/luxfi/corona/discussions
Primary maintainer z@lux.network (Lux Industries, Inc.)

Roadmap (v0.5 and beyond)

Milestone Target
Submission package scaffolding (this revision) v0.5.0
Single-document spec/corona.tex consolidating SPEC.md + paper sections v0.6.0
EasyCrypt theory shell for the construction-level interchangeability claim v0.7.0 (research)
Lean 4 / Mathlib mechanization of the Lagrange-aggregation identity over R_q v0.7.0 (research)
External cryptographic audit (engaged lab) v0.8.0
dudect-style statistical CT validation harness v0.8.0
Production deployment runbook hardening continuous

The roadmap is published at SUBMISSION.md "What this submission does NOT claim" + tracked at the GitHub issues link above.


Document metadata

  • Name: NIST-SUBMISSION.md
  • Version: v0.1 (initial submission-package scaffolding)
  • Date: 2026-05-18
  • Submission package version: Corona v0.2 (tagged submission-2026-11-16 on cut date)