The Maginot Line was not a folly. That's the part everyone forgets. In the late 1930s it was the most sophisticated defensive installation on earth: interconnected forts, retractable gun turrets, underground railways, air filtration against gas, garrisons provisioned to live below ground for weeks. It was…formidable. So in mid-May 1940, seven Panzer divisions under Guderian, Reinhardt, and Hoth simply declined to test it. Instead, the Germans drove 1700 tanks through the Ardennes forest to the north of the Line, assumed by the Allies to be impenetrable, and then forced the critical Meuse river crossing in three days, while the Allies had assumed at least three times that much advance warning.
West of the Meuse, the Wehrmacht sprang the trap. The Allies assumed they’d see the standard Schlieffen shape of attack from 1914: a large force rushing at them through the Low Countries. German Army Group B made it look that way, and the Allies took the bait, marching straight at them. But the separate seven-division armored force crossed the Meuse to the south and turned northwest, racing behind the Allies to the coast, cutting off supplies and reserves. Almost as an afterthought, the finest fortification of its age went on defending a border that was no longer of any consequence, until ordered to surrender by the armistice of June 22.
“The Maginot Line is an inevitable barrier”; “The Ardennes is impassable”; “Any assault at the Meuse will be too slow”; “The German attack will come from one place and follow the same old plan”. The engineering of the Dyle-Breda defensive plan seemed sound, but the trust assumptions were wrong. Dunkirk was just one direct outcome of those wrong assumptions.
How do Privacy Enhancing Technologies relate to the Maginot Line and Dunkirk? Most of the PET industry is building Maginot Lines. They’re real engineering, honestly difficult. Each approach comes with an accounting: assets in security matched by liabilities in the assumptions it makes about the threats you face and the costs you incur. Make the wrong assumptions at your own peril.
Double-Entry Bookkeeping in PETs
Which brings us to Luca Pacioli and 1494, long before Maginot. A Franciscan friar and sometime roommate of da Vinci, his contribution to the Renaissance wasn't mathematics, it was honesty: double-entry bookkeeping. He codified the method that forces every transaction onto the ledger twice: once for the asset, once for what it costs you. In contrast, the PET market keeps single-entry books: a column of defensive assets, without the frank accounting of possibly wrong assumptions and liabilities. We can start our bookkeeping with a simple recognition: no privacy technology eliminates the need for trust. Each one relocates it, and each pays for the move in a different currency. An honest liability accounting asks three questions of every PET: where did the trust go, what did the relocation cost, and do the resulting trust assumptions address the adversary you actually face?
Refuse the Category Error
PETs do not all answer the same question.
- Secure computation: trusted execution environments (TEEs), secure multi-party computation (MPC), and fully homomorphic encryption (FHE), protect the inputs to computation from whoever is doing the computation.
- Differential privacy (DP) protects only what the finished output reveals, and has nothing to say about keeping secrets from whoever is computing.
- Zero-knowledge proofs (ZKPs) are yet a different defense: they can prove that a computation was performed correctly without disclosing what went into it, but they say nothing else.
You can’t compare these diverse classes, but you can be disciplined about double bookkeeping within these groups. To keep an eye on the clock, we’ll focus today on just the first of these taxons: secure computation.
DP and ZKPs will have to wait for another blog post.
Trusted execution environments pay in hardware trust and adversary mismatch
A TEE is a hardware-isolated region of a processor that runs code and holds data in a way that shields them from the rest of the system, including the host OS and other privileged code. TEEs enforce confidentiality and integrity in CPU hardware (and more recently, in GPUs as well). With TEEs, trust rests on remote attestation: the hardware cryptographically signs a measurement of the code it's running, so a remote party can verify what is executing inside the enclave before entrusting it with secrets.
Assets: TEEs offer input privacy guarantees at near-native computation speed, which is one of two reasons people reach for them. The other reason is about ease of programming: you don’t need cryptographic training to build a TEE solution. They offer generality, supporting the full range of operators and data types we expect in a modern computer.
Liabilities: With TEEs, your trust goes to the silicon vendor's key infrastructure and attestation protocols, and the correctness of their silicon: complex and far-reaching infrastructure that still has not been comprehensively analyzed for security. Critically, you also trust that the adversary lacks (or is unwilling to use) privileged or physical access to the machine.
Why is that last liability critical? The whole point of a TEE is to compute on hardware that someone else owns. However, that also means that they can touch it at will. Foreshadow, Plundervolt, TEE.fail, and the steady procession of other successful attacks on TEEs are not a run of bad luck to be patched away one CVE at a time. They are the predictable consequence of assuming your enemy keeps their fingers out of a box that you handed them. Perhaps the wrong assumption for the enemy you face in the cloud. Finally, while TEEs attempt to assure the end user about what program is running inside the enclave, and hence what the output might leak about the input data, that attempt fails. Attacks such as TEE.fail can forge the very attestations that were supposed to vouch for the enclave, when an adversary has physical access to the machine.
Conclusion: TEEs offer speed and generality, but with security assumptions that echo 1940’s faux pas: a broad base assumed to be defensible with few resources / too little notice (the Meuse assumption), that holds only against an obliging adversary (the Line’s inevitability assumption), and is based on the assumption of no fingers in the box (the Ardennes impassability assumption).
Secure multi-party computation pays in comms and liveness
MPC is a family of cryptographic protocols that lets two or more participants jointly compute over their combined inputs. With certain trust assumptions in place, no party learns anything beyond the output. Confidentiality is enforced by mathematics rather than by any single machine or operator.
Assets: MPC offers the same input privacy, general computation, and integrity guarantees as TEEs, but with the advantage, like FHE, that no single hardware owner can break its confidentiality guarantees. Trust is split across the participants by construction: at least in some variants, every other party can collude against you and your data remains secure.
Liabilities: With MPC, you trust cryptography, but it’s much simpler cryptography to prove right than with TEEs. What MPC costs you is performance and interaction. Though research advances in the last few years have improved the situation, most production MPC suites require every party to stay online and in lockstep communication with every other party for the entire computation. Network latency, not arithmetic, becomes the wall. And, while recent results such as pseudorandom correlation generators and silent OT have removed the communication cost of manufacturing that correlated randomness, those inventions are less battle-tested than the root of trust for FHE.
Conclusion: MPC's trust assumption can be generous, providing confidentiality and integrity even when many participants share data and computation. On the other hand, current deployments pay dearly for that generosity in computational speed, constant communication, and an absolute dependence on every participant staying reachable. Not that different from 1940: the Wehrmacht never had to defeat the Allied armies in the north; it only had to sever their communications and cut them off from supply.
Fully homomorphic encryption pays in computation and integrity
FHE is a mature encryption scheme that can compute directly on ciphertexts. In a client-server arrangement, an FHE server can compute on encrypted data it can never read, with confidentiality enforced by a particular hard math problem: the hardness of lattice problems: the same family of problems that underpins NIST’s post-quantum cryptography standards. The critical hinge pin in FHE is that the decryption key never leaves the client, making it impossible for the server to learn about the data.
Assets: FHE provides input privacy with mathematical certainty far beyond what TEEs provide. It also requires a minimum of communication between client and server, unlike production MPC. Your trust goes only to cryptography, and you don’t pay in continuous communication.
Liabilities: FHE pays, one way or the other, in computation. FHE comes in two distinct flavors. In one of them, there’s no such thing as general computation. In the other, general computation can be done, but it costs orders of magnitude more when doing standard computer arithmetic.
The former we call the arithmetic schemes of FHE (CKKS, BGV, BFV). I would argue that they dominate in utility and practical acceleration of secure computation, but the operators they provide are just two: add and multiply. If used liberally, they can make FHE look like general computation, but when it comes to common needs like ReLU or sigmoid or division and so on, you’re stuck with approximate algorithms that may never be good enough to mimic the plaintext originals.
The latter we call the torus scheme of FHE (TFHE). The flexibility of this scheme, based on lookup tables that can implement a broad range of functions, is very much constrained by the very narrow precision you get: perhaps efficient for only two or at most four bits at a time. The consequence of only a few bits at a time is, of course, that doing arithmetic the way most programmers understand gets very expensive, very quickly. For comparable math, implementation using the arithmetic schemes is much cheaper than implementation using the torus scheme.
FHE has a further liability: it says nothing about integrity, which can also compromise output privacy. The server performing your computation could substitute a wholly different program, meaning that a server can purposely give you a wrong answer. Or worse, try to trick you into sharing your secret key to reveal your data, and you might never know.
Conclusion: FHE is incredibly complicated mathematics with a small attack surface. In all its schemes, the invoice in computation overhead and memory expansion is large enough to be discouraging for some applications, but still workable for a significant portion of them. The real payoff in FHE comes when overhead amortizes under heavy batching, and when hardware acceleration comes into play. But, FHE needs to be able to say something about integrity: the question of what program was actually run at the server.
Make your PET providers do the books in double entry
The secure computation PETs all have strengths, but they all make heavy trust assumptions that may not match the adversary, or that can come with high costs that nobody likes to talk about.
What to do? Every time someone approaches you with a Privacy Enhancing Technology, post its assets on the ledger, then turn the page and post its liabilities as well. Those liabilities include concerns like trust assumptions you cannot verify, participants who must not blink, cycles and memory you must pay for, and missing integrity assurance. The right question is never "which PET is best." It is which assumptions you can afford to live with — for your data, for your adversary, and for your tolerance for being wrong. In 1940, the French and British defense thought they could live with at least four: “The Maginot Line is our anchor”; “The Ardennes is impassable”; “Any assault at the Meuse will be slow”; and “The German attack will come from one place and follow the same old plan”. It turns out they were, to a disastrous degree, wrong.
To learn more about FHE, hardware acceleration, and Niobium’s encrypted cloud platform, The Fog™, contact us or sign up to join our Developer Partner Program.
