Post-Quantum Security

Lux Network is designed from the ground up to be resilient against quantum computing attacks. As quantum computers advance, the cryptographic foundations of most blockchains will become vulnerable. Lux addresses this by integrating post-quantum cryptographic primitives at the protocol level.

The Quantum Threat

Classical public-key cryptography (RSA, ECDSA, Ed25519) relies on the hardness of integer factorization or discrete logarithm problems. A sufficiently powerful quantum computer running Shor's algorithm can break these in polynomial time.

What Is at Risk

NIST Post-Quantum Standards

Lux Network aligns with the NIST Post-Quantum Cryptography standardization process, adopting algorithms from the finalized standard set.

ML-DSA-65 (FIPS 204)

ML-DSA-65 (formerly ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium)) is a lattice-based digital signature scheme standardized by NIST as the primary post-quantum signature algorithm.

• Security basis: Module Learning With Errors (MLWE) problem
• Security level: NIST Level 3 (192-bit)
• Signature size: ~3.3 KB
• Public key size: ~1.95 KB
• Performance: Fast signing and verification, suitable for blockchain throughput requirements
• Use in Lux: Default signature scheme for new validator keys and transaction signing

SLH-DSA (FIPS 205)

SLH-DSA (FIPS 205, formerly SPHINCS+) is a hash-based signature scheme standardized by NIST as a conservative alternative.

• Security basis: Security of the underlying hash function only
• Signature size: ~7.8 KB (SLH-DSA-128f) to ~49 KB (SLH-DSA-256s)
• Public key size: 32-64 bytes
• Performance: Slower signing but very fast verification
• Use in Lux: Available as a fallback signature scheme for maximum conservatism

ML-KEM-768 (FIPS 203)

ML-KEM-768 (formerly ML-KEM (FIPS 203, formerly CRYSTALS-Kyber)) is a lattice-based key encapsulation mechanism standardized by NIST for post-quantum key exchange.

• Security basis: Module Learning With Errors (MLWE) problem
• Security level: NIST Level 3 (192-bit)
• Ciphertext size: ~1.09 KB
• Public key size: ~1.18 KB
• Use in Lux: PQ-TLS 1.3 key exchange via X25519MLKEM768 hybrid, inter-node communication. Go 1.26 defaults to ML-KEM-768 for TLS key exchange -- no additional configuration required

Comparison

Hybrid Approach

Lux uses a hybrid classical + post-quantum strategy during the transition period. This means transactions can carry both a classical signature and a post-quantum signature.

Why Hybrid?

• Defense in depth: If the lattice assumption (MLWE) is unexpectedly broken, the classical signature still provides security against classical attackers
• Smooth migration: Existing tooling and wallets can continue operating during transition
• No single point of cryptographic failure: An attacker must break both schemes simultaneously

Impact on Blockchain Design

Larger Transactions

Post-quantum signatures are significantly larger than classical ones. Lux addresses this through:

• Efficient encoding: Compact binary serialization for PQ signatures
• Aggregation research: Investigating lattice-based signature aggregation to reduce per-block overhead
• Adjusted block sizes: Block size limits account for larger signature payloads

Key Management

PQ keys require different handling:

Classical key:    32 bytes private + 33 bytes public  = ~65 bytes
ML-DSA-65 key:   4.0 KB private  + 1.95 KB public    = ~5.95 KB

Lux wallets store PQ keys alongside classical keys, with the same HD derivation structure extended to support lattice-based key generation.

Address Format

Lux uses a PQ-aware address format that encodes the key type:

lux1qpq...    # Post-quantum address (ML-DSA-65)
lux1qph...    # Post-quantum address (SLH-DSA)
lux1c...      # Classical address (Ed25519)

Migration Strategy

For existing users and applications:

Parallel Post-Quantum: Pulsar ∥ Corona

Quasar finality (see Consensus) is sealed by a compact-certificate envelope whose post-quantum strength rests on two independent lattice families, each contributing one O(1) threshold signature:

Under the STRICT_QUASAR posture both legs sign one canonical finality message under one P-Chain-pinned key-era (AND-mode), alongside the classical BLS aggregate. Forging finality means breaking both Module-LWE and Ring-LWE simultaneously — two unrelated lattice problems, not one.

Pulsar = TALUS threshold ML-DSA

Pulsar's TALUS construction produces a threshold ML-DSA-65 signature that is byte-identical to a single-party FIPS-204 signature on the same message and public key — so a verifier needs no special threshold logic. It is built from a dealerless Shamir nonce DKG, a distributed w1 derivation (CEF), and a real secure-comparison circuit (CSCP).

The honest framing. The known impossibility is FROST-style additive threshold ML-DSA, not threshold ML-DSA in general — TALUS routes around it with binding-commit (BCC) + CEF rather than additive nonce sharing. But a fully dealerless key DKG for ML-DSA is genuinely unreachable: an additive sum of FIPS secrets breaks the S_η norm bound (proven), so Pulsar key generation is a committee/ceremony step. Pulsar ships two custody profiles for that step — Pulsar-MPC (honest-majority N ≥ 2T−1) and Pulsar-TEE (attested enclave). Because Pulsar keygen is not dealerless, Corona carries the dealerless, permissionless-public PQ guarantee: Ringtail's Pedersen DKG needs no trusted dealer, which is what makes it sound for an open validator set.

Hybrid identity & transport

Post-quantum strength is layered on classical primitives, never a clean replacement:

• Transport. Node-to-node PQ-TLS 1.3 uses the X-Wing hybrid KEM (X25519 + ML-KEM-768, negotiated as X25519MLKEM768) — Go 1.26's default. Breaking it requires breaking both X25519 and ML-KEM-768.
• Identity. Validator and account identity bind a classical key with ML-DSA-65 (hybrid signatures), so an identity forgery requires breaking both the classical and the lattice scheme.

Smart Account PQ Signing

EVM smart accounts (ERC-4337 / Safe) can verify post-quantum signatures on-chain via precompiles:

See PQ Crypto Precompiles for the full slot map and gas schedule. The SafeMLDSASigner module implements ERC-1271 signature verification using ML-DSA-65, allowing Safe multisig wallets to authorize transactions with post-quantum keys. This works on the C-Chain and all sovereign L1 EVM chains with PQ precompiles enabled.

// Safe module: verify ML-DSA-65 via precompile
function isValidSignature(bytes32 hash, bytes memory signature)
    external view returns (bytes4)
{
    (bool ok, bytes memory result) = ML_DSA_PRECOMPILE.staticcall(
        abi.encode(ownerPQKey, hash, signature)
    );
    require(ok && abi.decode(result, (bool)), "PQ sig invalid");
    return 0x1626ba7e; // ERC-1271 magic value
}

Further Reading

• Architecture - How PQ cryptography integrates with each chain
• Tokenomics - Staking with PQ keys
• SDKs - SDK support for PQ key types