Homomorphic encryption changes who needs to see a computation's inputs. The practical challenge is designing a useful calculation, a credible performance test and a safe path for the answer.
A company has a calculation it would like to outsource and a collection of measurements it does not want to disclose. The ordinary arrangement offers an uncomfortable bargain: send the data to a powerful computer, then trust the operator and its software to handle it properly. Homomorphic encryption changes that bargain. Under an appropriate cryptographic scheme, the remote computer can transform encrypted inputs into an encrypted answer without receiving the key that reveals those inputs.
The current research story is about making that unusual division of labor useful. NIST's fully homomorphic encryption program page, updated October 26, 2026, lists recent workshop activity and preview talks on September 30 and October 13. It describes work toward future recommendations and standards, not certification of a finished universal service. An active standards discussion is evidence of organized scrutiny, not proof that every advertised encrypted application is ready. NIST's FHE program.
The promise is easiest to misunderstand when expressed as an absolute. Computing on ciphertext does not mean every aspect of an application becomes invisible, every result becomes trustworthy, or every existing program runs efficiently without modification. The more productive question is concrete: which information can remain hidden from which participant while a particular job is completed?
Imagine, throughout this article, a fictional equipment maker called North Workshop. It wants a remote service to evaluate measurements from industrial test rigs. The scenario is invented to make the design choices tangible. No company, deployment, performance result or security certification is being reported. North Workshop will encounter the same categories of questions that a serious evaluation must settle: what is the function, who receives the result, how accurate must it be, and how much time and complexity are acceptable?
First decide what the remote worker is being asked to do
North Workshop initially asks for a service that will analyze its measurements. That phrase is too loose to specify an encrypted computation. Does the service calculate an average, evaluate a fixed prediction model, search for a matching record, or train a new model? Does it return one score, a list of records, or a revised model? Each choice creates a different amount of work and a different disclosure at the end.
The team narrows the first experiment to a fixed scoring function over a short vector of measurements. The client will prepare the input, send an encrypted representation, receive an encrypted result and decrypt locally. The server is not supposed to learn the measurements. This simple assignment lets the team write a testable requirement instead of promising private analysis in the abstract.
The final answer still has a recipient. If the client decrypts a score and posts it publicly, the score is public. If it sends the score back to the service provider, that provider learns the score. Encrypting the intermediate calculation does not erase the information deliberately released at the end. A design meeting should therefore draw the return path as carefully as the upload path.
There is also a difference between hiding data from a service and hiding it from everyone. Someone collected the original measurements. Someone controls the client application before encryption. Someone may see the decrypted answer. The proposed benefit is a reduction in the parties that need access, not the disappearance of all trusted components. That narrower description is both more accurate and more useful when deciding whether the additional machinery is worthwhile.
North Workshop's first acceptance statement might read: the service receives encrypted test vectors and returns encrypted scores; only an authorized client decrypts; the result agrees with a specified reference within a stated tolerance; a complete job finishes within a stated deadline. Security specialists would need to turn the confidentiality language into a precise threat model. The business team can already see what must be measured.
The idea that made the calculation possible
Craig Gentry's September 2009 Stanford dissertation presented a construction for fully homomorphic encryption. Its bootstrapping idea allows a ciphertext to be refreshed by evaluating decryption homomorphically, rather than revealing the underlying message to the evaluator. The introduction explains how this addresses the growth of error during continued computation. The construction is a foundational result with particular mathematical assumptions, not a claim that its original implementation could efficiently run every commercial workload. Gentry's dissertation, abstract and introductory bootstrapping discussion.
A useful way to think about the engineering task is to separate permission from price. A cryptographic construction can establish that an operation is possible under specified assumptions. A practical system must still pay for representing the data, carrying out the operations, moving intermediate objects and returning the result. Those expenses do not undermine the mathematical achievement. They define the next layer of work.
The envelope in this article's title is therefore only a metaphor. An ordinary sealed envelope cannot be manipulated to calculate an answer from its hidden contents. Ciphertexts are mathematical objects with carefully designed relationships. The evaluator performs permitted operations on those objects, and the key holder later interprets the result. The evaluator is doing real computation, not asking a hidden human to open a document.
For North Workshop, this distinction prevents a distracting question: can the server somehow read the numbers while calculating? The actual evaluation should examine the chosen scheme, assumptions, implementation and protocol. It should also check what the application reveals outside the encrypted values. A comforting physical analogy cannot substitute for that analysis, just as an intimidating mathematical vocabulary cannot substitute for a working application test.
The team also needs to distinguish a finite planned computation from an open-ended promise. Its initial scoring function has a known structure. That is a much more manageable target than an instruction to support any future analysis instantly. Starting with a bounded job allows engineers to identify the cost of the actual requirement, rather than designing around an undefined ambition.
Exact answers and approximate answers belong to different contracts
Some tasks demand an exact discrete result. Others are numerical calculations that already tolerate approximation. Mixing those expectations can produce a system that is cryptographically successful yet operationally wrong. North Workshop must decide whether a tiny difference in a score is acceptable and what happens when a result lies close to a decision threshold.
The original TFHE project's documentation describes gate-by-gate homomorphic evaluation of Boolean circuits and separates the secret key material used for encryption and decryption from cloud key material used for evaluation. Its page identifies an updated-parameter version released in February 2020 and points readers to a newer, separate TFHE-rs project. Historical timing figures on that original page are not current universal performance claims. Original TFHE project documentation.
Cheon, Kim, Kim and Song's December 4, 2017 ASIACRYPT presentation describes homomorphic arithmetic for approximate numbers, including addition, multiplication, rescaling and packing multiple values. Approximation is part of the numerical design, rather than an accidental defect to hide. The author-hosted slides were accessible for this article; the original ePrint paper endpoint returned an access error, so this account does not claim a full reading of that paper. Primary conference presentation.
Consider an invented scoring rule with an action threshold of fifty. Suppose a separate numerical validation establishes that the computed score differs from the chosen reference by at most one tenth over the tested domain. A returned value of sixty is comfortably away from the boundary. A returned value of fifty and five hundredths is not. The issue is not that every close result must be wrong; it is that the stated bound alone cannot settle which side of the threshold the reference occupies.
North Workshop could define a review band around the boundary. Results outside the band follow the ordinary workflow. Results inside it receive additional analysis or a more precise calculation. This is a hypothetical application policy, not a recommended cryptographic setting. Its purpose is to show why numerical error should be connected to decisions rather than reported only as an average difference across a test set.
Average error can conceal precisely the cases that matter. Imagine nine hundred easy examples far from the threshold and one hundred difficult examples near it. A low average discrepancy across all thousand might coexist with unacceptable changes in the difficult group. The validation plan should deliberately include boundary cases, large magnitudes, small magnitudes and combinations that stress the proposed function.
The comparison must also name its reference. An encrypted approximation should not be judged against one floating-point implementation in one chart and an exact symbolic expression in another without explanation. If the baseline itself rounds values or approximates a function, those choices belong in the record. Otherwise the team may blame encryption for differences introduced earlier in the pipeline.
The shape of a calculation matters
Two algebraically equivalent expressions can have different computational structures. This is familiar even before encryption enters the picture. A sequence of operations can force each step to wait for the previous one, whereas a balanced arrangement can expose independent work. Encrypted evaluation makes it especially important to describe the actual compiled task rather than merely name the mathematical function.
Here is an original toy example using eight inputs. A serial product multiplies the first two, multiplies that result by the third, and continues until all eight are included. It uses seven multiplications along a chain. A balanced product first forms four pairs, then two products of those pairs, then the final product. It still uses seven multiplications, but the longest dependency path has three multiplication stages rather than seven.
This is an arithmetic dependency example, not an encrypted benchmark. Real cost depends on the implementation, parameters, numerical representation and resources. The example nevertheless explains why an operation count alone can miss a meaningful difference. Equal numbers of operations do not imply equal waiting time or equal demands on the representation.
A compiler can help bridge that gap. The 2018 CHET author manuscript proposes an interface between application compilation and homomorphic runtimes, and demonstrates an end-to-end stack for neural-network evaluation over encrypted data. Its contribution includes arranging and optimizing the computation rather than treating the cryptographic library as a black box. The manuscript's reported comparisons belong to its studied networks and implementations, not all programs. CHET author manuscript.
North Workshop should therefore preserve the compiled version of its scoring function alongside the source-level formula. If the compiler changes, the resulting program may change even though the visible formula stays the same. A reproducible test should identify both. This is ordinary engineering discipline, but it becomes particularly valuable when performance depends on transformations that an application author does not inspect by eye.
The team can also ask whether it needs the original function exactly. Perhaps the service was designed around an unnecessarily complicated expression because that was convenient in a previous environment. Reconsidering the function may reduce work. But changing the function is a product decision, not a free optimization: the revised version must still answer the original question adequately. Faster execution of a different task cannot silently count as faster execution of the old one.
Packing is useful only when the job fits the package
An encrypted representation may hold multiple values that can be processed together. The practical question is how the application's data maps onto that representation. A layout that suits one operation may be awkward for the next. An impressive batch rate can also hide a poor experience for a user submitting only one item.
Rotom, presented at USENIX Security in August 2026, tackles automated layout selection for homomorphic tensor programs. The authors describe a compiler that explores layouts and optimizations, and report reductions in rotations and execution costs on their evaluated workloads. This article relies on the primary proceedings abstract because the full-paper link timed out during access. It does not extend those reported improvements to arbitrary applications or reproduce the headline factors as general expectations. Rotom proceedings record.
To see the scheduling problem without borrowing a benchmark, imagine a hypothetical service that can process a package containing up to one hundred independent jobs in one second. If the package is full, the arithmetic average is one hundredth of a second of processing time per job. That does not mean each arriving user waits one hundredth of a second. The package still takes a second to process, and a job may wait while the package is assembled.
Now suppose jobs arrive slowly. The service must choose between running mostly empty packages and waiting for more submissions. Waiting improves utilization but worsens response time. Running immediately improves responsiveness but may raise cost per completed job. Neither policy is inherently wrong. They serve different workloads, and the chosen policy should appear next to any performance claim.
North Workshop has a further constraint: some measurements may use different scoring versions or different authorization contexts. They may not belong in the same package even if combining them would improve utilization. A performance demonstration that assumes all work is interchangeable might not represent the actual service. The useful test uses a realistic mixture of jobs, not only the easiest batch to fill.
The company should report both throughput and the distribution of completion times. Averages alone can hide long waits for a small group of requests. A production-like test might include a steady period, a burst, a quiet period and a version transition. Those conditions reveal whether the system remains useful when the convenient benchmark pattern disappears.
Fast arithmetic can still wait for memory
Original hypothetical timing: reducing a six-second kernel to two seconds reduces a ten-second sequential job to six seconds, if all other costs stay fixed. Not an encrypted-computation benchmark.
Accelerators can improve part of the computation, but hardware performance must be interpreted at the right boundary. A device that executes one operation quickly may spend substantial time receiving inputs, moving intermediate objects or returning outputs. Counting only arithmetic units can produce a misleading picture of an entire service.
The July 2022 FAB author manuscript describes an FPGA accelerator for bootstrappable homomorphic encryption, with attention to the balance between computation and memory movement. Its evaluation setup identifies implementation on a Xilinx Alveo U280 platform and studies a particular encrypted workload. The paper's architectural lesson is that scheduling, memory resources and data movement matter alongside arithmetic. Its comparisons are specific to the investigated configurations, not a timeless ranking of every FPGA, GPU and processor. FAB author manuscript, architecture and evaluation setup.
Consider a hypothetical remote job that takes ten seconds in total. Six seconds are spent in a selected compute kernel, two in transfers, one in preparation and one in final processing. If a new device makes only that kernel three times faster, its six seconds become two. The total becomes six seconds, not three and one third. The complete job is about one and two thirds times faster, even though the kernel is three times faster.
The example assumes the stages do not overlap and everything else stays unchanged. A real implementation might overlap work or introduce new transfer costs. Those possibilities are reasons to measure the pipeline, not reasons to discard the arithmetic. The point is to identify which portion of the job a claimed improvement actually changes.
North Workshop might discover that a faster evaluator shifts the bottleneck to the client. Preparing and encrypting inputs could dominate a small job, while server execution dominates a large one. There is no contradiction. The right optimization depends on the workload size and on which machine has spare capacity. A single impressive server figure cannot settle the design for every client.
Costs also have a time dimension. A dedicated accelerator may be attractive when continuously occupied and unattractive when mostly idle. A shared service may improve utilization but introduce queueing. A realistic comparison should state the arrival pattern and the allocation policy rather than assuming an invisible supply of perfectly scheduled hardware.
A confidential computation still needs an honest answer
Keeping inputs secret and proving that a requested calculation was performed are different requirements. A remote service might return a stale result, use the wrong model version or fail halfway through a job. Even without malicious behavior, those possibilities matter to the person relying on the answer. The application needs a way to connect an output to the intended input and function.
Microsoft SEAL's current security guidance makes several boundaries explicit: ciphertexts are not authenticated merely by successful loading or decryption; circuit privacy is not supplied; and releasing decrypted CKKS outputs can create key-dependent leakage risks in some protocols. It calls for expert review of commercial applications. These are implementation-specific warnings about protocol design, not evidence that all homomorphic encryption is broken or that a single added checkbox repairs every application. SEAL security guidance.
For North Workshop, the first operational question is mundane but important: which scoring version produced this answer? A correct result under yesterday's model may be unsuitable today. The response should be associated with an agreed task identifier, input version and function version through a protocol designed for the relevant threat model. Simply placing those labels in a convenient text field does not make them trustworthy.
The second question is whether the service completed the entire request. A batch containing one hundred jobs should not silently return ninety-nine answers and leave the client to assume that the missing case was normal. The application needs explicit handling of incomplete work, duplicates and retries. These requirements exist in ordinary remote computing too; encryption does not remove them.
The third question is what the client reveals while checking results. A debugging feature that sends detailed information back to an untrusted evaluator might undermine assumptions that held for the main calculation. The safest editorial lesson is not a recipe for fixing such a protocol. It is that diagnostics, error messages and support workflows must be included in the security review rather than treated as harmless accessories.
North Workshop should resist describing its service as secure solely because the arithmetic library is respected. A library is a component. The complete application includes authorization, message handling, storage, client behavior, monitoring and recovery. The boundary between a proven property and an operational promise should remain visible in every explanation of the service.
Decide who holds the power to reveal the answer
Key ownership is also organizational ownership of an important capability. In the simple fictional arrangement, North Workshop controls the secret key needed to decrypt its results. That choice limits what the evaluator can learn, but it creates obligations for the client. Losing the capability to decrypt can make stored results unusable. Exposing it can defeat the intended confidentiality boundary.
The company therefore needs a lifecycle plan rather than a ceremonial statement that the key is kept safe. Who may authorize use? What happens when a staff member leaves? How are old jobs distinguished from new ones after a change? Which historical results must remain readable, and for how long? These are questions for the system design and its responsible owners, not optional details for a later deployment phase.
A useful exercise is to follow one job through a key transition. The client submits it under an older configuration. The service is delayed. The client changes its active configuration before the response arrives. Can the response still be matched to the right decryption capability? Can an operator tell the difference between a delayed legitimate answer and an unrelated object? The exercise exposes missing state management without requiring a real incident.
The same discipline applies to backups. An encrypted archive may be available while the capability needed to interpret it is not. Conversely, a copied key may remain accessible after the team believes a system has been retired. Storage policy and key policy should therefore be designed together. A diagram that ends at encrypted storage leaves half the lifecycle unexplained.
For a first experiment, North Workshop can keep the organizational arrangement deliberately simple. One clearly identified data owner, one bounded task and one authorized result recipient reduce the number of assumptions to inspect. More complicated collaborations may be valuable, but they should be added because the application requires them, not because a demonstration becomes more impressive when it contains more parties.
The answer can reveal what the input concealment did not promise to hide
Suppose the encrypted service returns the sum of two measurements to someone who already knows one of them. That person can subtract the known value and recover the other. The arithmetic works regardless of how well the intermediate computation protected the inputs from the server. This original toy example shows a limit of the requested function, not a failure to encrypt correctly.
A related problem appears when a recipient can request many overlapping answers. Each answer may seem innocuous in isolation, while the collection exposes more information than intended. The application must decide which queries are allowed and to whom results are released. The phrase encrypted computation does not itself define a sensible disclosure policy.
This is why North Workshop's first design question concerned the function rather than the encryption library. If the desired output is too revealing for its recipient, changing the way the server calculates it does not solve that problem. The team may need a less detailed output, a different authorization rule or another privacy mechanism. Those changes require their own analysis rather than being implied by the word encrypted.
There is a useful distinction between protecting data during outsourced work and controlling information in a published result. The present article concerns the former. It does not treat homomorphic encryption as a substitute for statistical disclosure controls, nor does it attempt to import a differential-privacy guarantee into a system that has not implemented one. Complementary tools should be named according to the problem they actually address.
The company can make that distinction visible in its user interface. A result page might say who is authorized to see the answer and what the service provider is intended not to learn. It should avoid a generic badge suggesting that every subsequent use of the answer is private. Clear language helps users preserve the boundary that the technical design worked to create.
Test the application before celebrating the benchmark
A credible first evaluation has at least three separately recorded outcomes: numerical correctness for the chosen task, performance under defined conditions and security review of the complete protocol. Passing one does not imply passing the others. A fast answer can be wrong, a correct answer can arrive too late, and a useful result can be produced through an unsafe information flow.
North Workshop begins with a reference collection of synthetic test vectors. Because these are invented inputs, the team can publish them for reproducibility without exposing production measurements. The collection includes ordinary cases, boundary cases and deliberately awkward shapes. It records expected outputs or tolerances before comparing implementations, reducing the temptation to redefine success after seeing a favorable result.
Next it measures a complete job from preparation through receipt of the usable answer. It separately records individual stages so that bottlenecks can be diagnosed. Both views matter: a total alone can hide an avoidable inefficiency, while isolated stages can hide an unusable total. The benchmark report should make it possible to reconstruct how the advertised end-to-end figure was obtained.
The team then repeats the test under different arrival patterns and input sizes. A quiet demonstration on an otherwise idle machine is useful for establishing a baseline, but it should not be labeled a guarantee under contention. The report can distinguish a controlled laboratory condition from a production-like load without treating either as worthless.
Failures belong in the record as well. If a job cannot be completed within the selected configuration, that is informative. If a result exceeds the allowed numerical tolerance, it should not disappear from an average. If the client exhausts memory before the server begins, the limitation still belongs to the system being evaluated. A benchmark becomes more useful when it explains the boundaries of success.
Finally, the team preserves enough configuration information to repeat the experiment. That includes the function, input representation, software versions, compiler settings, hardware, relevant cryptographic parameter choices and timing boundary. Publishing the names of two libraries is not enough to explain a comparison when the actual jobs differ.
A small pilot should have a real decision attached
The best pilot is not necessarily the largest one. North Workshop can select a narrow calculation for which hiding the inputs from the evaluator has clear value, the output is well defined and the deadline is realistic. It can then ask whether the resulting system improves its options compared with the alternatives it can actually use.
The alternative may be local computation, a smaller shared dataset or a process that avoids collecting some measurements in the first place. Those comparisons should not be caricatured. If local processing already meets the need at acceptable cost, outsourcing through elaborate cryptography may add little. If remote capacity is essential and input exposure is the main obstacle, the additional engineering may be worth serious investigation.
A decision-oriented pilot establishes a stopping rule. For example, the company may require a certain task size to finish within its operational window, with specified numerical behavior and a reviewable protocol. If the pilot misses that target, the next question is whether the bottleneck is tractable. It should not keep expanding merely because each new optimization produces an interesting chart.
Conversely, a pilot that meets its target should not immediately inherit every possible use case. Success on fixed scoring does not establish readiness for open-ended training, unrestricted search or arbitrary user programs. Each expansion changes the work and may change the information revealed. A disciplined roadmap treats those as new evaluations rather than free consequences of the first success.
The people responsible for operations should participate early. They will handle delayed jobs, version changes, failed clients and unusual outputs. A design that looks elegant in a research prototype can become difficult to support if those situations are undefined. Including operators does not diminish the cryptographic ambition; it connects the achievement to a service that people can reliably use.
Put the price of waiting into the comparison
North Workshop also needs a realistic economic unit. Cost per multiplication is useful to a hardware designer, but the company buys completed work. Cost per encrypted job may be more meaningful, provided the job definition stays fixed. Even that figure can be incomplete if an inexpensive service misses the deadline and forces the company to repeat the work elsewhere.
Consider another explicitly hypothetical comparison. Service A charges two units per job and completes ninety out of one hundred jobs within the required window. Service B charges three units and completes all one hundred on time. Assume late jobs from A must be rerun through a separate process costing fifteen additional units each. A's initial bill is two hundred units, and the ten reruns add one hundred fifty. B's bill is three hundred units. Under these invented assumptions, the apparently cheaper service costs three hundred fifty units to obtain the needed set of usable answers.
The arithmetic is not an argument that a more expensive provider is always better. It identifies a missing variable: the cost of an unsuccessful or late result. If the reruns were inexpensive, or the deadline were flexible, the conclusion could reverse. A transparent comparison makes those assumptions visible so a reader can substitute conditions relevant to a different application.
There may also be an onboarding cost that does not recur with every job. Suppose adapting and validating the function requires one hundred staff-hours. At ten jobs, that effort is ten staff-hours per job when allocated evenly. At ten thousand jobs, it is one hundredth of a staff-hour per job. This simple allocation does not predict real labor requirements. It shows why a prototype's economics and a stable service's economics can look different without either estimate being dishonest.
The calculation changes again when the function changes frequently. A one-time adaptation becomes a repeated activity if every new model or input layout requires renewed validation. North Workshop should therefore measure the rate of change in its own workflow. A technically excellent solution for a stable monthly report may be less attractive for an experimental team replacing its analysis every afternoon.
Preserve the question when the implementation changes
A useful project archive contains more than successful outputs. It records why the task was chosen, what exposure the team wanted to avoid and which tradeoffs it accepted. Otherwise, a later optimization may accidentally preserve the benchmark while abandoning the original purpose. An engineer can make a system faster by moving a sensitive step back to the server in plaintext; that might be an intentional redesign, but it cannot silently count as an equivalent improvement.
North Workshop can maintain a short change description for each version: what function changed, what information flow changed, what test must be repeated and who approved the new behavior. This is proposed project practice, not a cryptographic standard. It gives reviewers a way to distinguish a routine software update from a change to the assumptions on which the service depends.
The archive should also retain negative findings. Perhaps an early layout handled ordinary inputs well but failed on unusually long vectors. Perhaps a proposed batch policy created unacceptable delays during quiet periods. Recording those results prevents the same unsuitable configuration from returning under a different name when staff or vendors change.
A final useful exercise is to ask a colleague outside the implementation team to explain the service from its documentation. Can that person identify the protected inputs, the evaluator, the answer recipient and the unprotected information? Can they distinguish a measured result from a proposed future capability? If the explanation collapses into a vague claim that everything is encrypted, the documentation needs work even if the prototype is functioning correctly.
What progress would look like to the person sending the data
For the user, the most meaningful progress is not an isolated multiplier in a paper title. It is a previously unacceptable computation becoming possible under a clear and credible arrangement. The user can understand who sees the input, who receives the answer, how the result was checked and what happens if the job fails.
Researchers may contribute at very different layers: a new construction, a better numerical representation, a compiler transformation, a hardware architecture or a more careful protocol. Those contributions need not compete for a single winner's podium. A usable system may depend on several of them working together, with each evaluated according to its actual claim.
The fictional North Workshop pilot ends well only if the company can state a bounded conclusion. It has demonstrated a particular task under particular conditions, with a specified result policy and an independently reviewable design. That conclusion is narrower than saying all cloud analysis is now private. It is also strong enough to support a real decision about the next deployment step.
Homomorphic encryption's distinctive achievement is to separate useful calculation from possession of the plaintext in a way ordinary outsourced computing does not. The practical challenge is to preserve that achievement while building the rest of the application honestly. The server may never open the envelope. The people designing the service still have to decide what goes into it, what comes back out and why the answer should be trusted.