Managing Larger Key
Sizes in Post-Quantum Cryptography

One of the most significant practical challenges of post-quantum cryptography is increased key and signature sizes. While the security benefits are clear, these larger sizes require careful consideration in system design. This guide covers strategies for managing PQC overhead effectively.

Size Comparison

Let's compare sizes between classical and post-quantum algorithms:

Signature sizes show similar increases:

• ECDSA P-256: 64 bytes
• Ed25519: 64 bytes
• Dilithium3: 3,293 bytes
• FALCON-512: 666 bytes

Bandwidth Optimization

For network-constrained applications:

• Key caching: Cache public keys locally instead of transmitting with each request
• Compression: PQC keys compress moderately well (~10-20% reduction)
• FALCON for signatures: When signature size is critical, FALCON offers 5x smaller signatures than Dilithium
• Batch operations: Amortize key transmission overhead across multiple operations

// Key caching example
const keyCache = new Map();

async function verifyWithCache(userId, signature, data) {
  let publicKey = keyCache.get(userId);
  if (!publicKey) {
    publicKey = await fetchPublicKey(userId);
    keyCache.set(userId, publicKey);
  }
  return h33.quantum.verify({ data, signature, publicKey });
}

Storage Considerations

Database and storage planning for PQC:

• Column sizing: Update VARCHAR/BLOB columns to accommodate larger keys
• Index efficiency: Larger keys may impact index performance—test thoroughly
• Backup size: Expect 10-50x increase in key-related storage
• Key versioning: Store algorithm identifiers to support future migrations

Protocol Design

When designing protocols around PQC:

• Separate key exchange from data: Don't embed large keys in every message
• Session establishment: Use PQC for session keys, then symmetric crypto for data
• Certificate chains: Be mindful of certificate size in TLS (each cert has a signature)

Mobile and IoT Considerations

Resource-constrained devices face particular challenges:

• Memory: PQC operations may require more RAM—profile carefully
• Processing: Generally acceptable, but test on target hardware
• Bandwidth: Mobile networks may see noticeable impact from larger handshakes
• Battery: Slightly increased computation may affect battery life

Real-World Impact

In practice, the overhead is often acceptable:

• A TLS handshake adds ~2KB—negligible for most web requests
• Signed API requests add ~3KB—minimal impact at API-typical frequencies
• Key storage for 1 million users: ~2GB additional for public keys

The security benefits of quantum resistance far outweigh these modest increases for most applications.

H33's Approach

At H33, we handle size optimization internally:

• Keys are cached and reused across operations
• Our Full Stack Auth endpoint handles all cryptographic operations server-side
• Only the final result (proof/signature) needs to be transmitted

This abstracts the complexity of PQC key management from your application.

Larger key sizes are a manageable trade-off for quantum security. With thoughtful design, you can minimize their impact while gaining protection against future quantum threats.