magnetar/SUBMISSION.md

NIST MPTC Submission --- Magnetar

v1.0 framing. This document is a v0.x archival snapshot. Magnetar v1.0 ships two primitives: per-validator standalone and THBS-SE (Threshold Hash-Based Signatures with Selected-Element Reconstruction). See README.md, SPEC.md, THBS-SPEC.md, and CHANGELOG.md::[1.0.0] for v1.0 normative content.

This document is the cover sheet for the Magnetar submission to the NIST Multi-Party Threshold Cryptography (MPTC) project. It is written for NIST reviewers and points at every artifact a reviewer needs.

The magnetar repository is the single canonical home for the submission: it carries the Go reference implementation under ref/go/pkg/magnetar/, the cover sheet, the construction specification, the deterministic KAT generator, the deployment runbook, and the high-assurance gate orchestration. A NIST reviewer gets a self-contained checkout that does not require network access.

The repository is active (not frozen). The submission tarball is cut from a tag on main at NIST's deadline via scripts/cut-submission.sh; reviewer feedback and post-submission patches land in this same repository so the artifact chain stays auditable.

Date stamp (this revision): 2026-05-18.

Maturity stamp: Tier A documentation shape complete at v0.3.0. This submission is not NIST-ratified, not FIPS 140-3 validated, not ACVP-validated. It IS FIPS-anchored at the single-party layer (FIPS 205 SLH-DSA). The threshold-overlay layer is novel; the byte-equality property to single-party FIPS 205 is the load-bearing N1 claim.

At a glance

Field	Value
Submission name	Magnetar
Submitting organisation	Lux Industries, Inc.
Algorithm	Threshold SLH-DSA (FIPS 205) — reveal-and-aggregate over the SLH-DSA scheme seed
Target NIST MPTC classes	N1 (threshold signing, byte-identical to single-party FIPS 205 SLH-DSA on the reconstructed master seed) + N4-analog (multi-party key generation; public-key preservation across resharing is on the v0.4 roadmap)
Underlying construction	FIPS 205 SLH-DSA (single-party layer); v0.1 reveal-and-aggregate Shamir VSS of the SLH-DSA scheme seed over GF(257) (threshold overlay)
Hash family	SHA-3 / SHAKE (FIPS 202) and cSHAKE256 / KMAC256 (SP 800-185) for every Magnetar-specific transcript hash
Parameter sets	SLH-DSA-SHAKE-192s (recommended; NIST PQ Cat 3), SLH-DSA-SHAKE-192f (Cat 3 "fast"), SLH-DSA-SHAKE-256s (Cat 5)
Round count	DKG = 3 rounds (Round-1 deal; Round-2 transcript digest; Round-3 share assembly). Threshold sign = 2 rounds (commit + reveal).
Signature output	Byte-identical to single-party FIPS 205 slhdsa.SignDeterministic on the reconstructed master seed (the headline N1 claim)
Repository	https://github.com/luxfi/magnetar (single canonical home: code, spec, KAT, runbook, cut tool)
Algorithm source	This repository, ref/go/pkg/magnetar/. Latest tagged release at this revision: v0.2.0 (Tier B); this revision targets v0.3.0 (Tier A documentation shape complete).
Tarball cut tool	scripts/cut-submission.sh (tags from main, regenerates KATs deterministically, runs the test suite, tars)
Submission tag	submission-YYYY-MM-DD (cut from main at deadline)
Spec	SPEC.md (in-tree construction specification)
License	BSD-3-Clause (code) — see LICENSE
Patent posture	Royalty-free grant — see PATENTS.md. Lux Industries grants a worldwide, royalty-free, irrevocable patent license to any implementation conformant to the Magnetar construction released under BSD-3-Clause or compatible OSI license, OR any NIST MPTC / PQC / ACVP submission, validation, or interoperability test. Defensive termination mirrors Apache-2.0 §3.
Sibling submissions	Pulsar (luxfi/pulsar) — M-LWE threshold ML-DSA with FIPS 204 byte-equality (Tier A, sister submission). Corona (luxfi/corona) — R-LWE threshold (Tier A documentation shape; no FIPS standard target). Independent submissions; reviewable separately.

Headline claim

Every signature produced by a Magnetar threshold ceremony (DKG → Round-1 commit → Round-2 reveal → Combine) is byte-identical to the signature single-party FIPS 205 slhdsa.SignDeterministic(slhdsa.Scheme(ID).DeriveKey(S), m, ctx) would produce on the same reconstructed master seed S, message m, and context ctx. Verification under unmodified FIPS 205 slhdsa.Verify therefore accepts Magnetar signatures with no code change.

This is the Class-N1 byte-equality claim, anchored against FIPS 205 SLH-DSA (NIST PQ category 3 / 5 stateless hash-based signature standard, 2024).

Verifier-side story (load-bearing for N1 framing). Because FIPS 205 SLH-DSA IS a NIST standard, Magnetar's N1 claim has the strong form: a Magnetar threshold signature must verify under any FIPS 205-conformant verifier. The Magnetar verify.go is a thin dispatch over circl/slhdsa.Verify, which is the FIPS 205 §10.3 verifier verbatim. A reviewer can — and the test suite does — cross-check Magnetar threshold-emitted bytes against cloudflare/circl's FIPS 205 verifier; the byte-identity invariant is empirically realized by TestN1_ByteEquality_* over (committee, threshold) configurations (3,2), (5,3), (7,4).

Algorithm scope

The algorithm being submitted is the Magnetar implementation at luxfi/magnetar v0.3.0. The single-party signing primitive is FIPS 205 SLH-DSA, unchanged in its math (via cloudflare/circl's audited Go reference), plus the following production threshold lifecycle layers that FIPS 205 does not specify (these are Magnetar's contribution to the submission package):

1. Byte-wise Shamir VSS of the SLH-DSA scheme seed over GF(257) — ref/go/pkg/magnetar/shamir.go. Distributes the 96-byte (192s/192f) or 128-byte (256s) FIPS 205 scheme seed across n committee members at reconstruction threshold t. The choice of GF(257) is the smallest prime > 255 (so every byte fits as a distinct field element); shares are encoded as one big-endian uint16 per byte position, matching the byte-equal property byte-wise.

2. Three-round DKG over the scheme seed — ref/go/pkg/magnetar/dkg.go. Round-1 dealers broadcast per-recipient envelopes carrying that recipient's Shamir share plus the dealer's full contribution to the joint seed. Round-2 broadcasts a transcript digest binding the entire ordered envelope set. Round-3 reconciles digests (identifiable abort on equivocation) and computes each party's share of the master byte-sum + the group public key. v0.1 ships plaintext envelopes for KAT determinism; v0.4 wraps them under ML-KEM-768 to recipient identity keys (BLOCKERS.md BLK-4 path, matching Pulsar's CR-8 closure).

3. Two-round threshold sign with commit-bind reveal — ref/go/pkg/magnetar/threshold.go + combine.go. Round-1 each signer commits to D_i = cSHAKE256(mask || masked_share || tau_1) where tau_1 = (sid, attempt, quorum, pk, msg). Round-2 reveals (mask, masked_share). Combine re-derives every D_i from the reveals, gates each share on ctEqual32(D'_i, D_i), recovers each share via masked XOR mask, Lagrange-reconstructs the master byte-sum, applies the cSHAKE256 mix bit-for-bit identical to DKG Round-3, and calls FIPS 205 SignDeterministic on the reconstructed seed-derived key.

4. Identifiable abort with attributable evidence — dkg.go complaint emission (ComplaintEquivocation on DKG Round-3 digest mismatch; conflicting digest pair is the evidence blob). ComplaintBadDelivery on malformed envelopes. ComplaintMACFailure reserved for v0.2 (per-pair MAC layer, currently omitted — reveal-and-aggregate trust model already places the aggregator in the TCB; MACs close a session-bind hole that doesn't matter under v0.1 trust caveat).

5. Domain-separated hash suite — ref/go/pkg/magnetar/transcript.go centralises every Magnetar cSHAKE256 / KMAC256 call. All cSHAKE function-name "Magnetar"; customisation tags MAGNETAR-DKG-COMMIT-V1, MAGNETAR-DKG-TRANSCRIPT-V1, MAGNETAR-SIGN-R1-V1, MAGNETAR-SIGN-MASK-V1, MAGNETAR-SEED-SHARE-V1. Protocol-wide domain-separation context lux-magnetar-v0.1.

What to read first

A reviewer with limited time should read in this order:

1. SUBMISSION.md (this file) — submission metadata and headline
2. NIST-SUBMISSION.md — one-page executive summary
3. SPEC.md — standalone construction specification
4. PROOF-CLAIMS.md — what is claimed vs not (HONEST framing — no machine-checked refinement proof at this submission; FIPS-anchored byte-equality empirical at the test-vector level)
5. TRUSTED-COMPUTING-BASE.md — implementation TCB (Go + cloudflare/circl SLH-DSA + crypto/subtle)
6. FIPS-TRACEABILITY.md — FIPS 205 § → code mapping
7. AXIOM-INVENTORY.md — construction-level + implementation-level axioms; closure plans for the proof-tier roadmap
8. PATENTS.md — royalty-free patent grant text
9. DEPLOYMENT-RUNBOOK.md — operator-facing trust-model disclosure (v0.1 reveal-and-aggregate aggregator-as-TCB)
10. BLOCKERS.md — Tier B → A path; outstanding gates
11. CRYPTOGRAPHER-SIGN-OFF.md — internal review verdict
12. README.md — repository layout and how to reproduce

What to run

The reproducibility gate is scripts/cut-submission.sh against the tarball extract — the entire submission is self-contained, so no network access is required:

tar xzf submission-YYYY-MM-DD.tar.gz
cd magnetar
GOWORK=off go build ./...
GOWORK=off go test -count=1 -short -timeout 240s ./ref/go/pkg/magnetar/
GOWORK=off go run ./ref/go/cmd/genkat -out=vectors/   # regenerate KATs deterministically

The test suite includes TestN1_ByteEquality_ThresholdMatchesCentralized (across (3,2), (5,3), (7,4) configurations) and TestN1_ByteEquality_DifferentQuorumsSameSignature (the same DKG output under two distinct signing quorums yields byte-identical signatures). Both are the load-bearing N1 evidence.

To cut a fresh tarball (maintainer-side):

scripts/cut-submission.sh                       # dry-run, no tarball
scripts/cut-submission.sh submission-2026-11-16 # production cut + tag

The cut script verifies a clean tree, regenerates KATs from the in-tree canonical implementation, re-runs the test suite (including N1 byte-equality), tars the entire submission checkout, and prints the SHA-256.

Class N1 — Byte-equal to single-party FIPS 205

The N1 claim is asserted at three levels of evidence (one fewer than Pulsar at full Tier A; the missing level is the machine-checked refinement chain — EC theory shells for the threshold overlay layer remain a roadmap item, multi-month research):

Evidence	Where
Algorithmic argument	SPEC.md §6 (Class-N1-analog byte-equality claim) + the construction-equivalence proof sketch
Test harness	ref/go/pkg/magnetar/n1_byte_equality_test.go — three (committee, threshold) configurations; byte-identity asserted via bytes.Equal
KAT determinism	vectors/{keygen,sign,verify,threshold-sign,dkg}.json regenerated deterministically by ref/go/cmd/genkat
Cross-implementation verifier	Magnetar's Verify is a thin dispatch over cloudflare/circl/sign/slhdsa.Verify, which is the FIPS 205 §10.3 verifier verbatim. Any FIPS 205-conformant verifier accepts Magnetar threshold-emitted bytes.

What Magnetar DOES NOT yet provide vs Pulsar Tier A:

• No EasyCrypt refinement chain for the threshold overlay layer. (FIPS 205 SLH-DSA itself has the libjade formal artifacts available for the single-party layer; the threshold overlay is novel and not yet mechanized. See AXIOM-INVENTORY.md §2 closure plan.)
• No Lean ↔ EC algebraic bridge files specific to Magnetar. (Magnetar's Shamir / Lagrange operations are algebraically identical to Pulsar's GF(257) variant; cross-citation to Pulsar's proofs/lean-easycrypt-bridge.md is the closure target, see AXIOM-INVENTORY.md §2.)
• No Jasmin high-assurance implementation of the threshold overlay. (libjade covers SLH-DSA single-party; the threshold overlay is pure Go.)
• No machine-checked Class N1 byte-equality theorem for the threshold overlay layer.

The honest framing for Magnetar is: production-hardened implementation of a FIPS-anchored single-party primitive with a novel reveal-and-aggregate threshold overlay, NOT machine-checked refinement against FIPS 205. The mechanized proof tier for the threshold overlay remains a roadmap item; see PROOF-CLAIMS.md for the narrow stated claim and the closure path.

Class N4-analog — Public-key preservation across resharing

Multi-party reshare with public-key preservation is on the v0.4 roadmap (see BLOCKERS.md BLK-4 "Reshare protocol"). The v0.1 construction supports DKG → threshold-sign → Combine but does NOT ship a Refresh or ReshareToNewSet primitive. Class N4 framing is therefore "N4-analog" at v0.3.0: the construction admits a reshare protocol with the same byte-equality property to FIPS 205 under the reconstructed seed, but the protocol itself is not yet implemented.

The N4-equivalent claim, when v0.4 lands, will state: any DKG share set can be Refresh-rotated (same committee, fresh shares) or ReshareToNewSet-rotated (committee rotation) such that any post-reshare threshold-sign produces signatures verifiable under the byte-identical unchanged group public key.

High-assurance track — HONEST DELTA vs Pulsar

Pulsar ships an EasyCrypt + Lean + Jasmin high-assurance track that mechanically refines its Class N1 byte-equality claim against a formal model of FIPS 204. Magnetar does NOT ship that. The honest delta:

Pulsar artifact	Magnetar equivalent	Status
13/13 EasyCrypt files compile, 0/0 admits (refinement chain)	none	NOT PRESENT — threshold-overlay EC theory shells are roadmap v0.4+, multi-month research project, see AXIOM-INVENTORY.md §2
5/5 Lean ↔ EC algebraic-bridge files	none specific to Magnetar	NOT PRESENT — Shamir / Lagrange algebraically identical to Pulsar's GF(257) variant; cross-citation closure on roadmap, see AXIOM-INVENTORY.md §2
3/3 jasmin-ct blocking on threshold layer	none for the threshold overlay	NOT PRESENT — libjade covers FIPS 205 SLH-DSA single-party; threshold overlay is pure Go
Class N1 byte-equality theorem (mechanized)	empirical byte-equality at the test-vector level only	NOT MECHANIZED — see PROOF-CLAIMS.md §3
cloudflare/circl FIPS 205 cross-validation	Verify dispatches to circl's FIPS 205 verifier; TestN1_ByteEquality_* is the load-bearing harness	PRESENT — circl is the canonical Go FIPS 205 implementation

What Magnetar DOES offer at this submission-time:

1. Production-hardened reference implementation in Go (ref/go/pkg/magnetar/, ~2200 LOC). Single-party + DKG + threshold sign + Combine. Three FIPS 205 parameter sets.
2. KAT-deterministic outputs under the Magnetar hash suite (cSHAKE256 / KMAC256 per FIPS 202 + SP 800-185). Vectors at five profiles: keygen, sign, verify, threshold-sign, dkg. Deterministic regeneration via ref/go/cmd/genkat.
3. Byte-identity N1 evidence: TestN1_ByteEquality_ThresholdMatchesCentralized proves at three configurations that threshold-Combine output is byte-equal to single-party slhdsa.SignDeterministic on the same seed.
4. Identifiable-abort evidence pipeline at the DKG layer (ComplaintEquivocation carries the conflicting digest pair).
5. Honest gap disclosure — PROOF-CLAIMS.md §3 enumerates every property NOT proved; BLOCKERS.md enumerates the Tier B → A gates.
6. Reproducibility commitment — scripts/cut-submission.sh is deterministic from fixed seeds; the KAT generator's output is byte-stable across runs.

What this submission does NOT claim

• No formal mechanized refinement of the threshold overlay layer against FIPS 205. EasyCrypt / Lean / Jasmin theories for the Magnetar threshold layer are roadmap items, multi-month research. See PROOF-CLAIMS.md §3.1 and AXIOM-INVENTORY.md §2.
• No threshold secrecy without aggregator trust. Magnetar v0.1 is reveal-and-aggregate: the aggregator process holds the reconstructed master seed in memory for the duration of one Combine call. This is the same trust caveat Pulsar v0.1 carries; documented in DEPLOYMENT-RUNBOOK.md with the TEE / mlock / ptrace-off hardening matrix. A v0.2 full-MPC construction (aggregator never sees the seed) is on the research path; see BLOCKERS.md.
• No statistical constant-time validation (dudect) of the threshold layer. The Magnetar threshold-layer code paths use constant-time primitives (ctEqual32 / ctEqualSlice) for every commit verification and key equality check, but no statistical timing harness ships at v0.3.0. Roadmap v0.4+. See PROOF-CLAIMS.md §3.4.
• No ML-KEM-768 envelope wrapping of DKG Round-1 envelopes in v0.1 — envelopes are plaintext. A passive network observer can see the per-recipient share + dealer contribution. v0.4 closes this channel by wrapping envelopes under recipient identity keys (matching Pulsar's CR-8 closure). See BLOCKERS.md BLK-4.
• No reshare protocol in v0.1. Class N4-analog will be claimed at v0.4 when Refresh and ReshareToNewSet primitives land. See BLOCKERS.md BLK-4.
• No external cryptographic audit. Internal cryptographer sign-off (CRYPTOGRAPHER-SIGN-OFF.md) is the v0.3.0 review; an external lab engagement is roadmap, see BLOCKERS.md BLK-9.
• No FIPS 140-3 module validation — applies to packaged cryptographic modules, not this reference implementation. Downstream of this submission.
• No ACVP / CAVP algorithm validation certificate for the threshold layer — no NIST ACVP test vector set exists for threshold SLH-DSA. The single-party FIPS 205 layer in cloudflare/circl is independently ACVP-testable; the threshold overlay is not.
• No identifiable abort under network partition — synchronous network assumption only; asynchronous identifiable abort is a separate problem.
• No post-quantum hardness claim beyond FIPS 205's analysis. SLH-DSA's security rests on collision/preimage resistance of the underlying hash (SHAKE for the Magnetar parameter sets); NIST's FIPS 205 analysis is the substrate.

Comparison to sibling and related submissions

Submission	Hardness basis	Round count	Output story	NIST class
Magnetar (this)	Hash-based (FIPS 205 SLH-DSA collision/preimage resistance)	DKG=3 + sign=2	Byte-equal to single-party FIPS 205 SLH-DSA on reconstructed seed	N1 (+ N4-analog at v0.4)
Pulsar (luxfi/pulsar)	Module-LWE (FIPS 204 ML-DSA)	2	Byte-equal to FIPS 204 ML-DSA-65	N1 + N4
Corona (luxfi/corona)	Ring-LWE (Boschini et al. ePrint 2024/1113)	2	Construction-level interchangeable; no NIST standard target	N1 + N4
FROST (academic upstream)	Discrete log / Schnorr	2	EdDSA-compatible	not MPTC

The hash-based / M-LWE / R-LWE triple is intentional. Lux's Polaris cert profile MAY combine Magnetar (hash-based) and Pulsar (M-LWE) and Corona (R-LWE) as a cross-family layered defence so a break in any single family (lattice or hash) does not break finality. That layered combination is the consumer's design choice and is not part of this submission. Magnetar stands alone as an MPTC Class N1 candidate (with N4-analog roadmap).

Contact

• Primary: z@lux.network (Lux Industries, Inc.)
• Submission coordination: mptc@lux.network
• Security disclosure: see SECURITY.md (when present) or magnetar@lux.network
• Public discussion: https://github.com/luxfi/magnetar/discussions

Reproducibility commitment

The build, test, and vector-generation scripts are deterministic from fixed seeds. A reviewer reproducing the submission tarball from submission-YYYY-MM-DD should obtain byte-identical artifacts. Drift is a build bug; please open an issue.

---

Document metadata

• Name: SUBMISSION.md
• Version: v0.1 (initial Tier A submission-package scaffolding)
• Date: 2026-05-18
• Submission package version: Magnetar v0.3.0 (Tier A documentation shape complete)
• Underlying library version at this revision: luxfi/magnetar v0.3.0