How to Encrypt Data Without Decrypting for Processing

Every traditional encryption system shares the same fatal design assumption: to do anything useful with encrypted data, you must first decrypt it. AES, RSA, ChaCha20 -- they all protect data at rest and in transit, but the moment you need to compute on that data, you strip the encryption away and expose the plaintext to whatever machine, process, or administrator happens to be running the computation. This is not a limitation of specific algorithms. It is a limitation of the entire encryption paradigm that has dominated cryptography for decades.

Fully homomorphic encryption breaks this assumption. FHE allows you to perform computations directly on encrypted data. The result, when decrypted, is identical to the result you would have obtained by computing on the plaintext. The data is never exposed at any point during the computation. The machine performing the computation never sees the plaintext. The administrator of that machine never sees the plaintext. No one sees the plaintext except the entity holding the decryption key, and they only see the final result, not the intermediate steps.

This article explains how FHE works at a level that is technically precise without requiring a graduate degree in lattice cryptography. We cover the three major FHE schemes in production use -- BFV, CKKS, and TFHE -- with their respective strengths, limitations, and appropriate use cases. We present real production benchmarks from H33's pipeline, where FHE is not a research prototype but a system processing 2,293,766 authentications per second at 38 microseconds per operation. And we compare FHE honestly against the two other major approaches to private computation: multi-party computation (MPC) and trusted execution environments (TEE).

The Core Idea: Homomorphic Operations

A homomorphic encryption scheme has a special property: operations on ciphertexts correspond to operations on plaintexts. If you encrypt the number 3 and the number 7, then add the two ciphertexts together, you get a ciphertext that decrypts to 10. If you multiply the ciphertexts, you get a ciphertext that decrypts to 21. The encryption is transparent to the arithmetic.

Partially homomorphic encryption has existed for decades. RSA is multiplicatively homomorphic: multiply two RSA ciphertexts and you get the encryption of the product of the plaintexts. Paillier is additively homomorphic: add two Paillier ciphertexts and you get the encryption of the sum. But partial homomorphism is not enough for general computation. You need both addition and multiplication -- and you need to be able to perform them in arbitrary sequence, an arbitrary number of times.

Fully homomorphic encryption supports both addition and multiplication on ciphertexts, with unlimited composition. This was proven theoretically possible by Craig Gentry in 2009 and has been refined through multiple generations of schemes into practical systems. Modern FHE schemes fall into three families, each based on the hardness of lattice problems: BFV for exact integer arithmetic, CKKS for approximate real-number arithmetic, and TFHE for boolean gate-by-gate computation.

BFV: Exact Integer Arithmetic

The Brakerski-Fan-Vercauteren (BFV) scheme operates on polynomial rings and provides exact integer arithmetic over a plaintext modulus. When you encrypt an integer in BFV, you get back exactly that integer when you decrypt -- no approximation, no rounding error, no precision loss. This makes BFV the right choice for any computation where exact results are required: counting, matching, threshold comparisons, database lookups, and classification into discrete categories.

BFV encryption works by encoding a plaintext integer into a polynomial, adding carefully calibrated noise to the polynomial (this noise is what provides security), and performing a series of polynomial operations that embed the noisy encoding into a lattice structure. The security of BFV rests on the Ring Learning With Errors (RLWE) problem: given a polynomial ring element with noise added, it is computationally infeasible to recover the original polynomial without the secret key.

H33's production pipeline uses BFV as its workhorse FHE scheme. The parameters are tuned for the biometric authentication workload: polynomial degree N=4096, a single 56-bit modulus Q, and plaintext modulus t=65537. These parameters provide 128-bit security (H33-128) while keeping ciphertexts compact enough for the high-throughput batched pipeline. Each ciphertext encodes 4,096 plaintext values in SIMD slots, meaning a single encryption-computation-decryption cycle processes 4,096 independent values simultaneously.

Noise Management in BFV

The central challenge in BFV is noise growth. Every homomorphic operation increases the noise in the ciphertext. Additions increase noise linearly. Multiplications increase noise quadratically. After too many operations, the noise overwhelms the plaintext and decryption returns garbage. The noise budget determines how many operations you can perform before the ciphertext becomes unusable.

H33 manages noise through careful parameter selection and circuit design. The authentication pipeline requires a fixed, shallow computation depth: encrypt the biometric template, compute an inner product against the stored reference, and compare the result to a threshold. This circuit is known at compile time, which means the noise budget can be precisely allocated. There is no need for bootstrapping (the expensive operation that resets the noise) because the computation depth never exceeds the noise budget for the chosen parameters.

For deeper computations that exceed the noise budget, modulus switching provides an intermediate option. By switching to a smaller ciphertext modulus after each multiplication, you can trade ciphertext space for noise headroom. H33's BFV implementation supports multi-modulus configurations for workloads that require deeper circuits, though the production authentication pipeline uses a single modulus for maximum throughput.

CKKS: Approximate Real-Number Arithmetic

The Cheon-Kim-Kim-Song (CKKS) scheme takes a fundamentally different approach. Instead of exact integer arithmetic, CKKS provides approximate arithmetic on real (or complex) numbers. When you encrypt 3.14159 in CKKS, you get back something like 3.14159000002 when you decrypt -- close, but not exact. The approximation error is controlled and predictable, similar to floating-point rounding in conventional computing.

This design choice is not a weakness. It is an engineering decision that enables CKKS to handle the most important class of modern computation: machine learning. Neural network weights, activation values, gradient updates, and loss function outputs are all real-valued quantities where small rounding errors are irrelevant. A neural network that produces a classification confidence of 0.9723 versus 0.9723000001 makes the same decision. CKKS exploits this tolerance to achieve dramatically better performance than exact-arithmetic schemes for ML workloads.

CKKS encodes real numbers by scaling them up to integers, adding noise, and performing polynomial arithmetic analogous to BFV. The key insight is that the noise added for security and the rounding error from the real-to-integer encoding can be treated as the same thing. In BFV, noise is an adversary that you must keep below a threshold. In CKKS, noise is an acceptable approximation error that you manage alongside computational precision. This duality is what makes CKKS uniquely suited to floating-point workloads.

CKKS for Machine Learning Inference

The primary use case for CKKS is encrypted machine learning inference. A data owner encrypts their input (an image, a medical record, a financial profile) under their CKKS key. The model operator runs the neural network on the encrypted input, performing matrix multiplications, convolutions, and activation functions entirely on ciphertexts. The encrypted output is returned to the data owner, who decrypts to get the classification result. At no point does the model operator see the input or the output.

H33-CKKS implements the full CKKS lifecycle: key generation, encoding, encryption, homomorphic addition and multiplication, rescaling (the CKKS equivalent of modulus switching), rotation (for shifting values between SIMD slots), and decryption. The rescaling step is critical for CKKS performance because it prevents the scale from growing unboundedly through successive multiplications. Each rescaling consumes one modulus from the chain, and the chain length determines the maximum computation depth -- analogous to the noise budget in BFV.

TFHE: Boolean Gate-by-Gate Computation

Torus Fully Homomorphic Encryption (TFHE) takes yet another approach. Instead of operating on integers or real numbers, TFHE operates on individual bits. Each encrypted bit supports boolean operations: AND, OR, XOR, NOT, NAND, NOR, and XNOR. Any computation that can be expressed as a boolean circuit can be evaluated on encrypted data using TFHE.

The advantage of TFHE is universality. Any computation is expressible as a boolean circuit. Integer arithmetic, floating-point arithmetic, string operations, conditional branching, loops -- everything reduces to boolean gates at the hardware level, and TFHE can evaluate those gates on encrypted bits. This makes TFHE the most flexible FHE scheme. It handles computations that neither BFV nor CKKS can express directly, such as encrypted comparisons with arbitrary precision, encrypted string matching, and encrypted control flow.

The disadvantage is throughput. Each boolean gate on encrypted bits takes significantly longer than the corresponding plaintext operation. H33's TFHE implementation on Graviton4 achieves 768 TPS (operations per second) for 8-bit greater-than comparisons and 372 TPS for 16-bit greater-than comparisons. These numbers are real and measured, and they illustrate both the capability and the cost of gate-by-gate encrypted computation. TFHE is the right tool when you need arbitrary logic on encrypted data and BFV or CKKS cannot express your computation, but it is not the right tool when throughput is the primary constraint.

Programmable Bootstrapping in TFHE

TFHE's key innovation is programmable bootstrapping. In BFV and CKKS, bootstrapping is an expensive operation that resets the noise level. In TFHE, bootstrapping is built into every gate evaluation and can simultaneously apply a lookup table function. This means that after every boolean gate, the noise is automatically reset and an arbitrary function can be applied to the result. The computation depth is unlimited without requiring explicit bootstrapping steps.

This property makes TFHE ideal for deep, sequential computations where BFV and CKKS would exhaust their noise budgets. Hash function evaluation on encrypted data, encrypted sorting algorithms, and encrypted parsing of structured data all benefit from TFHE's unlimited depth. H33's TFHE implementation targets these specific use cases where other FHE schemes cannot operate efficiently.

Comparison: FHE vs MPC vs TEE

Fully homomorphic encryption is not the only approach to computing on private data. Multi-party computation (MPC) and trusted execution environments (TEE) offer different tradeoffs. Understanding these tradeoffs is essential for choosing the right tool.

Multi-Party Computation (MPC)

MPC allows multiple parties to jointly compute a function on their combined inputs without any party learning the other parties' inputs. The computation is distributed across the parties, with each party performing partial computations and exchanging encrypted messages. Security holds as long as a threshold number of parties do not collude (typically, as long as a majority are honest).

MPC's advantage is mature tooling and well-understood security guarantees. Protocols like SPDZ and ABY have been implemented, optimized, and deployed in production for specific use cases like private set intersection and secure auctions. MPC's disadvantage is that it requires network communication between the parties during computation. Every multiplication requires a round of communication, and network latency dominates the total computation time. For computations with many sequential multiplications, MPC is orders of magnitude slower than local computation.

MPC also requires the existence of multiple non-colluding parties. If you are computing on data from a single source (encrypting your own data for processing on an untrusted server), MPC does not apply. FHE is the only approach that allows a single untrusted party to compute on encrypted data.

Trusted Execution Environments (TEE)

TEEs like Intel SGX, AMD SEV, and ARM TrustZone provide hardware-isolated execution environments. Code and data inside the enclave are protected from the host operating system, hypervisor, and even the physical machine owner. The hardware guarantees (via attestation) that the code running inside the enclave is the expected code, and the data inside the enclave cannot be read from outside.

TEEs are fast -- the computation runs at near-native speed because the data is plaintext inside the enclave. But TEEs require trusting the hardware manufacturer. Intel SGX has suffered multiple side-channel attacks (Foreshadow, SGAxe, Plundervolt) that allowed extraction of enclave secrets. AMD SEV has similar documented vulnerabilities. The security model is fundamentally different from FHE: TEE security is hardware trust, FHE security is mathematical proof. If the hardware is compromised, TEE security evaporates completely. If the hardware is compromised, FHE security is unaffected.

For organizations in high-assurance environments -- government, military, healthcare, financial infrastructure -- the difference between hardware trust and mathematical proof is the difference between a compliance checkbox and actual security. FHE's security does not depend on the integrity of any hardware vendor's manufacturing process or firmware update pipeline.

H33's Production Pipeline: Real Numbers

H33 combines all three FHE schemes with STARK zero-knowledge proofs and three-family post-quantum signatures in a single pipeline. The production numbers on AWS Graviton4 (c8g.metal-48xl, 192 vCPUs):

Sustained throughput: 2,293,766 authentications per second. Per-authentication latency: 38 microseconds. Batch size: 32 users per ciphertext. SIMD slots: 4,096 per ciphertext. FHE batch computation: 943 microseconds. Batch attestation (SHA3 + Dilithium sign + verify): 391 microseconds. ZKP cached verification: sub-microsecond. Total batch pipeline: under 1,400 microseconds for 32 authentications.

These numbers include the complete pipeline: BFV encryption, homomorphic inner product, STARK proof verification, ML-DSA-65 signature generation and verification, and H33-74 attestation distillation. They are not isolated FHE benchmarks stripped of everything else that a production system needs. The FHE stage accounts for approximately 70% of total pipeline time, with signing at 29% and ZKP at less than 1%.

Choosing the Right Scheme

The decision tree for FHE scheme selection is straightforward. If your computation requires exact integer results (counting, matching, thresholds, database operations), use BFV. If your computation involves real-valued quantities where small approximation errors are acceptable (ML inference, statistical analysis, signal processing), use CKKS. If your computation requires arbitrary boolean logic, encrypted comparisons, or unlimited computation depth, use TFHE.

Many real-world applications combine schemes. H33's AI compliance pipeline uses CKKS for encrypted neural network inference and BFV for the downstream threshold comparison that determines the compliance verdict. The CKKS output (an approximate real number) is converted to a BFV input (an integer rounded to the required precision) at the scheme boundary. This multi-scheme approach uses each scheme in its optimal regime rather than forcing a single scheme to handle all computation types.

FHE is not a silver bullet. It adds substantial computational overhead compared to plaintext computation. But it eliminates an entire category of security risk: the risk of data exposure during processing. For workloads where that risk is unacceptable -- healthcare, finance, government, AI training on sensitive data -- FHE transforms the security model from "trust the compute provider" to "trust the mathematics." That is a fundamentally different and fundamentally stronger guarantee.

For technical documentation on H33's FHE implementations, visit the documentation portal or contact support@h33.ai.