Files
zeekay c0399e2607 docs/comments: correct lattice-family label Ring-LWE -> Module-LWE (Corona is Module-LWE)
Corona is Module-LWE (threshold-Raccoon/Ringtail), NOT Ring-LWE. Confirmed in code: sign/sign.go samples A in R_q^{8x7} (sign.go:87 SamplePolyMatrix M=8,N=7), secret s a rank-7 ring vector, b=A*s+e (sign.go:106-107) over R_q=Z_q[X]/(X^256+1) (LogN=8), q=0x1000000004A01 -- rank>1 module structure, not rank-1 ring-LWE. threshold/threshold.go:4-5 already said Module-LWE.

Fixed the family label across README, SPEC, SUBMISSION, NIST-SUBMISSION, PATENTS, LLM, CONTRIBUTING, SECURITY, CHANGELOG, DEPLOYMENT-RUNBOOK, Makefile, AXIOM-INVENTORY, PROOF-CLAIMS, BLOCKERS, CRYPTOGRAPHER-SIGN-OFF, FIPS-TRACEABILITY, TRUSTED-COMPUTING-BASE, AUDIT-2026-05/06, docs/mptc/*, jasmin/README, 3 Go comments + cli help string.

Also corrected the downstream false claim that Corona (Ring-LWE) and Pulsar (Module-LWE) are 'different lattice families' giving 'structural/family diversity': both are Module-LWE, so the Double-Lattice defense is construction/implementation diversity (threshold-Raccoon vs ML-DSA), not hardness-family diversity; a Module-LWE break affects both legs (hash-based Magnetar is the assumption-diversifier). Fixed companion R-SIS -> Module-SIS where it was the module scheme's SIS assumption; added the Langlois-Stehle (DCC 2015) Module-LWE citation alongside LPR 2010.

Delicate artifacts: proof identifiers (rlwe_sign_op, RLWE_Functional theory/file, *_eq_rlwe bridges, CentralRLWESign, RLWESign, rlwe_compute_*) were NOT renamed -- EasyCrypt/jasmin toolchains are absent here so a rename cannot be compile-verified, and .assurance/ gates parse those names. Added clarifying naming notes to the 5 prominent .ec files, proofs/easycrypt/README.md, AXIOM-INVENTORY.md, and jasmin/rlwe/sign.jazz. .assurance/*.txt left untouched (already say Module-LWE/Module-SIS; rlwe tokens are gate-parsed identifiers). Left AUDIT-2026-06.md:463 historical rename-log and the ProtoStar-LWE paper-title substring untouched.

go build ./... and go test ./... green (GOWORK=off; all packages ok).
2026-06-27 16:12:24 -07:00

341 lines
16 KiB
Markdown

# 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
> Multi-Party Threshold Cryptography (MPTC) project.
## TL;DR
Lux Industries, Inc. ("Lux") grants a **worldwide, royalty-free,
non-exclusive, irrevocable patent license** for any implementation of
the Corona threshold signature construction that is either (a)
licensed under Apache-2.0 or a compatible OSI-approved license, OR
(b) is part of a NIST MPTC / PQC / ACVP submission, validation, or
interoperability test.
The grant terminates automatically and prospectively against any
party that asserts a patent claim against Corona, the underlying
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.
The full text of the grant is in **§3 Patent Grant** below.
## §1 Scope of the IP statement
This document covers patent rights and patent posture for:
- The **Corona threshold-signing construction** as implemented at
`github.com/luxfi/corona` (DKG → Round-1 → Round-2 → Combine →
Reshare).
- The **reference implementation** in `sign/`, `threshold/`,
`dkg2/`, `reshare/`, `primitives/`, and `hash/`.
- The **test-vector format** in `cmd/*_oracle*/` and the
cross-runtime byte-equality manifest at
`scripts/regen-kats.manifest.sha256`.
It does NOT cover, and explicitly DISCLAIMS, the following prior art:
| Component | Status |
|---|---|
| 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. |
| HJKY97 proactive secret sharing (Herzberg, Jakobsson, Jarecki, Krawczyk, Yung. CRYPTO 1995/1997) | Academic prior art. Corona's `Refresh` primitive follows the HJKY97 same-set refresh shape. |
| Desmedt-Jajodia 1997 / Wong-Wang-Wing 2002 redistribution to new access structures | Academic prior art. Corona's `ReshareToNewSet` follows this VSR composition. |
| SHAKE128 / SHAKE256 / Keccak / cSHAKE / KMAC / TupleHash (FIPS 202 + SP 800-185) | Public domain — NIST standards. |
| FROST threshold-signing baseline (academic literature) | Published in IACR ePrint; no novelty asserted here against the published construction. |
| LSS (Linear Secret Sharing) framework (Seesahai 2025) | Academic prior art. Corona's lifecycle interfaces (Generation, RollbackFrom, Bootstrap Dealer / Signature Coordinator role separation) follow the LSS pattern. |
## §2 What Lux considers patentable (high level)
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 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.
### §2.1 Pedersen DKG over `R_q` with hiding blinds
The specific adaptation of Pedersen verifiable secret sharing to the
`R_q^M` polynomial-vector setting, where coefficient commitments
take the form `C^(k) = A·NTT(s^(k)) + B·NTT(r^(k))` for per-
coefficient hiding blind `r^(k)`. The adaptation includes:
- Domain-separated generator derivation from `sid_dkg` via cSHAKE256
(`CORONA-DKG-v1` customization string).
- Per-pair authenticated KEX (ML-KEM-768 hybrid recommended).
- Complaint round with publicly-verifiable evidence.
- Qualified-set selection with deterministic ordering.
Detailed in `papers/lp-073-pulsar/lp-073-pulsar-pedersen-dkg.tex`;
implementation in `dkg2/`.
### §2.2 Class N4 reshare with public-key preservation over `R_q`
Proactive secret-sharing protocol that rotates shares across
committee changes while preserving the group public key `(A, bTilde)`
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 Module-LWE).
- `ReshareToNewSet` — set rotation with `t_old → t_new` threshold
changes (Desmedt-Jajodia / Wong-Wang-Wing lineage adapted to
Module-LWE).
Detailed in `papers/lp-073-pulsar/lp-073-pulsar-resharing.tex`;
implementation in `reshare/`.
### §2.3 Activation certificate as circuit-breaker
The specific protocol step where, after a Reshare math completes,
the new committee threshold-signs an activation message under the
**unchanged** group public key using their freshly-derived shares;
only on successful verification does the chain mark the new epoch
live. The activation message canonical bytes include
`key_era_id || old_epoch || new_epoch || old_validator_set_hash ||
new_validator_set_hash || reshare_transcript_hash` with
domain-separated prefix `QUASAR-CORONA-ACTIVATE-v1`. Detailed in
`DESIGN.md` §"Activation cert (the circuit-breaker)"; implementation
in `reshare/activation.go`.
### §2.4 Constant-time Pedersen slot equality with `eq &=` accumulation
The specific implementation pattern in `dkg2/dkg2.go:VerifyShareAgainstCommits`
where Pedersen identity verification iterates over all `M` slots,
accumulating `eq &= subtle.ConstantTimeCompare(lhs_bytes, rhs_bytes)`
with NO early return on per-slot mismatch — preventing the recipient's
response-time variation from leaking which slot first diverged.
Specifically addresses Findings 5/6 of the upstream
RED-DKG-REVIEW.md; the same idiom can apply to any `(A, B)`-based
Pedersen commit scheme over a polynomial ring.
### §2.5 Hash-suite injection through every Sign-path primitive
The specific architectural pattern where every Sign-path primitive
(`PRNGKey`, `PRNGKeyForRound`, `GenerateMAC`, `GaussianHash`, `PRF`,
`Hash`, `LowNormHash`) takes a `hash.HashSuite` as its first argument
with `nil` resolving to the production default (`Corona-SHA3` via
KMAC over cSHAKE256), enabling per-deployment hash-profile selection
without code changes. Detailed in `CHANGELOG.md` "F22 hash-suite
injection into Sign"; implementation in `primitives/hash.go` +
`hash/sp800_185.go`.
## §3 Patent grant (the load-bearing text)
> **CORONA PATENT GRANT — v1.0**
>
> Lux Industries, Inc. ("Lux"), a Delaware corporation, hereby grants
> to any person or entity ("You") a **worldwide, royalty-free,
> non-exclusive, no-charge, fully-paid-up, irrevocable** (except as
> stated in §3.2 below) patent license to make, have made, use, offer
> to sell, sell, import, and otherwise transfer any implementation of
> the Corona threshold-signing construction described in `SPEC.md`
> and `DESIGN.md` (the "Construction"), provided that such
> implementation:
>
> (a) Implements the Construction (signing, DKG, or proactive
> resharing) in a manner consistent with the algorithmic
> specification (the "Construction-Conformance Condition"); AND
>
> (b) Is licensed to the public under (i) the Apache License, Version
> 2.0, or (ii) any other Open-Source-Initiative-approved license
> compatible with Apache-2.0, OR (c) is part of a submission to,
> validation under, or interoperability test for the NIST
> Multi-Party Threshold Cryptography (MPTC) project, the NIST
> Post-Quantum Cryptography (PQC) standardization process, or any
> successor program administered by NIST.
>
> The license granted in this §3 covers all "Necessary Claims" owned
> or controllable by Lux that would, in absence of this license,
> necessarily be infringed by an implementation meeting (a) and (b).
> "Necessary Claims" means claims of any patent or patent
> application that are essential for compliance with the Corona
> specification, that Lux has the right at the time of execution to
> grant a license under.
>
> ### §3.1 Documentation and reference-implementation grant
>
> The Corona specification (`SPEC.md`, `DESIGN.md`,
> `papers/lp-073-pulsar/`), the reference implementation (`sign/`,
> `threshold/`, `dkg2/`, `reshare/`, `primitives/`, `hash/`), and the
> test vectors (under `cmd/*_oracle*/` and the cross-runtime manifest)
> are released under the Apache License, Version 2.0. The patent
> grant in this document operates in addition to (not in lieu of) the
> patent provisions in the Apache-2.0 license.
>
> ### §3.2 Defensive termination
>
> The patent license granted in this §3 terminates automatically and
> prospectively, without notice, with respect to any party (the
> "Asserting Party") if the Asserting Party initiates patent
> litigation (including a cross-claim or counter-claim in a lawsuit)
> alleging that:
>
> (i) The Corona construction; or
> (ii) The underlying Boschini-Kaviani-Lai-Malavolta-Takahashi-Tibouchi
> 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
> (iv) Any implementation of (i), (ii), or (iii) — including without
> limitation the reference implementation in this repository,
> independent third-party implementations, NIST ACVP/CAVP
> reference vectors, or any FIPS 140-3 validated module
> containing such an implementation,
>
> infringes any patent owned or controllable by the Asserting Party.
> Termination is prospective only; it does not undo the validity of
> any implementation distributed prior to the date the Asserting
> Party initiated the litigation.
>
> Defensive termination mirrors the patent-termination clause of the
> Apache License, Version 2.0, §3, generalized to also cover the
> underlying Boschini et al. construction, FIPS 204 ML-DSA, and
> successor NIST-standardized post-quantum signature schemes. The
> purpose is to deter patent assertion against the broader post-
> quantum signature ecosystem, not only against Corona itself.
>
> ### §3.3 No trademark license
>
> This grant does not authorize the use of Lux's trademarks
> (including "Corona", "Pulsar", "Quasar", "Lux", "Lux Industries",
> and their respective logos) except as required for reasonable and
> customary use in describing the origin of the Construction and
> reproducing the content of any NOTICE file.
>
> ### §3.4 Disclaimer
>
> THE CONSTRUCTION AND ALL ASSOCIATED MATERIALS ARE PROVIDED ON AN
> "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED. Lux shall not be liable for any damages
> resulting from the use of the patent license granted in this §3.
## §4 Filing strategy (informational)
This section is for transparency; it does not modify the grant
in §3.
Lux intends to pursue patent protection on the Corona production-
lifecycle additions as follows:
1. **US provisional application** within 12 months of public
disclosure (the NIST MPTC submission counts as public disclosure
for §102 purposes; filing before submission preserves priority).
2. **PCT international application** within 12 months of the
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
30-month deadline, prioritized by anticipated deployment markets.
4. **Continuation / divisional applications** to cover incremental
refinements (e.g., the constant-time `eq &=` Pedersen slot-equality
pattern, the activation-cert circuit-breaker, future hash-suite
profile additions).
The royalty-free grant in §3 applies to ALL such filings, present
and future, that are owned or controllable by Lux.
## §5 Why the grant is structured this way
A few notes for reviewers who might ask "why this language and not
plain public-domain dedication":
### §5.1 Defensive patent ownership protects the ecosystem
Without Lux holding the patents on the Corona production-lifecycle
additions, a third party could observe the public NIST submission,
file blocking patents on (e.g.) the activation-cert circuit-breaker
shape, and assert them against open-source implementations. Lux
holding the patents (with a royalty-free grant) removes that attack
surface.
This is the same logic that protects FRAND ecosystems and that
underlies Apache-2.0's patent grant + retaliation clause.
### §5.2 Compatibility with NIST MPTC submission terms
The NIST Multi-Party Threshold Cryptography project's submission
guidelines require submitters to provide a patent statement
specifying the IP terms under which the submitted construction may
be used. The grant in §3 satisfies that requirement and goes beyond
NIST's baseline by extending defensive termination to the underlying
Boschini et al. construction (not just Corona's production
lifecycle additions) and to all NIST-standardized post-quantum
signature schemes.
### §5.3 Compatibility with the published Boschini et al. construction
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.
Any third-party implementation of the Boschini et al. construction
is free of Corona patent assertions whether or not it adopts
Corona's lifecycle layers.
### §5.4 Defensive termination for the broader PQ ecosystem
Extending defensive termination to the underlying Boschini et al.
construction AND to FIPS 204 ML-DSA (and successors) — not just
Corona itself — converts Lux's patent portfolio into a small
deterrent against PQ-signature patent trolls. It costs Lux nothing
(Lux does not intend to assert offensively) and benefits the
ecosystem.
## §6 What this document does NOT do
- It does not assign any Lux patent rights to NIST, IETF, or any
third party. Lux retains ownership; the grant in §3 is a license.
- It does not commit Lux to maintain or prosecute any specific
patent application. Lux may abandon applications for business
reasons; the grant in §3 covers issued patents in proportion to
what is actually granted.
- It does not waive Lux's right to update the grant text (subject
to §6.1 below).
- It does not modify the Apache-2.0 license covering the
reference implementation, specification, and vectors.
- It does not claim patent rights on the Boschini et al. published
construction (academic prior art).
### §6.1 Modifications to this grant
Lux may issue future versions of this PATENTS document with
clarifications or extensions of the grant. Future versions will
apply to implementations published under the future version's
identifier. **The grant in §3 of this v1.0 document is
irrevocable for implementations relying on it**, subject only to
the defensive-termination clause in §3.2.
## §7 Contact
| Purpose | Contact |
|---|---|
| Patent / IP inquiries | `[email protected]` |
| Licensing for non-conforming implementations | `[email protected]` |
| NIST submission coordination | `[email protected]` |
| Security disclosure | See `SECURITY.md` |
For patent-claim drafting (the document an attorney would work
from), see `docs/patent-claims.md`.
---
**Document metadata**
- Document name: `PATENTS.md`
- Document version: v1.0
- Document date: 2026-05-18
- Construction version: Corona v0.2 (NIST MPTC submission package scaffolding)
- Construction repository: <https://github.com/luxfi/corona>
- License of this document: Creative Commons CC-BY-4.0 (so it
can be freely reproduced in NIST submission packages and audit
reports without modification).