FHE Key Management:
Best Practices for Production Systems

FHE key management is critical for security. The encryption is only as strong as the protection of your keys. In a system processing 1.595 million authentications per second with BFV fully homomorphic encryption, a single leaked secret key compromises every ciphertext ever encrypted under it. This guide covers best practices for managing FHE keys in production — essential for any organization looking to compute on encrypted data at scale.

FHE Key Types

FHE systems use several key types:

• Secret key: Used for encryption and decryption -- must be kept private
• Public key: Used for encryption only -- can be shared
• Evaluation keys: Enable specific operations on ciphertexts
• Rotation keys: Enable SIMD slot rotations
• Relinearization keys: Reduce ciphertext size after multiplication

Secret Key Protection

The secret key is the crown jewel. Unlike symmetric encryption, where a leaked key exposes past messages, a leaked FHE secret key also lets an attacker evaluate arbitrary computations on existing ciphertexts and read the results. Protect it with:

• Hardware Security Modules (HSMs): Store keys in tamper-resistant hardware
• Key encryption: Encrypt keys at rest with separate master keys
• Access controls: Strict permissions on key access
• Audit logging: Track all key usage

// Never do this
const secretKey = "abc123...";  // Hardcoded key

// Better: Load from secure storage
const secretKey = await hsm.getKey('fhe-secret-key');
// Or from a cloud vault with IAM-scoped access
const secretKey = await keyVault.getSecret('fhe-secret-key');

In H33's production stack, the BFV secret key is stored in NTT form (forward NTT applied at keygen). This means even internal memory dumps would expose a transformed representation, not the raw polynomial coefficients. Defense in depth starts at the representation level.

Key Generation

Proper key generation is essential:

• Use cryptographically secure random number generators
• Generate keys in a secure environment (air-gapped if possible)
• Verify key integrity before use
• Consider key ceremonies for high-value applications

Parameter Selection Matters

Key generation is inseparable from parameter selection. In BFV, the polynomial degree N, ciphertext modulus Q, and plaintext modulus t jointly determine security level, noise budget, and performance. H33 uses N=4096 with a single 56-bit modulus and t=65537, tuned for the biometric_fast() tier. This configuration delivers 128-bit security while keeping the per-authentication latency at ~42 microseconds -- fast enough to sustain 1.595 million auths per second across 96 Graviton4 workers.

Choosing parameters that are too aggressive shrinks the noise budget and causes decryption failures. Choosing parameters that are too conservative wastes compute. There is no substitute for benchmarking your specific workload with your specific hardware.

Key Rotation

Regular key rotation limits exposure from potential compromise:

• Define rotation schedule based on risk assessment
• Re-encrypt data with new keys (can be done homomorphically)
• Maintain old keys for decryption until all data is rotated
• Securely destroy old keys after rotation complete

Evaluation Key Distribution

Evaluation keys must reach the computing party:

• Transmit over encrypted channels (TLS)
• Consider key caching to avoid repeated transmission
• Validate key integrity on receipt
• Evaluation keys don't need the same protection as secret keys

In high-throughput systems, evaluation key transmission is a real bottleneck. A full set of Galois keys for BFV at N=4096 can exceed 10 MB. H33 addresses this by pre-computing and caching public-key material in NTT form at enrollment time -- the pk0 component is stored in NTT form, eliminating a clone and forward NTT on every encrypt call. For ZKP proof caching, an in-process DashMap achieves 0.085-microsecond lookups, removing any network overhead entirely.

Multi-Party Scenarios

When multiple parties are involved:

• Each party may hold their own secret key
• Threshold schemes split keys across parties
• Multi-key FHE allows computation on data encrypted under different keys
• Define clear key ownership and responsibilities

Threshold Decryption

In threshold FHE, the secret key is split into n shares using a technique like Shamir's Secret Sharing. Decryption requires at least k of n shares, so no single party ever holds the complete key. H33's CollectiveAuthority uses this model for biometric batch verification: 32 users are packed into a single BFV ciphertext via SIMD batching, and partial decryption shares from multiple authorities are combined with combine_crt. This approach ensures that even the authentication infrastructure itself cannot unilaterally decrypt user biometric templates.

Backup and Recovery

Key loss means data loss. Plan for recovery:

• Secure backups with geographic distribution
• Key escrow for critical applications
• Recovery procedures tested regularly
• Consider Shamir's Secret Sharing for key backup

Post-Quantum Key Protection

BFV's lattice-based hardness assumptions already provide post-quantum security for the FHE layer, but key management infrastructure must match. Wrapping FHE secret keys with RSA or ECDH for transport defeats the purpose -- a quantum adversary breaks the wrapper and extracts the key. H33 uses Dilithium signatures for key attestation and Kyber (ML-KEM) for key encapsulation during distribution. Every key artifact in the pipeline -- generation, distribution, rotation, and destruction -- is protected by post-quantum primitives end to end.

Proper FHE key management ensures your encrypted data remains both secure and accessible. The gap between a theoretically sound FHE deployment and a production-grade one is almost entirely in key lifecycle management -- generation, storage, rotation, distribution, and destruction. Invest in robust key infrastructure from the start, benchmark your parameters against real hardware, and never assume that the cryptographic hardness of the scheme compensates for weak operational practices around the keys themselves.