zeekay
df1db68bd0
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).
3.6 KiB
Security policy
Reporting vulnerabilities
Please report cryptographic or implementation vulnerabilities privately to
security@lux.network — 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 Module-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 security@lux.network
mailing lists simultaneously to enable coordinated patching.
Disclosure timeline (default)
- T+0: Private report received at security@lux.network.
- 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.