MPC, Homomorphic Encryption, Trusted Execution, and PET Selection

Banks that want to detect shared fraud patterns without revealing customer records are not a thought experiment. The U.S.-U.K. PETs Prize Challenges put that problem on the table for real. Track A, "Transforming Financial Crime Prevention", asked for end-to-end privacy-preserving federated learning to detect anomalous payments on synthetic datasets created by Swift. US entrants could engage FinCEN. UK entrants could engage the ICO, the National Economic Crime Centre and the FCA. The money came from NIST and NSF with the White House OSTP, and in the UK from the Centre for Data Ethics and Innovation / Responsible Technology Adoption Unit and Innovate UK. It ran in three phases: concept paper, solution development, red teaming. US prizes came to $675,000, out of a combined US-UK pool of $1.6 million (£1.3 million). Winners were announced on 30 March 2023 at the second Summit for Democracy.

The phase that matters for PET selection is the last one. Independent red teams were paid to break the entries. The NSF's announcement of the winners, on 31 March 2023, records it plainly: "In the final phase of the challenges, the privacy guarantees of the solutions were put to the test by "red teams" attempts to reveal the original data used for training the models." Set that beside a proposal that says "use encryption". The challenge named the operator, the regulators, the data, the computation and the people paid to break the result. The proposal names a word.

No technique provides "private computation" in every sense. The choice comes out of a clear trust model, computation, leakage budget, adversary, performance target and operational environment. A team owes six answers before anybody names a technique.

MPC distributes trust among parties. Homomorphic encryption computes on ciphertext under cryptographic constraints. Trusted execution environments protect code and data within hardware-isolated regions. Hybrids can combine secure aggregation, DP, encryption and access controls. Each introduces new assumptions and failure modes.

The building blocks are considerably older than the current wave of products. Fully homomorphic encryption dates to 2009, when Craig Gentry published the first such scheme, built on ideal lattices. What it cost was then measured rather than argued. Gentry and Shai Halevi implemented the scheme and reported the numbers. Public keys ran from 70 Megabytes at dimension 2048 to 2.3 Gigabytes at dimension 32768. Key generation at dimension 32768 took 2.2 hours. A single bootstrapping (Recrypt) operation took 6 seconds at dimension 512, 32 seconds at 2048, 2.8 minutes at 8192 and 31 minutes at 32768. The machine was an IBM System x3500 with a quad-core Xeon E5450 at 3GHz and 24GB RAM. Their own abstract states the range: "The time to run one bootstrapping operation (on a 1-CPU 64-bit machine with large memory) ranges from 30 seconds for the "small" setting to 30 minutes for the "large" setting." The scheme worked. That was the price of running it.

The standards record shows the same distance between the idea and the deployable mechanism. Only one published ISO/IEC International Standard covers homomorphic encryption specifically: ISO/IEC 18033-6:2019, published 2 May 2019 and confirmed at stage 90.93 on 28 October 2024. It specifies two mechanisms, and both are only partially homomorphic. Its scope line reads "This document specifies the following mechanisms for homomorphic encryption.", and the two listed beneath it are exponential ElGamal encryption and Paillier encryption. The fully homomorphic series is still in progress. ISO/IEC DIS 28033-1, Information security — Fully homomorphic encryption — Part 1: General, stood at stage 40.60 with voting closing 11 December 2025. Sixteen years after Gentry's paper, the internationally standardised homomorphic mechanisms are still the partial ones, and the FHE parts are drafts.

Choosing a PET is choosing which assumption you agree to carry. A hardware enclave asks you to carry a chip vendor's threat model.

Three mechanisms, three different parties trusted to behave. The choice says which of them you are no longer willing to rely on. Secure multi-party computation distributes computation among participants. It reduces reliance on one trusted party, its communication and protocol complexity can be high, its security depends on the adversary and collusion model, and it is useful for joint statistics and matching. Homomorphic encryption keeps values encrypted during supported computation. It gives strong cryptographic separation, its computation and precision are expensive, key management is critical, and it is useful when the server should not see plaintext. A trusted execution environment protects execution inside hardware isolation. It can support broader existing code, it depends on vendor hardware and attestation, side channels and patching matter, and it is useful for lower-latency confidential workloads.

That comparison was settled once on a live market. The first large-scale practical deployment of secure multi-party computation was the Danish sugar-beet contract double auction of January 2008. It had 1,229 bidders. The auctioneer's role was split across a three-party computation, run by representatives of Danisco, the growers' association DKS and the SIMAP research project. Each held key material on a password-protected USB stick. The whole thing ran on three Dell Latitude D630 laptops over a 100Mbps LAN. The three-party split was not an architectural preference. Farmers would not accept Danisco as auctioneer, and Danisco could not be excluded, so the trust model dictated the shape. The mechanism inside that shape was then chosen on cost, and the team wrote down why: "A three party solution was selected, partly because it was natural in the given scenario, but also because it allowed using efficient information theoretic tools such as secret sharing, rather than (much) more expensive cryptographic methods such as homomorphic encryption."

The same paper disposes of the third option in one sentence, and it is an operations sentence rather than a cryptographic one: "But a real hardware box is a system component like any other: it must be securely installed, administrated, updated, backed up, etc." Whichever of the three you take, something has to be run by somebody afterwards.

Four mechanisms and the hybrid that combines them, each covering a different boundary between what is computed and what is revealed. MPC has parties jointly compute while limiting disclosure of private inputs. Homomorphic encryption performs supported operations over encrypted values. A trusted execution environment relies on hardware isolation, attestation and platform security. Differential privacy bounds individual influence in released results. A hybrid architecture combines mechanisms to cover different trust and leakage boundaries.

The hybrid is usually where a diagram stops and a label begins. One entry in the financial-crime track of the U.S. PETs Prize Challenge wrote it out, and took Special Recognition and $10,000 for it. The messaging network computes model updates for both possible values of the bank-held account flag. Then the messaging network, the bank and a separate aggregator run a multi-party computation: the aggregator adds differential-privacy noise, and the MPC obliviously selects the correct update. Classification is handled by two-party computation between the messaging network and the bank. Visa Research's own summary of the step where the two mechanisms meet: "The messaging network provides the two possible updates, bank provides the flag, and aggregator adds noise (for differential privacy) to prevent inference attacks."

MPC covers the joint computation. DP noise at the aggregator covers inference on the output. They are answering different questions, which is why both are present. The second-placed team, PPMLHuskies, layered the same two ideas differently — encryption for input privacy, a differentially private training algorithm for output privacy. That difference is the design space this map is for.

Name the adversary first. The mechanism, the layering and the verification all follow from what that adversary is assumed to be able to see.

1. Define the trust model. Name honest, curious, malicious, colluding and compromised parties. In the sugar-beet auction this step produced the whole architecture: the parties that could not be trusted with the auctioneer's role were named, and a three-party split followed.

2. Specify computation and leakage. Describe functions, outputs, metadata, repeated queries and precision. Track A did this before entrants existed: federated learning over synthetic datasets created by Swift, to detect anomalous payments.

3. Compare mechanisms. Evaluate security assumptions, latency, scale, usability and failure recovery. This is where 31 minutes per bootstrapping operation and a 2.3 Gigabyte public key are comparison results rather than trivia, and where secret sharing beat homomorphic encryption in the Danish auction on cost.

4. Design the hybrid. Layer PETs with minimization, access, DP, monitoring and contracts. The Visa Research design did it by wrapping an obliviously selecting MPC around an aggregator that adds differential-privacy noise.

5. Verify and maintain. Test implementation, keys, attestation, updates, incidents and retirement. The PETs Prize Challenges gave this an entire phase and separate prize money, on the assumption that nobody verifies their own privacy guarantee convincingly.

Every party in the architecture sees something. This drill writes down exactly what each of them sees. It has been run, competitively, on this exact scenario.

In Phase 3 of the U.S. PETs Prize Challenge, independent red teams of privacy researchers attacked the blue teams' prototypes. Their findings fed the final round of judging that ranked the blue teams. The red-team prizes were a single ranking across both tracks: ETH SRI took first place and $60,000, Entmoot second ($40,000) and Blackbird Labs third ($20,000). In the financial-crime track, the first-place team went straight for the one private attribute the banks held. Their own summary of the approach: "In the financial crime track we considered the safety of the flag value at the banks as an essential part of any good solution. We therefore focused on attacks exposing this as a boolean value and found highly generalizable attacks with near-perfect accuracy."

The attribute they recovered was one bit. Run the drill on the assumption that yours is worth as much.

A PET guarantee holds only under assumptions about the parties, the keys and the hardware, and those assumptions age. BadRAM dates one such ageing to the day.

AMD SEV-SNP's integrity and attestation guarantees were broken in 2025 by De Meulemeester and five colleagues. The method was to unlock a DIMM's Serial Presence Detect chip and create physical-address aliases. The equipment was a Raspberry Pi Pico and a DDR socket. Their paper puts the cost in the introduction: "Notably, our practical, low-cost SPD manipulation setup requires only brief, one-time physical access and can be built for approximately $10." It was disclosed to AMD on 26 February 2024 and tracked as CVE-2024-21944 / AMD-SB-3015. It was published at embargo end on 10 December 2024, with an AMD severity of Medium (CVSS 5.3) against 3rd- and 4th-generation EPYC processors — Milan, Milan-X, Genoa, Genoa-X, Bergamo and Siena. The only mitigation was Platform Initialization and SEV firmware updates shipped to OEMs.

Nothing about the deployed systems changed on 26 February 2024 except what was known about them. The attestation reports went on saying what they had always said until the firmware arrived. That is the shape of an assumption ageing: a vendor threat model that held, roughly $10 of parts, a CVE number, a severity rating, a processor list, and a patch someone has to apply.

Decide in advance which protocol failure, side channel, or performance result would force the owner to redesign, restrict, remedy, or retire the system.