How to Process Encrypted Data
Without Decrypting It

The Fundamental Problem with Traditional Encryption

AES-256-GCM is excellent at protecting data in transit and at rest. But the moment you need to do something with that data, whether it is running a database query, computing a match score, or feeding it into a machine learning model, you must decrypt it first. Decryption exposes plaintext in memory on the server performing the computation. That server becomes the attack surface. If it is compromised through a software vulnerability, a misconfigured access control, a malicious insider, or a supply chain attack, the plaintext is exposed.

This is not a theoretical concern. The overwhelming majority of data breaches occur at the point of processing, not the point of storage. Data is encrypted at rest in a database, decrypted for a query, and exposed in the process. The encryption did its job perfectly; it just was not present during the phase where the attack happened.

Fully Homomorphic Encryption solves this by making computation on encrypted data mathematically possible. The server performs arithmetic operations on ciphertexts, and the result, when decrypted by the key holder, is identical to what would have been obtained by performing the same operations on the plaintexts. The server learns nothing about the data, the query, or the result. Zero exposure. Zero trust required.

How BFV FHE Works (Without the Math PhD)

H33 uses the BFV (Brakervassi-Fan-Vercauteren) scheme for integer arithmetic on encrypted data. Here is how it works at a conceptual level, without the polynomial ring theory:

• Encrypt: Take an integer (or a vector of integers). Add carefully calibrated noise to it. Embed it in a polynomial structure. The noise is mathematically entangled with the secret key such that only the key holder can separate signal from noise.
• Add: Add two ciphertexts together, element by element. The noise grows slightly. The underlying plaintexts add correctly.
• Multiply: Multiply two ciphertexts. The noise grows more significantly. The underlying plaintexts multiply correctly. A "relinearization" step keeps the ciphertext size from exploding.
• Decrypt: Use the secret key to strip away the noise. Recover the exact integer result. If the noise has grown too large (too many operations), decryption fails. Careful parameter selection ensures this does not happen for the target computation depth.

The critical insight: the server performing the addition and multiplication never has the secret key. It operates on ciphertexts that look like random polynomials. It cannot distinguish a ciphertext encrypting "1" from a ciphertext encrypting "1,000,000." It performs the requested operations blindly and returns the encrypted result.

SIMD Batching: 32 Users in One Ciphertext

One of the most powerful properties of BFV is SIMD (Single Instruction, Multiple Data) batching. The polynomial ring used by BFV has 4,096 "slots" (for H33's N=4096 parameter set). Each slot can hold an independent integer. Operations on the ciphertext apply to all 4,096 slots simultaneously.

H33 uses 128 of these slots for each user's biometric feature vector (128 dimensions). That means one ciphertext holds 4,096 divided by 128 equals 32 users simultaneously. A single encrypted multiplication processes all 32 users' biometric matches in parallel. The computational cost is identical whether you are matching 1 user or 32.

This is why H33's batch FHE operation takes 939 microseconds for 32 users, which is 29.3 microseconds per user. Without SIMD batching, the same operation would take 939 microseconds per user, a 32x throughput reduction. Batching is not an optimization; it is the architectural decision that makes FHE viable at production scale.

Real-World Use Cases

Biometric Matching on Encrypted Templates

This is H33's primary production use case. A user enrolls by encrypting their biometric template (face embedding, fingerprint minutiae, voice features) with their key and uploading the ciphertext. During authentication, a fresh biometric capture is encrypted and sent to the server. The server computes the inner product (similarity score) between the enrolled template and the fresh capture, entirely on encrypted data. The result is an encrypted match score. The server never sees the biometric template, the fresh capture, or the match score.

This solves the fundamental problem with biometric authentication: if biometric templates are stored in plaintext (as they are in virtually every system today), a breach exposes irrevocable credentials. You cannot change your fingerprint. With FHE, even a complete server compromise exposes nothing but random-looking ciphertexts. See the H33 Biometrics product page for the full architecture.

Encrypted Database Queries

A client encrypts a query predicate (e.g., "age > 21") and sends it to a database server. The server evaluates the predicate against encrypted records and returns encrypted results. The server learns neither the query nor the matching records. H33's Encrypted Search product implements this pattern for equality, range, and keyword queries on encrypted data.

ML Inference on Encrypted Inputs

A healthcare provider encrypts a patient's lab results and sends them to a diagnostic AI service. The AI runs its model (linear layers, polynomial activations) on the encrypted data and returns an encrypted diagnosis. The AI provider never sees the patient's data; the healthcare provider never exposes its model. Privacy-preserving ML is one of the fastest-growing applications of FHE, and H33's CKKS engine is purpose-built for floating-point neural network operations.

Cross-Institution Analytics Without Data Sharing

Two banks want to detect fraud patterns that span both institutions without sharing customer records. Each bank encrypts their transaction data with their own key. A shared analytics service computes aggregate statistics (counts, sums, correlations) on the combined encrypted datasets. The results are decrypted collaboratively using a threshold scheme. Neither bank sees the other's raw data. The analytics service sees nothing. H33's MPC product combines FHE with secure multi-party computation for exactly this scenario.

Performance Reality: 2.17 Million Ops/Sec

The historical criticism of FHE is that it is "too slow for production." This was true in 2012 when the first practical FHE implementations required minutes per operation. It is not true in 2026. H33's production pipeline on a single Graviton4 node delivers:

Sustained throughput over 120 seconds of continuous load: 2,172,518 authentications per second with only 0.71% variance across the run. This is not a burst benchmark; it is steady-state production throughput. See live benchmarks for the full methodology.

The 5 FHE Engines

Different workloads require different FHE configurations. H33 offers five engines optimized for different use cases:

• H33-128 (BFV): The production workhorse. N=4096, 56-bit modulus, t=65537. Optimized for biometric matching and integer operations. 939 microseconds per 32-user batch.
• H33-256 (BFV L5): NIST Level 5 security. Larger parameters for higher security requirements. Suitable for government and defense applications.
• H33-CKKS: Approximate arithmetic for floating-point operations. Ideal for ML inference, statistical analysis, and any workload that tolerates bounded approximation error.
• H33-BFV32 (ARM): ARM-optimized BFV using 32-bit moduli for maximum NEON SIMD throughput on mobile and edge devices.
• H33-FHE-IQ (Auto-Select): Intelligent engine selection based on your workload characteristics. Send your data; FHE-IQ analyzes the required computation depth, precision requirements, and security level, then routes to the optimal engine automatically.

Compliance: The Strongest Possible Posture

If data is never decrypted on the server, most breach scenarios become definitionally impossible. This has profound implications for compliance frameworks:

• HIPAA: Protected Health Information (PHI) processed under FHE is never exposed to the processing environment. Even if the server is fully compromised, the adversary obtains only ciphertexts. This exceeds HIPAA's encryption requirements by eliminating the decryption phase entirely.
• GDPR: Processing personal data without accessing it satisfies data minimization by construction. The processor never has access to the personal data. Consent requirements may be simplified because the risk profile is fundamentally different.
• PCI DSS: Cardholder data processed under FHE never exists in plaintext in the processing environment. The scope of PCI compliance for the processing service can be dramatically reduced.

H33 maintains SOC 2 Type II, HIPAA, and ISO 27001 certifications at 100% in Drata. FHE does not replace compliance; it makes compliance structurally easier by removing the attack surface that most controls exist to protect. Read more about our compliance posture on the AI Compliance page.

Conclusion

Fully Homomorphic Encryption is no longer a theoretical curiosity. It is a production technology processing millions of operations per second on commodity hardware. The trade-off between data protection and data utility no longer exists. You can encrypt your data, compute on it, and get exact results, all without any server ever seeing a single plaintext value.

The question is not whether FHE is ready for production. H33 has been running it at scale since 2025. The question is how much longer your organization will continue decrypting data for processing when a proven alternative exists.