Adds the NIST MPTC Class N1 + N4 submission package for Corona (R-LWE
threshold signing). Pattern mirrors luxfi/pulsar (M-LWE byte-equal
FIPS 204 path), adapted HONESTLY to Corona's lighter proof tier:
- SUBMISSION.md / NIST-SUBMISSION.md — cover sheet + 1-page exec
summary. Cite Boschini-Kaviani-Lai-Malavolta-Takahashi-Tibouchi
ePrint 2024/1113 (IEEE S&P 2025) as the underlying construction.
Construction-level N1 claim (no FIPS standard target for R-LWE
threshold — Boschini et al. IS the spec). N4 = (A, bTilde)
preserved across reshare within a key era.
- SPEC.md — standalone construction specification consolidating
existing material (papers/lp-073-pulsar/, DESIGN.md). Full
single-doc spec/corona.tex is roadmap v0.6.0.
- PATENTS.md — royalty-free patent grant + defensive termination.
Claim scope EXCLUDES the published Boschini et al. construction;
claims limited to Corona's production lifecycle additions
(Pedersen DKG over R_q, proactive resharing, activation cert
circuit-breaker, constant-time Pedersen slot equality, hash-suite
injection).
- PROOF-CLAIMS.md — HONEST framing. Corona ships NO mechanized
refinement (no EasyCrypt, no Lean, no Jasmin) — unlike Pulsar.
Correctness reduces to code review + KAT cross-runtime byte-equality
+ academic construction analysis + per-path constant-time static
audit. Mechanized refinement is roadmap v0.7.0.
- TRUSTED-COMPUTING-BASE.md — implementation TCB. Structurally
simpler than Pulsar's; no EC/Lean/Jasmin tools in scope.
- DEPLOYMENT-RUNBOOK.md — operator-facing trust-model disclosure.
- LICENSING.md / CONTRIBUTING.md / SECURITY.md — standard NIST-MPTC
artifacts.
- docs/mptc/ — submission-package docs subdir (kept separate from
docs/ Next.js docs site):
- evaluation.md, ietf-draft-skeleton.md, nist-mptc-category.md,
patent-claims.md, design-decisions.md, family-architecture.md,
threat-model.md
- scripts/{build,test,bench,gen_vectors,check-high-assurance,
cut-submission}.sh — submission gates mirroring Pulsar's
orchestrator pattern, adapted to Corona's reality (no EC/Lean/
Jasmin checks because the artifacts do not exist).
- LLM.md + CHANGELOG.md — updated with submission scaffolding
context and v0.5.0 entry. NO fabricated prior history; CHANGELOG
v0.5.0 entry covers only the actual submission documentation.
DOES NOT FABRICATE: no CRYPTOGRAPHER-SIGN-OFF (Pulsar has one;
Corona's lighter proof tier does not yet warrant it — roadmap
v0.7.0+v0.8.0). No AXIOM-INVENTORY or FIPS-TRACEABILITY (Corona is
not anchored to a FIPS standard). No proof claims Corona does not
actually have.
Build/test verification: GOWORK=off go build ./... clean; sign/,
primitives/, hash/ unit tests pass; scripts/build.sh + scripts/
check-high-assurance.sh exit 0.
3.6 KiB
Security policy
Reporting vulnerabilities
Please report cryptographic or implementation vulnerabilities privately to
[email protected] — encrypted with the team key listed at
https://lux.network/security/key.asc. Public disclosure happens after a
fix lands and downstream consumers have had a 14-day private window.
What is in-scope
Corona is production-hardened reference implementation for Ring-LWE threshold signing in Quasar consensus, and a NIST MPTC submission package. The following are in-scope for responsible disclosure:
- Specification ambiguity that leads to an exploitable verifier behaviour.
- Threshold-protocol soundness gaps (forgery, key-recovery, share extraction, rogue-key, adaptive-corruption breaks).
- Constant-time violations in code paths that touch a secret share, a Gaussian sample, or a Lagrange-aggregation intermediate.
- KAT mismatches between the Go reference and the C++ port at
~/work/luxcpp/crypto/corona/(cross-runtime byte-equality is a load-bearing invariant). - Pedersen DKG (
dkg2/) hiding-blind leakage or commitment binding failures. - Reshare-protocol (
reshare/) failures to preserve(A, bTilde)across committee rotation. - Activation-cert (
reshare/activation.go) bypass or accept-on- failure paths. - Information leaks via logging, panics on secret-correlated paths, or variable-time equality.
- Cryptanalysis of the underlying Boschini et al. ePrint 2024/1113
construction or of Corona's specific parameter set (
N = 256,q = 0x1000000004A01).
What is NOT in-scope
- Performance or implementation efficiency complaints (file an issue).
- DoS attacks against the reference implementation that don't affect the threshold-correctness invariants.
- Issues exclusively in the M-LWE sibling at
luxfi/pulsar— file there. Corona and Pulsar are independent libraries with no shared types. - Issues in lens-specific code (
lens/) — Corona's threshold path does not depend on lens. - Issues in the legacy
dkg/(Feldman VSS without blinding) — documented as broken for public broadcast; replaced bydkg2/(Pedersen DKG with hiding blinds). Production deployments usedkg2/.
CVE assignment
Corona maintainers will request CVEs for any in-scope vulnerability prior to public disclosure. CVE numbers will be embedded in the ePrint changelog and the release tag's commit message.
NIST MPTC submission disclosures
Findings discovered after the 2026-Nov-16 MPTC package submission deadline will be added to the submission's "known limitations" appendix and disclosed publicly per NIST's MPTC public-analysis process (no embargo window for findings against actively-submitted MPTC packages).
Coordinated disclosure with Pulsar
Corona and Pulsar are independent submissions but share Lux as a
common author and overlap in some operational mitigations (e.g.,
aggregator-host hardening, mlock pinning). A vulnerability that
affects both packages will be disclosed to both [email protected]
mailing lists simultaneously to enable coordinated patching.
Disclosure timeline (default)
- T+0: Private report received at [email protected].
- T+5 days: Acknowledgement + initial triage; CVE requested if in-scope.
- T+30 days: Fix landed in
main; tagged patch release; private disclosure to downstream consumers (Quasar consensus, etc.). - T+44 days: Public disclosure (advisory + CVE published).
Faster disclosure timelines apply for critical findings (immediate exploitability with no mitigation). Slower timelines apply for research-level findings requiring spec consultation with NIST MPTC reviewers.