mirror of
https://github.com/luxfi/pulsar.git
synced 2026-09-24 00:25:52 +00:00
docs: delete patent-notes-draft.md (superseded by PATENTS.md) + x-wing-sig.md (design proposal without LP/impl)
This commit is contained in:
@@ -1,91 +0,0 @@
|
||||
# Notes on patent claims (draft)
|
||||
|
||||
> Required by NIST MPTC IR 8214C §5 as a package deliverable. This document
|
||||
> is collected over the development period and finalized for the
|
||||
> submission.
|
||||
|
||||
## Status
|
||||
|
||||
**Draft.** No patent claims have been formally identified. This page
|
||||
tracks claims as contributors disclose them.
|
||||
|
||||
## Inherited from upstream
|
||||
|
||||
### Pulsar (`luxfi/pulsar`)
|
||||
|
||||
Pulsar reuses Pulsar's protocol structure. Pulsar's IP posture per
|
||||
its README:
|
||||
|
||||
- Apache-2.0 licensed.
|
||||
- Patent grant per Apache 2.0 §3 from each contributor.
|
||||
- No known active patent claims as of repository creation.
|
||||
|
||||
This applies to Pulsar to the extent that Pulsar code or protocol
|
||||
elements are derivative of Pulsar.
|
||||
|
||||
### Corona (`luxfi/corona`)
|
||||
|
||||
Pulsar (and therefore Pulsar) is a fork of academic Corona.
|
||||
Corona (ePrint 2024/1113) authors: Cecilia Boschini, Darya Kaviani,
|
||||
Russell W. F. Lai, Giulio Malavolta, Akira Takahashi, Mehdi Tibouchi.
|
||||
Corona's open-source repo is Apache-2.0 with no asserted patent
|
||||
claims as of mid-2026. Pulsar's M-LWE adaptation does not import
|
||||
Corona code directly but inherits the protocol structure.
|
||||
|
||||
### ML-DSA / FIPS 204
|
||||
|
||||
ML-DSA is a NIST-standardized algorithm. The Dilithium team's IP
|
||||
disclosures during NIST PQC standardization are public on the NIST
|
||||
PQC website. Pulsar targets output interchangeability with FIPS 204
|
||||
but does not assert any rights over FIPS 204 itself.
|
||||
|
||||
## Contributor disclosures
|
||||
|
||||
Per CONTRIBUTING.md, every commit's `Signed-off-by` line is taken as
|
||||
either:
|
||||
1. An explicit assertion that the contributor has no relevant patent
|
||||
claims, OR
|
||||
2. A reference to a disclosed claim listed below.
|
||||
|
||||
| date | contributor | type | disclosure |
|
||||
|---|---|---|---|
|
||||
| 2026-05-10 | Lux Industries Inc | initial repo | no claims asserted |
|
||||
|
||||
(Updated as contributions land.)
|
||||
|
||||
## Third-party patents we may need to navigate
|
||||
|
||||
Live concerns to investigate before submission:
|
||||
|
||||
- Lattice-estimator usage (we use the open-source estimator; license
|
||||
pass-through to MIT).
|
||||
- Gaussian sampler implementation (FIPS 204 references CDT; alternate
|
||||
rejection samplers may have IP).
|
||||
- Polynomial multiplication via NTT (standard, no known IP).
|
||||
- Pedersen commitments (1991 paper, expired patents).
|
||||
|
||||
The submission's Notes on Patent Claims will explicitly call out each
|
||||
of these.
|
||||
|
||||
## NIST MPTC submission requirements
|
||||
|
||||
NIST IR 8214C §5 (Notes on Patent Claims) requires:
|
||||
|
||||
> Submitter(s) shall include a statement of any patent claims known to
|
||||
> them that may be relevant to the submitted package, regardless of who
|
||||
> owns the claim. Statements of "no known claims" are acceptable.
|
||||
|
||||
Our final statement, once the spec freezes:
|
||||
|
||||
> *To be drafted at spec freeze. Will incorporate every disclosure in
|
||||
> the contributor table above, every inherited claim from Pulsar /
|
||||
> Corona / ML-DSA, and the third-party investigation outcome.*
|
||||
|
||||
## Process
|
||||
|
||||
1. Every PR review checks for new IP-relevant code.
|
||||
2. Significant cryptographic additions (new sampling routine, new
|
||||
commitment shape, new aggregation step) trigger an explicit IP
|
||||
review with one of the sponsor's IP counsel.
|
||||
3. Final statement assembled at freeze, included in
|
||||
`spec/pulsar.pdf` Appendix A.
|
||||
@@ -1,167 +0,0 @@
|
||||
# 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 (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: `./docs/x-wing-sig.md`.
|
||||
- Suite-level inventory: `./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