FHE vs Post-Quantum: When You Need Both

The cybersecurity industry has a vocabulary problem. Two of the most important technologies for the next decade of data protection -- fully homomorphic encryption (FHE) and post-quantum cryptography (PQC) -- are frequently confused, conflated, or treated as alternatives. They are not alternatives. They solve fundamentally different problems. And for any organization that processes sensitive data with long-term value, the correct answer is almost always both.

Understanding when you need FHE, when you need PQC, and when you need both requires understanding exactly what each technology protects and where the protection gaps are when you have only one.

The Three States of Data

Every piece of data exists in one of three states: at rest, in transit, or in use. Traditional encryption addresses the first two states effectively. AES-256 encrypts data at rest in databases and file systems. TLS encrypts data in transit between systems. These are mature, well-understood technologies that form the baseline of modern data security.

The third state -- data in use -- has historically been the gap. When data is being processed, it must be decrypted. A database query requires the database engine to read the plaintext data. A machine learning model requires the training data in the clear. An analytics pipeline requires unencrypted inputs to produce its outputs. This decryption creates a window of exposure where the data is vulnerable to compromise, whether through a malicious insider, a compromised system, or a software vulnerability.

Fully homomorphic encryption closes this gap. FHE allows computations to be performed directly on encrypted data without ever decrypting it. The data remains encrypted throughout the entire computation. The result of the computation is also encrypted. Only the holder of the private key can decrypt the result. The system that performs the computation never sees the plaintext data, never has access to the private key, and cannot extract any information about the data from the encrypted computation.

What FHE Protects

FHE protects the confidentiality of data during processing. Consider a healthcare analytics platform that processes patient records to identify treatment patterns. Without FHE, the platform must decrypt the records to analyze them, creating exposure. With FHE, the records remain encrypted. The platform computes on ciphertexts. The treatment patterns emerge from the encrypted computation, and only the authorized party can decrypt the results.

H33 implements multiple FHE schemes optimized for different workloads. H33-128 (BFV) provides integer arithmetic on encrypted data, suitable for biometric matching, authentication scoring, and exact computations. H33-CKKS provides approximate arithmetic on encrypted floating-point data, suitable for machine learning inference and statistical analysis. H33-TFHE provides gate-level Boolean operations on encrypted bits, suitable for arbitrary computations including comparison operators and conditional logic.

The protection FHE provides is against access to the plaintext during computation. A compromised server, a rogue administrator, a court-ordered disclosure of processed data -- none of these reveal the underlying data when FHE is used. The computation proceeds correctly, the results are accurate, but the data is never exposed.

What FHE Does Not Protect

FHE does not protect against a quantum adversary that can break the key exchange used to establish the encryption keys. FHE schemes are built on lattice problems -- specifically, the Ring Learning With Errors (RLWE) or Module Learning With Errors (MLWE) problems. These problems are believed to be hard for both classical and quantum computers, which means FHE ciphertexts are likely quantum-safe. However, the key distribution mechanism, the protocol used to securely share the FHE public key and retrieve the encrypted results, typically relies on classical key exchange mechanisms like RSA or ECDH in TLS.

If an adversary intercepts the TLS session that carries the FHE public key, and later breaks that TLS session with a quantum computer, they recover the FHE public key and potentially the session keys used to encrypt the communication channel. The FHE ciphertexts themselves remain secure (they are based on lattice problems), but the communication metadata, the key exchange parameters, and any non-FHE data in the same session are exposed.

More fundamentally, FHE does not provide attestation. FHE proves nothing about when a computation was performed, by whom, or under what conditions. It protects data confidentiality during computation, but it does not create a verifiable record that the computation happened, that the results are authentic, or that the computational integrity was maintained. For compliance and audit purposes, you need more than encryption. You need attestation.

What Post-Quantum Cryptography Protects

Post-quantum cryptography protects data against attackers who have access to quantum computers. The specific threat is Shor's algorithm, which can efficiently factor large integers (breaking RSA) and compute discrete logarithms (breaking ECDH and ECDSA). Any data protected by these algorithms today is vulnerable to future decryption once a sufficiently powerful quantum computer is built.

PQC replaces the vulnerable classical algorithms with alternatives based on mathematical problems that quantum computers cannot efficiently solve. ML-KEM (FIPS 203) replaces RSA and ECDH for key encapsulation. ML-DSA (FIPS 204) replaces RSA and ECDSA for digital signatures. SLH-DSA (FIPS 205) provides hash-based signatures as an alternative to lattice-based schemes.

PQC protects three things. First, it protects key exchange: ML-KEM ensures that session keys established between two parties cannot be recovered by a quantum adversary. Second, it protects digital signatures: ML-DSA ensures that signed documents, software updates, and authentication tokens cannot be forged by a quantum adversary. Third, it protects against harvest-now-decrypt-later: data encrypted with PQ key exchange cannot be decrypted later, even if the ciphertext was intercepted and stored.

What Post-Quantum Cryptography Does Not Protect

PQC does not protect data during computation. If a server receives data encrypted with ML-KEM and decrypts it for processing, the data is in the clear during processing. A compromised server still sees the plaintext. A malicious administrator still has access. A court order compelling disclosure of processed data still applies. PQC protects the communication channel, not the computation.

This is the fundamental distinction. FHE protects the computation. PQC protects the channel. For comprehensive data protection, you need both.

The Combined Architecture

When FHE and PQC are combined, the protection is comprehensive. PQC protects the key exchange and communication channel against quantum adversaries. FHE protects the data during computation against any adversary, including quantum ones. The H33-74 attestation layer provides post-quantum proof that the computation occurred, linking the encrypted computation to a verifiable, tamper-evident record.

The architecture works as follows. The client establishes a session using ML-KEM key exchange, protecting the channel against quantum adversaries. The client sends data encrypted under the FHE scheme (BFV, CKKS, or TFHE, depending on the computation type). The server performs the computation on the encrypted data without decryption. The server returns the encrypted result over the PQ-protected channel. The H33-74 attestation layer attests the computation, creating a 74-byte proof signed with three independent PQ signature families (ML-DSA, FALCON, SLH-DSA).

At no point in this pipeline is the data exposed in plaintext on the server. At no point is the communication channel vulnerable to quantum attack. And the attestation provides a permanent, quantum-resistant record that the computation was performed correctly.

When You Need Only FHE

There are use cases where FHE alone is sufficient, at least in the near term. If your threat model is primarily concerned with insider threats, cloud provider access, or multi-party computation where no single party should see all the data, and if the data does not need to remain confidential for more than five to seven years, then FHE provides the protection you need.

Examples include real-time analytics on encrypted data where the results are ephemeral, encrypted database queries where the query results are consumed immediately, and multi-party machine learning where the training data must remain private to each contributor. In these cases, the data's confidentiality requirement does not extend far enough into the future for the quantum threat to be relevant.

When You Need Only PQC

There are use cases where PQC alone is sufficient. If your data is processed in trusted environments where insider threat is managed through other controls (physical security, background checks, access logging), and if your primary concern is the long-term confidentiality of data in transit and at rest, then PQC addresses the quantum threat without the computational overhead of FHE.

Examples include document signing with long-term verifiability requirements, TLS connections protecting data with multi-decade sensitivity horizons, and authentication systems where the credential validity must survive the quantum era. In these cases, the computation happens in a trusted boundary, but the artifacts must remain secure for decades.

When You Need Both

You need both FHE and PQC when your data meets two conditions: it must remain confidential during processing (the server should not see the plaintext), and it must remain confidential for long enough that quantum computers become a credible threat.

Healthcare data processed in cloud environments is the canonical example. Patient records must remain confidential during analytics (FHE requirement), and they must remain confidential for the patient's entire lifetime, which extends well past the expected arrival of quantum computers (PQC requirement). Processing healthcare data with FHE on a classical TLS channel protects the computation but leaves the channel vulnerable to harvest-now-decrypt-later. Processing healthcare data with PQC on a traditional server protects the channel but exposes the data during processing.

Financial data with long-term sensitivity has the same dual requirement. Trading strategies processed in cloud analytics platforms must be protected during computation and protected against future quantum decryption of intercepted traffic. Biometric data has an even stronger case: biometric templates are sensitive for the individual's entire lifetime, cannot be changed if compromised, and must be matched without exposing the raw template.

H33's platform is built specifically for these dual-requirement use cases. The FHE engines (BFV, CKKS, TFHE) handle the encrypted computation. The PQ infrastructure (ML-KEM, ML-DSA, FALCON, SLH-DSA) handles the quantum-resistant channel and attestation. The H33-74 attestation layer ties everything together with a 74-byte proof that spans both protection domains.

Performance Considerations

A common objection to combining FHE and PQC is performance. FHE is computationally expensive. PQC signatures and key exchange are larger and sometimes slower than their classical counterparts. Combining them must be prohibitively slow.

This objection was valid five years ago. It is not valid today. H33's BFV implementation on Graviton4 hardware processes 32-user authentication batches in 943 microseconds. The PQ attestation (SHA3 plus ML-DSA sign and verify) adds 391 microseconds per batch. The total per-authentication latency is 42 microseconds. This is faster than a DNS lookup.

The performance gains come from three sources. First, purpose-built FHE implementations with hardware-aware optimizations (NEON SIMD on ARM, Montgomery multiplication with Harvey lazy reduction) reduce FHE overhead by orders of magnitude compared to general-purpose libraries. Second, batching amortizes PQ signature costs across multiple operations. Third, the Cachee infrastructure layer provides sub-microsecond cached lookups for previously verified attestations, reducing repeat verification to effectively zero cost.

The practical result is that combined FHE and PQC is deployable in production systems with latency budgets measured in milliseconds. The technology is not a research project. It is running in production on Graviton4 metal at over 1.6 million authentications per second.

The Decision Framework

For organizations evaluating their cryptographic strategy, the decision framework is straightforward.

Does your data need to remain confidential during processing? If yes, you need FHE. No other technology provides data-in-use protection without trusted execution environments, which have their own vulnerability surface.

Does your data need to remain confidential for more than 7-10 years? If yes, you need PQC. The harvest-now-decrypt-later threat means this data is already at risk.

Do you need to prove that computations happened correctly and create tamper-evident records? If yes, you need PQ attestation. Classical digital signatures will be forgeable by quantum computers, making today's audit trails unreliable in the quantum era.

If you answered yes to more than one of these questions, you need a platform that provides both FHE and PQC. Not as separate products bolted together, but as an integrated architecture where the FHE computation flows naturally into PQ attestation, and the entire pipeline is protected by PQ key exchange.

This is what H33 builds. Not FHE or PQC. Both. In one API. At production performance. Because the question is not which technology you need. The question is when you will deploy both.