mirror of
https://github.com/luxfi/pulsar.git
synced 2026-09-24 00:25:52 +00:00
docs: import remaining design docs from luxfi/pulsar-mptc consolidation
Salvage the design-doc set the May 2026 pulsar-mptc consolidation listed in its "Was here / Is now" table but never actually copied over. Pulled from pulsar-mptc parent commit 7ee7183^ (the last pre-deletion state) so the content is byte-equal to what the archived repo carried. Files imported: - SUITE.md - HANZO-CRYPTO-SUITE.md - INFORMATION-ARCHITECTURE.md - ROADMAP.md (80 KB) - SINGLE-IMPL-PLAN.md - SYNC-STATUS.md - STATUS-SUBMISSION-READINESS.md - docs/magnetar.md - docs/x-wing-sig.md Pulsar is now the single canonical home for impl + spec + proofs + KAT vectors + cut tool + design docs. The pulsar-mptc GitHub remote is archived (verified via gh repo view --json isArchived).
This commit is contained in:
@@ -0,0 +1,300 @@
|
||||
# Hanzo Crypto Suite — full inventory + packaging status
|
||||
|
||||
> Comprehensive inventory of every cryptographic construction in
|
||||
> the Lux / Hanzo / Zoo / Pars ecosystem, with packaging-status,
|
||||
> LP cross-references, and submission-readiness gap analysis.
|
||||
>
|
||||
> The Hanzo PQ Threshold Suite (`SUITE.md`) is **one subset** of this
|
||||
> broader inventory. This document is the master index.
|
||||
|
||||
## Quick orientation
|
||||
|
||||
| Category | Tiers | This document section |
|
||||
|---|---|---|
|
||||
| **Post-quantum threshold signatures** | Pulsar, Magnetar, Corona | §1 |
|
||||
| **Classical threshold signatures** | FROST, CGGMP21, LSS, BLS | §2 |
|
||||
| **Hybrid PQ signature wrappers** | X-Wing-for-Signatures (proposed) | §3 |
|
||||
| **Key encapsulation** | ML-KEM, X-Wing | §4 |
|
||||
| **Zero-knowledge / accountability** | Z-Chain PQ, P3Q precompile | §5 |
|
||||
| **FHE / confidential compute** | TFHE on F-Chain, BFV, CKKS | §6 |
|
||||
| **EVM-native PQ migration** | C-Chain + X-Chain → PQ-native | §7 |
|
||||
|
||||
## §1 PQ threshold signatures — Hanzo PQ Threshold Suite
|
||||
|
||||
Master index: `SUITE.md`. Submission package: `pulsar-mptc/` (Tier 1).
|
||||
|
||||
| Tier | Construction | LP | Repo | Spec | Proofs | NIST submission | Status |
|
||||
|---|---|---|---|---|---|---|---|
|
||||
| 1 | **Pulsar** (Threshold ML-DSA) | LP-019 ref'd | `pulsar-mptc/`, `pulsar/` | ✅ SPEC.md + spec/pulsar.tex + IETF draft | ✅ EC 13/13, Lean 5/5 | ✅ v0.1 ready | **NIST-MPTC-submission ready** |
|
||||
| 1b | **Corona** (Threshold R-LWE) | LP-020 | `~/work/lux/corona/` | partial DESIGN.md | partial DKG proofs | ❌ v0.2 target | implementation mature, packaging needed |
|
||||
| 3 | **Magnetar** (Threshold SLH-DSA) | TBD | none | `docs/magnetar.md` placeholder | ❌ | ❌ research-only | research-direction sketch |
|
||||
| 4 | **LSS** (Linear Shamir) | LP-019 + LP-141 | `~/work/lux/lps/`, `~/work/lux/mpc/` | LP-019 sections | none mechanized | ❌ wrapper-only | spec exists, no submission package |
|
||||
|
||||
**Gap to "all tiers submission-ready"**:
|
||||
- Corona: full SUBMISSION.md + SPEC.md + PROOF-CLAIMS.md + AXIOM-INVENTORY.md + PATENTS.md package mirroring Pulsar. Estimate: 2-3 weeks.
|
||||
- Magnetar: research-paper + initial DKG prototype. Estimate: 2-3 months.
|
||||
- LSS: standalone IETF draft + reference vectors. Estimate: 2 weeks.
|
||||
|
||||
## §2 Classical threshold signatures
|
||||
|
||||
Used for bridging to non-PQ chains (Bitcoin secp256k1, Ethereum
|
||||
legacy, Cosmos Ed25519, Solana, etc.). Specified in
|
||||
**LP-019: Threshold MPC for Bridge Signing** (`~/work/lux/lps/LP-019-threshold-mpc.md`).
|
||||
|
||||
| Scheme | Curve | Use case | LP | Implementation | Submission package status |
|
||||
|---|---|---|---|---|---|
|
||||
| **FROST** | Ed25519 / secp256k1 (Schnorr) | Cosmos, Bitcoin Schnorr | LP-019 | `~/work/lux/mpc/` | LP-spec mature; IETF draft `draft-irtf-cfrg-frost` exists upstream; Lux profile gap |
|
||||
| **CGGMP21** | secp256k1 (ECDSA) | Ethereum, Bitcoin legacy | LP-019 | `~/work/lux/mpc/` | LP-spec mature; submission package gap |
|
||||
| **LSS wrapper** | n/a (linear Shamir over any of the above) | dynamic resharing | LP-019 + LP-141 | `~/work/lux/mpc/`, `~/work/lux/lps/LP-141` | LP-spec mature; submission package gap |
|
||||
| **BLS** | BLS12-381 | aggregated sigs, Quasar consensus | LP-020 | `~/work/lux/crypto/`, `~/work/lux/bls/` | spec mature; submission package gap |
|
||||
|
||||
**Per user direction "100% up to spec"**: each of FROST, CGGMP21,
|
||||
LSS, BLS needs:
|
||||
1. Equivalent of `pulsar-mptc/SUBMISSION.md` (cover sheet).
|
||||
2. Equivalent of `pulsar-mptc/SPEC.md` (text spec) — partially in LP-019.
|
||||
3. Equivalent of `pulsar-mptc/PATENTS.md` (FROST and CGGMP21 are
|
||||
academically published; need defensive grant statement).
|
||||
4. Implementation-correctness proof (EC + Lean) — currently absent for FROST/CGGMP21.
|
||||
5. Constant-time analysis — partial for FROST.
|
||||
6. Test vectors — KAT format aligned with `pulsar-mptc/vectors/`.
|
||||
|
||||
Estimated total: 8-12 weeks per scheme.
|
||||
|
||||
## §3 Hybrid PQ signature wrappers — "X-Wing for Signatures"
|
||||
|
||||
> **User direction**: "ala X-Wing but for older crypto wallets"
|
||||
|
||||
X-Wing (LP-115) is a hybrid PQ KEM combining X25519 + ML-KEM-768.
|
||||
For SIGNATURES, the analogous construct is a hybrid PQ-sig wrapper
|
||||
that combines classical (Ed25519 / ECDSA) + PQ (ML-DSA / SLH-DSA)
|
||||
into a single concatenated signature.
|
||||
|
||||
**Proposed name**: `X-WING-SIG` (or `X-WING-DSA`).
|
||||
|
||||
**Construction sketch**:
|
||||
```
|
||||
HybridSig(sk_classical, sk_pq, M)
|
||||
= Sign_classical(sk_classical, "X-WING-SIG-v0||" ++ M)
|
||||
|| Sign_pq(sk_pq, "X-WING-SIG-v0||" ++ M)
|
||||
|
||||
HybridVerify(pk_classical, pk_pq, M, sig)
|
||||
= Verify_classical(pk_classical, "X-WING-SIG-v0||" ++ M, sig[..classical_len])
|
||||
∧ Verify_pq(pk_pq, "X-WING-SIG-v0||" ++ M, sig[classical_len..])
|
||||
```
|
||||
|
||||
**Security claim**: forgery requires breaking BOTH the classical
|
||||
AND PQ scheme. Useful for transitional deployment where:
|
||||
- Legacy wallets cannot upgrade to PQ-only (e.g., hardware HSMs
|
||||
pinned to ECDSA).
|
||||
- Defense-in-depth against either scheme being broken.
|
||||
- FIPS compliance during the migration window.
|
||||
|
||||
**LP status**: not yet drafted. Recommended LP-NNN slot:
|
||||
"LP-XXX: X-WING-SIG hybrid signature wrapper".
|
||||
|
||||
**Submission-package status**: none. Estimated effort to draft:
|
||||
- Spec: 1-2 weeks.
|
||||
- Implementation (Go reference + Rust crate): 1 week.
|
||||
- Lean proof (composition theorem: hybrid_secure iff classical_secure ∨ pq_secure): 2-3 weeks.
|
||||
- Test vectors: 1 week.
|
||||
|
||||
**Threshold variant**: trivially threshold-izable as
|
||||
"FROST × Pulsar" — run threshold FROST and Pulsar in parallel,
|
||||
concatenate outputs. Documented in `~/work/lux/lps/LP-019` future
|
||||
revision.
|
||||
|
||||
## §4 Key encapsulation
|
||||
|
||||
| Scheme | Standard | LP | Implementation | Status |
|
||||
|---|---|---|---|---|
|
||||
| **ML-KEM-768** | FIPS 203 | LP-012 | `~/work/lux/crypto/mlkem` | production |
|
||||
| **X-Wing** (hybrid X25519 + ML-KEM) | draft IRTF CFRG | LP-115 | `~/work/lux/crypto/xwing` | production |
|
||||
| **X-Wing+** (Lux-extended profile) | n/a | LP-115 follow-up | `~/work/lux/crypto/xwing+` | production |
|
||||
|
||||
LP-115 has the X-Wing KEM spec. No threshold KEM (not a typical
|
||||
threshold primitive).
|
||||
|
||||
## §5 ZK / accountability layer — Z-Chain PQ + P3Q precompile
|
||||
|
||||
### §5.1 Z-Chain PQ
|
||||
|
||||
**LP-063: Z-Chain** + **LP-169: Z-Chain PQ Identity Rollup**.
|
||||
|
||||
Z-Chain is a Lux-original ZK rollup providing:
|
||||
- Asynchronous identifiable abort for Pulsar (when synchronous
|
||||
network assumption fails).
|
||||
- ZK-proof-backed key registry (HIP-0078).
|
||||
- Privacy-preserving identity layer.
|
||||
|
||||
**Construction**: Groth16 proofs over the PQ-signature aggregation
|
||||
identity, posted to Z-Chain rollup, verifiable by L1.
|
||||
|
||||
**Status**:
|
||||
- LP-063: spec mature.
|
||||
- LP-169: PQ identity rollup spec mature.
|
||||
- Implementation: `~/work/lux/zchain/` (if exists; verify).
|
||||
- Submission package: not in scope for v0.1 Pulsar — separate
|
||||
Lux artifact.
|
||||
|
||||
### §5.2 P3Q precompile (EVM, slot 0x012205)
|
||||
|
||||
**P3Q** = "Post-Quantum Pulsar Proof", an EVM precompile at slot
|
||||
`0x012205` providing on-chain verification of Pulsar threshold
|
||||
signatures.
|
||||
|
||||
**Reference**: per the Lux global guidance, P3Q is a new primitive
|
||||
at its own slot, not bolted onto existing ZK or Pulsar.
|
||||
|
||||
**LP**: covered partially by LP-078 (EVM precompiles); needs a
|
||||
dedicated LP-XXX for the precompile specification (input format,
|
||||
gas cost, error cases).
|
||||
|
||||
**Implementation**: in `~/work/lux/evm/precompiles/` (verify
|
||||
path).
|
||||
|
||||
**Submission package**: not applicable (precompile, not standalone
|
||||
algorithm). The Pulsar signature verified by P3Q is the same byte
|
||||
string as a FIPS 204 ML-DSA signature, so any FIPS 204 verifier
|
||||
inside the EVM precompile suffices.
|
||||
|
||||
## §6 FHE / confidential compute
|
||||
|
||||
**LP-013: FHE GPU**, **LP-066: TFHE**, **LP-067: Confidential ERC-20**,
|
||||
**LP-068: Private Teleport**.
|
||||
|
||||
| Scheme | Use case | LP | Status |
|
||||
|---|---|---|---|
|
||||
| **TFHE** (CGGI bootstrapped, gate-level) | Generic confidential compute | LP-066 | LP-spec mature; F-Chain host (LP-134) |
|
||||
| **BFV** | Vector ops (privacy-preserving inference) | LP-013 sections | partial |
|
||||
| **CKKS** | Approximate-arithmetic (ML inference) | LP-013 sections | partial |
|
||||
|
||||
**Threshold FHE**: threshold key generation for TFHE bootstrapping
|
||||
keys is hosted on F-Chain (LP-134 split — M-Chain hosts MPC
|
||||
ceremonies, F-Chain hosts FHE). Specified in LP-019 + LP-141.
|
||||
|
||||
**Pulsar ↔ FHE composition**: not directly composed. FHE provides
|
||||
confidential compute on encrypted data; Pulsar provides
|
||||
authenticated threshold signatures on plaintext messages. They
|
||||
operate at different layers.
|
||||
|
||||
**Submission-package status**: TFHE is research-grade; no NIST
|
||||
submission target.
|
||||
|
||||
## §7 EVM-native PQ migration
|
||||
|
||||
> **User direction**: "should shift all native lux c/x chain and
|
||||
> evm native PQ"
|
||||
|
||||
**LP-012: PQ Crypto GPU**, **LP-078: EVM precompiles**.
|
||||
|
||||
Current Lux native chains:
|
||||
- **C-Chain** (EVM-compatible): uses ECDSA for transaction signing.
|
||||
- **X-Chain** (UTXO): uses ECDSA / Ed25519 hybrid.
|
||||
|
||||
**Target**: native PQ signing using Pulsar / ML-DSA at the wallet
|
||||
+ transaction layer.
|
||||
|
||||
**Migration paths**:
|
||||
|
||||
1. **Soft migration via X-Wing-Sig** (§3 above): wallets sign
|
||||
transactions with hybrid (ECDSA + ML-DSA); validators accept
|
||||
either-or-both signatures during transition.
|
||||
|
||||
2. **Hard fork to PQ-native**: protocol change requiring all
|
||||
validators to verify ML-DSA exclusively. Breaks legacy wallets.
|
||||
Requires coordinated migration window.
|
||||
|
||||
3. **Per-account opt-in**: introduce a new account type that
|
||||
requires PQ signing; legacy accounts continue with ECDSA;
|
||||
block bridge encourages opt-in.
|
||||
|
||||
**Submission-package implications**: P3Q precompile (§5.2) is the
|
||||
on-chain verifier interface. If wallets migrate to native PQ,
|
||||
P3Q's gas cost becomes the bottleneck.
|
||||
|
||||
**LP status**: migration plan not yet drafted. Recommended LP-XXX:
|
||||
"LP-XXX: C-Chain / X-Chain PQ-native migration plan".
|
||||
|
||||
## Suite-wide standards conformance matrix
|
||||
|
||||
| Construction | NIST standard | IETF draft | EasyCrypt proof | Lean proof | Jasmin CT | Test vectors | LP |
|
||||
|---|---|---|---|---|---|---|---|
|
||||
| Pulsar | FIPS 204 (parent) | draft-hanzo-pulsar-threshold-mldsa-00 | ✅ 13/13 | ✅ 5/5 | ✅ 3/3 | ✅ | LP-019 |
|
||||
| Corona | none (Lux-original) | TBD | partial | TBD | TBD | partial | LP-020 |
|
||||
| Magnetar | FIPS 205 (parent) | none | none | none | none | none | TBD |
|
||||
| LSS | none | TBD | none | none | none | partial | LP-019 + LP-141 |
|
||||
| FROST | draft-irtf-cfrg-frost (upstream) | upstream | none in Lux | none | none | upstream KATs | LP-019 |
|
||||
| CGGMP21 | none | none | none | none | none | partial | LP-019 |
|
||||
| X-Wing-Sig | none (proposed) | TBD | TBD | TBD | TBD | TBD | TBD |
|
||||
| ML-KEM | FIPS 203 | RFC drafts | n/a (KEM) | n/a | partial | upstream | LP-012 |
|
||||
| X-Wing | draft IRTF | draft-irtf-cfrg-xwing | n/a | n/a | partial | upstream | LP-115 |
|
||||
| Z-Chain PQ | none (Lux-original) | none | none | partial Lean | none | none | LP-063 + LP-169 |
|
||||
| P3Q precompile | n/a | n/a | n/a | n/a | n/a | partial | LP-078 (partial) |
|
||||
| TFHE | academic | none | none | none | none | upstream | LP-066 |
|
||||
|
||||
**Honest summary**:
|
||||
- Pulsar is the only construction with FULL submission-grade
|
||||
packaging.
|
||||
- All others have varying degrees of LP-level spec maturity but
|
||||
lack the matching SUBMISSION.md + PROOF-CLAIMS.md +
|
||||
AXIOM-INVENTORY.md + TCB + IETF draft + PATENTS.md package.
|
||||
- Bringing the full suite to Pulsar-grade packaging is a 6-12
|
||||
month coordinated effort.
|
||||
|
||||
## Recommended next-quarter work plan
|
||||
|
||||
| Q | Work |
|
||||
|---|---|
|
||||
| Q3 2026 | Pulsar NIST MPTC submission (Nov 16 deadline) |
|
||||
| Q4 2026 | Corona equivalent packaging (matching Pulsar) |
|
||||
| Q1 2027 | FROST + CGGMP21 submission packages (Lux-profile IETF drafts + EC proof scaffolding) |
|
||||
| Q2 2027 | X-Wing-Sig LP + draft + reference impl |
|
||||
| Q3 2027 | Magnetar research paper + initial DKG impl |
|
||||
| Q4 2027 | Z-Chain PQ identity rollup audit + LP-169 finalization |
|
||||
| 2028+ | Full mechanized closure of codec axioms + Lean ↔ EC translation tooling |
|
||||
|
||||
## Information-architecture invariants
|
||||
|
||||
All Hanzo Crypto Suite documents MUST satisfy:
|
||||
|
||||
1. **Canonical algorithm wiring**: `~/work/lux/lps/CRYPTO-CANONICAL.md`
|
||||
2. **Per-construction LP**: `~/work/lux/lps/LP-NNN-*.md`
|
||||
3. **Per-construction repo**: `~/work/lux/<construction>/`
|
||||
4. **Per-construction submission package** (when production-ready):
|
||||
`<repo>/SUBMISSION.md`, `<repo>/SPEC.md`, `<repo>/PATENTS.md`,
|
||||
`<repo>/PROOF-CLAIMS.md`, `<repo>/AXIOM-INVENTORY.md`,
|
||||
`<repo>/TRUSTED-COMPUTING-BASE.md`, `<repo>/FIPS-TRACEABILITY.md`
|
||||
(if FIPS-anchored), `<repo>/docs/evaluation.md`,
|
||||
`<repo>/docs/ietf-draft.md`.
|
||||
5. **Master suite index**: `pulsar-mptc/SUITE.md` (for the PQ
|
||||
Threshold Suite) + `pulsar-mptc/HANZO-CRYPTO-SUITE.md`
|
||||
(this doc, for the broader inventory).
|
||||
|
||||
## Why this matters
|
||||
|
||||
The user's direction is clear: every novel cryptographic
|
||||
construction in the Lux ecosystem should reach Pulsar-grade
|
||||
documentation + proof artifacts BEFORE claiming production
|
||||
readiness. This document is the gap-analysis showing what work
|
||||
remains.
|
||||
|
||||
Be honest in claims:
|
||||
- DO say: "Pulsar is submission-ready for NIST MPTC v0.1."
|
||||
- DO say: "Corona has a mature LP and implementation; submission
|
||||
packaging is on the v0.2 roadmap."
|
||||
- DO say: "X-Wing-Sig is a proposed direction; no LP exists yet."
|
||||
- DO NOT say: "The Hanzo Crypto Suite is 100% NIST-ratified" —
|
||||
only Pulsar v0.1 is submission-ready.
|
||||
- DO NOT say: "Magnetar is production-ready threshold SLH-DSA" —
|
||||
research-only.
|
||||
|
||||
---
|
||||
|
||||
**Document metadata**
|
||||
|
||||
- Name: `HANZO-CRYPTO-SUITE.md`
|
||||
- Version: v0.1
|
||||
- Date: 2026-05-18
|
||||
- Scope: full Lux/Hanzo crypto inventory; broader than
|
||||
`SUITE.md` (which covers PQ threshold only).
|
||||
- Maintainer: `[email protected]`
|
||||
@@ -0,0 +1,194 @@
|
||||
# INFORMATION-ARCHITECTURE — Hanzo PQ Threshold Suite + Lux Crypto
|
||||
|
||||
> Cross-repo taxonomy showing where each artifact lives. Updated
|
||||
> 2026-05-18 to reflect the v0.1 submission package + the broader
|
||||
> Lux crypto landscape (Corona, KMS, MPC, LPs).
|
||||
|
||||
## TL;DR — where to read what
|
||||
|
||||
| If you want to read about... | Read here |
|
||||
|---|---|
|
||||
| **NIST MPTC submission for Pulsar** | `pulsar-mptc/SUBMISSION.md` + `NIST-SUBMISSION.md` |
|
||||
| **Hanzo PQ Threshold Suite overview** | `pulsar-mptc/SUITE.md` |
|
||||
| **Pulsar protocol spec** | `pulsar-mptc/SPEC.md` (text) + `pulsar-mptc/spec/pulsar.pdf` (formal) |
|
||||
| **Pulsar IETF / CFRG draft** | `pulsar-mptc/docs/ietf-draft-skeleton.md` |
|
||||
| **What's proved vs not proved** | `pulsar-mptc/PROOF-CLAIMS.md` |
|
||||
| **Residual EC axioms** | `pulsar-mptc/AXIOM-INVENTORY.md` |
|
||||
| **TCB / what to trust** | `pulsar-mptc/TRUSTED-COMPUTING-BASE.md` |
|
||||
| **Op → FIPS 204 § map** | `pulsar-mptc/FIPS-TRACEABILITY.md` |
|
||||
| **Patent grant** | `pulsar-mptc/PATENTS.md` |
|
||||
| **Patent claim drafts (internal)** | `pulsar-mptc/docs/patent-claims.md` |
|
||||
| **Per-version proof changelog** | `pulsar-mptc/CHANGELOG.md` |
|
||||
| **Performance + correctness evaluation** | `pulsar-mptc/docs/evaluation.md` |
|
||||
| **Magnetar (Tier 3 SLH-DSA research)** | `pulsar-mptc/docs/magnetar.md` |
|
||||
| **Lux canonical crypto wiring** | `lps/CRYPTO-CANONICAL.md` |
|
||||
| **Specific protocol LPs** | `lps/LP-NNN-*.md` (e.g., LP-019 threshold MPC) |
|
||||
|
||||
## Three-axis information hierarchy
|
||||
|
||||
The Lux crypto information landscape has three independent axes.
|
||||
Choose your entry point based on what you're doing:
|
||||
|
||||
### Axis 1 — by construction / primitive (cryptographic axis)
|
||||
|
||||
```
|
||||
PQ signatures (NIST-standardized)
|
||||
├── ML-DSA (FIPS 204)
|
||||
│ ├── Single-party: cloudflare/circl, libjade (external impls)
|
||||
│ ├── THRESHOLD: PULSAR (Tier 1, Hanzo suite) ← `pulsar-mptc/`
|
||||
│ └── DOCS: SUBMISSION, SPEC, IETF, PROOF, PATENTS in pulsar-mptc/
|
||||
│
|
||||
├── SLH-DSA (FIPS 205)
|
||||
│ ├── Single-party: FIPS 205 reference (external)
|
||||
│ └── THRESHOLD: MAGNETAR (Tier 3 research) ← `pulsar-mptc/docs/magnetar.md`
|
||||
│
|
||||
└── Module-LWE / Ring-LWE (Lux-original)
|
||||
├── Single-party: N/A (FIPS 204 covers it)
|
||||
└── THRESHOLD: CORONA (Tier 1b sibling) ← `~/work/lux/corona/`
|
||||
|
||||
Classical signatures
|
||||
├── ECDSA (secp256k1)
|
||||
│ └── THRESHOLD: CGGMP21 ← `lps/LP-019` + `~/work/lux/mpc/`
|
||||
├── Schnorr / Ed25519
|
||||
│ └── THRESHOLD: FROST ← `lps/LP-019` + `~/work/lux/mpc/`
|
||||
└── BLS
|
||||
└── THRESHOLD: standard BLS aggregation ← `lps/LP-NNN` (TBD)
|
||||
|
||||
Hybrid / composition
|
||||
└── HANZO PQ THRESHOLD SUITE ← `pulsar-mptc/SUITE.md` (master index)
|
||||
|
||||
Secret-sharing wrapper
|
||||
└── LSS (Linear Shamir Secret Sharing) ← `lps/LP-019` + `lps/LP-141`
|
||||
```
|
||||
|
||||
### Axis 2 — by audience / consumer (use-case axis)
|
||||
|
||||
```
|
||||
NIST submission reviewer
|
||||
├── Entry: pulsar-mptc/SUBMISSION.md
|
||||
├── Specs: pulsar-mptc/SPEC.md, spec/pulsar.pdf
|
||||
├── Trust: PROOF-CLAIMS, AXIOM-INVENTORY, TCB
|
||||
├── Validation: vectors/, docs/evaluation.md
|
||||
└── IP: PATENTS.md
|
||||
|
||||
IETF / CFRG editor
|
||||
├── Entry: pulsar-mptc/docs/ietf-draft-skeleton.md
|
||||
├── Cross-ref: pulsar-mptc/SUITE.md (overview)
|
||||
└── Conversion: mmark / kramdown-rfc → xml2rfc XML
|
||||
|
||||
Lux protocol developer (writing a new precompile, etc.)
|
||||
├── Entry: lps/CRYPTO-CANONICAL.md (wiring + algorithm list)
|
||||
├── Per-protocol: lps/LP-NNN-*.md
|
||||
├── Implementation: `~/work/lux/<repo>/` (e.g., pulsar/, corona/)
|
||||
└── Bindings: lps/LP-012 (PQ GPU), LP-013 (FHE)
|
||||
|
||||
Lux validator operator
|
||||
├── Entry: lps/LP-015-validator-key-management.md
|
||||
├── DKG ceremony: lps/LP-019-threshold-mpc.md
|
||||
└── Operations: lps/LP-141-threshold-vm.md
|
||||
|
||||
Attorney / patent reviewer
|
||||
├── Public-facing: pulsar-mptc/PATENTS.md
|
||||
├── Claim drafts (internal): pulsar-mptc/docs/patent-claims.md
|
||||
└── Prior-art map: docs/patent-claims.md §1.4 (per claim group)
|
||||
|
||||
Auditor (cryptographic review)
|
||||
├── Spec: pulsar-mptc/spec/pulsar.pdf
|
||||
├── Proofs: pulsar-mptc/proofs/easycrypt/ + ~/work/lux/proofs/lean/
|
||||
├── Bridge doc: pulsar-mptc/proofs/lean-easycrypt-bridge.md
|
||||
├── Trust: TRUSTED-COMPUTING-BASE.md
|
||||
└── Validation: scripts/check-high-assurance.sh
|
||||
|
||||
Application developer (calling Pulsar from Go / Rust)
|
||||
├── Reference impl: pulsar-mptc/ref/go/pkg/pulsar/
|
||||
├── Spec subset: SPEC.md §7 (signing) + §8 (verification)
|
||||
└── Bindings (future): per language target
|
||||
|
||||
External cryptographer (peer review)
|
||||
├── Honest framing: PROOF-CLAIMS.md
|
||||
├── Residual trust: AXIOM-INVENTORY.md
|
||||
└── External-facing: spec/pulsar.pdf + Lean side at ~/work/lux/proofs/lean/
|
||||
```
|
||||
|
||||
### Axis 3 — by Lux organizational structure (governance axis)
|
||||
|
||||
```
|
||||
luxfi/ (open-source NIST-submission entity)
|
||||
├── pulsar-mptc/ ← this repo (NIST submission)
|
||||
├── corona/ ← R-LWE sibling (open-source)
|
||||
├── crypto/ ← canonical Go crypto entry
|
||||
├── mpc/ ← general MPC infrastructure
|
||||
├── kms/ ← key-management service
|
||||
└── proofs/ ← Lean / EC / Tamarin / Halmos proofs
|
||||
|
||||
luxcpp/ (high-performance C++ + GPU crypto entry)
|
||||
└── crypto/ ← C++ + CUDA/Metal/WGSL backends
|
||||
|
||||
lps/ (Lux Proposal System)
|
||||
├── LP-001..LP-199 ← canonical protocol specs
|
||||
├── CRYPTO-CANONICAL.md ← cross-repo wiring summary
|
||||
└── LP-019, LP-020, LP-141 ← threshold-MPC, Quasar, ThresholdVM
|
||||
|
||||
hanzo/ (downstream consumers)
|
||||
├── platform/ ← Hanzo PaaS (consumes Pulsar at MPC layer)
|
||||
└── various AI/llm/etc.
|
||||
|
||||
zoo/, pars/, spc/ ← per-org subnets, may consume Pulsar
|
||||
```
|
||||
|
||||
## Cross-axis navigation
|
||||
|
||||
A reader can hop axes:
|
||||
- **From Axis 1 (Pulsar construction) to Axis 3 (governance)**:
|
||||
`pulsar-mptc/` is the open-source NIST-submission home; downstream
|
||||
consumers (hanzo/, lps/, etc.) reference it for production use.
|
||||
- **From Axis 2 (NIST reviewer) to Axis 1 (construction)**:
|
||||
SUBMISSION.md points to SPEC.md which describes Pulsar's place in
|
||||
the Tier-1/2/3 suite.
|
||||
- **From Axis 3 (LP-019 reader) to Axis 1 (Pulsar / Magnetar)**:
|
||||
LP-019 tags Pulsar precompile at 0x000B; reader follows to
|
||||
`pulsar-mptc/` for the actual NIST submission package.
|
||||
|
||||
## How the suite scales
|
||||
|
||||
For each new tier construction:
|
||||
|
||||
1. Add a row to `SUITE.md` §Tiers.
|
||||
2. Add a corresponding tier-N entry to `INFORMATION-ARCHITECTURE.md`
|
||||
Axis 1.
|
||||
3. If production-grade: spin up a parallel doc package
|
||||
(SUBMISSION, SPEC, PROOF-CLAIMS, AXIOM-INVENTORY,
|
||||
FIPS-TRACEABILITY, PATENTS, TCB, evaluation).
|
||||
4. If research-grade: a single `docs/<tier>.md` placeholder
|
||||
suffices (per `docs/magnetar.md` template).
|
||||
5. Cross-reference from the relevant LP-NNN in `lps/`.
|
||||
|
||||
## Consistency rules
|
||||
|
||||
To prevent drift across repos / LPs / docs:
|
||||
|
||||
1. **Canonical algorithm wiring lives in `lps/CRYPTO-CANONICAL.md`**.
|
||||
All other docs cross-reference; no other doc owns this.
|
||||
2. **Protocol specs live in `lps/LP-NNN`** as the authoritative
|
||||
versioned spec. Submission-package SPEC.md files reference
|
||||
the LP-NNN.
|
||||
3. **Implementation lives in the relevant repo** (`pulsar-mptc/`,
|
||||
`corona/`, etc.). Spec docs reference `ref/` paths.
|
||||
4. **Proof artifacts live in `~/work/lux/proofs/`** (Lean) and
|
||||
the relevant repo's `proofs/` (EasyCrypt + Jasmin). Bridge
|
||||
docs maintain the cross-prover correspondence.
|
||||
5. **Submission-package docs (this repo)** are NIST-submission-shaped
|
||||
and reference the canonical specs + implementations + proofs.
|
||||
6. **Patent grants** live with the repo that originated the
|
||||
construction (Pulsar's grant in `pulsar-mptc/PATENTS.md`;
|
||||
Corona's grant will live in `~/work/lux/corona/PATENTS.md`
|
||||
when packaged).
|
||||
|
||||
---
|
||||
|
||||
**Document metadata**
|
||||
|
||||
- Name: `INFORMATION-ARCHITECTURE.md`
|
||||
- Version: v0.1
|
||||
- Date: 2026-05-18
|
||||
- Cross-references: `SUITE.md`, `~/work/lux/lps/CRYPTO-CANONICAL.md`
|
||||
+1602
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,183 @@
|
||||
# SINGLE-IMPL-PLAN — collapse `pulsar-mptc/ref/go/pkg/pulsar/` into `luxfi/pulsar`
|
||||
|
||||
> Plan to honor "one and only one implementation" by making
|
||||
> `pulsar-mptc/` a thin **submission framework** that depends on the
|
||||
> canonical Go library at `github.com/luxfi/pulsar` rather than
|
||||
> carrying a parallel implementation tree.
|
||||
>
|
||||
> Date: 2026-05-18. Status: **plan-only — no code deleted yet.**
|
||||
|
||||
## TL;DR
|
||||
|
||||
`pulsar-mptc/ref/go/pkg/pulsar/` and `pulsar/ref/go/pkg/pulsar/`
|
||||
have **diverged in parallel**. Both trees have implementation work the
|
||||
other lacks. A clean collapse requires a real merge into the canonical
|
||||
`luxfi/pulsar`, then a Go-module dependency rewire — not a wholesale
|
||||
deletion.
|
||||
|
||||
| Tree | Files | Lines | Notes |
|
||||
|---|---:|---:|---|
|
||||
| `pulsar-mptc/ref/go/pkg/pulsar/` | 28 | 7 383 | submission focus: identifiable abort, identity stage, n1 byte-equality test, fuzz, zeroize |
|
||||
| `pulsar/ref/go/pkg/pulsar/` | 37 | 8 328 | production focus: large-scale variants, round abstraction, batch verify, shamir over GF(q), precompile e2e |
|
||||
|
||||
## Divergence inventory
|
||||
|
||||
### Only in `pulsar-mptc/` (5 files, ~600 lines)
|
||||
|
||||
| File | Purpose |
|
||||
|---|---|
|
||||
| `identity.go` | identity-stage logic |
|
||||
| `identity_test.go` | identity tests |
|
||||
| `n1_byte_equality_test.go` | submission-headline test for Class N1 byte equality |
|
||||
| `fuzz_test.go` | go-test fuzz harness |
|
||||
| `zeroize.go` | secret-material zeroization |
|
||||
|
||||
### Only in `pulsar/` (14 files, ~1500 lines)
|
||||
|
||||
| File | Purpose |
|
||||
|---|---|
|
||||
| `large_dkg.go`, `large_threshold.go`, `large_types.go`, `large_reshare.go` | large-scale variants (n ≫ 7) |
|
||||
| `large_e2e_test.go` | large-scale e2e |
|
||||
| `largeshamir.go`, `largeshamir_test.go` | shamir for large committees |
|
||||
| `shamir_gfq.go`, `shamir_gfq_test.go` | shamir over generic field GF(q) |
|
||||
| `round.go`, `round_test.go` | abstract round-state machine |
|
||||
| `verify_batch.go`, `verify_batch_test.go` | batched verification (consensus throughput) |
|
||||
| `precompile_e2e_test.go` | EVM-precompile end-to-end |
|
||||
|
||||
### Common 23 files — **all DIFFER**
|
||||
|
||||
`abort.go` `abort_test.go` `bench_test.go` `dkg.go` `dkg_test.go` `doc.go`
|
||||
`kat_test.go` `keygen.go` `keygen_test.go` `params.go` `pulsar_test.go`
|
||||
`reshare.go` `reshare_test.go` `shamir.go` `shamir_test.go` `sign.go`
|
||||
`sign_test.go` `threshold.go` `threshold_test.go` `transcript.go`
|
||||
`transcript_test.go` `types.go` `verify.go`
|
||||
|
||||
Sample delta: `abort.go` is 411 lines in pulsar-mptc vs 137 in pulsar
|
||||
(274-line difference). Sample causes (from spot-check): submission-grade
|
||||
abort-evidence verification was extended in pulsar-mptc; pulsar trimmed
|
||||
back to a smaller production surface. Other large deltas in
|
||||
`reshare.go` (+117), `threshold.go` (+59), `dkg.go` (+91).
|
||||
|
||||
## Merge strategy (forward direction = pulsar absorbs mptc)
|
||||
|
||||
The canonical destination is `~/work/lux/pulsar/` (production library).
|
||||
The merge direction is **pulsar-mptc → pulsar**:
|
||||
|
||||
1. **Adopt the 5 mptc-only files into pulsar/** verbatim
|
||||
(`identity.go`, `identity_test.go`, `n1_byte_equality_test.go`,
|
||||
`fuzz_test.go`, `zeroize.go`).
|
||||
2. **Reconcile the 23 common-but-divergent files** per-file. For
|
||||
each: 3-way merge using last common ancestor + mptc + pulsar. Land
|
||||
the **superset** of both trees' work into pulsar.
|
||||
3. **Keep pulsar's 14 unique files** (large_*, round, batch, etc.) —
|
||||
they are already canonical.
|
||||
4. **Run the union test suite** in `pulsar/` (all 37 + 5 = 42 source
|
||||
files, ~9 000 LOC). Confirm zero regressions.
|
||||
5. **Tag `luxfi/pulsar` v1.1.0** with the merged surface.
|
||||
|
||||
## Rewire pulsar-mptc as a dependent (after merge)
|
||||
|
||||
After pulsar v1.1.0 ships:
|
||||
|
||||
1. **`pulsar-mptc/go.mod`** — add:
|
||||
```
|
||||
require github.com/luxfi/pulsar v1.1.0
|
||||
replace github.com/luxfi/pulsar => ../pulsar // local dev only
|
||||
```
|
||||
2. **Delete** `pulsar-mptc/ref/go/pkg/pulsar/` entirely (28 files).
|
||||
3. **Repoint 3 imports** (currently `github.com/luxfi/pulsar-mptc/ref/go/pkg/pulsar` →
|
||||
`github.com/luxfi/pulsar/ref/go/pkg/pulsar`):
|
||||
- `ref/go/cmd/genkat/main.go:23`
|
||||
- `ct/dudect/verify_ct.go:66`
|
||||
- `ct/dudect/combine_ct.go:53`
|
||||
4. **Fix `scripts/gen_vectors.sh:22`** — currently references
|
||||
stale `./ref/go/pkg/pulsarm/` (note the trailing `m`, removed by
|
||||
pulsar commit `af3d669` in 2026-05). Change to
|
||||
`github.com/luxfi/pulsar/ref/go/pkg/pulsar` package path.
|
||||
5. **At submission cut**: `go mod vendor` under `pulsar-mptc/` so the
|
||||
NIST tarball contains a frozen snapshot of `luxfi/pulsar@v1.1.0`
|
||||
under `pulsar-mptc/vendor/github.com/luxfi/pulsar/`. NIST reviewers
|
||||
get a self-contained tarball without network fetch.
|
||||
|
||||
## Submission-package layout after collapse
|
||||
|
||||
```
|
||||
pulsar-mptc/ ← submission framework (Go-module dependent)
|
||||
├── go.mod (require luxfi/pulsar v1.1.0)
|
||||
├── go.sum
|
||||
├── vendor/ ← produced at submission cut via `go mod vendor`
|
||||
│ └── github.com/luxfi/pulsar/ (frozen at v1.1.0)
|
||||
├── ref/go/cmd/genkat/ ← KAT generator (imports vendored pulsar)
|
||||
├── test/interoperability/ ← Class N1 cross-validation (independent verifier)
|
||||
├── test/fuzz/ ← submission-specific fuzz scenarios
|
||||
├── test/negative/ ← submission-specific negative tests
|
||||
├── ct/dudect/ ← constant-time analysis harness
|
||||
├── proofs/easycrypt/ ← EC theories (untouched)
|
||||
├── proofs/lean-easycrypt-bridge.md
|
||||
├── jasmin/ ← Jasmin sources (untouched)
|
||||
├── scripts/ ← build/test/bench/gen_vectors (updated to use canonical)
|
||||
├── vectors/ ← KAT JSON output (unchanged)
|
||||
├── bench/ ← benchmark configs + results
|
||||
├── *.md ← all submission docs (unchanged)
|
||||
```
|
||||
|
||||
## What this buys
|
||||
|
||||
- **DRY**: 7 383 lines of Go in pulsar-mptc/ref/go/pkg/pulsar/ collapse
|
||||
to zero (one canonical impl in luxfi/pulsar).
|
||||
- **Drift impossible**: every CI change in pulsar/ is automatically
|
||||
picked up by pulsar-mptc/ via go.mod.
|
||||
- **NIST review surface clear**: SUBMISSION.md points NIST at the
|
||||
vendored snapshot under `vendor/github.com/luxfi/pulsar/` — single
|
||||
algorithm implementation, single test surface.
|
||||
- **Production library stays the source of truth**: changes go into
|
||||
pulsar/, then a tag picks them up everywhere.
|
||||
|
||||
## Risks and mitigations
|
||||
|
||||
| Risk | Mitigation |
|
||||
|---|---|
|
||||
| Merge introduces a subtle behavior change that breaks a KAT | Regenerate KATs from merged impl; diff against committed; only land if identical or with a documented seed change |
|
||||
| pulsar's smaller `abort.go` is intentional (production-stripped) and merging back the larger mptc version reintroduces dead code | Per-file review with comments; reconcile not by union but by intent |
|
||||
| Vendoring breaks the IETF / NIST `submission-2026-11-16` tag reproducibility if pulsar's HEAD drifts | Pin to exact commit/tag in go.mod; vendor produces a frozen tree |
|
||||
| Local dev `replace ../pulsar` directive leaks into the submitted tarball | `scripts/cut-submission.sh` strips the replace directive at tag time |
|
||||
|
||||
## Execution checklist
|
||||
|
||||
- [ ] **Sub-session 1 — file-by-file merge (1-2 days)**: adopt 5
|
||||
mptc-only files into pulsar/; merge 23 common-divergent files;
|
||||
verify pulsar test suite passes on the union.
|
||||
- [ ] **Sub-session 2 — release pulsar v1.1.0**: tag, push.
|
||||
- [ ] **Sub-session 3 — pulsar-mptc rewire (½ day)**: go.mod, delete
|
||||
ref/go/pkg/pulsar/, update 3 imports + 1 script, vendor at submission cut.
|
||||
- [ ] **Sub-session 4 — CI gate (¼ day)**: add `scripts/check-single-impl.sh`
|
||||
that fails if `pulsar-mptc/ref/go/pkg/pulsar/` re-appears.
|
||||
- [ ] **Sub-session 5 — docs update (¼ day)**: refresh
|
||||
`SUBMISSION.md`, `STATUS-SUBMISSION-READINESS.md`, `SYNC-STATUS.md`
|
||||
to reflect single-impl.
|
||||
|
||||
## Why not just delete now
|
||||
|
||||
The two trees are not duplicates of each other — they have
|
||||
PARALLEL EVOLUTIONS with **real implementation differences in
|
||||
all 23 common files plus 19 unique files (5+14)**. A wholesale
|
||||
deletion would drop ~600 lines of submission-grade work
|
||||
(identifiable-abort extensions, identity-stage logic, n1 byte
|
||||
equality test, zeroize, fuzz harness) from pulsar-mptc, OR drop
|
||||
~1500 lines of production work (large-scale variants, batch verify,
|
||||
round abstraction) from pulsar. Either is unacceptable.
|
||||
|
||||
The clean path is a deliberate merge. This document is the
|
||||
specification for that merge.
|
||||
|
||||
---
|
||||
|
||||
**Document metadata**
|
||||
|
||||
- Name: `SINGLE-IMPL-PLAN.md`
|
||||
- Version: v0.1
|
||||
- Date: 2026-05-18
|
||||
- Owner: `crypto-merge@lux.network`
|
||||
- Blocks: NIST submission tarball cut (2026-11-16) — recommended but
|
||||
not strictly required (submission tarball can ship with current
|
||||
duplicate-impl layout if merge slips)
|
||||
@@ -0,0 +1,364 @@
|
||||
# STATUS — Submission readiness per category
|
||||
|
||||
> Authoritative status of every Hanzo Crypto Suite category against
|
||||
> the NIST MPTC 2026-11-16 deadline (and adjacent submission tracks:
|
||||
> IETF / CFRG, FIPS 140-3 module, ACVP / CAVP, IETF KEM RFCs).
|
||||
>
|
||||
> Companion to `SUITE.md` (PQ-threshold tiers), `HANZO-CRYPTO-SUITE.md`
|
||||
> (full inventory), `ROADMAP.md` (multi-year plan), and
|
||||
> `SYNC-STATUS.md` (cross-repo audit).
|
||||
>
|
||||
> Date: 2026-05-18.
|
||||
|
||||
## TL;DR — what is submission-ready RIGHT NOW
|
||||
|
||||
| Track | Deadline | Ready? | Notes |
|
||||
|---|---|---|---|
|
||||
| **NIST MPTC v0.1 — Pulsar Tier 1** | 2026-11-16 | **YES** | All 14 artifacts shipped (spec, ref impl, KAT, EC 13/13, Lean 5/5, jasmin-ct 3/3, IETF draft, 10 submission docs) |
|
||||
| NIST MPTC v0.2 — Corona Tier 1b | not yet announced | **NO** | Implementation mature; submission package missing |
|
||||
| NIST MPTC v0.3 — Magnetar Tier 3 | not yet announced | **NO** | Research-only; no construction yet |
|
||||
| NIST MPTC v0.4 — LSS wrapper | not yet announced | **NO** | LP-019 spec mature; standalone package missing |
|
||||
| IETF / CFRG drafts (per construction) | rolling | **Pulsar only** | `draft-hanzo-pulsar-threshold-mldsa-00` drafted |
|
||||
| FIPS 140-3 module validation | n/a (lab) | **NO for any** | Requires NVLAP-accredited lab engagement |
|
||||
| ACVP / CAVP algorithm validation | n/a (lab) | **NO for any** | Requires NIST CAVP harness submission |
|
||||
| IETF KEM RFCs (X-Wing, ML-KEM) | upstream | partial | We consume upstream — Lux-profile draft TBD |
|
||||
|
||||
## §1 PQ threshold signatures (Hanzo PQ Threshold Suite)
|
||||
|
||||
### §1.1 Pulsar — **NIST MPTC v0.1 SUBMISSION READY** ✅
|
||||
|
||||
`~/work/lux/pulsar-mptc/` HEAD `c2e01e3` (2026-05-18).
|
||||
|
||||
| Artifact | Location | Status |
|
||||
|---|---|---|
|
||||
| Cover sheet | `SUBMISSION.md` | ✅ |
|
||||
| 1-page exec summary | `NIST-SUBMISSION.md` | ✅ |
|
||||
| Standalone spec | `SPEC.md` + `spec/pulsar.tex` | ✅ |
|
||||
| Suite index | `SUITE.md` | ✅ |
|
||||
| Suite-wide inventory | `HANZO-CRYPTO-SUITE.md` | ✅ |
|
||||
| Info architecture | `INFORMATION-ARCHITECTURE.md` | ✅ |
|
||||
| Patent grant | `PATENTS.md` | ✅ |
|
||||
| Patent claim drafts | `docs/patent-claims.md` (21 claims, 5 groups) | ✅ |
|
||||
| Trust accounting | `AXIOM-INVENTORY.md` + `PROOF-CLAIMS.md` + `TRUSTED-COMPUTING-BASE.md` | ✅ |
|
||||
| FIPS 204 traceability | `FIPS-TRACEABILITY.md` | ✅ |
|
||||
| Per-version proof log | `CHANGELOG.md` (v4-v13) | ✅ |
|
||||
| Multi-year roadmap | `ROADMAP.md` | ✅ |
|
||||
| Cross-repo sync | `SYNC-STATUS.md` | ✅ |
|
||||
| IETF Internet-Draft | `docs/ietf-draft-skeleton.md` (`draft-hanzo-pulsar-threshold-mldsa-00`) | ✅ |
|
||||
| Experimental evaluation | `docs/evaluation.md` (NIST IR 8214C §6) | ✅ |
|
||||
| Reference implementation | `ref/go/pkg/pulsar/` | ✅ 89.7% coverage |
|
||||
| KAT vectors | `vectors/` | ✅ deterministic |
|
||||
| EasyCrypt theories | `proofs/easycrypt/` | ✅ 13/13 compile, 0 admit |
|
||||
| Lean ↔ EC bridge | `proofs/lean-easycrypt-bridge.md` | ✅ 5/5 bridges, CI-guarded |
|
||||
| Jasmin constant-time | `jasmin/{lib,ml-dsa-65,threshold}/` | ✅ 3/3 CI green |
|
||||
| Class N1 interop | `test/interoperability/n1_class_test.go` | ✅ 19/19 subtests vs cloudflare/circl |
|
||||
| Build/test/bench/SBOM | `scripts/` | ✅ |
|
||||
| License | `LICENSE` (Apache-2.0) | ✅ |
|
||||
|
||||
**Open items before 2026-11-16 (Lux-controlled, achievable)**:
|
||||
|
||||
1. **Encoding section freeze** in `spec/pulsar.tex` — wire formats
|
||||
pinned at DD-008 (end of August 2026).
|
||||
2. **dudect timing-channel results** pinned in `ct/dudect/results/`.
|
||||
3. **Cross-validation against ≥2 of** {BoringSSL FIPS, AWS-LC,
|
||||
OpenSSL 3.0 PQ provider, pq-crystals Dilithium reference}.
|
||||
4. **Five algorithmic spec caveats** identified in red-team audit:
|
||||
- adaptive corruption (UNSUPPORTED → spec must say static-only)
|
||||
- cross-domain isolation Pulsar/Corona (WEAK → both share lattice hardness)
|
||||
- constant-time Verify (assertion vs measurement)
|
||||
- Z-Chain Groth16 / P3Q migration claim alignment
|
||||
- 2-round optimality clarification vs Raccoon
|
||||
5. **Patent filing(s)** for the 21 claim drafts — must precede or
|
||||
accompany submission (target Q3 2026).
|
||||
|
||||
### §1.2 Corona — **NOT SUBMISSION-READY** (v0.2 target)
|
||||
|
||||
`~/work/lux/corona/`.
|
||||
|
||||
| Artifact | Status |
|
||||
|---|---|
|
||||
| DESIGN.md | partial |
|
||||
| SUBMISSION.md | missing |
|
||||
| SPEC.md | missing |
|
||||
| IETF draft | missing |
|
||||
| Reference implementation | ✅ full Go |
|
||||
| EC proofs | partial (DKG only) |
|
||||
| Lean bridges | TBD |
|
||||
| Jasmin CT | TBD |
|
||||
| Test vectors | ✅ |
|
||||
| PATENTS.md | missing |
|
||||
| Trust accounting | missing |
|
||||
|
||||
**Left to ship submission-ready package**: 6-8 weeks of focused work.
|
||||
|
||||
### §1.3 Magnetar — **RESEARCH ONLY**
|
||||
|
||||
`docs/magnetar.md` placeholder. No construction. No implementation. No
|
||||
proofs. Threshold SLH-DSA is an open research direction (per-signature
|
||||
MPC over hash trees is materially harder than threshold ML-DSA).
|
||||
|
||||
**Left to ship**: 2-3 months for an initial DKG prototype + paper.
|
||||
Not on the 2026-11-16 critical path.
|
||||
|
||||
### §1.4 LSS (Linear Shamir wrapper) — **PARTIAL**
|
||||
|
||||
Spec lives in LP-019 + LP-141. Implementation in `~/work/lux/mpc/`.
|
||||
|
||||
| Artifact | Status |
|
||||
|---|---|
|
||||
| LP spec | ✅ LP-019 + LP-141 |
|
||||
| Standalone IETF draft | missing |
|
||||
| Reference vectors | partial |
|
||||
| EC + Lean proofs | missing |
|
||||
| Patent grant | covered by LP-019 |
|
||||
|
||||
**Left to ship**: 2 weeks for standalone IETF draft + KAT vectors;
|
||||
the wrapper does not require a standalone NIST MPTC submission
|
||||
(LSS-over-Pulsar is covered inside Pulsar's `§9 Reshare protocol`).
|
||||
|
||||
## §2 Classical threshold signatures
|
||||
|
||||
### §2.1 FROST (Ed25519 / secp256k1 Schnorr) — **NOT SUBMISSION-READY**
|
||||
|
||||
Implementation in `~/work/lux/mpc/`. IETF draft `draft-irtf-cfrg-frost`
|
||||
exists upstream — Lux profile gap.
|
||||
|
||||
| Artifact | Status |
|
||||
|---|---|
|
||||
| LP spec | ✅ LP-019 |
|
||||
| Upstream IETF draft | ✅ `draft-irtf-cfrg-frost` |
|
||||
| Lux-profile IETF draft | missing |
|
||||
| Reference implementation | ✅ (consumes upstream KATs) |
|
||||
| EC + Lean proofs | missing in Lux |
|
||||
| Constant-time analysis | partial |
|
||||
| Lux-specific KAT vectors | missing |
|
||||
| Patent grant / clearance | missing |
|
||||
|
||||
**Left to ship**: 8-12 weeks (Lux-profile draft + EC scaffolding +
|
||||
KATs + CT analysis).
|
||||
|
||||
### §2.2 CGGMP21 (secp256k1 ECDSA) — **NOT SUBMISSION-READY**
|
||||
|
||||
Implementation in `~/work/lux/mpc/`.
|
||||
|
||||
| Artifact | Status |
|
||||
|---|---|
|
||||
| LP spec | ✅ LP-019 |
|
||||
| IETF draft | missing |
|
||||
| Reference implementation | ✅ |
|
||||
| EC + Lean proofs | missing |
|
||||
| Constant-time analysis | missing |
|
||||
| KAT vectors | partial |
|
||||
| Patent clearance (CCS '21) | missing |
|
||||
|
||||
**Left to ship**: 8-12 weeks.
|
||||
|
||||
### §2.3 BLS (BLS12-381 aggregate) — **PARTIAL**
|
||||
|
||||
`~/work/lux/crypto/bls/`. Used everywhere (Quasar consensus
|
||||
classical-fast-path).
|
||||
|
||||
| Artifact | Status |
|
||||
|---|---|
|
||||
| LP spec | ✅ LP-020 |
|
||||
| IETF draft | upstream (`draft-irtf-cfrg-bls-signature`) |
|
||||
| Reference implementation | ✅ |
|
||||
| EC + Lean proofs | partial Lean (`lean/Crypto/BLS.lean`) |
|
||||
| Constant-time analysis | upstream (blst) |
|
||||
| KAT vectors | ✅ |
|
||||
| Patent grant | missing |
|
||||
|
||||
**Left to ship**: 4 weeks for Lux-profile package.
|
||||
|
||||
## §3 Hybrid PQ signature wrappers — X-Wing-Sig
|
||||
|
||||
**NOT SPECIFIED. NOT IMPLEMENTED.** Design direction documented in
|
||||
`docs/x-wing-sig.md`. No LP yet.
|
||||
|
||||
| Artifact | Status |
|
||||
|---|---|
|
||||
| Design direction | ✅ `docs/x-wing-sig.md` |
|
||||
| LP draft | missing |
|
||||
| Reference implementation | missing |
|
||||
| Composition proof | missing |
|
||||
| KAT vectors | missing |
|
||||
| IETF draft | missing |
|
||||
|
||||
**Left to ship to v0.1 LP**: ~2 months (per design doc estimate).
|
||||
|
||||
## §4 Key encapsulation
|
||||
|
||||
### §4.1 ML-KEM-768 — production-ready (consume FIPS 203)
|
||||
|
||||
We CONSUME the NIST-standardized FIPS 203 directly via
|
||||
`~/work/lux/crypto/mlkem/`. No Lux submission needed (NIST is
|
||||
already done).
|
||||
|
||||
### §4.2 X-Wing (X25519 + ML-KEM-768 hybrid) — production-ready (consume upstream)
|
||||
|
||||
We CONSUME the IRTF CFRG draft `draft-irtf-cfrg-xwing` via
|
||||
`~/work/lux/crypto/xwing/`. Specified in LP-115. No Lux NIST submission
|
||||
needed.
|
||||
|
||||
### §4.3 X-Wing+ (Lux-extended profile) — **NEEDS PROFILE LP**
|
||||
|
||||
Lux extension at `~/work/lux/crypto/xwing+/`. LP follow-up to LP-115
|
||||
not yet drafted. ~2 weeks for the profile LP.
|
||||
|
||||
## §5 ZK / accountability
|
||||
|
||||
### §5.1 Z-Chain PQ identity rollup — separate Lux artifact
|
||||
|
||||
LP-063 (Z-Chain) + LP-169 (Z-Chain PQ identity rollup). Mature LPs.
|
||||
Not a NIST submission target (Lux-original construction). Implementation
|
||||
in `~/work/lux/zchain/`.
|
||||
|
||||
| Artifact | Status |
|
||||
|---|---|
|
||||
| LP-063 spec | ✅ mature |
|
||||
| LP-169 spec | ✅ mature |
|
||||
| Reference implementation | ✅ |
|
||||
| Audit | gap |
|
||||
| Submission package | n/a (not standardization-tracked) |
|
||||
|
||||
### §5.2 P3Q precompile (EVM slot 0x012205) — **PARTIAL**
|
||||
|
||||
LP-078 covers EVM precompiles broadly; dedicated P3Q LP not yet
|
||||
drafted. Precompile reuses any FIPS 204 verifier (the signature
|
||||
verified by P3Q is byte-equal to single-party ML-DSA).
|
||||
|
||||
| Artifact | Status |
|
||||
|---|---|
|
||||
| Dedicated P3Q LP | missing |
|
||||
| Precompile implementation | partial (in `evm/precompiles/`) |
|
||||
| Gas-cost model | gap |
|
||||
| Test vectors | partial |
|
||||
|
||||
**Left to ship**: ~4 weeks for dedicated P3Q LP + gas model + KAT.
|
||||
|
||||
## §6 FHE / confidential compute
|
||||
|
||||
**LP-013** (FHE GPU), **LP-066** (TFHE), **LP-067** (Confidential ERC-20),
|
||||
**LP-068** (Private Teleport). All mature LPs. No NIST submission target
|
||||
(FHE is not currently a NIST standardization category; consume open-
|
||||
source TFHE / OpenFHE / Lattigo).
|
||||
|
||||
| Scheme | Status |
|
||||
|---|---|
|
||||
| TFHE (CGGI) | LP-spec mature; F-Chain host |
|
||||
| BFV | partial |
|
||||
| CKKS | partial |
|
||||
| Threshold FHE | LP-019 + LP-141; ceremonies on M-Chain |
|
||||
|
||||
**Left to ship**: paper-grade publication only; nothing for NIST.
|
||||
|
||||
## §7 EVM-native PQ migration (C-Chain + X-Chain)
|
||||
|
||||
**NOT YET DRAFTED.** No LP. Three migration paths sketched in
|
||||
`HANZO-CRYPTO-SUITE.md §7`:
|
||||
|
||||
1. Soft migration via X-Wing-Sig (depends on §3).
|
||||
2. Hard fork to PQ-native.
|
||||
3. Per-account opt-in.
|
||||
|
||||
**Left to ship**: LP-XXX draft (~4 weeks), then 4-8 weeks of
|
||||
implementation per chain, then coordinated rollout.
|
||||
|
||||
## External tracks (NOT under Lux's direct control)
|
||||
|
||||
| Track | Owner | Lux's input | Status |
|
||||
|---|---|---|---|
|
||||
| NIST MPTC ratification | NIST | Submit v0.1 package by 2026-11-16; respond to reviewer feedback | Inputs ready; multi-year process |
|
||||
| IETF / CFRG publication | IETF | Submit `draft-hanzo-pulsar-threshold-mldsa-00`; iterate at IETF meetings | Draft ready; submit on schedule |
|
||||
| ACVP / CAVP algorithm validation | NIST + accredited lab | Lab engagement + CAVP harness | Not yet engaged |
|
||||
| FIPS 140-3 module validation | NIST + accredited lab | Lab engagement; module-boundary documentation | Not yet engaged |
|
||||
| IETF KEM RFCs (X-Wing, ML-KEM) | IRTF CFRG | Consume upstream drafts; contribute review | Consuming |
|
||||
|
||||
## Aggregate gap analysis
|
||||
|
||||
| Category | LP | Spec | Ref Impl | Proofs | KAT | Package | IETF | Total readiness |
|
||||
|---|---|---|---|---|---|---|---|---|
|
||||
| **Pulsar (Tier 1)** | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | **100% NIST-MPTC-ready** |
|
||||
| Corona (Tier 1b) | ✅ | partial | ✅ | partial | ✅ | ❌ | ❌ | 50% |
|
||||
| Magnetar (Tier 3) | ❌ | placeholder | ❌ | ❌ | ❌ | ❌ | ❌ | 5% |
|
||||
| LSS (Tier 4) | ✅ | LP-only | ✅ | ❌ | partial | ❌ | ❌ | 35% |
|
||||
| FROST | ✅ | LP-only | ✅ | ❌ | upstream | ❌ | upstream | 45% |
|
||||
| CGGMP21 | ✅ | LP-only | ✅ | ❌ | partial | ❌ | ❌ | 40% |
|
||||
| BLS | ✅ | LP-only | ✅ | partial Lean | ✅ | ❌ | upstream | 60% |
|
||||
| X-Wing-Sig | ❌ | design direction | ❌ | ❌ | ❌ | ❌ | ❌ | 10% |
|
||||
| ML-KEM (consume) | ✅ | upstream FIPS 203 | ✅ | n/a | upstream | n/a | upstream | 100% (consume) |
|
||||
| X-Wing (consume) | ✅ | upstream draft | ✅ | n/a | upstream | n/a | upstream | 100% (consume) |
|
||||
| X-Wing+ Lux profile | ❌ | gap | ✅ | ❌ | ❌ | ❌ | ❌ | 25% |
|
||||
| Z-Chain PQ | ✅ | ✅ | ✅ | partial | ❌ | ❌ | n/a | 55% |
|
||||
| P3Q precompile | partial | gap | partial | n/a | partial | n/a | n/a | 30% |
|
||||
| TFHE / BFV / CKKS | ✅ | LP-spec mature | partial | ❌ | upstream | n/a (no NIST track) | n/a | 50% |
|
||||
| EVM-native PQ migration | ❌ | gap | n/a | n/a | n/a | n/a | n/a | 5% |
|
||||
|
||||
## What's left, by priority
|
||||
|
||||
### Critical path to 2026-11-16 (Pulsar v0.1 submission)
|
||||
|
||||
1. Encoding section freeze in `spec/pulsar.tex` — **Lux, 2 weeks**.
|
||||
2. dudect CT results pinned — **Lux, 1 week**.
|
||||
3. Cross-validation against ≥2 FIPS 204 verifiers — **Lux, 1 week**.
|
||||
4. Patent filing for 21 claim drafts — **Lux + attorneys, 8 weeks**.
|
||||
5. Final NIST submission cut — **Lux, 1 day at tag**.
|
||||
|
||||
### v0.2 (Q4 2026 — Q1 2027)
|
||||
|
||||
6. Corona equivalent packaging — **Lux, 6-8 weeks**.
|
||||
7. LSS standalone IETF draft + KAT — **Lux, 2 weeks**.
|
||||
8. X-Wing+ Lux-profile LP — **Lux, 2 weeks**.
|
||||
9. P3Q dedicated LP + gas model + KAT — **Lux, 4 weeks**.
|
||||
|
||||
### v0.3 (Q1 — Q2 2027)
|
||||
|
||||
10. FROST Lux-profile draft + EC scaffolding + KAT + CT — **Lux, 8-12 weeks**.
|
||||
11. CGGMP21 submission package — **Lux, 8-12 weeks**.
|
||||
12. BLS Lux-profile package — **Lux, 4 weeks**.
|
||||
13. X-Wing-Sig LP + impl + composition proof + KAT — **Lux, 2 months**.
|
||||
14. EVM-native PQ migration LP draft — **Lux, 4 weeks**.
|
||||
|
||||
### v0.4 (Q3 2027 — onwards)
|
||||
|
||||
15. Magnetar research paper + initial DKG prototype — **Lux, 2-3 months**.
|
||||
16. Z-Chain PQ identity rollup audit — **Lux + auditor, 4-8 weeks**.
|
||||
17. FHE submission-equivalent docs (paper-track only) — **Lux, 4 weeks each**.
|
||||
|
||||
### External (no fixed timeline — track only)
|
||||
|
||||
18. NIST MPTC reviewer feedback iteration — **NIST, 6-18 months**.
|
||||
19. IETF / CFRG publication for `draft-hanzo-pulsar-threshold-mldsa` — **IETF, 12-36 months**.
|
||||
20. ACVP / CAVP algorithm validation engagement — **lab, 3-6 months**.
|
||||
21. FIPS 140-3 module validation — **lab, 6-12 months**.
|
||||
|
||||
## Honest claims
|
||||
|
||||
- **DO say**: "Pulsar (Tier 1) is NIST MPTC v0.1 submission-ready as
|
||||
of 2026-05-18; the package will be cut from a tag on `main` on
|
||||
2026-11-16."
|
||||
- **DO say**: "Every other Hanzo Crypto Suite member has an LP and an
|
||||
implementation; the matching submission-grade documentation +
|
||||
proof package is on the v0.2 — v0.4 roadmap."
|
||||
- **DO say**: "External tracks (NIST ratification, IETF publication,
|
||||
FIPS 140-3 module validation, ACVP / CAVP) are outside Lux's
|
||||
direct control; submission inputs are ready, decision timeline is
|
||||
the standards body's."
|
||||
- **DO NOT say**: "The Hanzo Crypto Suite is 100% NIST-ratified" — only
|
||||
Pulsar v0.1 is submission-ready, and submission is not ratification.
|
||||
- **DO NOT say**: "Magnetar is production-ready threshold SLH-DSA" —
|
||||
research-only.
|
||||
- **DO NOT say**: "FIPS 140-3 validated" for any module — no engagement
|
||||
is underway.
|
||||
|
||||
---
|
||||
|
||||
**Document metadata**
|
||||
|
||||
- Name: `STATUS-SUBMISSION-READINESS.md`
|
||||
- Version: v0.1
|
||||
- Date: 2026-05-18
|
||||
- Companion to: `SUITE.md`, `HANZO-CRYPTO-SUITE.md`, `ROADMAP.md`,
|
||||
`SYNC-STATUS.md`
|
||||
- Re-run cadence: monthly through 2026-11-16; quarterly thereafter
|
||||
- Owner: `[email protected]`
|
||||
@@ -0,0 +1,146 @@
|
||||
# Hanzo PQ Threshold Suite — index
|
||||
|
||||
> Master index for the **Hanzo PQ Threshold Suite**: a coordinated
|
||||
> set of post-quantum threshold-signing protocols anchored to NIST
|
||||
> standards (FIPS 204 ML-DSA, FIPS 205 SLH-DSA) and Lux's R-LWE
|
||||
> sibling (Corona).
|
||||
|
||||
## Tiers
|
||||
|
||||
| Tier | Name | Primitive | Status | Home |
|
||||
|---|---|---|---|---|
|
||||
| **Tier 1** | **Pulsar** | FIPS 204 ML-DSA (M-LWE) | **v0.1 — NIST MPTC submission-ready** | `~/work/lux/pulsar-mptc/` (this repo) |
|
||||
| Tier 1b | **Corona** | R-LWE (sibling) | Production reference + DKG impl | `~/work/lux/corona/` |
|
||||
| Tier 2 | SLH-DSA single-party compatibility | FIPS 205 SLH-DSA | Standard-verifier-compatible | Out-of-scope this suite (use FIPS 205 directly) |
|
||||
| **Tier 3** | **Magnetar** | FIPS 205 SLH-DSA via MPC | **Research-track — not for v0.1 production** | `docs/magnetar.md` (this repo) |
|
||||
| Tier 4 | **LSS** | Linear Shamir's Secret Sharing | Wrapper enabling dynamic resharing across Tiers 1 + 1b | `~/work/lux/lps/LP-019-threshold-mpc.md` |
|
||||
|
||||
## Naming
|
||||
|
||||
| Identifier | Means |
|
||||
|---|---|
|
||||
| `HANZO-PQ-THRESHOLD-SUITE-v0.1` | The suite version covered by this index |
|
||||
| `PULSAR-THRESHOLD-ML-DSA-{44,65,87}` | Pulsar parameter sets (NIST cat 2/3/5) |
|
||||
| `MAGNETAR-THRESHOLD-SLH-DSA-SHAKE-{192s,256s}` | Magnetar parameter sets (FIPS 205 SHAKE profile) |
|
||||
| `CORONA-THRESHOLD-RING-LWE-{44,65,87}` | Corona parameter sets (Lux R-LWE) |
|
||||
|
||||
## Submission packaging per tier
|
||||
|
||||
Each tier targets the **same submission-grade documentation package**
|
||||
(SUBMISSION.md cover sheet, SPEC.md / IETF draft, EC + Lean proof
|
||||
artifacts, PATENTS.md, AXIOM-INVENTORY.md, PROOF-CLAIMS.md,
|
||||
FIPS-TRACEABILITY.md, TRUSTED-COMPUTING-BASE.md, test vectors,
|
||||
docs/evaluation.md). Status by tier:
|
||||
|
||||
| Doc | Pulsar | Corona | Magnetar | LSS |
|
||||
|---|---|---|---|---|
|
||||
| Cover sheet (`SUBMISSION.md`) | ✅ | partial (`~/work/lux/corona/DESIGN.md`) | placeholder | LP-019 (LPS) |
|
||||
| Standalone spec (`SPEC.md`) | ✅ | TBD | TBD | LP-019 (LPS) |
|
||||
| IETF draft | ✅ `docs/ietf-draft-skeleton.md` | TBD | TBD | TBD |
|
||||
| Reference impl | ✅ `ref/go/` | ✅ `~/work/lux/corona/` (full Go) | ❌ research-only | ✅ `~/work/lux/lps/` LP-019 + LP-141 |
|
||||
| EC proofs | ✅ 13/13 compile | partial (DKG only) | ❌ | ❌ |
|
||||
| Lean bridges | ✅ 5/5 | TBD | TBD | TBD |
|
||||
| Jasmin CT | ✅ 3/3 | TBD | ❌ | ❌ |
|
||||
| Test vectors | ✅ `vectors/` | ✅ `~/work/lux/corona/` | ❌ | partial |
|
||||
| PATENTS | ✅ | TBD | TBD | covered by `~/work/lux/lps/PATENTS-OVERVIEW.md` if it exists |
|
||||
| Trust accounting | ✅ AXIOM-INVENTORY + PROOF-CLAIMS + TCB | TBD | TBD | TBD |
|
||||
|
||||
**Equivalent-packaging roadmap** (post v0.1 submission):
|
||||
- v0.2 (Q1 2027): Corona full submission package matching Pulsar's
|
||||
structure; Corona is the R-LWE sibling so the proof technique
|
||||
largely transfers.
|
||||
- v0.3 (Q2 2027): Magnetar research draft + initial proof-of-concept
|
||||
DKG (SLH-DSA is hash-based — threshold construction is materially
|
||||
different; expect research-paper-grade artifact, not
|
||||
production-grade).
|
||||
- v0.4 (Q3 2027): LSS full IETF draft (currently LP-019 in `~/work/lux/lps/`).
|
||||
|
||||
## Information architecture
|
||||
|
||||
```
|
||||
~/work/lux/
|
||||
├── pulsar-mptc/ ← Tier 1, this repo (NIST MPTC submission target)
|
||||
│ ├── SUBMISSION.md ← NIST cover sheet
|
||||
│ ├── SUITE.md ← THIS file (master index)
|
||||
│ ├── SPEC.md ← standalone protocol spec
|
||||
│ ├── PATENTS.md ← royalty-free grant
|
||||
│ ├── AXIOM-INVENTORY.md
|
||||
│ ├── PROOF-CLAIMS.md
|
||||
│ ├── FIPS-TRACEABILITY.md
|
||||
│ ├── TRUSTED-COMPUTING-BASE.md
|
||||
│ ├── NIST-SUBMISSION.md ← 1-page executive summary
|
||||
│ ├── CHANGELOG.md ← per-version proof artifact log
|
||||
│ ├── docs/
|
||||
│ │ ├── ietf-draft-skeleton.md ← Tier 1 IETF draft
|
||||
│ │ ├── magnetar.md ← Tier 3 research placeholder
|
||||
│ │ ├── patent-claims.md ← attorney prep (21 claims)
|
||||
│ │ └── evaluation.md ← NIST IR 8214C §6
|
||||
│ ├── spec/pulsar.tex/.pdf
|
||||
│ ├── ref/go/
|
||||
│ ├── proofs/easycrypt/
|
||||
│ ├── jasmin/threshold/
|
||||
│ └── vectors/
|
||||
│
|
||||
├── corona/ ← Tier 1b R-LWE sibling
|
||||
│ ├── DESIGN.md, CONSTANT-TIME-REVIEW.md
|
||||
│ ├── cli/, cmd/, dkg/, dkg2/, ...
|
||||
│ └── (v0.2 target: parallel SUBMISSION/SPEC/PATENTS structure)
|
||||
│
|
||||
├── kms/ ← key-management service (consumer)
|
||||
├── mpc/ ← general MPC infrastructure (consumer)
|
||||
│
|
||||
└── lps/ ← Lux Proposal System (LP-NNN canonical specs)
|
||||
├── CRYPTO-CANONICAL.md ← master crypto wiring doc
|
||||
├── LP-012-pq-crypto-gpu.md ← PQ crypto GPU acceleration
|
||||
├── LP-019-threshold-mpc.md ← Threshold MPC (FROST, CGGMP21, LSS)
|
||||
├── LP-020-quasar-consensus.md ← Quasar consensus PQ-signature usage
|
||||
├── LP-134-chain-topology.md ← M-Chain (MPC) + F-Chain (FHE) split
|
||||
└── LP-141-threshold-vm.md ← Threshold VM substrate
|
||||
```
|
||||
|
||||
## Cross-references between tiers
|
||||
|
||||
- **Pulsar ↔ Corona**: parallel constructions (M-LWE vs R-LWE);
|
||||
each produces byte-identical signatures to its respective NIST
|
||||
standard. Quasar consensus (LP-020) uses BOTH as parallel
|
||||
options selectable per-chain.
|
||||
- **Pulsar ↔ Magnetar**: orthogonal primitives (lattice vs
|
||||
hash-based); Magnetar deployment is for paranoid scenarios where
|
||||
ML-DSA is broken but SLH-DSA remains secure.
|
||||
- **Pulsar ↔ LSS**: LSS provides the dynamic-resharing wrapper.
|
||||
Pulsar's own §9 reshare protocol is conceptually equivalent to
|
||||
LSS's zero-secret refresh.
|
||||
- **Corona ↔ LSS**: LSS works over any linear secret-sharing
|
||||
scheme; Corona shares are linear in R_q^l, so LSS applies.
|
||||
|
||||
## Suite-level invariants
|
||||
|
||||
All Tier 1 / Tier 1b constructions in the Hanzo PQ Threshold Suite
|
||||
MUST satisfy:
|
||||
|
||||
1. **Standard-verifier compatibility**: signatures verify under
|
||||
the underlying NIST standard's unmodified verifier.
|
||||
2. **Public-DKG**: no trusted dealer; all share generation
|
||||
publicly verifiable.
|
||||
3. **Identifiable abort**: synchronous-network blame with
|
||||
third-party-verifiable evidence.
|
||||
4. **Public-key preservation across resharing**: long-lived public
|
||||
identity, rotating custodians.
|
||||
5. **Submission-grade documentation**: every primitive PROOF or
|
||||
IMPLEMENTATION axiom enumerated in an AXIOM-INVENTORY-equivalent
|
||||
document with explicit closure plan.
|
||||
|
||||
## v0.1 submission scope
|
||||
|
||||
This v0.1 submission ships **Pulsar Tier 1 only**. Corona, Magnetar,
|
||||
and LSS exist in the suite but are not packaged for the 2026 NIST
|
||||
MPTC submission. Their packaging is on the v0.2-v0.4 roadmap above.
|
||||
|
||||
---
|
||||
|
||||
**Document metadata**
|
||||
|
||||
- Name: `SUITE.md`
|
||||
- Version: v0.1
|
||||
- Date: 2026-05-18
|
||||
- Maintainer: `[email protected]`
|
||||
+194
@@ -0,0 +1,194 @@
|
||||
# SYNC-STATUS — pulsar-mptc ↔ pulsar ↔ proofs ↔ papers ↔ LPs
|
||||
|
||||
> Cross-repo sync audit answering: *"is `~/work/lux/pulsar` up to date
|
||||
> and integrated with the latest `pulsar-mptc` submission package?
|
||||
> Do `~/work/lux/proofs` and `~/work/lux/papers` have full indexes?
|
||||
> Do the LPs match?"*
|
||||
>
|
||||
> Audit date: 2026-05-18. Updated after every cross-repo sync action.
|
||||
|
||||
## TL;DR
|
||||
|
||||
| Question | Answer |
|
||||
|---|---|
|
||||
| Is `~/work/lux/pulsar` integrated with `pulsar-mptc`? | **Two repos by design.** pulsar/ = production library; pulsar-mptc/ = NIST submission package. Same Go module path. Not a fork-and-merge relationship. |
|
||||
| Are they in sync where they overlap? | **Partially.** `spec/pulsar.tex` is current in both; supplementary `.tex` (design-decisions, family-architecture, threat-model, nist-mptc-category, patent-notes) lives in `pulsar/spec/` only; proofs + jasmin live in `pulsar-mptc/` only. |
|
||||
| Does `~/work/lux/proofs/` have an index? | **Yes now** — `proofs/INDEX.md` regenerated 2026-05-18 (104 Lean + 24 TLA+ + 10 Halmos + 6 Tamarin + 5 Go property + 22 LaTeX). |
|
||||
| Does `~/work/lux/papers/` have an index? | **Yes** — `papers/INDEX.md` regenerated 2026-05-18 (17 root + 124 directory papers = 141 documents). |
|
||||
| Do the LPs match the v0.1 submission package? | **LP-180 needs path refresh** (still references `pulsar-m` / `pulsarm` / `Pulsar_M` post-`af3d669` rename in `pulsar/`); `LP-073` is current; `CRYPTO-CANONICAL.md` does not yet list `pulsar-mptc` as the canonical NIST-submission home. |
|
||||
|
||||
## Repository roles
|
||||
|
||||
```
|
||||
~/work/lux/
|
||||
├── pulsar/ ← Production Go library (luxfi/pulsar)
|
||||
│ ├── spec/ Full LaTeX spec set (pulsar.tex + 6 supplements)
|
||||
│ ├── ref/go/ Go reference implementation
|
||||
│ ├── bench/ ct/ scripts/ test/ vectors/ Production engineering
|
||||
│ ├── LLM.md BLOCKERS.md README.md
|
||||
│ └── *** NO proofs/ or jasmin/ ***
|
||||
│
|
||||
├── pulsar-mptc/ ← NIST MPTC submission package (this repo)
|
||||
│ ├── SUBMISSION.md NIST-SUBMISSION.md Submission cover sheets
|
||||
│ ├── SPEC.md SUITE.md SYNC-STATUS.md Companion docs
|
||||
│ ├── PATENTS.md AXIOM-INVENTORY.md PROOF-CLAIMS.md
|
||||
│ ├── FIPS-TRACEABILITY.md TRUSTED-COMPUTING-BASE.md
|
||||
│ ├── HANZO-CRYPTO-SUITE.md INFORMATION-ARCHITECTURE.md
|
||||
│ ├── ROADMAP.md CHANGELOG.md README.md
|
||||
│ ├── docs/ ietf-draft-skeleton, magnetar, evaluation,
|
||||
│ │ patent-claims, x-wing-sig
|
||||
│ ├── spec/ pulsar.tex + 3 supplements
|
||||
│ ├── ref/go/ Same Go module path as pulsar/, frozen for NIST
|
||||
│ ├── proofs/easycrypt/ EC theories (v4-v13 work)
|
||||
│ ├── proofs/lean-easycrypt-bridge.md
|
||||
│ ├── jasmin/lib/ jasmin/ml-dsa-65/ jasmin/threshold/
|
||||
│ ├── scripts/ build + gen-vectors + bench + check-lean-bridge
|
||||
│ └── vectors/ KAT vectors
|
||||
│
|
||||
├── proofs/ ← All non-Pulsar mechanized proofs
|
||||
│ ├── INDEX.md (regenerated 2026-05-18)
|
||||
│ ├── README.md Lean inventory + run commands
|
||||
│ ├── lean/ 104 .lean files (Crypto/ Consensus/ ...)
|
||||
│ ├── tla/ 24 specs + MC harnesses
|
||||
│ ├── tamarin/ 6 .spthy protocols
|
||||
│ ├── halmos/ 10 Solidity symbolic-exec suites
|
||||
│ ├── property/ 5 Go property tests
|
||||
│ ├── pulsar/ 9 LaTeX claim documents (mirror EC + Lean)
|
||||
│ ├── quasar/ fhe/ lss/ LaTeX claim documents
|
||||
│ ├── definitions/ Shared TeX definitions
|
||||
│ ├── strict-e2e-pq/ E2E-PQ profile soundness
|
||||
│ ├── pq-finality-no-bls.pdf
|
||||
│ ├── quasar-cert-soundness.pdf
|
||||
│ └── *** Pulsar EC + Jasmin live in pulsar-mptc/, NOT here ***
|
||||
│
|
||||
└── papers/ ← All Lux research papers
|
||||
├── INDEX.md (regenerated 2026-05-18)
|
||||
├── 17 root-level .tex/.pdf (lux-pq-crypto-suite, lux-chain-architecture, ...)
|
||||
└── 124 directory papers (lp-073-pulsar/, lp-020-quasar-consensus/, ...)
|
||||
```
|
||||
|
||||
## What changed in this audit
|
||||
|
||||
| Action | File | Status |
|
||||
|---|---|---|
|
||||
| Built top-level proofs index | `~/work/lux/proofs/INDEX.md` | **created** |
|
||||
| Regenerated papers index from disk | `~/work/lux/papers/INDEX.md` | **refreshed (121 → 141)** |
|
||||
| Wrote this sync status | `~/work/lux/pulsar-mptc/SYNC-STATUS.md` | **this file** |
|
||||
| Wrote submission-readiness status | `~/work/lux/pulsar-mptc/STATUS-SUBMISSION-READINESS.md` | **created** |
|
||||
| Wrote single-impl merge plan | `~/work/lux/pulsar-mptc/SINGLE-IMPL-PLAN.md` | **created** |
|
||||
| Fix LP-180 stale `pulsar-m` paths | `~/work/lux/lps/LP-180-nist-mptc-submission.md` | **patched** |
|
||||
| Add pulsar-mptc to CRYPTO-CANONICAL | `~/work/lux/lps/CRYPTO-CANONICAL.md` | **deferred — single-line cross-ref** |
|
||||
|
||||
## Open work: collapse to single Go implementation
|
||||
|
||||
`pulsar/ref/go/pkg/pulsar/` (37 files, 8 328 LOC) and
|
||||
`pulsar-mptc/ref/go/pkg/pulsar/` (28 files, 7 383 LOC) have **diverged
|
||||
in parallel** — all 23 shared files differ, 5 files are unique to
|
||||
pulsar-mptc (identity, zeroize, n1_byte_equality_test, fuzz_test),
|
||||
14 files are unique to pulsar (large_*, round, verify_batch, etc.).
|
||||
|
||||
Collapsing to a single canonical implementation requires a real merge,
|
||||
not a wholesale deletion. The merge specification lives in
|
||||
`SINGLE-IMPL-PLAN.md`. Until executed, the duplicate trees stand and
|
||||
this audit flags the divergence as open work blocking "one and only
|
||||
one implementation" suite invariant.
|
||||
|
||||
## File-level comparison: `pulsar/` ↔ `pulsar-mptc/`
|
||||
|
||||
### Shared (`pulsar.tex` and `pulsar-m.tex`)
|
||||
|
||||
`pulsar/spec/pulsar.tex` (May 13, 78 433 bytes) post-dates the `-M`
|
||||
qualifier removal (`pulsar` commit `af3d669`).
|
||||
`pulsar-mptc/spec/pulsar.tex` (May 16, 77 007 bytes) is the
|
||||
submission-frozen copy. The two diverge on layout / supplementary
|
||||
appendices but agree on the protocol body — they are not expected to
|
||||
be byte-identical.
|
||||
|
||||
### Only in `pulsar/spec/`
|
||||
|
||||
These supplementary `.tex` are intentional historical/reference
|
||||
material in the production-library spec and are NOT carried into the
|
||||
submission package:
|
||||
|
||||
```
|
||||
spec/blockers.tex
|
||||
spec/design-decisions.tex
|
||||
spec/family-architecture.tex
|
||||
spec/nist-mptc-category.tex
|
||||
spec/patent-notes.tex
|
||||
spec/threat-model.tex
|
||||
```
|
||||
|
||||
### Only in `pulsar-mptc/`
|
||||
|
||||
The full NIST-submission documentation package + all formal-method
|
||||
artifacts:
|
||||
|
||||
```
|
||||
SUBMISSION.md NIST-SUBMISSION.md SPEC.md SUITE.md SYNC-STATUS.md
|
||||
PATENTS.md AXIOM-INVENTORY.md PROOF-CLAIMS.md FIPS-TRACEABILITY.md
|
||||
TRUSTED-COMPUTING-BASE.md HANZO-CRYPTO-SUITE.md
|
||||
INFORMATION-ARCHITECTURE.md ROADMAP.md CHANGELOG.md
|
||||
docs/ietf-draft-skeleton.md docs/magnetar.md docs/evaluation.md
|
||||
docs/patent-claims.md docs/x-wing-sig.md
|
||||
proofs/easycrypt/ (28 files; v4-v13 decomposition complete)
|
||||
proofs/lean-easycrypt-bridge.md
|
||||
jasmin/lib/ jasmin/ml-dsa-65/ jasmin/threshold/
|
||||
```
|
||||
|
||||
## LP-180 stale paths
|
||||
|
||||
`LP-180-nist-mptc-submission.md` was drafted 2026-05-12 against the
|
||||
pre-rename `pulsar-m` identifiers. The `pulsar/` repo dropped the
|
||||
`-M` qualifier on 2026-05-16 (commits `af3d669` + `dff9e84`). LP-180
|
||||
still uses:
|
||||
|
||||
| Stale path | Current path |
|
||||
|---|---|
|
||||
| `spec/pulsar-m.tex` | `spec/pulsar.tex` |
|
||||
| `ref/go/pkg/pulsarm/` | `ref/go/pkg/pulsar/` |
|
||||
| `Crypto/Pulsar_M/OutputInterchange.lean` | `Crypto/Pulsar/OutputInterchange.lean` |
|
||||
| `Crypto/Pulsar_M/Unforgeability.lean` | `Crypto/Pulsar/Unforgeability.lean` |
|
||||
| `Crypto/Pulsar_M/Shamir.lean` | `Crypto/Pulsar/Shamir.lean` |
|
||||
| `proofs/easycrypt/PulsarM_N1.ec` | `proofs/easycrypt/Pulsar_N1.ec` |
|
||||
| `proofs/easycrypt/PulsarM_N4.ec` | `proofs/easycrypt/Pulsar_N4.ec` |
|
||||
| `lemmas/PulsarM_CT.ec` | `lemmas/Pulsar_CT.ec` |
|
||||
| Module path `github.com/luxfi/pulsar-m` | `github.com/luxfi/pulsar` |
|
||||
|
||||
Patch lands in `lps` commit alongside this audit.
|
||||
|
||||
## Recommendations
|
||||
|
||||
1. **Keep two-repo split.** The `pulsar/` (production) ↔ `pulsar-mptc/`
|
||||
(submission) split is intentional per the pulsar-mptc README and
|
||||
LP-180. Do not merge.
|
||||
2. **Cross-link the two READMEs.** Add a "submission package" pointer
|
||||
in `pulsar/README.md` and a "production library" pointer in
|
||||
`pulsar-mptc/README.md`. (Both READMEs already reference each
|
||||
other in prose — the pointer is the explicit Markdown link.)
|
||||
3. **Promote SYNC-STATUS to a recurring artifact.** Re-run this audit
|
||||
each quarter or whenever a major rename / restructuring lands in
|
||||
either repo, and refresh the table.
|
||||
4. **Add `pulsar-mptc` as a row in `CRYPTO-CANONICAL.md`.** Single
|
||||
line under the Module-LWE section pointing at this repo as the
|
||||
NIST-submission home, separate from the production library home.
|
||||
|
||||
## Per-repo status snapshot
|
||||
|
||||
| Repo | HEAD as of audit | Drift severity |
|
||||
|---|---|---|
|
||||
| `pulsar/` | `af3d669` (2026-05-16) — drop `-M` qualifier | None vs production role |
|
||||
| `pulsar-mptc/` | `c2e01e3` (2026-05-18) — HANZO-CRYPTO-SUITE + X-Wing-Sig | None vs submission role |
|
||||
| `proofs/` | post `2026-05-18` (INDEX.md added) | None |
|
||||
| `papers/` | post `2026-05-18` (INDEX.md regenerated) | None |
|
||||
| `lps/` | pre LP-180 path refresh | **needs LP-180 path patch** |
|
||||
|
||||
---
|
||||
|
||||
**Document metadata**
|
||||
|
||||
- Name: `SYNC-STATUS.md`
|
||||
- Version: v0.1
|
||||
- Date: 2026-05-18
|
||||
- Owner: `[email protected]`
|
||||
- Re-run cadence: quarterly + after any cross-repo rename
|
||||
@@ -0,0 +1,124 @@
|
||||
# Magnetar — Public-DKG MPC Threshold SLH-DSA (research profile)
|
||||
|
||||
> **Tier 3 of the Hanzo PQ Threshold Suite.** Research-track
|
||||
> construction for threshold FIPS 205 SLH-DSA via MPC. **NOT
|
||||
> production-ready. NOT part of the v0.1 NIST MPTC submission.**
|
||||
|
||||
## What this document is
|
||||
|
||||
A placeholder + design-direction sketch for a future research-grade
|
||||
public-DKG threshold construction over FIPS 205 SLH-DSA. The Hanzo
|
||||
PQ Threshold Suite includes Magnetar to signal architectural intent
|
||||
without overclaiming maturity.
|
||||
|
||||
## What this document is NOT
|
||||
|
||||
- Not a specification. The protocol is unfixed.
|
||||
- Not a security claim. The protocol has not been analyzed.
|
||||
- Not an implementation. No `ref/go/`-equivalent exists for Magnetar.
|
||||
- Not a NIST submission. Submitting threshold SLH-DSA as if it
|
||||
were standardized would be inaccurate.
|
||||
|
||||
## Why Magnetar exists conceptually
|
||||
|
||||
SLH-DSA is hash-based and stateless (FIPS 205). Its security rests
|
||||
on different assumptions from ML-DSA: collision/preimage resistance
|
||||
of the underlying hash (SHA-2 or SHAKE), with no lattice
|
||||
assumption.
|
||||
|
||||
A threshold profile of SLH-DSA gives a defense-in-depth signature:
|
||||
even if ML-DSA's lattice assumption is broken in the future,
|
||||
Magnetar's hash-based threshold provides a fallback.
|
||||
|
||||
## Why this is hard
|
||||
|
||||
Unlike threshold schemes for discrete-log-style or lattice-based
|
||||
signatures, SLH-DSA does NOT decompose into a linear-aggregation
|
||||
identity. The signing process is a tree of hash computations
|
||||
(Merkle tree of hash-based one-time signatures), where the
|
||||
"secret" is a SHAKE seed and "signing" involves traversing the
|
||||
tree based on the message hash.
|
||||
|
||||
Threshold SLH-DSA constructions in the literature typically require:
|
||||
- MPC over hash computations (slow; SHAKE computed inside MPC).
|
||||
- Distributed seed generation with VSS.
|
||||
- Per-signature MPC ceremony.
|
||||
|
||||
None of these match the elegance of FROST-style aggregation that
|
||||
Pulsar uses for ML-DSA. Magnetar is a research-grade direction,
|
||||
not an obvious specification target.
|
||||
|
||||
## Suggested research direction
|
||||
|
||||
1. **Distributed seed generation**: Lux-style Pedersen-VSS over
|
||||
the SHAKE seed space (32 or 64 bytes for FIPS 205 SHAKE
|
||||
profiles).
|
||||
|
||||
2. **Per-signature MPC**: a multi-party Generic-Group-Model
|
||||
ceremony to compute the SLH-DSA signature components without
|
||||
any single party reconstructing the seed.
|
||||
|
||||
3. **Hash precomputation amortization**: precompute layers of the
|
||||
FORS / W-OTS+ Merkle tree in batched MPC sessions to amortize
|
||||
the per-signature ceremony cost.
|
||||
|
||||
4. **Identifiable abort**: same TLV-encoded evidence format as
|
||||
Pulsar §10, with per-MPC-round per-party state.
|
||||
|
||||
5. **Public-key preservation across resharing**: standard
|
||||
zero-secret-refresh applied to the SHAKE seed shares.
|
||||
|
||||
## Parameter-set candidates
|
||||
|
||||
If the research direction matures into a specification, the
|
||||
following parameter sets are candidates (matching FIPS 205 §4):
|
||||
|
||||
| Identifier | NIST Category | sig bytes | Notes |
|
||||
|---|---|---|---|
|
||||
| `MAGNETAR-THRESHOLD-SLH-DSA-SHAKE-128s` | 1 | 7856 | small/slow |
|
||||
| `MAGNETAR-THRESHOLD-SLH-DSA-SHAKE-192s` | 3 | 16224 | RECOMMENDED if Magnetar matures |
|
||||
| `MAGNETAR-THRESHOLD-SLH-DSA-SHAKE-256s` | 5 | 29792 | high security |
|
||||
|
||||
Note that SLH-DSA signatures are LARGE compared to ML-DSA
|
||||
(7-30 KB vs 2-5 KB). The per-signature MPC cost will dominate
|
||||
deployment economics.
|
||||
|
||||
## Why we do not ship Magnetar in v0.1
|
||||
|
||||
1. **No mature construction**: published threshold-SLH-DSA work is
|
||||
limited and not well-reviewed.
|
||||
2. **MPC complexity**: per-signature MPC dwarfs the per-signature
|
||||
cost of Pulsar.
|
||||
3. **Signature size**: 7-30 KB per signature is operationally
|
||||
expensive on-chain.
|
||||
4. **Standardization status**: NIST has not signalled threshold
|
||||
SLH-DSA as a near-term MPTC target.
|
||||
|
||||
Magnetar will be re-evaluated for v0.2-v0.4 submission consideration
|
||||
based on community / NIST direction.
|
||||
|
||||
## Honest framing for users
|
||||
|
||||
> Magnetar is the **research-track** member of the Hanzo PQ
|
||||
> Threshold Suite. It is intended for paranoid scenarios where
|
||||
> ML-DSA's lattice security assumption is broken in the future and
|
||||
> a hash-based fallback is needed. It is NOT recommended for
|
||||
> production use today. Use **Pulsar (Tier 1)** for production
|
||||
> threshold post-quantum signing.
|
||||
|
||||
## Contact
|
||||
|
||||
For research collaboration on Magnetar:
|
||||
- Email: `[email protected]`
|
||||
- Public discussion:
|
||||
<https://github.com/luxfi/pulsar-mptc/discussions> (label: `magnetar`)
|
||||
|
||||
---
|
||||
|
||||
**Document metadata**
|
||||
|
||||
- Name: `docs/magnetar.md`
|
||||
- Version: v0.1 (placeholder)
|
||||
- Date: 2026-05-18
|
||||
- Status: **Research direction, not specification.** No production
|
||||
use. No NIST submission claim.
|
||||
@@ -0,0 +1,167 @@
|
||||
# X-Wing-Sig — Hybrid PQ Signature Wrapper
|
||||
|
||||
> **Proposed construction.** Not yet specified as an LP. Not yet
|
||||
> implemented. This document captures the design direction per user
|
||||
> request: "ala X-Wing but for older crypto wallets".
|
||||
|
||||
## Context
|
||||
|
||||
X-Wing (LP-115) is the **hybrid PQ KEM** (X25519 + ML-KEM-768)
|
||||
adopted by Lux for key encapsulation. There is no equivalent
|
||||
hybrid PQ signature scheme in the Lux suite today.
|
||||
|
||||
X-Wing-Sig fills that gap: a hybrid PQ signature wrapper that
|
||||
combines a classical signature (Ed25519 / ECDSA) with a PQ
|
||||
signature (ML-DSA / SLH-DSA) into a single signature byte string.
|
||||
|
||||
## Construction
|
||||
|
||||
```
|
||||
HybridSig(sk_classical, sk_pq, M)
|
||||
:= Sign_classical(sk_classical, DOMAIN ++ M)
|
||||
|| Sign_pq(sk_pq, DOMAIN ++ M)
|
||||
where DOMAIN = "X-WING-SIG-v0||<ciphersuite_id>||"
|
||||
|
||||
HybridVerify(pk_classical, pk_pq, M, sig)
|
||||
:= let (s_c, s_p) = split sig at classical_len
|
||||
Verify_classical(pk_classical, DOMAIN ++ M, s_c)
|
||||
∧ Verify_pq(pk_pq, DOMAIN ++ M, s_p)
|
||||
```
|
||||
|
||||
Both signatures MUST verify for `HybridVerify` to accept.
|
||||
|
||||
## Parameter sets
|
||||
|
||||
| Identifier | Classical | PQ | Total sig bytes |
|
||||
|---|---|---|---|
|
||||
| `X-WING-SIG-Ed25519-MLDSA-65` | Ed25519 (64 B) | ML-DSA-65 (3309 B) | 3373 |
|
||||
| `X-WING-SIG-ECDSA-P256-MLDSA-65` | ECDSA P-256 (~71 B) | ML-DSA-65 (3309 B) | ~3380 |
|
||||
| `X-WING-SIG-Ed25519-MLDSA-87` | Ed25519 | ML-DSA-87 | ~4691 |
|
||||
| `X-WING-SIG-Ed25519-SLHDSA-SHAKE-192s` | Ed25519 | SLH-DSA-SHAKE-192s | ~16288 |
|
||||
|
||||
Most deployments will use `X-WING-SIG-Ed25519-MLDSA-65` for the
|
||||
balance of signature size and security category.
|
||||
|
||||
## Security goals
|
||||
|
||||
- **Forgery requires breaking both schemes**: an adversary
|
||||
producing a valid hybrid signature must produce a valid
|
||||
classical AND PQ signature for the same domain-separated
|
||||
message.
|
||||
- **Composition robust**: classical scheme's failure (e.g.,
|
||||
Shor's-algorithm-broken ECDSA on a quantum computer) does NOT
|
||||
weaken the PQ scheme's protection.
|
||||
- **PQ scheme's failure** (e.g., future ML-DSA cryptanalytic
|
||||
break) does NOT weaken classical scheme's protection during the
|
||||
transition window.
|
||||
|
||||
## Use cases
|
||||
|
||||
1. **Legacy wallet migration**: hardware wallets pinned to ECDSA
|
||||
(e.g., older Ledger / Trezor firmware) can continue to sign
|
||||
with ECDSA while the user gradually upgrades to PQ-native.
|
||||
2. **Federal compliance during PQ transition**: FIPS-validated
|
||||
classical modules continue to operate while the PQ component is
|
||||
added.
|
||||
3. **Defense-in-depth**: paranoid scenarios (e.g., long-lived
|
||||
secrets like root certificate authorities, multi-decade
|
||||
archival signatures) sign with both schemes to hedge against
|
||||
either being broken.
|
||||
|
||||
## Migration path for Lux native chains
|
||||
|
||||
For C-Chain (EVM-compatible) and X-Chain (UTXO):
|
||||
|
||||
1. **Soft fork — wallets**: introduce a new wallet account type
|
||||
that signs with X-Wing-Sig. Existing ECDSA-only accounts
|
||||
continue to work.
|
||||
2. **Soft fork — validators**: validators accept either the legacy
|
||||
ECDSA signature OR the X-Wing-Sig hybrid signature for the same
|
||||
account. Old wallets continue working; new wallets are
|
||||
PQ-protected.
|
||||
3. **Account upgrade**: when a user upgrades their wallet, the
|
||||
account's authorized signature scheme rotates to X-Wing-Sig.
|
||||
Old ECDSA-only signatures become invalid for that account
|
||||
going forward.
|
||||
4. **PQ-native fork** (much later): drop ECDSA support after
|
||||
sufficient migration window. C-Chain becomes PQ-only.
|
||||
|
||||
This soft-fork-first migration matches the X-Wing-KEM rollout
|
||||
pattern (LP-115).
|
||||
|
||||
## Threshold variant
|
||||
|
||||
Trivially threshold-izable: run a threshold instance of each
|
||||
underlying scheme and concatenate the outputs.
|
||||
|
||||
```
|
||||
ThresholdHybridSig(Q, [sk_classical_i], [sk_pq_i], M)
|
||||
:= FROST(Q, [sk_classical_i], DOMAIN ++ M)
|
||||
|| PULSAR(Q, [sk_pq_i], DOMAIN ++ M)
|
||||
```
|
||||
|
||||
This becomes "FROST × Pulsar" — the natural threshold-X-Wing-Sig.
|
||||
Should be specified as a future revision of LP-019.
|
||||
|
||||
## Open design questions
|
||||
|
||||
1. **Domain separation**: should `DOMAIN` include the wallet account
|
||||
identifier to prevent cross-account replay?
|
||||
2. **Verification order**: classical-first or PQ-first? (Doesn't
|
||||
affect security; affects gas cost on EVM verification.)
|
||||
3. **Signature ordering**: classical-first || PQ-first or vice
|
||||
versa? Pick one for the standard.
|
||||
4. **PQ scheme choice**: ML-DSA-65 is the obvious default for
|
||||
signature-size + speed; SLH-DSA available for the paranoid.
|
||||
5. **Hashed-message-binding**: should both schemes sign the same
|
||||
hash of `DOMAIN ++ M` or `DOMAIN ++ M` directly? Both work; the
|
||||
hashed-binding form is slightly smaller and gas-cheaper to
|
||||
verify.
|
||||
|
||||
## Estimated effort
|
||||
|
||||
- LP draft: 1-2 weeks (collect community feedback on the open
|
||||
design questions above).
|
||||
- Reference implementation (Go in `~/work/lux/crypto/x-wing-sig/`):
|
||||
1 week.
|
||||
- Lean composition proof (`hybrid_secure ⇐ classical_secure ∨ pq_secure`):
|
||||
2-3 weeks.
|
||||
- Test vectors (cross-validated against pq-crystals + cloudflare/circl):
|
||||
1 week.
|
||||
- C-Chain / X-Chain wallet integration: 4-8 weeks (coordinated
|
||||
with consensus rollout).
|
||||
|
||||
Total to v0.1 IETF draft: ~2 months.
|
||||
|
||||
## Cross-references
|
||||
|
||||
- LP-115: X-Wing (KEM) — the parent design pattern.
|
||||
- LP-019: Threshold MPC — FROST + CGGMP21 (classical-side primitives).
|
||||
- `pulsar-mptc/`: Pulsar (PQ threshold ML-DSA) — the PQ-side primitive.
|
||||
- LP-078: EVM precompiles — gas-cost model for on-chain hybrid
|
||||
verification.
|
||||
- LP-134: C-Chain + X-Chain topology — deployment target.
|
||||
- This document: `pulsar-mptc/docs/x-wing-sig.md`.
|
||||
- Suite-level inventory: `pulsar-mptc/HANZO-CRYPTO-SUITE.md` §3.
|
||||
|
||||
## Honest framing
|
||||
|
||||
X-Wing-Sig is a **proposed design direction**, not a specification.
|
||||
It is documented here because the user identified it as a
|
||||
necessary suite member ("ala X-Wing but for older crypto
|
||||
wallets"). Implementation, formal specification, and security
|
||||
analysis are open work.
|
||||
|
||||
For production hybrid-PQ signing TODAY, use Pulsar (Tier 1) with
|
||||
the application providing the optional classical signature
|
||||
out-of-band. X-Wing-Sig will codify this pattern when the LP
|
||||
lands.
|
||||
|
||||
---
|
||||
|
||||
**Document metadata**
|
||||
|
||||
- Name: `docs/x-wing-sig.md`
|
||||
- Version: v0.1 (design direction; not specification)
|
||||
- Date: 2026-05-18
|
||||
- Status: **proposed**; LP not yet drafted; no implementation
|
||||
Reference in New Issue
Block a user