diff --git a/AUDIT-2026-05.md b/AUDIT-2026-05.md index 36036f7..0bd6cad 100644 --- a/AUDIT-2026-05.md +++ b/AUDIT-2026-05.md @@ -102,7 +102,7 @@ former. ## 2. SOTA refresh — is Boschini 2024/1113 still current? **Yes.** Boschini-Takahashi-Tibouchi 2024/1113 ("Threshold Raccoon" -/ BTT24) remains the canonical 2-round non-interactive R-LWE +/ BTT24) remains the canonical 2-round non-interactive Module-LWE threshold signature. No 2025 paper supersedes it as the production construction. Subsequent work refines specific aspects: diff --git a/AUDIT-2026-06.md b/AUDIT-2026-06.md index f322811..5ede2f2 100644 --- a/AUDIT-2026-06.md +++ b/AUDIT-2026-06.md @@ -64,7 +64,7 @@ the complaint pipeline (§1.4 below). The chain MUST run `AUDIT-2026-05.md §10`). **Hash-to-curve binding**: Corona doesn't use hash-to-curve; -it's an R-LWE scheme. The challenge `c = H(A, bTilde, w, μ, sid, T)` +it's a Module-LWE scheme. The challenge `c = H(A, bTilde, w, μ, sid, T)` is a sponge output (Corona-SHA3 via KMAC256), and is domain-separated by `QUASAR-CORONA-*` prefixes (see `primitives/hash.go`). @@ -278,7 +278,7 @@ trust-anchor citations, not integration specs. Silicon; honest disclosure that Apple does NOT publish a remote attestation root (local-only defense-in-depth). 5. **Intel SGX**: NOT RECOMMENDED for Corona (long CVE record of - side-channel attacks against R-LWE math). + side-channel attacks against Module-LWE math). ### §2.3 Decomplecting rule @@ -402,7 +402,7 @@ ops/mpcvm/wgsl/mpcvm_Corona.wgsl ops/crypto/Corona/cuda/ ``` -These are **NOT** Corona's R-LWE math — they're the MPCVM +These are **NOT** Corona's Module-LWE math — they're the MPCVM ceremony-state-machine kernel (Corona DKG ceremony op + Corona sign ceremony op as a generic "lattice ceremony" workflow). The real lattice arithmetic (NTT, Gaussian sampling, MLWE matrix @@ -481,7 +481,7 @@ The fumadocs Next.js site at `docs/` was 3057 lines of MDX that framed Corona as a **privacy ring-signature scheme** with linkable Schnorr signatures, hash-to-curve, and "ring signatures for transaction privacy". That is NOT what Corona is — Corona is -a 2-round R-LWE threshold signature scheme (Boschini et al. +a 2-round Module-LWE threshold signature scheme (Boschini et al. 2024/1113). The docs referenced a non-existent `github.com/luxfi/Corona` Go module and would have shipped a misleading product to anyone reading them. They are gone. @@ -616,7 +616,7 @@ The audit closes the four scope dimensions: audits. **Production deployment posture (unchanged from v0.7.5)**: APPROVED -WITH ROADMAP GATES for public-permissionless deployment as a R-LWE +WITH ROADMAP GATES for public-permissionless deployment as a Module-LWE threshold signature primitive in Lux Quasar consensus, with the v0.8.0 GATE-3b + GATE-4 + GATE-5 carryovers remaining as research-track work. The TEE integration spec landed by this audit diff --git a/AXIOM-INVENTORY.md b/AXIOM-INVENTORY.md index 3c8a922..5e9f35e 100644 --- a/AXIOM-INVENTORY.md +++ b/AXIOM-INVENTORY.md @@ -19,6 +19,15 @@ > **Lagrange-reconstructed master secret**). They are now correctly > classified **C / OPEN**. +> **Naming note.** Identifiers and EasyCrypt/Lean file names containing +> `rlwe` / `RLWE` (e.g. `rlwe_sign_op`, `RLWE_Functional.ec`, the wrapper +> bridges `*_eq_rlwe`, and the informal "centralised RLWE sign" reference +> signer) are retained **proof identifiers** for the single-party reference +> signer the threshold protocol refines against; they are deliberately not +> renamed, to keep the EasyCrypt/Lean developments compiling. Corona is a +> **Module-LWE** scheme (threshold-Raccoon/Ringtail; module dims M=8, N=7 +> over `Z_q[X]/(X^256+1)`). + ## Buckets - **A — STANDARD-MATH-FACT.** Cited field/algebra/coding identity EC lacks @@ -33,14 +42,14 @@ ## §1 Construction-level assumptions (cryptographic substrate — NOT Lux-closable) -These are the underlying hardness + soundness assumptions of the R-LWE +These are the underlying hardness + soundness assumptions of the Module-LWE threshold construction, inherited from the literature. They are not closed in any Lux work and are not counted in the EC axiom histogram below. | Assumption | Reference | Rationale for non-closure | |---|---|---| -| Module-LWE / Ring-LWE hardness | Lyubashevsky-Peikert-Regev (TOC 2013); Langlois-Stehlé (DCC 2015) | Standard PQ lattice hardness; same substrate as ML-DSA / ML-KEM. | -| R-SIS hardness over `R_q` | Ajtai (1996); Micciancio-Regev (SIAM 2007) | Unforgeability reduces to R-SIS at `sign/config.go` parameters. | +| Module-LWE hardness | Lyubashevsky-Peikert-Regev (TOC 2013); Langlois-Stehlé (DCC 2015) | Standard PQ lattice hardness; same substrate as ML-DSA / ML-KEM. | +| Module-SIS hardness over `R_q` | Ajtai (1996); Micciancio-Regev (SIAM 2007); Langlois-Stehlé (DCC 2015) | Unforgeability reduces to Module-SIS at `sign/config.go` parameters. | | Boschini-Kaviani-Lai-Malavolta-Takahashi-Tibouchi soundness | IACR ePrint 2024/1113; IEEE S&P 2025 | The 2-round threshold protocol's UC-soundness is in the cited paper; Lux's fork inherits it. Note: this is the Ringtail/Corona-family paper, NOT a Pulsar citation. | | Pedersen-VSS soundness | Pedersen (CRYPTO 1991) | Corona's DKG (`dkg2/`) reduces to discrete-log hardness. | | cSHAKE256 / KMAC256 collision + preimage resistance | NIST SP 800-185 | Domain-separated hashing across DKG/signing/reshare. | @@ -137,7 +146,7 @@ ADMIT key counts the *word* "admit" in comments and is informational. | A13 | `rnd_to_bits_id` | RLWE_Functional.ec:241 | As A10. | As A10. | | A14 | `bits_to_sig_id` | RLWE_Functional.ec:242 | As A10. | As A10. | | A15 | `poly_degree_nonneg` | Corona_N1.ec:245 | `0 <= poly_degree s` (abstract `poly_degree`). | Discharge after `share_t` concretization. | -| A16 | `accept_signing_attempt_iff_components` | Corona_N1.ec:547 | accept ⇔ (l2-z ∧ l2-Δ ∧ full-rank): algebra of the R-LWE accept predicate. | Discharge with the concrete accept predicate. | +| A16 | `accept_signing_attempt_iff_components` | Corona_N1.ec:547 | accept ⇔ (l2-z ∧ l2-Δ ∧ full-rank): algebra of the Module-LWE accept predicate. | Discharge with the concrete accept predicate. | | A17 | `compute_mu_injective` | Corona_N1.ec:563 | distinct (m,ctx) ⇒ distinct mu (transcript binder injectivity). | Discharge with concrete transcript_hash. | | A18 | `context_bytes_len_bound` | Corona_N1.ec:356 | `0 <= |context_bytes ctx| <= 65535`. | Discharge after `context_bytes` concretization. | @@ -188,24 +197,24 @@ Corona's EC byte-equality (`corona_n1_byte_equality` / `CombineAbs.combine`, whose body (`wrapper_combine_refines_abs`, lines 96–142 of Corona_N1_Combine_Wrapper.ec) reduces — via the bridge axioms below — to `rlwe_sign_op (reconstruct quorum shares) m ctx rho_rnd`: the -**centralised R-LWE signer applied to the Lagrange-reconstructed master +**centralised Module-LWE signer applied to the Lagrange-reconstructed master secret**. This is the **reconstruct-then-sign / CombineAbs reconstruct-then- sign abstraction**. The "steps 2–6" of the Boschini combine (the `CombineAbs.combine` open/aggregate/reject steps) are **opened**, not proved leak-free. The no-leak property of the production signer is -**interop-tested (Go↔C++ KAT byte-equality; and the production R-LWE path's +**interop-tested (Go↔C++ KAT byte-equality; and the production Module-LWE path's correctness is by code review against the paper), NOT EC-proven**. Tracked: `BLOCKERS.md` § "EC reconstruct-then-sign model". | # | Axiom | File:line | What is assumed (open) | |---|---|---|---| -| C1 | `combine_body_axiom` (declare axiom) | Corona_N1.ec:697 | `T.combine ~ CombineAbs.combine` on honest-quorum inputs — the extracted threshold combine equals the centralised RLWE sign of the reconstructed secret. The module-contract form of the whole combine refinement; closure pathway is the Jasmin byte-walk (production target v0.8.0). | +| C1 | `combine_body_axiom` (declare axiom) | Corona_N1.ec:697 | `T.combine ~ CombineAbs.combine` on honest-quorum inputs — the extracted threshold combine equals the centralised Module-LWE sign of the reconstructed secret. The module-contract form of the whole combine refinement; closure pathway is the Jasmin byte-walk (production target v0.8.0). | | C2 | `S_functional_spec` (declare axiom) | Corona_N1.ec:712 | `S.sign ~ CentralRLWESign.sign` on accepted inputs — the single-party module is a faithful Boschini signer. | | C3 | `combine_body_spec` | Corona_N1_Combine_Refinement.ec:63 | the Jasmin-extracted combine writes exactly `combine_abs_op(args)` to sig_out. Atomic byte-walk; **steps 2–6 are inside this axiom, unproved.** | | C4 | `sign_body_spec` | Corona_N1_Sign_Refinement.ec:42 | the Jasmin-extracted central sign writes exactly `sign_abs_op(args)` to sig_out. Atomic byte-walk. | | C5 | `combine_abs_op_lifted_bridge` | Corona_N1_Combine_Wrapper.ec:47 | the share-typed lifted combine op = the byte-level `combine_abs_op` modulo encoding. The bridge from the abstract module interface to the byte-walk; the security content rides here. | | C6 | `sign_abs_op_lifted_bridge` | Corona_N1_Sign_Wrapper.ec:27 | the share-typed lifted sign op = the byte-level `sign_abs_op` modulo encoding. | -| C7 | `sign_abs_op_lifted_eq_rlwe` | Corona_N1_Sign_Wrapper.ec:38 | **the reconstruct-then-sign identity in its starkest form**: `sign_abs_op_lifted sk … = rlwe_sign_op sk …` — the lifted op IS the centralised Boschini signer (the analog of libjade's role for Pulsar, but in-house since R-LWE has no FIPS target). This is the open Boschini-conformance claim. | +| C7 | `sign_abs_op_lifted_eq_rlwe` | Corona_N1_Sign_Wrapper.ec:38 | **the reconstruct-then-sign identity in its starkest form**: `sign_abs_op_lifted sk … = rlwe_sign_op sk …` — the lifted op IS the centralised Boschini signer (the analog of libjade's role for Pulsar, but in-house since Module-LWE threshold has no FIPS target). This is the open Boschini-conformance claim. | | C8 | `rlwe_sign_size` | RLWE_Functional.ec:204 | per-instance signature byte length under Boschini's rejection-sampling. Carries the construction's wire-size contract; classified C because it is a construction-level claim from the paper, not a pure layout identity. | | C9 | `sign_round1_constant_time` (declare axiom) | lemmas/Corona_CT.ec:80 | Round-1 commit is constant-time. A CT *contract*, discharged Jasmin-side via `jasminc -checkCT` (roadmap), NOT by EC; a timing property, so a name/EC claim cannot certify it (see `proof-by-rename.sh` rationale). | | C10 | `sign_round2_constant_time` (declare axiom) | lemmas/Corona_CT.ec:110 | Round-2 response is constant-time. As C9. | diff --git a/BLOCKERS.md b/BLOCKERS.md index 2c80b8a..ef1beff 100644 --- a/BLOCKERS.md +++ b/BLOCKERS.md @@ -7,7 +7,7 @@ N4 reshare / code-review-against-Boschini claims are at the disclosed v0.7.0/v0.8.0-roadmap tier; the EasyCrypt byte-equality proof rests on an OPEN reconstruct-then-sign axiom cone, the constant-time evidence is a static audit (dudect-submission-grade pending), and there is no independent -interop verifier for the R-LWE construction. None of these is hidden — they +interop verifier for the Module-LWE construction. None of these is hidden — they are the honest proof-tier of a published-construction implementation. See `PROOF-CLAIMS.md` §0 and `AXIOM-INVENTORY.md` §C. @@ -43,7 +43,7 @@ admits) **relative to** the bucket-C-idealised axioms: steps 2–6 are INSIDE it, unproved. - `combine_abs_op_lifted_bridge` + `sign_abs_op_lifted_eq_rlwe` — the wrapper bridges pinning the lifted op to - `rlwe_sign_op (reconstruct quorum shares) …`, i.e. the centralised R-LWE + `rlwe_sign_op (reconstruct quorum shares) …`, i.e. the centralised Module-LWE signer on the **Lagrange-reconstructed master secret**. - `combine_body_axiom` / `S_functional_spec` — the section-local contracts. @@ -126,7 +126,7 @@ residual C11′ and the unchanged B-bucket codec bridges. Remaining OPEN: - The production no-leak path's correctness is ALSO established by code - review + cross-runtime KAT (Go↔C++); there is no independent R-LWE + review + cross-runtime KAT (Go↔C++); there is no independent Module-LWE verifier (CORONA-NO-INDEP-VERIFIER — by design, no NIST target). - `no_leak_reduction`'s full simulation-soundness proof (the v0.8.0 EC/paper artifact) is not written; disclosed as a Module-LWE/MSIS reduction. @@ -180,18 +180,18 @@ dudect harness (`ct/dudect/`) is wired at smoke-budget. ### CORONA-NO-INDEP-VERIFIER (MEDIUM — interop disclosure) -**Status: OPEN by design (no NIST target for R-LWE).** Corona's signature +**Status: OPEN by design (no NIST target for Module-LWE).** Corona's signature byte-equality is cross-validated only **Go↔C++ of the SAME construction** (`luxcpp/crypto/corona` via `scripts/regen-kats.sh --verify`), NOT against an independent verifier. Unlike Pulsar (CIRCL + pq-crystals FIPS 204), the -Boschini R-LWE construction has no second independent implementation to +Boschini Module-LWE construction has no second independent implementation to diff against. Therefore Corona's combine byte-equality is **asserted + same-construction-KAT-tested**, never "proven/verified" in the ≥2-independent-implementations sense. `PROOF-CLAIMS.md` is worded to never claim otherwise. **Resolution criteria:** -- [ ] An independent R-LWE verifier (third-party or a from-the-paper +- [ ] An independent Module-LWE verifier (third-party or a from-the-paper re-implementation) is stood up and the KAT manifest diffs against it, OR - [ ] External review accepts the same-construction KAT + code-review posture as sufficient for the disclosed tier (shared external-review diff --git a/CHANGELOG.md b/CHANGELOG.md index d3bbdc1..377a5ff 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -288,7 +288,7 @@ from the v0.6.0 sign-off. - `~/work/lux/proofs/lean/Crypto/Corona/OutputInterchange.lean` -- Class N1 verifier-compatibility. - `~/work/lux/proofs/lean/Crypto/Corona/Unforgeability.lean` -- - EUF-CMA reduction to Ring-LWE. + EUF-CMA reduction to Module-LWE. - `~/work/lux/proofs/lean/Crypto/Corona/dkg2.lean` -- Pedersen-VSS DKG. ### Jasmin sources @@ -350,7 +350,7 @@ FIPS 204 sibling), adapted honestly to Corona's lighter proof tier. - `SUBMISSION.md` — NIST MPTC cover sheet. Cites Boschini et al. ePrint 2024/1113 (IEEE S&P 2025) as the underlying construction. Declares - construction-level N1 (no FIPS standard target available for R-LWE + construction-level N1 (no FIPS standard target available for Module-LWE threshold) + N4 (`(A, bTilde)` preserved across reshare within key era). Two-variant honesty disclosure: Pedersen DKG (`dkg2/`) is the production path; legacy `dkg/` is retained for historical reference only. @@ -380,7 +380,7 @@ FIPS 204 sibling), adapted honestly to Corona's lighter proof tier. Boschini et al. construction). - `docs/design-decisions.md`, `docs/family-architecture.md`, `docs/threat-model.md` — adapted from Pulsar's pattern to Corona's - R-LWE / `R_q` setting. + Module-LWE / `R_q` setting. ### Honest gaps documented @@ -394,7 +394,7 @@ This submission EXPLICITLY does NOT include (per `PROOF-CLAIMS.md` §3): `papers/lp-073-pulsar/` are the current canonical material). - Parameter-set worksheet with concrete lattice-estimator bounds. - ACVP/CAVP algorithm validation certificate (no NIST ACVP test vector - set exists for R-LWE threshold). + set exists for Module-LWE threshold). - FIPS 140-3 module validation (downstream). - External cryptographic audit (engaged lab) — roadmap v0.8.0. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 55094bf..aeff2f3 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -2,7 +2,7 @@ ## What we accept -This repository is **both** a production Ring-LWE threshold signature +This repository is **both** a production Module-LWE threshold signature library for Quasar consensus AND a NIST-MPTC-track submission package. Until the 2026-Nov-16 package submission, contributions that align with the MPTC submission are highest priority: @@ -42,8 +42,9 @@ Until after the MPTC submission lands: KMAC256 / TupleHash256 exclusively (Corona-SHA3). The legacy Corona-BLAKE3 suite is retained for cross-port byte checks only; new BLAKE3 deltas should NOT land. -- Patches that introduce Pulsar (M-LWE) types into Corona (R-LWE). - The two libraries are independent with no shared types; keep +- Patches that introduce Pulsar (ML-DSA) types into Corona + (threshold-Raccoon). Both are Module-LWE, but they are distinct + constructions in independent libraries with no shared types; keep them that way. These reopen post-submission. diff --git a/CRYPTOGRAPHER-SIGN-OFF.md b/CRYPTOGRAPHER-SIGN-OFF.md index bcd2db6..39de33c 100644 --- a/CRYPTOGRAPHER-SIGN-OFF.md +++ b/CRYPTOGRAPHER-SIGN-OFF.md @@ -1,6 +1,6 @@ # Cryptographer sign-off -- luxfi/corona v0.7.0 -> Independent review of the Corona threshold R-LWE implementation +> Independent review of the Corona threshold Module-LWE implementation > at `main` of `github.com/luxfi/corona`. > Date of review: 2026-05-18. > Reviewer: cryptographer agent (Hanzo Dev, internal review). @@ -69,14 +69,14 @@ byte-equality with `luxcpp/crypto/corona/`). - **`~/work/lux/proofs/lean/Crypto/Corona/`**: - `Shamir.lean` -- Lagrange-over-polynomial-ring algebraic core. - `OutputInterchange.lean` -- Class N1 verifier-compatibility. - - `Unforgeability.lean` -- EUF-CMA reduction to R-LWE. + - `Unforgeability.lean` -- EUF-CMA reduction to Module-LWE. - `dkg2.lean` -- Pedersen-VSS DKG correctness statement. - **`jasmin/`**: - `lib/` -- shared primitives (corona_params, seed, transcript, mac, lagrange). - `threshold/round1.jazz`, `round2.jazz`, `combine.jazz` -- the Boschini 2-round threshold protocol with `#ct` annotations. - - `rlwe/sign.jazz` -- centralized R-LWE Sign reference. + - `rlwe/sign.jazz` -- centralized Module-LWE Sign reference. - **`ct/dudect/`**: - `verify_ct.go` + `dudect_verify.c` -- Verify CT harness. - `combine_ct.go` + `dudect_combine.c` -- Combine CT harness. @@ -197,7 +197,7 @@ byte-equality with `luxcpp/crypto/corona/`). I attest that, given the above review and the explicit non-claims documented in `corona/PROOF-CLAIMS.md` §3 (now reflecting the v0.7.0 EC + Lean + Jasmin scaffold), `luxfi/corona` v0.7.0 is **APPROVED -WITH ROADMAP GATES** for production use as a R-LWE threshold +WITH ROADMAP GATES** for production use as a Module-LWE threshold signature primitive in Lux Quasar consensus' Aurora and Polaris cert profiles. diff --git a/DEPLOYMENT-RUNBOOK.md b/DEPLOYMENT-RUNBOOK.md index 0748958..0693909 100644 --- a/DEPLOYMENT-RUNBOOK.md +++ b/DEPLOYMENT-RUNBOOK.md @@ -1,6 +1,6 @@ # Deployment Runbook — luxfi/corona -> Operational guidance for deploying Corona (threshold Ring-LWE +> Operational guidance for deploying Corona (threshold Module-LWE > signing + Pedersen DKG + proactive resharing) in production > validator sets. Discloses the v0.2 trust-model caveats and pins > the safe operating envelope. diff --git a/FIPS-TRACEABILITY.md b/FIPS-TRACEABILITY.md index 0e10ce7..b38ef62 100644 --- a/FIPS-TRACEABILITY.md +++ b/FIPS-TRACEABILITY.md @@ -1,6 +1,6 @@ # FIPS-TRACEABILITY — Corona -> Construction-paper → code traceability map. R-LWE has no FIPS +> Construction-paper → code traceability map. Module-LWE has no FIPS > standard, so this document maps **Boschini ePrint 2024/1113 (IEEE > S&P 2025)** sections to `~/work/lux/corona/` implementation paths. > Equivalent role to Pulsar's `FIPS-TRACEABILITY.md` (which maps @@ -89,7 +89,7 @@ unforgeability — see `AXIOM-INVENTORY.md` §2. - NOT a security proof. The Boschini construction's security is proved in the cited paper. -- NOT a NIST FIPS standard reference (R-LWE has no FIPS standard). +- NOT a NIST FIPS standard reference (Module-LWE has no FIPS standard). - NOT a mechanized refinement against the cited paper. EC theories that formalize this mapping are roadmap v0.7.0 (see `AXIOM-INVENTORY.md` §2 + `PROOF-CLAIMS.md` §3). diff --git a/LLM.md b/LLM.md index 9847cd9..04630a5 100644 --- a/LLM.md +++ b/LLM.md @@ -6,7 +6,7 @@ ## Purpose (one-liner) -Ring-LWE threshold signature library used as the post-quantum threshold +Module-LWE threshold signature library used as the post-quantum threshold layer in Quasar consensus. Corona provides O(1) per-cert proofs after DKG, paired with BLS12-381 + ML-DSA-65 in the QuasarCert. @@ -21,7 +21,7 @@ keygen path. This is why **Corona — not Pulsar — carries the permissionless no-trusted-dealer guarantee** in the Quasar AND-mode dual-PQ cert: Pulsar's byte-FIPS-204 keygen is provably stuck at a trusted dealer (a dealerless sum of FIPS-204 secrets breaks ML-DSA's small-norm `S_η` bound), so the -dealerless property must come from Corona's R-LWE leg. +dealerless property must come from Corona's Module-LWE leg. This repository is BOTH the production library AND the active NIST MPTC submission package (Class N1 + N4). The submission tarball is cut from a @@ -45,7 +45,7 @@ tag on `main` via `scripts/cut-submission.sh`; reviewer feedback lands here. | `docs/patent-claims.md` | Attorney-prep claim drafts (FEWER than Pulsar — only Corona-novel lifecycle additions) | **HONESTY GUARD**: do not claim Corona has EC / Lean / Jasmin proofs. It does not. -Pulsar does; Corona's R-LWE has no FIPS standard target to refine against. See +Pulsar does; Corona's Module-LWE construction has no FIPS standard target to refine against. See `PROOF-CLAIMS.md` §3 for the explicit non-claims list. ## Recent significant commits @@ -73,7 +73,7 @@ Pulsar does; Corona's R-LWE has no FIPS standard target to refine against. See ### Active versions - Repo: `v0.8.0`. The default `keyera.Bootstrap` / `keyera.BootstrapWithSuite` route through `BootstrapPedersen` (dealerless Pedersen DKG over R_q); the legacy trusted-dealer impl is the unexported `bootstrapTrustedDealerImpl`, reachable only via the explicit `BootstrapTrustedDealer*` / `ReanchorTrustedDealer*` names. -- Pinned by: `luxfi/consensus v1.23.6+` (R-LWE path is consensus-only). +- Pinned by: `luxfi/consensus v1.23.6+` (Module-LWE path is consensus-only). ### Canonical params - Ring degree: 256 (LogN=8). @@ -87,7 +87,7 @@ Pulsar does; Corona's R-LWE has no FIPS standard target to refine against. See - `golang.org/x/crypto/sha3` → cSHAKE256 / KMAC256 / TupleHash256. - `zeebo/blake3` → LEGACY only (cross-port byte-check). - Consumed by: - - `luxfi/consensus/protocol/quasar` (R-LWE threshold for QuasarCert). + - `luxfi/consensus/protocol/quasar` (Module-LWE threshold for QuasarCert). - Cross-runtime byte-equal port: `~/work/luxcpp/crypto/corona/` (KAT manifest at `scripts/regen-kats.manifest.sha256`). ### Where to look for X @@ -105,9 +105,9 @@ Pulsar does; Corona's R-LWE has no FIPS standard target to refine against. See ### Open follow-ups (tracked in BLOCKERS.md) - Constant-time: `jasminc -checkCT` on the extracted threshold layer + dudect submission-grade 10⁹-sample run (CORONA-CT-PENDING). - `no_leak_reduction` discharged to a full Module-LWE/M-SIS simulation proof, OR accepted by external review as a standard reduction; plus the C11′ public-`w` commitment-aggregate bridge (CORONA-EC-RECON-MODEL). -- Independent R-LWE interop verifier, OR external review accepting the same-construction Go↔C++ KAT posture (CORONA-NO-INDEP-VERIFIER). +- Independent Module-LWE interop verifier, OR external review accepting the same-construction Go↔C++ KAT posture (CORONA-NO-INDEP-VERIFIER). - External cryptographic review — shared gate across the three open findings above. -- Variable-size R-LWE certs remain a wire-size cost vs Pulsar M-LWE; consensus uses Corona for finality-throughput and Pulsar for the identity rollup. +- Variable-size Corona (Module-LWE, Raccoon-line) certs remain a wire-size cost vs Pulsar's fixed-size ML-DSA certs; consensus uses Corona for finality-throughput and Pulsar for the identity rollup. ## Rules @@ -116,7 +116,7 @@ Pulsar does; Corona's R-LWE has no FIPS standard target to refine against. See hardcode SHAKE / KMAC outside `hash/sp800_185.go`. 3. Param changes require a new key-era boundary; never edit in place. 4. NEVER claim mechanized refinement Corona does not have. See `PROOF-CLAIMS.md` §3. -5. NEVER mix Pulsar (M-LWE) types into Corona (R-LWE) — independent libraries with no shared types. +5. NEVER mix Pulsar (ML-DSA) types into Corona (threshold-Raccoon) — both Module-LWE, but independent libraries with no shared types. 6. NEVER push the legacy `dkg/` package onto a deployment surface — it has known leakage (Feldman VSS without blinding). Production uses `dkg2/`. 7. Cross-runtime byte-equality with the C++ port (`~/work/luxcpp/crypto/corona/`) diff --git a/Makefile b/Makefile index fc603eb..43334cd 100644 --- a/Makefile +++ b/Makefile @@ -1,4 +1,4 @@ -# Corona - Post-Quantum Ring-LWE Threshold Signature Scheme +# Corona - Post-Quantum Module-LWE Threshold Signature Scheme # Makefile for building, testing, and managing the project .PHONY: all build test clean fmt lint vet coverage bench run help install-tools @@ -33,7 +33,7 @@ all: test build ## help: Display this help message help: - @echo "Corona - Post-Quantum Ring-LWE Threshold Signature Scheme" + @echo "Corona - Post-Quantum Module-LWE Threshold Signature Scheme" @echo "" @echo "Usage: make [target]" @echo "" diff --git a/NIST-SUBMISSION.md b/NIST-SUBMISSION.md index af5f06b..1729992 100644 --- a/NIST-SUBMISSION.md +++ b/NIST-SUBMISSION.md @@ -10,10 +10,10 @@ |---|---| | Submission name | **Corona** | | Submitting organisation | Lux Industries, Inc. | -| Algorithm | Threshold Ring-LWE 2-round signing + Pedersen DKG + proactive resharing | +| 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 | Ring-LWE over `R_q = Z_q[X]/(X^N + 1)`, `N = 256`, `q = 0x1000000004A01` (48-bit NTT-friendly prime) | +| 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 | | @@ -31,17 +31,17 @@ > a key era (Class N4 invariant). **Theorem framing**: construction-level interchangeability. Corona -implements the published Boschini et al. 2-round R-LWE threshold +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.** R-LWE threshold signatures have no NIST +**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 R-LWE verifier to cross-check against. This is the +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. @@ -60,7 +60,7 @@ DOES cross-check against BoringSSL FIPS / AWS-LC / OpenSSL 3.0 PQ. ## What makes this submission different -1. **Production-hardened R-LWE threshold** — beyond the Boschini et al. +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), @@ -122,10 +122,10 @@ The trust base for Corona at submission time reduces to: | Out-of-scope claim | Why | |---|---| -| Byte-equality with FIPS 204 ML-DSA | That is Pulsar's claim. Corona is R-LWE; ML-DSA is M-LWE. | -| Mechanized refinement proof | Multi-month research project. No FIPS standard target exists for R-LWE threshold. See `PROOF-CLAIMS.md`. | -| Post-quantum hardness of R-LWE | Assumed from Lyubashevsky-Peikert-Regev (2010) and follow-up analysis. | -| ACVP/CAVP algorithm validation certificate | Not applicable — NIST has no ACVP test vector set for R-LWE threshold. | +| 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.). | diff --git a/PATENTS.md b/PATENTS.md index 3da008b..5f671f9 100644 --- a/PATENTS.md +++ b/PATENTS.md @@ -1,4 +1,4 @@ -# PATENTS — Corona Threshold Ring-LWE Signature +# PATENTS — Corona Threshold Module-LWE Signature > **Statement of Intellectual Property and Royalty-Free Patent Grant** > for the Corona threshold-signing construction submitted to the NIST @@ -15,7 +15,7 @@ interoperability test. The grant terminates automatically and prospectively against any party that asserts a patent claim against Corona, the underlying -Boschini et al. R-LWE construction, FIPS 204 ML-DSA, or any other +Boschini et al. Module-LWE construction, FIPS 204 ML-DSA, or any other NIST-standardized post-quantum signature scheme. Defensive termination mirrors Apache-2.0 §3. @@ -38,8 +38,8 @@ It does NOT cover, and explicitly DISCLAIMS, the following prior art: | Component | Status | |---|---| -| The base 2-round Ring-LWE threshold construction (Boschini, Kaviani, Lai, Malavolta, Takahashi, Tibouchi. *Practical two-round threshold signatures from learning with errors.* IACR ePrint 2024/1113, IEEE S&P 2025) | Academic prior art. Corona implements this construction unchanged in its math. Lux asserts no patents on the published Boschini et al. algorithm itself. | -| Ring-LWE (R-LWE) primitive (Lyubashevsky, Peikert, Regev. *On ideal lattices and learning with errors over rings.* EUROCRYPT 2010) | Academic / public domain. | +| The base 2-round Module-LWE threshold construction (Boschini, Kaviani, Lai, Malavolta, Takahashi, Tibouchi. *Practical two-round threshold signatures from learning with errors.* IACR ePrint 2024/1113, IEEE S&P 2025) | Academic prior art. Corona implements this construction unchanged in its math. Lux asserts no patents on the published Boschini et al. algorithm itself. | +| Module-LWE primitive (Langlois, Stehlé. *Worst-case to average-case reductions for module lattices.* Designs, Codes and Cryptography 2015), building on the Ring-LWE primitive (Lyubashevsky, Peikert, Regev. *On ideal lattices and learning with errors over rings.* EUROCRYPT 2010) | Academic / public domain. | | Shamir secret sharing (1979) | Public domain. | | Lagrange polynomial interpolation | Classical mathematics. | | Pedersen verifiable secret sharing (Pedersen 1991) | Academic prior art. Corona's `dkg2/` adapts the Pedersen VSS construction to `R_q^M` lattice commits; the adaptation pattern is generic. | @@ -55,7 +55,7 @@ Subject to attorney review (see `docs/patent-claims.md` for the detailed numbered claim drafts), Lux considers the following Corona contributions to be candidates for patent protection. Note: this list is intentionally narrower than Pulsar's because the underlying -2-round R-LWE construction is published academic prior art (Boschini +2-round Module-LWE construction is published academic prior art (Boschini et al. 2024/1113). Corona's novel contributions are the production lifecycle layers atop the published construction. @@ -79,14 +79,14 @@ implementation in `dkg2/`. Proactive secret-sharing protocol that rotates shares across committee changes while preserving the group public key `(A, bTilde)` -in the R-LWE setting. Permits long-lived public identity with +in the Module-LWE setting. Permits long-lived public identity with rotating custodians. Two distinct primitives: - `Refresh` — same committee, fresh shares (HJKY97 lineage adapted - to R-LWE). + to Module-LWE). - `ReshareToNewSet` — set rotation with `t_old → t_new` threshold changes (Desmedt-Jajodia / Wong-Wang-Wing lineage adapted to - R-LWE). + Module-LWE). Detailed in `papers/lp-073-pulsar/lp-073-pulsar-resharing.tex`; implementation in `reshare/`. @@ -179,7 +179,7 @@ injection into Sign"; implementation in `primitives/hash.go` + > > (i) The Corona construction; or > (ii) The underlying Boschini-Kaviani-Lai-Malavolta-Takahashi-Tibouchi -> 2-round R-LWE threshold signature construction (IACR ePrint +> 2-round Module-LWE threshold signature construction (IACR ePrint > 2024/1113); or > (iii) FIPS 204 ML-DSA, or any other NIST-standardized post-quantum > signature scheme; or @@ -229,7 +229,7 @@ lifecycle additions as follows: for §102 purposes; filing before submission preserves priority). 2. **PCT international application** within 12 months of the - provisional, designating jurisdictions where R-LWE deployment is + provisional, designating jurisdictions where Module-LWE deployment is anticipated (EU, JP, CN, KR, IN, AU, CA, UK, BR). 3. **EPO and major-jurisdiction national-phase entries** at the PCT @@ -273,7 +273,7 @@ signature schemes. ### §5.3 Compatibility with the published Boschini et al. construction -The underlying 2-round R-LWE threshold protocol is published in the +The underlying 2-round Module-LWE threshold protocol is published in the academic literature (IACR ePrint 2024/1113, IEEE S&P 2025). Lux asserts no patents on the published academic construction itself; Corona's claims are limited to the production-lifecycle additions. diff --git a/PROOF-CLAIMS.md b/PROOF-CLAIMS.md index 858ed0f..ed1e873 100644 --- a/PROOF-CLAIMS.md +++ b/PROOF-CLAIMS.md @@ -27,7 +27,7 @@ NOT the production residual (RE-SCOPED this pass).** `_extracted` prove the threshold combine equals `CombineAbs.combine`, whose body reduces — via `combine_abs_op_lifted_bridge` and `sign_abs_op_lifted_eq_rlwe` — to `rlwe_sign_op (reconstruct quorum -shares) …`: the centralised R-LWE signer applied to the +shares) …`: the centralised Module-LWE signer applied to the **Lagrange-reconstructed master secret**. The Boschini combine steps 2–6 are opened inside `combine_body_spec`, not proved. So Model 1 is machine-checked (0 admits) modulo a C-cone that **reconstructs-then-signs** — an idealised @@ -54,7 +54,7 @@ pending EasyCrypt**; its Lean core is machine-checked now. **Disclosure 2 — the no-leak property is NOT independently interop-tested.** Corona's KAT cross-validation is **Go↔C++ of the SAME construction** (`luxcpp/crypto/corona`), not against an independent verifier. There is no -CIRCL/pq-crystals analog for R-LWE (no NIST target). So Corona's combine +CIRCL/pq-crystals analog for Module-LWE (no NIST target). So Corona's combine output byte-equality is **asserted + same-construction-KAT-tested**, NOT interop-tested in the ≥2-independent-implementations sense (unlike Pulsar's CIRCL + pq-crystals). We therefore do NOT claim Corona byte-equality is @@ -138,27 +138,28 @@ secret). See §0 Disclosure 1. The implementation-backed N1 byte-equality theorem to cite is `Corona_N1_Extracted.corona_n1_byte_equality_extracted`. -R-LWE threshold signing has no NIST standard target. The Boschini +Module-LWE threshold signing has no NIST standard target. The Boschini et al. ePrint 2024/1113 construction IS the spec; the EC theories refine the Go implementation against the in-house mechanization of that spec (`lemmas/RLWE_Functional.ec`), which is the analog of Pulsar's libjade dependence on FIPS 204. -### §3.2 NOT proved: lattice-hardness of R-LWE +### §3.2 NOT proved: lattice-hardness of Module-LWE This submission says nothing about the post-quantum hardness of -Ring-LWE itself. R-LWE security rests on Lyubashevsky-Peikert-Regev -(2010) and follow-up cryptanalytic analysis. The parameter set +Module-LWE itself. Module-LWE security rests on Lyubashevsky-Peikert-Regev +(2010), the Langlois-Stehlé (2015) module generalisation, and follow-up +cryptanalytic analysis. The parameter set (`N = 256`, `q = 0x1000000004A01`, 48-bit prime) was chosen to provide ≥ 128 bits of post-quantum security per lattice-estimator methodology — but Corona ships no parameter-set worksheet at this revision; that is roadmap item v0.6.0. **The defensible PQ-safety claim**: -> Corona implements a published academic R-LWE threshold signature +> Corona implements a published academic Module-LWE threshold signature > construction (Boschini et al. ePrint 2024/1113) on a parameter > set chosen to provide ≥ 128 bits of post-quantum security against -> known R-LWE attacks per the lattice-estimator methodology of +> known Module-LWE attacks per the lattice-estimator methodology of > Albrecht-Player-Scott. The construction's EUF-CMA reduction is in > the cited paper. @@ -168,9 +169,10 @@ revision; that is roadmap item v0.6.0. ### §3.3 NOT proved: byte-equality with FIPS 204 ML-DSA Corona signatures are NOT byte-equal to FIPS 204 ML-DSA signatures. -The two constructions use different lattice families (Corona is -R-LWE; ML-DSA is M-LWE), different ring degrees, different -parameter sets. Any reviewer expecting FIPS 204 byte-equality +The two constructions are different schemes within the Module-LWE +family (Corona is the Raccoon/Ringtail line; ML-DSA is the Dilithium +line), with different moduli, module dimensions, and parameter sets. +Any reviewer expecting FIPS 204 byte-equality should look at the Pulsar sibling at `~/work/lux/pulsar/`. ### §3.4 NOT proved: statistical constant-time validation (dudect) @@ -273,7 +275,7 @@ same-construction Go↔C++ KAT only (§0 Disclosure 2). > Corona's submission package establishes that the Go reference > implementation faithfully implements the Boschini, Kaviani, Lai, -> Malavolta, Takahashi, and Tibouchi 2-round R-LWE threshold +> Malavolta, Takahashi, and Tibouchi 2-round Module-LWE threshold > signature construction (IACR ePrint 2024/1113, IEEE S&P 2025) on a > fixed parameter set, plus production lifecycle additions (Pedersen > DKG over `R_q`, proactive resharing with Refresh + ReshareToNewSet @@ -282,7 +284,7 @@ same-construction Go↔C++ KAT only (§0 Disclosure 2). > suite). Unlike the Pulsar sibling submission (which ships a > mechanized EasyCrypt + Lean + Jasmin refinement chain against > FIPS 204), Corona ships NO machine-checked refinement at this -> submission — R-LWE has no NIST standard target, the construction +> submission — Module-LWE has no NIST standard target, the construction > IS the spec, and mechanizing the construction itself is a multi- > month research roadmap item. Corona's correctness evidence > reduces to code review of the Go reference against the published diff --git a/README.md b/README.md index 9722455..4c0fd44 100644 --- a/README.md +++ b/README.md @@ -4,19 +4,20 @@ See [LP-105 §Claims and evidence](https://github.com/luxfi/lps/blob/main/LP-105-lux-stack-lexicon.md#claims-and-evidence) for the canonical claims/evidence table and the ten architectural commitments — single source of truth. -**Corona** is the Lux **Ring-LWE** post-quantum threshold signature library +**Corona** is the Lux **Module-LWE** post-quantum threshold signature library for **Quasar consensus**. The 2-round threshold construction line traces back -to the Boschini–Kaviani–Lai–Malavolta–Takahashi–Tibouchi R-LWE paper +to the Boschini–Kaviani–Lai–Malavolta–Takahashi–Tibouchi Module-LWE paper ([ePrint 2024/1113](https://eprint.iacr.org/2024/1113)). Corona adds the production lifecycle that line lacked: Pedersen DKG over `R_q` with proper hiding, proactive resharing for epoch validator rotation, identifiable abort, and the integration surface Quasar consumes. -The **Module-LWE sibling library** lives at [`luxfi/pulsar`](https://github.com/luxfi/pulsar). -Pulsar's threshold signature output is byte-equal to FIPS 204 single-party -ML-DSA (NIST MPTC Class N1). The two libraries are independent — there is -no import line between them — and Quasar consumes them as parallel kernels -selected per-chain via `FinalitySchemeID`. +The **ML-DSA sibling library** lives at [`luxfi/pulsar`](https://github.com/luxfi/pulsar). +Pulsar is also Module-LWE, but a different construction: its threshold +signature output is byte-equal to FIPS 204 single-party ML-DSA (NIST MPTC +Class N1). The two libraries are independent — there is no import line +between them — and Quasar consumes them as parallel kernels selected +per-chain via `FinalitySchemeID`. ## Why "Corona" @@ -33,7 +34,7 @@ research artefact — trusted-dealer DKG, no proactive resharing, no integration surface. Corona is the production track that fills those gaps: -| Layer | Original R-LWE construction | Corona | +| Layer | Original Module-LWE construction | Corona | |---|---|---| | 2-round threshold sign | ✅ same byte-equal protocol | ✅ inherited | | Trusted-dealer Gen | ✅ for fixed federation | ✅ tests / KAT / CLI / permissioned bridge MPC only — never the chain keygen path | @@ -43,15 +44,18 @@ gaps: ## Composition with Pulsar as optional layered PQ defense -Corona is independently usable: a chain can pick Ring-LWE Corona as its +Corona is independently usable: a chain can pick Corona as its sole PQ threshold layer, no cross-dependency on Pulsar. Lux primary- -network QuasarCert combines both lattice families as a **Double Lattice** -layered defence so a break in one family does not break finality: +network QuasarCert combines both Module-LWE schemes as a **Double Lattice** +layered defence so a break in one *construction or implementation* does not +break finality. (Both legs are Module-LWE, so this is construction- and +implementation-diversity, not lattice-family diversity — a break of the +shared Module-LWE problem would affect both legs): ``` QuasarCert { BLS — optional classical fast-path (BLS-12-381 aggregate) - Corona — Ring-LWE threshold ML-DSA (this repo) + Corona — Module-LWE threshold (Raccoon/Ringtail line; this repo) Pulsar — Module-LWE threshold ML-DSA (luxfi/pulsar) MLDSARollup — per-validator ML-DSA-65 rolled up via STARK/FRI (P3Q) } @@ -84,7 +88,7 @@ Pulsar's key generation provably stuck at a trusted dealer. ## Status Production. The 2-round Sign+Verify path is byte-equal-validated against -the original R-LWE construction (ePrint 2024/1113) via 16 SHA-256 KATs. +the original Module-LWE construction (ePrint 2024/1113) via 16 SHA-256 KATs. The dealerless **Pedersen DKG** (`dkg2/`, entered through `keyera.Bootstrap` / `BootstrapPedersen`) is the **production keygen default since v0.7.5**: it opens a new key era without a trusted dealer, @@ -96,7 +100,7 @@ alongside it; the trusted-dealer keygen helpers remain only as tests / KAT / CLI footguns (and permissioned bridge MPC), never the chain keygen path. -Corona remains the Ringtail/Raccoon-derived R-LWE leg (Boschini et al., +Corona remains the Ringtail/Raccoon-derived Module-LWE leg (Boschini et al., ePrint 2024/1113) with its own parameter set: it is **not** FIPS-204 -byte-equal, and its certificates are variable-size R-LWE certificates, +byte-equal, and its certificates are variable-size Module-LWE certificates, larger than Pulsar's FIPS-204-equal output. diff --git a/SECURITY.md b/SECURITY.md index 72a036e..2d75e88 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -10,7 +10,7 @@ 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 +Module-LWE threshold signing in Quasar consensus, and a NIST MPTC submission package. The following are in-scope for responsible disclosure: diff --git a/SPEC.md b/SPEC.md index df496c2..fb85272 100644 --- a/SPEC.md +++ b/SPEC.md @@ -1,7 +1,7 @@ -# SPEC — Corona Threshold Ring-LWE Signature (v0.2) +# SPEC — Corona Threshold Module-LWE Signature (v0.2) > **Standalone protocol specification** for **Corona** — a 2-round -> threshold Ring-LWE signature scheme with Pedersen DKG over `R_q` +> threshold Module-LWE signature scheme with Pedersen DKG over `R_q` > and proactive resharing. > > Companion to: @@ -17,7 +17,7 @@ ## §1 Scope -This document specifies **Corona**, the Ring-LWE 2-round threshold +This document specifies **Corona**, the Module-LWE 2-round threshold signature construction shipped at `github.com/luxfi/corona`. Corona implements the published construction of Boschini, Kaviani, Lai, Malavolta, Takahashi, and Tibouchi (IACR ePrint 2024/1113, IEEE S&P @@ -27,10 +27,10 @@ proactive resharing, identifiable abort, activation certificates, KAT-deterministic Corona-SHA3 hash suite). This spec does NOT cover: -- The single-party FIPS 204 ML-DSA algorithm (different lattice - family — see Pulsar at `~/work/lux/pulsar/`). +- The single-party FIPS 204 ML-DSA algorithm (a different + Module-LWE construction — see Pulsar at `~/work/lux/pulsar/`). - Verifier implementations beyond the Corona reference verifier - (`sign/sign.go:Verify`). No third-party R-LWE threshold verifier + (`sign/sign.go:Verify`). No third-party Module-LWE threshold verifier exists at submission time. - Pulsar (Module-LWE sibling) — see `https://github.com/luxfi/pulsar`. - Magnetar (Tier 3 SLH-DSA research profile) — see @@ -63,7 +63,7 @@ This spec does NOT cover: The single-set submission is intentional: Corona ships a fixed parameter set tuned to provide ≥ 128 bits of post-quantum security -against the best known R-LWE attacks (per the lattice-estimator +against the best known Module-LWE attacks (per the lattice-estimator methodology of Albrecht-Player-Scott). A second parameter set targeting NIST PQ Category 3 is on the roadmap but is NOT in this submission package. @@ -78,8 +78,9 @@ Per `DESIGN.md` §"Three layers, one shipping path". Summary: - Pedersen DKG (`dkg2/`) provides hiding and binding; legacy `dkg/` (Feldman VSS without blinding) is documented as broken for public broadcast and is retained for historical reference only. -- R-LWE hardness over the fixed parameter set (Lyubashevsky-Peikert- - Regev 2010 + follow-up analysis). +- Module-LWE hardness over the fixed parameter set (Langlois-Stehlé + 2015 module generalisation of Lyubashevsky-Peikert-Regev 2010 + + follow-up analysis). - cSHAKE256 / KMAC256 / TupleHash256 collision/preimage resistance per FIPS 202 + SP 800-185. @@ -181,7 +182,7 @@ The verifier: 3. Verifies `c' == c` via constant-time `r.Equal` (lattigo). 4. Checks low-norm bound on `z` (`primitives.CheckL2Norm`). -No third-party FIPS-validated verifier exists for R-LWE threshold +No third-party FIPS-validated verifier exists for Module-LWE threshold signatures at submission time. Corona's verifier is the spec. ## §9 Proactive resharing diff --git a/SUBMISSION.md b/SUBMISSION.md index 3da0466..6bb5a8a 100644 --- a/SUBMISSION.md +++ b/SUBMISSION.md @@ -22,7 +22,7 @@ auditable. **Maturity stamp**: v0.2 ready. This submission is **not** NIST-ratified, **not** FIPS 140-3 validated, **not** ACVP-validated, -and explicitly **not anchored to a FIPS standard** (R-LWE threshold +and explicitly **not anchored to a FIPS standard** (Module-LWE threshold signing has no NIST standard — the academic Boschini et al. paper is the construction spec). It is the algorithm-level reference plus production lifecycle additions plus reproducibility tooling. @@ -33,10 +33,10 @@ production lifecycle additions plus reproducibility tooling. |---|---| | Submission name | **Corona** | | Submitting organisation | Lux Industries, Inc. | -| Algorithm | Threshold Ring-LWE 2-round signing + DKG + proactive resharing | +| Algorithm | Threshold Module-LWE 2-round signing + DKG + proactive resharing | | Target NIST MPTC classes | **N1** (threshold signing, single-party-output-compatible against the construction's own verifier) + **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 | Ring-LWE over `R_q = Z_q[X]/(X^N + 1)`, `N = 256`, `q = 0x1000000004A01` (48-bit NTT-friendly prime) | +| 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 | | Signature output | Byte-compatible with the construction's own verifier (`sign.Verify`); **NOT byte-equal to FIPS 204 ML-DSA** — that property belongs to the M-LWE sibling [`luxfi/pulsar`](https://github.com/luxfi/pulsar) | | Hash suite | Corona-SHA3 (cSHAKE256 / KMAC256 / TupleHash256 per FIPS 202 + SP 800-185); legacy Corona-BLAKE3 retained for cross-port byte checks | @@ -59,12 +59,12 @@ production lifecycle additions plus reproducibility tooling. > events within a key era (Class N4 invariant). This is a **construction-level interchangeability** claim, NOT a FIPS -204 byte-equality claim. Corona uses Ring-LWE arithmetic that has no +204 byte-equality claim. Corona uses Module-LWE arithmetic that has no NIST standard analogue at the time of submission; the Boschini et al. construction IS the spec. **Verifier-side story (load-bearing for N1 framing).** Because there -is no NIST standard R-LWE threshold signature, the Class N1 +is no NIST standard Module-LWE threshold signature, the Class N1 "output-interchangeability" axis is reduced to: any verifier that accepts a single-party run of the underlying Boschini et al. construction MUST accept a Corona threshold-aggregated signature on @@ -75,7 +75,7 @@ in that respect. A reviewer evaluating the N1 claim should compare Corona's threshold-emitted bytes to the bytes a single-party run of the same parameter set would produce on the reconstructed secret — the comparison is via the same `Verify` routine, not via a third -party FIPS-validated verifier (which does not exist for R-LWE +party FIPS-validated verifier (which does not exist for Module-LWE threshold). ## Algorithm scope @@ -169,7 +169,7 @@ tests, tars the entire submission checkout, and prints the SHA-256. The N1 claim is asserted at **three** levels of evidence (one fewer than Pulsar; the missing level is the machine-checked refinement -chain, because R-LWE has no FIPS standard to refine against): +chain, because Module-LWE threshold has no FIPS standard to refine against): | Evidence | Where | |---|---| @@ -181,7 +181,7 @@ chain, because R-LWE has no FIPS standard to refine against): - No EasyCrypt refinement chain (Corona has no FIPS-standard target). - No Lean ↔ EC algebraic bridge files. -- No Jasmin high-assurance implementation (libjade does not cover Corona's R-LWE parameter set). +- No Jasmin high-assurance implementation (libjade does not cover Corona's Module-LWE parameter set). - No machine-checked `Class N1 byte-equality` theorem. The honest framing for Corona is: **production-hardened @@ -216,7 +216,7 @@ delta: | 5/5 Lean ↔ EC algebraic-bridge files | none | NOT PRESENT | | 3/3 jasmin-ct blocking on threshold layer | none | NOT PRESENT — libjade does not target this parameter set | | Class N1 byte-equality theorem (mechanized) | construction-level claim only | NOT MECHANIZED — Boschini et al. paper is the spec, no FIPS target | -| `pq-crystals` / BoringSSL / OpenSSL cross-validation | none possible | NOT APPLICABLE — no third-party R-LWE threshold verifier exists | +| `pq-crystals` / BoringSSL / OpenSSL cross-validation | none possible | NOT APPLICABLE — no third-party Module-LWE threshold verifier exists | What Corona DOES offer at submission-time: @@ -238,7 +238,7 @@ What Corona DOES offer at submission-time: ## What this submission does NOT claim - **No byte-equality with FIPS 204 ML-DSA** — that is Pulsar's claim. - Corona is an independent R-LWE construction with no NIST standard + Corona is an independent Module-LWE construction with no NIST standard to verify against. - **No mechanized refinement proof** — no EasyCrypt, no Lean, no Jasmin. The construction is the published academic paper; the Go @@ -249,7 +249,7 @@ What Corona DOES offer at submission-time: cryptographic modules, not this reference implementation. Downstream of this submission. - **No ACVP / CAVP algorithm validation certificate** — no NIST ACVP - test vector set exists for R-LWE threshold signatures. + test vector set exists for Module-LWE threshold signatures. - **No identifiable abort under network partition** — synchronous network assumption only; asynchronous identifiable abort is a separate problem. @@ -267,17 +267,21 @@ What Corona DOES offer at submission-time: | Submission | Lattice | Round count | Output story | NIST class | |---|---|---|---|---| -| **Corona** (this) | Ring-LWE (R-LWE) | 2 | Construction-level interchangeable with single-party Corona verifier; no NIST standard target | N1 + N4 | +| **Corona** (this) | Module-LWE (Raccoon/Ringtail line) | 2 | Construction-level interchangeable with single-party Corona verifier; no NIST standard target | N1 + N4 | | **Pulsar** ([`luxfi/pulsar`](https://github.com/luxfi/pulsar)) | Module-LWE (M-LWE) | 2 | Byte-equal to FIPS 204 ML-DSA-65 | N1 + N4 | | Raccoon (NIST PQC) | Module-LWE | 3 | Compatible verification | not MPTC | -| Boschini et al. (academic upstream) | R-LWE | 2 | Construction-level; trusted-dealer Gen only | not submitted as MPTC | +| Boschini et al. (academic upstream) | Module-LWE | 2 | Construction-level; trusted-dealer Gen only | not submitted as MPTC | -The R-LWE / M-LWE pair is intentional. Lux's primary-network -QuasarCert MAY combine Corona (R-LWE) and Pulsar (M-LWE) as a -**Double Lattice** layered defence so a break in one lattice family -does not break finality. That layered combination is the consumer's -design choice and is not part of this submission. Corona stands -alone as an MPTC Class N1 + N4 candidate. +The Corona / Pulsar pair is intentional. Both are Module-LWE, but they +are distinct constructions (Corona is the Ringtail/Raccoon-line threshold; +Pulsar is FIPS-204 ML-DSA made threshold). Lux's primary-network +QuasarCert MAY combine them as a **Double Lattice** layered defence so a +break in one *construction or implementation* does not break finality. +Because both legs are Module-LWE, a break of the shared Module-LWE problem +would affect both — the diversity is at the construction/implementation +layer, not the lattice family. That layered combination is the consumer's +design choice and is not part of this submission. Corona stands alone as +an MPTC Class N1 + N4 candidate. ## Contact diff --git a/TRUSTED-COMPUTING-BASE.md b/TRUSTED-COMPUTING-BASE.md index 93fa99a..a169ead 100644 --- a/TRUSTED-COMPUTING-BASE.md +++ b/TRUSTED-COMPUTING-BASE.md @@ -180,14 +180,14 @@ incorporating Corona): modify the hash suite, the claim's transferable guarantees attenuate. - **For FIPS 140-3 module validation**, Corona is NOT a candidate - — R-LWE threshold has no NIST standard, so no FIPS 140-3 module + — 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 - R-LWE kernel; the consuming consensus layer is responsible for + 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). @@ -201,11 +201,11 @@ incorporating Corona): | 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 (R-LWE primitives) | +| 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 R-LWE threshold) | +| 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 diff --git a/cli/cli.go b/cli/cli.go index 15520ef..dd1d4e9 100644 --- a/cli/cli.go +++ b/cli/cli.go @@ -23,7 +23,7 @@ func NewCmd() *cobra.Command { Aliases: []string{"corona"}, Short: "Corona threshold signing", Long: `The rt (corona) command provides tools for Corona threshold signing, -a post-quantum threshold signature scheme using Ring-LWE. +a post-quantum threshold signature scheme using Module-LWE. Corona is part of the triple consensus (BLS + Corona + ML-DSA) used by Lux validators. It provides threshold signatures where t-of-n parties diff --git a/docs/mptc/design-decisions.md b/docs/mptc/design-decisions.md index ec3be8c..e44f15f 100644 --- a/docs/mptc/design-decisions.md +++ b/docs/mptc/design-decisions.md @@ -1,24 +1,28 @@ # Corona — Design Decisions > Rationale for the design choices behind Corona's production -> lifecycle on top of the Boschini et al. ePrint 2024/1113 R-LWE +> lifecycle on top of the Boschini et al. ePrint 2024/1113 Module-LWE > threshold construction. -## §1 Why Ring-LWE (not Module-LWE)? +## §1 Why two Module-LWE schemes (Corona threshold-Raccoon + Pulsar ML-DSA)? + +Both Corona and Pulsar are Module-LWE; they are distinct *constructions*, +not distinct lattice families. Corona is the Ringtail/Raccoon-line 2-round +threshold construction; Pulsar is FIPS-204 ML-DSA made threshold. | Question | Answer | |---|---| -| Why ship an R-LWE library when ML-DSA (M-LWE) is the NIST standard? | The R-LWE 2-round construction (Boschini et al. 2024/1113) was published a year before the M-LWE equivalent matured. Lux deployed the R-LWE path first because it was the only construction with a published peer-reviewed 2-round threshold signature analysis for lattice-based signatures at the time of consensus design. | -| Why keep R-LWE after the M-LWE path (Pulsar) is ready? | Lux's primary-network QuasarCert is designed to consume BOTH lattice families as a **Double Lattice** layered defence so a break in one lattice family does not break finality. The two are complementary, not interchangeable. | -| Why not converge on a single lattice family? | A break in Module-LWE (which Pulsar uses) would not automatically break Ring-LWE (which Corona uses), and vice versa. The cost is wire-size overhead (Corona certs are variable-size; Pulsar certs are fixed-size); the benefit is structural diversity. | +| Why ship Corona when ML-DSA (Pulsar) is the NIST standard? | Corona's 2-round *threshold* construction (Boschini et al. 2024/1113, the Ringtail/Raccoon line) was published with a peer-reviewed 2-round threshold analysis a year before the ML-DSA threshold path matured. Lux deployed it first because it was the only construction with a published peer-reviewed 2-round threshold signature analysis for lattice-based signatures at the time of consensus design. | +| Why keep Corona after the ML-DSA path (Pulsar) is ready? | Lux's primary-network QuasarCert is designed to consume BOTH as a **Double Lattice** layered defence: two *independent constructions and codebases* (threshold-Raccoon vs ML-DSA) so that a construction- or implementation-specific flaw in one does not break finality. The two are complementary, not interchangeable. | +| Does running both give lattice-family diversity? | No. Both legs are Module-LWE, so a break of the Module-LWE problem itself would affect both. The diversity is at the *construction and implementation* layer, not the hardness assumption. Hardness-assumption diversity in the stack comes from the (research-stage) hash-based Magnetar (SLH-DSA), not from Corona-vs-Pulsar. The cost of running both is wire-size overhead (Corona certs are variable-size; Pulsar certs are fixed-size); the benefit is construction and implementation diversity. | ## §2 Why this parameter set? | Parameter | Value | Rationale | |---|---|---| -| Ring degree `N` | 256 | Standard choice for 128-bit post-quantum security per the lattice-estimator methodology; matches lattigo's default ring sizing for R-LWE. | +| Ring degree `N` | 256 | Standard choice for 128-bit post-quantum security per the lattice-estimator methodology; matches lattigo's default ring sizing. | | Prime `q` | `0x1000000004A01` | 48-bit NTT-friendly prime. Wide enough to absorb the Lagrange-aggregation coefficient growth without overflow; narrow enough that single-`q` polynomial arithmetic fits in `uint64`. | -| Module width `M` | 8 | Balances signature size against security margin under R-LWE attacks. | +| Module width `M` | 8 | Balances signature size against security margin under Module-LWE attacks. | | Module height `N_M` | 7 | Matches `M` − 1 to give comfortable EUF-CMA reduction margin. | | Challenge weight `Kappa` | 23 | Ternary challenge weight per Boschini et al. parameter analysis. | diff --git a/docs/mptc/evaluation.md b/docs/mptc/evaluation.md index c2daebc..25724e3 100644 --- a/docs/mptc/evaluation.md +++ b/docs/mptc/evaluation.md @@ -175,24 +175,26 @@ Corona v0.4.1 ships a single parameter set: ### §9.2 Concrete security claim Target: ≥ 128 bits of post-quantum security against the best known -R-LWE attacks per the lattice-estimator methodology of +Module-LWE attacks per the lattice-estimator methodology of Albrecht-Player-Scott. **Roadmap**: a worksheet with concrete lattice-estimator output for the parameter set is roadmap item v0.6.0. At submission scaffolding this revision, the concrete bounds are NOT included; the parameter -set was chosen by Lux engineering against the academic R-LWE +set was chosen by Lux engineering against the academic Module-LWE literature, but the documented worksheet is pending. -### §9.3 R-LWE prior art +### §9.3 Module-LWE prior art 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. EUF-CMA reduction in §3 of the paper. Corona inherits the analysis. -R-LWE primitive: Lyubashevsky, Peikert, Regev. *On ideal lattices and -learning with errors over rings.* EUROCRYPT 2010. +Module-LWE primitive: Langlois, Stehlé. *Worst-case to average-case +reductions for module lattices.* Designs, Codes and Cryptography 2015, +building on the Ring-LWE primitive of Lyubashevsky, Peikert, Regev. +*On ideal lattices and learning with errors over rings.* EUROCRYPT 2010. Concrete cryptanalysis literature: Albrecht, Player, Scott. *On the concrete hardness of learning with errors.* J. Math. Cryptol. 2015 @@ -206,8 +208,9 @@ IACR ePrint archive 2015–2026. - Concrete lattice-estimator output for the parameter set (roadmap v0.6.0). - Comparison benchmarks against single-party FIPS 204 ML-DSA — Corona - and ML-DSA are different lattice families; like-for-like comparison - is not meaningful. + and ML-DSA are different constructions (both Module-LWE, but a + threshold Raccoon-line scheme vs single-party Dilithium); like-for- + like comparison is not meaningful. - Threshold-vs-single-party overhead measurements at specific (n, t) — these depend heavily on network conditions in production; the reference benchmark suite measures the local compute portion. diff --git a/docs/mptc/family-architecture.md b/docs/mptc/family-architecture.md index a72a7ed..efcd275 100644 --- a/docs/mptc/family-architecture.md +++ b/docs/mptc/family-architecture.md @@ -6,12 +6,13 @@ ## §1 The three-library family -Lux ships three post-quantum threshold signature libraries with -distinct lattice families and use cases: +Lux ships three post-quantum threshold signature libraries spanning +two post-quantum families (Module-LWE lattice and hash-based) with +distinct constructions and use cases: -| Library | Lattice | Role | NIST MPTC class | Repository | +| Library | Family / construction | Role | NIST MPTC class | Repository | |---|---|---|---|---| -| **Corona** (this) | Ring-LWE (`R_q`) | Consensus-finality threshold (Quasar R-LWE finality kernel) | N1 + N4 (construction-level) | `luxfi/corona` | +| **Corona** (this) | Module-LWE (`R_q^{8×7}`), Raccoon/Ringtail line | Consensus-finality threshold (Quasar Module-LWE finality kernel) | N1 + N4 (construction-level) | `luxfi/corona` | | **Pulsar** | Module-LWE (`R_q^k × R_q^l`) | Identity-layer threshold + FIPS 204 byte-equality | N1 + N4 (FIPS-anchored) | `luxfi/pulsar` | | **Magnetar** (research) | SLH-DSA (FIPS 205) | Hash-based fallback (research-stage) | not submitted at this writing | `luxfi/magnetar` | @@ -23,9 +24,9 @@ layer (e.g., QuasarCert combines Corona + Pulsar + BLS). | Decomposition axis | Choice rationale | |---|---| -| Per-lattice-family library | A break in one lattice family (R-LWE vs M-LWE vs hash-based) should not break the others. Independent libraries with no shared types is the safest decomposition for defence-in-depth. | +| Per-construction library | A flaw in one library — whether a construction-specific cryptanalytic break or an implementation bug — should not break the others. Corona and Pulsar are both Module-LWE, so this isolates construction/implementation faults between them, not a break of Module-LWE itself; Magnetar's hash-based SLH-DSA additionally diversifies the hardness assumption. Independent libraries with no shared types is the safest decomposition for defence-in-depth. | | No shared types | Pulsar and Corona share NO Go types. If a vulnerability is found in Corona, the fix landing in Corona does not touch Pulsar (and vice versa). Each library's go.mod is independent. | -| Separate KAT vectors | Pulsar's KATs target FIPS 204 byte-equality. Corona's KATs target Go ↔ C++ cross-runtime byte-equality. The two KAT formats are intentionally different (different lattice algebra; different signature byte layouts). | +| Separate KAT vectors | Pulsar's KATs target FIPS 204 byte-equality. Corona's KATs target Go ↔ C++ cross-runtime byte-equality. The two KAT formats are intentionally different (different parameter sets and constructions; different signature byte layouts). | | Separate hash-suite registries | Pulsar uses SHAKE / cSHAKE / KMAC per FIPS 204 layouts. Corona uses cSHAKE256 / KMAC256 / TupleHash256 per FIPS 202 + SP 800-185 with `CORONA-*` customization strings. Even though the underlying primitives overlap, the domain-separation registries are disjoint. | ## §3 Composition surface — QuasarCert @@ -36,10 +37,10 @@ Lattice** layered certificate: ``` QuasarCert { - BLS — classical fast-path (BLS-12-381 aggregate); pre-quantum - Corona — Ring-LWE threshold (this repo) ; PQ kernel A - Pulsar — Module-LWE threshold (luxfi/pulsar) ; PQ kernel B - MLDSARollup — per-validator ML-DSA-65 rolled up via P3Q ; PQ accountability + BLS — classical fast-path (BLS-12-381 aggregate) ; pre-quantum + Corona — Module-LWE threshold, Raccoon line (this repo) ; PQ kernel A + Pulsar — Module-LWE threshold ML-DSA (luxfi/pulsar) ; PQ kernel B + MLDSARollup — per-validator ML-DSA-65 rolled up via P3Q ; PQ accountability } ``` @@ -107,15 +108,15 @@ Naming history (from `LLM.md` and `DESIGN.md`): - **Pulsar** — the M-LWE threshold ML-DSA library at `luxfi/pulsar`. Named for the rotating-neutron-star metaphor: persistent group key, rotating share distribution. -- **Corona** — the R-LWE threshold library (this repo). Named for - the luminous ring of light surrounding a star, brand-paired with - Pulsar at a different lattice layer. +- **Corona** — the Module-LWE threshold library (this repo). Named + for the luminous ring of light surrounding a star, brand-paired + with Pulsar at a different layer. A historical rename from `Pulsar` → `Corona` happened in 2026 when -the M-LWE work picked up the `Pulsar` name and the R-LWE work -retained the pulsar metaphor under the `Corona` brand. The +the ML-DSA work picked up the `Pulsar` name and the Ringtail/Raccoon-line +work retained the pulsar metaphor under the `Corona` brand. The `papers/lp-073-pulsar/` directory retains the old name; the LaTeX -sections inside refer to the R-LWE construction (now called Corona) +sections inside refer to the Module-LWE construction (now called Corona) under the historical paper name LP-073. ## §7 Two distinct primitives, one lifecycle @@ -159,7 +160,7 @@ What is preserved across Reanchor: ## §9 Relationship to the upstream academic construction Boschini, Kaviani, Lai, Malavolta, Takahashi, Tibouchi (IACR ePrint -2024/1113, IEEE S&P 2025) published the 2-round R-LWE threshold +2024/1113, IEEE S&P 2025) published the 2-round Module-LWE threshold signature construction. The paper specifies: - The 2-round signing protocol (Round 1 commit + Round 2 response + Combine). diff --git a/docs/mptc/ietf-draft-skeleton.md b/docs/mptc/ietf-draft-skeleton.md index 3a30cd8..2a57dfc 100644 --- a/docs/mptc/ietf-draft-skeleton.md +++ b/docs/mptc/ietf-draft-skeleton.md @@ -1,11 +1,11 @@ -# IETF Internet-Draft Skeleton — Corona Threshold Ring-LWE Signature +# IETF Internet-Draft Skeleton — Corona Threshold Module-LWE Signature > **HONEST FRAMING**: this document is a **draft skeleton**, not a > submitted Internet-Draft. The CFRG submission timing is contingent > on the v0.7.0 mechanized refinement work and the v0.8.0 external > audit landing. At submission scaffolding this revision, the > skeleton enumerates the sections an eventual `draft-luxfi-cfrg- -> corona-threshold-rlwe-XX.txt` would carry; it does NOT claim CFRG +> corona-threshold-mlwe-XX.txt` would carry; it does NOT claim CFRG > adoption, working-group status, or any timeline. > > The canonical algorithmic spec at this submission revision is @@ -21,14 +21,14 @@ Internet-Draft Lux Industries, Inc. Intended status: Informational [draft-XX] Expires: [TBD] [date-XX] - Corona: a 2-round threshold Ring-LWE signature scheme + Corona: a 2-round threshold Module-LWE signature scheme with proactive resharing - draft-luxfi-cfrg-corona-threshold-rlwe-XX + draft-luxfi-cfrg-corona-threshold-mlwe-XX Abstract This document specifies Corona, a 2-round threshold signature - scheme over Ring-LWE for use in post-quantum threshold signing + scheme over Module-LWE for use in post-quantum threshold signing deployments. Corona implements the construction of Boschini, Kaviani, Lai, Malavolta, Takahashi, and Tibouchi (IACR ePrint 2024/1113, IEEE S&P 2025) on a fixed parameter set, plus @@ -41,8 +41,9 @@ Abstract - §1.1 Motivation — threshold PQ signatures for blockchain finality (Quasar consensus reference). -- §1.2 Relationship to FIPS 204 ML-DSA — Corona is R-LWE; ML-DSA is - M-LWE; the two are independent. The M-LWE sibling is Pulsar +- §1.2 Relationship to FIPS 204 ML-DSA — Corona and ML-DSA are both + Module-LWE but distinct constructions (Corona is the Raccoon/Ringtail + line); the two are independent. The ML-DSA sibling is Pulsar (`luxfi/pulsar`). - §1.3 Document scope — algorithm specification + reference parameter set; deployment specifics (HSM, validator orchestration) @@ -157,7 +158,7 @@ See `SPEC.md` §13 + `hash/sp800_185.go`. ## §13 Security considerations -- §13.1 R-LWE hardness assumption. +- §13.1 Module-LWE hardness assumption. - §13.2 EUF-CMA reduction — inherited from Boschini et al. ePrint 2024/1113 §3. - §13.3 Constant-time guarantees on threshold + dkg2 paths. @@ -212,7 +213,7 @@ revisions may request: Dynamic and Resilient Threshold Signatures.* August 2025. - [FIPS204] NIST. *Module-Lattice-Based Digital Signature Standard (ML-DSA).* August 2024. (For context — Pulsar (M-LWE) targets - byte-equality with FIPS 204; Corona (R-LWE) does NOT.) + byte-equality with FIPS 204; Corona (Module-LWE) does NOT.) ## Appendix A — Test vectors diff --git a/docs/mptc/nist-mptc-category.md b/docs/mptc/nist-mptc-category.md index eb600fa..3042714 100644 --- a/docs/mptc/nist-mptc-category.md +++ b/docs/mptc/nist-mptc-category.md @@ -20,16 +20,16 @@ NIST MPTC subdivides threshold schemes into: - **N4**: ML keygen / DKG (Module-Lattice key generation, distributed) Corona aims for **N1 (construction-level threshold signing) + N4 -(distributed Ring-LWE keygen + reshare preservation)**. +(distributed Module-LWE keygen + reshare preservation)**. ### N1 framing for Corona — HONEST distinction from Pulsar NIST's Class N is defined relative to a "NIST-specified primitive." -**R-LWE threshold signing has no NIST standard at submission time.** +**Module-LWE threshold signing has no NIST standard at submission time.** This makes Corona's N1 framing structurally different from Pulsar's (which targets FIPS 204 ML-DSA byte-equality): -| Aspect | Pulsar (M-LWE) | Corona (R-LWE) | +| Aspect | Pulsar (ML-DSA) | Corona (Module-LWE, Raccoon line) | |---|---|---| | NIST standard target | FIPS 204 ML-DSA-65 | **none** | | Verifier-side interchange | byte-equal with BoringSSL FIPS / AWS-LC / OpenSSL 3.0 PQ | construction-level only (Corona's own `sign.Verify`) | @@ -59,7 +59,7 @@ Corona's submission package is structured to support **either reading**: injection) as the "novel threshold-friendly design" novelty. The downstream consumer story is identical either way: Quasar -consensus uses Corona as the R-LWE finality kernel; threshold-emitted +consensus uses Corona as the Module-LWE finality kernel; threshold-emitted signatures verify under `sign.Verify` regardless of whether NIST ultimately classifies the submission N or S. @@ -123,7 +123,7 @@ bits of post-quantum security per lattice-estimator methodology. A second parameter set targeting NIST PQ Category 3 is roadmap v0.6.0. Concrete lattice-estimator output for the current parameter set is roadmap v0.6.0 — at submission scaffolding the security claim -is qualitative (per Lux engineering's design choice against the R-LWE +is qualitative (per Lux engineering's design choice against the Module-LWE literature) rather than quantitative. ## Class N vs Class S decision (deferred to NIST) @@ -149,10 +149,11 @@ byte-equal to FIPS 204 ML-DSA-65 verified by unmodified BoringSSL FIPS / AWS-LC / OpenSSL 3.0 PQ. Pulsar's submission is at . -The R-LWE / M-LWE pair is intentional: Lux's primary-network -QuasarCert may combine Corona + Pulsar as a **Double Lattice** -layered defence (separate consumer-side design choice; not part of -this submission). +The Corona / Pulsar pair is intentional: both are Module-LWE but +distinct constructions, so Lux's primary-network QuasarCert may combine +them as a **Double Lattice** layered defence — construction- and +implementation-diversity, not lattice-family diversity (separate +consumer-side design choice; not part of this submission). ## Status diff --git a/docs/mptc/tee-integration.md b/docs/mptc/tee-integration.md index 9806a0b..d745685 100644 --- a/docs/mptc/tee-integration.md +++ b/docs/mptc/tee-integration.md @@ -17,7 +17,7 @@ +--------------------------------------------------------------+ | share storage / signing: sealed share -> Round1/Round2/Final | crypto +--------------------------------------------------------------+ -| Corona kernel: 2-round R-LWE signing | math +| Corona kernel: 2-round Module-LWE signing | math +--------------------------------------------------------------+ ``` @@ -287,7 +287,7 @@ unwrapped `KeyShare` struct. **Status**: NOT recommended. Intel SGX has a long published CVE record of micro-architectural side-channel attacks (Foreshadow, -ZombieLoad, LVI, ÆPIC Leak). Corona's R-LWE arithmetic spends +ZombieLoad, LVI, ÆPIC Leak). Corona's Module-LWE arithmetic spends significant time on `lattigo`'s NTT and Gaussian sampling — both data-dependent paths that have been demonstrated vulnerable to side-channel extraction on SGX in the published literature. diff --git a/docs/mptc/threat-model.md b/docs/mptc/threat-model.md index 3003d86..297c83f 100644 --- a/docs/mptc/threat-model.md +++ b/docs/mptc/threat-model.md @@ -31,7 +31,7 @@ adversary** with the following capabilities: | Eavesdropping on all broadcast messages | YES | | Active modification of broadcast messages | YES (Byzantine adversary; messages are signed and complaints expose tampering) | | Asynchronous corruption / late corruption mid-session | OUT OF SCOPE | -| Quantum computer | YES — the construction is post-quantum (R-LWE) | +| Quantum computer | YES — the construction is post-quantum (Module-LWE) | | Side-channel observation | OUT OF SCOPE for the math; addressed at the implementation layer via `CONSTANT-TIME-REVIEW.md` and `DEPLOYMENT-RUNBOOK.md` hardening checklist | ### §2.2 Adversary cannot @@ -84,8 +84,8 @@ protocol transcript with high probability. | Assumption | Where used | |---|---| -| Ring-LWE hardness over `R_q = Z_q[X]/(X^N + 1)` with `N = 256`, `q = 0x1000000004A01` | Inherits EUF-CMA reduction from Boschini et al. ePrint 2024/1113. | -| Ring-SIS hardness (informally; the construction's reduction passes through SIS in the random oracle model) | Same paper. | +| Module-LWE hardness over `R_q = Z_q[X]/(X^N + 1)` with `N = 256`, module dims `M = 8` × `N = 7`, `q = 0x1000000004A01` | Inherits EUF-CMA reduction from Boschini et al. ePrint 2024/1113. | +| Module-SIS hardness (informally; the construction's reduction passes through SIS in the random oracle model) | Same paper. | | cSHAKE256 / KMAC256 / TupleHash256 collision and preimage resistance | All transcript hashes, MAC derivation, PRF derivation. | | Random oracle model | The EUF-CMA reduction in Boschini et al. relies on ROM. | @@ -98,7 +98,7 @@ protocol transcript with high probability. ### §4.3 What this DOES NOT cover -- Lattice-cryptanalysis breakthroughs that reduce R-LWE security +- Lattice-cryptanalysis breakthroughs that reduce Module-LWE security parameters below current estimates. - Quantum-cryptanalytic breakthroughs against the random oracle model. @@ -199,7 +199,7 @@ historical reference and reading existing test fixtures. ### §8.1 What the chain trusts - The Bootstrap MPC ceremony at chain genesis (one-time). -- The R-LWE construction's correctness (per Boschini et al. +- The Module-LWE construction's correctness (per Boschini et al. paper). - The Go reference implementation's correctness (per code review + KAT + fuzz). diff --git a/gpu/gpu.go b/gpu/gpu.go index a91dc5a..0b45480 100644 --- a/gpu/gpu.go +++ b/gpu/gpu.go @@ -1,7 +1,7 @@ // Copyright (C) 2025-2026, Lux Industries Inc. All rights reserved. // See the file LICENSE for licensing terms. -// Package gpu wires Corona (R-LWE threshold signing) into the lattice +// Package gpu wires Corona (Module-LWE threshold signing) into the lattice // library's per-SubRing GPU NTT dispatcher. // // Decomplecting note. Corona never speaks CGO directly. The lattice diff --git a/jasmin/README.md b/jasmin/README.md index 4d75224..d3718e2 100644 --- a/jasmin/README.md +++ b/jasmin/README.md @@ -1,6 +1,6 @@ # Corona Jasmin sources -Constant-time threshold layer + centralized R-LWE Sign reference, +Constant-time threshold layer + centralized Module-LWE Sign reference, written in Jasmin (https://github.com/jasmin-lang/jasmin) for jasmin-ct verification + EasyCrypt extraction. @@ -10,7 +10,7 @@ jasmin-ct verification + EasyCrypt extraction. jasmin/ lib/ -- Shared primitives (corona_params, seed, transcript, mac, lagrange). - rlwe/ -- Centralized R-LWE Sign (single-party). + rlwe/ -- Centralized Module-LWE Sign (single-party). threshold/ -- Threshold round1.jazz, round2.jazz, combine.jazz. ``` diff --git a/jasmin/rlwe/sign.jazz b/jasmin/rlwe/sign.jazz index b3fea2b..c910bbe 100644 --- a/jasmin/rlwe/sign.jazz +++ b/jasmin/rlwe/sign.jazz @@ -1,4 +1,9 @@ -// Corona centralized R-LWE Sign reference (single-party). +// Corona centralized Module-LWE Sign reference (single-party). +// +// NAMING NOTE: the jasmin/rlwe/ directory name is a retained build-path +// identifier (referenced by scripts/checks/extraction.sh and jasmin.sh); +// the scheme is Module-LWE (threshold-Raccoon/Ringtail). The path is kept +// as-is so the high-assurance scripts keep resolving it. // // Mirrors the centralized signer for the Boschini construction (single // party holds the full secret). This is the dispatch target the diff --git a/proofs/easycrypt/Corona_N1.ec b/proofs/easycrypt/Corona_N1.ec index e2c1b6c..2d88b09 100644 --- a/proofs/easycrypt/Corona_N1.ec +++ b/proofs/easycrypt/Corona_N1.ec @@ -1,3 +1,7 @@ +(* NAMING NOTE: 'RLWE' / 'rlwe_*' identifiers and the RLWE_Functional *) +(* theory are the retained proof names for the single-party reference *) +(* signer; the scheme is Module-LWE (threshold-Raccoon/Ringtail; module *) +(* dims M=8, N=7 over Z_q[X]/(X^256+1)). Identifiers are not renamed. *) (* -------------------------------------------------------------------- *) (* Corona -- Class N1 byte-equality reduction *) (* -------------------------------------------------------------------- *) diff --git a/proofs/easycrypt/Corona_N1_Combine_Wrapper.ec b/proofs/easycrypt/Corona_N1_Combine_Wrapper.ec index 0e7cb17..d61f0fa 100644 --- a/proofs/easycrypt/Corona_N1_Combine_Wrapper.ec +++ b/proofs/easycrypt/Corona_N1_Combine_Wrapper.ec @@ -1,3 +1,7 @@ +(* NAMING NOTE: 'RLWE' / 'rlwe_*' identifiers (e.g. *) +(* combine_abs_op_lifted_eq_rlwe, rlwe_sign_op) are the retained proof *) +(* names for the single-party reference signer; the scheme is *) +(* Module-LWE (threshold-Raccoon/Ringtail; M=8, N=7, X^256+1). *) (* -------------------------------------------------------------------- *) (* Corona -- Combine wrapper bridge *) (* -------------------------------------------------------------------- *) diff --git a/proofs/easycrypt/Corona_N1_NoLeak.ec b/proofs/easycrypt/Corona_N1_NoLeak.ec index 5dc7893..ca67a37 100644 --- a/proofs/easycrypt/Corona_N1_NoLeak.ec +++ b/proofs/easycrypt/Corona_N1_NoLeak.ec @@ -1,3 +1,6 @@ +(* NAMING NOTE: 'RLWE' / 'rlwe_*' identifiers here are the retained *) +(* proof names for the single-party reference signer; the scheme is *) +(* Module-LWE (threshold-Raccoon/Ringtail; M=8, N=7 over Z_q[X]/X^256+1).*) (* -------------------------------------------------------------------- *) (* Corona -- Class N1 NO-LEAK telescoping-mask model *) (* -------------------------------------------------------------------- *) @@ -131,7 +134,7 @@ type public_transcript_t. (* per-party commitments, rounded h, z-sum, c *) type rlwe_leakage_t. (* one single-party Boschini sig's public footprint *) op module_lwe_hard : bool. (* Gaussian-masked commitments pseudorandom *) -op module_sis_hard : bool. (* extracting short s from the z-sum is R-SIS *) +op module_sis_hard : bool. (* extracting short s from the z-sum is Module-SIS *) op transcript_simulator : rlwe_leakage_t -> public_transcript_t. (* NO-LEAK REDUCTION (C / OPEN, but now a STANDARD-ASSUMPTION reduction). diff --git a/proofs/easycrypt/Corona_N1_Sign_Wrapper.ec b/proofs/easycrypt/Corona_N1_Sign_Wrapper.ec index de52491..6c48968 100644 --- a/proofs/easycrypt/Corona_N1_Sign_Wrapper.ec +++ b/proofs/easycrypt/Corona_N1_Sign_Wrapper.ec @@ -1,3 +1,7 @@ +(* NAMING NOTE: 'RLWE' / 'rlwe_*' identifiers (e.g. RLWESign, *) +(* sign_abs_op_lifted_eq_rlwe) are the retained proof names for the *) +(* single-party reference signer; the scheme is Module-LWE *) +(* (threshold-Raccoon/Ringtail; M=8, N=7, X^256+1). Not renamed. *) (* -------------------------------------------------------------------- *) (* Corona -- centralized Sign wrapper bridge *) (* -------------------------------------------------------------------- *) diff --git a/proofs/easycrypt/README.md b/proofs/easycrypt/README.md index 2baffea..8272a7a 100644 --- a/proofs/easycrypt/README.md +++ b/proofs/easycrypt/README.md @@ -4,6 +4,13 @@ This directory holds the EasyCrypt mechanization of the Class N1 (byte-equality) and Class N4 (reshare public-key preservation) correctness claims for Corona, mirroring `~/work/lux/pulsar/proofs/easycrypt/`. +> **Naming note.** Identifiers and file names containing `RLWE` / `rlwe` +> here (e.g. the `RLWESign` module type, `rlwe_sign_op`, and +> `lemmas/RLWE_Functional.ec`) are retained proof identifiers for the +> single-party reference signer the threshold protocol refines against; +> Corona is a **Module-LWE** scheme (threshold-Raccoon/Ringtail; module +> dims M=8, N=7 over `Z_q[X]/(X^256+1)`). + ## File map | File | Contains | diff --git a/proofs/easycrypt/lemmas/RLWE_Functional.ec b/proofs/easycrypt/lemmas/RLWE_Functional.ec index 88f963c..18fc430 100644 --- a/proofs/easycrypt/lemmas/RLWE_Functional.ec +++ b/proofs/easycrypt/lemmas/RLWE_Functional.ec @@ -1,3 +1,7 @@ +(* NAMING NOTE: 'RLWE' / 'rlwe_*' identifiers and the RLWE_Functional *) +(* theory are the retained proof names for the single-party reference *) +(* signer; the scheme is Module-LWE (threshold-Raccoon/Ringtail; module *) +(* dims M=8, N=7 over Z_q[X]/(X^256+1)). Identifiers are not renamed. *) (* -------------------------------------------------------------------- *) (* RLWE_Functional -- in-house EC mechanization of the Boschini et al. *) (* (ePrint 2024/1113) R-LWE single-party signature operator *) diff --git a/threshold/verify_batch.go b/threshold/verify_batch.go index e289293..f7cb9ee 100644 --- a/threshold/verify_batch.go +++ b/threshold/verify_batch.go @@ -4,7 +4,7 @@ package threshold // verify_batch.go -- parallel CPU batch verifier for Corona -// (Ring-LWE 2-round threshold) signatures. +// (Module-LWE 2-round threshold) signatures. // // Corona signatures are NOT FIPS 204 byte-equal (that's Pulsar's // Module-LWE sibling); the wire encoding is the (C, Z, Delta) ring