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:

Quasar Consensus

Lux's Quasar consensus uses a triple consensus signature scheme combining three independent cryptographic families -- classical (BLS) and two post-quantum (Pulsar + ML-DSA):

All three paths run in parallel via TripleSignRound1. A QuasarCert is the finality certificate containing a BLS aggregate signature and aggregated PQ proof (Pulsar + ML-DSA). Blocks are final only when all three certificates verify. An attacker must break ECDL (BLS), Module-LWE (ML-DSA), and Module-SIS (Pulsar) simultaneously to forge a consensus vote.

Smart Account PQ Signing

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

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