Privacy-Enhancing Technologies: Computing on Secrets

Two hospitals want to jointly train a model to detect a rare cancer earlier. Neither is allowed to send patient records to the other — regulation forbids it, and neither trusts the other's security team to handle raw data anyway. A decade ago, this collaboration simply wouldn't happen. Today, a family of techniques collectively called privacy-enhancing technologies (PETs) makes it possible for both hospitals to compute a shared result — a better model — without either one ever seeing the other's data.

That capability, computing on data you cannot see, is the thread connecting a set of otherwise very different tools: encryption schemes that let you do math on ciphertext, protocols that let multiple parties jointly compute a function without revealing their inputs, statistical noise that hides individuals in aggregate data, and proof systems that let you verify a claim without learning why it's true. None of these are new ideas in isolation. What's changed is that they've moved from cryptography papers into production systems that banks, hospitals, ad platforms, and governments actually run.

This guide explains what privacy-enhancing technologies are and how the five core techniques work: homomorphic encryption, secure multi-party computation, differential privacy, federated learning, and zero-knowledge proofs. It then covers why PETs are moving into production now, what they mean in practice for businesses and builders, the real limitations around cost and performance, and what to watch next.

What Privacy-Enhancing Technologies Actually Are

PETs is an umbrella term, not a single technology. It covers any tool or protocol designed to minimize or eliminate the exposure of personal or sensitive data while still allowing that data to be useful — analyzed, matched, modeled, or verified. The unifying goal is to separate two things that traditional data systems bundle together: the ability to use data and the ability to see it.

The major families, and what each one is actually good at:

• Homomorphic encryption (HE): lets you perform computations directly on encrypted data, producing an encrypted result that decrypts to the correct answer — without the computing party ever holding a decryption key. Fully homomorphic encryption (FHE) supports arbitrary computation; partially homomorphic schemes support a limited set of operations (like addition or multiplication only) but run much faster.
• Secure multi-party computation (MPC/SMPC): lets two or more parties jointly compute a function over their combined inputs while each party learns nothing about the others' inputs beyond what the output reveals. Think of three companies computing their combined market share without any of them disclosing their individual revenue.
• Differential privacy (DP): adds carefully calibrated statistical noise to query results or datasets so that no individual record can be reliably inferred, while aggregate patterns remain accurate. It's a mathematical guarantee, not a heuristic — you can quantify exactly how much privacy loss a given release incurs.
• Federated learning (FL): trains a machine learning model across many devices or data silos by sending model updates (gradients) back to a central server instead of raw data. The data never leaves its source; only the learning signal does.
• Zero-knowledge proofs (ZKPs): let one party prove a statement is true — "I am over 21," "this transaction is solvent," "I know the preimage of this hash" — without revealing any information beyond the statement's truth.
• Trusted execution environments (TEEs): hardware-isolated enclaves (Intel SGX, AWS Nitro Enclaves, Apple Secure Enclave) that run code and process data in a region even the host operating system or cloud provider cannot inspect, a category of infrastructure covered in more depth under confidential computing.
• Synthetic data generation: creates artificial datasets that preserve the statistical properties of real data without containing any actual individual's records, often generated by models trained with differential privacy.

None of these substitute for basic hygiene — access control, encryption at rest and in transit, and data minimization still matter. PETs address a different, harder problem: how to derive value from data during active use, computation, and sharing, which is exactly the point at which most privacy failures actually occur.

How the Core Techniques Work

Homomorphic Encryption

Ordinary encryption protects data at rest and in transit, but the moment you want to compute on it — run a query, apply a model, sum a column — you have to decrypt it first, which is where breaches and insider misuse happen. Homomorphic encryption removes that step. A scheme like CKKS or BFV encodes numbers into ciphertexts such that addition and multiplication operations on the ciphertexts correspond to the same operations on the underlying plaintexts. A cloud provider can therefore run a computation on your encrypted data and hand back an encrypted result that only you can decrypt, having never seen your data at any point.

The catch is cost. Fully homomorphic encryption is computationally expensive — orders of magnitude slower than plaintext computation, though hardware acceleration and better schemes have narrowed that gap considerably over the past few years. That's why most production deployments today use HE for narrow, high-value computations (a specific model inference, a specific aggregation) rather than general-purpose data processing — a cost curve worth watching alongside other long-horizon cryptographic shifts like post-quantum migration, which will eventually touch these same encryption primitives.

Secure Multi-Party Computation

MPC solves a different shape of problem: several parties each hold a piece of data and want a joint answer without pooling the raw inputs. Classic protocols split each party's input into random-looking "shares" distributed among the participants; no single share reveals anything, but the parties can jointly compute on the shares such that combining the final shares reveals only the output. Garbled circuits and secret-sharing schemes (like Shamir's) are the two dominant technical approaches.

MPC is the workhorse behind private set intersection — used when two companies want to find customers they have in common without either disclosing their full customer list — and behind multi-institution benchmarking, like banks jointly computing fraud-pattern statistics across their transaction data.

Differential Privacy

DP works by injecting calibrated noise, controlled by a parameter called epsilon, into query outputs or into the data collection process itself. A lower epsilon means more noise and stronger privacy; a higher epsilon means less noise and better accuracy. The technique gives a provable bound: even an attacker with unlimited auxiliary information cannot determine, with much better than random confidence, whether any specific individual's data was included in the dataset.

The tradeoff is explicit and tunable, which is both its strength and its operational headache — setting epsilon well requires understanding both the sensitivity of the query and the acceptable accuracy loss, and getting it wrong in either direction either leaks information or destroys utility.

Federated Learning

In federated learning, a central coordinator sends a model to many edge devices or data holders (phones, hospitals, banks). Each one trains locally on its own data and sends back only the updated model weights or gradients — never the raw data. The coordinator aggregates these updates into an improved global model and repeats the cycle.

FL alone isn't a complete privacy guarantee — gradients can leak information about training data through model-inversion or membership-inference attacks — so serious deployments pair it with differential privacy (adding noise to the gradients) or secure aggregation (an MPC technique ensuring the coordinator only ever sees the sum of updates, not any individual one).

Zero-Knowledge Proofs

ZKPs let a "prover" convince a "verifier" that a statement is true without revealing anything else. The classic illustration is proving you know the combination to a safe by opening it out of the verifier's sight, rather than reading the numbers aloud. In practice, zk-SNARKs and zk-STARKs let a party prove computational statements — "this transaction is valid and I have sufficient balance," "this credential meets an age threshold," "this ML model was trained on approved data" — with a proof that's fast to verify even though the underlying computation may have been complex.

Benefits of Privacy-Enhancing Technologies

Collaboration that was previously off the table

The headline benefit is that organisations can work together on data they are not allowed, or not willing, to share. Hospitals can improve a diagnostic model jointly, banks can compare fraud patterns, and advertisers can measure campaigns with publishers, all without pooling raw records. Projects that used to die in legal review because nobody could hand over the data become feasible when the computation, not the data, crosses the boundary between organisations.

Less sensitive data exposed during use

Most breaches and insider misuse happen when data is decrypted for processing or copied for analysis. Techniques like homomorphic encryption, MPC, and trusted execution environments keep data protected during computation itself. Fewer people and systems ever see plaintext, which shrinks the window in which something can go wrong and reduces the damage if a system is compromised.

Stronger support for regulatory arguments

Data protection rules and localisation laws make it risky to move raw personal data across borders or between companies. PETs let organisations show that individuals' records were never exposed, or that published statistics carry a quantified privacy guarantee. That doesn't make a system compliant on its own, but it gives legal and compliance teams a far stronger position than "we trusted the partner".

Provable, measurable privacy

Differential privacy and zero-knowledge proofs come with mathematical guarantees rather than best-effort masking. A team can state exactly how much privacy loss a release incurs, or prove a claim is true without revealing the evidence. That precision makes privacy decisions reviewable and auditable in the same way security controls are, instead of resting on whether a field was removed from a spreadsheet.

Customer and partner trust

Being able to explain that a partner never saw your customers' data, or that a model learned from devices without collecting messages, is a meaningful trust signal. It can shorten partner negotiations and reassure customers who are increasingly aware of how their data is used. Over time, a track record of collaborating without exposing raw data makes an organisation an easier partner to say yes to.

Privacy-Enhancing Technologies Use Cases

Joint model training across hospitals

Medical institutions often hold small, sensitive datasets that are individually too limited to train a strong model. Federated learning lets each site train locally and share only model updates, usually combined with secure aggregation or differential privacy. The outcome is a better model for conditions like rare cancers without patient records leaving any hospital, though legal and ethical review is still needed at each site.

Private set intersection for customer matching

Two companies want to know which customers they share, for a joint offer or advertising measurement, without revealing their full customer lists. MPC-based private set intersection computes the overlap so each side learns only the shared entries, or only a count. It has become one of the most established production uses of MPC.

Publishing statistics without exposing individuals

Statistical agencies and technology companies use differential privacy to release aggregate figures, such as census tables or usage statistics, with noise that protects individuals. The US Census Bureau's adoption is the best-known example. Analysts still get useful aggregate data, and the risk that someone could be re-identified by combining the release with other sources is formally bounded.

On-device learning on phones

Keyboard prediction and similar features learn from how people type without uploading what they type. Federated learning trains on the device and sends only updates, often with added noise. Users get better suggestions while their messages stay on their phones, and the provider avoids holding a large store of personal text.

Proving eligibility without revealing details

Zero-knowledge proofs let someone prove they are over an age threshold, or that an account balance exceeds a limit, without revealing the exact birth date or balance. Originally prominent in blockchain systems, the technique is spreading to identity verification and compliance checks where the verifier needs a yes or no, not the underlying record.

Cross-bank fraud analysis

Fraud often spans several institutions, but no bank wants to share transaction data with competitors. MPC lets banks compute shared fraud statistics or detect patterns across their combined data while each keeps its records private. Detection improves without creating a central pool of sensitive financial data.

Why This Matters Right Now

Three forces are converging to push PETs from research curiosity to deployment requirement.

First, regulation has multiplied the number of jurisdictions where moving raw personal data across a border, a company boundary, or even a departmental boundary carries legal risk. GDPR-style regimes, sector rules like HIPAA, and a growing list of national data-localization laws mean that "just centralize the data and analyze it" is no longer a safe default for any organization operating across markets or handling regulated categories of data.

Second, the value of cross-organizational data collaboration keeps growing faster than the willingness of any single party to hand over its raw data. Fraud detection improves when banks share patterns; drug discovery improves when pharma companies pool trial data; ad measurement improves when platforms and advertisers reconcile conversion data. In every one of these cases, the parties have a real commercial incentive to collaborate and an equally real incentive — competitive, legal, or reputational — not to expose their underlying datasets. PETs are the only way to get both.

Third, the computational cost of these techniques has fallen enough that they've moved from "theoretically possible" to "runs in production." Hardware-accelerated HE libraries, more efficient MPC protocols, and mature open-source implementations (Microsoft SEAL, OpenMined's PySyft, Google's differential privacy libraries) mean teams no longer need a cryptography PhD on staff to pilot these techniques — though they still benefit from one when tuning parameters that affect real privacy guarantees.

Common Privacy-Enhancing Technology Mistakes

Choosing a technique before naming the adversary

Teams often pick homomorphic encryption or federated learning because it is the technique they've heard most about, then try to fit the problem to it. Without first naming who must not see the data, the choice is frequently wrong: heavy cryptography where a trusted execution environment would do, or a distributed protocol where a simple noisy aggregate was enough. The result is over-engineering and poor performance.

Treating federated learning as private by default

Keeping raw data on devices feels like a complete privacy guarantee, but model updates can leak information about training data. Deployments that skip secure aggregation or differential privacy on the updates may expose more than their designers think. Federated learning reduces risk; it does not remove it on its own.

Letting engineers set privacy parameters alone

An epsilon value, key size, or share threshold chosen to make a pipeline run faster can quietly weaken the guarantee the business believes it has. These choices often get made by whoever implements the system, without review. They deserve the same scrutiny as access-control policies, with security and legal input.

Expecting plaintext performance and accuracy

Stakeholders sometimes assume a privacy-preserving version of an analysis will be as fast and as accurate as the original. Every PET costs something in latency, throughput, or accuracy. Pilots that don't set expectations upfront disappoint, and good projects get cancelled for missing a target that was never realistic.

Assuming the technology makes you compliant

Some organisations treat a PET deployment as the end of the compliance conversation. Regulators and auditors look at the whole data flow: who holds keys, what is released, how parameters were chosen. Skipping legal review because "the data is encrypted" leaves gaps that surface later, often during an audit or a partner's due diligence.

Privacy-Enhancing Technologies Best Practices

Adopting PETs is not a single decision — it's a set of technique-specific tradeoffs that depend heavily on the use case. The table below is a rough guide to matching problem shape to technique.

A few practical guidelines that tend to hold across industries:

1. Start with the threat model, not the technology. Are you protecting against an untrusted cloud provider (favor HE or TEEs), a mutually distrustful business partner (favor MPC), a curious analyst inside your own company (favor DP), or a regulator asking "can you prove this without showing us the data" (favor ZKPs)? Picking the technique before naming the adversary usually leads to over-engineering.
2. Combine techniques rather than picking one. Most real deployments layer them — federated learning with secure aggregation and differential privacy noise, or MPC-based computation running inside a TEE for defense in depth. No single PET is a complete answer on its own.
3. Budget for the utility cost up front. Every one of these techniques trades some accuracy, latency, or throughput for privacy. Decide the acceptable range before implementation, not after a pilot disappoints stakeholders expecting plaintext-speed performance.
4. Treat parameter choices as security decisions, not implementation details. An epsilon value, a key size, or a share threshold set by whoever happened to be implementing the pipeline can silently undermine the guarantee the business thinks it's getting. These choices deserve the same review rigor as an access-control policy.
5. Plan for auditability. Because PETs often make raw data literally inaccessible even to your own team, you need separate mechanisms — audit logs, proof transcripts, formal verification of the protocol implementation — to demonstrate the system is working correctly, since you can't just eyeball the data to check.

Real Limitations and Open Questions

PETs are powerful, not magic, and the limitations are worth taking seriously before betting a compliance strategy on them.

• Performance remains a real constraint. Fully homomorphic encryption is still commonly cited as running orders of magnitude slower than plaintext computation for general workloads; MPC protocols multiply network round-trips; ZKP generation for complex statements can take substantial compute. These costs are shrinking but haven't disappeared.
• Privacy guarantees depend on correct implementation, not just correct math. A provably secure protocol implemented with a timing side-channel, a weak random number generator, or a misconfigured noise parameter can leak exactly the data it was designed to protect. Cryptographic soundness on paper and security in deployment are different claims.
• Differential privacy's accuracy tradeoff is unavoidable, not a bug to be optimized away. There is a hard mathematical relationship between how much noise you add and how much privacy loss you tolerate; no amount of engineering cleverness lets you have strong privacy and full accuracy simultaneously for the same query.
• Federated learning still has attack surfaces. Malicious participants can attempt model-poisoning by submitting corrupted updates, and sophisticated inference attacks can sometimes reconstruct information about training data from model behavior, even without access to gradients directly.
• Composability is genuinely hard. Combining two PETs that are each individually secure doesn't automatically produce a system that's secure as a whole — interactions between protocols can open new attack paths that neither technique alone exhibits, which is why serious deployments rely on formal security proofs for the combined system, not just for each component.
• Regulatory recognition is inconsistent. Not every regulator or auditor treats a differentially private release or an MPC-computed result as equivalent to full anonymization or data minimization under the letter of the law, which means legal review is still a required step even after the cryptography is sound.
• Talent and tooling maturity vary widely by technique. MPC and DP have mature open-source libraries and a growing practitioner base; deploying production FHE at scale still often requires specialized cryptographic engineering that most organizations don't have in-house.

What to Watch Next

The trajectory across most of these techniques points toward lower cost and higher accessibility rather than fundamentally new capability. Hardware acceleration for homomorphic encryption — dedicated silicon and GPU-optimized libraries — is the single biggest lever on making HE practical for broader workloads. Standardization efforts around MPC and DP APIs are making it easier to swap providers without rewriting application logic. And as more regulators explicitly reference PETs in guidance (rather than leaving organizations to argue by analogy from existing anonymization rules), expect adoption to shift from "innovative differentiator" to "expected baseline" for any company handling data across organizational or jurisdictional boundaries — much the way TLS went from a security feature to a default assumption.

The organizations that get the most value out of PETs won't be the ones that adopt every technique at once. They'll be the ones that map their actual data-sharing and computation problems precisely enough to pick the narrowest tool that solves each one, and treat the parameter choices inside that tool as seriously as they treat any other access-control decision.

Teams evaluating which of these techniques fits their actual data and compliance constraints can get hands-on help from Woyce Technologies.

FAQ

What is the difference between encryption and homomorphic encryption?

Standard encryption protects data while it's stored or transmitted, but you have to decrypt it before computing on it. Homomorphic encryption allows computation directly on the encrypted data, producing an encrypted result that decrypts correctly, without ever exposing the plaintext to the party doing the computing. The trade-off is performance: homomorphic operations are much slower than working on plaintext, so today they suit targeted calculations like scoring or simple aggregates better than general-purpose workloads.

Is differential privacy the same as anonymization?

No. Traditional anonymization removes or masks identifying fields but has repeatedly been shown vulnerable to re-identification when combined with outside data. Differential privacy instead provides a mathematical guarantee about how much any single individual's presence in a dataset can affect the output, regardless of what auxiliary data an attacker has.

Can federated learning fully replace centralized data collection?

Not entirely. Federated learning avoids moving raw data, but it still requires careful design to prevent information leakage through model updates, and it introduces its own challenges around data quality, uneven participation, and coordination overhead across distributed sources. Many deployments combine it with differential privacy or secure aggregation for stronger guarantees. It works best when the data is naturally spread across many devices or institutions and moving it would be impractical or prohibited, such as keyboard prediction on phones or models trained across hospitals.

Are zero-knowledge proofs only used in cryptocurrency?

They originated in academic cryptography and gained early production traction in blockchain systems, particularly for private transactions, but the underlying technique applies anywhere you need to prove a claim without revealing supporting data — identity verification, regulatory compliance checks, and supply-chain attestations are all growing use cases outside crypto. A typical example is proving someone is over a required age, or that an account balance exceeds a threshold, without revealing the exact birth date or balance to the party checking it.

How expensive is it to adopt privacy-enhancing technologies?

It varies enormously by technique and workload. Differential privacy and secure multi-party computation for narrow use cases like private set intersection are relatively affordable with mature open-source tooling. Fully homomorphic encryption for general-purpose workloads remains costly in both compute and specialized engineering talent, though costs are falling. For most organisations the larger cost is expertise rather than infrastructure, so starting with a narrow, well-understood use case and an established library is usually cheaper than a broad platform effort.

Do privacy-enhancing technologies satisfy GDPR or HIPAA compliance automatically?

No single technology guarantees regulatory compliance. PETs can substantially reduce risk and support compliance arguments, but organizations still need legal review to confirm a given implementation meets the specific requirements of the applicable regulation in their jurisdiction and sector. Regulators generally look at the whole data flow, including who holds keys, what outputs are released, and how parameters such as a differential privacy budget were chosen, rather than at which technique was used.

Which privacy-enhancing technology should a business start with?

There's no universal answer — it depends on the threat you're addressing. A business worried about an untrusted cloud provider should look at homomorphic encryption or trusted execution environments; one collaborating with external partners should look at secure multi-party computation; one publishing aggregate statistics should look at differential privacy. Naming the specific risk first makes the technology choice much clearer.

Conclusion

Traditional data systems force a trade-off: to use data, someone has to see it. Privacy-enhancing technologies break that link. Homomorphic encryption computes on ciphertext, secure multi-party computation lets partners compute jointly without sharing inputs, differential privacy protects individuals in published statistics, federated learning trains models where the data lives, and zero-knowledge proofs verify claims without revealing the evidence.

The most useful takeaway is that these are tools for specific threats, not a single privacy upgrade. The right choice depends on who you don't trust with the data: a cloud provider, a partner, the public, or a central server. Naming that risk first makes the technology decision far simpler, and many real systems combine two or more techniques.

The caveats matter. Performance overhead is still significant for fully homomorphic encryption, parameter choices like a differential privacy budget require expertise, federated systems can leak through model updates if designed carelessly, and no technique makes a system compliant on its own.

A practical next step is to pick one data-sharing or analytics project currently blocked by privacy concerns and map which party needs to learn what. Our AI and machine learning team can help you assess which technique fits that workflow.