MetaMUI Post-Quantum Suite

Mobile wallet-optimized quantum-resistant algorithms

The MetaMUI Post-Quantum Suite provides quantum-resistant alternatives while maintaining the performance and usability principles established in our classical suite.

Core Algorithm Transitions

AEAD: ChaCha20-Poly1305 (Unchanged)

No quantum threat to symmetric cryptography

  • Quantum Impact: None - symmetric algorithms maintain security against quantum attacks
  • Key Size: 256-bit keys provide ~128-bit post-quantum security (Grover’s algorithm)
  • Performance: Identical to classical implementation (~1,200 MB/s)
  • Migration: No changes required
  • Advantage: Proven performance and security carry forward unchanged

Key Exchange: X25519 → ML-KEM-768

NIST standard compliance for production deployment

  • Classical: X25519 (128-bit security, vulnerable to quantum)
  • Post-Quantum: ML-KEM-768 (NIST standardized, ~128-bit PQC security)
  • Trade-off: Larger keys (1184 bytes public) vs quantum resistance
  • Performance: ~10k encapsulations/sec (vs 50k X25519 operations/sec)
  • Advantage: NIST standardization ensures production readiness and interoperability

Signatures: Sr25519 → Falcon-512

Mobile wallet speed optimization

  • Classical: Sr25519 (batch verification optimized)
  • Post-Quantum: Falcon-512 (individual signature speed optimized)
  • Strategic Shift: From blockchain infrastructure performance → end-user mobile experience
  • Performance: ~8k signs/sec, ~15k verifications/sec (optimized for mobile)
  • Trade-off: Lose batch verification capability, gain mobile responsiveness and lower latency
  • Advantage: Compact signatures (690 bytes), fast verification, battery efficient

Hashing: Blake3 (Unchanged)

Maintained parallel performance

  • Quantum Impact: None - hash functions maintain security (with doubled output for same security level)
  • Performance: Identical parallel processing capabilities (~2,000 MB/s)
  • Security: 256-bit output provides ~128-bit post-quantum security
  • Migration: No changes required
  • Advantage: Parallel hashing performance continues unchanged

Performance Analysis

Algorithm Performance Comparison

Operation Classical Post-Quantum Performance Ratio Notes
AEAD ChaCha20-Poly1305: 1,200 MB/s ChaCha20-Poly1305: 1,200 MB/s 1:1 No change needed
Key Exchange X25519: 50k ops/sec ML-KEM-768: 10k ops/sec 5:1 Acceptable for key agreement
Signatures Sr25519: 15k batch/sec Falcon-512: 15k verify/sec 1:1 Individual vs batch
Hashing Blake3: 2,000 MB/s Blake3: 2,000 MB/s 1:1 No change needed

Memory Requirements

Algorithm Classical Post-Quantum Size Increase Impact
Public Keys X25519: 32 bytes ML-KEM-768: 1,184 bytes 37x Manageable for key exchange
Private Keys X25519: 32 bytes ML-KEM-768: 2,400 bytes 75x Server-side storage impact
Signatures Sr25519: 64 bytes Falcon-512: 690 bytes 11x Mobile bandwidth consideration
Ciphertexts N/A ML-KEM-768: 1,088 bytes N/A Per-session overhead

Mobile Wallet Optimization Features

Battery Efficiency

  • Falcon-512: Optimized for individual signature operations common in wallet usage
  • ChaCha20-Poly1305: Unchanged battery-efficient encryption
  • ML-KEM-768: Key exchange happens infrequently, minimal battery impact
  • Blake3: Parallel processing reduces CPU time and energy consumption

Network Optimization

  • Signature Size: Falcon-512 provides reasonable signature size for mobile networks
  • Key Exchange: ML-KEM-768 overhead acceptable for session establishment
  • Streaming: ChaCha20-Poly1305 and Blake3 support efficient streaming operations

Storage Considerations

  • Key Storage: Larger ML-KEM keys require secure storage optimization
  • Signature Caching: Falcon-512 signatures benefit from efficient caching strategies
  • Metadata: Compact algorithm identifiers for hybrid classical+PQC modes

Algorithm Selection Rationale

ML-KEM-768 over NTRU Prime

Standards compliance for production deployment

  • NIST Standardization: ML-KEM-768 is officially standardized (FIPS 203)
  • Industry Adoption: Broader ecosystem support and integration
  • Security Analysis: Extensive public scrutiny through NIST PQC competition
  • Interoperability: Standard ensures compatibility across implementations
  • Risk Management: Conservative choice for production deployment

Falcon-512 over Dilithium

Mobile performance over theoretical margins

  • Signature Size: Falcon-512 (~690 bytes) vs Dilithium (~2,420 bytes)
  • Verification Speed: Falcon-512 optimized for individual verification (mobile wallets)
  • Memory Usage: Lower RAM requirements for mobile devices
  • Battery Impact: More efficient for typical wallet signing patterns
  • Network Efficiency: Smaller signatures reduce mobile data usage

Security Properties

Post-Quantum Security Levels

Algorithm Classical Security Post-Quantum Security Quantum Attack Model
ChaCha20-Poly1305 256-bit ~128-bit Grover’s algorithm
ML-KEM-768 N/A ~128-bit Shor’s algorithm resistance
Falcon-512 N/A ~128-bit Quantum signature forgery resistance
Blake3 256-bit ~128-bit Grover’s algorithm

Attack Resistance

Classical Attacks

  • All algorithms: Maintain security against classical computational attacks
  • Side-channels: Constant-time implementations resist timing and cache attacks
  • Implementation: Secure memory handling and zeroization

Quantum Attacks

  • Symmetric crypto: ChaCha20-Poly1305 and Blake3 resist quantum attacks with appropriate key sizes
  • Public-key crypto: ML-KEM-768 and Falcon-512 specifically designed for quantum resistance
  • Hybrid security: Classical+PQC modes provide defense-in-depth during transition

Integration Examples

Basic Post-Quantum Usage

from metamui_crypto import PostQuantumSuite

# Initialize post-quantum suite
pq_suite = PostQuantumSuite()

# ML-KEM-768 key exchange
ciphertext, shared_secret = pq_suite.key_exchange.mlkem768_encapsulate(public_key)
shared_secret = pq_suite.key_exchange.mlkem768_decapsulate(ciphertext, private_key)

# Falcon-512 signatures
signature = pq_suite.signatures.falcon512_sign(message, signing_key)
valid = pq_suite.signatures.falcon512_verify(message, signature, public_key)

# Unchanged algorithms
ciphertext, tag = pq_suite.aead.chacha20_poly1305_encrypt(plaintext, nonce, key)
hash_value = pq_suite.hashing.blake3(data)

Hybrid Classical+PQC Mode

from metamui_crypto import HybridSuite

# Use both classical and post-quantum for defense-in-depth
hybrid = HybridSuite()

# Dual key exchange
classical_secret = hybrid.key_exchange.x25519(priv_key_25519, pub_key_25519)
pq_secret = hybrid.key_exchange.mlkem768_encapsulate(pub_key_mlkem)
combined_secret = hybrid.kdf.combine_secrets(classical_secret, pq_secret)

# Dual signatures
classical_sig = hybrid.signatures.sr25519_sign(message, sr25519_key)
pq_sig = hybrid.signatures.falcon512_sign(message, falcon_key)

Mobile Wallet Optimization

# Optimized for mobile wallet usage patterns
class MobileWallet:
    def __init__(self):
        self.pq_suite = PostQuantumSuite()
        self.key_cache = {}
    
    def sign_transaction(self, transaction, wallet_key):
        # Falcon-512 optimized for individual signatures
        return self.pq_suite.signatures.falcon512_sign(transaction, wallet_key)
    
    def establish_secure_channel(self, peer_public_key):
        # ML-KEM-768 for session key establishment
        ciphertext, session_key = self.pq_suite.key_exchange.mlkem768_encapsulate(
            peer_public_key
        )
        return ciphertext, session_key
    
    def encrypt_backup(self, wallet_data, password):
        # ChaCha20-Poly1305 for backup encryption (unchanged)
        key = self.pq_suite.kdf.blake3_derive(password, b"wallet-backup")
        return self.pq_suite.aead.chacha20_poly1305_encrypt(wallet_data, key)

Migration Strategy

Phase 1: Infrastructure Preparation

  • Key Storage: Upgrade storage systems for larger PQC keys
  • Network Protocols: Modify protocols to handle larger signatures and keys
  • Performance Testing: Benchmark PQC algorithms in target deployment environments

Phase 2: Hybrid Deployment

  • Dual Mode: Run classical and post-quantum algorithms simultaneously
  • Gradual Rollout: Start with non-critical operations, expand gradually
  • Monitoring: Track performance impact and security effectiveness

Phase 3: PQC Migration

  • Algorithm Replacement: Replace classical algorithms with PQC equivalents
  • Legacy Support: Maintain backward compatibility during transition period
  • Full Deployment: Complete migration to post-quantum suite

Use Case Recommendations

Mobile Wallets

Primary Choice: Full post-quantum suite

  • Falcon-512 for transaction signing (optimized for mobile)
  • ML-KEM-768 for wallet-to-wallet key exchange
  • ChaCha20-Poly1305 for message encryption (unchanged)
  • Blake3 for address generation and transaction hashing (unchanged)

Blockchain Infrastructure

Primary Choice: Hybrid mode during transition

  • Classical suite for current performance requirements
  • PQC suite testing in parallel for future readiness
  • Gradual migration as quantum computing threat materializes

High-Security Applications

Primary Choice: Hybrid classical+PQC mode

  • Defense-in-depth through algorithm diversity
  • Protection against both classical and quantum attacks
  • Future-proof security during uncertain transition period

Performance Optimization

Mobile-Specific Optimizations

  • Batch Operations: Cache and batch ML-KEM operations when possible
  • Key Reuse: Optimize key storage and retrieval for frequently used keys
  • Streaming: Use Blake3 streaming for large data processing
  • Memory Management: Efficient allocation/deallocation for large PQC keys

Network Optimizations

  • Compression: Compress Falcon-512 signatures when network bandwidth is limited
  • Caching: Cache ML-KEM public keys to avoid repeated transmissions
  • Protocol Design: Design protocols to minimize PQC algorithm overhead