Cryptography

Hash functions

A deterministic function mapping arbitrary data to a fixed-size output, with three distinct security properties: preimage resistance, second preimage resistance, and collision resistance.

The input is processed through a compression function iteratively (Merkle-Damgard) or absorbed into a state (sponge). The output is a fixed-length digest.

The internal structure destroys invertibility. Finding an input that produces a given output requires work exponential in the output length, assuming no structural weakness.

The big idea

Collision resistance holds at the birthday bound, roughly 2^(n/2) for an n-bit hash. MD5 and SHA-1 are broken for collision resistance. SHA-256 and SHA-3 are not.

A short digest is often treated as a fingerprint, but different systems ask that fingerprint to resist different attacks. A hash function is the deterministic tool that produces the digest, and its security claims split into preimage, second-preimage, and collision resistance. The consequence is that choosing or judging a hash requires naming the adversary’s freedom. An attacker allowed to choose both inputs creates a different problem from one handed a fixed input to match.

• Preimage resistance. Given a hash output, finding any input producing it is infeasible.
• Second preimage resistance. Given a specific input, finding a different input with the same hash is infeasible.
• Collision resistance. Finding any two distinct inputs with the same hash is infeasible.

Collision resistance is the strongest of the three and implies the second, and a function can lose it while retaining the others, which is exactly what happened to SHA-1. A scheme where an attacker controls both inputs needs collision resistance; one where the input is fixed by someone else needs only the weaker properties.

Birthday bound

The birthday bound is why an $n$-bit hash gives only $n/2$ bits of collision security.

Finding a collision does not require checking each candidate against a specific target; it requires only that two of the candidates checked collide with each other, and among $k$ random values there are $\binom{k}{2}$ pairs. The expected number of trials before a collision is therefore about $2^{n/2}$ rather than $2^n$. A 128-bit hash gives collisions at around $2^{64}$, roughly $1.8 \times 10^{19}$ operations, which is within reach of a well-funded attacker. A 256-bit hash gives $2^{128}$, which is not. So 256 bits is the modern default when collision resistance is required.

SHA-2, SHA-3, and broken functions

SHA-2 (the family including SHA-256 and SHA-512) and SHA-3 are both in current use and neither has a practical break. They rest on different internal constructions, SHA-2 on a Merkle-Damgård chain and SHA-3 on a sponge, which is deliberate: a structural break against one is unlikely to transfer to the other.

MD5 and SHA-1 are dead for collision resistance. MD5 collisions have been producible in seconds since the mid-2000s. SHA-1 fell to a practical collision in 2017 and to a chosen-prefix collision in 2020.

Non-security uses only

MD5 and SHA-1 remain acceptable only as non-security checksums, and using either where an adversary can influence the input is a defect.

The distinction is the threat model rather than the algorithm. A hash used as a lookup key or as a checksum against accidental corruption never faces an adversary who chooses the colliding pair, so a broken collision property costs nothing in that role. The danger is promotion: a field added to catch bit rot becomes an identifier the system trusts, and once an attacker can supply one of the inputs, MD5 or SHA-1 hands them a forgery. For pure error detection a non-cryptographic hash such as CRC or xxHash is faster and states the intent honestly, and reaching for MD5 out of habit signals that the requirement was never named. Where the input can be attacker-chosen, the only safe default is a function with no known collision weakness, which today means SHA-256 or SHA-3.

Content addressing

Content addressing names an object by the hash of its contents, which gives several properties for free and is the standard way large datasets and model weights are managed. The name is a verifiable integrity check, so a corrupted or tampered download is detected on arrival. Identical content has an identical name regardless of where it came from, so deduplication happens automatically across sources. The name is stable and immutable, so a reference to a specific hash cannot silently change under a consumer, which is what makes a training corpus reproducible. Chaining those names so that each record commits to its predecessor is what makes an append-only ledger tamper-evident, the construction cryptocurrency builds on.

Chunked variants hash fixed or content-defined segments so that a large file that changes slightly shares most of its chunks with the previous version, which is how efficient synchronization of multi-terabyte checkpoints works. The near-duplicate detection on the data engineering page uses hashing for the opposite purpose: its MinHash signatures are built to collide with probability equal to set overlap.

Rolling checksums and rsync

A rolling checksum can be updated as a byte leaves its window and another enters, without rereading the whole window. The rsync algorithm uses this to find unchanged blocks when synchronizing two files: the receiver sends checksums of fixed-size blocks, and the sender tests consecutive byte offsets rather than only block boundaries. A one-byte insertion near the start therefore does not prevent later unchanged blocks from matching at shifted offsets.

The search first compares a weak 32-bit rolling checksum, then computes a strong hash only for candidate matches. A match on both lets the sender transmit a block reference instead of the block’s contents; unmatched bytes travel as literal data. After a match, the search skips to the end of the matched block. Tridgell and Mackerras’s original report used MD4 for the strong hash, a historical choice: RFC 6150 says MD4 is no longer appropriate where collision resistance is required.

Symmetric encryption

Encryption where sender and receiver share the same secret key, used for bulk data because it is fast, combined with authentication to detect tampering.

A block cipher encrypts fixed-size blocks under a key. A mode of operation chains blocks. Authentication produces a tag verified before decryption.

The cipher is a keyed permutation. Without the key, distinguishing ciphertext from random requires breaking the cipher. Authentication prevents malleability attacks.

The big idea

Data at rest and in transit. Requires a shared key, so it does not solve key exchange. Nonce reuse is catastrophic for counter-mode constructions.

A block cipher encrypts a fixed-size block, 128 bits for AES, under a key, and it is a permutation rather than a complete encryption scheme. Turning it into one requires a mode of operation that handles messages longer than a block.

Electronic codebook mode encrypts each block independently, which means identical plaintext blocks produce identical ciphertext blocks. The canonical demonstration is an image encrypted in this mode remaining visually recognizable. It is never acceptable, in any context.

Counter mode

Counter mode and its relatives fix this by encrypting a counter and combining the result with the plaintext, which makes the ciphertext depend on position and turns the block cipher into a stream cipher.

Encrypting the counter rather than the data is what buys the useful properties. Each block’s keystream depends only on the key and the counter, not on the previous ciphertext, so the blocks can be produced in parallel and any offset can be decrypted without touching the ones before it, which suits counter mode to random access into a large encrypted object. The mode also needs no padding, so the padding-oracle attacks that afflict block-chaining modes do not arise. That same independence carries a standing requirement, because a keystream fixed by the key and the counter is reused the instant a counter repeats under one key, which collapses confidentiality. Counter mode supplies no integrity by itself, so a usable scheme pairs it with authentication.

Authenticated encryption

Authenticated encryption combines confidentiality with integrity, and confidentiality alone is a vulnerability rather than a partial solution.

An attacker who can modify ciphertext without detection can often manipulate the plaintext in structured ways, since counter-mode encryption is a bitwise combination and flipping a ciphertext bit flips the corresponding plaintext bit. Worse, systems that decrypt and then react differently to malformed plaintext leak information through that difference (the padding oracle family of attacks). The correct construction produces a ciphertext plus an authentication tag, verifies the tag before doing anything with the plaintext, and rejects on failure. AES in Galois/Counter Mode and ChaCha20-Poly1305 are the two standard choices, and any design that encrypts without authenticating should be treated as broken.

Nonce reuse

Nonce reuse is the most common catastrophic implementation error in this area. Counter-mode constructions generate a keystream from the key and the nonce, so encrypting two messages with the same key and nonce produces two ciphertexts whose bitwise combination equals the combination of the plaintexts, which removes the key from the problem entirely. For Galois/Counter Mode it is worse: a single nonce reuse permits recovery of the authentication subkey, so an attacker can forge tags for any message under that key.

The failure arises from random nonce generation in a 96-bit space where the birthday bound makes collisions likely after enough messages, from counters that reset when a process restarts, and from copying a key to a second machine that maintains its own counter. The defenses are a nonce construction that cannot repeat, such as a per-key monotonic counter with durable state, or a nonce-misuse-resistant mode.

Encryption at rest

Encryption at rest and in transit for training corpora and checkpoints is standard practice, and its value depends on the threat model. At rest it protects against a stolen disk, a misconfigured storage bucket and an operator without key access, and it does not protect against an attacker who has compromised a process holding the key. In transit it protects against network interception, which within a datacenter is a modest threat and across the public internet is not. Key management is the hard part rather than the encryption. A key stored beside the data it protects provides nothing, and encryption at rest is frequently deployed as a compliance checkbox with the keys held by the same system that holds the data.

Public-key cryptography

Cryptography using a mathematically linked key pair where one key is public and the other private, enabling encryption to strangers and digital signatures.

RSA rests on the difficulty of factoring large semiprimes. Elliptic curve cryptography rests on the difficulty of discrete logarithms in elliptic curve groups.

The public key is derived from the private key by a one-way function. Reversing that derivation is believed to require solving a problem for which no efficient algorithm is known.

The big idea

Neither factoring nor discrete logarithm hardness is proven. Security holds under the assumption that these problems remain hard. A quantum computer running Shor's algorithm breaks both.

RSA rests on the difficulty of factoring a large integer that is the product of two primes, and elliptic curve cryptography rests on the difficulty of computing discrete logarithms in the group of points on an elliptic curve. Neither problem is proven hard; both are believed hard because they have resisted substantial effort.

A 3,072-bit RSA key and a 256-bit elliptic curve key offer comparable security. With the smaller key, elliptic curve operations are faster and keys and signatures far smaller.

Why elliptic curves

The key-size gap is why new systems use elliptic curves and why RSA persists mainly in legacy compatibility.

The gap in key size comes from the best known attack on each problem. The discrete logarithm on a well-chosen elliptic curve has no attack better than a generic one, whose cost is about the square root of the group size, so an $n$-bit curve gives roughly $n/2$ bits of security. Factoring has the number field sieve, which runs in sub-exponential time, so an RSA modulus has to be far larger to reach the same bar, and the gap widens as the security target rises. Smaller keys and signatures follow, along with faster key generation and signing, and these make elliptic curves the default for protocol handshakes and for constrained devices. RSA survives on inertia and on one real advantage, that verification with a small public exponent is cheap, so a certificate verified far more often than it is issued still leans on it. Both fall to Shor’s algorithm on a quantum computer, so the preference is a statement about classical adversaries only.

Key exchange and forward secrecy

Diffie-Hellman key agreement lets two parties compute a shared secret from exchanged public values and their own private exponents. In a deliberately insecure toy example, use prime $p = 47$ and base $g = 2$. Secrets $a = 5$ and $b = 9$ give public values $2^5 \bmod 47 = 32$ and $2^9 \bmod 47 = 42$. Each party raises the other’s public value to its own secret exponent, obtaining the same value: $42^5 \bmod 47 = 32^9 \bmod 47 = 24$. Agreement alone does not authenticate the peer. In a certificate-authenticated TLS 1.3 handshake, certificate validation and the CertificateVerify signature over the handshake authenticate the signing peer.

Forward secrecy means that a later compromise of a long-term key does not expose past session data. Ephemeral Diffie-Hellman provides it with fresh session secrets that are erased after use. TLS 1.3 removed static RSA and static Diffie-Hellman key exchange, but RFC 8446 specifies exceptions to forward secrecy: resumption using only a pre-shared key (PSK), without a fresh Diffie-Hellman exchange, loses it for application data. The 0-RTT early data sent before the handshake completes is also not forward secret, because its encryption keys depend only on the PSK.

Digital signatures

A digital signature proves that a message was produced by the holder of a private key and has not been modified, which is authenticity and integrity rather than confidentiality. The distinction is worth stating because the two are routinely confused. A signature is public: anyone with the public key can verify it, and the message itself is not concealed.

Encryption conceals content and says nothing about who produced it. Most real protocols need both and compose them, and the composition order matters, with sign-then-encrypt and encrypt-then-sign having different properties and different well-documented pitfalls. For model artifacts the application is signing weights and container images so a consumer can verify provenance, which addresses supply-chain tampering and not confidentiality.

Certificates and trust

Certificates bind a public key to an identity through a signature from an authority, and public key infrastructure is the system of authorities, intermediates, and validation rules built on that. The chain terminates in a root store, which is a list of authorities the software vendor has decided to trust, curated by browser and operating system vendors according to published but ultimately discretionary criteria. Every trust decision in the system reduces to that list.

Any authority in the store can issue a valid certificate for any name, so the security of the whole is that of its weakest member, and authorities have been compromised, coerced, and simply careless on multiple documented occasions. Certificate transparency logs mitigate this by making every issued certificate publicly auditable, so a fraudulent issuance is detectable after the fact, which is a real improvement and not the same as prevention.

Zero-knowledge proofs

A protocol where a prover convinces a verifier that a statement is true without revealing anything beyond that truth.

Interactive protocols use challenge-response rounds. Fiat-Shamir makes them non-interactive by hashing the transcript to derive challenges.

The verifier's view can be simulated without the prover's secret, so anything computable from the proof was already computable without it.

The big idea

Soundness holds computationally, not information-theoretically, for succinct constructions. Fiat-Shamir is secure in the random oracle model. SNARKs may require a trusted setup.

Three properties define a zero-knowledge proof, and each is separately necessary. Completeness means an honest prover convinces an honest verifier. Soundness means a cheating prover cannot establish a false statement. Zero-knowledge means the verifier learns nothing beyond the statement’s truth.

The zero-knowledge property is formalized by requiring that the verifier’s view can be simulated without access to the prover’s secret, so anything the verifier could compute after the interaction it could have computed before.

Fiat-Shamir and non-interactivity

Interactive proofs involve rounds of challenge and response, with the verifier’s random challenges preventing the prover from preparing answers in advance. The Fiat-Shamir transform makes these non-interactive by replacing the verifier’s random challenge with the hash of the transcript so far, on the reasoning that a prover cannot predict a hash output and therefore cannot prepare for it. This converts an interactive protocol into a single message that anyone can verify at any time, which is what makes the technology practical, and it is secure in the random oracle model rather than under standard assumptions.

Implementations of the Fiat-Shamir transform have been broken repeatedly by omitting part of the transcript from the hash, a class of bug common enough to have its own name in the literature.

SNARKs and STARKs

SNARKs and STARKs are the two dominant families, and they trade three quantities against each other. SNARKs produce very small proofs, on the order of a few hundred bytes, verifiable in milliseconds, and many constructions require a trusted setup that generates public parameters using randomness that must then be destroyed, since anyone retaining it can forge proofs. Multi-party ceremonies reduce that risk to requiring one honest participant. STARKs need no trusted setup and rest only on hash functions, which also makes them plausibly post-quantum secure, and their proofs are considerably larger, in the tens to hundreds of kilobytes. Both have prover costs orders of magnitude above simply performing the computation.

Verifiable inference

Verifiable inference is the application that matters here: proving that a specific model, identified by a commitment to its weights, produced a specific output for a specific input, without revealing the weights. This would let a provider demonstrate that it served the model it advertised rather than a cheaper one, let a regulator verify that a deployed system is the audited system, and let a user obtain a result from a private model with a guarantee about its provenance.

Prover cost is the binding constraint. Generating a proof of a computation costs several orders of magnitude more than performing it, with reported overheads commonly in the range of $10^3$ to $10^6$ depending on the construction.

Additional difficulty

The additional difficulty is that these systems work over finite fields while models use floating point arithmetic, so the computation must be rewritten in a form the proof system accepts. The honest position is that verifiable inference at frontier scale is a research direction rather than an available tool.

Homomorphic encryption

Encryption that permits computation on ciphertext, producing an encrypted result that decrypts to the function of the plaintexts.

Ciphertexts carry a noise term. Addition and multiplication on ciphertexts correspond to addition and multiplication on plaintexts. Bootstrapping resets noise by homomorphically evaluating decryption.

The algebraic structure of the ciphertext space mirrors that of the plaintext space, so operations compose. Noise growth is the price of that structure.

The big idea

Fully homomorphic encryption enables arbitrary computation but with 1000x to 1000000x overhead. Private inference at frontier model scale is a research direction, not a production tool.

Partially homomorphic schemes support one operation on ciphertexts, either addition or multiplication but not both, and they are old, fast, and useful within their limits. Somewhat homomorphic schemes support both for a bounded number of operations. Fully homomorphic schemes support arbitrary computation on encrypted data, which is the property that would permit sending an encrypted input to a service, having it compute, and receiving an encrypted result the service cannot read. That capability has existed since 2009 and the question has always been cost rather than possibility.

Noise and bootstrapping

Noise growth limits depth. Every ciphertext carries a noise term, and multiplication increases it far faster than addition. Past a threshold the noise overwhelms the message.

Bootstrapping resets the noise by homomorphically evaluating the scheme’s own decryption circuit on the ciphertext, producing a fresh encryption of the same value with low noise. It is what makes a scheme fully homomorphic and it is extremely expensive, since it requires evaluating a nontrivial circuit for every refresh. Aggregate overheads relative to plaintext computation are commonly reported in the range of $10^3$ to $10^6$, having improved by several orders of magnitude over fifteen years and remaining far from parity.

Private inference

The honest position on private inference is that it is possible in principle and not economic at frontier model scale. Demonstrations exist for small networks and for individual operations. The obstacles are cumulative: the overhead multiplies an already expensive computation, the non-linear operations that models depend on (softmax, normalization, activation functions) are the most expensive to evaluate homomorphically and often require polynomial approximations that change the model’s behavior, and the ciphertext expansion makes data movement substantial.

The techniques that are practical today are narrower, including encrypted database lookup, private set intersection and private information retrieval, and those are genuinely deployed. Anyone claiming production-scale private inference over a frontier model should be asked for the model size and the latency.

Secure multiparty computation

Protocols allowing several parties to jointly compute a function of their private inputs, revealing only the output to each party.

Secret sharing splits inputs so no party holds enough to reconstruct. Garbled circuits encrypt a Boolean circuit for evaluation by another party. Oblivious transfer lets a receiver choose one of several values without revealing the choice.

The computation is distributed so that each party's view is independent of the others' inputs, conditioned on the output. Simulation proves that no party learns more than necessary.

The big idea

Semi-honest security assumes honest protocol execution. Malicious security costs 10x to 100x more. Communication rounds, not local computation, are the usual bottleneck.

Sometimes the useful computation spans datasets that cannot be pooled: one party has its inputs, another has theirs, and neither is willing or allowed to reveal them. Secure multiparty computation attacks that shape of problem by replacing one trusted machine with a protocol among the parties. The price is that the guarantee depends on which adversary model was assumed, while the cost is dominated by communication rounds, so the local arithmetic is often the easy part.

Primitives

Three primitives underlie most constructions. Secret sharing splits a value into shares such that any sufficient subset reconstructs it and any smaller subset learns nothing, which permits parties to hold shares of an input and compute on them jointly, with addition free and multiplication requiring interaction. Garbled circuits let one party encrypt a Boolean circuit so that the other can evaluate it on their own input without learning anything about the circuit’s other inputs. Oblivious transfer lets a sender offer several values and a receiver obtain exactly one without the sender learning which or the receiver learning the others, and it is the primitive that makes garbled circuits work.

Adversary models

The adversary model is the largest cost lever. Moving from semi-honest to malicious security typically costs a factor of ten to a hundred in overhead.

A semi-honest adversary follows the protocol and tries to learn from what it sees. A malicious adversary deviates arbitrarily, sending wrong values, aborting selectively or manipulating the computation. Protecting against the second requires each step to be verified, typically through zero-knowledge proofs of correct behavior or through redundant computation with consistency checks.

Semi-honest assumptions

Many deployed systems assume semi-honest behavior because it is affordable and then describe themselves in language suggesting stronger guarantees.

A semi-honest guarantee holds only while every party runs the agreed code faithfully, a strange assumption to pair with a technology whose premise is that the parties do not trust each other. A participant willing to deviate can send malformed shares, choose inputs designed to reconstruct a peer’s value from the output, or abort the moment it has learned the result and before anyone else has. None of that breaks the semi-honest model, because the model assumed it away. The assumption is defensible when execution is pinned down by something outside the protocol, such as an attested enclave or an audited binary, and it is indefensible when the counterparties are the adversaries the protocol was chosen to defend against. A system that runs a semi-honest protocol and then advertises that no party can see another’s data has described the honest-execution case and sold it as the adversarial one.

Joint training

The application to joint training across organizations that cannot pool raw data is the one most often proposed. Several hospitals, banks, or firms hold complementary data, each is legally or commercially unable to share it, and a model trained on the union would be better than any trained on a part. Secure computation permits the training to proceed on secret-shared data with no party seeing another’s inputs.

The practical difficulty is that gradient computations are exactly the operations these protocols handle worst. Federated learning is the pragmatic alternative, keeping data local and exchanging model updates, which is far cheaper and offers a weaker guarantee since the updates themselves leak information about the data. It is usually combined with differential privacy for this reason.

Communication cost

Communication rather than computation is the usual bottleneck, and this is the most consistently misunderstood property of the field. The local arithmetic in these protocols is cheap. What costs is that a multiplication of secret-shared values requires a round of messages between parties. Rounds track multiplicative depth rather than multiplication count, so millions of multiplications that do not depend on each other batch into a single round, while a chain of a thousand each waiting on the last costs a thousand rounds no matter how few they are. Volume is what preprocessed correlated randomness buys down; depth is what it cannot. Round complexity interacts with network latency, so a protocol requiring a thousand sequential rounds across a wide-area link takes seconds regardless of how fast the parties compute.

Differential privacy

A mathematical guarantee bounding how much any single record can influence an output, formalized with multiplicative and additive limits on output distributions between neighboring datasets.

Noise calibrated to the query's sensitivity is added to the output. Laplace noise gives pure epsilon-DP. Gaussian noise gives approximate (epsilon, delta)-DP.

Noise limits how much the chance of any output event can change when a record is added or removed.

The big idea

The bound is per-query. Repeated queries compose and consume a finite budget. Epsilon around 1 is strong; epsilon around 10 is weak. Group privacy degrades linearly in group size.

Aggregate outputs can still expose one person when changing that person’s record shifts the answer enough to notice. Differential privacy treats that as the unit of privacy loss: compare the distribution of outputs with the record present and absent, then force those distributions to stay close. The consequence is a budgeted system rather than a one-time anonymization step, because every answered query spends part of the same guarantee.

$$\Pr[M(D) \in S] \le e^{\varepsilon} \Pr[M(D') \in S] + \delta$$

symbol	meaning
$M$	the randomized mechanism
$D, D'$	datasets differing in a single record
$S$	any set of outputs the observer might test for
$\varepsilon$	privacy loss parameter, smaller is stronger
$\delta$	additive slack allowed on the $\varepsilon$ bound, not a failure probability

For every output set $S$, $\delta$ is the extra probability mass allowed beyond the multiplicative $e^{\varepsilon}$ bound. It does not specify the probability that privacy protection fails. For a dataset of $n$ records, $\delta$ is usually chosen far below $1/n$.

What differential privacy does not promise

It does not prevent inference about an individual from population-level patterns, so a study establishing that a behavior predicts an outcome permits inference about anyone known to exhibit it, and that is the study working correctly rather than a privacy failure. It does not protect a group, since the guarantee is per-record and a correlated group of records loses protection proportional to its size.

$\varepsilon$ is not on an intuitive scale: values around 1 are strong, values around 10 are weak, and the guarantee at the $\varepsilon$ values many deployments actually use is closer to a gesture than a bound.

Mechanisms

The Laplace and Gaussian mechanisms add calibrated noise to a query result, and calibration is to sensitivity: the maximum change in the output when one record changes. The Laplace mechanism adds noise with scale $\Delta_1/\varepsilon$, where $\Delta_1$ is the $L_1$ sensitivity, and achieves pure $\varepsilon$-differential privacy with $\delta = 0$.

The Gaussian mechanism adds normal noise with standard deviation proportional to $\Delta_2/\varepsilon$, where $\Delta_2$ is the $L_2$ sensitivity, and achieves the relaxed guarantee with $\delta > 0$, preferred for high-dimensional outputs because $L_2$ sensitivity grows more slowly than $L_1$ as dimension increases.

Sensitivity in practice

Getting sensitivity right is where implementations fail. An unbounded query such as a sum over an unclipped numeric field has infinite sensitivity and no amount of noise makes it private.

Differentially private training

Differentially private stochastic gradient descent applies this to training. Each per-example gradient is clipped to a fixed norm, which bounds sensitivity, then noise is added to the summed gradient before the update. Per-example clipping is the expensive part, because the standard backward pass computes the gradient of the batch loss and never materializes per-example gradients.

The utility cost at practical privacy levels is substantial, and honest reporting of it is uneven. On large models with large batches the gap has narrowed but not closed, and the degradation concentrates on rare subpopulations, whose signal is composed of few individual contributions.

Budget accounting

Privacy budget accounting across repeated queries is where deployments quietly fail. The guarantee composes, so answering $k$ queries each at $\varepsilon$ costs at most $k\varepsilon$ under basic composition, and advanced composition gives tighter bounds of order $\sqrt{k \ln(1/\delta')}\,\varepsilon$ for small $\varepsilon$, at the price of an extra additive $\delta'$. Either way the budget is finite and it is consumed.

A system that applies a per-query $\varepsilon$ and serves an unbounded number of queries provides no meaningful guarantee, since an analyst can average away the noise by repetition.

Persistent ledger

Correct operation requires a persistent accountant that tracks cumulative expenditure per dataset and refuses queries once the budget is exhausted.

The accountant is hard to get right, because it has to be durable and shared and correctly keyed all at once, and most manage only one or two of the three. Durable means the running total outlives a restart, since a counter held in memory resets to zero on a crash and hands the next analyst a full budget. Shared means every path that can answer a query charges the same ledger, because a second replica keeping its own count doubles the true privacy loss while each half looks within budget. Correct keying means the spend is booked against the unit the guarantee protects, the dataset or the person, rather than a session that resets the instant a client reconnects. Miss any one and the mechanism keeps adding noise on every query while the guarantee it was meant to hold has already lapsed, a failure that passes review precisely because the noise is visible and the exhausted budget is not.

Trusted execution environments

Hardware-enforced isolation that protects code and data from the operator of the machine, using encrypted memory and remote attestation.

The processor encrypts memory leaving the chip with a hardware-held key. Remote attestation provides a signed statement of what code is running inside the enclave.

Software, including the OS and hypervisor, cannot read encrypted memory. Attestation lets a remote party verify the enclave before sending secrets.

The big idea

Addresses a compromised or untrusted infrastructure operator. Does not address bugs in the code inside the enclave. Side-channel attacks have broken TEE implementations repeatedly.

An enclave is a region of memory that the processor protects from everything outside it, including the operating system, the hypervisor and an attacker able to read the memory bus directly. Memory encryption is the mechanism: data leaving the processor package is encrypted with a key held in hardware and never exposed to software.

Remote attestation

Remote attestation is what makes it useful to a third party, providing a hardware-signed statement of exactly what code is running inside the enclave. A remote party verifies this against the vendor’s certificate chain before sending anything secret. The combination permits running a computation on infrastructure you do not control while the operator cannot read the data.

Confidential accelerators

Confidential computing on accelerators extends this to model workloads, which required hardware support since an enclave that cannot use a GPU is useless for anything model-sized. Current implementations encrypt accelerator memory, establish an encrypted channel between the host enclave and the device, and extend attestation to cover the device.

Performance cost is modest for large workloads: a 2024 benchmark of confidential computing on Hopper GPUs measured LLM inference overhead below 7 percent for typical queries, approaching zero for larger models and longer sequences, with the cost concentrated in encrypted CPU-GPU transfers.

Threat model

TEEs address a compromised or untrusted operator of the infrastructure, which is a real and common situation: running a proprietary model on a cloud provider, processing regulated data on shared hardware, or letting a customer run a workload against weights they must not extract.

A TEE does not address a vulnerability in the code inside the enclave, which retains full access to the data it is processing. Attestation proves what code is running, not that the code is trustworthy.

Side-channel history

Enclave technologies have been broken repeatedly by attacks that never violate the memory encryption: timing, cache occupancy, speculative execution, power draw and controlled page faults. Successive generations have been patched, mitigated, and broken again.

The correct posture is that these systems raise the cost of attack substantially and are not a guarantee against a well-resourced adversary with physical access and time.

Post-quantum cryptography

Cryptographic schemes designed to resist attack by both classical and quantum computers, replacing those that Shor's algorithm breaks.

Lattice-based schemes rely on difficult short-vector problems in lattices. Hash-based signatures rest only on hash function security. Hybrid deployment combines classical and post-quantum exchanges.

Shor's algorithm solves factoring and discrete logarithm in polynomial time on a quantum computer, breaking RSA and elliptic curve cryptography entirely. Symmetric schemes require only doubled key lengths.

The big idea

Data requiring confidentiality beyond the arrival of large-scale quantum computers. The harvest-now-decrypt-later threat makes migration urgent before such machines exist. Post-quantum assumptions are younger and less tested.

Encrypted traffic can be copied today and kept until the assumptions behind its public-key exchange fail. Post-quantum cryptography is the migration away from RSA and elliptic-curve schemes before that happens. The immediate consequence is uneven: symmetric encryption mostly changes key sizes, while key exchange and signatures need new assumptions, hybrid deployment, and caution about algorithms with less history behind them.

What quantum computers break

Shor’s algorithm breaks RSA and elliptic curve cryptography. Both reduce to the hidden subgroup problem over an abelian group, which a quantum computer solves in polynomial time.

Factoring and discrete logarithms both fall to it, so the entire public-key infrastructure in current use is affected, not a portion of it.

Grover against symmetric

Grover’s algorithm attacks symmetric schemes differently, giving a quadratic rather than exponential speedup on unstructured search, so it reduces the effective security of an $n$-bit key to $n/2$ bits. Counting Grover iterations alone, AES-128 drops to 64 bits of security and AES-256 to 128. Grover’s iterations are serial and parallelize poorly, so NIST expects AES-128 to remain secure for decades, and moving to AES-256 is the conservative margin rather than a requirement. The asymmetry is the practical headline: symmetric cryptography survives by doubling key sizes, and public-key cryptography needs replacing entirely.

Replacements

As of October 28, 2026, the finalized NIST post-quantum standards are FIPS 203 for ML-KEM key encapsulation, FIPS 204 for ML-DSA signatures, and FIPS 205 for SLH-DSA signatures. FIPS 206, the Falcon-derived FN-DSA signature standard, remains in development, and HQC, selected on March 11, 2025 as a backup code-based KEM, has not yet been published as a standard. The lattice-based family rests on the hardness of finding short vectors in high-dimensional lattices, and it supplies both the primary key encapsulation mechanism and a signature scheme, with performance close enough to current algorithms to be deployed without redesigning protocols.

The hash-based family builds signatures from hash functions alone, which gives the most conservative security argument available since it depends on no new mathematical assumption. HQC adds a different code-based assumption as a backup for key encapsulation rather than a replacement for ML-KEM.

Isogeny candidate broken

One prominent isogeny-based candidate was broken by a classical attack during the standardization process. These assumptions are younger and less tested than factoring.

Harvest now, decrypt later

Harvest now, decrypt later makes migration urgent well before any such machine exists, and this is the argument that drives the timelines rather than any prediction about quantum hardware. An adversary can record encrypted traffic today at low cost and decrypt it whenever the capability arrives.

Anything requiring confidentiality for a decade or more is already exposed: medical records, state secrets, long-lived commercial agreements and personal information.

Hybrid deployment

Hybrid deployment is how the transition is being run. A hybrid key exchange performs both a classical and a post-quantum exchange and combines the results, so the session is secure if either holds. This hedges against the new algorithms being broken and against implementation defects in code that is much newer than what it replaces.

Major browsers and servers have deployed hybrid key exchange by default, and Cloudflare reported in October 2025 that a majority of human-initiated traffic to its network already carried post-quantum protection for confidentiality. Signatures are further behind, since certificate chains involve more parties and larger signatures affect more of the ecosystem.