mirror of https://github.com/luxfi/pulsar.git synced 2026-09-24 00:25:52 +00:00

Files

T

zeekayandHanzo Dev 22731aba99 spec: cite Ringtail by its title, and state Corona's licence

references.bib gave ePrint 2024/1113 the title "Corona: Practical Two-Round
Threshold Signatures from Learning with Errors". The paper is "Ringtail:
Practical Two-Round Threshold Signatures from Learning with Errors", by the
six authors the entry already named correctly. A title is the authors' words.
The file's own header asks for exactly this — "verified against
https://eprint.iacr.org... Do not paraphrase or guess".

Ringtail is their scheme. Corona is Lux's implementation over Ring-LWE;
Pulsar retargets the same two-round structure to Module-LWE for FIPS 204.
The prose and the citation key now say so, and this spec is the NIST MPTC
submission, so it is the last place to get it wrong.

patent-notes.tex stated "Corona's open-source repo is Apache-2.0 with no
asserted patent claims". Corona is under the Lux Ecosystem License v1.2,
which reserves commercial use — no Apache grant and no Apache §3 patent
grant. The surrounding paragraph had been flattened by a rename into
"Pulsar ... is derivative of Pulsar" and "Pulsar (and therefore Pulsar) is a
fork"; it now names Corona and Ringtail where each is meant.

Dropped the residual Pulsar-M spelling, including the naming rule that
forbade writing "Pulsar" and required writing "Pulsar".

Co-authored-by: Hanzo Dev <[email protected]>

2026-07-29 11:12:14 -07:00

9.8 KiB

Raw Permalink Blame History

The Pulsar threshold-signature family

Pulsar is one name for a family of lattice-based threshold signature schemes. Variants share the same protocol skeleton (2-round threshold sign, Pedersen DKG with proper hiding, proactive resharing, identifiable abort) but differ in the underlying lattice problem and NIST-compatibility target.

This document is the canonical statement of the family architecture. Every Pulsar variant references it. Every NIST submission cites it. Every consumer that wires "the Pulsar family" into a downstream system points here for the variant table.

Variants

variant	repo	lattice basis	hash family (canonical)	FIPS 204 verifier interchange?	NIST MPTC class	status
Pulsar.R	`github.com/luxfi/pulsar`	Ring-LWE (`R_q`)	SHA-3 / cSHAKE256 (SP 800-185)	no — special threshold-friendly primitive	Class S1 + S4	shipping, hardened, MPTC-ready
Pulsar	`github.com/luxfi/pulsar`	Module-LWE (`R_q^k`)	SHA-3 / cSHAKE256 (SP 800-185)	yes — output is a single FIPS 204 ML-DSA σ	Class N1 + N4	bootstrap repo, spec in flight
`Pulsar.W` (reserved slot)	reserved	reserved	reserved	reserved	reserved	naming reservation; not specified

All variants share:

Protocol skeleton — 2-round threshold sign, Pedersen DKG, proactive resharing with beacon-randomized quorum, identifiable abort with signed complaints.
Hash suite — NIST SP 800-185 (cSHAKE256, KMAC256, TupleHash256) is canonical for every NIST-track variant. BLAKE3 deltas appear only in legacy / academic profiles (Pulsar.R-BLAKE3, upstream Corona) and are explicitly out-of-scope for any MPTC submission.
Constant-time discipline — every secret-touching path constant-time via crypto/subtle or local equivalents. No stdlib log in any primitive package; all logging goes through github.com/luxfi/log at fields the threat model has explicitly classified as public.
Implementation language — Go reference; C / Rust conformance after encoding-freeze gate per variant.

What differs between variants:

Algebra — Ring-LWE for Pulsar.R, Module-LWE for Pulsar. The algebraic shape determines parameter sizes, signature sizes, and the structure of the Pedersen commitment scheme.
Verification target — Pulsar.R verifies under its own verifier (a custom 2-round-aggregated check); Pulsar verifies under unmodified FIPS 204 ML-DSA.Verify. The latter is the single highest- value property of the family.
NIST submission posture — see Class column above.
Production maturity — Pulsar.R has a hardened reshare path, KAT suite, deployed code. Pulsar has a spec stub and skeleton repo.

Why one family

NIST MPTC IR 8214C accepts each variant as a separate submission package in either Class N or Class S. Submitting two as a coordinated family:

Reuses infrastructure once. The DKG harness, KAT cross-validation, transcript binding, constant-time analysis, lattice-estimator runs, patent disclosure, and IP review build to a shared pulsar-test/ and pulsar-spec-common/ set of artifacts both submissions reference.
Cross-validates the protocol skeleton. A reviewer attacking the Pedersen DKG soundness in Pulsar.R is also attacking it in Pulsar. Soundness arguments compose; reviewers don't have to redo work.
Demonstrates orthogonality. Both submissions running on the same 2-round structure with different lattice bases is itself a security argument: the family's robustness comes from a small, audited protocol skeleton with parameterized algebra, not from a one-off primitive.
Forwards-only. Adding Pulsar.W (or whichever future variant) becomes a parameter-set + algebra change against the same skeleton, not a new project. The naming reservation is pre-paid.

What goes where

artifact	shared	Pulsar.R	Pulsar
2-round protocol description	shared spec	parameterised for `R_q`	parameterised for `R_q^k`
Pedersen DKG (proper hiding)	shared spec	params for `R_q`	params for `R_q^k`
Proactive resharing (beacon-rand)	shared spec	params for `R_q`	params for `R_q^k`
Reference Go impl	shared testkit	full primitive in `pulsar/`	full primitive in `pulsar/`
KATs	shared format	`vectors/` per repo	`vectors/` per repo
Lattice estimator	shared script	parameter file per variant	parameter file per variant
Patent claims	shared review	repo-local `patent-notes.md`	repo-local `patent-notes.md`
MPTC technical specification PDF	NO	`pulsar/spec/pulsar-r.pdf`	`pulsar/spec/pulsar.pdf`
MPTC submission package	NO — separate Class S vs Class N	one per variant	one per variant

Two separate MPTC packages, one shared technical foundation. The shared material is brought in by reference from each submission's spec PDF, matching how PQ-CRYSTALS submitted Dilithium and Kyber as related algorithms in Round 3.

Naming discipline

The umbrella name is Pulsar. Always capitalised, no hyphen.
A specific variant is Pulsar.X where X is one uppercase letter identifying the lattice basis: Pulsar.R (Ring-LWE), Pulsar (Module-LWE). The dot is part of the name in prose; in identifiers the canonical machine form is pulsar-r, pulsar (lowercase, hyphen).
Variants do not carry the lattice basis in the umbrella name. Calling Pulsar.R "Corona-Pulsar" or "RPulsar" is wrong. Corona is a separate academic upstream (luxfi/corona) that Pulsar.R forks; Pulsar.R is not Corona.
HashSuiteID byte (per HIP-0077 §"Lux consensus PQ modes") identifies the hash family, not the variant. Pulsar.R and Pulsar canonical profiles both use HashSuiteSHA3 = 2. A future Pulsar with a different hash family (e.g. SHAKE256 only) would claim a new HashSuiteID without renaming the variant.

Repo organisation

~/work/lux/
├── pulsar/                ← Pulsar.R (R-LWE, production fork of Corona)
│   ├── sign/
│   ├── primitives/
│   ├── dkg2/              ← Pedersen DKG over R_q
│   ├── reshare/           ← proactive resharing
│   ├── hash/              ← Pulsar-SHA3 + Pulsar-BLAKE3 (legacy)
│   └── ...
├── pulsar/              ← Pulsar (M-LWE, FIPS 204-compatible)
│   ├── ref/go/
│   ├── spec/              ← own MPTC technical spec PDF
│   ├── docs/              ← family-architecture.md = THIS file
│   └── ...
├── corona/              ← academic upstream (NOT Pulsar; cited as the
│                            R-LWE 2-round skeleton's origin)
└── consensus/
    └── protocol/quasar/   ← witness orchestrator that consumes Pulsar
                              variants via WitnessProducer interface

The consensus/protocol/quasar/ orchestrator binds to Pulsar variants through QWitnessProducer (interface in consensus/protocol/quasar/witness_producer.go). Quasar doesn't know which variant produces the witness — it gets a []byte and a HashSuiteID. Variants are interchangeable at the orchestration layer, which is exactly the orthogonality the family architecture claims.

NIST submission strategy

Per CTO Decision 4 (recorded in this branch's HIP-0077 process notes):

Submit BOTH. Pulsar leads (Class N1+N4, FIPS 204 verifier-interchangeable, highest strategic value). Pulsar.R parallel (Class S1+S4, established production code, demonstrates the family's R-LWE branch). Withdrawing either wastes existing work; submitting both forces the team to factor shared infrastructure into reusable modules — the orthogonality requirement.

Single Git tag, simultaneous cut: mptc-preview-2026 on pulsar and pulsar at the same SHA discipline. Both submissions reference frozen artifacts. Drift between the two repos after the tag is only allowed via amendments NIST permits in the public-analysis window.

Status

Pulsar.R production code (shipping in Lux primary network)
Pulsar.R hardening: F8 (no log of secret state), F9 (constant-time reshare), F12 (LIGHT_MNEMONIC guard)
Pulsar.R MPTC spec doc finalised (pulsar/spec/pulsar-r.pdf to be added)
Pulsar.R mptc-preview-2026 tag
Pulsar repo bootstrap (pulsar/)
Pulsar Module-LWE algorithm body in spec (in flight via scientist agent)
Pulsar reference implementation
Pulsar FIPS 204 cross-validation (output interchangeability proof)
Pulsar mptc-preview-2026 tag
Family architecture cross-reference baked into HIP-0077

9.8 KiB Raw Permalink Blame History Unescape Escape