Input Privacy vs. Output Privacy: Choosing a PET

Choosing a privacy-enhancing technology (PET) by its reputation (or by whichever acronym is having a good week) is a risky way to design an architecture. A better starting point is the simple question: Where could information leak?

In Comparing FHE and Other PETs, CSA identifies two dominant security models in PETs: input privacy and output privacy. Input privacy protects data from exposure during computation. Output privacy limits what someone can learn from the results. Fully homomorphic encryption (FHE) is primarily an input privacy technology; differential privacy (DP) is an output privacy technology.

These technologies are not interchangeable. If you need a personalized, high-precision result while keeping the underlying data encrypted during processing, DP is not a substitute for FHE. If you plan to publish aggregate statistics and must limit what those statistics reveal about individuals, FHE alone does not solve the output privacy problem. In many systems, the right answer may be to use both.

This blog breaks down both security models, explains why FHE and DP are not substitutes, and offers four questions for PET architecture planning. It also shows where a hybrid FHE and DP design can protect both inputs and published outputs.

 

What is Input Privacy?

Input privacy aims to prevent information leakage during data processing or computation. You never expose the input data to the computing environment, collaborating parties, or data processing system itself.

This security model applies when you must protect sensitive information while another system does useful work with it. Relevant PETs include:

• Fully homomorphic encryption (FHE): Allow computation directly on encrypted data, removing the need for decryption during processing.
• Secure multi-party computation (SMPC): Let multiple parties compute jointly on private data without revealing their inputs.
• Trusted execution environments (TEEs): Execute sensitive code inside an isolated hardware environment.
• Zero-knowledge proofs (ZKPs): Demonstrate that a statement is valid without revealing the underlying information.

All these technologies provide privacy. To decide which one to use, ask: What must we prevent the processor, collaborator, or verifier from seeing, and what trust assumptions are acceptable?

 

What is Output Privacy?

Output privacy aims to prevent information leakage through queries or the output of computation. The model may allow computation on clear, unencrypted data, but it limits how much an adversary can learn by observing the results.

Differential privacy is the clearest example. Use DP for aggregated statistical analysis or training on large datasets when individual contributions are small and you can tolerate some accuracy loss. Its objective is to provide a mathematically verifiable assertion that the outcome of analyzing a dataset is independent of any single individual’s data.

DP usually achieves that protection by introducing statistical noise. This makes it useful when an organization wants to release trends, counts, or model insights without revealing whether they included a particular person’s record.

However, DP can reduce precision. Since it relies on multiple data entries, it is poorly suited to cases in which a single individual needs an exact, personalized answer.

 

Why Fully Homomorphic Encryption ≠ Differential Privacy

FHE and DP protect different points in the information flow.

FHE protects the computation’s inputs. The processing system can operate on ciphertext without seeing the underlying data. DP protects what the output reveals. Noise limits the information an observer can infer from results.

FHE can preserve high or exact accuracy. Depending on the scheme, it can support exact computation or fixed-point calculations. DP deliberately trades some accuracy for privacy, which can be acceptable for population-level analysis but dangerous for individualized decisions.

Consider the example of a cancer detection model. If a patient needs an individualized result, added noise could produce a clinically significant error. DP is therefore not a viable substitute for FHE in that scenario. The system needs input privacy without making the personal output deliberately imprecise.

Now suppose a hospital wants to publish aggregate statistics about how many patients received a diagnosis. Even if FHE protected every record while the cloud calculated the total, the exact published total could still disclose information. This is especially true when the population is small or repeated queries allow differencing attacks. This is an output privacy problem where DP may be appropriate at the publication layer.

 

A Four-Question Test for PET Architecture Planning

Before selecting a privacy-enhancing technology, security teams should answer four questions.

1. What data must remain hidden during processing? Identify the raw records, model features, credentials, or business inputs that the compute environment and collaborating parties must not see.
2. Who will receive the result? A private result returned to one authorized user creates a different disclosure risk from a dashboard, research dataset, or public statistic.
3. How much accuracy can the use case tolerate losing? Aggregate trend analysis may tolerate noise. Fraud decisions, password checks, tax calculations, and clinical outputs may require high or exact accuracy.
4. Where does trust reside? FHE requires low trust in the processing system because it is blind to calculation inputs and outputs. TEEs require trust in hardware isolation and the attestation chain. The technology choice must match the threat model, not merely the performance target.

 

When a Hybrid FHE and DP Design Makes Sense

Input privacy and output privacy can be complementary layers. Use FHE with DP to protect both inputs and situations in which you publish outputs, such as database queries.

A hybrid flow can work as follows:

1. Encrypt data before it reaches the processing environment.
2. The cloud performs computation directly on encrypted data using fully homomorphic encryption.
3. An approved mechanism applies differential privacy to the aggregate result.
4. Release the privacy-protected output to its intended audience.

This design reduces two distinct risks: exposure of sensitive inputs during computation and inference from released results. It also demonstrates how PET selection is not always an either-or decision. Multiple PETs can cooperate when the system has multiple privacy boundaries.

 

Start With the Leakage Point, Not the Acronym

The distinction between input privacy and output privacy gives architects a durable way to evaluate privacy-enhancing technologies. FHE, SMPC, TEEs, and ZKPs can protect inputs under different trust and performance assumptions. DP protects outputs by bounding information leakage, usually at the cost of some accuracy.

Neither security model is automatically stronger. They answer different questions. The mistake is expecting one control to solve both without examining the data lifecycle.

Comparing FHE and Other PETs goes further by comparing performance, computational accuracy, hardware dependency, standards, quantum-level security, and hybrid compatibility.

Key takeaways include:

• How FHE protects data-in-use by enabling encrypted computation on data.
• How FHE compares with DP, SMPC, TEEs, and ZKPs.
• The differences between input privacy and output privacy.
• How performance, trust, security, hardware, standards, and quantum resistance affect PET selection.
• Where PETs can work together in hybrid architectures.
• How FHE is being applied in private search and password breach monitoring.

Read the full paper to build a PET strategy around your actual privacy challenges.