ReliaFHE: Resilient Design for Fully Homomorphic Encryption Accelerators

Fully homomorphic encryption lets a server compute on data it can never see, but it is so slow that people build custom accelerators for it — and those accelerators quietly assume the hardware never makes a mistake, which is dangerous because a single flipped bit in an FHE ciphertext can cascade into wholesale corruption of the decrypted result; this paper (University of Central Florida — Fan Li, Mayank Kumar, Ruizhi Zhu, Mengxin Zheng, Qian Lou, Xin Xin) presents ReliaFHE, which adds lightweight, checksum-based error protection tailored to the three heavy arithmetic kernels of FHE — the number theoretic transform, base conversion, and element-wise operations — covering both stored and in-flight data, improving reliability by more than ten thousand times for about 1.5 percent performance or 1.9 percent area overhead and under 1 percent extra storage.

The argument in one glance

Problem

FHE accelerators assume perfect hardware, but one flipped bit can wreck the answer

Fully homomorphic encryption (FHE) lets a server compute directly on encrypted data without ever decrypting it, which is a profound privacy guarantee. The price is staggering computational cost, so researchers have built many custom hardware accelerators to make FHE practical. But these accelerators share a hidden assumption: that every computation runs perfectly, with no hardware faults. That assumption is dangerous for FHE specifically, because modern FHE schemes are extraordinarily fragile to bit errors — a single flipped bit somewhere in a ciphertext can cascade, through the transforms and mixing that FHE performs, into widespread corruption of the final decrypted plaintext. So a fault that a normal chip would shrug off can silently turn an FHE computation's result into garbage, and the accelerators built to speed FHE up have no defense against it.
What people did

Rely on the accelerator computing everything correctly

Existing FHE accelerator designs implicitly assume reliable execution: they optimize the arithmetic kernels for speed and area and treat the hardware as fault-free, the way most performance-focused accelerator work does. Any protection against faults would come, if at all, from generic memory error-correcting codes rather than from the FHE design itself.
Why it fell short

Generic reliability is a poor fit and FHE amplifies every error

This leaves FHE accelerators exposed. FHE's fragility is not the ordinary kind: because a ciphertext is a large polynomial and the core operations mix all its coefficients together and then the result is decrypted through a structure that amplifies noise, an error that would be a minor glitch elsewhere becomes catastrophic here, corrupting far more of the plaintext than the single bit that was flipped. Meanwhile, blindly bolting on heavy, generic fault-tolerance — full replication, or coarse error-correcting codes over everything — would impose overheads that defeat the whole point of building a fast accelerator. What is missing is protection designed for FHE: something that exploits the specific structure of FHE data and its arithmetic to detect and tolerate faults cheaply, covering both the data sitting in memory and the data being computed on, without erasing the accelerator's performance advantage.
This paper's idea

Add checksum codewords tailored to FHE's three heavy kernels

ReliaFHE is a resilient framework that gives FHE accelerators both storage-oriented and computation-oriented protection at low cost. Its key leverage is that FHE operates on large ciphertext polynomials, which carry enough structure and room to attach lightweight, checksum-based redundancy — efficient codewords — that can catch errors both while the data is stored and while it is being computed. Crucially, ReliaFHE tailors these checksum schemes to the three dominant arithmetic kernels of FHE: the number theoretic transform (the FFT-like transform behind polynomial multiplication), base conversion (switching a ciphertext between residue number bases), and element-wise operations (pointwise adds and multiplies). Because each kernel transforms the data differently, ReliaFHE designs a checksum that each kernel provably preserves or predictably transforms, so an injected error breaks the checksum and is caught. The evaluation reports that this improves reliability by more than ten thousand times, measured in primitive operations, at only about 1.5 percent performance overhead or about 1.9 percent area overhead, with parity storage overhead below 1 percent.

Why this problem is worth solving

FHE is one of the most important privacy technologies in computing, and its whole promise rests on getting the right answer.

Fully homomorphic encryption is a form of encryption with an almost magical property: you can perform computations directly on the encrypted data, and when the owner decrypts the result, it is exactly as if the computation had been performed on the original plaintext. A cloud server can run an analysis, or even a neural network, over a user’s encrypted data while learning nothing about the data or the result. This makes FHE a cornerstone technology for private computation. The catch is cost: FHE represents each encrypted value as a large polynomial with many coefficients, and every operation on the plaintext becomes a heavy sequence of polynomial arithmetic, so a computation that would be trivial in the clear can be many orders of magnitude slower under FHE. This is why so much effort has gone into FHE accelerators — custom hardware that speeds up the polynomial arithmetic to make FHE usable in practice. But an accelerator only delivers value if its results are trustworthy, and here trustworthiness is not just about security; it is about correctness under real hardware conditions, where transistors occasionally glitch. If the accelerated result can be silently wrong, the privacy guarantee is worthless, because the user gets a corrupted answer they cannot detect. That is why reliability is not a nice-to-have for FHE hardware but a precondition for using it at all, and why it deserves first-class design attention.

The reason FHE reliability is a distinct problem, not a solved one, is that FHE amplifies faults in a way ordinary computation does not.

In most computations, a single-bit hardware fault causes a small, localized error — one wrong pixel, one wrong number — and often no harm at all. FHE is different because of how its data and operations are structured. A ciphertext is a large polynomial, and the central FHE operation, the number theoretic transform, is like a Fourier transform: it combines every input coefficient into every output coefficient. So a single corrupted coefficient going into an NTT spreads into all the coefficients coming out, and subsequent operations mix it further. On top of that, decryption in FHE recovers the plaintext by combining the ciphertext with the secret key through arithmetic that is sensitive to the accumulated noise; a corruption that inflates that noise can push the result past the threshold where decryption is correct, so instead of one wrong plaintext slot you get many, or all, of them wrong. The upshot is that FHE takes a fault that would be negligible in ordinary hardware and turns it into catastrophic, silent corruption of the answer. This amplification is exactly why generic, coarse protections are both insufficient and wastefully applied, and why a protection scheme has to understand the FHE kernels themselves to be both effective and cheap, which is the gap ReliaFHE fills.

What people did before, and where it broke

Assume fault-free execution. Design the FHE accelerator purely for speed and area, treating the hardware as reliable. Where it broke. Real hardware suffers transient and permanent faults, and FHE amplifies them, so an undefended accelerator can silently return catastrophically wrong results.
Generic memory error-correcting codes. Protect the memory holding ciphertexts with standard ECC. Where it broke. Memory ECC guards data at rest but not the computation, and it is not tailored to FHE’s kernels, so errors introduced during the arithmetic or amplified by it are not caught.
Full replication or checking. Run the computation twice, or use heavy redundancy, and compare. Where it broke. For an accelerator whose reason to exist is performance, doubling the work or area is a large overhead that undermines the speedup FHE hardware is built to provide.
Coarse codes over all data uniformly. Apply one error-correcting scheme indiscriminately across the whole pipeline. Where it broke. Ignoring how each kernel transforms the data means the code either fails to remain valid through the operation or must be recomputed expensively, so uniform protection is both costly and ill-fitting.
The gap. No design exploited FHE’s large ciphertext polynomials to attach lightweight checksums tailored to each dominant kernel (the number theoretic transform, base conversion, and element-wise operations), protecting both storage and computation at overheads small enough to keep the accelerator fast.

How ReliaFHE works

Protecting an FHE accelerator with kernel-tailored checksum codewords

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Turn FHE’s bulky ciphertexts from a cost into a place to hide cheap redundancy. The organizing insight of ReliaFHE is that the very thing that makes FHE expensive — its large ciphertext polynomials — is also what makes cheap fault protection possible. There is enough structure and room in those polynomials to attach compact, checksum-based codewords that detect errors without duplicating the data, so the protection rides along at a fraction of the cost of the computation it guards. Adding a small amount of computed redundancy so that corruption of a large data object becomes detectable, rather than paying to store or compute the whole thing twice, is the same principle the work on redundant arrays for reliable storage covered elsewhere on this site is built on, spreading lightweight parity across data so failures are caught and tolerated. ReliaFHE applies that principle inside an FHE accelerator, using the ciphertext polynomials as the carrier for the redundancy.

Make the checksum fit the kernel, so it survives the computation. The subtle part is that protecting computation is much harder than protecting storage, because the data is being transformed. A checksum that is valid before a kernel runs is usually invalid after, unless the kernel transforms the checksum in a known way. ReliaFHE’s core move is to design, for each of FHE’s three dominant kernels — the number theoretic transform, base conversion, and element-wise operations — a checksum that the kernel provably preserves or predictably alters, so the expected output checksum can be computed cheaply and compared, catching any error the kernel introduced. Co-designing an error-checking scheme with the specific arithmetic structure of the operation it must survive, rather than layering a generic check on top, is the same tailoring the work on high-arithmetic-efficiency fully homomorphic encryption covered elsewhere on this site relies on, matching the mechanism to the exact structure of FHE’s polynomial kernels. ReliaFHE tailors reliability the way others tailor performance, kernel by kernel.

Buy resilience cheaply enough that the accelerator stays an accelerator. The reason a tailored, checksum-based approach matters is overhead: an accelerator exists to be fast, so any reliability scheme that doubles work or area defeats its purpose. By exploiting the ciphertext structure and matching the check to each kernel, ReliaFHE keeps the cost to roughly 1.5 percent in performance or 1.9 percent in area, with under 1 percent extra storage, while improving reliability by more than four orders of magnitude. Achieving fault tolerance for a demanding compute system at a small fraction of the system’s cost, rather than through expensive full redundancy, is the same efficiency-minded resilience the work on system-efficient fault tolerance for large models covered elsewhere on this site pursues, protecting the computation without paying to run it twice. ReliaFHE delivers that for FHE hardware, so privacy-preserving computation can be both fast and trustworthy.

Following a ciphertext through ReliaFHE

Detecting a hardware fault during an FHE computation

An illustrative trace, based on the paper's abstract, of how ReliaFHE catches an error in an FHE accelerator. Internal details beyond the abstract were not available for this draft.

Step 1 of 5

A ciphertext polynomial is stored with a checksum

An encrypted value lives in the accelerator's memory as a large polynomial, and ReliaFHE stores a compact checksum codeword alongside it. The parity added is tiny, under 1 percent of the storage, but it fixes what the data should look like.

Storage-oriented protection guards the ciphertext while it sits in memory.

Why it works

Big ciphertexts leave room for cheap checks. FHE ciphertexts are large polynomials that are expensive to compute on → but that size lets a compact checksum ride along without duplicating the data → so error detection costs a tiny fraction of the computation it protects.
Kernel-tailored checksums survive the arithmetic. A generic checksum becomes invalid once a kernel transforms the data → but a checksum designed to be predictably transformed by that kernel stays checkable → so errors introduced during computation, not just in storage, are caught.
Covering all three kernels closes the pipeline. Protecting only one operation leaves the others as unguarded gaps → but tailoring checks to the number theoretic transform, base conversion, and element-wise ops covers the dominant work → so faults have nowhere in the pipeline to slip through undetected.
Cheap detection matters because FHE amplifies faults. A single flipped bit in FHE cascades into widespread plaintext corruption → but detecting that bit before it propagates prevents the catastrophe → so a small check averts an enormous, silent error.
Low overhead keeps the accelerator worthwhile. Heavy replication would erase the speedup the accelerator exists to provide → but about 1.5 percent time or 1.9 percent area buys the resilience → so the design stays fast while becoming trustworthy.

What it costs (trade-offs and scope)

This is a draft built from the paper’s abstract. The full paper was behind a publisher access wall for this draft (no arXiv version, no open-access or author copy located, and the ACM Digital Library returned a bot-verification challenge), so this account is assembled from the paper’s complete abstract plus standard background on FHE and error-detecting codes. The exact checksum constructions, how each kernel’s codeword is derived and verified, the fault model, whether errors are corrected or only detected, and the evaluation setup are not reproduced here and should be read from the paper.
The reported figures are the abstract’s own. The more-than-ten-thousand-fold reliability improvement (in primitive operations), the roughly 1.5 percent performance or 1.9 percent area overhead, and the below-1-percent parity storage are the abstract’s results; the workloads, fault injection methodology, and baselines behind them are not detailed in this draft.
Checksums primarily detect; recovery is a further question. Lightweight checksum codewords are naturally suited to detecting corruption; whether and how ReliaFHE recovers from a detected fault (for example by recomputation), and the cost of that recovery, is beyond what the abstract states and should be confirmed in the paper.
Protection is scoped to the dominant kernels. ReliaFHE targets the number theoretic transform, base conversion, and element-wise operations; faults in control logic, in less-common operations, or outside the modeled points may fall outside its coverage, and the abstract does not enumerate the full fault surface.
It is designed for FHE accelerators. The approach leverages FHE-specific structure, so it applies to FHE hardware rather than general accelerators; how the tailored-checksum idea transfers to other domains is not the abstract’s concern.

The evaluation

Protecting an FHE accelerator against hardware faults

Property	Assume fault-free	Generic memory ECC / replication	ReliaFHE
Protects data in storage
Protects the computation
Tailored to FHE kernels
Overhead
Reported reliability gain (per abstract)

A qualitative comparison based on the paper's abstract; the paper's main body, including the checksum constructions, the fault model, and the evaluation setup, was not available for this draft. The more-than-ten-thousand-fold reliability gain and the roughly 1.5-percent performance or 1.9-percent area overheads are the abstract's own reported figures.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

This is an honest draft assembled from the paper’s complete abstract plus standard background on fully homomorphic encryption and error-detecting codes; the full text was not accessible (no arXiv preprint, no open-access or author copy found, and the ACM Digital Library version returned a bot-verification challenge), so the internal design is not reproduced. What is solid and comes directly from the abstract: existing FHE accelerators implicitly assume reliable execution, but modern FHE schemes are highly vulnerable to hardware faults, and even a single-bit error in a ciphertext can cascade into widespread plaintext corruption; ReliaFHE is a resilient framework integrating both storage- and computation-oriented protection for FHE accelerators; it leverages the large ciphertext polynomials inherent in FHE and employs lightweight, checksum-based schemes to construct efficient codewords; it is tailored to the three dominant arithmetic kernels — the number theoretic transform, base conversion, and element-wise operations; and it improves reliability by more than ten thousand times (in terms of primitive operations) with about 1.5 percent performance overhead or about 1.9 percent area overhead, and parity storage overhead below 1 percent. The explanations of why FHE amplifies faults and why kernel-tailored checksums are needed are standard background and the natural reading of the abstract, not claims about ReliaFHE’s specific internals. Read the exact checksum constructions, the fault model, whether faults are corrected or only detected, and the evaluation in the paper itself; treat this page as a faithful account at the level of the abstract, not of the implementation.

Background

Why reliability is catching up to performance in accelerators

It helps to see ReliaFHE as part of a broader reckoning in specialized hardware: for years accelerator design chased performance and efficiency almost exclusively, treating correctness under faults as someone else’s problem, but as accelerators take on more critical and more error-sensitive workloads, silent data corruption has become a first-class concern. Large fleets have found that hardware occasionally computes the wrong answer without any crash or warning, and for workloads where a wrong answer is dangerous — safety-critical control, financial computation, or, as here, privacy-preserving computation whose result the user cannot independently check — that silent wrongness is unacceptable. The response across the field is to fold reliability into the design of the accelerator itself, exploiting the structure of the specific workload to detect and tolerate faults cheaply rather than paying for generic, heavy protection. FHE is an especially acute case because its mathematics amplifies faults so violently, but the pattern is general: understand what the accelerator computes, and use that understanding to protect it efficiently. That same drive to build efficient, workload-aware fault tolerance into demanding computation rather than bolting on costly redundancy is the concern the work on system-efficient fault tolerance for large sparse models covered elsewhere on this site shares, and it is the shift ReliaFHE brings to FHE hardware.

If you remember only three things

1. Fully homomorphic encryption lets a server compute on data it never decrypts, but it is so costly that many hardware accelerators exist for it — and those accelerators implicitly assume the hardware is fault-free. That is dangerous because modern FHE amplifies faults: a single flipped bit in a ciphertext, passing through transforms that mix all coefficients and a decryption sensitive to accumulated noise, can cascade into widespread, silent corruption of the decrypted plaintext.
2. ReliaFHE is a resilient framework that gives FHE accelerators both storage- and computation-oriented protection at low cost. It exploits FHE's large ciphertext polynomials to attach lightweight, checksum-based codewords, and it tailors a checksum to each of the three dominant FHE kernels — the number theoretic transform, base conversion, and element-wise operations — so the check remains valid through each kernel's arithmetic and catches errors during computation, not just in storage.
3. The abstract reports that ReliaFHE improves reliability by more than ten thousand times (in primitive operations) at only about 1.5 percent performance overhead or about 1.9 percent area overhead, with parity storage below 1 percent. This explainer is a draft written from the abstract without the paper body, so the exact checksum constructions, fault model, whether faults are corrected or only detected, and the evaluation should be confirmed against the paper. The approach is scoped to the dominant FHE kernels and to FHE accelerators specifically.

Check yourself

Check your understanding

1. Why are FHE accelerators especially vulnerable to hardware faults?
2. What is ReliaFHE's core approach?
3. Why must ReliaFHE tailor a different checksum to each kernel instead of using one generic check?
4. What should a reader keep in mind about this explainer, and what did the paper report?

Sources

The paper is “ReliaFHE: Resilient Design for Fully Homomorphic Encryption Accelerators” by Fan Li, Mayank Kumar, Ruizhi Zhu, Mengxin Zheng, Qian Lou, and Xin Xin (University of Central Florida), published at ASPLOS 2026 (Volume 2), DOI 10.1145/3779212.3790211. It is licensed CC BY.

This explainer is a draft. The paper’s main text was not accessible at the time of writing (there is no arXiv preprint, no open-access or author copy was located, and the ACM Digital Library PDF returned a bot-verification challenge), so it is written from the paper’s complete abstract together with standard background on fully homomorphic encryption, its arithmetic kernels, and error-detecting codes. The abstract supplies the problem and approach: the significant computational complexity of FHE has prompted numerous accelerator designs, but existing FHE accelerators often implicitly assume that all computations are executed reliably, overlooking that modern FHE schemes can be highly vulnerable to hardware faults, since even a single-bit error in a ciphertext can cascade into widespread plaintext corruption; ReliaFHE is a resilient framework that integrates both storage- and computation-oriented protection for FHE accelerators; it leverages the large ciphertext polynomials inherent in FHE and employs lightweight, checksum-based schemes to construct efficient codewords; it is tailored to the three dominant arithmetic kernels — number theoretic transform, base conversion, and element-wise operations; and its evaluation shows that ReliaFHE improves reliability by more than ten thousand times (in terms of primitive operations) with either about 1.5 percent performance overhead or about 1.9 percent area overhead, and parity storage overhead below 1 percent. The explanations of why FHE amplifies faults and why kernel-tailored checksums are necessary are standard background and the natural reading of the abstract, not claims about ReliaFHE’s specific internal design. The paper’s exact checksum constructions, its fault model, whether faults are corrected or only detected, its hardware configuration, and its evaluation setup are not reproduced here and should be read from the paper. No numbers beyond the abstract’s have been introduced.