Chapter 16: Computing on Secrets
"The problem of privacy is not how to hide data, but how to use data without disclosing it."
Andrew C. Yao, "Protocols for Secure Computations" (1982)^1^
Introduction
The previous chapter examined zero-knowledge proofs, which let one party prove a statement is true without revealing why. This chapter is about the adjacent and complementary capability: performing a computation on secret inputs, without any participant in the computation learning those inputs.
A zero-knowledge proof operates on a result that already exists. The computation whose correctness is proved was performed somewhere, by someone, on inputs that were available somewhere. The proof certifies what was computed, not who saw the inputs. Zero-knowledge is the verification primitive.
Computing on secrets is the execution primitive. It answers a different question: can a computation be performed when no single party is permitted to see the inputs? The answer is yes, under three architectural families that have reached practical deployment within the last decade. Fully homomorphic encryption performs arithmetic directly on ciphertexts. Secure multi-party computation splits a computation across participants so that no participant sees the whole input. Trusted execution environments run computation inside a hardware enclave whose contents are opaque to the operating system and to the hardware owner.
These families are complementary to zero-knowledge proofs, not competing with them. A pipeline that protects privacy end-to-end typically uses computing-on-secrets to operate on private data and zero-knowledge to prove the result was produced honestly. Chapter 15 examined the proving half of that pipeline. This chapter examines the executing half.
16.1 The Verification-Execution Distinction
Consider a voting system in which each voter's choice must remain private, and in which the tallied result must be publicly verifiable. The inputs (individual ballots) must remain secret; the output (the tally) must be computable and verifiable.
Plain encryption handles the secrecy of inputs at rest but not their use. If ballots are encrypted and sent to a counting service, the counting service must decrypt them to count them, which means at least one party has access to every individual ballot. The architecture has not solved the problem; it has only moved the problem from transport to a specific processing node.
Zero-knowledge proofs handle the verifiability of the output without directly addressing the privacy of the inputs. A zk-proof can certify that a tally was computed correctly from some set of ballots. The proof alone does not ensure that the ballots were private during the tally; it ensures only that the tally corresponds to them. If the counting service decrypted ballots to produce the tally, the proof is compatible with that architecture. Privacy of inputs is a separate requirement.
Computing on secrets handles the privacy of inputs directly. Homomorphic addition lets the counting service add up ballots in ciphertext form without ever decrypting any individual ballot; the final tally ciphertext is decrypted once by a distributed threshold of key holders. Secure multi-party computation distributes the counting across nodes so that no single node sees any voter's choice, and the output is reconstructed only from the joint result. A trusted execution environment runs the count inside an enclave that refuses to disclose its memory to any external party and provides an attestation that the canonical counting software ran on the expected ballot inputs.
The complete system combines the two families. Ballots remain private through computing-on-secrets; and the tally is publicly verifiable through zero-knowledge. Neither family alone solves the problem; their combination does.
16.2 Homomorphic Encryption: Arithmetic on Ciphertext
Homomorphic encryption permits operations on ciphertexts that correspond to operations on the underlying plaintexts. If Enc(a) is the encryption of a plaintext value a, and Enc(b) is the encryption of b, then a homomorphic addition produces a ciphertext whose decryption equals a + b, without any party learning either value in plaintext form. The construction is almost miraculous when stated plainly, and it is achievable under specific mathematical assumptions.
From Partial to Fully Homomorphic
The earliest homomorphic schemes supported only a single operation. RSA famously supports homomorphic multiplication, which is a property its designers did not advertise but which researchers quickly noticed and which motivated the broader line of research. The Paillier cryptosystem supports homomorphic addition. Partially homomorphic schemes have been used in practice for narrow applications for decades, including e-voting systems and private information retrieval.^2^
Craig Gentry's 2009 dissertation was the first construction of a fully homomorphic encryption scheme capable of both addition and multiplication on arbitrary circuits.^3^ The original construction was roughly a billion times slower than the equivalent plaintext computation, which ruled it out for any serious application. The theoretical breakthrough was that such a scheme existed at all. The engineering program that followed has reduced the overhead by roughly four orders of magnitude over fifteen years, which moves narrow applications into the range of feasibility while keeping general-purpose computation out of reach.
The Current Deployment Field
The present constructions that practitioners use fall into three families. The Brakerski-Gentry-Vaikuntanathan (BGV) and Brakerski-Fan-Vercauteren (BFV) schemes support integer arithmetic and are well-suited to computations that can be expressed as polynomials over finite fields.^10^ The Cheon-Kim-Kim-Song (CKKS) scheme supports approximate arithmetic over the real numbers, which is well-suited to machine-learning inference where small numerical errors are acceptable. The Torus FHE (TFHE) family supports fast evaluation of arbitrary Boolean circuits through a technique called programmable bootstrapping, which is well-suited to logic-heavy computations. Open-source libraries including OpenFHE, Microsoft SEAL, and Zama's TFHE-rs implement these schemes in production-quality code.^4^
The practical deployments fall into categories whose common property is that narrow usefulness beats broad slowness. Encrypted machine-learning inference lets a client send an encrypted input to a service and receive an encrypted output without the service seeing the input; CKKS is the usual vehicle, and the applications include encrypted medical diagnosis and encrypted financial-risk scoring. Private information retrieval lets a client query a database without revealing which record it wants; variations of homomorphic techniques power deployments of this kind in privacy-focused email and search products. Encrypted databases let a service host encrypted customer data and answer queries over it without decrypting; BGV and BFV are the usual vehicles.
What homomorphic encryption does not yet do is support fully general-purpose computation at acceptable speed. The overhead remains large enough that applications are chosen for their tolerance for latency and their limited computational complexity. The frontier is moving toward broader applicability, and improved hardware acceleration has contributed to the move, but the architecture is not yet the default way to run arbitrary programs on private data.
The Structural Promise
Beneath any specific application sits a simpler claim. Homomorphic encryption breaks the assumption that the service running a computation must see the data on which the computation runs. That assumption had been treated as a law of cloud architecture for two decades. Homomorphic encryption denies it. The service and the user become parties to an exchange in which the service performs a function and the user retains epistemic ownership of the inputs. The contract structure that was previously infeasible is now infeasible only at certain workload sizes, and the workloads for which it is feasible are expanding each year.
16.3 Secure Multi-Party Computation
Secure multi-party computation (MPC) addresses a different problem with a different architecture. Multiple parties each hold private inputs; they wish to jointly compute a function of those inputs and to learn only the output. No party learns any other party's input beyond what the output itself reveals.
The Core Primitives
The classical constructions rely on a small family of cryptographic primitives. Secret sharing, originally studied by Shamir in the 1970s, splits a secret into shares such that any threshold number of shares reconstructs it but any smaller subset reveals nothing. A function to be computed on secret inputs can be expressed as an arithmetic circuit, and operations on the circuit can be performed on shares, with each participant computing local operations on their share and jointly opening only the final output. Garbled circuits, introduced by Yao, allow two parties to evaluate a Boolean circuit where one party encrypts the circuit and the other evaluates the encryption; each gate's behavior is correct but its intermediate values are hidden. Oblivious transfer lets a party receive one of two values chosen by another party without the sender learning which value was chosen; it is a foundational primitive on which many MPC protocols rest.
The practical constructions combine these primitives in ways that fit specific applications. The GMW, BGW, and SPDZ protocol families each offer different tradeoffs among efficiency, security against actively malicious adversaries, and the threshold of honest participants required. A production MPC deployment must pick a protocol whose threat model matches the deployment's actual threat model, and the choice determines how many participants can collude without compromising the computation.
Threshold Signing in Production
The single most successful MPC deployment to date is threshold signing, and it has reached institutional scale. A threshold signature scheme distributes the private key across multiple parties such that signing requires a threshold of them to cooperate, and no subset below the threshold can produce a valid signature. No party ever holds the full private key, which means a breach of any individual party does not compromise the system. Fireblocks, the largest institutional custody provider, operates threshold-signed wallets for roughly two thousand customers including major banks and payment processors; the architecture is the basis on which several of those institutions extended credit into the crypto-asset space at all, because the alternative of a single-party custodian required levels of counterparty trust they were not prepared to extend.
Two Schnorr-based constructions have made threshold signing directly viable on Bitcoin. MuSig2, specified in BIP 327, aggregates an arbitrary number of signers into a single public key and a single signature indistinguishable from a normal single-party Schnorr signature. FROST (Flexible Round-Optimized Schnorr Threshold signatures) extends the same approach to t-of-n threshold signing, so any t of the n key shareholders suffice to produce a signature and the protocol tolerates up to n-t shares going offline or hostile without losing liveness. Both became usable on Bitcoin with the Taproot activation in November 2021; MuSig2 and FROST produce valid BIP 340 Schnorr signatures, and the resulting on-chain transactions are indistinguishable from single-signer spends. Chain analysis cannot distinguish a ten-of-ten MuSig2 transaction from a single-key transaction, nor a three-of-five FROST spend from either. The architecture delivers MPC's distributed-trust guarantee and Bitcoin's base-layer privacy in one construction, which is the combination the book's framework treats as the target for every privacy-preserving primitive.
Threshold signing is also the basis for several consumer-oriented wallet products that offer the user security properties stronger than single-key custody without the usability burden of multi-signature setups at the base-layer protocol. The protocols that enable these products rely on the same MPC primitives as the institutional products, adapted for the specific constraints of mobile devices and retail-user onboarding.^5^
The Structural Promise
MPC distributes trust across parties who do not trust one another, and the distributed trust produces a cryptographic guarantee that no single party can violate. This is a different guarantee from the one homomorphic encryption provides. Homomorphic encryption lets one party execute a computation on another party's private input. Multi-party computation lets several parties execute a computation on their own private inputs, with no party learning any other party's input. The two primitives solve complementary problems, and many real systems combine them.
Parties with private information can now cooperate on joint tasks that benefit from that information without pooling it in a central repository or extending trust to a shared intermediary. The cryptographic guarantee replaces a coordination cost that was previously priced into every such cooperation: the cost of establishing enough trust to share the inputs. When that cost falls, cooperation expands to cases that were previously uneconomic.
16.4 Trusted Execution Environments
Trusted execution environments (TEEs) take a different architectural path. Where cryptographic means prevent the computing party from seeing the inputs, a TEE prevents the computing party from seeing the inputs through hardware isolation instead. A region of memory inside the processor is marked as an enclave; code running inside the enclave can decrypt inputs, operate on them, and produce outputs, while code running outside the enclave (including the operating system, the hypervisor, and any other process on the machine) cannot observe the enclave's memory. An attestation mechanism allows a remote party to verify that a specific piece of software is running inside an authentic enclave on an authentic processor, giving the remote party confidence that the computation was performed as described.
The Platforms
Intel Software Guard Extensions (SGX) was the first mainstream TEE and remains the most widely deployed in server applications. SGX was deprecated on Intel's consumer processor line starting with the eleventh-generation Core products, in recognition of a series of side-channel attacks that made client-side SGX impractical. Its server variant, now called Scalable SGX, remains available on Xeon processors and continues to support cloud-scale applications. Intel Trust Domain Extensions (TDX) is the successor architecture, designed to address the side-channel vulnerabilities through a combination of hardware and software changes. AMD offers Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP), which provides enclave-like properties at the virtual-machine boundary. ARM TrustZone has been the primary mobile-device TEE for over a decade and underlies the biometric and payment-credential storage on hundreds of millions of devices. Apple's Secure Enclave is a hardened variant of ARM TrustZone that also handles device-local cryptographic operations.^6^
The Consumer-Scale Deployment
TEE architecture at consumer scale breaks into two deployment patterns. The first is the device-local enclave. ARM TrustZone on Android phones, Apple's Secure Enclave on iOS devices, and the TPM 2.0 specification on modern PCs together place a hardened execution environment inside hundreds of millions of consumer devices, where it holds biometric templates, payment-credential keys, disk-encryption keys, and attestation material. The device-local enclave is the oldest and most widely deployed consumer TEE pattern, and it is the least controversial because the user and the enclave are colocated in the same physical device under the same owner.
The second pattern is the remote attested enclave. A consumer device sends a request to a cloud-operated server whose hardware and software can be cryptographically attested and whose code is published for inspection. Each server's software is cryptographically measured, the measurement is published, and the device refuses to send a request to a server whose measurement does not match a published image. The servers are built to hold no persistent state beyond the request's lifetime, so that even a full compromise of a server at a later time yields no earlier request's inputs. The enterprise cloud tier has offered this architecture for several years through Google Cloud Confidential Computing, Microsoft Azure Confidential Computing, and AWS Nitro Enclaves, which expose attested-enclave primitives to business workloads built on AMD SEV-SNP, Intel TDX, and similar hardware. Signal's Private Contact Discovery uses an SGX-based enclave to let Signal clients look up which of their phone contacts use Signal without revealing the query to the Signal server. Apple Private Cloud Compute, introduced in June 2024 to serve workloads from Apple Intelligence that exceed on-device compute, is the most consumer-visible instance to date and is the deployment whose architecture has been published in the most detail. The category has been converging across vendors for several years; the Apple release made it legible to a mass consumer audience.
The architecture is worth describing in detail because it illustrates both the promise and the limit of TEE-based privacy. The promise is that a large-scale cloud service can be operated in a way that the service itself cannot observe user inputs, which is the same structural promise as homomorphic encryption but achieved through different means. Apple's design specifically targets the case where Apple itself is the adversary: an append-only transparency log records the cryptographic measurement of every production server image, the user's device refuses to encrypt requests to any node whose attestation does not match a logged measurement, and the signed binaries are published for independent researchers to reproduce. The residual trust is narrow but real: the silicon vendor's attestation root keys, the manufacturing supply chain that installs them, and the presence of independent monitors watching the transparency log for split views or suppressed entries. Side-channel attacks against the enclave's hardware isolation remain a separate risk class. Trust is reduced, not eliminated, and the user has traded trust in a provider's operational practices for trust in its hardware root and in the auditors watching its log.
Attested Inference: Frontier Models Without Disclosure
The remote-attested-enclave pattern has found a second application whose privacy stakes are higher than most of its early uses. Large language models have concentrated in the hands of a few operators because frontier-scale inference requires compute that individual users do not have. A prompt sent to a hosted model is a revealed preference handed to the operator in plaintext, and the default cloud architecture gives the operator full view of every request every customer makes. The surveillance consequences compound across professions (medical queries, legal drafts, source-protected journalism, negotiation strategy, personal correspondence) in a way base-layer communication surveillance does not, because a model prompt is often a condensed statement of what its author is thinking at that moment.
Two architectures have moved attested inference from proposal into production. Nvidia introduced confidential-computing support on H100 GPUs in 2023, reached general availability in April 2024, and extended the capability across H200 and Blackwell B200 with multi-GPU Protected PCIe in April 2025.^7^ The GPU establishes a hardware root of trust with a device-unique key burned in at manufacture, boots a measured firmware image, and carries on an attested SPDM session with a CPU TEE (AMD SEV-SNP or Intel TDX) that relays encrypted data in and out of the GPU. A relying party verifies the attestation chain through Nvidia's remote attestation service and sends prompts whose plaintext the GPU alone sees. Azure made this generally available for customers in September 2024 as NCC H100 v5 confidential VMs; Google Cloud shipped the equivalent on A3 Confidential instances. A set of third-party operators run consumer- and developer-facing inference services on this hardware. Tinfoil publishes device attestations on every request and binds model identity to the attestation; Edgeless Systems' Privatemode serves EU-hosted confidential inference on the same Azure substrate; Nillion's nilAI deploys open-weight models (Llama 3, DeepSeek, Gemma, GPT-OSS) inside attested GPUs. The open-weight frontier (Llama 3.3 70B, DeepSeek R1, Kimi K2, GPT-OSS 120B) now runs end-to-end inside attested enclaves at production scale.
The deployment that goes furthest integrates confidentiality with anonymity. Apple Private Cloud Compute combines the attested-enclave architecture described above with two orthogonal primitives lifted from anonymous-communication research. Every production request routes through an OHTTP relay (RFC 9458) operated by a third party that strips the client IP before the request reaches Apple's infrastructure, so the cloud side never sees the network origin of the request. Authorization uses RSA blind signatures (RFC 9474), a single-use credential that proves the request comes from a legitimate Apple device without identifying which device, so the cloud side never sees the user identity either. The combination means Apple's production side cannot read the prompt (confidentiality, from the TEE), cannot link two prompts to the same user (unlinkability, from the fresh blind credential per request), and cannot identify the user at all (anonymity, from the OHTTP strip). Target-diffusion routing prevents the load balancer from steering a specific user's traffic to a compromised node, because it has no user identifier to key on. The sovereign-host tier examined in Chapter 23 provides the same three guarantees by never leaving the user's hardware at all; PCC provides them at the cloud layer for workloads sovereign-host hardware cannot run.
The gap sits at the closed frontier. OpenAI, Anthropic, and Google ship contractual zero-retention tiers and tenant-isolated deployments, not hardware-attested inference. Microsoft's published collaboration with OpenAI on confidential Whisper inference (September 2024) is a validation exercise, not a general-availability product for the flagship models. The structural reason is that closed model weights become a policed asset once exposed to a customer-facing TEE boundary, and the operators have so far preferred contractual guarantees over architectural ones. Users who require an architectural guarantee today have two options: run open-weight inference inside an attested enclave (Tinfoil, Privatemode, or the same cloud primitives), or accept the lower-capability alternative of running the model locally on their own hardware. The closed frontier will either move to attested inference as customer demand accumulates or concede that segment of the market to the open-weight stack that already has.
TEE-based privacy is the primitive that scales the most easily today. Homomorphic encryption remains expensive for general computation. Multi-party computation requires at least two non-colluding parties, and organizing them is a social problem as much as a technical one. TEEs run at plaintext speeds on general-purpose workloads, and the cryptographic overhead is limited to attestation and to the isolation boundary. The primitive fits the cloud-service business model almost exactly.
The qualifier is that the trust reduction is not a trust elimination. Every TEE architecture depends on the integrity of the hardware, the attestation mechanism, and the software image against which attestation is verified. The history of side-channel attacks against SGX shows that hardware integrity is contested, not given; the recent examples of Spectre, Meltdown, and their variants show that the contested boundary extends across the entire processor design.^11^ The user who evaluates a TEE-based privacy claim must evaluate the specific hardware vendor's track record, the specific attestation architecture's design, and the specific software image published for verification. None of these evaluations is trivial, and none of them can be reduced to a single binary. TEEs are useful when the alternative is no privacy guarantee at all, and they are inferior when the alternative is a cryptographic primitive that does not require trusting hardware.
16.5 Private Information Retrieval
Private Information Retrieval (PIR) lets a client retrieve an item from a server's database without the server learning which item was retrieved. The query index is the private input; the item is the output. The server performs a computation over its entire database that depends cryptographically on the query but preserves no observable trace of which element the query selected.
The primitive comes in two families. Information-theoretic PIR replicates the database across multiple non-colluding servers; the client splits the query into shares and each server answers its share without learning the full query. Information-theoretic privacy holds as long as at least one server remains honest. Computational PIR operates with a single server and relies on cryptographic assumptions, typically additively homomorphic encryption or fully homomorphic encryption: the client sends an encrypted query vector, the server computes over its database in ciphertext, and the response ciphertext decrypts to the requested item without the server learning which index produced it. The cost is that every query must touch every record in the database, which is why computational PIR took two decades of engineering to become practical.
Practical deployments have arrived over the last five years. SealPIR, from Microsoft Research and Stanford in 2018, showed computational PIR over gigabyte-scale databases at single-query latencies of hundreds of milliseconds. SimplePIR and DoublePIR, introduced in 2022, cut the per-query cost by an order of magnitude through offline preprocessing, reaching throughput in the tens of gigabits per second and making PIR viable for high-volume services. Spiral, OnionPIR, and FrodoPIR occupy adjacent points in the design space. Signal's private contact discovery combines PIR-style queries with a trusted execution environment so the server has cryptographic assurance it cannot see which phone numbers a client is looking up.
The applications that matter for the book's framework are the ones in which the query is itself the information. Domain-name resolution is the canonical case: every DNS lookup tells the resolver which services a user is about to contact, which aggregates into an exhaustive record of online activity. Oblivious DNS over HTTPS (ODoH) mitigates this by splitting the query across an HTTP proxy and a DNS resolver, but a full PIR-based resolver would hide the query from both. Bitcoin light clients are the most directly relevant case for the book's argument. BIP 37 bloom filters leak which addresses a wallet cares about; BIP 158 compact block filters leak less but are more expensive in regards to bandwidth and computation. A PIR-based light client would let the wallet fetch transaction data without telling the serving node which addresses, UTXOs, or transactions it is watching. Lightning light-client flows reach Lightning Service Providers that observe every payment activity the client performs; PIR-aware routing queries would materially reduce that exposure. Certificate-revocation checks through OCSP reveal which TLS connections a browser is about to establish, and OCSP stapling partially masks this without eliminating it; a PIR-based revocation service would close the gap.
The structural promise is narrower than homomorphic encryption or MPC but sharply focused. PIR does not compute; it retrieves. What it adds to the book's stack is the ability to interact with remote databases in a way that does not leak the query. Every service the privacy architecture depends on is also a lookup surface, and every lookup surface is an observation channel unless the queries are themselves protected. PIR is the primitive that closes the query channel.^8^
16.6 Differential Privacy and the Aggregation Layer
Differential privacy is a statistical guarantee about aggregated data releases. Unlike the preceding primitives, it does not protect individual records during a computation; it protects the privacy of individuals whose records contribute to a released aggregate.
The Motivating Failure
The naive approach to sharing a dataset is to remove obvious identifiers (names, addresses, phone numbers) and publish what remains. This approach has failed repeatedly. In 1997, Latanya Sweeney re-identified the medical record of the Massachusetts governor from a "de-identified" state employee dataset by cross-referencing ZIP code, date of birth, and sex with publicly available voter rolls. In 2008, Arvind Narayanan and Vitaly Shmatikov re-identified a substantial fraction of users in the Netflix Prize dataset of 100 million movie ratings by cross-referencing with public IMDb reviews. The general pattern is the linkage attack: combine the released dataset with any auxiliary information the attacker has access to, and the combined information often suffices to re-identify individuals. No amount of column removal prevents this. The data itself encodes enough structure that uniqueness emerges even from coarse attributes.^9^
Differential privacy is the statistical response to the linkage attack. Instead of trying to remove identifying information from records, it changes what the release itself depends on. If the released aggregate would look the same whether any particular individual's record was included or not, then the released aggregate cannot be used to learn anything specific about that individual. The guarantee is a statement about the mechanism that produces the output, not about the output itself.
The Randomized-Response Intuition
Randomized response, introduced by Stanley Warner in 1965 for survey research, is the simplest case and makes the mechanism concrete. Suppose a researcher wants to know what fraction of respondents have engaged in some sensitive activity that no one will admit to openly. The researcher asks each respondent to flip a coin privately. On heads, the respondent answers the sensitive question truthfully. On tails, the respondent flips again: on heads they answer "yes" regardless, on tails they answer "no" regardless. Each respondent's answer gives the researcher some information, but nothing definitive: a "yes" could have come from the truthful-yes path or from the random-yes path, and only the respondent knows which. Plausible deniability is built into the protocol.
Yet in aggregate the researcher can recover the true rate. If the true fraction of yeses is p, the expected fraction of observed yeses is (1/2)p + 1/4: on the truthful half the real rate comes through, and on the random half a coin flip gives "yes" half the time. Solving for p gives p = 2(observed fraction − 1/4). The noise cancels in expectation; the individual deniability remains.
Randomized response is the prototype for every differentially private mechanism. Randomness at the individual level provides deniability; structure at the population level preserves utility. Real deployments generalize this tradeoff to arbitrary queries through a single privacy budget that bounds how much any one record can shift a released output and that composes additively across queries, so each release consumes part of the budget.
Central and Local Differential Privacy
Two architectures exist for where the noise is added. In central differential privacy, participants send their raw records to a trusted aggregator, the aggregator computes the true answer, and the aggregator adds noise before releasing the result. The user trusts the aggregator to handle the raw data correctly; the released aggregate is differentially private relative to external observers. The U.S. Census Bureau's TopDown Algorithm is a central-DP deployment: the Bureau receives raw census records, computes tabulations, and publishes noisy tabulations under a total privacy budget allocated across the many tables that make up the decennial release.
In local differential privacy, participants add noise to their own records before sending them anywhere. No trusted aggregator is required. The cost is that much more noise must be added, because each record's own noise is the only noise protecting that record; the per-record noise must be large enough that a single record reveals almost nothing, even though noise averages out in the aggregate. Apple's telemetry system uses local DP: iOS devices perturb individual usage records on-device before transmitting them, and Apple aggregates the perturbed records without ever seeing the raw ones. The tradeoff is stark. Local DP provides stronger privacy (no trusted aggregator) at substantial accuracy cost; central DP provides better accuracy at the cost of requiring a trusted aggregator.
What Differential Privacy Protects and Does Not Protect
DP protects against two broad categories of attack. The first is membership inference: an adversary trying to determine whether a specific individual is in the dataset. Under a properly calibrated privacy budget, the adversary's advantage over guessing is bounded and shrinks as the budget tightens. The second is attribute inference about any named individual: learning anything specific about one person that the adversary did not already know. The same budget bounds how much the adversary can learn there as well.
DP does not protect against population-level inferences that do not depend on any one individual. If the data establishes that everyone in a demographic group buys a particular product, DP-released statistics will still reveal that pattern, and any individual known to be in that group will be implicated by the population-level inference. This is the "secrecy of the sample" limitation: DP protects the contribution of each individual to the inference, not the inference itself. DP also does not protect raw data at rest. If the raw dataset is held somewhere in plain form, a breach of that storage is not mitigated by the fact that a DP-released tabulation is protected.
Deployments
The U.S. Census Bureau applied central differential privacy to the 2020 census redistricting data release through the TopDown Algorithm, allocating a total ε budget across the tables and publishing the noisy tabulations alongside the algorithm documentation so that statisticians can model the noise. Apple has used local differential privacy for aggregate telemetry (emoji usage, QuickType predictions, Safari crash reports) since iOS 10, with published per-type ε budgets. Google has used differential privacy for Chrome browser usage statistics, for the COVID-19 Community Mobility Reports,^13^ and for audience measurement in its advertising products, deploying central, local, and hybrid variants depending on the product.
Where It Fits
Differential privacy belongs in the book's framework as the protection that applies when the population as a whole is the object of analysis and any individual's record contributes only as a data point. It complements the primitives earlier in the chapter, because it does not protect the individual computation on a sensitive input. Many real systems need both guarantees at once: that individual computations do not leak their inputs, and that aggregate releases do not deanonymize the individuals behind them. The combination is the architecture of a privacy-preserving analytics system, and the analytics system is the category in which every mature deployment of these primitives must settle.
16.7 The Design Space and the Complements
Each primitive fits a distinct region of the design space. Homomorphic encryption suits the case where one party runs a workload on another's private inputs and the overhead is tolerable. Secure multi-party computation suits the case where several parties each hold private inputs and can be organized around a specified collusion model. A trusted execution environment suits the general-purpose workload where cryptographic overhead is unacceptable and the hardware trust model is acceptable. Private information retrieval suits remote database access in which the query index is itself the private input. Differential privacy is the guarantee that applies to population-level analysis; the contribution of any single record stays mathematically bounded.
The combinations matter as much as the individual primitives. Homomorphic encryption inside a trusted execution environment gives the hardware as a second defense against a broken scheme. Multi-party computation with participants running inside their own TEEs reduces the collusion surface to hardware. PIR over a TEE-hosted database combines query privacy with server-side integrity, which is the architecture Signal's private contact discovery uses. Zero-knowledge proofs attached to any of these primitives certify correctness without adding another execution copy. The frontier is the composition work that fits these primitives together for specific applications.
16.8 The Axiom of Resistance Applied to Compute
The book's Axiom of Resistance holds that a system's security is measured by the cost required to compromise it. Computing on secrets extends the measurement to the compute layer of the stack.
Homomorphic encryption's resistance surface is the set of cryptographic assumptions underlying the specific scheme in use. For lattice-based schemes, the assumption is learning-with-errors;^12^ for code-based schemes, it is the hardness of decoding random linear codes; for other constructions, other assumptions apply. The assumption set is standard in modern cryptography, and it is the same assumption set that underlies the post-quantum standards in Chapter 14. A break in a specific scheme would affect the deployed applications using that scheme but would not break the family, because alternative schemes under different assumptions exist.
Multi-party computation's resistance surface is the threshold model. The guarantee holds if and only if fewer than the threshold number of participants collude. The threshold must be chosen large enough that collusion is infeasible, and the participants must be chosen to have diverse incentives. The guarantee is a function of the social structure of the participant set, not only of the cryptographic construction.
Trusted execution environments have the largest resistance surface. Hardware vendor integrity, attestation mechanism correctness, side-channel resistance, and software-image verification are each separate assumptions, and the composed guarantee is the conjunction of all of them. A break in any single assumption compromises the whole. The empirical track record of TEEs includes multiple documented side-channel attacks, and the architectural response has been to rebuild the hardware where software patching was insufficient. The history shows both that the primitive is contestable and that the contesting process is active.
Differential privacy's resistance surface is the privacy budget and the composition of multiple releases over time. Each release consumes a portion of the budget, and sufficient releases deanonymize the population regardless of how tightly any individual release was set. The practical deployments track and limit the cumulative budget, which requires operational discipline beyond the initial algorithmic choice.
The axiom's logic applies to each family independently and to compositions. An attacker must compromise each primitive in the composition, and the compromise cost compounds. The defender's architectural choice is the selection of primitives whose compositions raise the compromise cost above the adversary's willingness to pay. Computing on secrets does not promise invulnerability. It promises that the cost curve of observation now bends upward at the execution layer, which is the layer the adversary had previously assumed was free.
Chapter Summary
Computing on secrets is the execution complement to zero-knowledge verification. Where zero-knowledge proves correctness of a computation whose inputs are private, computing-on-secrets performs computation on inputs that the executing party cannot see. The two primitives solve complementary problems, and real privacy-preserving systems combine them. Three architectural families cover the practical design space. Fully homomorphic encryption performs arithmetic on ciphertexts, breaking the assumption that a service running a computation must see the data the computation runs on; its overhead has fallen by four orders of magnitude since Gentry's 2009 breakthrough and continues to fall, though general-purpose computation remains out of reach. Secure multi-party computation distributes a computation across participants such that no party sees the whole input, with threshold signing as the most deployed production case, MuSig2 and FROST produce Schnorr signatures indistinguishable from single-sig spends on Bitcoin, and Fireblocks-class institutional custody runs threshold signing at scales that would otherwise require counterparty trust regulated institutions were not prepared to extend. Trusted execution environments run computation inside hardware enclaves whose contents are opaque to the hardware owner, with ARM TrustZone and Apple Secure Enclave on hundreds of millions of consumer devices and Apple Private Cloud Compute, Azure Confidential Computing, AWS Nitro Enclaves, and Google Cloud Confidential Computing carrying cloud-scale services.
Private information retrieval covers remote database access: every lookup surface is an observation channel unless queries are themselves protected, and PIR is the primitive that closes it. Signal's production deployment and the SealPIR and SimplePIR class of single-server implementations have made PIR practical where the query is itself the information. Differential privacy covers the aggregation layer, bounding through a single privacy budget how much an adversary can learn about any individual from a released statistic. Randomized response provides the intuition, calibrated noise provides the deployed construction, and the U.S. Census Bureau's TopDown Algorithm and Apple's local-DP telemetry are the largest deployed cases.
None of these primitives provides absolute guarantees. Homomorphic encryption relies on cryptographic assumptions that could fail, multi-party computation relies on threshold assumptions about collusion, trusted execution environments rely on hardware vendors whose integrity is contested, and differential privacy relies on budget discipline that can be exceeded. Maturity differs sharply by use case: homomorphic encryption's overhead rules out general-purpose computation, multi-party computation's organizational requirements limit its deployment, and trusted execution environments have a history of side-channel vulnerabilities that constrains which threat models they suit. The Axiom of Resistance extends to this layer. Each primitive has a specific resistance surface, and compositions compound the compromise cost. Computing on secrets does not promise invulnerability; it bends the observation cost curve upward at the execution layer, and that bending is the architectural basis on which the privacy-preserving applications of the next decade will be built. Implementation requires expertise in the specific scheme, protocol, or platform, which the reading recommendations point to.
Endnotes
^1^ Yao's 1982 paper founded secure computation; the epigraph paraphrases its orienting principle, not its exact language. Andrew Chi-Chih Yao, "Protocols for Secure Computations," Proceedings of the 23rd Annual Symposium on Foundations of Computer Science (1982): 160–164.
^2^ RSA's homomorphic multiplication property is implicit in the original paper: R. L. Rivest, A. Shamir, and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems," Communications of the ACM 21, no. 2 (1978): 120–126. The Paillier cryptosystem's additive homomorphism is the subject of Pascal Paillier, "Public-Key Cryptosystems Based on Composite Degree Residuosity Classes," EUROCRYPT 1999, Lecture Notes in Computer Science vol. 1592, pp. 223–238.
^3^ Gentry's 2009 dissertation proved fully homomorphic encryption was possible; fifteen years of engineering have cut its overhead by four orders of magnitude and still counting. Craig Gentry, "Fully Homomorphic Encryption Using Ideal Lattices," Proceedings of the 41st Annual ACM Symposium on Theory of Computing (2009): 169–178. Gentry's Stanford dissertation (2009) is the longer treatment. For the broader survey of the field as it stands, see Craig Gentry, "Computing Arbitrary Functions of Encrypted Data," Communications of the ACM 53, no. 3 (2010): 97–105, and Zvika Brakerski, "Fundamentals of Fully Homomorphic Encryption," in Providing Sound Foundations for Cryptography (ACM Books, 2019), which remains the best accessible overview.
^4^ BGV, BFV, CKKS, and TFHE are the four scheme families deployed in practice; OpenFHE, Microsoft SEAL, and Zama are the production-quality open-source implementations. OpenFHE, https://www.openfhe.org/. Microsoft SEAL, https://github.com/microsoft/SEAL. Zama (TFHE-rs, Concrete), https://www.zama.ai/, with source at https://github.com/zama-ai. On the CKKS scheme, Jung Hee Cheon, Andrey Kim, Miran Kim, and Yongsoo Song, "Homomorphic Encryption for Arithmetic of Approximate Numbers," ASIACRYPT 2017, is the originating paper. On TFHE and programmable bootstrapping, Ilaria Chillotti, Nicolas Gama, Mariya Georgieva, and Malika Izabachène, "TFHE: Fast Fully Homomorphic Encryption over the Torus," Journal of Cryptology 33, no. 1 (2020): 34–91.
^5^ Secret sharing (Shamir 1979) and garbled circuits (Yao 1986) are the foundational MPC primitives; Fireblocks runs threshold-signing MPC for roughly two thousand institutional custody customers; on Bitcoin, MuSig2 (BIP 327) aggregates n-of-n Schnorr signers into one signature and FROST extends the same construction to t-of-n, with both producing on-chain signatures indistinguishable from single-party spends. Adi Shamir, "How to Share a Secret," Communications of the ACM 22, no. 11 (1979): 612–613, on secret sharing. Andrew C. Yao, "How to Generate and Exchange Secrets," Proceedings of the 27th Annual Symposium on Foundations of Computer Science (1986): 162–167, on garbled circuits. Oded Goldreich, Foundations of Cryptography, Volume 2 (Cambridge, 2004), is the authoritative theoretical treatment, and David Evans, Vladimir Kolesnikov, and Mike Rosulek, A Pragmatic Introduction to Secure Multi-Party Computation (NOW Publishers, 2018), is the most accessible practitioner reference. Fireblocks, https://www.fireblocks.com/. On threshold signatures for Bitcoin and Ethereum, see Rosario Gennaro and Steven Goldfeder, "Fast Multiparty Threshold ECDSA with Fast Trustless Setup," ACM CCS 2018, which underlies much of the production tooling. MuSig2: Jonas Nick, Tim Ruffing, and Yannick Seurin, "MuSig2: Simple Two-Round Schnorr Multi-Signatures," CRYPTO 2021, https://eprint.iacr.org/2020/1261; specification at BIP 327, https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki; reference implementation in libsecp256k1, https://github.com/bitcoin-core/secp256k1. FROST: Chelsea Komlo and Ian Goldberg, "FROST: Flexible Round-Optimized Schnorr Threshold Signatures," SAC 2020, https://eprint.iacr.org/2020/852; IETF draft specification at https://datatracker.ietf.org/doc/draft-irtf-cfrg-frost/; production implementations at https://github.com/ZcashFoundation/frost (Zcash Foundation) and https://github.com/coinbase/kryptology (Coinbase). Taproot/Schnorr underlying activation: BIP 340, "Schnorr Signatures for secp256k1," https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki, and BIP 341 Taproot, https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki.
^6^ Intel SGX and TDX, AMD SEV-SNP, ARM TrustZone, and Apple's Secure Enclave are the deployed TEE platforms; Apple Private Cloud Compute (June 2024) is the clearest consumer-scale TEE architecture published in detail. Victor Costan and Srinivas Devadas, "Intel SGX Explained," IACR ePrint Archive 2016/086, is the canonical technical reference for SGX. Intel TDX documentation at https://www.intel.com/content/www/us/en/developer/tools/trust-domain-extensions/overview.html. AMD SEV-SNP white paper, David Kaplan, Jeremy Powell, and Tom Woller, "AMD Memory Encryption" (2021), https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf. ARM TrustZone overview at https://www.arm.com/technologies/trustzone-for-cortex-a. Apple Secure Enclave documentation at https://support.apple.com/guide/security/secure-enclave-sec59b0b31ff/web. Apple Private Cloud Compute architecture at https://security.apple.com/blog/private-cloud-compute/. Confidential Computing Consortium, https://confidentialcomputing.io/.
^7^ Nvidia confidential computing on Hopper and Blackwell GPUs for attested LLM inference. Gavin Uberti and Steven Hecht, "Confidential Computing on NVIDIA H100 GPUs for Secure and Trustworthy AI," Nvidia Developer Blog (August 3, 2023), https://developer.nvidia.com/blog/confidential-computing-on-h100-gpus-for-secure-and-trustworthy-ai/, is the technical introduction. General availability on H100 announced in "Announcing Confidential Computing General Access on NVIDIA H100 GPUs" (April 25, 2024), https://developer.nvidia.com/blog/announcing-confidential-computing-general-access-on-nvidia-h100-tensor-core-gpus/. Multi-GPU Protected PCIe general availability announced in "Announcing NVIDIA Secure AI General Availability" (April 23, 2025), https://developer.nvidia.com/blog/announcing-nvidia-secure-ai-general-availability/, covering HGX H100 and H200 eight-GPU configurations required for frontier-scale workloads. Azure NCC H100 v5 confidential VMs reached general availability in September 2024; see Microsoft Azure Confidential Computing blog, "General Availability: Azure Confidential VMs with NVIDIA H100 Tensor Core GPUs" (September 24, 2024), https://techcommunity.microsoft.com/blog/azureconfidentialcomputingblog/general-availability-azure-confidential-vms-with-nvidia-h100-tensor-core-gpus/4242644. Third-party attested-inference platforms include Tinfoil (https://tinfoil.sh, with technology documentation at https://tinfoil.sh/technology), Edgeless Systems Privatemode (https://www.privatemode.ai, built on the Continuum AI framework at https://www.edgeless.systems/products/continuum), and Nillion nilAI (https://nillion.com); each publishes attestation reports and serves open-weight models on Nvidia CC infrastructure. For the Apple Private Cloud Compute anonymity mechanisms referenced in the prose, the two relevant RFCs are Eric Kinnear et al., "Oblivious HTTP," RFC 9458 (January 2024), https://www.rfc-editor.org/rfc/rfc9458.html, and Frank Denis, Jonathan Hoyland, David Schinazi, and Christopher A. Wood, "RSA Blind Signatures," RFC 9474 (October 2023), https://www.rfc-editor.org/rfc/rfc9474.html. Apple's architecture ties them together in "Private Cloud Compute: A New Frontier for AI Privacy in the Cloud" (June 10, 2024), https://security.apple.com/blog/private-cloud-compute/. For the ongoing gap at closed frontier models, see Microsoft's September 2024 announcement of confidential Whisper inference with OpenAI at the Azure blog above, and OpenAI's enterprise Zero Data Retention documentation at https://platform.openai.com/docs/guides/your-data. As of early 2026, no flagship closed-frontier model (GPT-5, Claude 4.x, Gemini Ultra) ships a publicly announced generally available hardware-attested confidential inference product for customers.
^8^ Private Information Retrieval lets a client fetch an item from a server's database without the server learning which item; information-theoretic PIR needs multiple non-colluding servers, computational PIR runs on one server at the cost of cryptographic assumptions; SealPIR (2018), SimplePIR and DoublePIR (2022), and Signal's private contact discovery are the reference practical systems. Foundational PIR papers: Benny Chor, Oded Goldreich, Eyal Kushilevitz, and Madhu Sudan, "Private Information Retrieval," Journal of the ACM 45, no. 6 (1998): 965–981, on information-theoretic PIR; Eyal Kushilevitz and Rafail Ostrovsky, "Replication Is Not Needed: Single Database, Computationally-Private Information Retrieval," FOCS 1997, on computational PIR. SealPIR: Sebastian Angel, Hao Chen, Kim Laine, and Srinath Setty, "PIR with Compressed Queries and Amortized Query Processing," IEEE Symposium on Security and Privacy 2018, https://eprint.iacr.org/2017/1142, with implementation at https://github.com/microsoft/SealPIR. SimplePIR and DoublePIR: Alexandra Henzinger, Matthew M. Hong, Henry Corrigan-Gibbs, Sarah Meiklejohn, and Vinod Vaikuntanathan, "One Server for the Price of Two: Simple and Fast Single-Server Private Information Retrieval," USENIX Security 2023, https://eprint.iacr.org/2022/949. Spiral: Samir Jordan Menon and David J. Wu, "Spiral: Fast, High-Rate Single-Server PIR via FHE Composition," IEEE Symposium on Security and Privacy 2022. Signal's private contact discovery: Signal blog, "Technology preview: Private contact discovery for Signal," https://signal.org/blog/private-contact-discovery/, and the subsequent SGX-and-oblivious-operations architecture described at https://signal.org/blog/signal-private-group-system/. On Oblivious DNS over HTTPS (ODoH) as a weaker-than-PIR mitigation, see IETF RFC 9230, https://www.rfc-editor.org/rfc/rfc9230.html. On Bitcoin light-client query privacy, BIP 37 Bloom filter privacy analysis in Arthur Gervais et al., "On the Privacy Provisions of Bloom Filters in Lightweight Bitcoin Clients," ACSAC 2014; BIP 158 compact block filter specification at https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki; ongoing privacy analysis at https://bitcoinops.org/. On PIR-based light clients as a research direction, see the Ethereum Portal Network discussions and the "Vitalik on Ethereum light client privacy" thread at https://ethresear.ch/.
^10^ The BGV scheme's originating paper, which established the framework for leveled fully homomorphic encryption over integers using ring learning-with-errors: Zvika Brakerski, Craig Gentry, and Vinod Vaikuntanathan, "Fully Homomorphic Encryption without Bootstrapping," ITCS 2012, https://eprint.iacr.org/2011/277. The BFV variant that optimizes for integer arithmetic in practice: Junfeng Fan and Frederik Vercauteren, "Somewhat Practical Fully Homomorphic Encryption," IACR ePrint 2012/144, https://eprint.iacr.org/2012/144. These two papers are the theoretical foundation for the BGV/BFV library implementations cited in endnote 4; the libraries (Microsoft SEAL, OpenFHE) implement these schemes but the originating papers define the security reductions and parameter choices that determine practical security levels.
^11^ Spectre and Meltdown are the landmark 2018 CPU speculative-execution vulnerabilities that revealed the contested nature of processor-level isolation boundaries; their relevance to TEE security is that the same hardware features (branch prediction, out-of-order execution, cache hierarchy) that enable these attacks are present inside the TEE boundary and can be exploited from outside it. Paul Kocher et al., "Spectre Attacks: Exploiting Speculative Execution," IEEE Symposium on Security and Privacy (2019), https://spectreattack.com/spectre.pdf. Moritz Lipp et al., "Meltdown: Reading Kernel Memory from User Space," USENIX Security Symposium (2018), https://meltdownattack.com/meltdown.pdf. The dedicated SGX side-channel attack literature is extensive; representative papers include Jo Van Bulck et al., "Foreshadow: Extracting the Keys to the Intel SGX Kingdom with Transient Out-of-Order Execution," USENIX Security (2018), https://foreshadowattack.eu/, and Daniel Moghimi et al., "Downfall: Exploiting Speculative Data Gathering," USENIX Security (2023), https://downfall.page/. Intel's deprecation of client SGX and the architectural pivot to TDX is documented in Intel's product change notifications starting with 11th-generation Core processors.
^12^ The learning-with-errors (LWE) problem, introduced by Oded Regev in 2005, is the hardness assumption underlying BGV, BFV, CKKS, and the NIST post-quantum standards for key encapsulation and digital signatures; its ring variant (RLWE) is the assumption underlying most deployed FHE. Oded Regev, "On Lattices, Learning with Errors, Random Linear Codes, and Cryptography," STOC 2005, https://cims.nyu.edu/~regev/papers/qcrypto.pdf; journal version in Journal of the ACM 56, no. 6 (2009). Vadim Lyubashevsky, Chris Peikert, and Oded Regev, "On Ideal Lattices and Learning with Errors over Rings," EUROCRYPT 2010, https://eprint.iacr.org/2012/230, introduced the ring variant that all practical FHE schemes use. The NIST post-quantum standardization process selected LWE-based schemes (CRYSTALS-Kyber, CRYSTALS-Dilithium) as primary standards; see NIST IR 8413 (2022), https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8413.pdf.
^13^ Google's COVID-19 Community Mobility Reports used aggregated, differentially private location data drawn from Google Maps users to produce anonymized population-level mobility summaries during the pandemic; the methodology document describes the DP parameters applied. Google LLC, "COVID-19 Community Mobility Reports: Understand the Data," methodology documentation available at https://support.google.com/covid19-mobility/answer/9825414. Archived report data at https://www.google.com/covid19/mobility/. On Google's broader differential privacy infrastructure, see Miguel Guevara, "Helping public health officials combat COVID-19," Google Blog (April 3, 2020), and the open-source DP library at https://github.com/google/differential-privacy, which implements the mechanisms used across Chrome, Mobility Reports, and advertising measurement products.
^9^ Differential privacy guarantees aggregate releases cannot be used to deanonymize individual records within an ε budget; Warner's 1965 randomized response is the intuition, Dwork's mid-2000s formalization is the mathematical framework, and the 2020 U.S. Census, Apple telemetry (since iOS 10), and Google usage statistics are the largest deployed cases. Foundational formalization: Cynthia Dwork, Frank McSherry, Kobbi Nissim, and Adam Smith, "Calibrating Noise to Sensitivity in Private Data Analysis," TCC 2006, https://iacr.org/archive/tcc2006/38760266/38760266.pdf. Authoritative reference: Cynthia Dwork and Aaron Roth, The Algorithmic Foundations of Differential Privacy, Foundations and Trends in Theoretical Computer Science 9, nos. 3–4 (2014): 211–407, https://www.cis.upenn.edu/~aaroth/Papers/privacybook.pdf. Randomized response origin: Stanley L. Warner, "Randomized Response: A Survey Technique for Eliminating Evasive Answer Bias," Journal of the American Statistical Association 60, no. 309 (1965): 63–69. On the motivating failures: Latanya Sweeney, "Simple Demographics Often Identify People Uniquely," Carnegie Mellon University, Data Privacy Working Paper 3 (2000), https://dataprivacylab.org/projects/identifiability/, and Arvind Narayanan and Vitaly Shmatikov, "Robust De-anonymization of Large Sparse Datasets," IEEE Symposium on Security and Privacy 2008, https://www.cs.utexas.edu/~shmat/shmat_oak08netflix.pdf, the Netflix Prize de-anonymization paper. U.S. Census Bureau TopDown Algorithm documentation at https://www.census.gov/programs-surveys/decennial-census/decade/2020/planning-management/process/disclosure-avoidance.html. Apple's deployment documented in Differential Privacy Team, "Learning with Privacy at Scale," Apple Machine Learning Journal 1, no. 8 (2017), https://machinelearning.apple.com/research/learning-with-privacy-at-scale. Google's OpenDP library at https://github.com/google/differential-privacy. On theoretical tradeoffs: Salil Vadhan, "The Complexity of Differential Privacy," in Tutorials on the Foundations of Cryptography (Springer, 2017). For the "secrecy of the sample" limitation and the distinction between individual-level and population-level inference, Cynthia Dwork, "Differential Privacy: A Survey of Results," TAMC 2008, is the standard reference.
<- **Previous: Zero-Knowledge Proofs** |
-> Next: Anonymous Communication Networks |
The Praxeology of Privacy -- third edition. New chapters publish daily at 1600 UTC.