luxfi/corona
1
0
Fork 0
mirror of https://github.com/luxfi/corona.git synced 2026-07-27 02:50:34 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs/comments: correct lattice-family label Ring-LWE -> Module-LWE (Corona is Module-LWE)

Browse Source 
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).
This commit is contained in:
zeekay
2026-06-27 16:12:24 -07:00
parent 26eb3f35b7
commit df1db68bd0
37 changed files with 252 additions and 190 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AUDIT-2026-05.md
+1 -1
View File
@@ -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:
AUDIT-2026-06.md
+5 -5
View File
@@ -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
AXIOM-INVENTORY.md
+17 -8
View File
@@ -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. |
BLOCKERS.md
+6 -6
View File
@@ -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
CHANGELOG.md
+4 -4
View File
@@ -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.
CONTRIBUTING.md
+4 -3
View File
@@ -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.
CRYPTOGRAPHER-SIGN-OFF.md
+4 -4
View File
@@ -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.
DEPLOYMENT-RUNBOOK.md
+1 -1
View File
@@ -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.
FIPS-TRACEABILITY.md
+2 -2
View File
@@ -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).
LLM.md
+8 -8
View File
@@ -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/`)
Makefile
+2 -2
View File
@@ -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 ""
NIST-SUBMISSION.md
+10 -10
View File
@@ -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 | <https://github.com/luxfi/corona> |
@@ -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.). |
PATENTS.md
+11 -11
View File
@@ -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.
PROOF-CLAIMS.md
+15 -13
View File
@@ -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
README.md
+19 -15
View File
@@ -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.
SECURITY.md
+1 -1
View File
@@ -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:
SPEC.md
+11 -10
View File
@@ -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
SUBMISSION.md
+23 -19
View File
@@ -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
TRUSTED-COMPUTING-BASE.md
+4 -4
View File
@@ -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
cli/cli.go
+1 -1
View File
@@ -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
docs/mptc/design-decisions.md
+11 -7
View File
@@ -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. |
docs/mptc/evaluation.md
+10 -7
View File
@@ -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.
docs/mptc/family-architecture.md
+18 -17
View File
@@ -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).
docs/mptc/ietf-draft-skeleton.md
+10 -9
View File
@@ -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
docs/mptc/nist-mptc-category.md
+10 -9
View File
@@ -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
<https://github.com/luxfi/pulsar>.
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
docs/mptc/tee-integration.md
+2 -2
View File
@@ -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.
docs/mptc/threat-model.md
+5 -5
View File
@@ -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).
gpu/gpu.go
+1 -1
View File
@@ -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
jasmin/README.md
+2 -2
View File
@@ -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.
```
jasmin/rlwe/sign.jazz
+6 -1
View File
@@ -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
proofs/easycrypt/Corona_N1.ec
+4
View File
@@ -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 *)
(* -------------------------------------------------------------------- *)
proofs/easycrypt/Corona_N1_Combine_Wrapper.ec
+4
View File
@@ -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 *)
(* -------------------------------------------------------------------- *)
proofs/easycrypt/Corona_N1_NoLeak.ec
+4 -1
View File
@@ -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).
proofs/easycrypt/Corona_N1_Sign_Wrapper.ec
+4
View File
@@ -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 *)
(* -------------------------------------------------------------------- *)
proofs/easycrypt/README.md
+7
View File
@@ -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 |
proofs/easycrypt/lemmas/RLWE_Functional.ec
+4
View File
@@ -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 *)
threshold/verify_batch.go
+1 -1
View File
@@ -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