The Scheme Families: BGV/BFV Exact Integers versus CKKS Approximate Reals

There is no single fully homomorphic encryption scheme; there is a small set of families that differ most fundamentally in what kind of number they encrypt and whether the arithmetic they perform is exact or approximate. This choice is not a detail — it determines which workloads a scheme suits, how it batches data, how it handles non-linear functions, and ultimately whether a given private computation is practical. This article surveys the two schemes named in the standardization conversation, BGV/BFV for exact integers and CKKS for approximate reals, adds the fast-bootstrapping FHEW/TFHE family, and gives a framework for choosing among them.

BGV and BFV: exact integer arithmetic

The BGV scheme and the closely related BFV scheme encrypt integers and compute exact arithmetic over them, modulo a chosen plaintext modulus. When you add or multiply BGV/BFV ciphertexts and decrypt, you get exactly the integer sum or product you would have computed on the plaintexts — no rounding, no approximation. The message space is the integers modulo a parameter, and the scheme behaves like modular arithmetic performed under encryption.

Exactness is the defining virtue and the defining constraint. It makes these schemes the correct choice whenever the computation must be precise: integer aggregation, exact comparisons and equality tests, database and set operations, and any logic where an approximate answer is wrong rather than merely imprecise. Both schemes also support batching, packing many integers into the independent slots of a single ciphertext so that one homomorphic operation acts on all of them in parallel, which is essential for throughput.

The difference between BGV and BFV is mainly in how they manage noise and encode the message relative to the modulus — BGV tracks a chain of moduli and switches between them, while BFV keeps the message in the high-order part of the ciphertext and scales — but for the purpose of choosing a scheme they occupy the same niche: exact integer arithmetic with batching. The reason not to use them for everything is that many important workloads are not integer computations at all.

CKKS: approximate arithmetic for real numbers

The CKKS scheme takes a different stance: it encrypts vectors of real or complex numbers and computes approximately. Rather than treating the noise inherent in a lattice ciphertext purely as an enemy to be kept below a threshold, CKKS treats a controlled amount of it as ordinary numerical rounding error, embedded in the low-order bits of the result. Decrypting a CKKS ciphertext yields a close approximation of the true value, with an error comparable to the rounding error of fixed- or floating-point arithmetic.

This reframing is exactly right for a large class of real-world computation. Machine learning, statistics, and signal processing operate on real-valued data and are already approximate — model weights are floating-point, activations are rounded, and results are tolerant of tiny numerical error. CKKS lets these computations run under encryption with the same kind of precision they would have in the clear, and its rescaling operation, which trims the low bits after each multiplication, manages both the growth of magnitude and the noise together. Like BGV/BFV it batches, packing many real values into the slots of one ciphertext.

The cost of CKKS's convenience is that it is genuinely approximate: results carry error, precision must be budgeted, and it is the wrong tool where exact answers are required. You would not use CKKS to test integer equality or compute an exact count, because the small error that makes it efficient for real arithmetic makes those exact operations unreliable. The line between the two families is therefore the line between approximate and exact computation, which is the first question to ask of any workload.

The wider family and how to choose

A third major line, the FHEW/TFHE family, occupies a distinct niche defined by very fast bootstrapping. Where BGV/BFV and CKKS bootstrap infrequently and amortize the cost over batched arithmetic, TFHE bootstraps after essentially every gate, but so cheaply that it excels at boolean and small-integer computation and at evaluating arbitrary functions through programmable bootstrapping — using the bootstrapping step to apply a lookup table. This makes TFHE the natural home for the non-linear and comparison-heavy operations that the arithmetic schemes handle awkwardly.

Choosing among the families is therefore driven by the shape of the workload. The first question is exact or approximate: exact integer logic points to BGV/BFV, approximate real arithmetic to CKKS. The second is the mix of operations: heavy batched linear algebra favors the arithmetic schemes, while frequent comparisons, decisions, and arbitrary non-linear functions favor TFHE's programmable bootstrapping. Real systems increasingly combine schemes, using CKKS for the linear layers of a network and switching to a TFHE-style evaluation for the non-linearities.

The table summarizes the mapping. It is deliberately about fit rather than a ranking, because no family dominates the others; each is the best choice for a different class of computation. Getting this first decision right matters more than any parameter tuning, because a workload placed on the wrong family fights the scheme's design — trying to do exact logic in CKKS, or heavy batched arithmetic gate-by-gate in TFHE — and pays for it in both correctness and performance.

Which fits private AI, and why

For private machine-learning inference the dominant choice is CKKS, and the reason follows directly from the framework. Neural networks are real-valued computations — weights, inputs, and activations are real numbers — and they are already approximate and robust to small numerical error, exactly the regime CKKS is built for. Its batching packs the many values of a tensor into one ciphertext so that a homomorphic multiplication computes across a whole layer at once, matching the linear-algebra structure of a network. Encrypting a prompt or feature vector and running the linear layers under CKKS is the backbone of private inference.

The exact schemes still have their place in the AI stack, just not for the arithmetic core of a model. Private set intersection — finding the overlap between two parties' data without revealing the rest — is an exact integer computation that belongs to BGV/BFV, and it underlies privacy-preserving data collaboration and audience matching. Exact private database queries and secure aggregation of integer counts likewise sit naturally with the arithmetic-exact family. The two families are complementary tools in a confidential-computing toolbox, not competitors.

The genuinely hard part of private inference — the non-linear activations like softmax and the comparisons in pooling or attention — is where the families' limits bite and where hybrid designs earn their keep, switching from CKKS's efficient linear arithmetic to a TFHE-style programmable-bootstrapping evaluation for the non-linear step. That interface, and the approximations it forces, is the subject of a later article. The lesson here is foundational to everything that follows: match the scheme family to the data type and error tolerance of the workload first, because that single decision shapes the feasibility of the entire private computation, and for real-valued AI it points squarely at CKKS.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

fhe_scheme_selection:
  decision_order: [exact_or_approximate, data_type, operation_mix]
  mapping:
    exact_integer: bgv_bfv
    approximate_real: ckks
    boolean_or_lut: fhew_tfhe
  ml_inference:
    linear_layers: ckks
    non_linearities: tfhe_programmable_bootstrap

Glossary

BGV / BFV

Homomorphic schemes that encrypt integers and compute exact modular arithmetic, with batching over ciphertext slots.

CKKS

A homomorphic scheme that encrypts real/complex vectors and computes approximately, folding controlled noise into rounding error.

FHEW / TFHE

A homomorphic family with very fast bootstrapping, suited to boolean/small-integer logic and programmable-lookup-table evaluation.

Batching (packing)

Storing many plaintext values in the independent slots of a single ciphertext so one operation acts on all of them in parallel.

Rescaling

A CKKS operation that trims low-order bits after multiplication to manage magnitude and noise growth.

Programmable bootstrapping

Using the bootstrapping step in TFHE to apply an arbitrary lookup table, evaluating non-linear functions.

References

1. Brakerski, Gentry, Vaikuntanathan, (Leveled) FHE without Bootstrapping / BGV (ITCS 2012)
2. Fan, Vercauteren, Somewhat Practical Fully Homomorphic Encryption / BFV (ePrint 2012/144)
3. Cheon, Kim, Kim, Song, Homomorphic Encryption for Arithmetic of Approximate Numbers / CKKS (ASIACRYPT 2017)
4. Chillotti, Gama, Georgieva, Izabachene, TFHE: Fast Fully Homomorphic Encryption over the Torus (J. Cryptology 2020)
5. NIST Privacy-Enhancing Cryptography (PEC) project