deuterium Himanshu Sheoran's blog on tech, security, CTFs and cryptography

Explore

Cryptography

A searchable map of cryptographic ideas, constructions, attacks, and papers.

Basic ideas and security definitions

Start with what a cryptographic system is supposed to protect. Learn how researchers describe an attacker, define success and argue that an attack should be difficult.

Basic computational primitives

Abstract interfaces and relationships among minimal computational primitives. Concrete designs and mathematical hardness problems have separate homes.

One-way functions and trapdoors

Average-case inversion hardness, one-way permutations, hard-core predicates, trapdoor inversion or preimage-sampling relations, and lossy trapdoor functions. A trapdoor sampler need not define a permutation.

GPV lattice trapdoors

GPV lattice trapdoors support preimage sampling using a short basis.

Papers

Pseudorandom functions

Keyed function indistinguishability, weak and related-key variants, and generic PRF constructions. Oblivious, threshold and constrained evaluation have separate functional homes.

Farasha

Farasha is a permutation-based construction of a parallelizable pseudorandom function.

Papers

Pseudorandom functions

A pseudorandom function is a deterministic keyed function whose answers look like those of a randomly chosen function to an efficient observer who does not know the key.

Why it is useful

It provides a precise way to require random-looking outputs across many chosen inputs, which is useful for authentication and key derivation.

How it works

  1. Choose and hide a random key.
  2. Allow the observer to request function values on inputs of its choice.
  3. Compare those answers with a random function that remembers its earlier answers.
  4. Require that the observer cannot reliably distinguish the two experiments.

What to watch for

A repeated input has the same output in both experiments. Pseudorandomness does not mean fresh independent randomness on every call, and security depends on the key distribution, query limits and computational assumptions.

Papers

SipHash

SipHash is an ARX pseudorandom-function family used for message authentication and keyed table hashing.

Papers

Statistically injective pseudorandom functions

A statistically injective pseudorandom-function family is injective for all but a small probability of key choices. For a good key, distinct inputs never share an output, while the secret-key function retains the required pseudorandomness.

Why it is useful

The deniable-encryption proof needs unique decoding of some internal encodings, not just the absence of efficiently findable collisions.

How it works

  1. Choose domain and output lengths that permit an injective function.
  2. Generate a key from a family with a bounded probability of non-injectivity.
  3. Use the uniqueness of outputs where the construction requires it.
  4. Keep the injectivity condition distinct from computational collision resistance.

What to watch for

An ordinary pseudorandom function does not automatically provide this global property. The paper's construction uses additional hash-family properties and a sufficiently large output space.

Papers

Pseudorandom generators

Computational expansion of short seeds, next-bit unpredictability and generator constructions. Entropy acquisition and deployed DRBG state management are separate topics.

Sparse pseudorandom-generator images

A generator can stretch a short seed into a longer string that looks random to efficient observers even though its possible outputs occupy only a small fraction of the larger space.

Why it is useful

A proof can replace a generator output with a random string that is probably outside the generator's image, making a chosen program input unreachable.

How it works

  1. Count the possible seeds and the larger output space.
  2. Use generator security to justify replacing an output with a uniform string in a proof experiment.
  3. Bound the probability that the new string lies in the generator's image.
  4. Use the outside-image event to establish program equivalence where required.

Example

A generator with n-bit seeds and 2n-bit outputs reaches at most a 2^(-n) fraction of its output space.

What to watch for

Computational indistinguishability is not statistical closeness. A uniform string is usually outside the image even though an efficient observer cannot reliably recognize that fact.

Papers

Pseudorandom permutations

Keyed permutation security, forward/inverse oracle access, PRP/PRF switching and generic constructions. Block-cipher instantiations illustrate the interface, not proven security.

Cryptographic permutation p

A b-bit permutation p in Perm(b) used as the underlying primitive in duplex-based AE modes. Treated as a random permutation in the security analysis and attacked via permutation queries.

Papers

Random function F_beta

The function F_beta(x) = floor(p(beta||x))_c, which behaves like a random function for fixed beta and random permutation p. Central to the Gilbert et al. attack's offline phase for finding large components and small cycles.

Papers

Entropy, extraction and noisy secrets

Entropy measures, statistical distance, seeded and seedless extractors, secure sketches and fuzzy extractors. Definitions and existence results live here; randomness production is linked separately.

Computational entropy in shared secrets

A value may be mathematically determined by public data yet remain computationally hidden. Computational entropy describes this by comparing the real source with an indistinguishable source that has genuine conditional entropy.

Why it is useful

It explains why a Diffie-Hellman shared value can be useful as secret key material even though an unlimited attacker could derive it from the public exchange.

How it works

  1. Include the public exchange in the source's side information.
  2. State the computational assumption under which the shared value resembles a high-entropy source.
  3. Apply an extractor justified for that source model.
  4. Keep statistical entropy and computational secrecy separate in the argument.

What to watch for

Hardness of computing the whole value does not by itself prove that its encoding is indistinguishable from a random key. CDH and DDH provide different guarantees, and some protocols require a different extraction argument.

Papers

Computational randomness extractors

A computational extractor produces output that feasible attackers cannot distinguish from uniform, even if an unlimited observer could distinguish it.

Why it is useful

This weaker requirement can fit cryptographic sources and output lengths that do not support a strong statistical extraction guarantee.

How it works

  1. Specify the source and the attacker's side information.
  2. Choose the extractor and its seed according to the required assumptions.
  3. Compare the real output with a uniform string in a bounded-computation experiment.
  4. Account for the extractor's distinguishing loss when using its output as a key.

What to watch for

Computational security is not statistical closeness. The input still needs an appropriate entropy or hardness property, and a real hash function does not automatically satisfy every idealized extraction claim.

Related ideas

Papers

Entropy conditioned on side information

The entropy relevant to key derivation is the uncertainty left after accounting for what the attacker knows. The paper models a source as a pair: secret material and accompanying information visible to the attacker.

Why it is useful

A source can look highly variable in isolation but offer no secrecy once its relation to public observations is considered.

How it works

  1. Specify how the source is sampled.
  2. List the public observations and leaked information available to the attacker.
  3. Measure or assume the remaining uncertainty under those observations.
  4. Choose an extraction claim that matches this conditional source model.

Example

A 128-bit value chosen uniformly has 128 bits of entropy before disclosure. If the attacker receives the whole value, the remaining conditional entropy is zero.

What to watch for

This paper mostly uses a worst-case conditional min-entropy requirement, with a qualification for rare bad observations. It is not a measurement procedure for a physical device, and repeated correlated samples do not automatically add their individual entropy estimates.

Useful background: Min-entropy.

Papers

Extracting pseudorandom functions

An extracting pseudorandom function combines a keyed pseudorandomness property with extraction from a sufficiently unpredictable input. Its extraction guarantee keeps the output close to uniform even when the independently sampled key is included in the observer's view.

Why it is useful

The encryption proof sometimes needs good randomness from a hidden high-entropy input without treating the extraction key as secret.

How it works

  1. Specify the minimum input entropy and desired output length.
  2. Sample the key independently of that input distribution.
  3. Apply a family with the stated extraction guarantee.
  4. Account for the statistical error and any exceptional key choices.

What to watch for

A secret-key pseudorandomness claim alone is not this extraction property. The entropy bound and independence conditions cannot be dropped.

Related ideas

  • Min-entropy: Quantifies the input uncertainty needed for extraction.

Papers

Min-entropy

Min-entropy measures how predictable the most likely outcome of a random source is. It is minus the base-two logarithm of the largest outcome probability.

Why it is useful

A source can have many possible outputs yet be dominated by one very common value. Min-entropy captures that worst-case guessing probability.

How it works

  1. Identify the probability of the most likely outcome.
  2. Take its negative base-two logarithm.
  3. For a history-dependent source, check the conditional distributions required by the construction.

Example

If the most likely outcome has probability one quarter, the min-entropy is two bits.

What to watch for

A large output length does not imply large min-entropy. Side information and conditioning can change the relevant guessing probability.

Papers

Privacy Amplification

Privacy amplification compresses shared data about which an observer has partial information into a shorter key that is close to uniform even given that information.

Why it is useful

Agreement on a bit string is not enough for a secret key. An observer may know something about the raw data or the reconciliation messages.

How it works

  1. Bound the uncertainty remaining after all relevant leakage.
  2. Select a suitable randomized hash function as specified by the security argument.
  3. Communicate its description authentically; it need not be secret.
  4. Hash to an output length allowed by the uncertainty bound and desired failure probability.

What to watch for

For quantum key distribution the bound must handle quantum side information. Hashing to an arbitrary length, or merely using a cryptographic hash, does not establish this guarantee.

Related ideas

Papers

Strong seeded randomness extractors

A strong seeded extractor combines a source with enough min-entropy and an independent random seed to produce an output close to uniform even when the seed is public.

Why it is useful

It can turn biased but sufficiently unpredictable data into usable randomness without requiring the seed itself to remain secret.

How it works

  1. Establish a min-entropy bound for the source under the relevant side information.
  2. Choose an independent random seed from the extractor's specified seed space.
  3. Apply the seed-selected function to the source sample.
  4. Bound the distance between the joint seed-output distribution and a public seed paired with uniform output.

What to watch for

The guarantee averages over the seed choice; it does not certify every fixed seed for every source. Generic statistical extraction also needs an entropy margin beyond the output length.

Useful background: Min-entropy, Entropy conditioned on side information.

Related ideas

  • Privacy Amplification: Uses related extraction ideas to remove an adversary's partial knowledge. Quantum side information needs a suitable additional security analysis.

Papers

Information-theoretic cryptography

Secrecy and authenticity without computational hardness, with explicit key, channel, storage or noise resources. Quantum communication primitives belong under quantum.

Perfect and statistical secrecy

Perfect and approximate secrecy, secrecy capacity, wiretap coding and privacy amplification for secret-key agreement. Physical-channel assumptions are distinct from computational ones.

One-Time Pad

Information-theoretically secure encryption scheme used as the primary method for encrypting messages with QKD-generated keys; requires key as long as the message.

Papers

Unconditional authentication

Authentication codes, universal-hash authentication and information-theoretic key-consumption bounds. Reusing an authentication key requires a separate analysis.

Reductions, composition and feasibility

Proof relationships between assumptions, primitive definitions and composed protocols. This branch organizes theory; proof tooling and cryptanalytic practice belong under analysis.

Complexity, separations and impossibility

Average-case hardness, minimal assumptions, black-box separations, lower bounds and impossibility results for cryptographic tasks. Arithmetic problem algorithms remain under mathematics.

Attack-wise online complexity (sigma_tilde_D)

An adversarial online complexity metric used by Gilbert et al. that counts every permutation call made by each decryption query. For the attack, this gives sigma_tilde_D = 2^(3c/4), treating repeated paths as separate evaluations.

Papers

Composable security

Sequential, parallel, concurrent and universal composition, joint state and shared setup. Session and identity binding belong in the composed functionality.

Reduction techniques and concrete bounds

Hybrid arguments, game hopping, rewinding, straight-line simulation, tightness and security amplification. Reductions must state resource costs and security loss.

Concrete losses in a security reduction

A security reduction relates an attacker against a construction to an attacker against a component, with explicit changes in running time, queries and success probability.

Why it is useful

Those losses determine how much numerical security the proof actually supports, rather than merely whether an asymptotic theorem exists.

How it works

  1. State the attacker's query counts and message-length bounds.
  2. Track how many component operations the reduction performs.
  3. Include collision terms and multiplicative probability losses.
  4. Check that the assumed component-security estimate matches the reduction's computational model.

What to watch for

A tighter non-black-box reduction need not give a better concrete conclusion under the same guessed component bound. This retained revision corrects earlier optimistic estimates involving hardwired advice and time-memory tradeoffs.

Papers

Concrete losses in signature security reductions

A security proof for a signature scheme is a recipe that converts any successful forger into an algorithm that solves a hard problem, such as factoring. The concrete loss is the exact price the recipe charges: how much slower the new algorithm runs, how much smaller its success probability becomes, and how these change with the number of hash and signature queries the forger may make.

Why it is useful

Asymptotic proofs only say that no efficient forger exists once the keys are large enough. To pick an actual key length you need numbers, and the loss factors decide how much extra key length the proof forces on you.

How it works

  1. Write down the forger resources exactly: running time, signature queries, hash queries, and success probability.
  2. Build the solver that runs the forger inside it, and count every extra step and every repeated run it needs.
  3. Compare the solver time and success probability with the assumed hardness of the underlying problem.
  4. Read off the loss factors, for example a factor equal to the number of hash queries, and enlarge the keys until the loss is affordable.

Example

The paper illustrates with factoring: if forging is never more than 100 times easier than factoring integers of a given length, choose the length so that even one percent of the factoring work is already infeasible.

What to watch for

The paper is careful that "tight" and "loose" are comparative, imprecise words, not measurements. A loose reduction does not by itself make a scheme worse, because a faster scheme can spend its speed on longer keys.

Useful background: Exact security of digital signatures.

Related ideas

Papers

Exact security of digital signatures

Exact security, also called concrete security, states the security of a signature scheme as numbers instead of asymptotic claims. A scheme is called (t, qsig, qhash, epsilon, delta)-secure when no forger that runs for time t, asks at most qsig signature queries and qhash hash queries, and succeeds with probability epsilon on keys that arise with share delta, can produce a fresh valid signature.

Why it is useful

Classical proofs say a polynomial-time forger exists only for sufficiently large security parameters. That wording gives no answer to the practical question of which key size resists adversaries with specific, concrete abilities.

How it works

  1. Fix the attack game: the forger receives the public key, a signing oracle, and a hash oracle that is modeled as a truly random function.
  2. Count the forger resources as explicit bounds on time and on each kind of query.
  3. Split the success probability into two shares: how well the forger does for a fixed key, and how often key generation produces such a workable key.
  4. Declare the scheme secure at those numbers when no forger meeting the bounds exists.

What to watch for

The statement lives inside a proof model, here with hash functions treated as random oracles and with an assumed hardness estimate for the underlying problem. It is not a measurement of any real attack.

Useful background: Random oracle model.

Papers

Forking lemma

A proof technique for signatures derived from identification schemes. Run the forger once and note which hash query its forgery was based on. Then rewind the forger to just before that query and answer the same query differently. If it forges again using the same commitment, the two different answers to one commitment break the underlying problem.

Why it is useful

These signature schemes are secure exactly because answering two different challenges for a single commitment requires the secret key. Forking manufactures such a double answer out of a forger that only ever produced single signatures.

How it works

  1. Answer signature queries by choosing the response first and programming the hash table accordingly, so no secret key is ever needed.
  2. Run the forger once; any forgery it outputs must rest on some hash query it made.
  3. Rewind to the moment just before that query and give it a fresh, different answer.
  4. If the forger forges again on the same commitment, combine the two signatures; for the factoring scheme analyzed in the paper, this combination is a greatest common divisor computation that splits the modulus.

What to watch for

The second forgery must land on the same hash query, and the forger has as many queries to choose among, so the success probability drops by roughly that count. The paper states plainly that no proof exists showing this loss is necessary.

Useful background: Fiat-Shamir-like signature schemes.

Related ideas

Papers

Heavy row lemma

A probability fact used when a proof replays an attacker. If an experiment succeeds with probability alpha overall, then, given that it succeeded, the chance is at least one half that the circumstances of that run were ones where the experiment succeeds with probability at least alpha over two.

Why it is useful

Replaying a forger is the heart of proofs for signatures built from identification schemes, but the replays all see the same public key, so they cannot be treated as independent trials. The lemma keeps the analysis valid anyway.

How it works

  1. Split the probability space into rows, one for each combination of the public key and the random choices.
  2. Rows that individually succeed with probability below alpha over two cannot together account for more than half of the total success probability alpha.
  3. So at least half of all successes come from rows that succeed with probability at least alpha over two.
  4. After a first success, the row is therefore a decent one with probability at least one half, and a replay on that same row still succeeds with comparable probability.

What to watch for

Earlier concrete analyses by Ohta and Okamoto and by Pointcheval and Stern treated repeated runs of the forger as fully independent, which is wrong precisely because the public key never changes. Repairing this forces the security definition to track the key-selection share separately, which is what the delta in the definition is for.

Useful background: Exact security of digital signatures.

Related ideas

  • Forking lemma: Used to justify replaying the forger a second time on a workable key.

Papers

Hybrid arguments

A hybrid argument compares two complicated experiments through a sequence of small changes. If an attacker can distinguish the endpoints, it must be able to distinguish at least one adjacent pair.

Why it is useful

This is a way to turn an attack on a whole protocol into an attack on one of its underlying cryptographic components.

How it works

  1. Describe the original experiment and the experiment you want to compare it with.
  2. Change one component at a time to create intermediate experiments.
  3. Show that distinguishing an adjacent pair would violate an assumed security property.
  4. Account for how the number of steps affects the final bound.

Example

For private retrieval, change the encrypted selector for one requested position into the selector for another. The change can be reduced to distinguishing an encryption of 0 from an encryption of 1.

What to watch for

Every intermediate change needs justification. It is not enough to say that the two complete protocols look similar.

Papers

When loose security beats tight security

A comparison principle for choosing among signature schemes: judge by the security actually delivered per unit of cost, not by how tight the proof is. A scheme with a loose reduction but fast signing can use longer keys and still deliver more provable security for the same work.

Why it is useful

Tightness is a property of a proof, not of the deployed system. What matters is how hard attacking the chosen parameters is, compared with what signing and verifying cost at those parameters.

How it works

  1. Fix the cost that matters for the application; the paper uses the on-line part of signing.
  2. For each scheme, find the key sizes that make the costs equal, using its exact security formula.
  3. Compare the resulting provable security, which for these factoring-based schemes is the hardness of factoring the corresponding modulus.
  4. Locate the cross-over point where the schemes tie; on one side of it one scheme wins, and the gap grows from there.

Example

With the paper estimates, a loosely secure scheme using 6109-bit moduli matches a tightly secure variant using 1954-bit moduli in both signing speed and provable security; past that point the loose scheme pulls ahead.

What to watch for

The conclusion depends on the assumed cost of factoring and on counting only the chosen cost component. The paper also notes that its loosely secure scheme may be even more secure than proven, but that this cannot be shown with the available proof.

Useful background: Concrete losses in signature security reductions, Choosing adversary query bounds.

Papers

Security definitions and adversary interfaces

Game-based and simulation-based definitions, correctness, indistinguishability, unforgeability and resource bounds. Primitive-specific definitions remain with their functions.

Authentication Security

Assumption that authentication is secure, preventing man-in-the-middle attacks; a key concern in evaluating QKD security.

Papers

Chosen-ciphertext confidentiality for symmetric encryption

Chosen-ciphertext confidentiality adds access to a decryption oracle: an attacker may submit other ciphertexts while trying to distinguish the encrypted challenge messages.

Why it is useful

It models a receiver that processes attacker-controlled ciphertexts and may reveal its decryption results.

How it works

  1. Provide the chosen-plaintext challenge interface.
  2. Also provide the scheme's decryption result for allowed attacker-submitted ciphertexts.
  3. Exclude ciphertexts already returned by the challenge interface.
  4. Require the hidden message choice to remain indistinguishable.

What to watch for

This is a confidentiality property. It need not prevent accepted ciphertexts for unrelated known messages, and the ideal oracle does not capture every timing, error-message or implementation side channel.

Related ideas

Papers

Chosen-plaintext confidentiality for symmetric encryption

Chosen-plaintext confidentiality asks whether an attacker can distinguish encryptions of two chosen messages of the same length, even after obtaining other encryptions under the same secret key.

Why it is useful

It tests whether encryption hides message contents when the attacker can influence what gets encrypted.

How it works

  1. Choose a secret key and a hidden challenge bit.
  2. Let the attacker submit pairs of equal-length messages.
  3. Encrypt the message selected by the same hidden bit using the scheme's required randomness or state.
  4. Ask the attacker to guess the bit.

What to watch for

Equal-length challenges allow message length to remain visible. This confidentiality game gives no decryption oracle and does not establish integrity, replay protection or correct handling of reused nonces.

Papers

One-more oracle assumptions

A one-more assumption says that access to a limited number of difficult-operation evaluations should not let an attacker solve more independent challenge instances than that allowance.

Why it is useful

Blind evaluation protocols deliberately give clients some useful secret-key operations. Ordinary hardness without such access does not express the security question they need.

How it works

  1. Specify a challenge distribution, such as random RSA inputs or random group elements.
  2. Give the attacker the permitted public information and a bounded evaluation oracle.
  3. Count distinct challenge solutions rather than repeated answers.
  4. Require it to be infeasible to return more solutions than the allowed number of evaluation queries.

What to watch for

Oracle budgets are part of the assumption. One-more RSA, one-more Diffie-Hellman and gap variants supply different interfaces. In this paper, an extra DH query in one reduction remains unresolved; it cannot be ignored when comparing the reduction with the stated assumption.

Related ideas

Papers

Related-key assumptions in the HMAC proof

The two internal HMAC keys come from XORing one key with two fixed pads. The proof therefore needs a narrowly specified related-key property, rather than pretending that these key blocks were sampled independently.

Why it is useful

It makes explicit the extra step connecting the independent-key NMAC theorem to ordinary single-key HMAC.

How it works

  1. Treat the compression function's data block as the key for this part of the proof.
  2. Evaluate it at the fixed public initial vector under the two pad-derived keys.
  3. Require this pair of derived chaining states to behave like independent random states in the reduction.
  4. Then apply the NMAC theorem under the resulting internal keys.

What to watch for

Security when keyed through the chaining input and security when keyed through the data input are different assumptions. The required related-key family has just two fixed XOR transformations; this is not a claim of resistance to arbitrary related-key attacks.

Papers

Strong signature unforgeability

Strong unforgeability prevents an attacker from producing any new valid message-signature pair after obtaining signatures of its choice. This includes a new signature on a message that was already signed.

Why it is useful

Some applications care about controlling accepted signatures themselves, rather than only preventing signatures on new messages.

How it works

  1. Give the attacker a signing oracle.
  2. Record every message-signature pair the oracle returns.
  3. Let the attacker submit a candidate pair.
  4. Count success if the pair verifies and is absent from that record.

What to watch for

This is stronger than ordinary existential unforgeability. It does not prevent replaying an already issued pair, and does not by itself provide credential privacy.

Papers

Classical and quantum adversary models

Computational bounds, uniformity, static or adaptive corruption, selective targets, and classical versus quantum computation and oracle access. Quantum-resistant classical protocols do not imply quantum communication.

Choosing adversary query bounds

Exact security formulas contain query counts as inputs. Turning the formulas into key sizes requires deciding how many signature queries and how many hash queries a real adversary could realistically make.

Why it is useful

The loss factors in the reductions grow with these counts, so the counts change the recommended parameters directly. Guessing too low weakens the guarantee; guessing too high wastes key length and signing time.

How it works

  1. Bound signature queries by what the honest signer will actually answer; the paper assumes about a billion, written as 2 to the 30, because each query needs the signer to do work.
  2. Bound hash queries by the adversary's own computing budget, which can be far larger since hashes can be computed alone and off line; the paper uses 2 to the 80 minus 1.
  3. Pick the challenge length so that correctly guessing one hash answer among all queries stays negligible; the paper sets it so the guessing chance is below one in a million.
  4. Pick the modulus length from the assumed cost of factoring, since both schemes analyzed fall immediately if the modulus is factored.

What to watch for

These are 1999-era estimates chosen to illustrate the method, not parameter guidance for present use. The hash query bound in particular assumes an adversary willing to spend extraordinary resources on off-line queries.

Useful background: Exact security of digital signatures.

Related ideas

Papers

Semi-honest and malicious adversaries

A semi-honest participant follows the protocol but tries to learn extra information from everything it sees. A malicious participant may instead change messages, choose invalid inputs or depart from the instructions.

Why it is useful

These are different promises about what an attacker may do. They explain why a protocol may need extra checks before it can be used with untrusted participants.

How it works

  1. State which participants may be dishonest.
  2. Specify whether they must follow the protocol or may deviate.
  3. Analyze the information available in that model.
  4. Add and justify consistency checks when moving to a stronger attacker model.

What to watch for

Semi-honest security does not mean that the implementation detects cheating. Calling both settings simply secure hides an important distinction.

Papers

Idealized oracles and algebraic models

Random and quantum random oracles, ideal ciphers, generic groups and algebraic adversaries. These choices do not establish security of concrete hashes or group implementations.

Algebraic group model

The algebraic group model restricts an attacker to supplying a representation of each relevant output group element as a combination of group elements it has already received.

Why it is useful

Those representations give a security reduction information about how an output was formed, allowing tighter arguments for some group-based constructions.

How it works

  1. Track the group elements available to the attacker.
  2. Require coefficients explaining a produced element in terms of those elements.
  3. Translate the coefficients into algebraic relations.
  4. Use those relations in a reduction to the underlying hardness assumption.

What to watch for

Real attackers are not required to submit these explanations. A tight proof in this restricted model is useful evidence, but it does not remove the restriction or automatically replace a standard-model analysis.

Papers

Generic group model

The generic group model treats group elements as opaque random encodings. Algorithms manipulate them through allowed group operations rather than exploiting their concrete bit representation.

Why it is useful

It makes it possible to analyze the algebraic information available from group operations while excluding representation-specific attacks.

How it works

  1. Represent elements with hidden random labels.
  2. Provide oracles for group operations and equality tests.
  3. Track the algebraic expressions built through those oracle calls.
  4. Prove a security bound for adversaries restricted to that interface.

What to watch for

A generic-group proof is not a proof against every attack on a concrete elliptic-curve representation. It also differs from the algebraic group model, which requires output explanations but gives the attacker concrete group representations.

Related ideas

  • Bilinear pairings: Add cross-group multiplication of hidden exponents to the generic operations.

Papers

Lifting the symbolic proof to real cryptography

The bridge result: when the abstract commands are implemented with real algorithms that meet the accepted security definitions, the implementation is at least as secure as the symbolic model. This relation between the two systems is called reactive simulatability.

Why it is useful

It is what turns a symbolic argument about Kerberos into a statement about actual code, without redoing the proof at the level of bitstrings and probabilities.

How it works

  1. Compare what the honest users see: their inputs, outputs and internal states form a view.
  2. For every efficient adversary attacking the implementation there is an adversary against the symbolic model that makes the two views indistinguishable; if no such adversary exists, the underlying cryptography can be broken.
  3. Properties phrased as integrity requirements then transfer automatically, provided the protocol avoids the Commitment Problem.
  4. The Commitment Problem arises when a key encrypts something while secret and is revealed later: the simulator would have committed to a ciphertext it cannot afterwards explain. Kerberos avoids it, so the transfer applies.

What to watch for

The transfer is property-dependent and one-directional: authentication carries over, but symbolic key secrecy does not, because the computational definition of secrecy asks for more.

Useful background: The Dolev-Yao idealization used in the proof.

Papers

Random oracle model

The random-oracle model treats a hash-like function as a public, consistently sampled random function. Repeating an input gives the same answer; a new input receives a fresh random answer from the defined output space.

Why it is useful

It lets a security proof analyze protocols whose challenges or derived values come from hashing, while giving the proof access to the adversary's oracle queries.

How it works

  1. Specify the oracle's input and output spaces.
  2. Return a consistent answer for every repeated query.
  3. Analyze attackers with access to the same oracle.
  4. Distinguish this idealized proof from an unconditional guarantee about a concrete hash implementation.

What to watch for

A real hash function is a fixed algorithm, not a literal random oracle. A random-oracle proof does not by itself justify omitted transcript fields, ambiguous encodings or using one domain for unrelated tasks.

Papers

The Dolev-Yao idealization used in the proof

A symbolic model of cryptography, the BPW model of Backes, Pfitzmann and Waidner. Every message piece is an entry in one abstract database, each entry has a type such as signature or ciphertext, and participants hold handles that record who may know what.

Why it is useful

Hand proofs about real bitstrings and algorithms were impractical for a protocol of Kerberos size. An algebraic model makes the reasoning manageable, and this particular one comes with a computational justification, so the simplification is not a leap of faith.

How it works

  1. Each encryption, signature or nonce operation creates a new typed entry with pointers to its inputs.
  2. A participant can only read an entry if she holds a handle to it or to entries that could produce one; the model simply does not allow cheating.
  3. A single trusted machine executes the commands for the honest participants, so the state is exactly who knows which term.
  4. Length bounds on entries and on the number of operations keep the whole system polynomial in the security parameter, the knob that sets all key and message lengths.

What to watch for

This is an idealization of cryptography, not a description of it: real schemes can leak partial information, so the mapping back to real algorithms needs the conditions discussed in the next lesson.

Useful background: Kerberos ticket-based authentication.

Papers

Leakage, tampering and subversion models

Formal limits on leakage, key relations, tampering, faults, selective failure and malicious implementations. Countermeasure engineering and attacks are linked rather than reproduced here.

Trust and setup assumptions

Plain, common-reference-string, public-key registration, random-string and hardware-assisted models, including who samples parameters. Setup ceremonies belong under distributed infrastructure.

Spacetime-constrained and proximity cryptography

Classical and quantum cryptographic tasks using spatial separation, timing or bounded signal propagation, including relativistic commitments, position verification and distance-bounding authentication. These tasks have different guarantees; a distance bound does not by itself certify a unique position, and quantum communication is not required for every construction.

Steganography and covert cryptography

Steganography hides whether a secret message is present by matching ordinary communication. Its guarantees depend on a realistic model of that communication, including history and timing, and on what changes an observer may make.

History-dependent cover channels

A cover channel describes what ordinary communication looks like after a particular history. Its next sample can depend on earlier messages and on timing, rather than being drawn from one fixed distribution forever.

Why it is useful

Matching the appearance of isolated messages is insufficient when observers can notice unusual sequences, repetition or sending times.

How it works

  1. Include the observable contents and timing in the channel model.
  2. Condition the next-sample distribution on the communication history.
  3. Sample possible next blocks from that conditional distribution.
  4. Update the history with the block actually transmitted.

What to watch for

The paper assumes a sampler that can produce suitable independent draws for a fixed history. A person or a real data source may not provide that ability.

Related ideas

Papers

Integrity of hidden messages

Hidden-message integrity asks whether an attacker can cause the receiver to accept a new message that the sender never encoded. The receiver may reject invalid material rather than decode every input as a message.

Why it is useful

A secret channel may conceal communication yet still allow undetected changes or fabrication of its payload.

How it works

  1. Define a decoding failure result.
  2. Check the authentication required by the construction before accepting the hidden message.
  3. Treat an accepted, newly fabricated payload as an integrity failure.

What to watch for

Rejecting altered messages is different from recovering the original message despite alteration. Integrity does not prevent denial of service.

Related ideas

  • Robust steganography: Concerns recovery despite bounded alterations, rather than only rejecting fabrications.

Papers

Rejection sampling for steganographic encoding

This encoding method samples possible cover blocks and tests whether each block represents the desired hidden symbol. It accepts a suitable block, with a fixed cutoff to bound the amount of sampling.

Why it is useful

It works through a channel sampler instead of modifying an arbitrary existing file and assuming the modified file remains typical.

How it works

  1. Choose the hidden symbol to encode.
  2. Draw a candidate from the channel distribution for the current history.
  3. Apply the construction's label function to the candidate.
  4. Accept a matching label or apply the specified cutoff behavior.
  5. Advance the history using the emitted block.

What to watch for

Conditioning on a label can change a distribution. The complete construction must justify why its labels, randomness and state hide that change. A cutoff can also introduce decoding errors.

Papers

Robust steganography

Robust steganography additionally aims to recover the hidden message after an observer makes permitted changes to the transmitted material. Secrecy and recovery under alteration are separate requirements.

Why it is useful

An observer can disrupt communication without first detecting or reading its hidden message.

How it works

  1. Specify exactly which alterations the observer may make.
  2. Define decoding success under those alterations.
  3. Design both the embedding and recovery procedure for that restriction.
  4. Analyze ordinary-traffic indistinguishability separately from decoding reliability.

What to watch for

No such construction can guarantee delivery if the observer may replace or suppress every message arbitrarily. The robustness claim depends on explicit restrictions on its power.

Related ideas

Papers

Stateful rejection-sampling steganography

The paper's stateful construction labels candidate cover blocks with a pseudorandom function keyed by a shared secret and indexed by a synchronized counter. It uses bounded sampling and an error-correcting code to convey a message.

Why it is useful

Changing the counter for each block avoids repeatedly using the same secret labeling of the channel, while bounded sampling limits work.

How it works

  1. Encode the hidden message with a code suited to the resulting error model.
  2. For each coded bit, test at most the prescribed number of sampled blocks using the secret label and current counter.
  3. Transmit the selected block and advance the counter.
  4. The receiver computes the same labels and decodes the recovered noisy bit string.

What to watch for

The parties need synchronized state and the specified channel entropy and sampling assumptions. The coding overhead cannot be inferred merely from the phrase error correction.

Related ideas

Papers

Stateless steganography with balanced labels

This construction first encrypts the message into random-looking bits. It then samples cover blocks whose public labels match those bits, using a label function that is balanced on the channel distribution.

Why it is useful

It avoids the synchronized secret-label counter used by the paper's first construction.

How it works

  1. Encrypt the hidden message with the required random-looking-ciphertext scheme.
  2. For each ciphertext bit, sample cover blocks until the public label matches or the cutoff is reached.
  3. Recover the labels at the receiver and decrypt the resulting bit string.

What to watch for

A balanced label function is a strong channel-specific assumption and need not exist for every channel. Stateless here does not mean the channel has no history or that every underlying encryption mode has no state.

Related ideas

Papers

Steganographic secrecy

Steganography aims to hide the presence of a secret message, not only its contents. An observer should have difficulty telling the transmitted material from ordinary communication on the specified channel.

Why it is useful

Encrypted content may be unreadable but still recognizable as encrypted communication. Steganographic secrecy asks a different question about the observable distribution.

How it works

  1. Define the distribution of ordinary communication.
  2. Encode the hidden message into material drawn from that channel.
  3. Give the observer the access specified by the security model.
  4. Compare its ability to distinguish encoded communication from ordinary channel samples.

What to watch for

The guarantee is only as meaningful as the channel model. Hiding a payload does not automatically hide the sender, timing, length or endpoints.

Papers

Leakage-resilient cryptography

Leakage-resilient cryptography designs schemes that stay secure when an attacker learns part of the secret key or other internal state. This paper works in the bounded setting: the attacker chooses arbitrary efficiently computable functions of the signer’s state, their combined output length is capped below the secret-key length, and signatures must remain unforgeable anyway.

Bounded leakage model for signatures

A security game for signatures in which the attacker, on top of the usual public key and signatures, may choose functions of the secret key and the signer’s internal state and learn their outputs, as long as all outputs together stay under a fixed bit budget.

Why it is useful

Standard proofs pretend the attacker only sees the public key and chosen-message signatures. Real implementations also expose side-channel measurements, fault attacks, timing information, weak random generation, or keys reused in two protocols. The bounded-leakage model lets a proof survive a measured amount of that exposure instead of ignoring it.

How it works

  1. Start from the standard game: existential unforgeability under adaptive chosen-message attack, where the attacker requests signatures and must then sign a fresh message.
  2. Add a leakage oracle. The attacker submits a circuit f and the oracle replies with f applied to the current state, which contains the secret key and randomness used so far.
  3. Cap the total output length of every submitted function combined at some bound, stated as a function of the secret-key length.
  4. The scheme is leakage resilient if, despite all this, the chance of producing a valid signature on a message never signed stays negligibly small.
  5. This is a general recipe: the same modification can be applied to encryption, identification, or symmetric primitives.

Example

A 2048-bit key with a leakage bound of 1000 bits means the attacker may obtain any 1000 bits’ worth of computed information about the key, adaptively chosen, and still must not be able to forge.

What to watch for

The cap limits how many bits come out, not how the functions are chosen; they can be any efficiently computable circuit, including one built from recorded side-channel traces. The oracle may also be queried adaptively, after seeing earlier answers.

Useful background: Existential unforgeability under chosen-message attack.

Related ideas

Papers

Bounded leakage only slowly erodes unpredictability

A counting lemma: the probability that the output of an arbitrary function with λ-bit output cuts the min-entropy of a secret by more than Δ is at most 2 raised to the power λ−Δ.

Why it is useful

It is the engine of every proof in the paper: after λ bits leak from an n-bit key with n bits of min-entropy, about n−λ bits of unpredictability survive, so the attacker cannot tell which of many possible keys is in use.

How it works

  1. Define min-entropy as minus the base-2 logarithm of the largest probability of any single key value; it measures how hard the key is to guess in one try.
  2. Condition on one particular leakage output. If that output would pin the key down too much, then that output must itself have been unlikely.
  3. There are at most 2 to the λ possible outputs, so adding these small probabilities bounds the chance of a damaging output by 2 to the λ−Δ.
  4. Apply the lemma with Δ set to the original entropy: the chance that the leaked information uniquely determines the key is at most 2 to the λ−n, which is tiny whenever the leakage stays well below n bits.

Example

Illustration only: an 8-bit secret with full min-entropy and 3 bits of leakage; the chance that those 3 bits already determine the secret is at most 2 to the power 3−8, or 1 in 32.

What to watch for

The lemma bounds min-entropy, not average uncertainty, and it only controls functions whose output length is bounded; nothing is said about functions with longer outputs.

Useful background: Bounded leakage model for signatures.

Related ideas

Papers

Limits of the bounded-leakage model

What the results do and do not promise: a fixed key with a total leakage cap, differing conventions about what may be read, one-time or bounded-signature restrictions in the efficient schemes, and known losses in the proofs.

Why it is useful

Stating the boundaries prevents over-claiming: leakage resilience here is a specific, budgeted guarantee, not immunity to every implementation attack.

How it works

  1. The total-leakage cap is forced by the unchanged key; the paper’s earlier related work reached roughly half the key length in the random oracle model, and the constructions here approach all but a sublinear remainder in the standard model.
  2. The efficient schemes trade generality for leakage: they sign only once or a bounded number of times, and their tolerated fraction of the key is lower.
  3. The results are incomparable across sections of the paper: full leakage resilience and better efficiency on one side, unrestricted signing on the other.
  4. The random-oracle proof is loose, and improving the tightness of that reduction is left open.
  5. Factoring or RSA instantiations must restrict what the leakage functions may read or pay for oblivious modulus sampling.

What to watch for

The model covers passive exposure of bounded length; it does not cover tampering with the key, leakage beyond the budget, or attacks that fall outside the chosen convention for what the functions may read.

Useful background: Why the leakage bound is unavoidable, A leakage-resilient signature scheme in the standard model, Leakage-resilient one-time signatures from a one-way hash.

Related ideas

Papers

What the leakage functions are allowed to read

Three conventions for the inputs of the leakage functions: only the parts of the key touched while computing, the whole secret key at all times, or every piece of state the signer ever uses, including randomness.

Why it is useful

The choice decides which physical attacks the definition actually covers, and for signatures it matters because signing uses fresh randomness that could also be measured.

How it works

  1. In the “only computation leaks” convention each function sees only the key material accessed during one phase of the scheme.
  2. Cold-boot style memory attacks read long-term secrets while nothing is computing, so they are modeled by letting the functions take the entire secret key as input at any time.
  3. For signatures the strongest option lets the functions read all state used while signing, which includes the randomness of each signing query and even of key generation.
  4. If signing is deterministic, no fresh signing randomness exists, so the distinction between the weaker and stronger conventions collapses.

What to watch for

The paper’s Definition 2 starts the state at the randomness that generated the key and adds the randomness of each signing query, which is why it is called “full” leakage resilience.

Useful background: Bounded leakage model for signatures.

Related ideas

Papers

Why the leakage bound is unavoidable

If the secret key never changes and the leakage functions are unrestricted, then an attacker allowed n bits of output for an n-bit key could ask for the key itself, so every guarantee must cap the total leakage below the key length.

Why it is useful

The bound is not an artifact of the proofs; it is a logical necessity for keys that stay fixed, and recognizing it explains which escapes exist and what they cost.

How it works

  1. Take an n-bit key and allow arbitrary functions with n or more total output bits; the function that simply outputs the key is allowed, and security is impossible.
  2. So a fixed-key scheme must promise security only while the total leakage stays below n bits. For signatures the paper notes the budget must also stay below the signature length, since signatures themselves are handed to the attacker and already narrow down which keys are possible.
  3. One escape is to refresh the secret key over time; then the total leakage can be unbounded, but the leakage between two refreshes must still be bounded.
  4. Another escape keeps the key computationally hard to recover no matter how much leaks; the paper warns there is no general way to check whether given functions satisfy this, and the known results need super-polynomial hardness assumptions.

What to watch for

Every scheme in this paper keeps one unchanged key, so the total cap is essential here.

Useful background: Bounded leakage model for signatures.

Related ideas

Papers

Smooth projective hashing

A hash tool with two evaluation modes, one public and one using a witness, that yields simple password-based key exchange and oblivious transfer protocols.

A quadratic-residuosity hash family without safe primes

A concrete family modulo an RSA modulus N: the hash of x under key k is x to the power k modulo N, the projective key is a power of a public element g, and the witness is a discrete log. The special subset is generated by a forced odd-order version of g, and non-members are produced as N minus x.

Why it is useful

Earlier factoring-based families were only proved secure when N was a product of safe primes, meaning each half of N minus one is itself prime. This paper shows the restriction was never needed: any modulus that is a product of two same-size primes works.

How it works

  1. The sender cannot test whether g has odd order, so it pushes g into the odd-order subgroup by raising it to a power of two larger than N, since high powers of two kill off the even part of the order.
  2. The sender checks that one element equals N minus the other; two such elements cannot both have odd order, so hashing is smooth on at least one of them.
  3. The family is first built as universal with a bound near one half, then amplified by repetition and extraction.

What to watch for

The safe-prime observation also repairs earlier proofs: the paper notes that the Cramer-Shoup, Gennaro-Lindell and Camenisch-Shoup encryption schemes remain secure with ordinary RSA moduli.

Useful background: From universal to smooth hashing, Verifiable smoothness against malicious receivers.

Papers

An N-th residuosity hash family and its wider domain

A second concrete family, this time modulo the square of an RSA modulus, in the setting of the N-th residuosity (Paillier) assumption. Hashing is again exponentiation by the key, but the subgroup structure used for the special subset is different.

Why it is useful

It gives a second oblivious-transfer protocol from a different assumption, with a much better universality bound per hash, and it also drops two earlier restrictions: safe primes and the Jacobi-symbol condition on elements.

How it works

  1. As with quadratic residues, the sender forces g into the subgroup of elements whose order shares no factor with N, by raising g to a huge power of N.
  2. The receiver forms the non-member by multiplying the member by an element of the form 1 plus v times N, and the sender verifies exactly that shape, with v sharing no factor with N.
  3. The domain is the set of products of a power of g with a power of 1 plus N, and the special subset is the powers of g alone.

What to watch for

A quirk of this family is that some elements of the full group lie outside the domain and there is no easy way to recognize which; harmless for oblivious transfer, but a real obstacle the paper has to work around for chosen-ciphertext-secure encryption.

Useful background: A quadratic-residuosity hash family without safe primes.

Papers

From universal to smooth hashing

A weaker property called universality is often easier to build: given the projective key, no single hash value is much more likely than any other. A standard transformation turns a universal family into a smooth one.

Why it is useful

The concrete families in this paper are first constructed as universal families with a rather weak bound, so this amplification step is what makes them usable.

How it works

  1. Hash the same input t times with independently drawn key pairs; the chance that an attacker can pin down all t values at once drops like epsilon to the power t.
  2. Feed the t hash values through a strong randomness extractor with a public seed to get an output that is nearly uniform.
  3. Choose t so that t times the logarithm of one over epsilon comfortably exceeds the wanted output length.

What to watch for

The transformation costs t key pairs and t hash computations per output, and it forces the final hash outputs to be bit strings rather than group elements.

Useful background: Smoothness versus projection.

Papers

Smooth projective hashing: two keys and six algorithms

A smooth projective hash family is a collection of keyed hash functions with two kinds of keys. The primary hashing key computes the hash on every input. The projective key, by itself, is only enough to compute the hash on inputs from a special subset, and even there it needs extra information called a witness.

Why it is useful

The gap between the two keys is the working material of the protocols built on top: whoever holds the projective key and a witness can compute one hash value, while for inputs outside the special subset the projective key hides the hash value almost completely.

How it works

  1. A parameter generator fixes public parameters, which define a large domain of inputs and, inside it, a special subset.
  2. The instance sampler produces a triple: a member x of the special subset, a non-member x-prime, and a witness w proving that x is a member.
  3. The hash-key generator outputs a pair of keys: the primary key k and the projective key pk.
  4. Hashing with k works on any input; hashing with pk works only on a member, and only together with its witness.

Example

In a group with a hard discrete-log problem, the special subset could be the pairs of elements that share one secret exponent; the exponent is the witness.

What to watch for

Everything rests on the special subset being hard to recognize: if members and non-members were easy to tell apart, the two keys would no longer play different roles.

Papers

Smoothness versus projection

Two properties pull in opposite directions. Projection says that on a member input, the projective key alone pins down the hash value. Smoothness says that on a fixed non-member input, seeing the projective key together with the hash value looks the same as seeing the projective key with an unrelated random value.

Why it is useful

Projection is what makes protocols correct: two parties who hold different keys still compute the same hash on a member. Smoothness is what makes them private: for a non-member, the public projective key gives essentially no help in guessing the hash.

How it works

  1. Check projection by verifying that any two primary keys matching the same projective key agree on the member input.
  2. Check smoothness by comparing two experiments: draw a key pair and hash the non-member, versus draw a key pair and an independent random value; the two outcomes must be close as distributions.
  3. The allowed gap is a small parameter epsilon that shrinks with the security parameter.

What to watch for

The two properties cannot both hold at the same input: if projection fixed the hash on a non-member, the projective key would determine that hash, contradicting smoothness. This paper also uses the stronger, per-instance flavour of smoothness: it must hold for every non-member, not merely for a random one.

Useful background: Smooth projective hashing: two keys and six algorithms.

Papers

Verifiable smoothness against malicious receivers

An extra algorithm, the instance tester, inspects the hashing parameters and the two elements the receiver sent, and accepts only if the family is smooth on at least one of them.

Why it is useful

A dishonest receiver picks its own parameters and elements, and could put both elements inside the special subset to decode both strings. Earlier applications of smooth projective hashing never faced this, because a public key or a common reference string produced the parameters honestly.

How it works

  1. The tester must accept every honestly sampled pair, in either order.
  2. Whenever the tester accepts some pair, at least one of the two elements must be a smooth point for the family.
  3. The sender runs the tester first and aborts if it fails, so hashing only ever happens on inputs where the privacy argument applies.

What to watch for

The guarantee is deliberately vague about which element is smooth; if the tester revealed that, it would leak the receiver’s choice. Building families with this property is the main technical work of the paper.

Useful background: Two-message oblivious transfer from projective hashing, Smoothness versus projection.

Papers

Shared-key encryption and hashing

Shared-key encryption uses the same secret key to protect and recover messages. Hash functions summarize data; authentication codes help a key holder detect changes.

Anemoi

Anemoi is a field-based hash family using Flystel nonlinear components.

Papers

Anemoi Flystel

Flystel is the nonlinear building block used in Anemoi permutations.

Papers

ARIA

ARIA is a substitution-permutation block cipher with alternating substitution layers.

Papers

BLAKE2

BLAKE2 is a revision of BLAKE with keyed and unkeyed hashing modes.

Papers

Chaskey

Chaskey is a permutation-based MAC designed for microcontrollers.

Papers

DES

DES is a Feistel block cipher with a bit-oriented round function.

Papers

Farfalle

Farfalle constructs keyed functions from parallel applications of cryptographic permutations.

Papers

Generalized triangular dynamical systems

Generalized triangular dynamical systems provide algebraic templates for cryptographic permutations over finite fields.

Papers

GMiMC

GMiMC is a field-based family of block-cipher and hashing constructions related to MiMC.

Papers

HCH

HCH is a tweakable enciphering scheme using a hash-counter-hash structure.

Papers

HCTR

HCTR is a variable-length tweakable enciphering construction combining hashing and counter-mode processing.

Papers

HERA cipher

HERA is a symmetric cipher designed for homomorphic evaluation.

Papers

Hirose compression

Hirose is a double-block-length block-cipher-based compression construction.

Papers

Horst construction

Horst extends a Feistel update by multiplying one branch by a function of the other branch.

Papers

Jarvis cipher

Jarvis is a STARK-oriented block cipher in the MARVELlous family.

Papers

Jive compression mode

Jive is a permutation-based compression mode presented alongside the Anemoi family.

Papers

Kalyna

Kalyna is a block cipher standardized in Ukraine.

Papers

KangarooTwelve

KangarooTwelve is a tree-hash construction using Keccak-p.

Papers

Masta cipher

Masta is a homomorphic-evaluation-oriented cipher with pseudorandom affine layers.

Papers

Miyaguchi-Preneel compression

Miyaguchi-Preneel forms a block-cipher compression function with message and chaining-value feedforward.

Papers

Poseidon2

Poseidon2 revises Poseidon with different linear layers.

Papers

Poseidon2b

Poseidon2b adapts Poseidon2 to binary extension fields.

Papers

Poseidonb

Poseidonb adapts Poseidon to binary extension fields.

Papers

PRINCE

PRINCE is a block cipher with a reflection structure around its middle layer.

Papers

Reinforced Concrete

Reinforced Concrete is a hash design combining field operations with lookup-oriented nonlinear operations.

Papers

Rescue-Prime Optimized

Rescue-Prime Optimized adapts Rescue-Prime for a specified prime-field setting.

Papers

Serpent

Serpent is a bitslice-oriented substitution-permutation block cipher.

Papers

SM4

SM4 is a block cipher with a nonlinear round transformation and a word-oriented state.

Papers

Sponge construction

The sponge construction absorbs input and squeezes output through a fixed-width permutation state.

Papers

TMAC

TMAC is a two-key variant of CBC-MAC.

Papers

Twofish

Twofish is a Feistel block cipher using key-dependent S-boxes.

Papers

Vision Mark-32

Vision Mark-32 is a Vision hash variant defined over binary tower fields.

Papers

Xoodyak

Xoodyak is a duplex-based symmetric construction built on the Xoodoo permutation.

Papers

Cipher and permutation design

Keyed block and stream transformations, public permutations, tweaks and round structures. Encryption modes and security definitions are separate topics.

Block ciphers

Fixed-width keyed permutations, key schedules and block/key-size tradeoffs. A block cipher alone does not specify a message-encryption mode or integrity protection.

Advanced Encryption Standard (AES)

Block cipher used in hybrid QKD systems where the QKD key is expanded to encrypt long messages when QKD key rates are insufficient for one-time pad encryption.

Papers

AES

AES is a substitution-permutation block cipher standardized from Rijndael.

Papers

Data Encryption Standard (DES)

Historical block cipher used as an example of a cipher that has withstood decades of cryptanalysis, supporting the argument that hybrid QKD systems with classical ciphers offer enhanced security.

Papers

Partially serialized Simeck hardware

Evaluating only part of a Simeck word per cycle, including a one-bit fully serialized case. The datapath width is a divisor of the word size; extra rotation-selection logic and a serialized-step counter reduce throughput while allowing smaller datapaths.

Papers

Round-parallel Simeck hardware

The paper's hardware datapath that processes one complete encryption round and one key-schedule round in each clock cycle. It trades a wider datapath for higher throughput; the paper counts four additional cycles for loading.

Papers

Simeck

A family of lightweight Feistel block ciphers designed for compact hardware. It changes SIMON's rotation constants, reuses its own round function in the key schedule following a SPECK design idea, and generates round-constant bits with small LFSRs. The paper specifies three block/key-size variants; its security evaluation is historical, not a current deployment recommendation.

Papers

Simeck32/64

The Simeck variant with 32-bit blocks, a 64-bit key and 32 Feistel rounds. These are algorithm parameters, not a claim of 64-bit security for arbitrary message volumes or attack models.

Papers

Simeck48/96

The Simeck variant with 48-bit blocks, a 96-bit key and 36 Feistel rounds. These are algorithm parameters, not a claim of 96-bit security for arbitrary message volumes or attack models.

Papers

Simeck64/128

The Simeck variant with 64-bit blocks, a 128-bit key and 44 Feistel rounds. These are algorithm parameters, not a claim of 128-bit security for arbitrary message volumes or attack models.

Papers

SIMON

SIMON is a family of block ciphers using bitwise operations in a Feistel structure.

Papers

SPECK block ciphers

SPECK is a block-cipher family based on addition, rotation and XOR.

Papers

Lightweight block ciphers

Block-cipher designs for constrained hardware and software. Lightweight is a design goal, not a security rating.

GIFT

GIFT is a lightweight substitution-permutation block cipher.

Papers

Midori

Midori is a lightweight block cipher designed for low-energy implementations.

Papers

PRESENT

PRESENT is a lightweight block cipher built from small S-boxes and a bit permutation.

Papers

Reading the security margin of a lightweight cipher

A security margin is the distance between what a design claims and what cryptanalysis can actually reach. The paper measures it two ways: how many rounds of the construction no known attack covers, and how many bits separate the claimed security level from the best attack complexity.

Why it is useful

Lightweight designs spend their budget on being small, so they sit close to the line; an honest margin number tells designers and standardizers how much room is left before a small improvement in attacks turns into a real break.

How it works

  1. Rounds measure: differential attacks reach 338 of the 384 rounds of the short permutation, leaving 46 rounds unattacked, about 12 percent of the construction.
  2. Data measure: on the full 384 rounds the best differential has probability about 2 to the minus 70.7 once its trail cluster is summed, so less than 8 bits separate the attack from the claimed 64 bits.
  3. On the permutation taken alone with no restriction on input or output, the refined model finds a full-round differential of probability 2 to the minus 19 (20 active gates minus 1 correlation), which the authors verified experimentally with the implementation from the designers.
  4. The suggested responses are to raise the short permutation from 384 to 512 rounds, or to re-choose the tap positions using the refined model instead of the simple one.

Example

Two ways to state the same result: 46 unattacked rounds out of 384 (about 12 percent), or 64 claimed bits minus roughly 70.7 attack bits (less than 8 bits of slack).

What to watch for

A small margin is a warning, not a break: the paper states that its attacks do not contradict the stated security claims, and margin numbers depend on the attack techniques available when they are measured.

Useful background: Forging tags with a differential on the nonce blocks, Why counting active AND gates understates the risk.

Papers

Round functions and public permutations

A round function is the small transformation a block cipher repeats to build security; the choice of round determines both the cipher's resistance to cryptanalysis and its cost in whatever engine evaluates it. Classical rounds mix S-box lookups, XORs, and bit permutations, which suits hardware and CPUs but not arithmetic over large prime fields. MiMC instead uses a single monomial, cubing, with the key and a round constant added: over a prime p where 3 does not divide p minus 1, cubing is a permutation, it is the cheapest available non-linear field operation, and the number of rounds is dictated by interpolation and GCD attacks on the resulting low-degree polynomial rather than by differential or linear cryptanalysis.

Camellia

Camellia is a Feistel block cipher with substitution and linear layers.

Papers

Gimli permutation

Gimli is a cryptographic permutation intended for cross-platform symmetric constructions.

Papers

MiMC: cubing over a prime field

A block cipher whose round function is a single cubing over the prime field, with the key and a round constant added beforehand, iterated enough times to resist algebraic attacks.

Why it is useful

Cubing is the cheapest non-linear operation available in field arithmetic and it stays inside the engine's native data type, so the whole cipher is a short chain of secure multiplications.

How it works

  1. Choose the prime so that 3 does not divide p minus 1, which makes cubing a permutation of the field.
  2. Iterate the round map about log base 3 of p times, since interpolation and GCD attacks on the cipher's low-degree polynomial set that count; 82 rounds for full security, 73 when only a limited number of plaintexts is available.
  3. The basic MPC evaluation needs one squaring and one multiplication per round, in twice as many rounds of communication.
  4. A faster variant precomputes cube triples: open the difference of the shared value and a random value, then express the cube as a linear combination of shared powers of that random value.

Example

With the cube-triple trick the paper reports 3r openings in r rounds instead of 2r rounds, halving latency at a small cost in computation.

What to watch for

Many rounds give good throughput but poor latency, and the algebraic simplicity that makes it cheap is also what the interpolation and GCD attacks target.

Useful background: Why bit-oriented ciphers still miss the target.

Related ideas

  • Round functions and public permutations: a round built from one monomial

Papers

Serialized rotation input selection in Simeck

The one-bit datapath's two rotation multiplexers. MUX1 selects register b on serialized step zero, then register a; MUX5 selects b on steps zero through four, then a. The selected bit positions are n-1 and n-5, respectively, as the registers shift.

Papers

Simeck key schedule

Expands four master-key words into round keys by applying the same nonlinear function as the encryption round, together with a fixed word constant and an LFSR-generated bit. The low master-key word supplies the first round key. Reusing round logic follows a design idea attributed here to SPECK; it does not make the two ciphers identical.

Papers

Simeck LFSR round constants

Combines the fixed n-bit value 2^n - 4 with one bit from a small LFSR sequence. Simeck32/64 and Simeck48/96 use a period-31 sequence from X^5 + X^2 + 1; Simeck64/128 uses a period-63 sequence from X^6 + X + 1. Both registers start with all bits set.

Papers

Simeck round function

A two-word Feistel round that replaces the left word with the right word XOR a nonlinear function of the left word XOR the round key, and moves the old left word to the right. Its nonlinear function combines the input AND its 5-bit left rotation with the input's 1-bit left rotation using XOR.

Papers

The TinyJAMBU keyed permutation: one NAND gate per round

The core of TinyJAMBU is a 128-bit nonlinear feedback shift register. Each round shifts the state by one bit and computes one fresh bit from a few selected state bits (the tap positions) and one key bit; the single NAND gate in that formula is the only nonlinear operation in the whole round.

Why it is useful

This is what makes the cipher tiny in hardware, and because there is exactly one nonlinear gate per round, counting how many of those gates a cryptanalytic trail activates becomes a natural way to measure the trail cost.

How it works

  1. The state (s127,...,s1,s0) moves to (z, s127,...,s1) where z = s0 XOR s47 XOR (s70 AND s85) XOR s91 XOR b, and b is one key bit.
  2. Rounds consume the key bits in turn, repeating cyclically, so a 384-round call of the short permutation XORs key bits into the fresh bit 384 times without ever expanding or updating the key.
  3. No key schedule exists: the saved logic and control circuit are part of the lightweight goal, and in some implementations the key XORs can even be direct wiring.

Example

One clock of the round function needs one NAND, four XORs and a shift, which is why the authors point the reader at the round diagram to feel the lightness.

What to watch for

It is a keyed permutation, not a public one like the sponge permutation of Keccak or Ascon, and the mode security proofs assume these keyed permutations behave ideally; the round count is a design choice, not a proof.

Useful background: TinyJAMBU.

Related ideas

Papers

Addition, rotation and XOR (ARX)

Constructions based on modular addition, bit rotation and XOR. Rotation/AND/XOR designs are distinct.

LEA

LEA is an ARX block cipher using word operations.

Papers

Stream ciphers

A stream cipher expands a short secret key into a long keystream that is added bit by bit to a message. Trivium does this with three interacting nonlinear feedback shift registers: it loads an 80-bit key and an 80-bit initialization vector, runs 1152 setup rounds while discarding the output, and only then starts emitting the keystream bits that are added to the plaintext.

ChaCha

ChaCha is an ARX stream-cipher family derived from Salsa20.

Papers

Cube attack

A key-recovery method that treats one output bit of a cipher as a polynomial in the key bits and the public initialization-vector bits, then sums it over all values of a chosen set of public variables to obtain a much simpler polynomial in the key bits alone.

Why it is useful

Simple polynomials give equations, and linear equations can be solved with basic linear algebra. Enough of them reveal key bits directly, and whatever is left can be found by brute force. This works whenever the cipher’s output polynomial stays low-degree, which is exactly what Trivium’s slow degree growth allows.

How it works

  1. Write the first output bit as a polynomial P over the key bits and the public bits.
  2. Pick a “cube”: a set C of k public variables, and sum P over all 2 to the power k assignments of those variables.
  3. Every monomial that misses at least one cube variable is summed an even number of times and cancels, leaving the “superpoly” in the key bits.
  4. A cube whose superpoly is linear is called a maxterm and yields one linear equation on key bits.
  5. Offline, with a key you know, search for many maxterms; online, with the target key, evaluate those cubes and solve the resulting linear system, then brute-force the remaining key bits.

Example

After 767 rounds the earlier Dinur-Shamir attack found linear superpolys from cubes of only 29 variables, far below the theoretical maximum degree of 160.

What to watch for

The attacker must be able to feed many chosen initialization vectors (resynchronizations) to the cipher, and the output polynomial must stay low-degree. For a genuinely random high-degree polynomial, small maxterms are extremely unlikely, and Trivium’s degree does keep growing toward 160.

Useful background: Trivium, Polynomials over bits.

Related ideas

Papers

Elisabeth cipher

Elisabeth is a homomorphic-evaluation-oriented stream cipher extending FLIP and FiLIP designs.

Papers

Espresso

Espresso is a stream cipher based on a nonlinear feedback shift register.

Papers

Grain-128: NFSR plus LFSR stream cipher

Grain-128 is a stream cipher built from two coupled 128-bit shift registers: a linear feedback shift register (LFSR), whose new bit is a fixed XOR of old bits, and a nonlinear feedback shift register (NFSR), whose new bit also XORs products of pairs of old bits. Each keystream bit is a filtering function of a few taps from both registers.

Why it is useful

Shift-register ciphers are cheap in hardware, and Grain-128 was one of the eSTREAM stream-cipher proposals. Its state layout - nonlinear register seeded with the key, linear register seeded with the initialization vector (IV), then many mixing rounds - is the structure every attack in this paper targets.

How it works

  1. Load the 128-bit key into the NFSR and the 96-bit IV into the LFSR, and fill the remaining 32 LFSR bits with ones.
  2. Clock the state through 256 initialization rounds with no output, feeding the computed output bit back into both registers.
  3. After initialization, each clock outputs one keystream bit: a XOR of seven NFSR taps, a nonlinear filter h over nine taps taken from both registers, and one LFSR tap.

Example

Degree 3 means the biggest product of unknowns in an output bit uses three state bits, which is small enough that algebraic tools can push through after 200+ mixing rounds.

What to watch for

The filter h multiplies pairs of tap bits and adds one product of three taps, so one output bit is a degree-3 polynomial in the state bits; the paper exploits exactly this low-degree structure. This is a summary for learning; the full specification and later Grain versions live in the original design paper.

Related ideas

  • Trivium: another eSTREAM shift-register design mentioned by the paper

Papers

How Trivium generates its keystream

Each round, Trivium taps six fixed positions of its state, XORs three tap sums to form one output bit, adds a small nonlinear correction to each tap, and shifts the three registers by one position.

Why it is useful

The cipher has to turn a slowly mixing state into output bits that look random. Throwing the output away during the 1152 setup rounds means the first usable bit already depends on the whole key and initialization vector.

How it works

  1. Compute three tap sums from fixed state positions.
  2. XOR the three tap sums: that value is the output bit for this round.
  3. Add one product of two neighbouring state bits to each tap sum (the only nonlinear step).
  4. Feed each corrected tap into the front of one register and shift that register by one bit.
  5. Discard the output bit for all 1152 setup rounds, then use it as keystream.

What to watch for

The output bit is a plain XOR of six state bits, so all the nonlinearity sits in the register updates. Because a freshly generated bit is not reused for at least 64 rounds, a software implementation can compute 64 rounds at once and only update the registers 18 times during setup.

Useful background: Trivium, Stream ciphers.

Related ideas

Papers

Measuring polynomial density

Density is the fraction of the possible monomials of a given size that actually occur in the output polynomial. With the Moebius transform you can count them all at once and see up to which degree the cipher behaves like a random polynomial, where every monomial would appear with probability one half.

Why it is useful

It locates the frontier where the cipher’s algebraic structure is still visible. For an attacker that is where to look for useful cubes; for a designer it is a warning that the cipher is not yet behaving randomly at that degree.

How it works

  1. Choose a large cube of k public variables and build the truth table of the first output bit over those variables.
  2. Apply the Moebius transform to that table.
  3. Count how many monomials of each degree up to k appear, by reading the transformed table.
  4. Compare each count with half of the number of possible monomials of that degree.

Example

After 784 rounds the measured density of monomials of size 34 is about 25%, well below the 50% a random polynomial would show.

What to watch for

Only a fraction of the variables is observed (for Trivium no more than 40 of the 160 key and initialization-vector bits), so there is no guarantee the full polynomial has the same density. Testing for a single monomial directly is NP-hard, which is why this bulk approximation is used at all.

Useful background: Moebius transform for cube searches, Cube attack.

Related ideas

Papers

Moebius transform for cube searches

A rearrangement of a Boolean function’s truth table that lists, for every subset of the variables, whether the product of that subset appears as a monomial. Running it once on a cube of k variables evaluates every subcube of that cube at the same time.

Why it is useful

Testing cubes one by one is hopeless when each cube costs billions of cipher runs. One transform over a table of 2 to the power k entries replaces an astronomical number of separate cube computations, which is what let the authors measure the real offline cost of the attack.

How it works

  1. Fix every variable outside the chosen large cube to constants and build the truth table of the output bit over the k cube variables.
  2. Sweep the table with a butterfly of XOR operations, one variable at a time.
  3. Read the entry indexed by a subcube’s indicator bits to get the superpoly that subcube yields.
  4. Reuse the same table for linearity and degree tests, for density measurements and for interpolating several superpolys at once.

What to watch for

Memory is the price: all subcubes of a cube of size k need 2 to the power k bits, which is 128 gigabytes at k = 40 in the authors’ runs. The transform is cheap only relative to the cipher evaluations it replaces.

Useful background: Cube attack, Truth tables.

Related ideas

Papers

Pre-selecting sparse cubes

A search heuristic that only tests cubes which kill the high-degree part of Trivium’s output polynomial: pick two disjoint cubes whose subcubes nearly all yield the zero polynomial on the twelve state registers that carry the degree-2 terms, then work inside their union.

Why it is useful

Random cube walks keep landing on dense, high-degree superpolys, while the rare sparse cubes are the useful ones. Filtering first is what pushed key recovery from 767 to 784 and 799 rounds, and after 799 rounds it was the only method that found any maxterm at all.

How it works

  1. Look at the formal expression of the output bit: an XOR of six registers, each carrying one degree-2 monomial, so twelve registers drive the whole high-degree part.
  2. Using the Moebius transform, find subcubes whose superpoly is zero on all twelve of those registers.
  3. Pick two disjoint cubes that each have as many such subcubes as possible.
  4. Take their union as the large cube, run one transform on it and harvest the candidate subcubes inside.

What to watch for

This is an empirical filter, not a theorem: it assumes the useful maxterm also annihilates the twelve high-degree registers, and it is justified by measurements such as density at size 34 dropping from over 25% to under 10% and maxterms per transform rising from 83 to 916.

Useful background: Measuring polynomial density, Moebius transform for cube searches, Cube attack.

Related ideas

Papers

Quadratic superpolys

When no more linear superpolys can be found, superpolys of degree two still leak key bits. Every quadratic superpoly the authors interpolated at 799 rounds had the same shape: one product of two neighbouring key bits, plus a few single key bits.

Why it is useful

A quadratic relation is not an equation you can solve directly, but if you guess the bits inside the product, the remaining single key bit becomes known. Each such relation therefore cuts the brute-force space in half, just like a linear one.

How it works

  1. Test candidate superpolys for degree two, reusing the queries already made for the linearity tests; only one fresh cube evaluation per triple is needed.
  2. Assume the observed shape and interpolate cheaply: test the 81 possible single-bit terms, then only the quadratic partners of the ones found.
  3. Check the reconstructed polynomial against all points already computed during the tests.
  4. Online, guess the bits appearing in the product; the accompanying single-bit term is then determined, which removes one unknown from the brute-force search.

Example

A recovered relation of the shape x9 + x34x35 + x36 reveals x36 once x34 and x35 are guessed, so it halves the remaining search.

What to watch for

The interpolation leans on an observed regularity (one failed out of dozens), and the degree-2 test uses keys that are not independently chosen, so it is weaker than the textbook version. These relations only pay off while the polynomial stays sparse.

Useful background: Cube attack, Pre-selecting sparse cubes.

Related ideas

Papers

Salsa20

Salsa20 is a stream cipher built from an ARX core.

Papers

SNOW 3G

SNOW 3G is a word-oriented stream cipher combining a shift register and a finite-state machine.

Papers

SNOW-V

SNOW-V is a stream cipher combining feedback registers and an AES-based finite-state machine.

Papers

Stream-cipher design lessons from Grain-128

The paper turns a distinguisher into key recovery by showing that the algebraic degree of Grain-128's output rests on a handful of late nonlinear operations that public input choices can switch off. For designers the lesson is that the final nonlinear terms of the output and the thoroughness of key-IV mixing decide whether cube testers stay mere distinguishers.

Why it is useful

A weak-key set of one key in a thousand that breaks faster than exhaustive search is practically significant, unlike weak-key results that cover only a negligible fraction of keys, so designs must survive attackers who fix or guess a few key bits and simplify the output polynomial.

How it works

  1. Mix key and IV thoroughly and early, so that no late state bit keeps an ANF simple enough to zero with a few public variables.
  2. Check whether removing single high-degree terms from the output function makes the cipher more vulnerable to cube testers; if it does, those terms are single points of failure.
  3. Treat experimentally verified cube-tester distinguishers as key-recovery threats during initialization-round reduction, not merely as certification weaknesses.

Example

The single degree-3 term of Grain-128's output function, a product of two NFSR bits and one LFSR bit, is the term the whole attack works to simplify and nullify.

What to watch for

These are lessons drawn from one cipher family: the paper's preliminary analysis of Trivium improved the best known attack only slightly, and whether most Grain-128 keys can be attacked this way remains an open question, so no general design theorem is implied.

Useful background: Grain-128: NFSR plus LFSR stream cipher, Dynamic cube attacks: dynamic variables that zero state bits.

Papers

Trivium

A stream cipher that stretches an 80-bit secret key and an 80-bit public initialization vector into a long stream of bits, using a 288-bit internal state split over three nonlinear feedback shift registers.

Why it is useful

It was submitted to the eSTREAM competition, which was founded after every stream cipher sent to the earlier NESSIE project had been broken, and it is deliberately tiny in hardware. According to this paper no attack had been published on its full version, which runs 1152 setup rounds.

How it works

  1. Set up the 288-bit state from the 80-bit key and the 80-bit initialization vector.
  2. Repeat the round update 1152 times, throwing the output bit away each time.
  3. After those setup rounds, keep updating the state and output one bit per round.
  4. Add the output bits to the plaintext bit by bit to encrypt.

Example

With an 80-bit key and an 80-bit initialization vector, encrypting is just plaintext XOR keystream once the 1152 setup rounds are done.

What to watch for

The paper gives the state size, the key and initialization-vector sizes and the round function; it does not repeat the exact loading positions, which are in the original Trivium specification. It also states only that Trivium was a candidate for the hardware profile of eSTREAM, not the competition outcome, and “no attack on the full version” means no published attack, not a proof of security.

Useful background: Stream ciphers, Initialization vectors.

Related ideas

  • Cube attack: the attack this paper pushes further against Trivium

Papers

Trivium nonlinear feedback registers

The 288 state bits of Trivium live in three shift registers of 93, 84 and 111 bits. Each register produces its next bit as an XOR of taps plus one AND of two neighbouring bits.

Why it is useful

A purely linear shift register can be broken by solving linear equations, so Trivium adds exactly one degree-2 term per register. That keeps the hardware tiny while forcing any algebraic description of the state to grow in degree.

How it works

  1. Take the taps of a register and XOR them together.
  2. Multiply two neighbouring state bits (a logical AND) and XOR that product in.
  3. Insert the result at the front of the register and shift everything by one position.
  4. Repeat for all three registers in parallel, every round.

Example

One register update reads s178,r+1 = s162,r + s177,r + s175,r · s176,r + s264,r, where · is a bitwise AND of two state bits.

What to watch for

The degree does grow, just slowly. The paper expects it to reach the maximum of 160 (there are only 160 key and initialization-vector variables) by the end of the 1152 setup rounds, which is what protects the full cipher.

Useful background: Trivium, How Trivium generates its keystream.

Related ideas

  • Cube attack: attacks the low-degree polynomials this structure produces

Papers

What a reduced-round attack margin means

A margin is the gap between the strongest published attack and the cipher as actually specified. Here the attacks reach 784 and 799 of Trivium’s 1152 setup rounds, leaving 353 rounds of headroom.

Why it is useful

Stream ciphers earn trust by being attacked and surviving. Reduced-round results are how the community measures whether that headroom is large, whether it is shrinking, and whether the best attack still costs less than simply trying all 2 to the power 80 keys.

How it works

  1. Count the rounds attacked out of the full 1152 setup rounds.
  2. Add up every phase of the attack: the offline search for relations, the online cube queries, and the final brute-force tail.
  3. Compare that total with 2 to the power 80, the cost of simply trying every Trivium key.
  4. Watch the trend over the years: 735 rounds in 2009, then 784 and 799 here, while distinguishers that only detect non-randomness already reach further.

What to watch for

A margin records what has been tried, not what is possible. The paper itself expects the cube attack to stop paying off around 900 rounds, when the degree reaches 80 and the attack becomes no better than brute force, and it says nothing about other attack families.

Useful background: Trivium, Cube attack, Quadratic superpolys.

Related ideas

  • Trivium: the cipher whose margin is being measured
  • Cube attack: the attack setting the current margin

Papers

ZUC

ZUC is a stream cipher used in mobile-communication encryption and integrity algorithms.

Papers

Tweakable cipher primitives

Keyed permutation families indexed by a public tweak, including tweak schedules and domain separation. Variable-length enciphering modes are linked separately.

CRAFT

CRAFT is a lightweight tweakable block cipher designed with fault-protection implementations in view.

Papers

SKINNY

SKINNY is a family of tweakable block ciphers.

Papers

Ciphers and hashes for encrypted or proved evaluation

Symmetric design for arithmetic circuits, Boolean MPC, lookup arguments and homomorphic transciphering. Gate count, multiplicative depth and encryption noise are different cost measures.

LowMC

LowMC is a block-cipher family designed to limit nonlinear operations in multiparty computation.

Papers

MiMC

MiMC is a family of field-based ciphers and hashes using low-degree power maps.

Papers

PASTA cipher

PASTA is a symmetric cipher intended for hybrid homomorphic encryption.

Papers

Poseidon

Poseidon is a field-based hash design using Hades-style partial and full rounds.

Papers

Algebraic hashes for proofs

Hash designs whose operations are chosen for efficient algebraic constraints.

Rescue

Rescue is a field-based hash design alternating power maps and inverse power maps.

Papers

Rescue-Prime

Rescue-Prime is a specification variant of the Rescue hash design.

Papers

Hash functions and output interfaces

A hash function is expected to resist three searches: finding two messages with the same digest (a collision), finding any input for a chosen digest (a preimage), and finding a second input for a message you were given (a second preimage). For an n-bit hash each of these should cost about 2^n work, or 2^(n/2) for collisions, and cryptanalysis is judged by how close an attack gets to those bounds and on how much of the function it covers.

Arion

Arion is an arithmetization-oriented hash function built from a triangular polynomial-system permutation.

Papers

Ascon

Ascon is a permutation-based family providing authenticated encryption and hashing.

Papers

BLAKE

BLAKE is a hash-function family using a compression function inspired by ChaCha.

Papers

Griffin hash

Griffin is an arithmetic-oriented hash design using nonlinear layers with different coordinate functions.

Papers

Kupyna

Kupyna is a hash function standardized in Ukraine.

Papers

LHash

LHash is a lightweight hash function using a sponge construction.

Papers

Monolith

Monolith is a hash-function family combining field arithmetic and binary operations.

Papers

Optimal collision resistance of iterated JH

The main result: for digest sizes c at most n/2, the c-bit JH hash built on an ideal n-bit permutation resists collisions up to about 2^(c/2) queries. Formally, the collision advantage of any adversary making q queries is at most q(q+1) over 2^(c-1).

Why it is useful

The generic birthday attack collides any c-bit hash in about 2^(c/2) evaluations, so no design can beat that scale. The theorem says chaining the weak compression step brings JH exactly to this optimum, closing the gap left by the earlier 2^(n/6) bound.

How it works

  1. Count the adversary strength by the number q of queries to the permutation or its inverse.
  2. Split the collision event into a right-half collision among reachable states plus three local configurations.
  3. Bound each piece with birthday-type probabilities (Propositions 2 and 3) and add them through inequality (2).
  4. Conclude the advantage is at most q(q+1)/2^(c-1), the birthday scale for c-bit digests.

What to watch for

The bound holds in the ideal permutation model, for c at most n/2 and q below 2^(n/2). It is a statement about the mode, not a certificate for the concrete permutation shipped in the JH submission.

Useful background: Birthday attack, The JH hash function.

Related ideas

Papers

PHOTON hash

PHOTON is a lightweight hash-function family using a sponge construction.

Papers

Polocolo

Polocolo is a field-based hash function with S-boxes using power residues.

Papers

RIPEMD-160

RIPEMD-160 is an iterated hash function with a double-branch compression structure.

Papers

SHAKE

SHAKE is a family of Keccak-based extendable-output functions.

Papers

Skyscraper

Skyscraper is a hash function designed around arithmetic over large prime fields.

Papers

Skyscraper-v2

Skyscraper-v2 is a hash-function variant designed for arithmetic over large prime fields.

Papers

SM3

SM3 is a Chinese standardized cryptographic hash function.

Papers

SPONGENT

SPONGENT is a lightweight sponge-based hash-function family.

Papers

Streebog

Streebog is the hash function specified in GOST R 34.11-2012.

Papers

Tip5

Tip5 is a hash function designed for recursive STARK applications.

Papers

Whirlpool

Whirlpool is a hash function with a block-cipher-based compression structure.

Papers

Compression and iterated hashing

Compression functions, block-cipher-to-hash constructions, domain extension, padding and iteration. Hash-state exposure and length extension depend on the interface.

Davies-Meyer compression

The Davies-Meyer construction turns a block cipher into a compression step that hashes one message block at a time. The message block is used as the cipher key, the current chaining value is encrypted under that key, and the chaining value is XORed into the ciphertext.

Why it is useful

A block cipher is built to be inverted by whoever holds the key, so on its own it cannot hide or compress anything. XORing the input back into the output removes that invertibility and gives a candidate one-way step, which is what an iterated hash needs between one message block and the next.

How it works

  1. Carry a chaining value CV from one message block to the next.
  2. Use the current message block M as the block cipher key and encrypt CV with it.
  3. XOR CV into the ciphertext to obtain the new chaining value, so H = E_M(CV) XOR CV.
  4. Skein swaps the roles: its cipher is keyed by the chaining value together with a tweak, and the message block is the plaintext.

What to watch for

The XOR feedforward protects against running the cipher backwards; it does not stop every attack. This paper attacks functions built in this mode, and separately notes that designs whose internal state is wider than the digest do not admit the same meet-in-the-middle savings.

Useful background: Merkle-Damgard construction.

Related ideas

  • Skein: A SHA-3 finalist that applies the same feedforward with the chaining value and tweak as the cipher key.
  • SHA-2: A hash family whose compression steps also come from a block-cipher-style round function.

Papers

HAIFA

HAIFA is an iterated hashing construction that incorporates a salt and a message-length counter.

Papers

Merkle-Damgard construction

Merkle-Damgard hashing processes a padded message block by block. Each compression step combines the current chaining state with the next message block, producing the state for the following step.

Why it is useful

It builds a variable-length hash from a fixed-input-size compression function.

How it works

  1. Encode and pad the message into complete blocks.
  2. Begin with the specified initial chaining value.
  3. Apply the compression function to each block and the previous state.
  4. Return the final state as the digest.

What to watch for

The paper also studies an unpadded block-aligned cascade with a secret initial state. Its security properties differ from those of an ordinary public hash. A public digest of a full-state iterated hash can enable extension calculations.

Papers

Merkle-Damgård iteration and digest truncation in JH

How JH turns its fixed-size compression step into a hash for messages of any length: an injective padding rule stretches each message to whole blocks, the state starts at a fixed initial value and is updated block by block, and the digest is the final state with its leftmost n minus c bits removed.

Why it is useful

A compression step only accepts fixed-size inputs, so something must extend it to arbitrary lengths, and something must set the output size. Both choices carry security weight here: the collision bound is proven for digest sizes up to half the state, c at most n/2.

How it works

  1. Pad the message injectively so its length becomes a multiple of the block size.
  2. Set the initial chaining value u[0] to the fixed IV.
  3. Update block by block with u[i] = F(u[i-1], M[i]).
  4. Return the last chaining value, keeping only the rightmost c bits, so the c-bit hash equals chop applied to the iterated result.

What to watch for

Because the padding is injective, the analysis can ignore it and treat the domain as all messages whose length is a multiple of n/2. A padding that mapped two messages to the same padded string would break that simplification.

Useful background: Merkle-Damgård construction, The JH compression function.

Related ideas

Papers

SHA-2

SHA-2 is a family of iterated hash functions with word-oriented compression functions.

Papers

Skein

Skein is a hash function family that the paper identifies as a SHA-3 finalist. Its 512-bit version is built from a dedicated block cipher called Threefish-512, and each compression step encrypts one message block under the current hash state and a tweak value, then adds the message block back.

Why it is useful

Every hash function needs an internal scrambling engine. Skein's designers built one block cipher and reused it: the running hash state acts as the key, a 128-bit tweak carries bookkeeping such as the position of the last message bit, and the message block is what gets encrypted.

How it works

  1. Hold eight 64-bit words of internal state and a 512-bit key; the tweak is two further 64-bit words.
  2. Run Threefish-512 for 72 rounds: four rounds of MIX and word-permutation steps, then a subkey addition, repeated through 19 subkeys.
  3. Derive each subkey from key words and tweak words; one key word is a fixed constant chosen to frustrate rotation attacks.
  4. Feed a block through F(CV, T, M) = E_{CV,T}(M) XOR M to produce the next chaining value.

What to watch for

This is the structure the attack needs, not a full specification: the rotation constants and the word permutation are left to the Skein document. The paper describes Skein as a SHA-3 finalist, which is a statement about the competition as it stood in 2011, not a prediction of its outcome.

Useful background: Davies-Meyer compression.

Related ideas

  • SHA-2: The other hash family attacked in the same paper, iterated with a word-oriented compression rule.
  • Davies-Meyer compression: The feedforward pattern Skein applies with the chaining value and tweak as the key.

Papers

The JH compression function

One compression step of JH: it takes an n-bit state u and an n/2-bit message block z and returns a new n-bit state. The block is XORed into the left half of the state, the permutation runs, and the same block is XORed into the right half of the result.

Why it is useful

This is the fixed-size core that gets chained. Because the permutation is public and unkeyed, every interaction between message and state happens through those two XOR masks, which makes the step short enough to write down exactly and to analyze.

How it works

  1. Split the state into a left and a right half of n/2 bits each.
  2. XOR the message block z into the left half, forming u XOR (z||0).
  3. Apply the permutation to that value.
  4. XOR z into the right half of the permutation output, giving v = pi(u XOR (z||0)) XOR (0||z).

Example

With n = 1024 the state is 1024 bits, each block is 512 bits, and one permutation call absorbs 512 message bits.

What to watch for

The step absorbs only n/2 message bits per permutation call, half the state size. On its own it offers no collision resistance at all: two inverse queries to the permutation already produce a collision.

Useful background: The JH hash function.

Related ideas

Papers

Sponge and duplex constructions

Absorb/squeeze and duplex modes over permutations, including hashing, keyed use and extensible output. Permutation selection and protocol framing are separate design choices.

Borderline cubes and divide-and-conquer key recovery

Take the 33-variable cube whose sums are guaranteed to be zero and delete one variable. The sums stop being forced to zero and start to depend on the values of a few particular state bits, and those bits can be chosen to be key bits, so one part of the key can be recovered while the rest is still unknown.

Why it is useful

This turns key recovery into several small, independent searches instead of one search over the whole key, which is how the paper reaches 7 rounds of the keyed sponge in about 2 to the power 97 operations when a standard cube attack would need more than 2 to the power 128.

How it works

  1. Select 32 cube variables in the lanes A[2,2] and A[2,3] so that their column parities stay constant; with this borderline cube the sums after 6 rounds provably ignore the whole lane A[1,0] yet still depend on the lane A[0,0].
  2. Preprocessing: for every possible value of the 64 bits of A[0,0], compute the cube sums and store them in a sorted list; this costs about 2 to the power 96 and 2 to the power 64 memory.
  3. Online: query the 2 to the power 32 messages of the cube, compute the sums, and look them up in the list to read off A[0,0]; repeat with variables in A[4,2] and A[4,3] to get A[1,0], then test the few remaining combinations.
  4. Using auxiliary public variables in the neighbouring lane to freeze the column parities of the first column rebalances the two phases, cutting total time to about 2 to the power 66 with only 2 to the power 32 memory, and a 64-variable borderline cube extends the whole attack to 7 rounds.
  5. Applied to 7-round Keyak the same method recovers the 252 hidden capacity bits through 8 rotated cubes, at a total cost of about 2 to the power 76.

Example

Recovering a 128-bit key as two independent 64-bit halves costs roughly two searches of 2 to the power 64 instead of one search of 2 to the power 128.

What to watch for

The attack assumes the cube sums are spread out enough that the online lookup leaves only a handful of candidate keys; the authors back this with experiments over 2 to the power 16 random keys, not with a proof, and a badly behaved distribution would inflate the final enumeration.

Useful background: Cube variables that survive the first round: column parities, Cube attacks on round-reduced Keccak.

Related ideas

  • Cube attack: the baseline this divide-and-conquer version improves on

Papers

Cube attacks on round-reduced Keccak

A cube attack treats one output bit of a keyed primitive as a polynomial in the public variables the attacker controls and the secret key bits. Summing that output over all values of a chosen set of public variables, called a cube, cancels the high-degree terms and leaves a superpoly that can be linear in the key; on a 5-round Keccak message authentication code this recovers the whole 128-bit key for about 2 to the power 35 permutation calls.

Why it is useful

One summation produces one linear equation in the secret bits, and enough independent equations solve the system by Gaussian elimination; on Keccak the per-round degree of 2 makes the work predictable, because 5 rounds have degree at most 32, so any 31-variable cube is guaranteed a linear superpoly and the linearity search can be skipped.

How it works

  1. Preprocessing, done once per design and independent of the actual key: pick cubes, evaluate the output with the key bits set to all zero and then to each unit vector, and read off the coefficients of the superpoly; keep the cubes whose superpoly is linear in key bits and discard the ones that come out constant.
  2. Online, once the key is set: sum the output over each kept cube, which equals that linear expression evaluated at the real key; repeat until there are as many independent linear equations as key bits.
  3. Pick 31 of the 128 public message variables at random and test whether the superpoly involves any key bits; the authors found 117 linearly independent expressions this way in a few days on a desktop PC.
  4. The online phase for the 5-round MAC uses 19 cubes of 31 variables each, about 2 to the power 35 output evaluations, giving 117 equations plus a guess of the remaining 11 key bits.
  5. To reach 6 rounds, undo the final nonlinear step: 960 of the 1024 available stream-cipher output bits form 192 complete 5-bit rows, each of which can be run backwards through chi and iota, leaving 5.5 effective rounds of degree at most 32.

Example

A 400-bit-state MAC with an 80-bit key falls the same way using 18 cubes, again about 2 to the power 35 work.

What to watch for

Linearity of a superpoly has to be established rather than assumed, and many cubes collapse to constants that carry no key information, since only about 20 to 25 percent were useful here; the 6-round extension also needs many output bits, so it works in stream-cipher mode or on the small 400-bit state but not on a standard 128-bit tag, and every number is for a round-reduced variant.

Useful background: Keyed modes built on the Keccak sponge, The Keccak permutation and its degree-two nonlinear step.

Papers

Cube testers: zero sums and predicting an unseen output

A cube tester does not try to recover the key. It sums an output bit over a cube and checks for behaviour a random function would not show, most simply a sum that is always zero no matter what the key is; a guaranteed-zero sum then lets the attacker compute one output they have never queried.

Why it is useful

Predicting an output for an unseen input is already a break: it forges a message tag or predicts keystream for an unused initialisation vector, without ever learning the key.

How it works

  1. Choose the cube so the polynomial degree after the attacked number of rounds stays below the cube size; the paper builds a 33-variable cube whose degree after 6 rounds is only 32, so every cube sum is zero.
  2. Collect the outputs for all cube values except one; since the total sum is zero, the missing output equals the XOR of all the others.
  3. For a 7-round MAC this becomes a forgery: query 2 to the power 65 minus 1 tags, then XOR them to obtain the tag of the one message never sent.
  4. The same prediction reaches 8 rounds with a 129-variable cube at cost 2 to the power 129, and predicts keystream for 8- and 9-round stream-cipher variants at 2 to the power 128 and 2 to the power 256, each well under the generic cost.

Example

The distinguishing property holds regardless of how many secret variables there are, where they sit, or what values they have.

What to watch for

A distinguisher proves non-randomness but recovers nothing, and the longer-range predictions are far beyond practical: the point is that they beat the generic attack cost, not that anyone can run them.

Useful background: Cube attacks on round-reduced Keccak.

Papers

Duplex construction

The duplex construction interleaves input absorption and output extraction around a permutation.

Papers

Duplex construction

A sponge-based construction that processes input in single-pass mode, used to build authenticated encryption modes. The paper references its security bound from Daemen et al. [DMA17] and Mennink [Men23].

Papers

Keccak

Keccak is a family of permutations and sponge constructions used for hashing.

Papers

Keyed modes built on the Keccak sponge

The same sponge gives a message authentication code if the secret key is written in front of the message, a stream cipher if the state is loaded with a key and a public initialisation vector and keystream is read out, and an authenticated encryption scheme such as Keyak that does both at once.

Why it is useful

Most early Keccak cryptanalysis looked only at the unkeyed hash; the keyed interfaces are what real protocols use, and they expose different amounts of input control and output to an attacker.

How it works

  1. Message authentication code: prepend the key to the message and squeeze a tag; the paper uses short messages so the permutation runs only once. No nested HMAC-style construction is needed.
  2. Stream cipher: initialise the state with the secret key followed by a public initialisation vector, run the permutation once, and XOR the r rate bits of output with the plaintext.
  3. Keyak, an authenticated encryption design submitted to the CAESAR competition, uses the Keccak permutation with a 128-bit key and tag and a capacity of 252, so its rate is 1600 minus 252, that is 1348 bits.
  4. Confidentiality in Keyak requires a nonce that is never reused; authenticity and integrity do not, and the paper exploits that difference by fixing the nonce and varying message bits instead.

Example

A tag is only 128 or 256 bits, but a stream-cipher output can be as large as the rate, which is why the stream cipher and Keyak modes are easier to attack than the MAC mode.

What to watch for

Keyak here is the 2014 competition proposal, not a final standard, and the attacks that reuse the nonce break only the properties whose specification allows a repeated nonce.

Useful background: The sponge construction: bitrate, capacity, absorb and squeeze.

Papers

Reading the security margin of round-reduced Keccak

A security margin is the distance between the number of rounds a design ships with and the number the best known attack can reach. Full Keccak uses 24 rounds; this paper reaches 9 rounds of the keyed variants, and concludes that the margin is still large, though smaller in keyed modes than in plain hashing.

Why it is useful

Round counts are the honest way to report cryptanalytic progress, because an attack on fewer rounds than the design uses does not break the design but does measure how much slack is left.

How it works

  1. The full 1600-bit Keccak permutation runs 24 rounds, and the attacks here stop at 9, so more than half the rounds remain untouched.
  2. For keyless hashing the best published attack that beats exhaustive search reaches 5 rounds, so the keyed margin looks thinner by comparison.
  3. Keyak, the Keccak-based authenticated encryption scheme, is specified with a nominal 12 rounds, so the same 9-round reach leaves it a smaller margin than the hash, which the authors still call sufficient.
  4. Treat the margin as a comparative statement about this paper's techniques, not a guarantee: later analysis, or a combination of these techniques with older ones, could move the boundary again.

Example

Nine broken rounds out of 24 leaves 15 rounds of margin, while nine broken rounds out of Keyak's nominal 12 leaves only three.

What to watch for

None of these attacks touches the full-round function, and the conclusion is specific to the keyed modes and to the 2014 Keyak proposal; the margin language describes what is known, not what is provable.

Useful background: The Keccak permutation and its degree-two nonlinear step, Keyed modes built on the Keccak sponge.

Papers

Sponge construction

The predecessor to the duplex construction, proven indifferentiable from a random oracle when the underlying permutation is random, providing the foundation for sponge-based AE modes like SpongeWrap.

Papers

The sponge construction: bitrate, capacity, absorb and squeeze

A sponge builds a hash function out of one fixed permutation. It keeps a b-bit internal state split into two parts, a rate of r bits and a capacity of c bits, with r plus c equal to b.

Why it is useful

Older hash designs chain a keyed compression function; a sponge needs only a public permutation, and the split between r and c is the single knob that trades speed against the security claim.

How it works

  1. Set the whole r plus c bit state to zero at the start, and cut the message into blocks of r bits.
  2. Absorbing: XOR one message block into the r rate bits of the state, run the permutation, repeat until the message is used up.
  3. Squeezing: read r bits of output off the state, run the permutation, read again, and stop once the digest is as long as wanted.
  4. Only the r rate bits ever touch the message or the output; the c capacity bits are mixed only by the permutation itself.

Example

With a 1600-bit state and a rate of 1024 bits, a message is absorbed 1024 bits at a time and 576 bits of state are never written or read directly.

What to watch for

The output can be made as long as wanted, so the same object is a hash, an extendable-output function or a keystream generator; the shape gives no security by itself, since everything depends on how the permutation behaves.

Related ideas

  • Hash functions: the interface the sponge provides

Papers

What the capacity parameter buys

The capacity c is the slice of the sponge state that the message never overwrites and the output never shows. In keyed use it is the hidden reservoir of state, and the claimed security level is capped by it.

Why it is useful

Raising the rate speeds up absorption and squeezing but shrinks the capacity and lowers the security ceiling; the paper shows the same trade-off from both sides, as a formula and as the set of bits an attacker is left guessing.

How it works

  1. For a keyed sponge with key length n, state size b and capacity c, the paper quotes the ideal security level as the minimum of n, c and b over 2.
  2. The default Keccak instances use a 1600-bit state with a 1024-bit or 1344-bit rate, so the capacity is 576 or 256 bits respectively.
  3. In the divide-and-conquer attacks the authors set c to 256 with a 128-bit key; the security level is then set by the key, 128 bits.
  4. In Keyak the rate is 1348, so after one known ciphertext block the attacker has seen 1348 state bits and the unknown secret state is exactly the c equals 252 capacity bits sitting in the last column of lanes.

Example

A 512-bit key with c equal to 576 and b equal to 1600 gives min(512, 576, 800), that is a 512-bit security claim.

What to watch for

The capacity caps security only while the permutation behaves as a random transformation; the attacks in the paper beat the nominal levels on round-reduced variants without ever attacking the capacity itself, by exploiting the permutation structure instead.

Useful background: The sponge construction: bitrate, capacity, absorb and squeeze.

Related ideas

Papers

Keccak and sponge-based hashes

A permutation-based hash builds the whole function from one large public permutation instead of a keyed block cipher. JH wraps a permutation-based compression step in the Merkle-Damgard transform and truncates the final state to the digest length. The permutation is public and unkeyed, so all security must come from how the mode injects and hides the message, which is why analyses treat the permutation as ideal and ask what the mode alone can guarantee.

Cube variables that survive the first round: column parities

The diffusion step theta decides what it adds to a lane by looking only at the parity of each column of five bits, not at the individual bits. Choosing cube variables so that every column parity stays fixed therefore stops theta from spreading them at all.

Why it is useful

This buys the attacker the whole first round for free: if no two cube variables share a 5-bit row after the linear half of the round, chi cannot multiply them together either, so the degree in the cube variables stays 1 after one round instead of doubling.

How it works

  1. Pick 33 variables in the lanes A[0,2] and add a matching bit in A[0,3] constrained to equal each variable XOR a fixed constant, so each column parity is the same for all 2 to the power 33 values of the cube.
  2. The rotation and lane-permutation steps then place the variables so that no row of the state holds two of them when chi runs.
  3. With degree 1 after the first round, the degree after 6 rounds is at most 32 rather than 64, which is what makes the cube sums vanish and the tester practical.
  4. On smaller states the same idea generalises: a 400-bit state with 16-bit lanes admits a cube of up to 4 times 16, that is 64, variables, with the fifth lane acting as the parity fixer.

Example

The 33-variable cube with its parity constraints is the seed from which both the tester and the divide-and-conquer key recovery are grown.

What to watch for

The gain depends entirely on placing the variables correctly, and it is a statement about the specific permutation: another diffusion layer that used bit values rather than column parities would kill the trick.

Useful background: The Keccak permutation and its degree-two nonlinear step, Cube testers: zero sums and predicting an unseen output.

Papers

SHA-3

SHA-3 is a family of sponge hash functions based on the Keccak permutation.

Papers

The JH hash function

JH is a hash function family that reached the final round of the NIST competition to replace SHA-2, alongside BLAKE, Groestl, Keccak and Skein. Its engine is a single very large fixed permutation on n bits - n = 1024 in the original submission - and the message is mixed in by a compression step built from that permutation, chained by the Merkle-Damgard transform, with the final state cut down to the digest length.

Why it is useful

Widely used hash functions were developing serious breaks, which is why NIST opened a public competition for a new one. Permutation-based designs were also harder to pin down: even with the permutation treated as a perfectly random object, JH security had no satisfying analysis, which is exactly the gap this paper fills for collisions.

How it works

  1. Pad the message into blocks and start from a fixed initial state.
  2. Feed each block through the compression step, which uses one call to the permutation.
  3. Carry the n-bit output state forward to the next block.
  4. After the last block, keep only the rightmost c bits as the digest.

Example

With n = 1024 the internal state is 1024 bits and each message block is 512 bits.

What to watch for

This paper studies the mode of operation and treats the permutation as an ideal random object. It says nothing about the round function inside the actual JH permutation, so none of its bounds measure attacks on the permutation itself.

Useful background: Cryptographic hash function, Random permutation.

Related ideas

Papers

The Keccak permutation and its degree-two nonlinear step

Keccak-f is the permutation inside the sponge. Its state is a 5 by 5 array of 64-bit lanes, 1600 bits in the default version, and the number of rounds depends on the state size, 24 for that default. Each round is built from five named steps, of which only one is nonlinear.

Why it is useful

Every algebraic attack in the paper is priced off this layout: the nonlinear step chi has algebraic degree only 2 over the binary field, and it works on each 5-bit row on its own, which makes the degree easy to bound and the last step easy to undo.

How it works

  1. Picture the state as a 5 by 5 grid of 64-bit words called lanes; a bit is addressed by three coordinates x, y and z.
  2. Theta, rho and pi are the linear half of a round: theta XORs column parity information across the state for diffusion, rho rotates bits inside each lane, and pi moves whole lanes to new grid positions.
  3. Chi is the only nonlinear step, a layer of 5-bit substitution boxes, one per row of the state; its algebraic degree over GF(2) is only 2, and it only multiplies neighbouring bits in a row.
  4. Iota XORs a constant that changes from round to round.
  5. Because chi acts on each row independently, anyone who knows all 5 bits of a row can run chi and iota backwards on that row, which is how the attacks peel the final nonlinear layer off.

Example

After 5 rounds the degree is at most 2 to the power 5, that is 32, which is why a 31-variable cube already gives a linear expression.

What to watch for

A degree bound of 2 per round is a worst case that only holds while the degree stays below the number of state bits, and real diffusion in the first rounds is slower than the bound; that gap between the bound and the true degree is where the attacks live.

Useful background: The sponge construction: bitrate, capacity, absorb and squeeze.

Papers

Tree and parallel hashing

Parallel digest construction, tree encodings, domain separation and incremental hashing. Hashing a tree is not the same interface as producing authenticated membership proofs.

BLAKE3

BLAKE3 is a tree-hashing construction with a BLAKE-derived compression function.

Papers

Sakura encoding

Sakura is a coding scheme for constructing tree-hash inputs.

Papers

Key derivation and key separation

Key derivation begins with a description of the available secret. Extraction handles an imperfect source; expansion uses a suitable secret key to produce outputs for specific purposes. Public salt and context have different jobs, and neither creates secret entropy. Distinct key uses need distinct encodings, while password guessing requires a separate cost-increasing design.

Context-bound key separation

Context-bound derivation uses distinct labels and protocol information to derive different keys from the same source secret. The context describes what a key is for.

Why it is useful

It reduces accidental reuse between directions, algorithms, protocol stages or applications that share underlying secret material.

How it works

  1. Define the key purposes that must remain separate.
  2. Encode the purpose and other needed context fields unambiguously.
  3. Use those encoded values as inputs to the expansion function.
  4. Keep enough secret-source entropy after conditioning on any public context.

Example

A protocol can use separately encoded labels for a client-to-server encryption key and a server-to-client encryption key, rather than requesting the same unlabeled key twice.

What to watch for

Distinct meanings need distinct encodings. Putting a secret into public context can disclose it, and labels do not authenticate a peer or validate a handshake. This paper does not prescribe one universal context format.

Useful background: Unambiguous encoding.

Papers

Derived-key length and security strength

Producing more key bits does not create more source entropy or automatically increase the work required to break the derivation. Security also depends on the extracted key size, primitives, exposed outputs and attacker resources.

Why it is useful

It prevents treating a long output string as a security-level certificate.

How it works

  1. Track source uncertainty after side information.
  2. Track the size and strength of the intermediate key and expansion primitive.
  3. Account for information exposed through other derived keys or their use.
  4. Use the construction's actual security argument rather than counting output bytes.

What to watch for

The paper does not claim that expanding a k-bit intermediate key yields more than k-bit exhaustive-search resistance. Its comparison attack assumes a special enumerable two-part source and exposed or testable outputs; it is not a general practical attack on HKDF.

Papers

Domain separation by reserved input bits

A cryptographic function may be used for several jobs. Domain separation makes the inputs for those jobs distinguishable, so a value used for one purpose cannot accidentally be reused as an input for another.

Why it is useful

In the paper's two-key GCM-SIV variant, this permits one AES key to serve both tag generation and counter-mode encryption without the two input families overlapping.

How it works

  1. Assign a different reserved-bit value to each purpose.
  2. Construct every tag-generation input in one of those domains.
  3. Construct every encryption-counter input in the other domain.
  4. Prove that the two kinds of input cannot coincide.

What to watch for

This technique is specific to a construction with room for reserved bits and a proof that accounts for the reduced input space. Adding a label somewhere unrelated does not establish separation.

Related ideas

Papers

Extract-then-expand key derivation

Extract-then-expand separates two jobs: concentrate suitable source randomness into a fixed-size pseudorandom key, then use that key to derive context-specific output strings.

Why it is useful

Extraction and expansion require different properties. Keeping the jobs separate makes the assumptions and interfaces easier to analyze.

How it works

  1. Run an extractor on the source material, using a salt where the construction requires it.
  2. Use the extracted key as the key to a pseudorandom function.
  3. Give the expansion function a context and desired output length.
  4. Separate key purposes by distinct, unambiguously encoded contexts.

What to watch for

The composition theorem assumes that extraction remains secure given the attacker's side information and that expansion is secure under a suitable random key. PRF security alone does not establish extraction from every imperfect source.

Useful background: Key derivation function, Computational randomness extractors, Pseudorandom functions.

Papers

Extracting keys from Diffie-Hellman values

A Diffie-Hellman shared group element has a structured encoding and is not automatically a uniformly distributed bit-string key. A KDF converts that shared value into the key format required by the application.

Why it is useful

It connects a group-based key exchange to symmetric algorithms without confusing group secrecy with bit-string uniformity.

How it works

  1. Validate the group and peer inputs as required by the exchange.
  2. Compute and encode the shared value.
  3. Choose an extraction argument matching the protocol's secrecy assumptions and source distribution.
  4. Bind the resulting keys to their protocol context.

What to watch for

DDH-based pseudorandomness of group elements and CDH-based difficulty of computing a value are different starting points. The paper uses stronger or idealized hash assumptions for some CDH-only or dependent-session cases. A KDF cannot make an invalid or publicly known shared value secret.

Useful background: Computational entropy in shared secrets, HKDF.

Papers

Feedback expansion of pseudorandom functions

Feedback expansion generates several blocks by feeding the previous pseudorandom block into the next invocation, together with context and a counter.

Why it is useful

It extends a fixed-output pseudorandom function to the output lengths needed by a protocol.

How it works

  1. Start with the specified first-block input.
  2. Generate each later block using the previous block and the application context.
  3. Include a correctly encoded, nonwrapping counter.
  4. Concatenate blocks and truncate to the requested length.

What to watch for

A strong PRF also supports counter-mode expansion. The paper presents the extra cryptanalytic benefit of feedback as a design rationale, not a theorem that counter mode is insecure. The construction is deterministic and does not add entropy.

Useful background: Pseudorandom functions.

Papers

HKDF

HKDF is an HMAC-based extract-then-expand construction. Extraction uses the salt as the HMAC key and the source material as its message. Expansion uses the resulting pseudorandom key to generate output blocks.

Why it is useful

The same available HMAC primitive can support both stages, while the design keeps their different security requirements explicit.

How it works

  1. Extract a pseudorandom key by applying HMAC to the source material under the salt.
  2. For expansion, key HMAC with that extracted key.
  3. Generate blocks using the application context, a counter and, after the first block, the previous block.
  4. Concatenate the blocks and take the requested output length.

What to watch for

A public salt does not act like HMAC's usual secret authentication key; extraction needs its own argument. The retained paper is a historical presentation with counter and final-block edge cases, not an implementation-ready byte specification. Use the applicable specification and test vectors for interoperability.

Useful background: HMAC, Extract-then-expand key derivation.

Papers

Key derivation function

A key derivation function turns suitable secret key material into the keys needed by an application. Its inputs may include an output length, a public salt and information identifying the intended use of each key.

Why it is useful

A shared secret or a noisy source is not automatically in the form required by an encryption or authentication algorithm. A KDF also lets one secret support several distinct uses.

How it works

  1. Describe the source secret and what an attacker already knows about it.
  2. Derive key material using a construction justified for that source.
  3. Bind each intended use to a distinct context.
  4. Return the required number of bits without treating extra output length as extra source entropy.

What to watch for

A KDF cannot repair a known secret, an unauthenticated exchange or an invalid group input. Its guarantees depend on the source, not just the name of the hash function.

Papers

Output prefixes in key expansion

When output length only controls how much of an expansion stream is returned, a shorter request gives a prefix of a longer request made with the same key and context.

Why it is useful

It prevents a mistaken assumption that requesting different lengths creates independent keys.

How it works

  1. Identify whether the requested length is included in the expansion input or only used for truncation.
  2. Keep key purposes in distinct contexts when independence is required.
  3. If a protocol needs different lengths to identify different derivations, bind the length into its context encoding.
  4. Specify how a combined output is divided when a protocol intentionally derives a key bundle.

What to watch for

Prefix consistency is expected behavior, not a break of the paper's KDF game: its test context must differ from exposed contexts. The first 16 bytes of a 32-byte result are not an independent second key.

Useful background: Context-bound key separation.

Papers

Prefix constraints from the GGM tree

A prefix-constrained key works on all inputs that begin with a fixed bit string v. For this family no new assumption is needed: the constrained key is simply the key stored at the node labelled v in the GGM key tree.

Why it is useful

This is hierarchical key derivation in disguise. The GGM construction grows a binary tree of keys from any length-doubling generator, and a node key opens the whole subtree below it, so handing out the node for v is exactly handing out a labelled subkey that derives everything under that label.

How it works

  1. Run the GGM construction: a length-doubling pseudorandom generator turns the master key into a binary tree of keys, with the master key at the root and each input bit selecting a child on the way down.
  2. To constrain to the prefix v, release the node key reached by following the bits of v.
  3. That key evaluates the PRF at v followed by any continuation, without revealing node keys outside that subtree.

Example

A key issued for the prefix 0110 derives keys for 01100011, 01101110 and every other string starting with 0110, and nothing else.

What to watch for

The security argument is straightforward only when the adversary commits to its challenge point ahead of time; full security again costs a complexity-leveraging guess. The paper notes the same tree idea had already appeared inside combinatorial broadcast encryption.

Useful background: What a constrained PRF is.

Related ideas

Papers

Salt independence in key derivation

An extraction salt selects which member of an extractor family is used. In the generic seeded argument, it is random and independent of the source distribution, but need not be secret.

Why it is useful

This independence rules out sources tailored to be poorly handled by one particular extraction function.

How it works

  1. Determine how the salt is obtained and what can influence it.
  2. Ensure the source model remains valid after the salt becomes known.
  3. Authenticate protocol-carried salt when active substitution would invalidate the argument.
  4. If salt is fixed or absent, use a source-specific justification instead of silently assuming the generic seeded theorem.

What to watch for

Salt reuse is not automatically a failure: the paper allows an independently chosen public seed to be reused for suitable independent samples. Conversely, a fresh attacker-controlled value is not necessarily a suitable independent salt. Salt creates no new secret entropy.

Papers

Password hashing and password-based KDFs

Salted password processing, memory hardness, time-memory tradeoffs, peppers and offline-guessing cost. PAKE supplies protocol-level properties beyond password hashing.

Argon2

Argon2 is a family of memory-hard password-hashing functions.

Papers

Balloon hashing

Balloon hashing expands and mixes a password-dependent memory buffer.

Papers

Password stretching versus key expansion

Password stretching deliberately makes each password guess more expensive. Key expansion instead efficiently derives several outputs from a secret that is already suitable for cryptographic use.

Why it is useful

A long derived key does not remove the low-entropy guessing problem of a human password.

How it works

  1. Use a password-specific derivation design when the source is a password.
  2. Use a salt according to that design to limit reuse of precomputed guesses.
  3. Set an appropriate cost for each derivation.
  4. If several application keys are needed, expand the resulting suitable key under distinct contexts.

What to watch for

Ordinary HKDF is intentionally efficient and supplies no password-stretching cost by itself. Stretching raises the cost per guess, not the password's entropy. This historical paper does not analyze current memory-hard password schemes or their parameters.

Papers

scrypt

scrypt is a password-based key-derivation algorithm that uses memory-intensive mixing.

Papers

Memory-hard password hashing

Password-hashing functions and their time-memory tradeoffs.

Symmetric encryption constructions

Message encryption organized by interface, length constraints and integrity guarantees. Deterministic behavior or tweakability does not itself supply authentication.

Ciminion

Ciminion is a symmetric-encryption construction using Toffoli-style operations over large finite fields.

Papers

Ciphertext indistinguishability from random bits

Some encryption definitions require ciphertexts to be indistinguishable from uniformly random strings of the same length. This is stronger than merely hiding which of two messages was encrypted.

Why it is useful

A construction that embeds ciphertext bits into a balanced cover channel needs those bits to look random, not simply to hide their plaintext.

How it works

  1. Compare access to the encryption procedure with access to uniformly random strings of matching lengths.
  2. Allow the chosen-message queries specified by the definition.
  3. Bound the observer's ability to tell which source it is using.

What to watch for

Ordinary message confidentiality does not imply this property. Public headers or fixed-format ciphertext components can distinguish ciphertexts from random strings without exposing the message.

Papers

Rubato

Rubato is a symmetric cipher designed for use with approximate homomorphic encryption.

Papers

Authenticated encryption and AEAD

Hiding a message and detecting changes are different jobs. Authenticated encryption provides both; associated data lets you protect readable context, such as a header, alongside the encrypted message.

AEGIS

AEGIS is an authenticated-encryption family using AES round operations.

Papers

Ascon

A duplex-based AE mode (NIST Lightweight Cryptography winner) mentioned as not describable in terms of MonkeySpongeWrap due to its unique key-blinding technique.

Papers

Authenticated encryption with associated data

Authenticated encryption hides a message and checks that its protected contents have not been altered. Associated data is additional information, such as a packet header, that must be checked but need not be hidden.

Why it is useful

A receiver usually needs both secrecy and a way to reject forged or modified messages. Encrypting data without authenticating it does not provide both guarantees.

How it works

  1. Give the encryption algorithm a secret key, a nonce, the message and any associated data.
  2. Send the encrypted message and its authentication tag; associated data may remain readable.
  3. The receiver uses the same associated data when checking the tag.
  4. Accept the plaintext only if verification succeeds.

Example

A packet can encrypt its payload while authenticating a readable sequence number as associated data. Changing that sequence number then invalidates the tag.

What to watch for

Authentication is tied to the supplied context and the mode's nonce rules. It does not by itself establish who owns a key or prevent replay of an otherwise valid message.

Papers

CCM

CCM combines counter-mode encryption with CBC-MAC authentication.

Papers

Ciphertext integrity

Ciphertext integrity prevents an attacker from creating any accepted ciphertext that the encryption interface did not previously issue, even if it decrypts to an old message.

Why it is useful

It protects the complete accepted ciphertext representation rather than only the novelty of the underlying plaintext.

How it works

  1. Record ciphertexts issued by the encryption interface.
  2. Allow the attacker to submit candidate ciphertexts for validation.
  3. Reject malformed or unauthenticated candidates.
  4. Count a forgery when a new ciphertext is accepted.

What to watch for

Replaying an issued ciphertext is not a win in this game. Replay prevention needs additional protocol state or policy. Ciphertext integrity alone also does not hide plaintext contents.

Related ideas

  • Plaintext integrity: Is implied by ciphertext integrity under the paper's correctness and decryption conditions.

Papers

Combining ciphertext integrity with confidentiality

For the symmetric-encryption model in this paper, ciphertext integrity together with chosen-plaintext confidentiality implies chosen-ciphertext confidentiality.

Why it is useful

If an attacker cannot create a fresh accepted ciphertext, a decryption oracle mostly returns rejection and gives no useful extra view of protected messages.

How it works

  1. Start from a scheme meeting both component security goals.
  2. Exclude challenge ciphertexts from decryption queries.
  3. Bound the probability that another submitted ciphertext is accepted.
  4. Outside that forgery event, replace the decryption oracle with one that always rejects.
  5. Use chosen-plaintext confidentiality for the remaining experiment.

What to watch for

Replacing ciphertext integrity with plaintext integrity is insufficient. The theorem also assumes correct encryption and deterministic, stateless decryption; it does not substitute for analysis of implementation leakage.

Papers

Deoxys

Deoxys is an authenticated-encryption family built around an AES-like tweakable block cipher.

Papers

Elephant

Elephant is a family of permutation-based authenticated-encryption schemes.

Papers

Encrypt-and-MAC composition

Encrypt-and-MAC encrypts the plaintext and separately authenticates that plaintext, then sends the ciphertext and tag together.

Why it is useful

It is a natural attempt to combine an existing encryption scheme with an existing authentication scheme, but the exposed plaintext tag can undermine confidentiality.

How it works

  1. Generate independent encryption and authentication keys.
  2. Encrypt the message.
  3. Compute a tag directly on the same message.
  4. Transmit both results and verify the tag after recovering the message.

What to watch for

Generic forgery resistance does not promise tag privacy. Even a random-looking deterministic tag reveals repeated plaintexts. The paper's negative result is about generic composition, not every protocol variant that uses a related ordering.

Useful background: Message authentication codes.

Papers

Encrypt-then-MAC composition

Encrypt-then-MAC encrypts the plaintext and authenticates the resulting complete ciphertext. With the paper's component assumptions, it provides both confidentiality and ciphertext integrity.

Why it is useful

It allows an invalid ciphertext to be rejected through its authentication tag before plaintext is released or acted on.

How it works

  1. Generate independent encryption and authentication keys.
  2. Encrypt the plaintext using a chosen-plaintext-secure scheme.
  3. Authenticate the complete ciphertext representation, including fields needed for its interpretation.
  4. Transmit an unambiguous encoding of ciphertext and tag.
  5. Verify the tag before accepting or acting on decrypted data.

What to watch for

The generic ciphertext-integrity theorem requires strong tag unforgeability. A reused key, omitted ciphertext field or ambiguous parsing changes the construction. Associated data and replay protection need explicit protocol treatment.

Useful background: Ciphertext integrity, Strong unforgeability for authentication tags, Unambiguous encoding.

Papers

GCM

GCM combines counter-mode encryption with polynomial authentication over a binary field.

Papers

GIFT-COFB

GIFT-COFB is an authenticated-encryption scheme combining GIFT with the COFB mode.

Papers

Gilbert et al. forgery attack

A forgery attack covering duplex-based AE modes where the key is incorporated once during initialization. Exploits the fact that F_beta(x) = floor(p(beta||x))_c behaves like a random function, requiring an offline permutation query phase followed by online decryption queries.

Papers

How TinyJAMBU absorbs the nonce, data and tag in 32-bit blocks

The mode works in four phases: initialization from the all-zero state, associated-data processing, encryption, and finalization that produces the tag. Everything moves through the 128-bit state 32 bits at a time, so a 96-bit nonce takes three blocks and a 64-bit tag takes two.

Why it is useful

The block structure decides where an attacker can inject a difference and where one can be observed, so it is the part of the design the later attacks lean on.

How it works

  1. Initialization runs the long permutation, then absorbs the three nonce blocks.
  2. Associated-data and message steps XOR a 3-bit frame bit value (3 for associated data, 5 for plaintext, 7 for finalization) to separate the phases, run a permutation, then absorb or extract 32 bits.
  3. The tag is squeezed as two 32-bit halves, each after its own permutation call.
  4. Nonce setup, associated-data processing and the second half of the tag run the short 384-round permutation; initialization, encryption and the first tag half run the much longer one.

What to watch for

Absorbing and squeezing only 32 bits per block is exactly what keeps the implementation small, and it is also what splits the nonce and the tag across several blocks; the paper flags that this split is a structural weakness, not a bug in the code.

Useful background: TinyJAMBU.

Related ideas

Papers

ISAP

ISAP is an authenticated-encryption family designed for implementations with side-channel countermeasures.

Papers

MAC-then-encrypt composition

MAC-then-encrypt computes an authentication tag on the plaintext, appends it and encrypts the combined encoding. The receiver decrypts before checking the recovered tag.

Why it is useful

It hides the authentication tag as well as the message, avoiding the exposed deterministic-tag problem of plain Encrypt-and-MAC.

How it works

  1. Generate independent encryption and authentication keys.
  2. Compute a tag on the plaintext.
  3. Encode plaintext and tag unambiguously, then encrypt them together.
  4. Decrypt, parse and verify before accepting the plaintext.

What to watch for

The generic theorem supplies chosen-plaintext confidentiality and plaintext integrity under the component assumptions, but not full ciphertext integrity or chosen-ciphertext confidentiality. Specific instantiations need a separate analysis.

Papers

MORUS

MORUS is an authenticated-encryption design with a bitwise state-update function.

Papers

Multiplex AE

Multiplex is an authenticated-encryption mode based on tweakable block ciphers.

Papers

NeevAs

NeevAs is a lightweight authenticated-encryption design.

Papers

OCB

OCB is a block-cipher authenticated-encryption mode using offsets.

Papers

PHOTON-Beetle

PHOTON-Beetle is an authenticated-encryption and hashing design using the PHOTON permutation.

Papers

Plaintext integrity

Plaintext integrity prevents an attacker from creating an accepted ciphertext whose decrypted message was never previously encrypted by the sender.

Why it is useful

It captures the goal of preventing fabricated new messages, while allowing a distinction between message authenticity and the exact ciphertext representation.

How it works

  1. Allow the attacker to obtain encryptions of chosen messages.
  2. Record those messages.
  3. Let the attacker submit candidate ciphertexts for validation.
  4. Count a forgery when an accepted ciphertext decrypts to a message outside the record.

What to watch for

It does not rule out a new ciphertext encoding of an old plaintext. Even combined with chosen-plaintext confidentiality, it does not generically imply chosen-ciphertext confidentiality.

Papers

Rocca

Rocca is an authenticated-encryption design using AES round operations.

Papers

Romulus

Romulus is an authenticated-encryption family built from a tweakable block cipher.

Papers

Security-proof online complexity (sigma_D)

An adversarial online complexity metric used in security proofs of duplex-based AE modes that does not double-count permutation evaluations on repeated paths. For the attack, this gives sigma_D = 2^(c/2).

Papers

SpongeWrap

An early duplex-based authenticated encryption mode mentioned as one of the modes covered by the Gilbert et al. forgery attack. Proven secure using sponge indifferentiability results.

Papers

TinyJAMBU

TinyJAMBU is a family of authenticated encryption schemes: with one shared secret key it scrambles a message into ciphertext and appends a 64-bit authentication tag that reveals tampering. A nonce (a number meant to be used once) and any associated data are mixed in as well.

Why it is useful

It was designed by Wu and Huang as a shrunken version of the JAMBU mode from the CAESAR competition, and when this paper was written it was one of the 32 second-round candidates in the NIST lightweight cryptography standardization process, so an independent check of its security numbers mattered for the selection.

How it works

  1. Three variants, TinyJAMBU-128, -192 and -256, named after the key size in bits; all three share a 128-bit internal state, a 96-bit nonce and a 64-bit tag.
  2. The short keyed permutation P K runs 384 rounds in every variant and covers nonce setup, associated-data processing and the second half of the tag; the long permutation covers initialization, encryption and the first tag half, and runs 1024, 1152 or 1280 rounds.
  3. Claimed security with unique nonces: 112, 168 or 224 bits of confidentiality depending on the key size, and 64 bits of authenticity for all variants.
  4. The NIST process received 57 submissions in 2019, kept 56 as first-round candidates, and announced the 32 second-round candidates on August 30, 2019, with a second round expected to last twelve months.

Example

TinyJAMBU-128 is the smallest variant: a 128-bit key, a 128-bit state, and a claim of 64-bit security against forgeries.

What to watch for

The competition status reported here is the one stated in this 2020 paper; later rounds of the standardization process are outside this reading, and the paper analyses the design rather than endorsing or breaking it.

Related ideas

Papers

Confidentiality modes and storage encryption

Block-cipher modes for messages and storage units, including chaining, counters, ciphertext stealing and narrow-block tweaks. Integrity must be stated separately.

Counter-mode encryption

Counter mode turns a block cipher into a stream of secret masks. It encrypts a sequence of counter values and combines each resulting block with the message using exclusive OR, or XOR.

Why it is useful

Different counter blocks can be processed independently, making this a fast way to encrypt long messages.

How it works

  1. Construct distinct counter blocks from a starting value and a block counter.
  2. Encrypt those counter blocks with the secret key to obtain the mask stream.
  3. XOR the stream with the plaintext to encrypt, or with the ciphertext to decrypt.

Example

As a toy XOR illustration, ciphertexts C1 = M1 XOR S and C2 = M2 XOR S satisfy C1 XOR C2 = M1 XOR M2. The reused mask S cancels.

What to watch for

Reusing the same mask stream exposes the XOR of the two plaintexts. Counter mode also needs an authentication mechanism; encryption alone does not detect changes.

Papers

MonkeySpongeWrap

A duplex-based authenticated encryption mode operating on a b-bit state split into r-bit outer and c-bit inner parts, with encryption and decryption functions Ep_K and Dp_K instantiated with a cryptographic permutation p.

Papers

SCB mode

SCB is a length-preserving symmetric-encryption mode.

Papers

XTS

XTS is a tweakable block-cipher mode used for storage encryption.

Papers

Format-preserving and small-domain encryption

Encryption over constrained alphabets, numeric domains and structured formats using encodings and finite-domain permutations. Tokenization and property-preserving search have separate threat models.

FNR

FNR is a small-domain block-cipher construction for variable input lengths.

Papers

Nonce misuse and reset resilience

Guarantees under repeated nonces, synthetic-IV constructions, deterministic authenticated encryption and state resets. Misuse resistance can still leak equality or other information.

AES-GCM-SIV

AES-GCM-SIV is a synthetic-IV authenticated-encryption construction using AES and polynomial hashing.

Papers

Encryption nonces

A nonce is an extra input used to distinguish encryption operations under the same key. Many encryption modes require every nonce to be different; a nonce is not normally a second secret key.

Why it is useful

Nonce rules stop separate encryptions from accidentally reusing internal values whose repetition would reveal data or enable forgery.

How it works

  1. Follow the nonce requirement of the chosen encryption mode rather than assuming all modes have the same rule.
  2. A counter can provide uniqueness if it is not reset or reused with the same key.
  3. Randomly chosen nonces can collide, so randomness does not make repetition impossible.

What to watch for

The term initialization vector is also used in encryption, but some modes require an unpredictable random value rather than uniqueness alone. A nonce in a digital signature has different requirements from the encryption inputs discussed here.

Related ideas

Papers

Nonce-misuse-resistant authenticated encryption

This kind of authenticated encryption is designed to retain its protection even when an encryption nonce is accidentally reused. It still reveals repetition when the nonce, message and associated data are all identical.

Why it is useful

A reset counter or a broken random generator can otherwise turn a routine encryption mistake into loss of both secrecy and authenticity.

How it works

  1. Bind the nonce, associated data and complete message into a secret-key computation.
  2. Use the result to derive the encryption's internal starting value.
  3. Check the same binding when decrypting.

What to watch for

Misuse resistance is not permission to ignore the scheme's limits. It does not hide exact repeated inputs or message length, and full misuse resistance costs an extra pass over the plaintext.

Related ideas

  • SIV mode: A general approach for obtaining this property.

Papers

SIV mode

Synthetic initialization vector mode, or SIV, first computes an authentication value from the message and its context. It then uses that value to determine how the message is encrypted.

Why it is useful

Because the internal starting value depends on the entire message, repeating an external nonce does not automatically repeat the same encryption mask for different messages.

How it works

  1. Encode the nonce, associated data and plaintext without ambiguity.
  2. Compute a keyed pseudorandom tag for that encoded input.
  3. Derive the encryption starting value from the tag and encrypt the message.
  4. On decryption, recover the message, recompute the tag and reject a mismatch.

What to watch for

The complete plaintext must be processed before encryption can use the synthetic starting value. Repeating all the inputs produces the same ciphertext.

Useful background: Authenticated encryption with associated data, Unambiguous encoding.

Papers

GCM-SIV (original construction)

The original GCM-SIV construction combines GHASH, AES and the synthetic-IV approach. It hashes the plaintext and associated data before generating the tag used for counter-mode encryption.

Why it is useful

It reuses much of the hardware-friendly machinery of GCM while protecting against accidental nonce reuse.

How it works

  1. Encode and hash the plaintext and associated data with GHASH.
  2. Combine the result with the nonce and apply AES to produce the synthetic tag.
  3. Encrypt using counters derived from that tag.
  4. On decryption, recompute the tag from the recovered message and reject a mismatch.

What to watch for

This is the construction described in the original GCM-SIV paper, not a substitute specification for later AES-GCM-SIV standards. The retained paper also corrects a security-bound factor from an earlier version.

Related ideas

  • AES-GCM-SIV: The later standardized construction has a similar name but a different specification.

Papers

Universal-SIV

Universal-SIV builds a synthetic initialization vector using a fast keyed universal hash followed by a pseudorandom function. The hash handles the long message; the second function turns the result and nonce into the tag.

Why it is useful

It separates fast message processing from the short cryptographic operation that produces the synthetic starting value.

How it works

  1. Hash an unambiguous encoding of the associated data and plaintext with the universal-hash key.
  2. XOR the nonce into that hash result, then apply the keyed pseudorandom function to obtain a tag.
  3. Use tag-derived counters to encrypt the message.
  4. Decrypt and recompute the tag before accepting the plaintext.

What to watch for

The paper starts with independent keys for hashing, tag generation and counter-mode encryption. Reducing the number of keys requires a separate argument; it is not an arbitrary implementation shortcut.

Papers

Wide-block and variable-length enciphering

Length-preserving tweakable permutations over whole messages or data units, including hash-encrypt-hash and hash-counter constructions. This does not imply ciphertext integrity.

HCTR2

HCTR2 is a tweakable enciphering mode combining block-cipher calls and universal hashing.

Papers

Symmetric message authentication

Shared-secret authentication interfaces, variable-length tags and composition of hashing with secret masking or encryption. Publicly verifiable signatures have their own root.

KMAC

KMAC is a Keccak-based message-authentication construction.

Papers

PMAC

PMAC is a parallelizable block-cipher message-authentication construction.

Papers

Message authentication codes

An authentication tag lets parties sharing a secret check whether a message was created by someone with that secret. The tag does not conceal the message. A pseudorandom-function guarantee is stronger and matters when the same primitive is used for tasks such as key derivation.

CBC-MAC

CBC-MAC computes an authentication tag by chaining block-cipher evaluations over message blocks.

Papers

CMAC

CMAC is a block-cipher MAC derived from CBC-MAC with final-block subkeys.

Papers

HMAC

HMAC authenticates a message by hashing it with an inner masked key block, then hashing the result with a different outer masked key block. It can use an ordinary hash implementation without exposing a custom initial-state interface.

Why it is useful

It provides a keyed authentication construction without relying on the unsafe assumption that merely prepending a secret to a public hash is enough.

How it works

  1. Normalize the key according to the selected HMAC specification.
  2. XOR the normalized key block with the inner pad and hash it followed by the message.
  3. XOR the same key block with the distinct outer pad.
  4. Hash the outer key block followed by the inner digest.

What to watch for

The paper's NMAC theorem does not transfer to standard single-key HMAC without an additional assumption about two related data-input keys. Long-key preprocessing also needs its own argument. The discussion of MD5 and SHA-1 is historical, not a recommendation to choose them today.

Useful background: Message authentication codes, Merkle-Damgard construction, NMAC.

Papers

Keyed hash-then-PRF composition

The paper proves that an independently keyed pseudorandom outer function can turn a computationally almost-universal inner function into a pseudorandom function on longer messages.

Why it is useful

The inner layer compresses the message; the outer layer hides its value and gives unpredictable tags unless distinct messages collide internally.

How it works

  1. Compute the inner keyed function on the message.
  2. Apply the outer pseudorandom function under a separate key.
  3. In the proof, replace the outer function with a random function.
  4. Bound the chance that two distinct queried messages have the same inner value.

What to watch for

The keys are independent in this composition theorem. A collision at the inner layer survives the outer function, and an unkeyed hash with a different collision property cannot be substituted without another argument.

Related ideas

Papers

Message authentication codes

A message authentication code uses a shared secret key to produce a tag for a message. Someone without the key should be unable to produce an accepted tag for a new message, even after requesting tags for other messages.

Why it is useful

It detects unauthorized changes or fabrications when sender and receiver share a secret.

How it works

  1. Generate a secret authentication key.
  2. Compute a tag over the complete message representation.
  3. The receiver checks the claimed tag using the same key.
  4. Define security against tag-generation queries and attempted verification queries.

What to watch for

Authentication does not hide the message or prevent replay of an already valid message-tag pair. A secure authentication code also need not produce outputs suitable for every use requiring a pseudorandom function.

Papers

NMAC

NMAC uses one secret key as the initial state for an inner iterated hash, then authenticates the resulting digest with a separately keyed outer compression step.

Why it is useful

The outer step protects the inner result and supports variable-length authentication even though the raw inner cascade permits extension.

How it works

  1. Use the inner key as the initial chaining state.
  2. Process the encoded message through the compression function.
  3. Format the inner digest as the outer compression input.
  4. Apply the outer compression function with an independent secret key.

What to watch for

The principal theorem assumes the compression function is pseudorandom when keyed through its chaining-state input. The generalized theorem handles nonempty block-aligned strings; arbitrary messages still need an unambiguous encoding into that domain.

Useful background: Pseudorandom functions, Merkle-Damgard construction.

Related ideas

  • Computational almost universality: The inner cascade has the collision property used in the proof.
  • HMAC: Obtains internal chaining keys through ordinary hash calls instead of setting them directly.

Papers

Poly1305

Poly1305 is a polynomial message-authentication construction over a prime field.

Papers

Privacy-preserving authentication codes

A privacy-preserving authentication code combines forgery resistance with a restricted indistinguishability property for tags of distinct chosen inputs. It can be weaker than a pseudorandom function.

Why it is useful

It identifies a sufficient outer-function property when the goal is authentication rather than full pseudorandomness.

How it works

  1. Require ordinary message-authentication security.
  2. Compare tags for the left and right sides of chosen input pairs.
  3. Disallow repeated inputs within either side, which would reveal deterministic equality patterns.
  4. Use this privacy property together with the inner function's collision bound.

Example

Appending a fixed zero bit to every tag can preserve the stated privacy and authentication properties while making the output distinguishable from a random function.

What to watch for

This restricted tag-privacy property does not encrypt the message. Privacy alone is insufficient: a constant-output function satisfies the privacy test but is trivially forgeable.

Papers

Strong unforgeability for authentication tags

Strong unforgeability prevents a new accepted message-tag pair, including a different valid tag for a message that was already authenticated.

Why it is useful

A composition can fail if an attacker merely changes the tag representation of an existing ciphertext, without forging a tag on a new ciphertext.

How it works

  1. Record every message-tag pair issued by the authentication interface.
  2. Give the attacker the prescribed tag and verification queries.
  3. Treat any new accepted pair as a forgery.
  4. Distinguish this from ordinary unforgeability, which only counts new messages.

What to watch for

The requirement concerns the whole pair: the message need not be new. An ignored extra tag bit can preserve ordinary unforgeability while violating strong unforgeability.

Papers

Universal hashing and algebraic authenticators

Universal and almost-universal hash families, polynomial evaluation and collision bounds used inside authentication. A universal hash alone is not generally a reusable secure MAC.

Computational almost universality

A keyed function is computationally almost universal when an efficient attacker cannot choose two distinct messages likely to collide under a fresh hidden random key, without receiving information about that key.

Why it is useful

It is the limited collision guarantee needed for the inner stage of the paper's authentication proof.

How it works

  1. The attacker chooses two distinct messages without a keyed-function oracle.
  2. Sample the secret key independently.
  3. Evaluate both messages under that key.
  4. Bound the probability that the outputs match.

What to watch for

Giving the attacker keyed evaluations changes the game. This property is weaker than weak collision resistance with an oracle and differs from statistical almost universality, which is not restricted to efficient attackers.

Papers

GHASH

GHASH compresses a sequence of blocks by evaluating a polynomial in a binary finite field. The secret hash key determines where that polynomial is evaluated.

Why it is useful

It gives GCM-style authentication a fast algebraic building block that can use hardware carry-less multiplication.

How it works

  1. Pad the message and associated data to block boundaries.
  2. Include their original lengths so that different input pairs remain distinguishable.
  3. Evaluate the resulting polynomial using the hash key.
  4. Combine the result with the rest of the authenticated-encryption construction.

What to watch for

GHASH alone is not a secure standalone authentication tag. In ordinary GCM, repeated nonces can expose relations between GHASH outputs and undermine authentication.

Related ideas

Papers

Batched GHASH multiplication

Several GHASH blocks can be processed together by precomputing powers of the hash key and combining polynomial products before field reduction.

Why it is useful

This exposes parallel work and avoids performing a separate reduction after every multiplication.

How it works

  1. Prepare powers of the fixed hash key for the selected batch size.
  2. Compute the polynomial products for several blocks.
  3. Combine the products and reduce the accumulated result in the binary field.

What to watch for

Precomputation has a cost, so a batching strategy that helps long messages may not help short ones. The reported timings depend on the tested processors and implementation.

Papers

Universal hashing

A universal hash family bounds the probability that two fixed, distinct inputs collide when the hash function is selected at random. The probability is over the selected function, not over a guess that the inputs are random.

Why it is useful

This gives a mathematical collision bound for tasks such as comparing strings and extracting shorter secrets.

How it works

  1. Specify the input and output sets and a family of functions.
  2. Select a function using the required randomness.
  3. For every fixed pair of distinct inputs, bound their collision probability.
  4. Use the family in the larger construction with its required independence and leakage conditions.

What to watch for

Universal hashing and cryptographic collision resistance are different properties. Publishing a hash function does not make it an authenticator without the additional secret-key construction.

Related ideas

Papers

Wegman-Carter MAC

Universal hash-based message authentication code used for symmetric key authentication in QKD, providing unconditionally secure authentication of classical communication.

Papers

XOR-universal hashing

A keyed hash family is XOR-universal when, for any two distinct fixed inputs, choosing a random key makes a particular XOR difference between their hashes unlikely. The guarantee is over the randomly chosen key.

Why it is useful

That bound helps prove that an attacker cannot often force different message-and-nonce pairs to collide before a keyed pseudorandom function is applied.

How it works

  1. Choose a secret hash key from the specified key space.
  2. Compress the encoded message with that keyed hash.
  3. Use the bounded collision probability as one part of the larger authentication proof.

What to watch for

Universal hashing is not the same guarantee as collision resistance of a public hash function. It is also not automatically a complete message-authentication scheme.

Papers

Constrained and puncturable pseudorandom functions

Pseudorandom functions whose keys only work on part of the input space: punctured keys that exclude chosen points, and constrained keys for prefixes or circuits, used in bootstrapping and broadcast designs.

Bit-fixing constraints from multilinear maps

A bit-fixing key works on exactly the inputs that match a pattern of bits and wildcards. The paper constructs such keys directly by lifting the Naor-Reingold pseudorandom function into a tower of n+1 groups linked by multilinear maps, which are pairings chained so that several exponents can be multiplied together step by step.

Why it is useful

Bit-fixing is the family that powers the broadcast encryption application, and it is the first place where constrained PRFs need more than a single pairing: an input of n bits needs n+1 levels so that n exponents plus one secret can be combined.

How it works

  1. Setup chooses a secret exponent alpha and, for every bit position i and bit value b, a secret exponent d, publishing only the corresponding group element D.
  2. The function value at an input x is the top-level group element carrying alpha times the product of the chosen exponents, one per bit of x.
  3. A key for a pattern v contains the group element carrying alpha times the product of the exponents fixed by v, together with the published D values for every wildcard position.
  4. Evaluation first rejects any input disagreeing with v on a fixed position, then pairs across the wildcard positions to climb to the top group.

Example

The pattern 0?1 lets a key evaluate the function at 001 and 011, and at nothing else.

What to watch for

Security rests on the (n+1)-multilinear decisional Diffie-Hellman assumption, and the proof guesses the challenge input and loses a factor of 2 to the power n. The multilinear-map candidates available in 2013 are an assumption, not a mature instantiation.

Useful background: What a constrained PRF is, The constrained security game.

Papers

Broadcast encryption with an empty header

Broadcast encryption lets one broadcaster address any subset of n receivers, and its cost is measured by the header shipped alongside the ciphertext. From a bit-fixing constrained PRF the paper derives a system whose header is always the empty string.

Why it is useful

Zero header length is optimal, and private key length does not grow with the number of users either. The constraint does the work that headers normally do: it tells each receiver which session key to derive.

How it works

  1. Give user i the bit-fixing key for the pattern that fixes only bit position i to the value 1.
  2. To address a set S, form its characteristic vector x, whose i-th bit is 1 exactly when user i belongs to S, and set the message key to the PRF value at x.
  3. Send the empty header. Every member of S can evaluate the PRF at x with its constrained key; non-members cannot.

Example

With four users and the recipient set {1,3}, the characteristic vector is 1010 and the message key is the PRF value at 1010.

What to watch for

This is secret-key broadcast encryption, since only the broadcaster can start a session, and the instantiation needs multilinear maps. Classic bilinear systems instead have a public broadcaster key and a constant-size header, so the win here is header length, not practical efficiency.

Useful background: Bit-fixing constraints from multilinear maps.

Papers

Circuit constraints and policy-based group keys

The most expressive family: a constrained key for a boolean circuit C evaluates the function exactly on the inputs where C outputs 1. The construction reuses the wire-by-wire key structure of an attribute-based encryption scheme for circuits.

Why it is useful

It turns a key into a policy. Any group of users whose attributes satisfy a policy can derive one shared key with no interaction and no online authority, while a coalition of users who all fail the policy learns nothing about that key.

How it works

  1. Setup produces n plus ℓ multilinear levels, where ℓ is the maximum circuit depth the system accepts.
  2. Constrain picks a fresh random value for every wire and emits key components for each input wire and each AND and OR gate.
  3. Evaluation first checks that the circuit accepts the input, then combines components along accepting wires bottom-up with repeated pairings.
  4. For policy keys, a user with attribute vector id receives the key for the universal circuit applied to id, and the group key for a policy p is the PRF value at the description of p.

Example

The policy IACR member AND driver licence holder becomes a small circuit; every user satisfying it derives the same group key.

What to watch for

The number of multilinear levels grows with circuit depth, and the circuits are treated as leveled and monotone, meaning gates sit in layers and only AND and OR gates appear, with negations pushed down to the inputs. The security proof again loses a factor of 2 to the power n by guessing the challenge.

Useful background: Bit-fixing constraints from multilinear maps.

Papers

Constrained pseudorandom functions

A pseudorandom function (PRF) is a keyed function whose outputs on new inputs look random. A constrained PRF lets the key owner hand out a second, limited key that only works on part of the input space.

Why it is useful

It lets you delegate part of the PRF computation without giving away the master key, which is the basis for fine-grained access to a shared source of pseudorandomness.

How it works

  1. The owner keeps a master seed and can compute the PRF on every input.
  2. The owner derives a constrained key for a predicate (a Boolean circuit) f.
  3. Whoever holds the constrained key can compute the PRF value on exactly the inputs where the predicate accepts.
  4. On every other input the value stays hidden: it stays indistinguishable from random even for someone holding the constrained key.

Example

As an illustration, a key for the predicate "the first bit of the input is 0" lets its holder evaluate the PRF on half of the inputs and learns nothing about the values on the other half.

What to watch for

The paper uses the convention that f(x) = 0 means the predicate accepts, so 0 is the authorized case.

Related ideas

Papers

Constraint hiding in constrained PRFs

A private (constraint-hiding) constrained PRF requires that the constrained key itself does not reveal which predicate it was built for.

Why it is useful

A normal constrained key shows its predicate to whoever holds it. Hiding the predicate means the holder cannot even tell which inputs the key covers, which several applications need.

How it works

  1. The security game gives the adversary a constrained key and lets it ask about PRF values.
  2. One secret bit decides which of two predicates the key was built for; guessing it breaks constraint hiding.
  3. A second bit decides whether values outside the constrained set are real or random.
  4. A third bit decides whether values inside the set come from the master evaluation or the constrained evaluation.
  5. The scheme is secure if no efficient adversary gains a noticeable edge on any of the three bits.

What to watch for

This single game is stated for the selective case, where the adversary fixes its two predicates before seeing the public parameters, and it covers one constrained key only.

Useful background: Constrained pseudorandom functions.

Related ideas

Papers

Dual use: one LWE secret for FHE and ABE

The first new technique: use one and the same Learning With Errors secret vector both as the FHE secret key and as the ABE encryption randomness.

Why it is useful

The lattice FHE scheme and the lattice ABE scheme are structured so similarly that a single secret serves both roles, and then the FHE noise never gets multiplied by the gadget matrix in the first place, removing the shift problem at its source.

How it works

  1. Publish the FHE public key and derive the ABE public matrices from it.
  2. Encrypt the attribute with the FHE, and build the ABE ciphertext pieces from partly decrypted FHE material.
  3. During decryption, recombine the pieces according to the FHE homomorphic evaluation of the predicate.
  4. That recombination makes the ABE ciphertext decrypt its own FHE component, leaving an ordinary ABE ciphertext that the predicate key can open.
  5. The security proof has to argue carefully about the FHE encryption randomness, which is where the two roles of the one secret interact.

What to watch for

The proof needs the FHE randomness to stay hidden by a leftover-hash argument, and the construction still only gives the weak (unauthorized-keys-only) privacy guarantee.

Useful background: The FHE noise that blocks constraint hiding, Embedding a circuit in a PRF.

Related ideas

  • GSW: the FHE whose secret-key shape is reused as ABE randomness

Papers

Embedding a circuit in a PRF

A route from lattice attribute-based encryption to constrained PRFs: fix public matrices, keep the PRF seed as an encryption randomness vector, and evaluate a universal circuit through the matrices before rounding.

Why it is useful

It reuses the homomorphic key-evaluation machinery of lattice ABE so that one public object serves both the master evaluation and the constrained evaluation, instead of designing a PRF from scratch.

How it works

  1. Publish the public matrices of an ABE-style scheme; the seed is a secret vector s that corresponds to no ciphertext in particular.
  2. For an input x, build the universal circuit that takes a description of a function and runs it on x.
  3. Homomorphically evaluate that circuit on the public matrices, and output the rounding of the secret vector times the resulting matrix.
  4. Hand out, as the constrained key for f, the analogue of an ABE ciphertext that encrypts the description of f.
  5. Whoever holds it processes the key the same way; when the predicate accepts the input, the processed key reproduces the master PRF value.

Example

If the universal circuit is applied to the description of "input equals 0010", the key holder can reproduce the value at 0010 and only there.

What to watch for

The evaluation has to be deterministic, because a PRF cannot add fresh randomness, so the noise that normally appears in decryption is fixed by the public parameters instead.

Useful background: Constrained pseudorandom functions.

Related ideas

  • Gadget decomposition: the homomorphic evaluation works by decomposing vectors against the powers-of-two gadget

Papers

Left/right constraints from a single bilinear map

The paper builds a PRF on pairs (x, y) where a constrained key can fix either the left or the right coordinate to a chosen value, and it does so with nothing more than a bilinear map plus random oracles. A bilinear map, or pairing, is an operation e that takes two elements of a group and returns a third while mixing their exponents: e(g^a, g^b) equals e(g, g)^{ab}. A random oracle is an idealized hash function that behaves like a fresh random table.

Why it is useful

It shows that non-trivial constrained PRFs exist under a standard assumption, decision bilinear Diffie-Hellman, and its algebraic shape is the same pairing trick behind the Boneh-Franklin identity-based encryption and the Sakai-Ohgishi-Kasahara key exchange. That similarity is why this family directly yields identity-based key exchange.

How it works

  1. Hash both coordinates into a pairing group with random oracles H1 and H2, and define the function value as the pairing e(H1(x), H2(y)) raised to the secret exponent k.
  2. The constrained key fixing the left side to a value x* is H1(x*) raised to k; its holder pairs it with H2(y) to evaluate the function at (x*, y) for every y, and symmetrically for the right side.
  3. Evaluating at a point where neither coordinate is fixed would require the exponent k itself, which no constrained key reveals.

Example

Two users order their identities lexicographically; the smaller one uses its left key, the larger one its right key, and both arrive at the same PRF value without ever talking.

What to watch for

The construction needs random oracles, and the paper states that building left/right constrained PRFs without them is a far more challenging problem that requires multilinear maps. Instantiated for key exchange it reproduces the Sakai-Ohgishi-Kasahara system rather than a new one.

Useful background: What a constrained PRF is.

Papers

Modulus switching to absorb the noise

The second new technique: after the noisy inner product, apply a low-norm linear map to a gadget over a smaller modulus and then divide by the large constant, so the noise term lands inside the ordinary error.

Why it is useful

Straight rounding does nothing because the attribute is encoded robustly in the most significant part of the ciphertext. Mapping through a smaller-modulus gadget separates the two scales and makes the division effective.

How it works

  1. Keep a large constant t and the FHE error bound far apart in magnitude.
  2. Replace the gadget matrix by the gadget for the smaller modulus p = q/t, using the small-coefficient decomposition G inverse of the smaller gadget.
  3. Apply that map to the processed ciphertext; the error term becomes a low-norm contribution because the secret is short.
  4. Divide the whole expression by t, which lands the result modulo p and turns the error term into part of the accumulated noise.
  5. The predicate bit survives because it was sitting at the large scale, while the noise it carried does not.

What to watch for

The map must use small coefficients, since applying it to large coefficients would blow up the accumulated noise; the paper notes the same idea appeared independently in the point-function construction of Boneh, Kim and Montgomery.

Useful background: The FHE noise that blocks constraint hiding.

Related ideas

  • Gadget decomposition: the powers-of-two gadget and its small-coefficient inverse carry out the switch

Papers

Open problems: adaptivity, delegation, other assumptions

The paper closes with the gaps it could not fill: constrained PRFs secure against adaptive adversaries without a non-polynomial reduction, keys that can be delegated several levels deep, and constructions from assumptions other than multilinear maps.

Why it is useful

Each gap blocks a use. Adaptive security without parameter blow-up is needed for realistic instantiations; multi-level delegation would mimic hierarchical identity-based encryption; and learning-with-errors constructions would give a post-quantum route to the same key exchange and broadcast systems.

How it works

  1. Adaptive security currently comes from guessing the challenge input, which loses an exponential factor and forces much larger groups.
  2. Delegation means a constrained key for a set can itself derive keys for smaller sets; the GGM prefix system supports this directly, the bit-fixing one extends naturally, and others do not.
  3. The paper asks for constrained PRFs from the learning with errors problem or from simple bilinear maps.

What to watch for

These are research directions stated in 2013, not results; the paper claims no progress on them.

Useful background: The constrained security game, Bit-fixing constraints from multilinear maps.

Papers

Puncturing and the single-key limit

Puncturing is the special case where the constrained key evaluates the PRF everywhere except on one input. It needs only one constrained key to be handed out, which is a far weaker requirement than resisting many keys at once.

Why it is useful

Most applications that would want many constrained keys (collusion resistance) are out of reach from standard assumptions, while the puncturing paradigm gets by with a single key and still yields useful results.

How it works

  1. A punctured key is a constrained key for the predicate that rejects one chosen input.
  2. Deletion-style proofs then rely on the PRF value at the punctured point looking random to the key holder.
  3. Security against a single key is achievable for rich function classes under the Learning With Errors assumption.
  4. Security against even two keys for these classes would already imply indistinguishability obfuscation, a much stronger and unproven object.

What to watch for

The paper only claims and only proves the single-key setting; nothing here is secure against an adversary that collects several constrained keys.

Useful background: Constrained pseudorandom functions.

Related ideas

Papers

Puncturing and what trivial keys give

A punctured key is the most demanding kind of constrained key: it works on every input except one chosen point. Before hunting for clever constructions, note that every PRF already supports small sets for free, because the constrained key for a single point is just that one function value.

Why it is useful

It separates the easy cases from the real problem. Any set whose size is polynomial in the security parameter is handled by listing values, so nothing new is needed. Puncturing is the opposite extreme: everything except one point is an exponentially large set, so listing fails and a dedicated construction is required.

How it works

  1. For a single point x, the constrained key is the value F(k, x) itself.
  2. For a polynomial-size set S, the constrained key is the list of values F(k, x) for every x in S.
  3. For an exponentially large set such as all inputs except one, the list is far too long, which is why the paper builds real constrained PRFs for bit patterns and circuits.

Example

A key that opens every door in the hotel except room 17.

What to watch for

The paper never uses the word puncturing; it defines constraining for arbitrary set systems, and puncturing is the usual name for the special case that excludes points. In this paper such keys come from the bit-fixing and circuit families, never from the trivial listing route.

Useful background: What a constrained PRF is.

Papers

The constrained security game

Security says that an adversary who collects many constrained keys of its own choosing, plus many honest function values, still cannot tell the function value at a fresh point apart from a random string.

Why it is useful

Without care the definition is vacuous. If the adversary could challenge a point lying inside a set it holds a key for, it could compare answers and win instantly, so the game has to track which points are computable and which are challenged.

How it works

  1. The adversary gets three oracles: evaluate the function, obtain a constrained key, and issue a challenge.
  2. A set V records every point the adversary can now compute, from direct evaluations and from the sets covered by its keys.
  3. A set C records challenged points, and the game keeps C and V disjoint so that no challenge is answerable.
  4. A hybrid argument shows that a definition allowing a single challenge query is as strong as one allowing many.

What to watch for

The definition lets the adversary choose the challenge point adaptively, but the proofs in this paper only establish selective security, where the challenge point is committed to in advance. Adaptive security is recovered by complexity leveraging, a non-polynomial-time reduction that forces larger parameters.

Useful background: What a constrained PRF is.

Papers

The FHE noise that blocks constraint hiding

In the predicate-encryption route, the processed constrained key carries an extra term that comes from the noise of the homomorphic evaluation, and that term is what stops the construction from being constraint-hiding.

Why it is useful

It explains why simply taking an existing weakly attribute-hiding scheme and turning it into a PRF fails: the holder of the constrained key ends up with a shifted value rather than the PRF value.

How it works

  1. Homomorphic decryption of the predicate yields the accepted-or-rejected bit plus a small error term.
  2. The earlier scheme put a trapdoor for every possible value of that error and let decryption try them all, a "lazy OR" over 2B+1 lattices.
  3. Trying them all leaks the actual error to whoever decrypts, which already breaks attribute privacy.
  4. In the PRF setting the roles of predicate and input are swapped, so the same shifts break correctness: the key holder only obtains the value offset by an unknown small error.
  5. Both new techniques in the paper work by making that error small enough to be absorbed into the ordinary noise of the construction.

What to watch for

The size of the shift grows with the depth of the evaluated circuit, so deep predicates force larger parameters.

Useful background: Embedding a circuit in a PRF.

Related ideas

  • GSW: the homomorphic scheme whose decryption produces the noisy inner product

Papers

What a constrained PRF is

A pseudorandom function (PRF) is a keyed function whose outputs look like random noise to anyone who lacks the key. A constrained PRF adds a second kind of key: from the master key one can derive a constrained key for a chosen part S of the input space, and that key computes the function on S and nowhere else.

Why it is useful

It separates knowing the function on some inputs from holding the master key. The paper shows that this one extra ability, for rich enough families of sets, already gives broadcast encryption and identity-based key exchange, which ordinary PRFs cannot do.

How it works

  1. Start from a PRF F with key space K, domain X and range Y, plus a setup algorithm that samples the master key k.
  2. F.constrain(k, S) takes the master key and the description of a set S and outputs a constrained key.
  3. F.eval(kS, x) returns F(k, x) when x is in S, and a special failure symbol otherwise.
  4. The family of allowed sets, called a set system or equivalently a family of predicates, is part of what a given scheme supports.

Example

Picture a hotel with a million doors. The master key opens everything; a constrained key is a floor key that opens only the rooms on one floor.

What to watch for

A scheme is only constrained relative to the set system it supports, and F.eval must decide membership in S efficiently, so the framework is stated for sets that can be decided in polynomial time.

Related ideas

Papers

What the two techniques deliver

Both techniques yield single-key constraint-hiding constrained PRFs for all polynomial-size circuits of bounded depth, and both also yield weakly attribute-hiding predicate encryption with shorter keys.

Why it is useful

The point of the paper is that each technique is reusable: the same trick upgrades predicate encryption and constrained PRFs at once, and each handles predicates that previous predicate-encryption methods could not.

How it works

  1. Two constructions of single-key private constrained PRFs for circuits of an a-priori bounded depth, generalizing the point-function and NC1 results that came before.
  2. Two weakly attribute-hiding predicate encryption schemes, with predicate keys shorter than the earlier lattice scheme by a polynomial factor in the security parameter.
  3. Both avoid the first of the two leakage sources that broke the earlier scheme.
  4. The analysis composes with an existing lattice PRF instead of using admissible hash functions, which the authors say simplifies and tightens the security reduction.

What to watch for

Everything rests on Learning With Errors with a subexponential noise-to-modulus ratio and polynomial-time hardness, and only the single-key, selective notion is proved. The second construction also fixes the input length in advance; unbounded inputs need a different assumption.

Useful background: Constraint hiding in constrained PRFs, Dual use: one LWE secret for FHE and ABE, Modulus switching to absorb the noise, Trapdoor extension in Hermite normal form.

Related ideas

Papers

Public-key encryption

A public key lets other people encrypt a message for you. The matching private key lets you decrypt it. Key-encapsulation methods instead establish a shared secret that other encryption algorithms can use.

DAWN encryption

DAWN is an NTRU encryption design using double encoding.

Papers

DHAES

DHAES combines ephemeral Diffie-Hellman key agreement with symmetric encryption and message authentication.

Papers

Extended reproducible PKE

Extended reproducible PKE supports ciphertext reproduction using additional hints.

Papers

HILA5

HILA5 is a ring-lattice encryption and encapsulation design using reconciliation and error correction.

Papers

Kurosawa-Desmedt encryption

Kurosawa-Desmedt encryption combines an algebraic encapsulation component with symmetric encryption.

Papers

LAC

LAC is a lattice encryption and encapsulation design that uses error-correcting codes.

Papers

Lizard

Lizard is a lattice public-key encryption construction combining noisy and rounded linear operations.

Papers

McEliece encryption

McEliece encryption masks an error-correcting code and adds an error vector to encoded messages.

Papers

NEV

NEV is an NTRU encryption design using vector decoding.

Papers

Niederreiter encryption

Niederreiter encryption encodes a message as an error vector and publishes its syndrome under a disguised code.

Papers

NTRU encryption

NTRU encryption uses small polynomials and inversion in a quotient polynomial ring.

Papers

NTRU LPRime

NTRU LPRime is a rounded polynomial-ring key-encapsulation construction in the NTRU Prime family.

Papers

NTRU Prime

NTRU Prime is a family of polynomial-ring encryption and key-encapsulation constructions.

Papers

PIKE encryption

PIKE is an isogeny-based public-key encryption design using pairing-assisted decryption.

Papers

Round5

Round5 is a lattice encryption and encapsulation design using generalized learning with rounding.

Papers

RQC

RQC is a rank-metric code-based public-key encryption and encapsulation construction.

Papers

Streamlined NTRU Prime

Streamlined NTRU Prime is a public-key encryption and encapsulation construction within the NTRU Prime family.

Papers

ThreeBears

ThreeBears is a key-encapsulation family using arithmetic over a generalized Mersenne-number representation.

Papers

Encryption interfaces and message models

Ordinary randomized PKE, correctness, decryption errors and variants of message or key handling, including key-evolving and reproducible encryption. Access-policy and homomorphic functions have separate roots.

ElGamal encryption

ElGamal encryption combines an ephemeral group element with a message masked by a shared group value.

Papers

Elliptic Curve Cryptography

Public key cryptosystem based on the elliptic curve discrete logarithm problem; mentioned as vulnerable to quantum attacks via Shor's algorithm.

Papers

FESTA

FESTA is a public-key encryption design using higher-dimensional isogeny techniques developed in SIDH cryptanalysis.

Papers

Finite Field Discrete Logarithm

Public key cryptosystem based on the discrete logarithm problem in finite fields; mentioned as vulnerable to quantum attacks via Shor's algorithm.

Papers

Lossy coefficient compression

A noisy polynomial encryption scheme can encode coefficients with fewer bits by rounding them. Decompression returns nearby coefficients rather than reproducing the originals exactly.

Why it is useful

Small controlled rounding errors can reduce public-key or ciphertext size when decryption already tolerates a bounded amount of noise.

How it works

  1. Scale and round a coefficient into the smaller encoded range.
  2. Transmit the shorter representation.
  3. Map it back to a nearby coefficient during decryption.
  4. Include the resulting error in the correctness analysis.

What to watch for

Compression is a change to the cryptographic distribution as well as an encoding choice. More aggressive rounding can increase decryption failures, and public-key compression may need an additional security argument.

Related ideas

Papers

NTRU+PKE

NTRU+PKE is a public-key encryption construction using an NTRU-based encoding design.

Papers

Public-key encryption from an obfuscated encryption program

The paper builds a public encryption key by obfuscating a restricted symmetric-style encryption program. The program expands a seed, evaluates a secret pseudorandom function there and uses the result as a mask for the message.

Why it is useful

It shows how the weaker indistinguishability form of obfuscation can support public encryption when the program's inputs are designed carefully.

How it works

  1. Generate a puncturable function key and keep it as the decryption secret.
  2. Publish an obfuscation of the seed-expanding encryption program.
  3. Encrypt using a fresh seed and output the expanded seed with the masked message.
  4. Decrypt by evaluating the secret function on the expanded seed and removing the mask.

What to watch for

Simply publishing an obfuscation that evaluates the mask on an arbitrary supplied input would expose challenge masks. This basic construction is chosen-plaintext secure under its assumptions, not automatically chosen-ciphertext secure.

Papers

RSA

Public key cryptosystem based on the difficulty of factoring large integers; mentioned as a current public key scheme that would be broken by large-scale quantum computers running Shor's algorithm.

Papers

RSA encryption

RSA encryption uses modular exponentiation with separate public and private exponents.

Papers

Batch and multi-recipient encryption

Shared work, randomness or ciphertext components across messages or recipients, including batched encapsulation. Broadcast access policies and revocation belong under access encryption.

mmCipher-KEM

mmCipher-KEM is a module-lattice construction for batched key encapsulation to multiple recipients.

Papers

mmCipher-PKE

mmCipher-PKE is a module-lattice construction for encrypting multiple messages to multiple recipients.

Papers

Deniable and non-committing encryption

Alternative openings for coercion resistance and simulation-oriented non-committing encryption for adaptive corruption. These uses have different adversaries and are not interchangeable guarantees.

Sender-deniable encryption

Sender-deniable encryption allows a sender to provide alternative message-and-randomness explanations for a ciphertext that an observer cannot reliably distinguish from an honest explanation.

Why it is useful

Ordinary encryption hides a message until secret information is disclosed, but it need not protect a sender required to explain the randomness used for encryption.

How it works

  1. Encrypt normally for the receiver.
  2. Keep the receiver's decryption behavior separate from the observer's explanation test.
  3. When needed, generate alternative coins for the claimed message.
  4. Require the resulting view to resemble an honestly generated ciphertext and explanation.

What to watch for

The model does not give the observer the recipient's decryption key or arbitrary external evidence. Alternative explanations exploit rare coin choices; correctness need only hold with overwhelming probability over honest coins. This does not guarantee protection against device records or real-world coercion.

Papers

Publicly deniable encryption

Public deniability lets anyone generate an alternative randomness explanation from the public key, ciphertext and claimed message. The explanation algorithm does not require the original sender's coins.

Why it is useful

It separates the ability to explain a ciphertext from knowledge of how that ciphertext was actually created.

How it works

  1. Provide public encryption and explanation algorithms.
  2. Require ordinary message confidentiality.
  3. Separately require honest coins and generated explanations to be indistinguishable for the same claimed message.
  4. Combine these properties to obtain deniability for alternative messages.

What to watch for

Explanation indistinguishability alone does not establish message confidentiality. The paper's construction is conditional on obfuscation and suitable one-way-function-based components, not a deployment recommendation.

Papers

Deterministic encryption and entropy-dependent security

Deterministic PKE with high-entropy or auxiliary-input assumptions, and related message-locked encryption research. Message-locked designs may be symmetric; they are cross-axis search leads here. Equality leakage and offline testing are explicit model choices.

Key-dependent and circular security

Security when plaintexts depend on encryption keys, keys encrypt each other, or adversaries induce related keys. Permitted function and key-relation classes must be explicit.

Recipient anonymity and key privacy

Hiding the recipient key or recipient set of a ciphertext, including outsider versus insider anonymity. Plaintext secrecy alone does not supply key privacy.

Encryption security notions

Learn the different attacks an encryption scheme may need to resist, including attackers who can request encryptions or ask for some ciphertexts to be decrypted.

Chosen-ciphertext security

Chosen-ciphertext security considers an attacker who can ask for other ciphertexts to be decrypted or decapsulated while trying to distinguish a challenge secret. The challenge ciphertext itself is excluded from those queries.

Why it is useful

A real receiver may process attacker-supplied ciphertexts. Protection against merely observing honest ciphertexts is a weaker requirement.

How it works

  1. Give the attacker a public key and a challenge ciphertext.
  2. Allow the prescribed decryption or decapsulation queries on other ciphertexts.
  3. Ask whether the attacker can distinguish the challenge message or shared key from the alternative in the security game.

What to watch for

This is a formal confidentiality notion. It does not automatically authenticate public keys, guarantee delivery or cover implementation leakage outside the model.

Related ideas

Papers

Cramer-Shoup encryption

Cramer-Shoup encryption augments an ElGamal-style ciphertext with a hash-dependent consistency component.

Papers

Decryption failures in noisy encryption

Noisy encryption recovers a message by removing the large secret-dependent term and decoding the smaller remainder. If the combined error crosses a decoding boundary, an honestly generated ciphertext can decrypt incorrectly.

Why it is useful

The failure probability affects both reliability and the security analysis of chosen-ciphertext transformations. It cannot always be treated as an application-only error rate.

How it works

  1. Write the residual error after the secret-dependent terms cancel.
  2. Include fresh noise and compression errors.
  3. Compare that error with the message-decoding threshold.
  4. Choose parameters and analyze the probability of crossing the threshold.

What to watch for

An average honest-ciphertext failure estimate is not automatically a bound on every adversarial strategy. Observable failure behavior can also expose information and needs protocol-level analysis.

Related ideas

Papers

IND-CPA security

Indistinguishability under chosen plaintext attack. An adversary cannot distinguish the KEM shared secret from random given all public information.

Papers

Message space size and the RCCA definitions

How many distinct messages the scheme can encrypt correctly decides whether the three definitions of replayable security coincide. Large, super-polynomial message spaces make them equivalent; polynomial-size spaces do not.

Why it is useful

The proof that the game definition implies the simulation definition has the simulator encrypt random messages in place of real ones. That substitution stays sound only when a random message essentially never collides with a message anyone cares about.

How it works

  1. Call the message domain large when it grows faster than any polynomial in the security parameter.
  2. Under that assumption the simulation definition and both game definitions are provably equivalent, so the intuitive formulation and the handy ones can be used interchangeably.
  3. For polynomial-size domains the paper builds a scheme that encrypts a message together with an encryption of a random different message; it stays indistinguishable, yet an attacker can maul it into winning the non-malleability game.
  4. Whether the non-malleability definition implies the simulation definition in the polynomial case is left open.

What to watch for

A large message domain is a correctness requirement, not an assumption that messages are random. It says the scheme encrypts and decrypts that many distinct values correctly, and it can be combined with any security requirement.

Useful background: The IND-RCCA game, The NM-RCCA game, RCCA as an ideal encryption functionality.

Papers

OW-CPA security

One-wayness under chosen plaintext attack. An adversary cannot recover the shared secret given the public key and encapsulation.

Papers

RCCA as an ideal encryption functionality

A simulation-based definition of replayable security, written as an ideal service in the universal composability framework. The service records ciphertext and message pairs and never lets the adversary see a recorded message.

Why it is useful

An ideal functionality states what surrounding protocols may assume, and any scheme that realizes it can be dropped in without re-proving those protocols. It also displays the whole difference between CCA and RCCA as one added adversary ability.

How it works

  1. An encryption request returns a ciphertext chosen by the adversary, who never learns the message, so the ciphertext carries no information about it.
  2. Decrypting a recorded ciphertext returns the recorded message.
  3. Decrypting any other ciphertext returns whatever value the adversary names.
  4. In the replayable variant the adversary may instead ask that such a ciphertext decrypt to the value of some recorded ciphertext, still without learning that value.

What to watch for

The equivalence between realizing the ideal service and CCA security holds against non-adaptive adversaries only. Against adversaries that corrupt parties during the run, extra machinery such as forward-secure or non-committing encryption is needed.

Useful background: Replayable CCA security.

Papers

The IND-RCCA game

An attack game that defines replayable security in the style of indistinguishability. It is the usual CCA game with one changed rule about the decryption oracle.

Why it is useful

Game definitions are the easiest to use when checking a concrete scheme, and the single changed rule shows exactly how much is being given away: only queries that decrypt to one of the two challenge messages are refused.

How it works

  1. Generate the key pair and give the attacker the public key and a decryption oracle.
  2. The attacker names two different messages and receives an encryption of one of them, chosen by a hidden coin flip.
  3. A later decryption query is answered with the reserved word test whenever the submitted ciphertext decrypts to either challenge message, not only when it equals the challenge ciphertext itself.
  4. The attacker wins by guessing the coin flip.

What to watch for

The game alone does not show that the relaxation is small. The evidence is the equivalence with the simulation-based definition, and that equivalence needs a large message space.

Useful background: Replayable CCA security.

Papers

The NM-RCCA game

The same game with a non-malleability style winning condition: instead of naming the hidden message, the attacker must output a ciphertext that decrypts to the other challenge message.

Why it is useful

Non-malleability asks whether an attacker can transform a challenge ciphertext into a related one. Here the only transformation granted for free is producing another ciphertext for the same message, so the attacker must use some relation other than equality of plaintexts.

How it works

  1. Play the IND-RCCA game through key generation, the decryption stage and the challenge ciphertext.
  2. In the final stage the attacker outputs a ciphertext instead of a bit.
  3. It wins if that ciphertext decrypts to the other challenge message.
  4. Producing another encryption of the same message does not win, because that replay is exactly the freedom the notion grants.

What to watch for

For message spaces of polynomial size this notion is strictly stronger than indistinguishability, and the paper separates them with an explicit scheme. The two agree only when the message space is large.

Useful background: The IND-RCCA game.

Papers

Chosen-ciphertext transforms and encodings

PKE/KEM transformations targeting stronger security through consistency checks, re-encryption, hashing or authentication. Exact variants differ in assumptions and rejection behavior.

Fujisaki-Okamoto transform

Fujisaki-Okamoto-style transformations add hashing and ciphertext consistency checks to an underlying encryption scheme. In the KEM variant described here, encryption randomness is derived from the encapsulated message and public context.

Why it is useful

The receiver checks that a ciphertext could have been generated in the required way, rather than allowing arbitrary modified ciphertexts to act as a decryption oracle.

How it works

  1. Hash the random encapsulated message and the required public context to derive encryption coins and key material.
  2. Encrypt using those coins.
  3. On decapsulation, recover a candidate message and derive the same coins.
  4. Re-encrypt and compare the entire reconstructed ciphertext.
  5. Return the construction's prescribed key or rejection result.

What to watch for

There are several FO variants with different assumptions and failure behavior. The transformation needs the exact underlying-encryption, hash-model and correctness conditions of its proof.

Related ideas

Papers

Implicit rejection in a KEM

With implicit rejection, an invalid encapsulation produces a secret-derived fallback key rather than a public invalid-ciphertext symbol. The fallback depends on the ciphertext and secret rejection material.

Why it is useful

The KEM interface can return a key-shaped value without exposing the internal consistency result directly.

How it works

  1. Recover a candidate message and reconstruct the expected ciphertext.
  2. Compare the reconstructed ciphertext with the received one.
  3. Derive the normal output key and the specified fallback key.
  4. Select the required result without exposing the secret-dependent decision through implementation behavior.

What to watch for

Returning bytes does not mean authentication succeeded. The surrounding encrypted-message protocol must verify its authentication tag, and timing or other side channels must not reveal the hidden decision.

Related ideas

Papers

RSA-OAEP

RSA-OAEP combines RSA encryption with an encoding built from mask-generation operations.

Papers

Ciphertext robustness and key commitment

Preventing ciphertext acceptance under conflicting keys, recipients or interpretations, including adversarial keys. Robustness, anonymity and ordinary confidentiality are separate requirements.

Post-quantum encryption security and migration

Public-key encryption and key encapsulation designed to resist attackers with quantum computers. Different constructions rely on different mathematical problems and parameter choices.

ML-KEM

ML-KEM is the standardized module-lattice key-encapsulation mechanism derived from Kyber.

Papers

Post-Quantum Cryptography

Family of cryptographic schemes believed to be secure against attacks by large-scale quantum computers; mentioned as future alternatives for public key authentication in QKD infrastructures.

Papers

SIKE

SIKE is a historical key-encapsulation design built from supersingular-isogeny key exchange.

Papers

Key encapsulation mechanisms

A KEM establishes a shared key rather than encrypting an application message directly. Learn how encapsulation and decapsulation work, what happens on malformed ciphertexts and how the key is used by a separate authenticated-encryption layer.

BAT KEM

BAT is an NTRU-based key-encapsulation mechanism.

Papers

BIKE

BIKE is a code-based key-encapsulation mechanism using quasi-cyclic moderate-density parity-check codes.

Papers

Classic McEliece

Classic McEliece is a code-based key-encapsulation design using binary Goppa codes.

Papers

FrodoKEM

FrodoKEM is a key-encapsulation mechanism using unstructured lattice matrices.

Papers

HQC

HQC is a code-based key-encapsulation mechanism using quasi-cyclic codes.

Papers

Key encapsulation mechanism

A key encapsulation mechanism, or KEM, establishes a shared secret using a public key. Encapsulation produces both a secret key and a ciphertext; decapsulation uses the matching private key to recover the secret from that ciphertext.

Why it is useful

Applications often need to agree on a random encryption key rather than encrypt a whole message with public-key arithmetic.

How it works

  1. Generate a public and private key pair.
  2. Encapsulate to the public key, obtaining a ciphertext and a shared secret.
  3. Send the ciphertext, but keep the shared secret private.
  4. Decapsulate with the private key to obtain the matching secret.

What to watch for

A KEM alone does not authenticate the source of the recipient's public key. The surrounding protocol must also handle key derivation, message authentication and failure behavior.

Related ideas

Papers

Kyber

Kyber is a module-lattice key-encapsulation mechanism.

Papers

Kyber (early construction)

This early Kyber design starts with noisy polynomial-based public-key encryption and applies a ciphertext-checking transformation to make a KEM. Polynomial vectors provide a tradeoff between structure, size and arithmetic cost.

Why it is useful

The design aims to retain efficient polynomial arithmetic while allowing the module dimension to change with the desired parameter set.

How it works

  1. Generate a public polynomial matrix from a seed and a secret vector with small coefficients.
  2. Construct the public encryption key by adding noise to a matrix-vector product.
  3. Encapsulate a random message using deterministically derived encryption coins.
  4. Decapsulate by recovering the message, re-encrypting it and checking the ciphertext before selecting the output key.

What to watch for

The q=7681 design in this paper is not the later standardized ML-KEM. The paper distinguishes a proved uncompressed-public-key variant from the additional argument used for its compressed-public-key choice.

Related ideas

Papers

NewHope

NewHope is a ring-lattice key-exchange and encapsulation design using reconciliation.

Papers

NewHope-Simple

NewHope-Simple constructs a key-encapsulation variant from ring-lattice encryption without NewHope's reconciliation procedure.

Papers

NTRU+

NTRU+ is an NTRU-based key-encapsulation design using an encoding transformation.

Papers

Public-key and ciphertext binding in key derivation

A KEM can include the public key and ciphertext in the hashes that derive its shared key. This ties the key material to the specific public context used in the exchange.

Why it is useful

The early Kyber paper uses public-key hashing to make derivation target-specific and ciphertext hashing to bind the final result to the encapsulation.

How it works

  1. Hash the public key into the derivation of encapsulation randomness and preliminary key material.
  2. Hash the resulting ciphertext into the final key derivation.
  3. Use the same encodings and context on decapsulation.

What to watch for

Binding public inputs does not establish that the public key belongs to the intended person. Authentication and the exact KEM security properties remain separate requirements.

Related ideas

Papers

ROLLO

ROLLO is a family of rank-metric code-based key-encapsulation mechanisms.

Papers

RSA-KEM

RSA-KEM encapsulates a key by applying a derivation function to an RSA-domain secret.

Papers

Saber

Saber is a module-lattice key-encapsulation mechanism using rounding.

Papers

Public-key encryption composition

Combining public-key components with symmetric encryption, other assumptions or signing functions. Composition claims must name component interfaces and failure conditions.

KEM-DEM and integrated encryption

Encapsulation or ephemeral agreement followed by derivation and symmetric data encryption, including tag-bound variants. Here hybrid means public-key plus symmetric encryption, not necessarily classical plus post-quantum assumptions.

ECIES

ECIES is an integrated encryption construction using elliptic-curve key agreement and symmetric primitives.

Papers

HPKE

HPKE combines a KEM, a key-derivation function and an authenticated-encryption scheme.

Papers

KEM-DEM composition

KEM-DEM encryption uses a public-key mechanism to establish a fresh symmetric key, then uses a symmetric data-encryption mechanism to protect the message. The transmitted object contains both ciphertext parts.

Why it is useful

Public-key operations handle key establishment while the faster symmetric scheme handles messages of arbitrary practical length.

How it works

  1. Encapsulate a fresh key to the recipient's public key.
  2. Encrypt and authenticate the message under that key using the specified symmetric scheme.
  3. Send the encapsulation ciphertext and the protected message.
  4. Decapsulate, then verify and decrypt the protected message.

What to watch for

The security requirements apply to both components and their composition. A CCA-secure KEM combined with unauthenticated symmetric encryption is not the composition described here.

Related ideas

Papers

Tag-KEM

Tag-KEM constructions bind an encapsulated key to a supplied tag in hybrid encryption.

Papers

Multi-assumption and hybrid combiners

Combining PKE schemes or KEMs to retain a property when one component fails, including classical/post-quantum combinations. Concatenation alone does not specify a secure combiner.

CasKDF combiner

A hybrid KEM combiner that processes KEM secrets through a cascade of KDF iterations, each accepting one secret and producing chain state for the next iteration.

Papers

CtKDF combiner

A hybrid KEM combiner that concatenates the shared secrets from multiple KEMs and passes them through a KDF to produce a single shared secret.

Papers

Signcryption and authenticated public-key encryption

Joint confidentiality and sender authentication, including insider/outsider security and public-verifiability choices. Sign-then-encrypt and encrypt-then-sign need separate composition arguments.

Isogeny-based key exchange

Key exchange and encryption built from maps between elliptic curves. Two parties walk different paths on a curve family and end up with a shared secret; schemes include SIDH, CSIDH and SIKE.

ECDH+SIDH hybrid key exchange

Run classical elliptic curve Diffie-Hellman alongside SIDH, using a strong Montgomery curve defined over the same prime field as the SIDH arithmetic.

Why it is useful

SIDH had received less cryptanalytic scrutiny than older post-quantum candidates. Pairing it with a long-studied classical problem means the combination stays classically secure even if the new component is weakened, and stays post-quantum secure even though the classical component is broken by a quantum computer.

How it works

  1. Search the SIDH prime field for a Montgomery curve whose order and whose twist’s order are each four times a large prime. A twist is a related curve that shares the same x-coordinates but not the same y-coordinates.
  2. Reuse the SIDH library’s base-field Montgomery ladder for the scalar multiplications, changing only the curve constant, so almost no extra code is needed.
  3. Because every field element is the x-coordinate of a point on the curve or on its twist, and the ladder computes correctly on both, all field elements are valid public keys and no point validation is required.
  4. Concatenate the ECDH public key onto the SIDH public key and derive the two shared secrets independently.

Example

Illustration: the paper’s curve, nicknamed BigMont, is a Montgomery curve over the SIDH prime field with order and twist order each equal to four times a 749-bit prime; it is a 2016 illustration, not a recommended curve.

What to watch for

The classical component is far larger than a standardized curve would be, so the combined key grows: the paper reports about a 17 percent increase in public key size and 13 percent in runtime over standalone SIDH, and the 384-bit classical security margin is deliberately generous.

Useful background: Elliptic curve Diffie-Hellman, Quadratic twists, SIDH.

Related ideas

Papers

SIDH

Two parties each build a secret isogeny (a map from one elliptic curve to another that respects the point-addition law) away from one shared supersingular elliptic curve, publish the curve they land on together with the images of two public points, and then each pushes the other party’s points through their own secret scalars. Both end up on isomorphic curves and take the same j-invariant as the shared secret.

Why it is useful

It is a Diffie-Hellman-style key exchange whose hardness comes from finding isogenies between supersingular curves rather than from factoring or discrete logarithms, so Shor’s algorithm does not apply to it the way it applies to RSA or to classical elliptic curve Diffie-Hellman.

How it works

  1. Agree on a starting supersingular curve E0 over Fp2 (supersingular is a special, highly symmetric type of curve) whose number of points is (2^eA · 3^eB · f)^2, on two independent points of order 2^eA for Alice, and on two independent points of order 3^eB for Bob.
  2. Alice picks two secret scalars (mA, nA), not both divisible by 2, and forms the point RA = [mA]PA + [nA]QA, which has order 2^eA. Her secret is the isogeny whose kernel is generated by RA.
  3. Her public key is the curve she lands on together with the images of Bob’s two public points under her secret isogeny. Bob does the same with his own scalars and Alice’s points.
  4. To get the shared secret, Alice combines Bob’s two image points with her own scalars to rebuild Bob’s kernel inside Bob’s curve, and Bob does the symmetric thing inside Alice’s curve.
  5. The two resulting curves are isomorphic, so both parties read off the same j-invariant, a number that identifies a curve up to isomorphism.

Example

Illustration: Alice’s secret isogeny has degree 2^372 and Bob’s has degree 3^239 over a 751-bit prime field, so the walk consists of hundreds of tiny steps rather than one enormous map.

What to watch for

The security proof covers a model with authenticated links, which forces adversaries to be passive eavesdroppers, and rests on the Supersingular Decision Diffie-Hellman problem. The best known attacks against the underlying problems are claw-finding attacks, which look for a matching pair of isogeny paths; they cost about the fourth root of p on a classical computer and the sixth root of p on a quantum computer. Even so, SIDH was young when this paper was written and the authors explicitly call for more cryptanalysis. The parameter set here is a 2016 choice, not a current recommendation.

Useful background: Elliptic curve points and the group law, Diffie-Hellman key exchange, Supersingular elliptic curves.

Related ideas

  • CSIDH: a later isogeny key exchange that uses a commutative group action instead of published point images
  • Castryck-Decru SIDH attack: a later attack that exploits the auxiliary torsion-point images that SIDH public keys expose

Papers

SIDH public key compression

Send only the three x-coordinates per public key and let the receiver reconstruct the Montgomery coefficient of the isogenous curve from them.

Why it is useful

It removes the curve coefficient from the transmitted key at no cost, keeps public keys at 564 bytes, and avoids the square-root computation that an earlier compression variant would have required.

How it works

  1. Publish xP, xQ and x(Q−P): the x-coordinates of the two image points and of their difference.
  2. The receiver recovers the curve coefficient a from the algebraic identity relating a to those three x-coordinates, so the curve never has to be sent.
  3. Decompression costs four multiplications, one squaring, seven additions and one inversion, all operations the implementation already performs elsewhere.
  4. The difference coordinate is also exactly what the other party needs to start the three-point ladder (a Montgomery ladder variant that computes x(P + [m]Q)) during the shared secret phase, so nothing is transmitted purely for decompression.

Example

Illustration: three x-coordinates over Fp2 at a 751-bit prime take up 3 × 2 × 751/8 ≈ 564 bytes once the curve coefficient is dropped.

What to watch for

A stronger compression based on smooth-order discrete logarithms can roughly halve the key size again, but its compression step alone costs over ten times a full key exchange, so this implementation does not include it.

Useful background: Montgomery models, SIDH.

Related ideas

Papers

SIDH public key validation

A family of checks that a received SIDH public key really has the shape an honestly generated key would have, performed using x-coordinates only.

Why it is useful

The proven security model assumes passive adversaries and honestly generated keys. If private keys are reused, a malicious public key can be crafted to leak information about the other party’s static secret, so validation becomes necessary and, unlike in classical elliptic curve Diffie-Hellman, non-trivial.

How it works

  1. Recover the curve coefficient from the three transmitted x-coordinates and treat it as part of the key being validated.
  2. Check that both image points have full order, which blocks a small-subgroup attack where a short-order point reveals the secret modulo a small factor.
  3. Check that one image point is not a scalar multiple of the other, which prevents a key that forces the shared secret to be independent of the honest party’s private key.
  4. Check that the Weil pairing of the two points has the largest order the public parameters allow; taking a power of the pairing and comparing it with the pairing of scaled points makes this check cheap.
  5. Check that the curve is not defined over the base field, and test supersingularity with a random-point scalar multiplication: if neither p−1 nor p+1 kills the point, the curve is rejected.

What to watch for

The supersingularity test is probabilistic, passing an ordinary curve with probability at most 8p/(p−1)^2, and it depends on the random element staying unknown to the sender. The whole procedure costs a visible fraction of one key exchange round, unlike the near-free point checks of classical ECDH.

Useful background: SIDH, Weil pairing, Small subgroup attacks.

Related ideas

  • SIDH: the scheme whose static-key deployments need this
  • Montgomery ladder: the x-only scalar multiplication used to run the checks

Papers

SIDH-friendly primes and fast modular reduction

Choosing p = 2^eA · 3^eB · f − 1 with exponents sized so that the prime just fits below a whole number of machine words, and then adapting Montgomery multiplication to that particular shape.

Why it is useful

Modular multiplication dominates the cost of an isogeny key exchange. A prime of this special form allows a reduction routine with far fewer instructions than the generic Montgomery or Barrett reduction used by earlier SIDH software.

How it works

  1. Balance the exponents so that 2^eA is close to 3^eB, which keeps either side of the exchange from being appreciably easier to attack and evens out the two parties’ running times.
  2. Keep the bit length just under a multiple of the word size, here 751 bits under 768, so additions can be done without carries spilling out of the top word and so a field element needs 12 rather than 13 machine-word chunks (called limbs).
  3. In Montgomery reduction the expression a + (ap’ mod R)·p simplifies, because the multiplier becomes p + 1 = 2^eA · 3^eB, whose least significant limbs are zero.
  4. Skip the multiplications that touch those zero limbs: the theoretical speedup is about 1.85x, and the implemented routine needs 83 instead of 156 multiplication instructions per reduction.

Example

Illustration: p = 2^372 · 3^239 − 1 is 751 bits, so a 12-limb 64-bit representation leaves 17 bits of headroom below the 768-bit boundary.

What to watch for

The special form is what makes the arithmetic fast, not what makes the scheme secure; the security target comes from the attack complexities against the isogeny problems. The instruction counts are for the authors’ 64-bit implementation, and the prime itself is a 2016 choice.

Useful background: Montgomery multiplication, Modular arithmetic, SIDH.

Related ideas

Papers

Lattice public-key encryption and key exchange

Lattice key exchange sends noisy polynomial products between two parties, who then reconcile their almost-equal values into one shared key. Security rests on ring learning-with-errors; practical designs use small moduli, easy-to-sample noise, fresh public parameters, and transform-domain arithmetic.

A fresh shared parameter every exchange

The public ring element is generated anew per handshake instead of being a fixed global constant.

Why it is useful

A fixed parameter chosen by someone else invites planted weaknesses and lets one expensive attack break every session at once.

How it works

  1. Generate the public element from a hash of the transcript seed each time.
  2. Accept the small transmission or generation overhead.
  3. Backdoors and all-for-the-price-of-one attacks lose their anchor.

What to watch for

Generation must itself be trustworthy and reproducible by both parties from public randomness.

Useful background: Ring-LWE key exchange as a KEM.

Papers

Binomial noise instead of discrete Gaussian

For key exchange, near-uniform binomial errors work in place of high-quality Gaussian samples.

Why it is useful

Gaussian samplers are slow and awkward to make constant-time; a centered binomial table is fast, constant-time, and barely moves the security estimate.

How it works

  1. Sample a fixed number of bits; the error coefficient is their count minus half the count.
  2. The distribution is close enough to Gaussian for the security argument.
  3. Sampling becomes table lookups, safe against timing observation.

What to watch for

For signatures and trapdoors, by contrast, distribution quality is critical - the paper states this split explicitly.

Useful background: Ring-LWE key exchange as a KEM.

Related ideas

Papers

From research exchange to TLS cipher suite

A prior ring-learning-with-errors instantiation was already wired into OpenSSL; this proposal made the same route practical.

Why it is useful

It shows the path from lattice assumption to deployable handshake: concrete parameters, constant-time code, and measured speedups around an order of magnitude.

How it works

  1. Start from the earlier OpenSSL-integrated proposal.
  2. Fix the oversized modulus and the slow Gaussian sampler.
  3. Double the security parameter while halving the message size at the same dimension.

What to watch for

Performance numbers are implementation-specific and dated; they show feasibility, not current records.

Useful background: Ring-LWE key exchange as a KEM.

Papers

How the security proof works

Security is proved by a sequence of hybrid steps: the evaluation key consists of LWE samples that are indistinguishable from uniform, so an attacker who sees the evaluation key learns nothing beyond what an attacker on Regev-style LWE encryption already sees. The final steps replace the public key and then the ciphertext with uniform values.

Why it is useful

Publishing all the re-linearization and modulus-switching material is the main new attack surface this construction creates, so the proof must show it leaks nothing about any of the chained secret keys.

How it works

  1. Replace the short-parameter parts of the evaluation key with uniform values, using decision LWE with parameters (k, p).
  2. Replace each level of the long-parameter parts similarly, one hybrid per level, using decision LWE with (n, q).
  3. Replace the public-key vector b with uniform values, again via decision LWE.
  4. Use a leftover hash lemma argument so the ciphertext itself is statistically close to uniform.
  5. Conclude semantic security; the two LWE instances are set so they are of roughly the same hardness, since the smaller parameters can carry higher relative noise.

What to watch for

The guarantee is semantic security against passive adversaries, stated with parameters for super-polynomial-time attackers; circuit privacy (not revealing which function was evaluated) needs extra noise that the base scheme does not add.

Useful background: Somewhat homomorphic encryption from Learning With Errors, Standard LWE versus ideal-lattice assumptions.

Papers

Reconciliation from an almost-agreed value

The helper signal maps each coefficient to a key bit, with randomized doubling on the sender side to keep the key uniform.

Why it is useful

Because the two parties hold slightly different values after the noisy exchange, one cannot just compare; the rounding rule makes the small gap disappear.

How it works

  1. Split the modulus range into two intervals with a middle no-man band.
  2. The responder sends one hint bit per coefficient from a randomized doubling of its value.
  3. The initiator uses the hint to round its own value to the same bit.
  4. Applied coefficient-wise across the polynomial.

What to watch for

Failure probability is nonzero but engineered to be astronomically small; the analysis must be tight or the modulus inflates.

Useful background: Ring-LWE key exchange as a KEM.

Papers

Ring-LWE key exchange as a KEM

Two parties each add small secret noise to a shared ring computation and end up with values that are almost equal; a helper signal lets them agree on exactly the same key.

Why it is useful

It is the lattice answer to Diffie-Hellman: keys built from polynomial arithmetic with small errors, aimed at transport security under quantum attackers.

How it works

  1. A public ring element is fixed for the session.
  2. One side sends its noised product; the other replies with its own plus a reconciliation hint.
  3. Both sides round their approximately-equal values to the same shared key.
  4. The encapsulated key then feeds a symmetric cipher suite.

Example

The ring is polynomials modulo x to the power 1024 plus 1, with coefficients modulo the prime 12289.

What to watch for

Passively secure only; authentication must come from elsewhere, classically from pre-quantum signatures.

Useful background: Learning with errors as lattice decoding.

Related ideas

  • Key encapsulation mechanisms: the interface used
  • Transport layer security: the target protocol

Papers

Standard LWE versus ideal-lattice assumptions

Earlier fully homomorphic schemes were built from ideals in rings, or ideal lattices, a structured special case about which much less is known. This paper instead builds everything from the plain Learning With Errors problem over ordinary vectors, whose hardness is connected to worst-case problems on arbitrary lattices.

Why it is useful

General lattice problems have been studied for decades, and LWE comes with worst-case to average-case reductions, so the scheme rests on a more standard and better understood foundation than ideal-lattice assumptions.

How it works

  1. State security as the decision LWE problem: distinguishing noisy random linear equations involving a hidden secret from uniformly random values.
  2. Use the known reductions (quantum by Regev, classical by Peikert) that turn an LWE solver into an algorithm for approximate shortest-vector problems on arbitrary lattices.
  3. Keep encryption, the evaluation key, and all re-linearization material as plain vectors and matrices, so no ring structure is ever assumed to be hard.

What to watch for

The worst-case guarantee is for approximation factors tied to the parameters, and the classical reduction needs the modulus to factor into co-prime, polynomial-size pieces; using rings would give smaller keys but would reintroduce the ideal-lattice assumptions.

Useful background: Somewhat homomorphic encryption from Learning With Errors.

Papers

Tighter failure analysis and better error correction

A sharper failure-probability bound plus a small error-correcting lattice cut the modulus from 32 bits to 12289.

Why it is useful

The prior instantiation used an oversized modulus to paper over a loose failure analysis, hurting speed and security at once.

How it works

  1. Bound the decryption-failure probability tightly.
  2. Correct small reconciliation errors using a four-dimensional lattice code.
  3. Shrink the modulus below 2 to the 14th power.

What to watch for

The failure analysis needs care; an off-by-one in the distribution definition was itself caught and fixed in revision.

Useful background: Reconciliation from an almost-agreed value.

Papers

Transform-domain encoding

Sending polynomials already in the transform domain removes conversions inside the handshake.

Why it is useful

Polynomial multiplication runs in the number-theoretic transform domain; keeping data there end to end saves whole transformation rounds.

How it works

  1. Represent ring elements by their transform coefficients.
  2. Skip the forward and inverse transforms the protocol would otherwise need.
  3. Combine with lazy reduction techniques for further speed.

What to watch for

The encoding must be specified exactly, or encoder mismatches become interoperability bugs.

Useful background: Ring-LWE key exchange as a KEM, Number-theoretic transform.

Related ideas

Papers

Chosen-ciphertext secure constructions

Constructions that resist attackers who can ask for decryptions of chosen ciphertexts: the Cramer-Shoup scheme, refined and relaxed security notions, and tightly secure designs.

Detectable RCCA

A family of notions between RCCA and CCA. The scheme carries a relation that decides whether two ciphertexts are modified versions of each other, and that relation is computable either from the public key alone, called publicly detectable, or only with the secret key, called secretly detectable.

Why it is useful

Padding changes and byte-order changes are easy to test with the public key, and earlier relaxations in the literature were built on exactly that. Naming the relation places those notions in one hierarchy and shows that replayable security is genuinely weaker still.

How it works

  1. The relation must be compatible: related ciphertexts decrypt to the same value, and two independent encryptions of the same message are related only with negligible probability.
  2. Run the CCA game, but answer test when the attacker submits a ciphertext related to the challenge ciphertext.
  3. If the relation is computable from the public key the scheme is publicly detectable; if it needs the secret key it is secretly detectable.
  4. The implications run from CCA to publicly detectable to secretly detectable to plain replayable security, and the first two steps are strict.

What to watch for

Whether secretly detectable is strictly stronger than plain replayable security is open. Schemes that anyone can re-randomize can never be publicly detectable, and the paper builds a secretly detectable, publicly re-randomizable scheme from ElGamal under the Decisional Diffie-Hellman assumption.

Useful background: Replayable CCA security.

Papers

Protocols that RCCA security protects

The protocol tasks for which replayable security has been proved enough: non-interactive secure message transmission, encryption-based key exchange, and encrypted password authentication.

Why it is useful

These tasks are the main reasons CCA-secure encryption is demanded inside protocols. If the weaker notion suffices, schemes that CCA security rejects become usable and existing proofs hold under weaker hypotheses.

How it works

  1. For secure transmission, the sender encrypts its own identity together with the message and the receiver checks that identity after decryption, so a replayed plaintext presented as coming from someone else is rejected.
  2. For key exchange, one party encrypts a random key and both sides derive the session key by applying a pseudorandom function to it; the proof reduces to an encryption game that replayable security already wins.
  3. For password authentication, the paper defines a relaxed ciphertext-verification notion implied by indistinguishability under replay and re-proves the Encrypted Challenge-Response protocol without changing the protocol.

What to watch for

These results assume the protocol never inspects ciphertext strings directly. Where ciphertexts are compared, for example to detect duplicate encrypted votes, replay matters and CCA security is needed.

Useful background: Replayable CCA security.

Papers

RCCA hybrid encryption

Hybrid encryption assembled from a replayable-secure public-key part and a replayable-secure symmetric part is itself replayable-secure as a public-key scheme.

Why it is useful

Public-key encryption is slow for long messages, so practice encrypts a symmetric key publicly and encrypts the data with that key. The theorem says this composition does not need CCA security on either side in order to keep replayable security.

How it works

  1. Define replayable security for symmetric encryption by giving the attacker an encryption oracle in addition to the decryption oracle; the rule that answers test is unchanged.
  2. Compose: the public-key part encrypts a fresh symmetric key, and the symmetric part encrypts the message under that key.
  3. Encrypt-then-authenticate, where a message authentication code is computed over the symmetric ciphertext, gives a replayable-secure symmetric scheme out of a passively secure cipher and an ordinary authentication code.
  4. The usual envelope construction therefore stays replayable-secure with a regular authentication code, where the CCA variant needs a strong one.

What to watch for

The composition preserves the relaxed notion, not CCA security. Combining it with the generic transformation is the route from replayable security to full CCA security.

Useful background: Replayable CCA security, Upgrading RCCA to CCA.

Papers

Replayable CCA security

A relaxed version of security against adaptive chosen-ciphertext attack (CCA). A scheme is replayable-CCA secure, or RCCA secure, when it meets CCA security except for one freedom: anyone may turn a ciphertext they have seen into a different ciphertext that decrypts to the same plaintext.

Why it is useful

Real implementations keep failing CCA tests for reasons that look harmless, so CCA seems stronger than applications need. The argument is that making another ciphertext for the same plaintext is no worse than copying the original ciphertext, and copying is something even a CCA-secure scheme cannot prevent.

How it works

  1. Start from a CCA-secure scheme.
  2. Let encryption append a 0 bit to every ciphertext and let decryption ignore that bit; flipping the bit now produces a new ciphertext with the same plaintext, which CCA security forbids but RCCA security allows.
  3. Keep every other demand: seeing a challenge ciphertext must not help an attacker learn which of two chosen messages it encrypts, except by making such replays.
  4. The resulting notion is strictly weaker than CCA security, and strictly weaker than the earlier relaxations proposed in the literature.

Example

Appending an ignored padding bit, accepting the same ciphertext in big-endian and little-endian encodings, or wrapping a ciphertext in a second encryption that only needs to resist passive eavesdroppers all break CCA security while leaving the protection of the plaintext in place.

What to watch for

The argument holds only while the surrounding protocol acts on decrypted plaintexts and never compares ciphertext strings. A voting scheme that rejects duplicate votes by comparing ciphertexts genuinely uses the full CCA guarantee.

Related ideas

Papers

Upgrading RCCA to CCA

A generic transformation that takes any replayable-secure scheme able to carry messages as long as the security parameter and returns a CCA-secure scheme, using only shared-key primitives.

Why it is useful

It shows the relaxed notion is not a dead end. Once replayable security is available for a large enough message space, full CCA security follows with no additional computational assumptions, and the added layer is cheap when both components are efficient.

How it works

  1. Choose a fresh symmetric key.
  2. Encrypt that key under the replayable-secure public-key scheme; call the result c1.
  3. Encrypt the pair consisting of c1 and the message under the symmetric key with a CCA-secure symmetric scheme; the ciphertext is (c1, c2).
  4. To decrypt, recover the key from c1, decrypt c2, and output invalid unless the copy of c1 found inside matches the outer c1.
  5. The encrypted copy of c1 works as an authentication tag on c1, so any modification of c1 breaks the check and the malleability that replayable security tolerates disappears.

Example

With a 128-bit symmetric key, the ciphertext is the public-key encryption of the key followed by the symmetric encryption of (that first component concatenated with the message).

What to watch for

The symmetric scheme must itself be CCA-secure, and the paper gets one from any one-way function. That existence step is very inefficient, though the composition step is efficient whenever the two components are.

Useful background: Replayable CCA security.

Related ideas

  • RCCA hybrid encryption: the same layering viewed as a way to keep replayable security rather than gain CCA security

Papers

Trapdoor functions and lattice trapdoors

A trapdoor function is easy to compute in the forward direction but hard to invert, unless you hold a secret: the trapdoor. Here the forward direction is a modular linear map, multiplying a public random-looking matrix by a short vector. The trapdoor is a short secret matrix R linking the public matrix to a fixed public gadget G whose lattice is easy to work with; the holder converts targets into gadget instances, while everyone else must solve the Short Integer Solution or Learning With Errors problems. This paper made such trapdoors small, fast to generate, and safe to use.

Basis-oblivious sampler output

The distribution of sampled vectors depends only on the length measure of the basis, not on its particular shape.

Why it is useful

This is the difference between the secure schemes in this paper and the broken GGH-style schemes: signatures must not reflect the geometry of the secret key.

How it works

  1. Two different short bases of similar quality produce statistically close outputs.
  2. The signature transcript therefore carries almost no information about which short basis was used.

What to watch for

Obliviousness is statistical, up to the parameter choices; poor quality bases widen the distribution and lengthen outputs.

Useful background: Discrete Gaussian sampling from a basis.

Papers

Delegating trapdoors for hierarchical identity-based encryption

A holder of a trapdoor R for A can manufacture a fresh, independently distributed trapdoor for an extension A-prime = [A | A1]: sample each column of the new R-prime as a discrete Gaussian over the right coset of the lattice of A, so that A times R-prime equals the tag times G minus A1.

Why it is useful

Hierarchical identity-based encryption hands derived keys to users lower in a hierarchy; the delegated trapdoor must let the child sign or decrypt without being able to reconstruct the parent trapdoor, and its size must not balloon as the hierarchy deepens.

How it works

  1. Fix the new tag and the target relation A R-prime = tag times G minus A1 for the extension matrix.
  2. Using the parent trapdoor R, sample each column of R-prime from a discrete Gaussian over the appropriate coset of the lattice of A.
  3. The result is a G-trapdoor for the extension whose quality is about the sampling width times a factor of order the square root of the total dimension.

What to watch for

Unlike the earlier basis delegation of Cash, Hofheinz, Kiltz, and Peikert, this only works when the extension adds at least the gadget width in new columns (m-prime at least m plus w); it cannot delegate to the same matrix.

Useful background: Micciancio-Peikert trapdoors.

Related ideas

  • Gentry-Silverman HIBE: hierarchical encryption motivated key delegation

Papers

Lattice trapdoors from short bases

A trapdoor for a lattice: a second basis of the same lattice whose vectors are short, while the published basis looks random.

Why it is useful

A short basis lets its holder find lattice points near any target, which is believed hard using only the long public basis. This one idea unlocks signatures, identity-based encryption, and inversion tools for the learning-with-errors problem.

How it works

  1. Generate a random lattice that is as hard as the worst case, together with one short basis kept secret.
  2. Publish the long basis; keep the short one.
  3. Use the short basis to decode points or sample short vectors on demand.
  4. Anyone with only the public basis faces a believed-hard lattice problem.

Example

Think of a city grid published with long, diagonal streets; the trapdoor is a private map of short alleyways that reach the same addresses.

What to watch for

The security claim is asymptotic, based on approximating lattice problems within polynomial factors; it does not certify concrete parameter choices.

Useful background: Lattice.

Related ideas

  • Learning with errors: lattice problem whose trapdoors this paper builds
  • Discrete Gaussian sampling: the tool that makes short bases usable

Papers

Micciancio-Peikert trapdoors

The new trapdoor is not a basis. A G-trapdoor for a public matrix A is a short random matrix R such that A times the block matrix with R above the identity equals H times G, for an invertible tag matrix H. The public matrix is generated as A = [A-bar | HG - A-bar R] for a random A-bar.

Why it is useful

Knowing R converts every inversion or sampling question about A into the same question about the easy public gadget G, at the cost of one multiplication by R. Generation is essentially a single matrix multiplication, and R needs storage that grows linearly with the lattice dimension, not quadratically like a basis.

How it works

  1. Pick a random matrix A-bar and a short matrix R, with entries drawn for example from 0 and plus or minus 1, or from a narrow discrete Gaussian.
  2. Output A = [A-bar | HG - A-bar R]; publish A and keep R secret, along with its tag H.
  3. To invert, multiply the target by the block matrix with R above the identity to obtain a G-instance, solve it with the easy G algorithms, then undo the tag H.
  4. Quality is the largest singular value of R: a smaller R supports narrower Gaussians and shorter outputs.

Example

With tag H set to the identity, the right block of the public matrix is simply G - A-bar R: the gadget, blinded by one multiplication with the short secret R.

What to watch for

The tag H must be invertible modulo q or the trapdoor cannot be used, and the matrix must be wide enough to contain the gadget. R is not a basis, so older algorithms that expect a basis must first derive one from R, which costs a little quality.

Useful background: The gadget matrix G: a public lattice that is easy to invert.

Related ideas

Papers

Preimage sampleable trapdoor functions

One-way functions with a secret key that, instead of returning one inverse, samples among all inverses with the right probability.

Why it is useful

Classic trapdoor permutations have exactly one inverse per output. Lattice functions are many-to-one, and security needs the inversion to pick preimages exactly as the legitimate generation process would.

How it works

  1. Evaluate by adding a small random error to a lattice point.
  2. The output is statistically close to uniform over the range.
  3. The trapdoor inverter samples a preimage from the same distribution conditioned on the output.
  4. Either order of choosing input and output yields nearly the same pair distribution.

What to watch for

Many-to-one structure means the same output can arise from different inputs; applications must tolerate that.

Useful background: One-way function.

Related ideas

Papers

The gadget matrix G: a public lattice that is easy to invert

The construction starts from a fixed, public matrix G, built from the row (1, 2, 4, ..., 2 to the k-1) modulo q, where k is about log base 2 of q. The lattice attached to G has a very short and highly structured basis, so inverting and Gaussian sampling for G are fast, simple, and parallel.

Why it is useful

If the hard part is already solved for G, then trapdooring a random-looking A only needs a small secret change that turns A-instances into G-instances. Since G is the same for everyone, its operations can be optimized once and reused in every key.

How it works

  1. Set k = ceiling of log base 2 of q and use the row g = (1, 2, 4, ..., 2 to the k-1); G is n stacked copies of this row.
  2. For q a power of two, the vectors x with the transpose of g times x equal to 0 mod q form a lattice with a basis having 2 on the diagonal and -1 just below it: short vectors, with Gram-Schmidt length 2.
  3. To invert, recover the unknown scalar one binary digit at a time from least to most significant (or by table lookup); each step only tests whether a value is closer to 0 or to q/2.
  4. To sample a preimage, peel one bit of the syndrome off at a time, drawing each coordinate from a small Gaussian over even or odd integers.

Example

With q = 8 and g = (1, 2, 4), the vector x = (1, 0, 1) has syndrome 1 + 4 = 5 mod 8: the integer whose binary digits are x.

What to watch for

The very clean structure (Gram-Schmidt length exactly 2) is special to moduli that are powers of two; for other moduli the paper uses a slightly longer basis (norm at most about the square root of 5) and adapted algorithms.

Useful background: Why lattice cryptography needed strong trapdoors.

Papers

Trapdoor extension in Hermite normal form

A lattice trapdoor is a shortcut for sampling short vectors in the kernel of a public matrix. This paper needs a version that works for matrices that carry an identity block plus a low-norm error term, called the Hermite normal form.

Why it is useful

After modulus switching, the simulated key material is only known up to a small error matrix, and ordinary trapdoor extension no longer applies. The Hermite normal form version tolerates that error.

How it works

  1. A trapdoor for a matrix A is the ability to sample short preimages of any target vector under A, close to a discrete Gaussian.
  2. The gadget matrix has a public trapdoor, so any target matrix can be rewritten as the gadget times a small-coefficient (zero-one) matrix.
  3. Standard trapdoor extension turns a trapdoor for A into one for wider matrices such as A next to A times a short matrix plus the gadget.
  4. The Hermite normal form version extends this to the matrix with an identity block, a public A, and A times a short matrix plus the gadget plus a low-norm error.
  5. Sample the LWE secret itself from the noise distribution, so the zero vector already has the shape secret times identity plus noise, and any ciphertext can be padded with it to match the identity block.

What to watch for

The error matrix must stay low-norm relative to the sampling parameter, which is one more constraint feeding into the parameter choice; the paper states this trapdoor method was only mentioned in passing before, for a different purpose.

Useful background: The FHE noise that blocks constraint hiding.

Related ideas

Papers

Using the trapdoor: inverting LWE and sampling Gaussian preimages

To invert the Learning With Errors function, multiply the noisy target by the block matrix with R above the identity, decode with the easy gadget oracle, and remove the tag: the secret and its error fall out. To sample a Gaussian preimage of fA, sample for the gadget and add a fresh Gaussian perturbation on top.

Why it is useful

The perturbation is not optional. A converted sample y lands in a lower-dimensional subset of the target coset and its Gaussian is skewed; that skew is information about R, so publishing y as-is would leak the trapdoor.

How it works

  1. Invert: transform the target, run the gadget decoder to get the G-secret and G-error, then return s = the inverse tag times the G-secret, and e = target minus the transpose of A times s.
  2. Sample, offline: draw a perturbation p from a Gaussian with a carefully chosen covariance and precompute what can be precomputed.
  3. Sample, online: adjust the syndrome by subtracting A times p, draw z from the right coset of the gadget lattice, and output x = p plus the block matrix times z.
  4. Covariances of independent Gaussians add, so the output is spherical over the whole coset, with a parameter only about the largest singular value of R times the gadget quality, within a factor of about 1.23 of what a full short basis would allow.

What to watch for

Inversion is only correct while the error stays small relative to q divided by (the quality of R times the gadget quality), so a worse trapdoor tolerates less noise. The sampling guarantees are statistical, and every Gaussian parameter hides a smoothing factor.

Useful background: Micciancio-Peikert trapdoors, GPV Gaussian sampling.

Related ideas

Papers

Why lattice cryptography needed strong trapdoors

A lattice public key is usually just a random-looking matrix A of integers modulo q, and the public operations are modular linear maps: multiply A by short vectors. Those alone give only collision-resistant hashing and encryption against passive listeners. Signatures, encryption that survives a chosen-ciphertext attack, and identity-based encryption all need a secret as well: a strong trapdoor, classically a short basis S of the lattice of vectors x with Ax = 0 mod q.

Why it is useful

The holder of the short basis can invert the public maps (removing noise, or sampling short preimages), while everyone else faces the Short Integer Solution (SIS) and Learning With Errors (LWE) problems, which are connected to worst-case lattice problems. Generating such an (A, S) pair was the slow, complex bottleneck in all of these schemes before this paper.

How it works

  1. Publish a random matrix A modulo q; the public maps are fA(x) = Ax mod q and gA(s, e) = the transpose of s times A, plus the short error e, all modulo q.
  2. Generate A together with a secret short basis S satisfying AS = 0 mod q.
  3. Use S to invert: decode noisy gA targets and sample Gaussian preimages of fA syndromes.
  4. Measure the trapdoor by the Euclidean lengths of its vectors; shorter is better, because it permits shorter outputs.

Example

Inverting fA without the secret means solving SIS; with the secret it is routine arithmetic. That gap is the whole point of a trapdoor.

What to watch for

The earlier generators (Ajtai 1999, Alwen-Peikert 2009) did work, but used Hermite normal forms, matrix inverses, or high-precision real arithmetic with large hidden constants; the improvements here are 2011 asymptotics, not modern parameter advice.

Related ideas

Papers

Why the trapdoored matrix still looks random

A = [A-bar | HG - A-bar R] must be indistinguishable from a uniformly random matrix, or everyone would see that a gadget is hidden inside. The paper proves closeness to uniform in two ways: statistically, with a leftover-hash-lemma style argument over a wider A-bar, or computationally, from the hardness of Learning With Errors with a much narrower A-bar.

Why it is useful

Security proofs for lattice schemes assume the public matrix is nearly uniform; if A leaked its hidden G-structure, an attacker could aim at the easy part instead of the hard problem.

How it works

  1. Statistical route: choose R with entries 0 and plus or minus 1 (or a small Gaussian); a regularity argument makes [A-bar | A-bar R] statistically close to uniform once A-bar has about n times log q columns.
  2. Computational route: take A-bar of width 2n containing an identity block; then [A-bar | A-bar R] is exactly a decision-LWE instance, so it looks random if LWE is hard.
  3. Either way the public matrix may be kept with an identity submatrix (Hermite normal form) without losing security.

What to watch for

The computational route was the first of its kind but rests on an assumption (decision-LWE) instead of statistical closeness and yields a somewhat worse trapdoor quality; the statistical route needs the wider A-bar.

Useful background: Micciancio-Peikert trapdoors.

Papers

Worst-case-hard lattice generation

A method due to Ajtai generates a random lattice and a short basis for it so the lattice is as hard as the worst case.

Why it is useful

Cryptography needs keys that are both sampled together and provably hard; ordinary lattices from toy bases do not give that.

How it works

  1. Run the generator to produce a lattice with worst-case hardness guarantees.
  2. Keep the generated short basis as the trapdoor.
  3. Publish the remaining basis.

What to watch for

The generator is the reason these schemes get worst-case guarantees rather than merely average-case hopes.

Papers

Digital signatures

A digital signature scheme lets anyone verify that a message came from the holder of a secret signing key. This paper asks what happens when bits of that key leak to an attacker, and gives signature constructions that stay unforgeable as long as the total leakage stays under a stated fraction of the key length.

A leakage-resilient signature scheme in the standard model

A feasibility construction: the secret key is a random n-bit string, the public key contains its hash under a universal one-way hash function plus an encryption key and a common reference string, and a signature is an encryption of the secret key together with a zero-knowledge proof that the ciphertext hides a preimage of that hash.

Why it is useful

Compressing the key with the hash function creates exponentially many equally valid secret keys, so leaking almost everything still leaves the true key ambiguous, and producing a different valid key means finding a hash collision.

How it works

  1. Generate the key: pick a random n-bit string x, hash it to y under a universal one-way hash function, and publish y together with an obliviously sampled encryption public key and a reference string for a simulation-sound non-interactive zero-knowledge proof system.
  2. Sign a message: encrypt x, then attach a proof that the ciphertext encrypts a value whose hash equals y, with the message included in the proved statement.
  3. Verify by checking the proof.
  4. Read a forgery: decrypting the forged signature gives a value x′ with the same hash as the signer’s x.
  5. Finish with the counting lemma: the public-key hash and the leakage together reveal fewer than n bits, so x is not uniquely determined and x′ differs from x with probability at least one half, which is a second preimage and breaks the hash function.

What to watch for

The proof counts only the randomness used to generate the secret key as leakable, not auxiliary signing state, and the generic zero-knowledge machinery makes this a plausibility result rather than a practical design.

Useful background: Three properties that keep signing safe under leakage, Universal one-way hash functions.

Related ideas

Papers

BLISS

BLISS is a lattice signature scheme using bimodal Gaussian sampling.

Papers

Boneh-Boyen signatures

Boneh-Boyen signatures are pairing-based signatures using an inverse-exponent form.

Papers

Commitment disclosure through ECDSA nonce reuse

CommitCoin's disclosure step: use a randomized commitment as a temporary signing key and sign two distinct transactions with the same ECDSA nonce so an observer can recover the commitment. This deliberate disclosure is part of that protocol, not safe nonce handling for ordinary signing keys.

Papers

ECDSA

ECDSA is an elliptic-curve signature scheme using a per-message scalar nonce.

Papers

FN-DSA

FN-DSA names the Falcon-derived lattice signature scheme in standardization work.

Papers

HAETAE

HAETAE is a lattice signature design using hyperball sampling.

Papers

Leakage-resilient one-time signatures from a one-way hash

A Lamport-style one-time scheme built on a universal one-way hash function with long preimages, where each secret-key component is a random string hashed in the public key; an error-correcting code raises the tolerable leakage to a constant fraction of the key, and cover-free families stretch one signature into a bounded number.

Why it is useful

Long random preimages give every public key exponentially many possible secret keys, and any forgery must reveal a preimage the signer never used, which is a hash collision.

How it works

  1. Basic variant: for a k-bit message the key holds two long random strings per position and the public key holds their hashes; signing reveals one string per message bit.
  2. The obvious attack shows the budget is nearly tight: after seeing a signature, leak just one unrevealed secret value and forge on the message that differs exactly there.
  3. Boosting: encode the message with a linear error-correcting code of high minimum distance before signing, so any forged message differs from the signed one in many positions and the forger must produce many never-revealed preimages at once.
  4. Extension to several signatures: use a cover-free family to choose which key components each message consumes, so no t signatures between them cover all the components another signature needs.
  5. The tolerated leakage is a constant fraction of the key length for the one-time boosted scheme, and shrinks proportionally to n over t squared for the t-time scheme.

Example

Illustration with two message bits: the key holds x1,0, x1,1, x2,0, x2,1, the public key holds their hashes, and signing 01 reveals x1,0 and x2,1; nothing about the other two values follows from the signature.

What to watch for

These schemes sign only once, or a bounded number of times, and the t-time variant needs large keys; the leakage fraction is bought with key size, not with a stronger assumption.

Useful background: Lamport signatures, Three properties that keep signing safe under leakage.

Related ideas

Papers

Leakage-resilient signatures from Fiat-Shamir in the random oracle model

An efficient construction in the random oracle model: the public key is a group element with many different exponent representations, and a signature is a witness-indistinguishable proof of knowledge of one representation, converted to a signature by the Fiat-Shamir transform.

Why it is useful

Because many exponent vectors explain the same public key, leaked bits cannot identify which one the signer holds, and a forgery combined with a rewound hash answer extracts a second representation, solving a discrete-log-based problem.

How it works

  1. Generate the key: publish random group generators g1 through gℓ and h equal to their product raised to secret exponents x1 through xℓ, which are the secret key.
  2. Sign: pick fresh randomness r1 through rℓ, compute the commitment A as the product of the generators raised to those values, set the challenge c to the hash of A and the message, and reply with each cxᵢ plus rᵢ.
  3. Verify by recomputing c from A and the message and checking that the generators raised to the reply values equal h to the c times A.
  4. Prove security by rewinding: replay the attacker from the moment it first asked the hash of A and the message, answer that query differently, and combine the two accepting transcripts to compute a fresh representation of h.
  5. The counting lemma bounds how much the two runs’ leakage can narrow down which representation was used, giving tolerance of roughly half the key length by taking ℓ large enough.

What to watch for

This holds in the random oracle model, the reduction loses a factor of the number of hash queries and squares the forging probability, and instantiations from RSA or factoring must either narrow what the leakage may read or generate the modulus obliviously at a real efficiency cost.

Useful background: Fiat-Shamir transform, Random oracle model, Schnorr signatures, Three properties that keep signing safe under leakage.

Related ideas

Papers

MAYO

MAYO is a multivariate signature scheme derived from oil-and-vinegar constructions.

Papers

MEDS

MEDS is a signature scheme using matrix code equivalence.

Papers

RSA-PSS

RSA-PSS is a probabilistic RSA signature encoding and signing scheme.

Papers

SPECK signatures

SPECK is a signature protocol using permutation equivalence of codes and kernels.

Papers

SQIsign2D-West

SQIsign2D-West is a signature design using two-dimensional isogenies.

Papers

SQIsignHD

SQIsignHD is a SQIsign variant using higher-dimensional isogenies.

Papers

Three properties that keep signing safe under leakage

A recipe for leakage tolerance: each public key should match a huge set of possible secret keys, finding a second such key given one should be hard, signatures should not lower the key’s min-entropy, and any forgery should hand over a full secret key consistent with the public key.

Why it is useful

These properties turn a forger into a machine that produces a second valid secret key, which contradicts the assumed hardness; the leftover min-entropy from the leakage budget is exactly what keeps the two keys different.

How it works

  1. Check the key set: for the given public key there are exponentially many secret keys, and given one of them it remains hard to compute any other.
  2. Check the view: the honest signatures, and the leakage, still leave the actual secret key with high min-entropy, so many candidates remain consistent with everything the attacker saw.
  3. Run the reduction: given one secret key and the public key, answer the attacker’s signing and leakage queries with that key.
  4. Extract: a forgery yields a secret key matching the public key; because at least two candidates were still possible, the extracted one differs from the signer’s with probability at least one half.

What to watch for

The recipe needs a forgery to expose a complete alternate secret key. Schemes that are merely hard to forge, without a large set of interchangeable keys, do not fit this route and need different reasoning.

Useful background: Bounded leakage only slowly erodes unpredictability, Existential unforgeability under chosen-message attack.

Related ideas

Papers

Waters signatures

Waters signatures are a pairing-based signature construction with algebraic message encoding.

Papers

Wavelet signatures

Wavelet is a code-based signature design adapted from Wave.

Papers

Adaptor signatures and conditional completion

Witness-based pre-signature completion, witness extraction and public-verifiability choices. Fair-exchange and transaction applications are linked separately.

Adaptor signatures

Adaptor signatures link a pre-signature to a witness revealed when the signature is completed.

Papers

Delegation, controlled changes and evolving keys

Signature authority that can be delegated, restricted, transformed or updated over time. These functions need explicit authorization rules beyond ordinary unforgeability.

Forward-secure and key-insulated signing

Key evolution, exposure resilience, puncturing and helper-based insulation. Forward security protects past periods after compromise; future recovery needs separate assumptions.

Proxy and delegated signatures

Delegated signing authority, proxy re-signing and restricted signing warrants. Delegation is not threshold possession of the original signing key.

Redactable, sanitizable and derived-data signatures

Authorized edits or computations on signed data, including redaction, sanitization and homomorphic signatures. Removing fields and authenticating arbitrary derived functions have different admissibility rules.

Independent-key collective signing

Signatures involving independent signing keys, explicit signer sets and rogue-key models. Threshold signing under one shared key belongs under threshold; batch verification alone is not aggregation.

Aggregate signatures

Combining signatures across messages or public keys into compact verifiable results, including sequential aggregation and aggregate extraction. Aggregation need not involve a joint signing session.

Multisignatures

Joint authentication of a common message by independent signers, including key aggregation, signing rounds and nonce coordination. This differs from a threshold access structure over secret shares.

Concurrent sessions break earlier two-round multisignatures

When an honest signer can be engaged in many signing sessions at the same time, an attacker controlling the other cosigners can bend the honest partial signatures into a forgery on a message nobody agreed to. Drijvers et al. showed that every two-round multi-signature scheme proposed so far in the plain discrete-logarithm setting falls to this.

Why it is useful

It explains why dropping the commitment round is genuinely hard: the earlier two-round designs were not merely unproven, they were attackable. Practitioners were left with three rounds or strictly sequential sessions.

How it works

  1. Open many concurrent sessions and collect the honest signer's nonce from each.
  2. Choose the attacker's nonce replies with Wagner's algorithm for the generalized birthday problem, so that the session challenges add up to the challenge of a chosen target message.
  3. The honest partial signatures then sum to a valid forged signature on that target message.
  4. For a 256-bit group, about 128 concurrent sessions bring the cost down to roughly 2 to the power 39 operations; a later polynomial-time attack needs more sessions but runs fast in practice.

What to watch for

The attack needs concurrency: it disappears with a commitment round or with strictly sequential sessions. The paper outlines the mechanism and cites the complexity figures; it does not give attack code.

Useful background: Multi-signatures: one signature from a group, MuSig.

Related ideas

Papers

Multi-signatures: one signature from a group

A multi-signature is a single signature on one shared message, produced by a group of n signers who each keep their own independent secret key. The group publishes one signature that anyone can check against a single aggregate public key computed from the members' public keys.

Why it is useful

One signature replaces n of them, so storage and verification cost do not grow with the group size. Because verification only uses the aggregate key, a checker cannot tell whether one signer or a whole group signed, which hides the group structure.

How it works

  1. Each signer generates its own key pair; there is no shared secret and no dealer.
  2. The list of public keys is compressed into one aggregate public key.
  3. The signers exchange short protocol messages: nonce contributions first, then one partial signature each.
  4. The partial signatures combine into one response that satisfies the ordinary verification equation under the aggregate public key.

Example

Three people share control of one coin: they publish one signature under one aggregate key instead of three separate signatures that a checker would verify one by one.

What to watch for

A multi-signature shows that the listed signers took part, not that some smaller subset of them would have sufficed; signing with any t of n members is a threshold scheme, a different setting. The paper studies n-of-n signing with independent keys.

Related ideas

  • Schnorr signatures: The combined signature is verified with the ordinary Schnorr equation.

Papers

MuSig

MuSig is a three-round Schnorr multi-signature protocol that defeats rogue keys by weighting every public key with a hash-derived coefficient before multiplying the keys together, and by running a nonce commitment round before the actual signing exchange.

Why it is useful

It works in the plain public-key model: public keys can be aggregated without validity checks or proofs of possession, so existing key formats keep working.

How it works

  1. Give each public key Xi in the list L its own coefficient ai, defined as a hash of the whole list together with that key.
  2. Compute the aggregate public key as the product of all keys raised to their coefficients.
  3. Each signer signs with a signer-dependent challenge, its coefficient times the signature hash, which is what stops a rogue key from cancelling the other keys.
  4. Verification of the combined signature is exactly ordinary Schnorr verification with respect to the aggregate key.
  5. Before any nonces are exchanged, every signer first commits to its nonce and only later reveals it.

Example

With two keys, each key enters the aggregate with a fresh hash value as its exponent, so an attacker cannot design a key that cancels its cosigner's key.

What to watch for

The commitment round makes signing a three-round protocol, and only that first round can be prepared before the message is known. Revealing the later moves before the message is fixed renders the scheme insecure.

Useful background: Multi-signatures: one signature from a group, The rogue-key attack on naive multisignatures.

Related ideas

Papers

MuSig-DN

MuSig-DN is a Schnorr multisignature protocol with deterministic nonce generation and supporting proofs.

Papers

MuSig2

MuSig2 is a two-round Schnorr multi-signature protocol. Every signer first broadcasts a list of nonces without knowing the message or the cosigners; after seeing the aggregated nonces, the message and the cosigner keys, each returns one partial signature, and the partial signatures are summed into an ordinary Schnorr signature.

Why it is useful

It is the first scheme combining security under concurrent sessions, key aggregation, ordinary Schnorr output, two communication rounds, and signer cost close to ordinary Schnorr signing, so it can replace single-signer Schnorr signatures without touching the verifier side.

How it works

  1. First round, which can be run in advance: signer i draws random exponents and broadcasts its list of nonces; an optional aggregator can multiply the lists position-wise for everyone.
  2. Second round: given the aggregated nonces, the message and the cosigners' keys, the signer computes the aggregate key and its own key coefficient, derives b by hashing, forms the combined nonce R and the challenge c, and outputs its partial signature as c times its weighted secret key plus its nonce exponents weighted by powers of b.
  3. The partial signatures are summed into one value s, and the signature is the pair (R, s).
  4. Verification is exactly ordinary key-prefixed Schnorr verification under the aggregate public key.

What to watch for

The second round must be run at most once per stored nonce state. The number of nonces is a deliberate choice: four nonces keep a proof in the random oracle model alone, while two nonces rely on also assuming the algebraic group model.

Useful background: Multi-signatures: one signature from a group, MuSig, MuSig2 nonce randomization with several nonces.

Related ideas

Papers

How multiple nonces repair the security proof

A security proof must let a reduction answer the adversary's signing queries without the honest secret key, by programming the hash that defines the challenge. With a single nonce the adversary sees the combined nonce before the reduction can program that hash, so the simulation breaks. With two nonces the reduction holds two unknowns and can still answer after the adversary forces two different challenges.

Why it is useful

This is the formal reason two rounds were out of reach before: the proofs themselves failed, not just implementations. The nonce list is what hands control back to the simulator.

How it works

  1. The reduction treats each honest nonce as a discrete-logarithm challenge and answers signing queries through a discrete-logarithm oracle.
  2. It programs the nonce hash and the signature hash so that whenever the adversary forces different challenges across two executions, the coefficient b differs as well.
  3. The two responses then form two linearly independent equations in the two unknown nonce secrets, which the reduction can solve once it extracts the secret key from a forgery.
  4. In the random-oracle-only proof, extracting both the key and the aggregate key needs two forkings and therefore four executions of the adversary, which is why that proof requires four nonces; assuming the algebraic group model, two nonces suffice.

What to watch for

The price of the saved round is a stronger assumption than plain discrete logarithm: security rests on the algebraic one-more discrete logarithm assumption, which asks that no algorithm output the discrete logs of q plus 1 challenge group elements while making at most q discrete-log queries. It is a falsifiable variant that follows from the older one-more discrete logarithm assumption.

Useful background: MuSig2 nonce randomization with several nonces.

Papers

MuSig2 nonce randomization with several nonces

MuSig2 removes the commitment round by having every signer publish a list of at least two nonces instead of one, and by deriving a single random-looking coefficient b from a hash of all signers' nonce products and the message. Each signer effectively signs with a power combination of its own nonces.

Why it is useful

It makes the honest signer's effective nonce uncontrollable: whenever the adversary changes its reply, the coefficient b changes with it, so the quantity that the concurrent-session attacks need to hold constant keeps moving. Without that fixed target, Wagner's algorithm does not apply.

How it works

  1. In the first round, signer i broadcasts nonces for positions 1 through nu, with nu at least 2, before knowing the message or the cosigners.
  2. Everyone hashes the products of all signers' nonces at each position, together with the aggregate key and the message, to obtain b.
  3. The effective nonce of signer i is the product of its nonces raised to the powers 1, b, b squared, and so on up to b to the power nu minus 1.
  4. The aggregate nonce, the challenge and the response are then computed exactly as in Schnorr, with each signer adding its nonce exponents weighted by those same powers of b.

What to watch for

One exponentiated nonce is not enough: with nu equal to 1 the adversary can fold the coefficient into its chosen target value and the attack goes through again. The number of nonces is a real parameter choice, tied to which security proof one accepts.

Useful background: MuSig, Concurrent sessions break earlier two-round multisignatures.

Related ideas

  • MuSig: Extends MuSig by dropping the commitment round.

Papers

MuSig2 deployment requirements

Deploying MuSig2 safely requires a good random number generator, strict one-time use of the per-session nonce state, and treating any coordinator node as untrusted.

Why it is useful

The nonce exponents must be truly random. Deriving them deterministically from the secret key and the message, a common habit for protecting single-signer Schnorr implementations, is insecure for essentially all Schnorr multi-signatures including MuSig2. Re-running the second round on the same state reuses nonces and exposes the secret key.

How it works

  1. Generate each nonce exponent with a secure random generator; do not derandomize by hashing the secret key and the message.
  2. Store the nonce state so the second round runs at most once per state, and erase it afterwards.
  3. Guard against accidental reuse, for example restoring an old backup, and against deliberate tampering with the storage.
  4. If a coordinator aggregates traffic, it only relays and multiplies public values and is modeled as untrusted; signers can equally broadcast directly, and using the coordinator keeps total communication linear rather than quadratic in the number of signers.
  5. Choose the number of nonces: two is the efficient option if one accepts the random oracle model together with the algebraic group model, and four keeps a proof in the random oracle model alone.

What to watch for

The only known way to avoid the randomness requirement is to prove deterministic nonce derivation with zero-knowledge proofs as in MuSig-DN, which costs far more than three-round MuSig. The paper specifies the protocol; it does not audit any implementation.

Useful background: MuSig2.

Related ideas

  • MuSig-DN: Avoids the randomness requirement with zero-knowledge proofs.

Papers

The rogue-key attack on naive multisignatures

If the aggregate public key is simply the product of all signers' public keys, a cheating signer can choose its own public key so that the product collapses to a key it alone controls. It can then produce valid signatures for the whole group by itself.

Why it is useful

It shows that key aggregation cannot be naive: without extra protection, one malicious cosigner forges for everyone, and none of the honest signers ever needs to participate.

How it works

  1. Let the honest signers publish their keys X2 up to Xn first.
  2. The attacker picks a secret x1 and sets its public key to g to the power x1, multiplied by the product of all other keys raised to the power minus one.
  3. Multiplying all the keys together now leaves exactly g to the power x1, a key whose secret only the attacker knows.
  4. Any signature the attacker makes on its own satisfies the group verification equation.

What to watch for

Requiring each user to attach a proof that it knows its secret key blocks the attack, but it makes key management cumbersome and does not fit widely used key formats. The paper instead repairs the aggregation rule itself, as MuSig does. Note also that the adversary may choose corrupted public keys arbitrarily and may even duplicate keys in the list.

Useful background: Multi-signatures: one signature from a group.

Related ideas

  • MuSig: Defeats this attack with hash-weighted keys.

Papers

Why Bitcoin wants Schnorr-compatible multisignatures

Bitcoin's Schnorr signature standard motivated the search for multi-signatures that are drop-in compatible: a group signature must be an ordinary Schnorr signature that verifies against a single aggregate public key.

Why it is useful

Signatures live on a blockchain, so compactness saves space and cost. Verification code stays unchanged because verifiers only run ordinary Schnorr verification, and since a verifier sees one key and one signature it cannot tell a single user from a group, which improves privacy.

How it works

  1. Coins are held under an aggregate public key computed from the signers' keys.
  2. Spending presents one Schnorr signature; the verifying node may not even know that the key aggregates several keys, and only checks that the owners of the coins authorize the spend.
  3. The first MuSig2 round can be prepared before the message or the signer set exists, which turns the online phase into a single round; the paper argues this is safe because an adversary choosing the message or the signer set after seeing the nonces gains nothing.
  4. Earlier two-round alternatives failed the drop-in requirement, for example mBCJ outputs signatures more than twice as large as Schnorr signatures.

What to watch for

The formal security game has the forger name the list of public keys. The paper argues this also covers the aggregate-key mode used in Bitcoin, because a forgery under an aggregate key that does not involve the honest key cannot spend coins owed to the honest user.

Useful background: Multi-signatures: one signature from a group, MuSig2.

Papers

Privacy and verification control for signatures

Hiding messages during issuance, signer identity during verification, or transferable evidence of validity. These are distinct properties; credential and payment protocols belong under privacy systems.

Message privacy and signature encodings

A public signature lets anyone with the verification key check guesses about the signed message. Hiding a low-entropy message therefore needs more than choosing a secure signature scheme.

Why it is useful

It separates signature authenticity from confidentiality and explains why output length or timing can matter when signatures are deliberately kept private.

How it works

  1. Decide whether the message, signature and verification key are public.
  2. Account for offline message guessing whenever verification is available.
  3. If output secrecy is required, examine message-dependent timing and encoded lengths.
  4. Use an appropriate confidentiality mechanism rather than relying on authenticity alone.

What to watch for

Falcon's optional fixed-length encoding and constant-time hash-to-point target additional leakage in an unusual secret-output setting. They do not hide a guessable message from someone who already has its public signature and verification key.

Papers

Blind and partially blind signatures

Interactive issuance hiding a message or selected fields while preserving unforgeability, including partially blind and restrictive variants.

Blind signatures

Blind-signature protocols let a signer sign a message through a blinded interaction.

Papers

Honest limits of the AGM argument

The AGM result is a clean characterisation, but three limits are worth stating plainly: earlier proofs were informal, the classical standard-model route looks blocked, and the AGM itself can invite overconfident shortcuts.

Why it is useful

Reading a proof in an idealised model without noting what the model assumes is how a scheme gets trusted for the wrong reason.

How it works

  1. Before this paper the only positive result was in the generic group model plus the random oracle model, and it assumed ROS was hard without a precise statement of the problem.
  2. Separate results indicate that one-more unforgeability of blind Schnorr signatures cannot be proved from standard assumptions at all, not even in the random oracle model. AGM proofs live with that by changing the model rather than defeating the barrier.
  3. The authors point out that Bernhard et al. concluded too quickly that signed ElGamal was secure in the AGM once straight-line extractability was available; writing out the proof showed the gap. Idealised models do not make arguments automatic.
  4. Finally, the ROS assumption itself collapsed in 2020, while the modified problem used for the clause scheme held. A reduction is only as good as the problem it reduces to.

Example

A correct reduction to a broken problem still yields a broken scheme, which is what happened to plain blind Schnorr signatures.

What to watch for

The AGM statement is conditional on adversaries being algebraic, and on the hardness of the target problem. Neither condition is a given.

Useful background: What the AGM proof actually delivers, Why concurrent security failed: Wagner and the 2020 break.

Papers

ROS: the linear system behind the attack

ROS stands for Random inhomogeneities in an Overdetermined, Solvable system of linear equations. The attacker must find more vectors than there are unknowns, yet have the system stay solvable, where the right-hand sides come from a random oracle.

Why it is useful

Solving ROS is equivalent to breaking blind Schnorr signatures: an attacker that solves it produces l+1 valid signatures after only l concurrent signing sessions, which violates one-more unforgeability.

How it works

  1. Pick l+1 row vectors of length l, where l is the number of open sessions.
  2. Query a random oracle on each row to get the right-hand side values.
  3. Find unknowns c1, ..., cl that satisfy all l+1 equations at once.
  4. There are more equations than unknowns, so a random right-hand side makes the system unsolvable. Winning means finding rows for which it happens to be solvable anyway.

Example

With l = 1 you need two rows (a, a') and hashes h, h' with a*c = h and a'*c = h' for the same c. A random h makes that a coincidence you cannot force.

What to watch for

For small l the problem is statistically hard: the odds that a random right-hand side lies in the span of the rows are about 1/p. Hardness collapses as l grows, which is the subject of the next lesson.

Useful background: The rogue-choice problem: the user picks the challenge.

Papers

The algebraic group model

The AGM sits between the standard model and the generic group model. The adversary sees real group elements, but every group element it outputs must arrive with an explanation of how it was built from the elements it was given.

Why it is useful

That explanation, called a representation, is the handle a security proof needs. It lets the proof read the discrete logarithm of a forgery straight out of the coefficients the adversary itself supplied.

How it works

  1. Give the adversary the generator G, the public key X, and the session nonces.
  2. Whenever the adversary outputs a group element Z, it must also output coefficients z = (z0, ..., zn) with Z = sum of zi*Xi.
  3. The proof checks the arithmetic. If the coefficients are inconsistent the adversary has broken the group itself.
  4. Because the model still allows reductions to ordinary computational problems, unlike the information-theoretic generic group model, results carry the flavour of standard-model proofs.

Example

Handed G and X, an algebraic adversary cannot conjure a fresh group element out of thin air. It can only hand back something like 3G + 5X and say so.

What to watch for

The AGM is an assumption about adversaries, not a theorem about them. A proof in the AGM covers adversaries that play by this rule, and says nothing about whatever else might exist.

Useful background: Digital signatures.

Papers

The blind Schnorr issuing protocol

Take an ordinary Schnorr signature and split it across two parties: the signer supplies a nonce and answers one challenge, while the user blinds that challenge and unblinds the answer.

Why it is useful

It keeps the signature format of plain Schnorr, so anything that already verifies Schnorr signatures can verify these too, and the protocol needs only a couple of group operations per round.

How it works

  1. The signer picks a nonce r and sends R = rG.
  2. The user picks blinding values alpha and beta, computes R' = R + alpha*G + beta*X, hashes it with the message to get c', and sends back c = c' + beta.
  3. The signer answers with s = r + c*x. The user checks sG = R + cX, then outputs the signature (R', s') with s' = s + alpha.
  4. Rearranging gives s'G = R' + H(R',m)X, which is exactly Schnorr verification on the hidden message.

Example

With alpha = beta = 0 the protocol degenerates to ordinary Schnorr signing with no blindness at all.

What to watch for

The user is free to choose alpha and beta however it likes. An honest user picks them at random; a dishonest user turns that freedom into the attack described two lessons on.

Useful background: What a blind signature is for.

Papers

The clause protocol: run two sessions, finish one

The fix changes only the conversation. Signer and user run two blind Schnorr sessions in parallel, and in the last round the signer picks one of the two at random and completes only that one.

Why it is useful

It removes the leverage the rogue choice gave the attacker. Now, for every open session the attacker must guess in advance which of its two challenges the signer will answer, and every wrong guess wastes the work built on it.

How it works

  1. The signer sends two nonces R0 and R1 instead of one.
  2. The user blinds both and returns two challenges.
  3. The signer flips a coin, answers only the chosen challenge, and discards the other run.
  4. The user unblinds the answer it receives into an ordinary Schnorr signature.
  5. Security now rests on a modified ROS problem in which the attacker commits to each coordinate before learning a random bit that constrains the shape of its rows.

Example

Two runs cost roughly twice the communication and signing time, which is the whole price of the change: keys and verification are untouched.

What to watch for

The paper conjectures rather than proves that guessing all the random bits and then running Wagner is the best attack, so the added cost is a factor of 2^l. Conjectures are not theorems, and the authors say so.

Useful background: Why concurrent security failed: Wagner and the 2020 break.

Papers

The rogue-choice problem: the user picks the challenge

In this protocol the signer never chooses the challenge it answers. The user computes c = c' + beta, so whatever value the user sends becomes the challenge, and the signer signs against it without seeing how it was made.

Why it is useful

That freedom is what a cheating user exploits. By opening many sessions first and only then deciding which challenges to submit, the user can correlate the signer's answers instead of treating them one at a time.

How it works

  1. Open many signing sessions and collect the nonces R1, ..., Rl.
  2. Choose the challenges c1, ..., cl jointly, as a set, rather than one per session.
  3. Send them all at once to close every session.
  4. Each answer s_j = r_j + c_j*x is a linear equation in the secret key, and a correlated choice of the c_j can be solved for extra signatures.

Example

One session gives one equation in x and teaches nothing. Many sessions with hand-picked challenges give an over-determined linear system, which is exactly the ROS problem of the next lesson.

What to watch for

The security game lets the adversary schedule and interleave sessions arbitrarily, so "finish one session before starting the next" is not something the signer can demand.

Useful background: The blind Schnorr issuing protocol.

Papers

What a blind signature is for

A blind signature is issued by an interactive protocol instead of a one-shot signing call: the user hides the message, the signer still signs something useful, and the user ends up with at most one valid signature per completed run.

Why it is useful

Applications that promise anonymity need a signer who cannot later recognise its own signatures. Electronic cash, anonymous credentials, electronic voting and direct anonymous attestation all rely on this split.

How it works

  1. The user runs a signing protocol with the signer, sending blinded values rather than the message itself.
  2. Blindness: even the signer cannot match a finished signature back to the session that produced it, so the message stays hidden.
  3. One-more unforgeability: if the signer counted k completed sessions, no user can produce more than k valid signatures.
  4. Without the second condition a user could mint signatures for free, which would ruin an e-cash or credential system.

Example

A bank signs a blinded coin. Later it sees the coin being spent but cannot tell which issuing session produced it, so it cannot trace the payer.

What to watch for

Blindness protects the user against the signer; one-more unforgeability protects the signer against the user. Both must hold at once, and they pull in opposite directions.

Related ideas

  • Digital signatures: the underlying primitive that gets issued blindly

Papers

What the AGM proof actually delivers

The theorem says an algebraic adversary that produces l+1 valid signatures from l sessions must have solved either the one-more discrete logarithm problem or ROS. There is no third route inside the model.

Why it is useful

It settles the security of the protocol on stated assumptions instead of leaving it at the level of an informal argument, and it is the first rigorous proof for this scheme.

How it works

  1. OMDL, one-more discrete logarithm: given q group elements and an oracle that solves discrete logs, return all q logarithms while calling the oracle fewer than q times.
  2. The reduction embeds its own challenges as the public key and the session nonces, and answers each closing challenge by asking the oracle for the logarithm of R_j + c_j*X.
  3. When the adversary's representation of a forgery clashes with the signature equation, the clash isolates log X and the reduction wins OMDL.
  4. When no such clash exists anywhere, the adversary's choices form a ROS solution, and the reduction wins ROS instead.

Example

One session, one forgery: the reduction used one discrete-log query to simulate the session and can still read the secret key out of the forgery, so nothing is gained.

What to watch for

The proof is tight, meaning it avoids the rewinding and security loss of the classical forking-lemma argument, but it holds only against algebraic adversaries.

Useful background: The algebraic group model, The rogue-choice problem: the user picks the challenge.

Papers

Why concurrent security failed: Wagner and the 2020 break

ROS reduces to a generalised birthday problem, and Wagner's algorithm solves that in sub-exponential time once the number of concurrent sessions is large enough. In 2020 the problem fell outright.

Why it is useful

This is why blind Schnorr signatures were never safe at standard group sizes: a 256-bit group does not buy 128 bits of security here, and raising the group order to compensate makes the scheme slow.

How it works

  1. ROS becomes a search for several hash values that sum to zero, which is the k-sum problem.
  2. Wagner's algorithm builds lists of hash outputs and combines them in a tree to find such a sum far faster than brute force.
  3. The cost drops as the number of sessions l grows, so an attacker willing to run many concurrent sessions wins.
  4. Benhamouda et al. later gave a polynomial-time algorithm for ROS once l exceeds about log2(p), which finishes the scheme as it stood.

Example

The paper reports that for a 256-bit group an attacker could obtain extra signatures after roughly a dozen concurrent sessions using Wagner's method.

What to watch for

The paper notes the classical way out, enlarging the group order, and rejects it as inefficient. The constructive answer is the clause protocol of a later lesson.

Useful background: ROS: the linear system behind the attack.

Papers

Designated verification and undeniable signatures

Restricted or interactive verification, designated-verifier simulation and confirmation/disavowal protocols. Non-transferability, invisibility and undeniable validity require different definitions.

Group signatures and accountable anonymity

Group signatures differ from ring signatures in that membership is managed: an authority enrolls members by issuing keys, holds the opening key that traces signatures to a signer, and can revoke members. This paper proves its scheme anonymous in a chosen-plaintext variant of the standard model and fully traceable, then extends it with revocation and exculpability.

Anonymity with a fully corrupt issuer

Anonymity is an indistinguishability game. The attacker names two honest members and a message, receives a signature produced by one of them according to a hidden bit, and must guess which. To win it does not have to recover an identity; telling the two chosen signers apart is already a break. The attacker holds the issuer key, can play the issuer in joining sessions, can read both secret keys of any user, and can edit the registration table, and it may ask the opener to trace any signature except the challenge one.

Why it is useful

Handing over the issuer key states that anonymity must survive a complete compromise of the issuer, which is the strongest assumption available short of also giving away the opener key. Letting the attacker distinguish rather than identify makes the game easier to win and therefore harder on the scheme.

How it works

  1. The challenge oracle signs the message with the signing key of one of the two named honest members, following the hidden bit, and records the pair so the opening oracle will refuse it later.
  2. The attacker may fully corrupt the issuer, obtain both keys of any user, write to the registration table, and open any signature other than the challenge.
  3. The scheme is anonymous if the attacker's advantage, the difference between its success probabilities for the two values of the hidden bit, is negligible in the security parameter.
  4. The opener key is withheld, since it would let the attacker open signatures by itself, and oracles redundant under the rest are omitted.

Example

Two employees sign the same message; an attacker holding the issuer key and every employee secret key still cannot say which of the two produced a given signature.

What to watch for

Anonymity is conditional: it holds only while the opener is uncorrupt. A scheme can satisfy this definition and still reveal every signer the moment the opening key leaks, so the condition belongs in any security claim about a deployment.

Useful background: Oracles as a menu of attack capabilities, Correctness under adversarial joining schedules.

Related ideas

Papers

Correctness under adversarial joining schedules

Correctness asks three things of a signature from an honest member: it verifies, the opener names the right member, and the judge accepts the opener's proof. Because members join at times the attacker controls, correctness is stated as an experiment in which an adversary enrolls honest users in any order it likes and then names one of them plus a message.

Why it is useful

In a static group correctness can be checked once against a fixed member list. Once joining is scheduled from outside, the guarantee has to hold for every possible schedule, and an experiment is the standard way to say "for every schedule".

How it works

  1. Run group key generation, then let the adversary add honest users through the add-user oracle and read the registration table.
  2. The adversary outputs an honest user i and a message m; the experiment signs m with the signing key of i.
  3. The scheme is incorrect if the signature fails verification, if the opener names anyone other than i, or if the judge rejects the opener's proof.
  4. Correctness requires the failure probability to be zero for every adversary and every security parameter, and the adversary here is not computationally bounded at all.

Example

A member who joined first and a member who joined last must both produce signatures that verify and open correctly, whichever order the adversary chose for enrolling them.

What to watch for

Correctness only constrains honest execution. It says nothing about forged signatures, which is the job of the three security requirements.

Useful background: Oracles as a menu of attack capabilities, The algorithms of a dynamic group signature scheme.

Related ideas

  • Group signatures: The honest-case promise that the security requirements then build on.

Papers

CPA-full-anonymity and full-traceability

The two security properties the scheme is proven to satisfy, following the definitions of Bellare, Micciancio and Warinschi: anonymity says signatures do not reveal their signer, and traceability says every valid signature, even one forged by a coalition that includes the group manager, traces to a group member.

Why it is useful

These two requirements pull in opposite directions - one hides the signer, the other guarantees the hidden identity can always be recovered - and proving both is what makes the primitive trustworthy rather than merely private.

How it works

  1. Correctness: honestly generated signatures verify and open correctly.
  2. Anonymity is proved in a weakened model, called CPA-full-anonymity, where the attacker may not query the opening oracle at all; the original experiment allowed such queries before and after the challenge, mirroring adaptive chosen-ciphertext attacks.
  3. The paper argues this is reasonable because tracing access will be tightly controlled in practice, and that the traditional anonymity and unlinkability requirements still follow.
  4. Anonymity reduces to the semantic security of Linear encryption: an attacker who tells which of two members signed would distinguish the underlying encryptions.
  5. Traceability reduces to the Strong Diffie-Hellman assumption via the forking lemma, splitting forgers into two types - those whose forgery opens outside the member list, and those whose forgery opens to a member whose key was never requested.

What to watch for

The relaxation from the full to the CPA anonymity notion is a real loss: a scheme proven here could still leak through an opening oracle. The traceability bound also loses factors typical of forking-lemma proofs, so the concrete security margin is smaller than the assumption's.

Useful background: The SDH group signature scheme, Decision Linear assumption and Linear encryption, Fiat-Shamir transform.

Related ideas

  • Group signatures: States precisely what accountability and privacy such a scheme must deliver.

Papers

Non-frameability against corrupt authorities

Non-frameability says the attacker cannot produce a judge-accepted proof that an honest user signed a message, unless that user really signed it. The attacker holds both authority keys, can run the joining protocol in the issuer's role, can read the signing keys of every user except its target, and can rewrite the registration table; it loses only if it obtained the target's signing key or asked for that exact user and message from the signing oracle.

Why it is useful

This requirement protects the member rather than the group: anonymity and traceability are worth little to someone who can be blamed for a signature they never made. Because both authorities may be fully corrupt here, the protection has to come from outside them, which is the role of the personal certified key pair each user holds before joining.

How it works

  1. Before joining, each user obtains a personal public key certified independently of any group authority, together with the matching private key.
  2. During joining, the user signs, with that personal private key, the verification key it will use for group signing, and the issuer stores this signature in the registration table.
  3. The stored signature is later the evidence behind the opener's proofs, so blaming a member for a signature it did not make would require forging the member's personal signature.
  4. The experiment: the attacker outputs a message, a signature, an identity and a proof, and wins only if the signature is valid, the identity is honest with a defined signing key, the judge accepts, and the attacker neither exposed that key nor requested that signature.
  5. The requirement is stated separately from traceability because it holds under less trust: traceability needs an uncorrupt issuer, non-frameability does not.

Example

Even an attacker holding the issuer and opener keys cannot make a judge attribute a signature to a member who never signed, unless it also forges that member's personal signature.

What to watch for

The guarantee leans on the personal key infrastructure. Without an authentic personal public key for each member there is nothing for the member to sign with at joining time, and the protection against a corrupt issuer disappears.

Useful background: Traceability and its minimal trust, Splitting the group authority in two.

Related ideas

Papers

Oracles as a menu of attack capabilities

The model hands the attacker a fixed collection of oracles, each standing for one capability: adding an honest user, corrupting a user, playing either side of the joining protocol, reading a user's two secret keys, reading or editing the registration table, obtaining signatures, asking who produced a given signature, and a challenge oracle that signs with one of two members the attacker names. Each definition then gives the attacker some subset of this collection.

Why it is useful

Separating capabilities from requirements keeps the definitions short and comparable, and it makes the model extensible: a future requirement can be expressed by adding an oracle rather than by rewriting the model, which matters in an area where the goal list kept growing.

How it works

  1. Specify the oracles once, as procedures over shared state: sets of honest and corrupt users, a record of signatures produced by the challenge oracle, and the registration table.
  2. For each requirement, list which oracles the attacker receives; the list is the formal statement of the attacker's power.
  3. Two examples: the add-user oracle enrolls an honest user and returns only its personal public key, while the user-secret-keys oracle returns both the personal private key and the group signing key of a named user.
  4. Concurrency is captured by letting the attacker schedule message delivery across any number of simultaneous joining sessions.

Example

The opening oracle answers "who signed this" for any signature, but refuses the one signature the challenge oracle produced, so the anonymity game stays meaningful.

What to watch for

An oracle list is a claim about reality. Leaving a capability out quietly weakens every definition built on the list, which is why the paper argues separately that each requirement assumes the least trust in each authority that the requirement permits.

Useful background: The algorithms of a dynamic group signature scheme.

Related ideas

Papers

Revocation and exculpability in group signatures

Ways to retire a member: the revocation mechanism of Camenisch and Lysyanskaya publishes data that forces a group-wide public key update, while verifier-local revocation sends revocation data only to verifiers. Exculpability is the separate promise that nobody, not even the key issuer, can frame a member.

Why it is useful

Revocation is what makes anonymous membership usable in practice - a compromised car chip must be switched off without reissuing every key. Exculpability protects the member in the other direction: anonymity must not become an excuse to blame someone who did not sign.

How it works

  1. A revocation authority publishes a revocation list containing the private keys of revoked users.
  2. From the list, anyone recomputes the group public key; unrevoked users adjust their own keys locally to match, and revoked users cannot.
  3. Because a revocation entry exposes that user's private key, updates must reach all verifiers simultaneously, or a holder of a fresh entry can fool a verifier with a stale list.
  4. In verifier-local revocation only a fragment of the private key is published and only verifiers need the list, so unrevoked signers never update.
  5. For strong exculpability, keys are issued through a joining protocol in which the user adds a secret of her own; the issuer ends up unable to forge under her key, and the proof system extends to cover the three-part key.

What to watch for

The paper describes revocation along the lines of an earlier accumulator-based mechanism and only cites, rather than develops, the verifier-local variant. Strong exculpability is sketched briefly; the joining protocol and the modified proof are not given in full here.

Useful background: The SDH group signature scheme, CPA-full-anonymity and full-traceability.

Related ideas

  • Group signatures: Revocation and non-framing are the accountability half of the primitive.

Papers

The algorithms of a dynamic group signature scheme

A dynamic group signature scheme is a tuple of eight algorithms: group key generation, user key generation, the two sides of the joining protocol, group signing, group verification, opening and judging. Opening takes a valid signature and returns either an identity together with a proof, or zero meaning no member produced it; judging checks such a proof against the personal public key of the claimed member.

Why it is useful

Naming the parts is what makes an exact definition possible. In particular, making the opener produce a proof, and giving a separate judge algorithm to check it, is what protects members against an opener that simply asserts a false attribution.

How it works

  1. Group key generation outputs the group public key plus separate issuer and opener keys.
  2. User key generation lets anyone create a personal key pair independently of any group.
  3. Join and Iss are the two sides of the joining protocol; when the issuer accepts it records an entry for the user in a registration table, and when the user accepts its final state is its signing key.
  4. GSig produces a signature that anyone checks with GVf under the single group public key.
  5. Open, run by the opener with read access to the registration table, returns a pair (i, tau): i of at least 1 names a member and tau is a proof, while i of 0 claims no member produced the signature.
  6. Judge verifies tau using the personal public key of the claimed member, so its verdict does not depend on trusting the opener.

Example

Verification looks like an ordinary signature check against one public key; only the opener can name a signer, and a court uses the judge algorithm to confirm that claim without trusting the opener.

What to watch for

The joining protocol is assumed to run over private and authenticated channels. The authors call this assumption a convenience and note that the protocols can be modified to avoid it.

Useful background: Group signatures, Splitting the group authority in two.

Related ideas

  • Group signatures: The same interface without the joining protocol, which only a dynamic group needs.

Papers

Traceability and its minimal trust

Traceability says the attacker cannot produce a valid signature that escapes the opener: either the opener returns zero, claiming that no member produced the signature, or it names a member but cannot supply a proof the judge accepts. The attacker may create honest members, read both secret keys of any user, read the registration table, and corrupt users, but the issuer is assumed uncorrupt and the registration table cannot be rewritten.

Why it is useful

It is the accountability half of the primitive: anonymity is only acceptable if every valid signature still has an origin that can be established. The trust assumptions are not a choice but a limit, since a partially corrupt issuer could invent members of its own and a fully corrupt opener could refuse to trace at all.

How it works

  1. The attacker outputs a message and a signature; the experiment runs the honest opener on it.
  2. The attacker wins if the signature verifies and either the opener returns zero, or the opener returns a positive identity whose proof the judge rejects.
  3. The scheme is traceable if this winning probability is negligible.
  4. The issuer must be uncorrupt because a partially corrupt one can create dummy users with valid keys and sign untraceably; the opener may be partially but not fully corrupt because a fully corrupt one can simply stop tracing.

Example

A coalition that steals every member key still cannot produce a signature that the opener cannot attribute with a proof a judge accepts.

What to watch for

Formal traceability alone is a little weaker than the everyday meaning of the word. What one intuitively wants from tracing is delivered by traceability together with non-frameability, a gap the authors point out themselves.

Useful background: Oracles as a menu of attack capabilities, The algorithms of a dynamic group signature scheme.

Related ideas

Papers

Ring and linkable signatures

A ring signature lets one member of a freely chosen set of public keys sign while the signature names no individual. This paper sharpens what anonymity and unforgeability should mean when the ring may contain keys that no authority checked, and when ring members later reveal their keys, and it gives constructions secure without random oracles, including efficient ones for rings of exactly two keys.

Ring composition forgery on a discrete-log ring signature

An attack on a published discrete-log ring signature: the scheme hides the signer perfectly, and resists forgers when the ring is fixed in advance, but two signatures obtained for disjoint rings on the same message can be glued together into a valid signature for the union of the rings.

Why it is useful

It shows the gap between fixed-ring and chosen-subring security with a real scheme rather than a contrived one, and it shows why the ring itself must be bound into the hashed data.

How it works

  1. Ask the signing oracle for a signature on a message M under a first ring; the answer has the form (b, C1, ..., Cn), where each C value commits to one ring member's share.
  2. Ask again for the same message M under a second ring disjoint from the first, getting (b', C'1, ..., C'm).
  3. Output (b + b', C1, ..., Cn, C'1, ..., C'm) as a signature on M for the union of the two rings.
  4. The verification equation multiplies over all ring members, so the two halves multiply together and the sum b + b' satisfies the combined check; only an accidental collision between the two sets of C values spoils it.
  5. The repair is small: include the ring as an input to the hash, so shares computed for one ring do not help in another.

What to watch for

The original scheme was analyzed in the random oracle model, and its unforgeability claim covered only fixed-ring attacks; the patched version was shown secure in later work the authors cite. The lesson is about binding the ring into the signature, not a claim that the patched scheme meets today's standards.

Useful background: Unforgeability levels for ring signatures, Discrete logarithm problem.

Related ideas

Papers

SNOVA

SNOVA is a multivariate signature scheme using noncommutative ring structure.

Papers

Two-user ring signatures from Waters and Camenisch-Lysyanskaya signatures

Two efficient ring signature schemes that work only for rings of exactly two users. Both start from an ordinary pairing-based signature and exploit the fact that either of the two parties can compute the one secret value a signature needs, so the signature itself cannot say which one produced it.

Why it is useful

They stay in the standard model, avoid the heavy machinery of the generic construction, and are enough for uses where only two possible signers matter, such as a sender and a receiver of an e-mail. Even this case is hard without random oracles, because the usual Fiat-Shamir trick for removing interaction is unavailable.

How it works

  1. Waters variant: the ordinary scheme has a public value h whose corresponding secret is needed to sign; drop h from the public key and use the other user's published group element as h instead, so each user can compute the needed shared value from their own secret.
  2. Camenisch-Lysyanskaya variant: a signature can be produced either from one user's first secret together with the other's public value, or the other way around, so both users can sign and the results look alike.
  3. Give each key a random identifier and let the lexicographic order of the two identifiers decide which of the two symmetric computations to run, saving work.
  4. Verification is the original scheme's check applied to the pair of keys; anonymity is unconditional and survives exposure of both secret keys.
  5. Security of the underlying ordinary signature carries over: a forger for the two-user scheme yields a forger for the ordinary scheme with the same probability.

What to watch for

The schemes sign for exactly two users, and their unforgeability is proved only against chosen-subring attacks, not against insider corruption; they also depend on specific pairing assumptions rather than general ones. They are 2005 feasibility designs and carry no parameter guidance.

Useful background: Ring signatures, Waters signatures, Camenisch-Lysyanskaya credentials.

Related ideas

Papers

Single-signer signatures and signing methods

A signer uses a private key to sign a message. A verifier uses the corresponding public key to check it. Different constructions use different mathematical problems and signing procedures.

BBS signatures

BBS signs an ordered vector of field elements with a signature containing one group element and one scalar. Its algebra lets a holder prove possession of a signature while revealing only selected message components.

Why it is useful

A credential can certify several attributes without requiring every presentation to disclose the complete signed record.

How it works

  1. Represent the message components as scalars with fixed positions.
  2. Combine the components using separate public group generators.
  3. The signer uses its secret scalar and a fresh signature scalar to compute the signature point.
  4. Verify a bilinear pairing equation, or use a separate proof of knowledge for private presentation.

What to watch for

The paper proves the short BBS variant under q-SDH and separately in the algebraic group model. Message encoding, domain separation, subgroup validation and exceptional denominators still need a concrete specification. BBS is not automatically a rerandomizable or aggregatable signature scheme.

Papers

BBS+ signatures

BBS+ adds a randomly chosen blinding scalar to the signed group expression. Its signature contains one group element and two scalars, whereas the short BBS variant needs one group element and one scalar.

Why it is useful

The added scalar was used in earlier security reductions and is useful for understanding the distinction between the two historical variants.

How it works

  1. Choose a random blinding scalar and a signature scalar.
  2. Add the blinding contribution through its own public generator.
  3. Use the secret signing exponent to form the signature point.
  4. Include both scalars so verification can reconstruct the signed expression.

What to watch for

Removing the blinding term needs a security argument; it is not justified by treating the term as unused overhead. This paper supplies a new proof for the shorter variant, without making every BBS+ application interchangeable with BBS.

Related ideas

  • BBS signatures: Omits the additional blinding scalar and has a different security reduction.

Papers

BLS signatures

BLS signatures multiply a hashed curve point by a signing scalar and verify using a pairing.

Papers

EdDSA

EdDSA is a Schnorr-style signature design specified for Edwards curves.

Papers

LESS

LESS is a code-based signature scheme built around code equivalence.

Papers

ML-DSA

ML-DSA is the standardized module-lattice signature scheme derived from Dilithium.

Papers

Signature-scalar collisions in BBS

The scalar component of a BBS signature must avoid collisions across different signed messages. Two signatures sharing that scalar can be combined algebraically into a signature on a related message.

Why it is useful

It explains why a scalar that is public still needs careful generation and why a persistent counter requires reliable state.

How it works

  1. Track the distribution or state used to choose signature scalars.
  2. Account for collision probability across the total number of signatures.
  3. For counter-based variants, prevent rollback, concurrency collisions and wraparound.
  4. Use the security theorem matching the chosen scalar-generation method.

Example

For an odd prime order, combining two signatures with the same scalar using the inverse of 2 gives a signature on the componentwise average of their message vectors.

What to watch for

The paper's standard-model theorem uses uniformly sampled scalars. Its counter and truncated variants use the separate algebraic-model analysis. A public counter is not interchangeable with the secret nonce used in Schnorr signing.

Papers

SQIsign

SQIsign is a signature scheme using supersingular isogenies and quaternion arithmetic.

Papers

Hash-and-sign constructions

These signatures first encode or hash a message, then use a private-key operation such as trapdoor inversion or short-preimage sampling. The encoding is part of the security argument.

Falcon

Falcon is a lattice-based signature construction in which a secret short lattice basis helps produce a short vector matching a hashed message.

Why it is useful

It combines compact signatures with verification that mainly uses polynomial arithmetic modulo a public prime.

How it works

  1. Generate a secret NTRU basis and its public polynomial h.
  2. Hash a fresh nonce and the message to a target polynomial c.
  3. Sample short polynomials s1 and s2 satisfying s1+s2*h=c in the public polynomial ring.
  4. Send the nonce and s2.
  5. Verify by reconstructing s1 and checking the required norm bound.

What to watch for

Passing the algebraic and norm checks does not prove that the signer sampled securely. This source describes a revised 2019 implementation; its encodings, parameters and benchmarks are not a specification of a later standard.

Useful background: NTRU lattices, Discrete Gaussian sampling.

Papers

Expanded signing keys and precomputation

An expanded Falcon key stores secret-basis transforms and key-dependent sampling-tree data in a form that can be reused across signatures.

Why it is useful

It saves repeated work during signing at the cost of a larger secret representation in memory.

How it works

  1. Identify computations that depend only on the secret key.
  2. Precompute the basis transforms and sampling-tree data.
  3. Reuse those values while computing message-dependent targets separately.
  4. Account for expanded-key storage as well as temporary workspace.

What to watch for

Precomputation does not make the resulting data public. The paper's dynamic variant uses less retained memory but rebuilds more data; the faster signing measurements with an expanded key do not include key expansion on every signature.

Papers

Fixed schedules for secret polynomial reduction

A reduction loop can leak through the measured sizes of secret coefficients and the point at which it stops. A conservative schedule uses public bounds instead of stopping as soon as the secret-dependent goal is reached.

Why it is useful

It makes the amount of work less dependent on secret intermediate values.

How it works

  1. Bound the size of the secret coefficients.
  2. Read a fixed-size approximation window.
  3. Use a conservative estimate of progress per iteration.
  4. Continue according to the justified schedule rather than a secret-dependent early exit.

What to watch for

The schedule must still leave the computation correct for its allowed inputs. The Falcon paper uses statistical size estimates in its Babai reduction; its historical measurements are not a universal correctness or leakage proof for other parameters.

Papers

Fourier sampling with an LDL tree

Falcon's Fourier sampler recursively decomposes a Gram matrix derived from the secret basis. At the leaves it samples small integers, then combines them into a lattice vector near the target.

Why it is useful

It turns a large structured lattice-sampling problem into smaller problems while accounting for dependencies between coordinates.

How it works

  1. Form the Gram matrix B*B-adjoint from the secret basis.
  2. Use an LDL-adjoint decomposition to separate diagonal sampling data from coordinate corrections.
  3. Split into smaller polynomial problems and recurse.
  4. Use the sampled coordinates to adjust the remaining target before continuing.
  5. Merge the recursive results into the final sampled vector.

What to watch for

This is a conceptual outline. The order of dependent samples, coordinate corrections, widths and numerical precision must follow a complete sampler specification; independent rounding of coordinates is not an equivalent replacement.

Useful background: Fast Fourier transform, Discrete Gaussian sampling.

Papers

Hash-and-sign lattice signatures

Lattice hash-and-sign constructions sample a short preimage of a hashed message under a public linear map.

Papers

HAWK

HAWK is a lattice signature scheme using a hash-and-sign design over module lattices.

Papers

Plover signatures

Plover is a lattice hash-and-sign construction designed for masked implementations.

Papers

RSA-FDH

RSA-FDH signs a hash value mapped into the RSA domain.

Papers

Signatures with an obfuscated verifier

This construction signs by evaluating a secret pseudorandom function on the message. A public obfuscated verifier checks the result through a one-way function instead of exposing the secret function evaluation directly.

Why it is useful

It turns a symmetric-looking tag into publicly checkable evidence while supporting a proof that punctures the function at the target message.

How it works

  1. Keep a puncturable function key as the signing key.
  2. Publish the obfuscated verification program.
  3. Sign a message with its secret function value.
  4. Verify by comparing one-way images of the supplied signature and expected function value.

What to watch for

The proof in this paper fixes the forgery message before setup. That selective security must not be silently presented as ordinary adaptive-message security; changing the assumption or parameters requires further analysis.

Papers

Wave signatures

Wave is a code-based hash-and-sign construction using generalized code structures.

Papers

Hash-based signature composition

Hash-based signatures authenticate messages using secret hash inputs, limited-use signatures and trees. The main design questions are how often each small key may be used, how its public key is authenticated and whether signing needs reliable changing state.

Address-based signing-key derivation

A large signature tree can be defined by a secret seed and a pseudorandom function. Each internal signing key is regenerated from a structured address rather than stored independently.

Why it is useful

The signer can keep a compact secret key even when the conceptual tree contains far more keys than could be stored or generated at once.

How it works

  1. Assign each key an address identifying its layer, tree and position.
  2. Use the secret seed as the key to a pseudorandom function on that address.
  3. Expand the resulting seed into the required one-time or few-time secret material.
  4. Regenerate only the portions needed for the operation.

What to watch for

Distinct key roles and positions need distinct encodings. A collision in the address space can reuse secret material in places the construction expects to be separate.

Related ideas

Papers

HuFu signatures

HuFu is a lattice signature scheme using a hash-and-sign construction.

Papers

L-tree public-key compression

An L-tree hashes the elements of a WOTS+ public key into one value. It is a small, possibly unbalanced binary tree used before placing that public key into the larger authentication tree.

Why it is useful

WOTS+ has several public chain endpoints. Compressing them gives the surrounding tree a fixed-size leaf.

How it works

  1. Use the public chain endpoints as leaves.
  2. Hash neighboring values using the prescribed masks and encoding.
  3. If a value has no sibling, carry it to the next level as specified.
  4. Continue until one root remains.

What to watch for

This construction is not the same as simply concatenating the endpoints and applying an unspecified hash. The handling of an odd number of nodes is part of the algorithm.

Related ideas

  • WOTS+: Its chain endpoints are the L-tree leaves.

Papers

Signature hypertrees

A signature hypertree arranges smaller hash trees in layers. A one-time signature in an upper tree authenticates a lower tree's root, creating a path of certificates to the single public root.

Why it is useful

Using smaller trees avoids constructing one enormous tree for every operation. The number and height of the layers trade signature size against signing work.

How it works

  1. Build or derive the selected bottom-level tree.
  2. Sign its root with the designated one-time key in the next layer.
  3. Authenticate that key within its own tree.
  4. Continue until reaching the top public root.

What to watch for

Each upper one-time key must remain bound to its designated child root. A stateless outer scheme does not permit its inner one-time keys to sign arbitrary different roots.

Related ideas

  • SPHINCS: Uses a hypertree above its few-time message signatures.

Papers

One-time and few-time signing

Hash preimages, chains and subset-reveal components with bounded signing use. Few-time security does not mean unrestricted key reuse.

FORS

FORS is a few-time hash-based signature construction used within SPHINCS+.

Papers

HORS few-time signatures

HORS signs by revealing a small selection from a large collection of secret values. The message digest determines which values are revealed, and their hashes appear in the public key.

Why it is useful

Only a small number of secrets need to be disclosed per signature. The construction tolerates limited reuse with a security cost that grows as more values become public.

How it works

  1. Generate many secret values and publish their hashes.
  2. Map the message digest to a collection of indices.
  3. Reveal the secrets at those indices.
  4. Check each revealed value against its public hash.

What to watch for

Enough signatures reveal enough secrets to make forgery easier. Few-time does not mean unlimited use, and the hash-to-indices function has a specific subset-resilience requirement.

Related ideas

  • Subset resilience: Expresses the difficulty of finding a new message requiring only already revealed secrets.

Papers

HORST few-time signatures

HORST, meaning HORS with trees, replaces HORS' large public list of hashes with a hash-tree root. A signature reveals selected secrets together with evidence connecting their hashes to that root.

Why it is useful

SPHINCS needs to authenticate a few-time public key inside every full signature. A short root is much smaller than carrying the full HORS public key.

How it works

  1. Hash the secret values into leaves of a binary tree.
  2. Use the tree root as the public key.
  3. Select secret values from the message digest.
  4. Reveal those values and the required tree authentication data.
  5. Check their paths and reconstruct the root.

What to watch for

The security still decreases with reuse. HORST is also unrelated to the similarly named Horst block-cipher construction.

Related ideas

Papers

Lamport signatures

A Lamport one-time signature commits to pairs of secret values through their hashes. For each bit of the message representation, the signer reveals the secret value corresponding to zero or one.

Why it is useful

The basic idea builds a signature from the difficulty of recovering secret inputs from hash outputs, without using a discrete-logarithm or factoring problem.

How it works

  1. Create a pair of independent secret values for each bit position.
  2. Publish the hashes of both values in every pair.
  3. For each message bit, reveal the corresponding secret value.
  4. Verify by hashing each revealed value and comparing it with the matching public value.

Example

For one bit, the public key contains hashes of two secrets. A signature on bit one reveals only the second secret.

What to watch for

Signing different messages with the same one-time key reveals more secret values and can enable forgery. The message encoding and any hash used before signing need their own security requirements.

Papers

Subset resilience

For a signature that reveals secrets at message-selected indices, subset resilience concerns finding a new message whose required indices are all covered by previous revelations. Such a message could be signed by recombining known secrets.

Why it is useful

The relevant attack does not need to find an ordinary hash collision or recover an unrevealed preimage. It can exploit the accumulated coverage of earlier signatures.

How it works

  1. Collect the index sets revealed by previous signatures under the same few-time key.
  2. Take their union.
  3. Ask how hard it is to find a new message mapping entirely into that union.

What to watch for

The bound depends on the number of signatures under that key, the number of indices per message and the size of the index universe. Ordinary collision resistance is not a substitute for this analysis.

Related ideas

Papers

Winternitz one-time signatures

Winternitz one-time signatures encode a message and checksum using hash-chain positions.

Papers

WOTS+

WOTS+ encodes a message and a checksum as positions along hash chains. A signature reveals an intermediate point on each chain; verification continues those chains to reconstruct the public key.

Why it is useful

Several message bits can be represented by a chain position. This trades extra hashing for a smaller one-time signature.

How it works

  1. Express the message in the chosen digit base and append its checksum digits.
  2. Derive a secret starting value for each chain.
  3. Advance each chain to the position selected by its digit; those values form the signature.
  4. Continue each revealed chain to its endpoint during verification.

What to watch for

WOTS+ remains a one-time construction. The public masks and exact chain function in this paper belong to its described variant and must not be replaced by an arbitrary repeated hash.

Related ideas

Papers

Winternitz checksum

The Winternitz checksum adds digits that depend on how far the message digits are below their maximum values. Increasing the message digits decreases the checksum value.

Why it is useful

Anyone can move forward along an exposed hash chain. The checksum makes it insufficient to change a message merely by advancing all the revealed chain positions.

How it works

  1. Write the message as base-w digits.
  2. Sum w-1 minus each message digit.
  3. Encode that sum as checksum digits with the prescribed length.
  4. Sign the message digits and checksum digits together.

Example

With base four and message digits 1 and 2, the checksum is (3-1)+(3-2)=3. Raising the first digit to 2 changes the checksum to 2.

What to watch for

Digit ordering, length and checksum encoding are part of the signature algorithm. Omitting the checksum changes the construction and its security.

Papers

Stateful hash-based signatures

Tree-authenticated limited-use keys with persistent allocation state, including traversal, delegation and backup hazards. Stateful signing is not automatically forward-secure.

LMS

LMS is a stateful hash-based signature scheme using a Merkle tree of one-time keys.

Papers

State management for one-time signing keys

A stateful hash-based signer records which one-time keys have already been used. Restoring an old backup or using unsynchronized copies can cause the same key to sign different messages.

Why it is useful

The security of the signature construction can depend on a storage and coordination rule outside the hash function itself.

How it works

  1. Choose the next unused signing key.
  2. Ensure that its use cannot be repeated after a crash or rollback.
  3. Prevent independent device copies from selecting the same key.
  4. Retire the key after its permitted use.

What to watch for

A good random-number generator does not repair lost usage state. Stateless schemes need a different construction and security analysis rather than simply removing the counter.

Related ideas

  • SPHINCS: Avoids a changing next-key counter by using a different composition.

Papers

XMSS

XMSS is a stateful hash-based signature scheme combining one-time signatures with a Merkle tree.

Papers

Stateless hash-based signatures

Many-use hash signatures avoiding a persistent leaf counter through randomized or pseudorandom component selection and hypertrees. Internal few-time components retain collision-dependent bounds.

SLH-DSA

SLH-DSA is the standardized stateless hash-based signature scheme derived from SPHINCS+.

Papers

SPHINCS

SPHINCS is a hash-based signature construction that avoids keeping a changing next-signature counter. It combines few-time signatures at the bottom with layers of hash trees and one-time signatures that authenticate them.

Why it is useful

Stateful signing keys can fail when backups, copied devices or crashes cause a one-time key to sign different messages. SPHINCS accounts for limited bottom-level reuse without relying on that counter.

How it works

  1. Derive a message-dependent pseudorandom index and message-hashing randomness.
  2. Sign the resulting digest with the selected HORST few-time key.
  3. Authenticate that key through WOTS+ signatures and hash-tree paths up the hypertree.
  4. Verify the chain until its top root matches the public key.

What to watch for

This source describes the original SPHINCS, including SPHINCS-256. SPHINCS+ is a distinct later family. Stateless signing still has a total-signature security bound and requires protection of the secret seeds.

Related ideas

Papers

SPHINCS+

SPHINCS+ is a stateless hash-based signature family using FORS and a hypertree.

Papers

Proof-based signing transformations

A proof-based signature is built from an interactive identification protocol. The signer plays the prover, sends a commitment, and the verifier's challenge is replaced by a public hash of the commitment and the message, so no interaction is needed. Security proofs for this family model the hash as a random function, and they typically must replay the forger with a different challenge, which costs security proportional to the number of hash queries.

AIMer

AIMer is a signature scheme combining MPC-in-the-head proofs with an AIM-family one-way function.

Papers

Biscuit signatures

Biscuit is an MPC-in-the-head signature design using structured multivariate polynomials.

Papers

Choosing the number of parties and opened instances

The proof protocol has three dials: how many simulated MPC instances to prepare (M), how many parties each instance has (N), and how many instances the verifier inspects (tau). Their soundness is fixed by a formula, so many different triples give the same security level.

Why it is useful

Every extra party costs real work, namely one more seed to derive, one more random tape to expand and one more commitment to hash, yet it buys very little extra soundness. So spreading the security over fewer parties and more opened instances is usually the better deal.

How it works

  1. Fix the target security level and list the triples (N, M, tau) that reach it.
  2. Benchmark them, since the balance cannot be predicted from the formula alone.
  3. Prefer fewer parties: the paper finds 16 parties better than the 64 used by the existing specification.
  4. Keep M large and tau small rather than shrinking M and raising tau, which grows signatures quickly.

Example

At level L1, moving from 64 parties with 343 instances and 27 opened to 16 parties with 252 instances and 36 opened made signing 3.95 times faster for a signature 1.12 times larger.

What to watch for

The measurements come from one workstation with vector instructions, and the best triple depends on the platform and on which other optimizations are applied; these are benchmark results, not a formula you can apply without measuring.

Useful background: From MPC-in-the-head to a Picnic signature.

Related ideas

  • Picnic: the scheme whose parameters are being tuned

Papers

CROSS signatures

CROSS is a signature scheme using restricted syndrome decoding and identification proofs.

Papers

FAEST

FAEST is a signature scheme proving knowledge of an AES key with VOLE-in-the-head techniques.

Papers

Fiat-Shamir with aborts

Fiat-Shamir with aborts combines challenge hashing with rejection of selected prover executions.

Papers

Fiat-Shamir-like signature schemes

A family of signatures built from identification protocols. The signer sends a commitment, and the verifier's random challenge is replaced by a public hash function applied to the commitment and the message, which removes the interaction and binds the message.

Why it is useful

It turns any commit, challenge and respond identification scheme into a signature scheme, which is how many practical factoring-based schemes were obtained.

How it works

  1. Start from an identification scheme where answering two different challenges for one commitment requires the secret key.
  2. Replace the verifier's challenge with the hash of the commitment and the message, for a public hash function.
  3. Output the commitment together with the response; anyone verifies by recomputing the hash and checking the response.
  4. Prove security in the random oracle model, where the hash is an ideal random function; the known proofs must then fork the forger, which is where their looseness enters.

Example

In the scheme the paper analyzes, computing square roots of one value for two different exponents lets you factor the modulus by a greatest common divisor computation.

What to watch for

For this whole family the known reductions lose a factor equal to the number of hash queries, which pushes key sizes up. The security argument also relies on the random oracle idealization of the hash function.

Useful background: Random oracle model, Fiat-Shamir transform.

Related ideas

Papers

From MPC-in-the-head to a Picnic signature

MPC-in-the-head is a way for one person to prove they know a secret: imagine the whole multi-party computation yourself, commit to what every imaginary party saw, and then let a challenger inspect all but one of them. Picnic packages that idea as a signature by deriving the inspection choice from a hash.

Why it is useful

In a real multi-party computation each party sees only a share of the secret, so no single view reveals it. If a prover simulates all parties and only ever opens all-but-one view, a verifier can check that the computation was honest while the secret stays hidden. That check is exactly a proof of knowledge, and hashing the commitment to produce the challenge removes the need for a live verifier.

How it works

  1. Simulate N parties running the circuit, giving each one a random tape and recording what they broadcast.
  2. Hash each party's state into a commitment, and hash the set of commitments into one value.
  3. Derive the challenge by hashing that value together with the message being signed, which is the Fiat-Shamir transform applied to the three-move proof.
  4. Open everything except one party per inspected instance; a verifier recomputes the opened parts and checks that the same challenge comes out of the hash.

What to watch for

The security proof treats the hash as a random oracle, so the challenge must be unpredictable before the commitment exists; the paper only uses the high-level idea of the Fiat-Shamir transform and points to the literature for the details.

Useful background: Picnic.

Related ideas

Papers

Full S-box layer LowMC instances

Instead of sending only a few bits through S-boxes each round, let every state bit go through one. That needs the state size to be a multiple of three, so Picnic uses 129-bit and 255-bit states instead of 128 and 256. The round count then drops sharply while the total AND count stays close to the old instances.

Why it is useful

Fewer rounds means fewer dense matrix multiplications to simulate, so signing and verification get much faster, and because the AND total barely changes the signature size barely changes either. The original design had missed this option because 128 and 256 are not divisible by three.

How it works

  1. Pick state and key size 129 at security level L1, 192 at L3, and 255 at L5, so that a full S-box layer fits.
  2. Let the LowMC round analysis, together with the published cryptanalysis, set the round count; at L1 four rounds are the minimum and five add a security margin.
  3. Compare the AND totals with the old instances: they stay within about twenty percent, so the signature size moves only slightly.

What to watch for

This changes the cipher instance, so it relies on the cited cryptanalysis of these specific parameters and on the Picnic setting where an attacker sees a single plaintext-ciphertext pair. The earlier optimisation for partial S-box layers no longer applies, which simplifies the implementation but removes that speedup.

Useful background: LowMC, the block cipher inside Picnic, Why the AND-gate count sets the signature size.

Papers

LowMC, the block cipher inside Picnic

LowMC is a block cipher built to be re-tuned: you choose the block and key size n, the number of S-boxes s per round, and the number of rounds r. Its design goal is a low number of AND operations, which is what an MPC-in-the-head proof finds expensive.

Why it is useful

In this setting AND gates are the costly part, while XOR gates and matrix multiplications over bits are almost free. LowMC leans on that split by using a small non-linear part and a large linear part, which is the opposite of what a hardware-oriented cipher like AES does.

How it works

  1. Each round applies a 3-bit S-box to the first 3s bits of the state, leaving the remaining bits unchanged when the S-box layer is partial.
  2. The state is then multiplied by a random full-rank matrix, a round constant is added, and a round key computed as another matrix times the master key is added.
  3. Because every S-box takes 3 bits to 3 bits, the number of S-boxes is limited by 3s at most n; the round count needed for security follows from all these choices plus the number of plaintext-ciphertext pairs an attacker may see.

What to watch for

The linear layer is a dense random matrix, which is cheap in a plain circuit but expensive when simulated once per party; that cost is what later optimizations attack. The secure number of rounds is not a property of the cipher alone but of the chosen parameters and the attacker model.

Useful background: The Picnic public key is a block-cipher key.

Related ideas

  • LowMC: the cipher described here

Papers

Moving the linear layer into preprocessing

Three related changes to the MPC protocol. First, run the expensive linear layer once on the combined masks instead of once per party. Second, draw each party's random masks at the input of the S-box layer rather than at its output, so the online phase never multiplies matrices at all. Third, define the final output mask to be zero so the closing broadcast disappears.

Why it is useful

LowMC's linear layer is a dense random matrix, and doing it once per party dominates the runtime. The fix is linearity: the correction values the protocol needs depend only on the XOR of all parties' masks, so you can add the shares first and then multiply once, instead of multiplying N times and then adding.

How it works

  1. In preprocessing, XOR the mask shares together and run one matrix multiplication, which is an N-fold reduction of that cost.
  2. Sample the masks for the input of each S-box layer directly from the random tapes; because the linear layer is invertible, masks placed there are just as uniformly random as masks placed at the output.
  3. For the last round, fold the key mask into an equivalent last round key and set the output share to zero, which removes the final broadcast and shortens the signature.

What to watch for

The argument that moving the masks is safe needs the linear layer to be invertible, and with a partial S-box layer the relevant sub-matrix is not guaranteed full rank, which is a further reason to prefer full S-box instances. These changes alter the specification, so they are protocol changes rather than pure implementation work.

Useful background: LowMC, the block cipher inside Picnic, From MPC-in-the-head to a Picnic signature.

Papers

Picnic

Picnic is a digital signature scheme whose only cryptographic ingredients are symmetric-key operations, that is block ciphers and hash functions. A signature is a zero-knowledge proof that the signer knows a block-cipher key, produced with the MPC-in-the-head technique.

Why it is useful

Signature algorithms in common use today, such as RSA and elliptic-curve schemes, rest on number-theory problems that a large quantum computer is expected to solve. Picnic was designed so that no such assumption is needed: if block ciphers and hash functions stay secure, the signature stays secure. The price is speed, since the symmetric-only candidates are the slowest family in the NIST comparison.

How it works

  1. Build the public key from one encryption of a block cipher, so the secret is a cipher key.
  2. Turn knowledge of that key into a proof with MPC-in-the-head, where the simulated MPC is information-theoretically secure.
  3. Hash with standard symmetric functions throughout; no lattices, codes, or discrete logarithms appear anywhere in the security argument.

Example

Where RSA hides a trapdoor in factoring, Picnic hides its trapdoor inside the difficulty of recovering a LowMC key from one plaintext-ciphertext pair.

What to watch for

Conservative assumptions are not free: the paper states that this family of designs performs considerably worse than the lattice and multivariate candidates, and Picnic signatures are tens of kilobytes rather than tens of bytes.

Related ideas

  • LowMC: the block cipher used to build the key statement
  • SPHINCS+: the other symmetric-only NIST candidate
  • ZKB++: the proof protocol of the first Picnic version

Papers

Rainier

Rainier is a signature scheme combining MPC-in-the-head proofs with the Rain one-way function.

Papers

Schnorr signatures

A Schnorr signature proves control of a discrete-logarithm secret while binding that proof to a message. It combines a fresh nonce commitment with a hash-derived challenge and a linear response.

Why it is useful

The linear response makes the scheme suitable for efficient signature verification and carefully designed threshold protocols.

How it works

  1. Choose a fresh secret nonce and publish its group commitment.
  2. Hash the commitment, public key and message to obtain the challenge.
  3. Add the nonce to the challenge times the secret key.
  4. The verifier recomputes the challenge and checks the resulting group equation.

What to watch for

Reusing a nonce with distinct challenges exposes the signing secret. Concrete variants need precise encodings, hash-domain rules and group validation; this algebra is not a complete wire specification.

Papers

SDitH

SDitH is a signature scheme combining syndrome decoding with MPC-in-the-head proofs.

Papers

Swap method for Fiat-Shamir-like signatures

A modification of Fiat-Shamir-like signing. The signer picks the random challenge first and then computes the commitment as the hash of the challenge and the message, instead of the usual order where the commitment is chosen first and hashed together with the message to produce the challenge.

Why it is useful

With the commitment derived from the challenge, a single forged signature is enough to break the underlying problem. The proof hides a second, different challenge inside each hash answer it gives, so one forgery already yields two challenges for one commitment, and no rewinding is needed.

How it works

  1. Choose a random challenge string and precompute the response to it; this can happen before the message is known.
  2. Hash the challenge together with the message, and adjust the result into the algebraic set the scheme needs, for example the quadratic residues modulo the public modulus.
  3. Compute the response matching this hashed commitment using the secret key, and output the response with the challenge.
  4. In the proof, answer each hash query with a value built to contain a second challenge different from the one the forger used, so any forgery factors the modulus at once.

What to watch for

The method only works when the signer can answer a challenge for a commitment it did not generate itself. It fails for discrete-logarithm identification schemes such as Schnorr signatures, where the response needs the discrete logarithm of the commitment.

Useful background: Fiat-Shamir-like signature schemes, Forking lemma.

Related ideas

Papers

The Picnic public key is a block-cipher key

A Picnic key pair is a small block-cipher puzzle. The signer picks a secret key k and a random plaintext block p, encrypts p under k, and publishes the pair (p, ciphertext). Signing is proving that you know a key which maps the published plaintext to the published ciphertext.

Why it is useful

This turns "I hold the secret key" into a statement about a circuit, namely the block cipher, so the whole signature stands or falls with the difficulty of recovering that cipher key. It also makes key generation a single encryption, which is why Picnic keys are tiny and key generation is among the fastest of all the NIST candidates.

How it works

  1. Pick a random block-cipher key and a random plaintext block; the key is the secret key.
  2. Encrypt the plaintext once; the plaintext-ciphertext pair is the public key.
  3. Define the circuit that outputs 1 exactly when the input key encrypts the plaintext to the published ciphertext, and prove knowledge of an input that makes it output 1.

What to watch for

Security is therefore the security of key recovery for that specific cipher instance, and the paper's analysis of LowMC uses the fact that a Picnic attacker ever sees only one plaintext-ciphertext pair per key.

Useful background: Picnic.

Related ideas

  • LowMC: the cipher whose key is being proven

Papers

Why the AND-gate count sets the signature size

Every AND gate in the circuit forces the preprocessing to create correlated randomness that the simulated parties cannot produce on their own, and the correction bits for one party have to be shipped inside the signature. Fewer AND gates therefore means a shorter signature.

Why it is useful

XOR gates are free in this protocol because each party can combine its shares locally, but an AND gate needs a pre-agreed relation between the parties' random masks. The signer stores those corrections on an auxiliary tape, and roughly half of the signature data grows with the number of AND gates.

How it works

  1. Count the AND gates of the cipher instance: this is the primary metric when choosing a cipher.
  2. Note that the original search picked one S-box per round to minimise AND gates, which gave the smallest signatures but many rounds.
  3. Expect large changes in the AND count, not small ones, to move the signature size much, since only about 40 to 50 percent of the signature depends on it.

What to watch for

Minimising AND gates alone is a trap: the single-S-box instances need many rounds, and each round adds a dense matrix multiplication that slows signing and verification down. Speed and size pull in opposite directions here.

Useful background: LowMC, the block cipher inside Picnic, From MPC-in-the-head to a Picnic signature.

Papers

Lattice-based signatures

Lattice signatures replace the discrete logarithm with the difficulty of finding unusually short vectors in a high-dimensional grid of points. The two main routes are hash-and-sign with a secret trapdoor basis, and Fiat-Shamir style prove-and-respond as used here. Learning this family means following how the response is kept independent of the secret, how the transcript stays simulatable, and how parameters tie signature size to the cost of lattice attacks.

Dilithium

Dilithium is a digital signature scheme whose security comes from the difficulty of finding short vectors in high-dimensional lattices. A signature lets a verifier check that the signer holds a short secret without learning it. Dilithium is one component of the CRYSTALS suite (Cryptographic Suite for Algebraic Lattices), which its authors submitted to the NIST competition for post-quantum cryptographic standards.

Why it is useful

Quantum computers would break the RSA and elliptic-curve signatures used today, so replacements have to be ready before large quantum computers appear. The paper states four design goals: be simple to implement securely, be conservative with parameters, minimize the combined public key plus signature size, and let security levels vary easily.

How it works

  1. Publish a seed that expands to a matrix over a polynomial ring, plus a public vector built from a short secret.
  2. Sign by answering a hashed challenge with a masked multiple of the secret, retrying when the answer would leak it.
  3. Verify with one matrix-times-vector computation and one hash comparison.
  4. At equal security, the public key is about 2.5 times smaller than the previous most efficient lattice signatures that avoided Gaussian sampling, with essentially the same signature size.

Example

For the recommended security level the submission reports a 1.5 KB public key and a 2.7 KB signature.

What to watch for

This article describes the 2017 competition-era design, not the finished standard. The scheme was revised repeatedly and later standardized as ML-DSA (FIPS 204) with different parameters, sizes and estimates, so every number quoted here is historical.

Useful background: Fiat-Shamir lattice signatures without trapdoors.

Related ideas

  • Fiat-Shamir with aborts: The proof-of-knowledge framework the signing loop implements.
  • Falcon: A contemporaneous lattice signature that keeps Gaussian sampling.

Papers

Fiat-Shamir lattice signatures without trapdoors

A second route to lattice signatures: instead of hashing a message to a lattice point and decoding it with a secret basis, prove knowledge of a short secret vector and turn the interaction into a signature.

Why it is useful

It removes the need for trapdoor bases and Gaussian sampling over arbitrary lattices, and it produced the smallest provably secure lattice signatures of its time.

How it works

  1. Publish a random matrix and a public key built from a short secret matrix.
  2. Pick a masking vector, hash a combination with the message to get a short challenge, and answer with the mask plus the secret times the challenge.
  3. No lattice decoding or short basis is involved; operations are matrix-vector products.

Example

Where hash-and-sign decodes, this scheme answers a challenge - closer to a Schnorr signature shape than to RSA.

What to watch for

Security is in the random oracle model, from worst-case lattice hardness; the construction is not a parameter recommendation.

Useful background: Hash-and-sign lattice signatures.

Related ideas

  • Digital signatures: the primitive

Papers

Fiat-Shamir with aborts in Dilithium

Signing is a non-interactive proof of knowledge of the short secret, built with the Fiat-Shamir with aborts technique: commit to a random mask, derive a challenge by hashing, respond with the mask plus the secret times the challenge, and abort (restart) whenever the response would depend on the secret.

Why it is useful

This is the same lineage as Lyubashevsky 2009, improved in 2012 by mixing LWE and SIS ingredients, then shrunk by GLP 2012 and Bai-Galbraith 2014. It needs no trapdoor or lattice decoding, only polynomial arithmetic, hashing and retries.

How it works

  1. Sample a masking vector y with coefficients below a bound gamma1, chosen large enough for zero knowledge yet small enough to prevent forgery.
  2. Compute Ay and keep only the high-order bits w1 of its coefficients.
  3. Hash the message together with w1 to obtain the challenge c, a sparse polynomial with exactly 60 coefficients equal to plus or minus 1 and the rest 0; c is short and still comes from a set of more than 2^256 possibilities.
  4. Form the candidate response z = y + c times s1.
  5. Restart if any coefficient of z reaches gamma1 minus beta, or if the low-order bits of Ay minus c times s2 come within beta of their boundary; parameters are tuned so the expected number of restarts is between 4 and 7.
  6. The verifier recomputes the high-order bits of Az minus ct. Because c times s2 is too small to push a low-order coefficient across its boundary and cause a carry, these match the values the signer hashed.

What to watch for

The version walked through in the paper is deliberately simplified and less efficient; the full scheme adds public-key compression. The no-carry claim is a bound enforced by the rejection test, not an unconditional identity.

Useful background: Fiat-Shamir lattice signatures without trapdoors, Rejection sampling to hide the secret.

Related ideas

Papers

Gaussian-free design against side channels

The most compact earlier lattice signatures drew their randomness from the discrete Gaussian distribution. Dilithium deliberately uses only uniform sampling, so that no part of the algorithm needs a Gaussian sampler at all.

Why it is useful

Sampling discrete Gaussians in constant time is hard, and published attacks on BLISS implementations showed that subtle sampler leaks give up the key. Since a widely deployed scheme cannot assume expert implementers everywhere, the paper removes the hazard rather than mitigates it.

How it works

  1. Draw the secret, the mask and the challenge uniformly from simple ranges; every other operation, such as polynomial multiplication and rounding, is straightforward to run in constant time.
  2. The NTRU-based competitors crucially require Gaussian sampling, and the paper states no constant-time implementation of them was known.
  3. A cited 2017 fix for integer Gaussian sampling still relied on lookup tables unprotected against side channels.
  4. The price is modest: Gaussian sampling would save roughly 10 to 15 percent of the signature size, which the authors judge not worth the implementation risk.

What to watch for

Avoiding Gaussians removes a documented leakage source, not side channels in general; the arithmetic itself still has to be implemented in constant time.

Useful background: Dilithium, Discrete Gaussian sampling.

Related ideas

Papers

Hash-and-sign lattice signatures

Sign by hashing the message to a point in space and outputting a nearby lattice point found with the secret basis.

Why it is useful

It gives lattice signatures the same simple shape as textbook RSA signing, with a security proof from worst-case lattice hardness.

How it works

  1. Hash the message to a point near the lattice, using a random oracle.
  2. Sample a lattice point close to that hash using the short basis.
  3. Verify by checking the point is short and hashes back consistently with the message.

What to watch for

Proven in the random oracle model; concrete parameters are a separate engineering question.

Useful background: Lattice trapdoors from short bases, Discrete Gaussian sampling from a basis.

Related ideas

  • Digital signatures: the primitive being built

Papers

Hash-and-sign lattice signatures from the new trapdoor

The trapdoor plugs straight into the Gentry-Peikert-Vaikuntanathan hash-and-sign signature: hash the message to a syndrome and sign by Gaussian-sampling a short preimage under the public matrix; verification re-multiplies and checks the length. The paper also improves a standard-model scheme of Boyen with a better length bound, faster online signing via chameleon hashing, and a tighter proof.

Why it is useful

Signing is exactly the preimage-sampling operation the new trapdoor accelerates, so the same improvement shortens signatures, shrinks keys, and tightens the security reduction at equal concrete security.

How it works

  1. Key generation: run the trapdoor generator, publish A, keep R.
  2. Sign: hash the message to a syndrome u (in the random-oracle version), then sample a short vector v with Av = u mod q from the right Gaussian.
  3. Verify: accept when Av = u mod q and the length of v is within the bound.
  4. Standard-model variant: extra public matrices let the message bits select the tag, and the same sampler signs under the resulting tagged matrix.

What to watch for

The random-oracle scheme depends on the random-oracle model, and the standard-model schemes still have public keys of order n-cubed bits (up to suppressed factors), which the authors themselves call mainly of theoretical interest. This is a historical 2011 construction, not a modern standard.

Useful background: Hash-and-sign lattice signatures, Micciancio-Peikert trapdoors.

Related ideas

Papers

How this compares with trapdoor signatures

Against the Micciancio-Peikert trapdoor scheme, the designs look similar but package the challenge differently.

Why it is useful

This scheme outputs a sparse challenge in the clear and pays for it in size; the trapdoor scheme perturbs its challenge and can tailor perturbations to the key.

How it works

  1. Here the challenge is sparse with low entropy but is transmitted as-is.
  2. There the challenge is perturbed and never sent in the clear.
  3. Which is smaller depends on the secret’s shape, and the LWE setting favors this scheme.

What to watch for

The comparison is asymptotic and constant-level; final choices need concrete parameter analysis.

Useful background: Fiat-Shamir lattice signatures without trapdoors, Hash-and-sign lattice signatures.

Papers

LWE-parameter variant

Changing parameters so key recovery matches the Learning With Errors problem makes keys and signatures smaller.

Why it is useful

It trades the SIS-based worst-case guarantee for an LWE-based one, allowing fewer secret rows and shorter outputs at a believed-similar cost.

How it works

  1. Set the number of secret rows small enough that recovering it from the public product is an LWE-style problem.
  2. Balance the assumed cost of key recovery against the cost of forging.
  3. Sizes shrink as rows shrink, with a stronger worst-case assumption as the price.

What to watch for

The balance of assumptions is an engineering judgement, not a proven equivalence.

Useful background: Learning with errors as lattice decoding, The Small Integer Solution problem.

Papers

Module structure and scalable security

All arithmetic happens in the polynomial ring Rq = Zq[X]/(X^256 + 1) with the single prime q = 2^23 - 2^13 + 1, and the public matrix A is a k by l grid of ring elements. Security is scaled by changing only the grid dimensions.

Why it is useful

Using a module (a grid of ring elements) rather than one big ring element or a plain integer matrix balances key size, speed and trust in the underlying problems, and it lets one optimized implementation serve every security level.

How it works

  1. Fix the ring and modulus once; at the recommended level A is 5 by 4, so multiplying A by a vector costs 20 polynomial products.
  2. Move between the four offered levels by changing (k, l) from (3, 2) up to (6, 5) and the secret bounds, while reusing the same code and the same ring.
  3. Security rests on Module-LWE and Module-SIS, which generalize LWE, Ring-LWE, SIS and Ring-SIS.
  4. No known attack exploits the ring structure, so the analysis treats the module problems as plain LWE and SIS over integers, which is the more conservative view.
  5. Moving from Ring-LWE to Module-LWE also distances the scheme from algebraic lattices that admitted specialized attacks: the fraction of suspiciously short vectors drops from 1/2 in NTRU and at most 1/3 in Ring-LWE to at most 1/(l+2).

What to watch for

The module variants were younger and less studied than plain LWE when the paper appeared, and the claim that ring structure cannot be exploited is a statement about known attacks, not a theorem.

Useful background: Learning with errors as lattice decoding, The Small Integer Solution problem.

Related ideas

  • Kyber: The companion CRYSTALS key-encapsulation submission built on the same module setting.
  • NTRU lattices: The older structured-lattice alternative with different attack surface.

Papers

Normal masks for shorter signatures

Using a Normal distribution for the mask instead of a uniform ball shrinks signatures from about n to the power 1.5 to linear length.

Why it is useful

The uniform-ball approach needs a radius grown by the secret’s maximum length; the Normal tail makes the ratio of distributions bounded by a constant instead.

How it works

  1. Set the mask distribution to a Normal law with a standard deviation tied to the secret’s size.
  2. Bound the density ratio only for candidates that are not too large.
  3. Acceptance stays constant on average; the expected signature length becomes linear in the dimension.

What to watch for

The bound is statistical, and the standard deviation must grow with the secret’s norm.

Useful background: Rejection sampling to hide the secret.

Papers

Rejection sampling to hide the secret

Output the signature only with a carefully chosen probability, so the kept outputs follow a target distribution that does not reveal the secret.

Why it is useful

The raw answer equals the secret times the challenge plus a mask; left alone, its distribution tilts with the secret. Rejection sampling resets it.

How it works

  1. Draw the mask from a chosen distribution.
  2. Compute the candidate signature.
  3. Accept with probability given by the ratio of the target to the candidate distribution, scaled by a constant.
  4. The accepted outputs follow the target distribution exactly; the constant bounds the expected number of tries.

What to watch for

Retries cost time; the acceptance constant is a tunable trade-off between speed and signature size.

Useful background: Signature independence from the secret key.

Papers

Ring setting: smaller keys

Working with polynomial rings instead of plain matrices compresses keys by roughly the dimension factor.

Why it is useful

The ring structure mainly saves space and speeds products; the security idea stays the same.

How it works

  1. Represent the public matrix as ring elements.
  2. Multiply and hash inside the ring.
  3. Key sizes shrink by about the ring degree.

What to watch for

The ring assumption is stronger than the general one; the paper notes the structure adds efficiency rather than functionality.

Useful background: Fiat-Shamir lattice signatures without trapdoors.

Papers

Rounding hints compress the public key

Dilithium stores only the high-order part t1 of the public vector t, discarding d low-order bits per coefficient, and repairs verification with one-bit hints sent in the signature.

Why it is useful

This is the main novelty over earlier schemes in the same lineage: the public key shrinks by a factor of about 2.5 while the signature grows by roughly 150 bytes, which is favorable wherever keys and signatures travel together.

How it works

  1. Split each coefficient using a rounding routine that writes r as a high part times 2^d plus a small remainder.
  2. The verifier can only compute Az minus c times t1 times 2^d, which equals Az minus ct plus c times t0, and t0 is secret.
  3. Because c has only 60 nonzero coefficients, the high-order bits barely move when the small term c times t0 is added; the positions where a carry does occur are sent as hint bits.
  4. A hint routine marks whether adding a small value pushed a coefficient into the neighboring high-order bucket, and the verifier applies the hint to recover exactly the high-order bits the signer used.
  5. With q near 2^23 and d = 14, each public key coefficient costs 9 bits instead of 23.
  6. Signing is made deterministic by deriving the mask y from a secret seed together with the message, and a counter separates retry attempts.

Example

Think of writing each coefficient in two parts: keep the top digits in the public key, and ship a handful of carry flags inside each signature so the verifier lands on the same rounding.

What to watch for

The number of hint bits is capped by a parameter omega, and the paper argues only heuristically that few carries occur; the exactness claim for the recovered high-order bits is what the lemma guarantees.

Useful background: Fiat-Shamir with aborts in Dilithium.

Related ideas

Papers

Security assumptions and concrete estimates

Unforgeability is reduced to three problems: Module-LWE against key recovery, a new hash-convoluted problem SelfTargetMSIS against forgeries on new messages, and Module-SIS for strong unforgeability (no second signature for an already signed message). Attack costs are then estimated with the core-SVP methodology.

Why it is useful

The classical proof rewinds the forger, and rewinding does not survive quantum adversaries, so the paper leans on an intermediate problem that stays tightly equivalent even for quantum attackers, plus deliberately pessimistic cost accounting.

How it works

  1. Model the hash as a random oracle the adversary may query in superposition (the quantum random oracle model); the forking-lemma reduction does not transfer to that setting.
  2. SelfTargetMSIS asks for a short vector whose hashed image equals a coordinate of that vector; it combines MSIS with the hash function and is the tightly equivalent intermediate problem.
  3. Each assumption guards one goal: MLWE for key recovery, SelfTargetMSIS for new-message forgery, MSIS for strong unforgeability.
  4. Cost attacks with BKZ block reduction, where each block call solves a shortest-vector problem in dimension b; solvers cost about 2^(0.292*b) classically and 2^(0.265*b) quantumly, with 2^(0.2075*b) treated as a plausible future floor.
  5. Be pessimistic on the attacker side: assume asymptotically best algorithms run with no overhead and that huge amounts of possibly quantum memory are free.
  6. The four offered levels correspond to SIS block sizes from 235 to 605, public keys from 896 to 1760 bytes, and roughly 4.3 to 6.6 expected signing repetitions.

What to watch for

The estimates are the authors 2017 numbers under a methodology that has since been refined, and the reduction to MSIS is explicitly non-tight; the table is a snapshot, not a recommendation for today.

Useful background: Module structure and scalable security, Lattice basis reduction.

Related ideas

Papers

Signature independence from the secret key

The signature transcript must be statistically independent of the secret key for the security proof to work.

Why it is useful

With independence, the proof can program the random oracle to answer the forger’s signing requests without knowing the key, then use a fresh forgery to solve the hard problem.

How it works

  1. Sign so that the output pair does not depend on the secret in distribution.
  2. The reduction fabricates answers to signing queries via the random oracle.
  3. A forgery on a new message then breaks the underlying lattice problem.

What to watch for

Without independence, signatures accumulate information about the key - exactly how earlier schemes fell.

Useful background: Fiat-Shamir lattice signatures without trapdoors.

Papers

The road to secure lattice signatures

Early lattice signatures failed; provably secure ones arrived in 2008 and shrank rapidly afterwards.

Why it is useful

It explains why the field converged on two designs - hash-and-sign with trapdoors and Fiat-Shamir with rejection sampling.

How it works

  1. The GGH proposal and the NTRU signature were broken by transcript analysis.
  2. Provable schemes from 2008 were megabyte-scale.
  3. Key-generation improvements and the rejection-sampling design each cut sizes by orders of magnitude.

What to watch for

History is the motivation: every step removed a leak or a size obstacle.

Useful background: Why GGH-style signatures leaked their keys.

Papers

The Small Integer Solution problem

SIS asks for a short nonzero vector that a given random matrix sends to zero modulo a modulus.

Why it is useful

Forging in these schemes means producing such a short vector, so signature length and SIS hardness are directly linked.

How it works

  1. Take a random matrix modulo a modulus.
  2. Find a small nonzero vector mapped to zero.
  3. Shorter allowed vectors mean a harder problem and force shorter, harder-to-produce signatures.

What to watch for

The worst-case connection: finding such vectors is as hard as approximating shortest-vector problems in all lattices of the dimension.

Useful background: Lattice.

Papers

Why GGH-style signatures leaked their keys

Early lattice signatures broke because every signature disclosed information about the shape of the secret basis.

Why it is useful

A deterministic decoder always lands in patterns shaped by the basis, so a transcript of signatures gradually reveals the basis itself; a full key recovery from transcripts was shown for the original scheme.

How it works

  1. Original proposal: decode deterministically with the secret basis.
  2. Transcripts reveal the decoding patterns.
  3. Statistical attacks reconstruct the secret basis or an equivalent one.
  4. The fix: sample with the correct Gaussian spread so outputs forget the basis shape.

What to watch for

The historical lesson generalizes: randomized with the right distribution beats deterministic decoding for trapdoor use.

Useful background: Hash-and-sign lattice signatures.

Related ideas

Papers

Multivariate-quadratic signatures

Signatures based on the difficulty of solving systems of quadratic equations over many variables, including the UOV and Rainbow families.

Rainbow: stacking UOV layers

Rainbow is UOV applied several times. Its trapdoor is a chain of nested subspaces of the input space, F = O0 containing O1 containing ... containing Ol, together with a chain of nested subspaces of the output space, Fm = W0 containing W1 containing ... containing Wl = {0}, sized so that dim O1 = m and dim Oi = dim W(i−1) for i > 1. Two properties define the scheme: P maps each Oi into Wi, and the polar form P′(x, y) lands in W(i−1) whenever y is in Oi, whatever x is. Rainbow with one layer is exactly UOV; the efficient and commonly used case is two layers, described by four parameters q, n, m and o2, where o2 is the dimension of the innermost oil space O2 and of W.

Why it is useful

The design goal of layering was to make the Kipnis-Shamir attack less powerful so that smaller, faster parameters could be used. The price is extra hidden structure, and that structure is what the MinRank, Billet-Gilbert and Rainbow Band Separation attacks, and the two new attacks of this paper, target.

How it works

  1. Pick v at random and solve for o1 in the quotient space O1/O2, where two vectors of O1 count as the same when they differ by an element of O2, so that P(v + o1) equals t modulo W; this is a linear system, solved by Gaussian elimination.
  2. Then solve for o2 in O2 so that P(v + o1 + o2) = t exactly; all the leftover terms lie in W, giving a square linear system of dim W equations in dim W unknowns.
  3. Each step succeeds with probability about 1 − 1/q; on failure, restart with a new v.

Example

The round-two Rainbow parameter set Ia uses q = 16, n = 96, m = 64 and o2 = 32, with a public key of about 149 kilobytes and signatures of 64 bytes: the secret subspace O2 is a 32-dimensional subspace of a 96-dimensional space.

What to watch for

The layering only pays off if the extra structure does not create a cheaper attack path, and this paper shows that it does. All parameter sets submitted to the NIST project were two-layer instances.

Useful background: Signing with UOV: the polar form turns inversion into linear algebra.

Papers

Signing with UOV: the polar form turns inversion into linear algebra

The polar form of a quadratic polynomial is defined as p′(x, y) = p(x + y) − p(x) − p(y) + p(0), and for a whole map P it is applied component by component. Theorem 1 of the paper shows this polar form is symmetric and bilinear: linear in each argument separately. That is the trick behind signing. To hit a target t, pick a random vector v and look for the answer in the form v + o with o in the secret subspace O. Because P vanishes on O, the equation P(v + o) = t collapses to P(v) + P′(v, o) = t, which is linear in o and can be solved by Gaussian elimination. The signature itself uses the Full Domain Hash approach, where the hash of the message is used directly as the value to invert: s satisfies P(s) = H(M || salt), with salt a fresh random string chosen for every signature.

Why it is useful

This is the reason the owner can invert a map that everyone else has to treat as a hard MQ instance: one evaluation of the polar form replaces the exponential search. The same polar form is also the attacker tool, because each component of it defines a matrix that leaks information about O.

How it works

  1. Compute the polar form, which for a quadratic form written with matrix Q is x^T (Q + Q^T) y.
  2. Pick a random v and solve the linear system P′(v, o) = t − P(v) for o in O.
  3. The linear map is non-singular with probability about 1 − 1/q; if it fails, pick a new v and try again.
  4. Output the signature s = v + o; the verifier just checks P(s) = H(M || salt).

Example

For the single polynomial p(x1, x2) = x1x2, over a field where 2 is nonzero, the polar form is u1v2 + u2v1: substituting u = v = (1, 1) gives 2, which equals p(2, 2) − 2p(1, 1) = 4 − 2. This identity is what makes the substitution step above collapse to a linear equation.

What to watch for

The linear step succeeds only with high probability per attempt, so signing needs retries, and the salt is what makes each signature attempt an independent fresh system. Nothing in this procedure hides the public map, so the scheme stands or falls with the difficulty of finding O.

Useful background: The UOV trapdoor: a map that vanishes on a secret subspace.

Papers

The UOV trapdoor: a map that vanishes on a secret subspace

The Unbalanced Oil and Vinegar (UOV) public key is a quadratic map P that sends every vector of a secret subspace O to zero, where O has dimension m. The subspace O is the entire secret key: a description of O is all the owner needs, and the trapdoor map is generated by picking O first and then picking P uniformly among the maps that vanish on it. Classically the same object is described as a public key P = F composed with a secret invertible linear map T, where F is a so-called central map chosen so that its structure is hidden by T; the paper deliberately drops the central map and states the property of P directly.

Why it is useful

The vanishing property is exactly what makes inversion easy for the owner and hard for everyone else, so every structural attack in the paper is an attempt to recover O (or the Rainbow analogue) from the public map. Removing the central map from the description also makes the attacks easier to state: they become statements about subspaces rather than about a hidden factorization.

How it works

  1. Pick the secret subspace O of dimension m uniformly at random inside the n-dimensional input space.
  2. Pick P uniformly among the quadratic maps with m components that vanish on O.
  3. Publish P as the public key and keep O as the secret key.
  4. The same distribution of public keys comes out of the traditional recipe (random central map composed with a secret linear map), so the change of viewpoint does not alter the scheme.

Example

Over a finite field with n = 4 variables and m = 2 equations, let O be the vectors of the form (0, 0, a, b). A quadratic polynomial that vanishes on O cannot contain the monomials x3x4, x3 squared or x4 squared, so every term needs at least one of the first two variables. Knowing which terms are missing is equivalent to knowing O.

What to watch for

The map P also has roughly q^(n-m) natural zeros that are not in O, so finding some zero of P is not the same as finding O. The original balanced choice n = 2m was broken in polynomial time by Kipnis and Shamir in 1998, which is why every later proposal takes more variables than equations, n > 2m.

Useful background: Why multivariate signatures are hard to break.

Papers

Why multivariate signatures are hard to break

A multivariate quadratic (MQ) map P is a list of m quadratic polynomials in n variables over a finite field, and evaluating it is easy. The hard direction is inverting it: given a target vector t, find an input s with P(s) = t. This is the Multivariate Quadratic (MQ) problem, and it is the assumed source of hardness for the whole family. A forger who ignores the secret structure of a scheme and simply tries to solve P(s) = H(M || salt) is running what the paper calls a direct attack.

Why it is useful

The MQ problem is NP-hard, which means it is at least as hard as the hardest search problems in the class NP, and it is believed to be exponentially hard on average, even for quantum adversaries. That belief is why multivariate schemes are treated as post-quantum candidates: no quantum algorithm is known to beat the classical equation solvers on random instances, and seven of the nineteen signature schemes submitted to the NIST post-quantum project were multivariate.

How it works

  1. Publish the quadratic map P as the public key; the secret key is extra structure that lets the owner invert P quickly.
  2. To forge, take the hash of the message and a fresh random salt as the target t and try to solve P(s) = t with no knowledge of the structure.
  3. Solvers such as XL or F4/F5 treat the quadratic equations as one large linear system in all monomials; their cost grows exponentially with the number of variables, which is what makes the direct attack expensive.

Example

With two variables over a small field and p(x1, x2) = x1x2 + x1, the target t = 1 is met by x1 = 1, x2 = 0, found by trying all values. Real public keys use a hundred or more variables, where trying all inputs is hopeless.

What to watch for

NP-hardness is a worst-case statement about the hardest instances, not about the random-looking maps these schemes publish, so security rests on an average-case belief rather than a theorem. That belief has to be rechecked whenever a better equation solver appears, and the paper itself is an example of such a recheck for the structured public keys of UOV and Rainbow.

Related ideas

Papers

Group, ring and anonymous signatures

Signatures in this family hide which key holder signed. A ring signature names a set of possible signers chosen by the signer at signing time, with no group manager, no enrollment and no coordination among users; a group signature instead has a manager who can later trace the signer. This paper strengthens the security definitions for such schemes and gives the first constructions proved secure without the random oracle heuristic.

Anonymity against adversarially-chosen keys

An anonymity condition for ring signatures in which the attacker, who already sees all honest public keys and may request signatures from any of them, must not identify the signer of a challenge signature, even when the challenge ring mixes honest keys with keys the attacker made up.

Why it is useful

Earlier definitions only protected rings made entirely of honestly generated keys. Since rings are assembled ad hoc from keys that no authority validates, an attacker can publish keys built out of honest users' keys and lure a signer into using them, so a definition that ignores this protects little.

How it works

  1. Start from the basic game: all honest public keys are handed to the attacker, who may query a signing oracle for any honest signer in any ring drawn from those keys.
  2. The attacker names a message, two honest users and a ring containing both, then receives a signature made by one of the two and must say which.
  3. The strengthened definition drops the requirement that every key in that ring come from the honest set, so attacker-made keys may be mixed in.
  4. The scheme keeps anonymity if the attacker's guess stays negligibly better than a coin flip.

What to watch for

Even this guarantee needs at least two honest users in the ring, and that limit is inherent: if an honest signer is the only honest member, the owner of every other key knows the signer must be the honest one, since none of them produced the signature.

Useful background: Ring signatures.

Related ideas

Papers

Anonymity against attribution attacks and full key exposure

Two increasingly strong anonymity goals. The first says that when everyone else in a ring colludes against one honest signer, they still cannot prove to an outsider that she signed, even after revealing their own secret keys and the coin flips that generated them. The second exposes the key-generation coins of every honest user as well.

Why it is useful

It models stolen keys and framing attempts: a ring of colleagues who want to blame one member in court should not be able to manufacture evidence. Full key exposure also matches the concern that randomness logs or backups survive even when keys are erased.

How it works

  1. Let all honest users generate keys from recorded randomness, and give the attacker the public keys and a signing oracle.
  2. For the attribution notion, hand the attacker the key-generation randomness of every honest user except the challenge signer.
  3. For full key exposure, hand over the randomness of all honest users, including the signer.
  4. The attacker must still not tell which of the two named honest users produced the challenge signature.
  5. All of these definitions also imply unlinkability: two signatures, even under different rings, cannot be tied to the same signer.

What to watch for

Preventing attribution outright when the signer is the only honest member seems to need a trusted party or a shared random string, which this line of work deliberately avoids, so the defined notion is a weakening. The paper proves its generic construction only against attribution attacks, and needs an extra tool for full key exposure.

Useful background: Ring signatures, Anonymity against adversarially-chosen keys.

Related ideas

Papers

Bilinear group pairs

Two prime-order groups, a first and a second, plus a third target group and a map called a pairing that takes one element from each source group into the target. A computable isomorphism also leads from the second group back to the first.

Why it is useful

The pairing lets a verifier test equations about secret exponents without learning them, and the first group can be chosen so that its elements are very short strings - about 171 bits in this paper - which is what keeps the resulting signatures small.

How it works

  1. Take two cyclic groups of the same prime order, with generators for each.
  2. Let the pairing satisfy bilinearity: raising either input to a power raises the pairing value to that power, so raising both multiplies the effect.
  3. Require non-degeneracy so the pairing value actually carries information.
  4. Allow the two source groups to differ, so that non-supersingular elliptic curve families can be used.

What to watch for

The isomorphism between the groups is needed only inside the security proofs; for the scheme itself it is enough that it exists and is efficiently computable. Sizes quoted are the paper's 2004 parameters, not current advice.

Useful background: Elliptic curve groups.

Related ideas

Papers

Decision Linear assumption and Linear encryption

Decision Linear asks: given three generators and three masked elements, decide whether the third mask is the sum of the first two. Linear encryption is an ElGamal-style scheme built on it, with a public key of three generators and a secret of two exponents.

Why it is useful

Inside a bilinear group the pairing decides the usual Diffie-Hellman test, so plain ElGamal no longer hides anything. Linear encryption is believed to stay secure even where that test is easy, which is exactly the situation this construction sits in.

How it works

  1. Publish generators u, v, h as the public key, keeping secret exponents x, y with u to the x equal to v to the y equal to h.
  2. To encrypt a group element m, pick random a and b and output the triple (u to the a, v to the b, m times h to the a plus b).
  3. To decrypt, divide the third component by the first raised to x and the second raised to y.
  4. Semantic security against chosen-plaintext attack follows from the Decision Linear assumption.

Example

With mask exponents a = 5 and b = 7 the third ciphertext component carries the factor h raised to 12; decryption with the two secret exponents removes exactly that factor and leaves the message.

What to watch for

Only chosen-plaintext security is claimed; the encryption is not by itself secure against attackers who can ask for decryptions. The paper adds a generic-group lower bound as evidence for the assumption, which is an argument about a restricted model, not a proof in the ordinary sense.

Useful background: ElGamal encryption, Bilinear group pairs.

Related ideas

Papers

From static groups to dynamic groups

In a static group signature scheme, one trusted setup chooses the group public key, the opening key and a signing key for every member, all at once, and the membership never changes. In a dynamic scheme, setup chooses only the group public key and the keys for the authorities; a user joins later by running a joining protocol with the issuer and ends up holding a signing key nobody else knows.

Why it is useful

Groups in use change: staff join, devices are enrolled. Static setup also demands too much trust, because the party running it knows every member signing key and could sign as any of them. Making enrollment dynamic removes both problems, but the definitions have to be rebuilt for it.

How it works

  1. Static setup: a single trusted execution fixes the number and identities of members and hands each one a signing key.
  2. Dynamic setup: the trusted execution outputs only the group public key and the authority keys, so no signing key exists yet.
  3. A user joins at any time by running the joining protocol with the issuer; when both sides accept, the user alone holds its signing key.
  4. Treating the dynamic case is not a routine edit of the static one: new elements and new security questions appear, which is why the paper devotes a full treatment to it.

Example

A company publishes one group public key at founding; each new employee runs the joining protocol on their first day and can sign for the company afterwards.

What to watch for

The model covers growth only. Members cannot be revoked, and the authors keep revocation out on purpose because different revocation designs need different model features.

Useful background: Group signatures.

Related ideas

Papers

Group signatures

A group signature is produced by one enrolled member of a group, but it is checked against a single group public key and does not reveal which member signed. A separate authority, holding a special tracing key, can undo the anonymity of a signature when misuse has to be investigated.

Why it is useful

A verifier only needs to know that an authorized member signed, not which one - the property wanted when many devices or people must speak for one organization while staying unlinkable.

How it works

  1. Enroll members by giving each one a private signing key tied to the group.
  2. A member signs a message with her own key.
  3. Anyone checks the signature with the one group public key.
  4. Only the authority holding the tracing key can recover who signed.
  5. Group membership can be changed by revoking keys without disturbing members who stay.

What to watch for

Anonymity here is conditional: it holds against verifiers and the public, not against the tracing authority. Which guarantee a system really gives depends on the precise security definition, not on the word "anonymous".

Useful background: Digital signatures.

Related ideas

Papers

How the Back-style linkable ring signature works

A chain of Schnorr-style equations that starts at the real signer and closes around the ring, so that every listed key could have produced the challenge that follows it.

Why it is useful

The paper restates Adam Back’s tightening of the LSAG construction because it halves what must be stored: one challenge value is enough, since the rest of the chain can be recomputed from it.

How it works

  1. At the secret index j, pick a random scalar α and set L = αG and R = αHp(Pj).
  2. Hash the message with L and R to obtain the next challenge.
  3. For every other ring member pick a random scalar, compute that member’s L and R from the previous challenge, and hash again to advance.
  4. When the chain returns to j, close it by solving for the real signer’s scalar so its equation holds.
  5. A verifier regenerates the whole chain from one stored challenge and checks that it closes on itself.

Example

What gets stored is the key image, one challenge and one scalar per ring member, written σ = (I, c1, s1, ..., sn).

What to watch for

Hp has to return a group element; on ed25519 the implementation hashes repeatedly until the digest lands in the group, and the discrete-logarithm relation between G and Hp(P) must stay unknown or the signer’s key leaks.

Useful background: Schnorr signatures, Ring signatures hide which key spent.

Related ideas

Papers

MLSAG: one ring signature over a vector of keys

A multilayered ring signature signs a whole vector of public keys at once, so each ring member is a column of m keys rather than one key.

Why it is useful

A Monero spend references several things at once, for example the spend key plus the commitment belonging to each output being spent. One layered signature covers all of them, and reusing any single row links the signatures together.

How it works

  1. Give each of the n possible signers a key-vector of length m.
  2. Compute one key image per row, using the signer’s secret key for that row.
  3. Hash the L and R values of all rows together into each challenge, so a valid signature requires every secret key of one column.
  4. Verification regenerates the chain and checks closure; cost grows as O(m(n+1)).

Example

With two rows, a public key and a commitment, in a ring of four candidates, the signature carries two key images, one challenge and eight scalars.

What to watch for

Signature size grows with ring size times the number of rows, and the paper itself flags that the commitment row’s key image is probably unnecessary and that further size savings are likely.

Useful background: The key image double-spend tag, How the Back-style linkable ring signature works.

Papers

Oblivious key generators for encryption

A pair of algorithms for an encryption scheme: one produces a public key from coins alone, without ever forming the matching secret key, and the other explains any real public key as if it had been produced that way, so the two cases cannot be told apart.

Why it is useful

In the generic ring signature, an attacker holding the coin flips that generated every honest encryption key could decrypt the shares and unmask the signer. Generating the encryption keys obliviously removes that path while keeping the same public keys.

How it works

  1. Check that keys produced obliviously, together with their coins, look the same as real keys paired with coins reconstructed after the fact.
  2. Change key generation so the encryption public key is produced by the oblivious generator instead of by the normal one.
  3. Keep everything else in the ring signature unchanged; signatures and proofs are exactly as before.
  4. With this change, revealing the key-generation coins of every honest user, including the signer, no longer helps identify who signed, and unforgeability is unaffected.

What to watch for

The property is special and not every encryption scheme has it; the paper offers El Gamal encryption over the group of quadratic residues modulo a prime as an example, which the reader should treat as an existence claim rather than a deployment recommendation.

Useful background: Standard-model ring signatures from encryption and a ZAP, ElGamal encryption.

Related ideas

Papers

q-Strong Diffie-Hellman assumption and member keys

Each member's private key is a pair (A, x) where A is a group element whose exponent is one over the sum of a secret value and x. Such a pair satisfies a pairing equation that anyone can check with the group public key.

Why it is useful

Producing a fresh valid pair is exactly the q-Strong Diffie-Hellman problem, so whoever cannot solve that problem cannot manufacture a new member. The paper notes this assumption behaves much like the Strong-RSA assumption that earlier group signatures used, but yields shorter objects.

How it works

  1. The key issuer picks a secret value and publishes a group element raised to it in the public key.
  2. For user i the issuer picks a number x and computes A as the group generator raised to one over the secret plus x.
  3. The user's private key is the pair (A, x); the pairing equation involving the public key and x verifies it.
  4. No one, not even the group manager, is allowed to hold the secret value itself - only the key issuer ever knows it.

What to watch for

The assumption is discrete-logarithm-type and its credibility rests on generic-group arguments cited from earlier work; the group size n is tied to the strength parameter q of the assumption.

Useful background: Bilinear group pairs, Discrete logarithm problem.

Related ideas

Papers

Ring signatures

A ring signature is made by one member of a chosen list of public keys, and anyone can check that some member of that list signed, without learning which one. The signer builds the list, called a ring, at signing time; it must contain the signer's own key and at least one other key.

Why it is useful

It gives anonymity with no setup at all: there is no group manager, no enrollment step and no coordination, and members of a ring may not even know they were included. Each signer separately chooses how much anonymity a given signature gets by choosing the ring.

How it works

  1. Each user independently runs a key-generation algorithm and publishes a public key; nobody registers it with an authority.
  2. To sign, a user picks a ring: an ordered list of public keys that includes the signer's own key and at least two keys in total.
  3. The signing algorithm takes the message, the ring and the signer's secret key, and outputs a signature that names no individual.
  4. Anyone verifies with the ring and the message; acceptance means someone holding one of the listed keys signed.
  5. Compared with a group signature, no manager can later revoke the anonymity, and rings can be formed on the fly from keys that were never prepared to work together.

Example

A department head receives a complaint signed with the ring of all twenty professors in a department: the signature proves a professor wrote it, but not which one.

What to watch for

Verification only narrows the signer down to the ring. If every key except the signer's belongs to one attacker, that attacker knows who signed, so a ring needs at least two honest members to hide anyone. People listed in a ring never agreed to be there and cannot remove themselves.

Useful background: Digital signatures.

Related ideas

  • Group signatures: the contrasting primitive: a manager can trace the signer, but enrollment and coordination are required
  • RingCT: a later protocol that hides payment senders using ring-style signer ambiguity

Papers

Ring signatures hide which key spent

A ring signature replaces the single signature that authorizes a payment with one signature that names a whole list of public keys and proves that one of their owners signed, without saying which.

Why it is useful

In Bitcoin the transaction is signed by the key that owns the coins, which the paper compares to signing a check. Monero wants the same authorization without a name attached: the spender folds their key into a set of keys that all look equally plausible.

How it works

  1. Collect n public keys that could plausibly have spent the coin, one of which belongs to the spender.
  2. Produce one signature that verifies against the whole list.
  3. A verifier learns that some member of the list authorized the payment, and nothing that separates that member from the others; guessing the signer is a one-in-n shot.

Example

With five keys in the ring, an observer sees five equally possible spenders and has no way to pick the real one.

What to watch for

Signer ambiguity is proved under the Decisional Diffie-Hellman assumption in the random oracle model, and it is only as strong as the set of keys the spender can honestly mix with.

Useful background: Digital signatures.

Related ideas

  • Ring signatures: The general primitive that this payment authorization instantiates.

Papers

Separations between ring signature security definitions

Proofs that each stronger definition in the hierarchy genuinely excludes schemes that pass the weaker one: under stated existence assumptions, a scheme is built that meets the weaker notion and visibly fails the stronger one.

Why it is useful

Without separations, a stronger-looking definition might be equivalent to the old one, and the extra clauses would be decoration. With them, a designer can see which game actually has to be targeted.

How it works

  1. Take a secure scheme and tag every honestly generated public key with a leading zero bit.
  2. Make signing and verification refuse to work whenever the ring contains a key that does not start with zero.
  3. Such a scheme still passes the old games, which only ever use honest rings, yet an attacker who plants a key starting with one either learns the signer outright or forges with respect to the honest-only subring.
  4. A different counterexample smuggles the message itself into the ring as a fake public key during signing, so a signature requested for one ring also verifies for a larger ring the attacker assembles afterwards.
  5. Read the resulting forgeries as proof that chosen-subring and insider-corruption security are strictly stronger requirements.

What to watch for

Several of these counterexamples are deliberately contrived, and one separation is proved from an assumption the paper notes is not minimal. The value is in the ordering of the definitions, not in the artificial schemes themselves; a natural scheme showing one of the same gaps is covered separately.

Useful background: Anonymity against adversarially-chosen keys, Unforgeability levels for ring signatures.

Related ideas

Papers

Short group signatures

A variant of group signatures chosen so that each signature fits in a fixed, small number of bytes. The paper builds signatures under 200 bytes, roughly the size of an ordinary RSA signature of comparable strength.

Why it is useful

The motivating system embeds transmitters in cars that broadcast signed safety messages; each car must stay anonymous, yet so many messages flow that a hard limit of 250 bytes per signature was set. Older group signatures built from the Strong-RSA assumption were too long for this.

How it works

  1. Cars broadcast signed status messages, and the messages reveal speed and location, so the sender must stay anonymous.
  2. All messages are signed by a tamper-resistant chip, and a compromised chip must be revocable.
  3. The broadcast volume forces signatures under 250 bytes, which Strong-RSA constructions of the time could not meet.
  4. The new scheme reaches 192 bytes at security comparable to a 1024-bit RSA signature.

Example

A car executing an emergency brake signs the alert with the group key of all cars; every nearby car verifies it with one group public key and learns nothing about which car sent it.

What to watch for

The length comparison is against 2004-era RSA-1024 and 170-bit pairing-group parameters. It is a historical sizing claim, not a parameter recommendation for present-day systems.

Useful background: Group signatures.

Related ideas

Papers

Splitting the group authority in two

The single group manager of earlier schemes is divided into an issuer, which runs the joining protocol and grants signing keys, and an opener, which identifies who produced a signature. Each authority is then graded by how much it is trusted: uncorrupt, partially corrupt (its secret key has leaked but it still follows its program), or fully corrupt (an attacker controls it outright).

Why it is useful

Two keys mean two separate failures an attacker would need, and an authority that can trace signatures cannot also mint members. Grading corruption is what lets each security requirement assume as little honesty as it can get away with, which is what makes the resulting definitions strong rather than nominal.

How it works

  1. Give the issuer and the opener separate secret keys, created together with the group public key at setup.
  2. For each requirement, declare the trust level of each authority before stating the game.
  3. Read the trust table: anonymity assumes an uncorrupt opener but tolerates a fully corrupt issuer; traceability assumes an uncorrupt issuer but only a partially corrupt opener; non-frameability is required even when both are fully corrupt.
  4. Each row of the table is the weakest trust for which that requirement can hold at all, so no requirement can be strengthened for free.

Example

A clerk who enrolls members cannot later trace signatures, and the tracing officer cannot enroll anyone, so stealing one of the two keys does not break both halves of the system.

What to watch for

If a single party plays both roles the definitions still apply, but the scheme must then be trusted for both jobs at once and the achieved security is weaker.

Useful background: From static groups to dynamic groups.

Related ideas

Papers

Spontaneous mixing without a coordinator

The spender builds the anonymity set alone, by choosing decoy keys from the public blockchain, instead of handing transactions to a service that combines them.

Why it is useful

CoinJoin and mixing services also hide senders, but they rely on a party that gathers or combines everyone’s transactions. A ring signature is produced by one person with no coordination step, so there is no operator to compromise or subpoena.

How it works

  1. Pick decoy outputs that already exist on the blockchain.
  2. Sign a ring containing those decoys together with the real spend key.
  3. Publish the signature; no server, group manager or rendezvous with other users is involved.

Example

A CoinJoin needs every participant to deliver a transaction to one combining server before the joint transaction exists; a ring signature exists as soon as its author finishes signing.

What to watch for

The paper does not analyse how decoys should be chosen, and decoys that differ from the real output in age, amount pattern or other visible features can narrow the ring from the outside.

Useful background: Ring signatures hide which key spent.

Related ideas

  • CoinJoin: Contrasted as mixing that needs a coordinating party.

Papers

Standard-model ring signatures from encryption and a ZAP

A ring signature built from any semantically secure public-key encryption scheme, any ordinary signature scheme and a ZAP, which is a two-round proof that convinces without revealing which witness was used. The signer signs normally, hides that signature among ciphertexts for the whole ring, and proves with a ZAP that one of them hides a valid signature.

Why it is useful

It was the first ring signature whose security proof needs no random oracle heuristic and no trusted setup, and it meets the strongest definitions in the paper: anonymity against attribution attacks and unforgeability with insider corruption.

How it works

  1. Split the signature to be hidden into random shares whose exclusive-or reconstructs it, and encrypt one share to each ring member's encryption key, so the whole stays hidden while any single decryption key stays unknown.
  2. Each user's public key holds three parts: a signing key, an encryption key whose decryption key is erased, and a random string that starts the ZAP.
  3. To sign, make an ordinary signature on the message together with the whole ring, encrypt it into the share structure, and attach a ZAP proof of the statement: one of these ciphertexts hides a valid signature by one of these public keys.
  4. To verify, check only the ZAP proof against the ring and the message; no decryption and no knowledge of any secret key is needed.
  5. Because verification is a proof about the ring as a whole, keys generated dishonestly cannot break anonymity or unforgeability.

What to watch for

A signature costs one ciphertext per ring member plus a proof for a large disjunction, so this is a feasibility result, not a practical design. The proof needs the ZAP's witness indistinguishability precisely because adversaries may choose the random string inside their own keys however they like; an ordinary non-interactive zero-knowledge proof tied to a shared reference string would not survive that. The claim to be first is the authors' own; they note concurrent standard-model work of Chow, Liu and Yuen for rings of constant size, and an earlier standard-model claim whose proof was found to be flawed.

Useful background: Ring signatures, Random oracle model, Public-key encryption.

Related ideas

Papers

The key image double-spend tag

A key image is a group element computed from the private key of the output being spent; the ledger rejects any later signature that reuses it.

Why it is useful

Ring signatures deliberately blur who signed, so the ledger still needs a way to stop one coin being spent twice. The tag is derived from the secret key rather than from the signer’s position in the ring, so it catches reuse without identifying the spender within a single transaction.

How it works

  1. At signing, compute I = xHp(P) for the real spend key x and its public key P.
  2. Include I in the signature; verifiers check the ring equations that involve it.
  3. Nodes and miners reject any transaction whose key image is already on the chain.
  4. The linkability argument shows that two verifying signatures sharing a public key must carry equal key images, so one of the two is necessarily rejected.

Example

Two transactions carrying the same key image are the same output spent twice; the second is discarded and the double-spend attempt is visible to everyone.

What to watch for

The tag is computed only for the real signer’s key, so linking happens exactly when the same output is spent twice; a decoy output spent in some unrelated ring is not linked to this signature. The two linked transactions become publicly connected, which is the price of the guarantee.

Useful background: Ring signatures hide which key spent.

Related ideas

  • Ring signatures: The linkable variant that the tag turns the primitive into.

Papers

The SDH group signature scheme

The complete scheme: a key generation algorithm issues member keys, a signing algorithm turns the zero-knowledge proof into a signature, a verification algorithm checks it against the group public key, and an opening algorithm traces it.

Why it is useful

It packages the proof of a member key into 192 bytes at the paper's parameters - three group elements and six field numbers - which is what the vehicle-safety application required.

How it works

  1. Key generation issues each user a member pair, publishes the group public key, and gives the tracing key to the group manager.
  2. Signing computes the proof's first-round values, then derives the challenge by hashing the message together with them, then computes the five answers.
  3. A variant of the Fiat-Shamir transform sends the challenge instead of the five committed values; the hash acts as a checksum over what was omitted.
  4. Verification re-derives the committed values from the challenge and answers, then checks that the hash of the message and those values matches.
  5. Signing needs eight exponentiations and no pairing; verification needs six multi-exponentiations and one pairing, and several pairing values can be precomputed.

What to watch for

Security holds in the random oracle model, where the hash is treated as ideal. The section also sketches shorter and CCA2-anonymous variants that replace Linear encryption with ElGamal or Cramer-Shoup under a further assumption about decision Diffie-Hellman hardness in the first group - an assumption the paper itself flags as risky and unverified.

Useful background: Zero-knowledge proof of an SDH pair, Fiat-Shamir transform.

Related ideas

Papers

Unforgeability levels for ring signatures

Three nested attacking games for ring signatures. In the weakest, the fixed-ring game, both the attacker's signing queries and the final forgery must use one fixed ring of honest keys. The chosen-subring game lets the attacker pick any subring for each query and for the forgery. The insider-corruption game additionally lets the attacker corrupt honest users, and lets honest users be asked to sign rings containing attacker-made keys.

Why it is useful

A forgery should count as a break unless a ring member actually signed that message under that ring, or the attacker put its own key in the ring. The weaker games miss realistic situations: honest signers can be talked into signing with rings that contain hostile keys, and attackers can buy or steal a member's key.

How it works

  1. Fixed ring: the attacker gets one ring of honest keys and a signing oracle for that ring, and must produce a new message that verifies under the same ring.
  2. Chosen subring: each oracle query names the signer, the message and any subring of honest keys containing that signer; the forgery may use any subring and must be a message never signed under that exact ring.
  3. Insider corruption: the attacker also gets a corrupt oracle that hands over any honest user's secret key, and signing queries may use rings containing adversarially chosen keys.
  4. A forgery succeeds only if it verifies and its ring contains no corrupted user and no message already signed under that ring.

What to watch for

The name insider corruption is a term of art; ring signatures have no insiders in the usual sense, since any key can join any ring. A scheme that passes the middle game can still fail the last one, which is why the levels are stated separately.

Useful background: Ring signatures, Existential unforgeability under chosen-message attack.

Related ideas

Papers

Why group signatures needed formal foundations

A definition states security as a game with rules an attacker can probe, rather than as a sentence in prose. This paper continues a program that replaces the informal wish lists attached to group signature schemes with a small number of such games, checks that the new games cover everything on the old lists, and then proves that a scheme can meet them.

Why it is useful

A proof only settles the statement it proves. When a requirement does not say what the attacker may do and what counts as winning, a scheme described as proven secure can still fail in a way nobody specified, and two readers can honestly disagree about what was claimed.

How it works

  1. Write each requirement as an experiment: the attacker is a program with named inputs, named oracles and a stated winning condition.
  2. Keep the list of formal requirements short, then show it implies the informal ones used in earlier papers, so the old goals are covered rather than dropped.
  3. Ask last whether a scheme meeting the definitions exists; here it does under the same assumption used for static groups, namely that trapdoor permutations exist.

Example

The informal sentence "the signer stays anonymous" becomes a game: the attacker names two members, receives a signature from one of them, and must say which.

What to watch for

Definitions settle what is claimed, not whether the underlying assumption holds, and the scheme built to answer the existence question is a proof of concept rather than a practical design.

Useful background: Group signatures.

Related ideas

Papers

Zero-knowledge proof of an SDH pair

A three-move protocol, generalizing Schnorr's identification protocol, in which a prover shows she holds a valid member pair without revealing it. The member element is first hidden inside a Linear encryption, and five relations about the encryption and the hidden exponents are then proven.

Why it is useful

It is the building block of the whole scheme: a group signature is nothing but a non-interactive version of this proof attached to a message.

How it works

  1. The prover picks two random exponents and publishes a Linear encryption of her member element as three group elements, plus two helper values that are the member number times each exponent.
  2. She commits to five blinding values by publishing five quantities computed from them.
  3. The verifier returns a random challenge from the field.
  4. The prover answers with five shifted values, each the blinding value plus the challenge times the secret.
  5. The verifier checks five equations; honest answers always satisfy them.

What to watch for

The guarantee is honest-verifier zero knowledge: transcripts can be simulated for a verifier who follows the challenge rule, and the simulation of the encrypted part leans on the Decision Linear assumption. Knowledge extraction works by rewinding the prover to answer two different challenges with the same first message.

Useful background: Schnorr identification protocol, Decision Linear assumption and Linear encryption, q-Strong Diffie-Hellman assumption and member keys.

Related ideas

Papers

Agreeing on keys and protecting conversations

Key-exchange protocols establish secrets between communicating parties. Authentication checks who is involved; messaging protocols manage keys as conversations, participants and devices change.

EKE

EKE combines password-based encryption with public-key key exchange.

Papers

Security goals for machine-readable travel documents

A machine-readable travel document is a passport with a contactless radio chip inside it. The chip stores the holder's identity details and biometric data such as the face image. Its two goals are that nobody can forge the stored identity, and that nobody can read private data over the radio while the holder is unaware.

Why it is useful

The chip answers radio queries without being touched or even opened, so a distant device could silently read the stored data. Biometric data raises the stakes permanently, because a leaked face image or fingerprint template cannot be replaced the way a password can.

How it works

  1. The International Civil Aviation Organization standard stores biometrics in the chip so border checks can identify the holder more reliably.
  2. Because the chip talks over radio without contact, some access control is required before it releases data.
  3. The only mechanism protecting the mandatory data groups is the optional Basic Access Control, which the paper says offers very little privacy protection.
  4. The radio identifier that the chip announces changes for each session instead of staying constant, so that identifier alone does not let a third party track the document.

What to watch for

Protocol-level protection does not fix the physics. The paper reports that readers with modified antennas could reach a passport from up to 25 metres rather than a few centimetres, and that the radio traffic of a legitimate session induces a power-line signal that can be captured 500 metres away.

Useful background: Digital signatures.

Related ideas

Papers

Authenticated key exchange

Binding fresh session keys to peers and transcripts, with explicit authentication direction, compromise timing and key confirmation. Authentication alone does not guarantee secrecy after compromise.

A key-recovery attack on forward secrecy

The paper's new attack works when the handshake is treated as complete after the responder's reply: the attacker corrupts the responder's long-term key, impersonates an initiator so the responder accepts, and later corrupts the long-term key of the party being impersonated - at which point it can compute the session key outright.

Why it is useful

It shows that the one-round-trip form is worse than an authentication slip: session keys can be recovered, so no strong proof of key secrecy can exist unless an extra handshake message is added.

How it works

  1. Corrupt the responder's long-term private key and impersonate an initiator; with no first data message in the model, the responder accepts as soon as it sends its reply.
  2. Ask the challenger to Test that accepted session, receiving either its real key or a random one.
  3. Corrupt the long-term key of the party you impersonated and recompute the session key from the handshake values.
  4. Distinguish the real key from the random one, which is exactly what the security game forbids.

What to watch for

The authors themselves call the attack artificial: it needs an unusual combination of compromises, and they present it as a barrier to strong proofs rather than as a practical break.

Useful background: Key compromise impersonation in WireGuard, The eCK-PFS-PSK security model.

Related ideas

Papers

Chaining values and transcript hashes in WireGuard

During the handshake each side keeps two running values: a chaining seed that feeds the key derivation function at every step, and a hash value that absorbs pieces of the conversation so far. The two transport keys are the outputs of the key derivation function applied to the last chaining value.

Why it is useful

The two chains tie the final keys to this particular run: change any Diffie-Hellman value, the preshared key, or an encrypted transcript field, and every later value in the chain changes with it.

How it works

  1. Start from the hash of a fixed label; each new Diffie-Hellman shared secret is fed to the key derivation function together with the current chaining value, giving the next chaining value and any intermediate keys the messages need.
  2. Selected transcript pieces - the peer's public keys, the encrypted long-term key, the timestamp, the empty "zero" ciphertext - are hashed into the running hash as the run proceeds.
  3. The preshared key is handled like the other inputs: it is applied to the chaining value in the ninth step of the paper's table.
  4. The transport keys are the first and second outputs of the key derivation function applied to the final chaining value, with an empty salt.

Example

Think of the chaining value as a rolling secret that each Diffie-Hellman result re-randomises, and the hash value as a running fingerprint of the conversation.

What to watch for

The hash chain does not cover everything: the session identifiers are never mixed into either chain, so the protocol cannot be proven to authenticate its full transcript. Adding them would be a small and straightforward strengthening, and the paper notes that similar gaps have hurt TLS before.

Useful background: The WireGuard handshake from the Noise framework.

Related ideas

  • HKDF: the key derivation function every step uses

Papers

EDHOC

EDHOC is a compact authenticated Diffie-Hellman exchange for constrained environments.

Papers

Key compromise impersonation in WireGuard

Key compromise impersonation (KCI) means an attacker who learns one party's long-term private key can then impersonate other people to that party, not merely read its traffic. In WireGuard, whoever holds the responder's long-term private key can build the first handshake message and pass as any initiator.

Why it is useful

It shows that the two handshake messages alone do not authenticate the initiator to the responder, so something else has to carry that proof of identity.

How it works

  1. Learn the responder's long-term private Diffie-Hellman value.
  2. Build the first handshake message yourself: the initiator's long-term key is only protected under keys that the responder's private value lets you compute.
  3. WireGuard's defence is for the responder to wait for the first data transport message from the initiator and check its integrity before trusting the session.
  4. Counting that message as part of the handshake makes the exchange one and a half round trips rather than one.

What to watch for

The attack was already described by WireGuard's own designer; it breaks an authentication goal, not the secrecy of a session between two honest parties.

Useful background: The WireGuard handshake from the Noise framework.

Related ideas

  • Key compromise impersonation: the attack class this belongs to

Papers

NAXOS

NAXOS is an authenticated key-exchange protocol that derives an ephemeral exponent from long-term and ephemeral secrets.

Papers

Session freshness in key-exchange security models

Freshness specifies which compromises a security experiment permits for the session being tested. It excludes trivial wins, such as asking directly for the very key whose secrecy is being tested.

Why it is useful

A claim that key exchange remains secure after compromise has little meaning unless it says which values may leak and when.

How it works

  1. Identify the session and related peer sessions.
  2. List the long-term, ephemeral and session-key revelations allowed by the model.
  3. Apply the timing restrictions on those revelations.
  4. Test secrecy only for sessions satisfying these conditions.

What to watch for

Freshness is a restriction in a security definition, not a claim that a deployed program can detect every leak. Two models may allow different attacks and need not be ordered from weaker to stronger.

Papers

SIGMA

SIGMA is a family of signature-and-MAC authenticated Diffie-Hellman protocols.

Papers

The eCK-PFS-PSK security model

A formal security game for key exchange, built by extending the eCK-PFS model of Cremers and Feltz with preshared keys. Many parties run many sessions while an adversary controls the network, may reveal long-term keys, ephemeral keys, preshared keys and session keys, and finally has to tell a tested session's key apart from a random value.

Why it is useful

WireGuard mixes three kinds of secrets, so a useful model must state exactly which combinations of leakage still leave the session key secret; that list is the cleanness predicate.

How it works

  1. The adversary creates sessions and preshared keys, and delivers every message itself, so it can modify, inject, delay or drop traffic at will.
  2. Corruption queries expose four layers of secrets: long-term keys, ephemeral keys, preshared keys and session keys, each modelling a different real-world failure such as bad randomness or a leaky partner.
  3. Two sessions count as partners through contributive keyshares: one session's sent key material appears inside the other's received messages. This is weaker than agreeing on the whole transcript, and is needed because WireGuard does not authenticate its full transcript.
  4. One Test query on an accepted session returns either its real key or a random one; the protocol is secure if the adversary's chance of telling which is barely better than guessing.

What to watch for

Security is claimed only for the leakage combinations the cleanness predicate allows, and the model covers the handshake: neither the cookie messages nor the data transport phase appear in it.

Useful background: Key compromise impersonation in WireGuard.

Related ideas

  • Extended Canetti-Krawczyk security: the model family this extends

Papers

The structure of Extended Access Control

Extended Access Control is the European addition to the ICAO passport. It protects the data groups that ICAO does not mandate, such as the fingerprint template, with three mechanisms: secure messaging based on elliptic curve Diffie-Hellman key agreement, a chip authentication protocol and a terminal authentication protocol.

Why it is useful

Basic Access Control depends on a guessable printed key, and the ICAO optional mechanisms do not authenticate the reader. Extended Access Control wants an authenticated key agreement that resists passive eavesdroppers, proves the chip is genuine and checks the reader's authorization.

How it works

  1. Establish secure messaging keys with elliptic curve Diffie-Hellman, which resists passive adversaries unlike the symmetric Basic Access Control agreement.
  2. Run chip authentication so that a cloned chip cannot impersonate the genuine document.
  3. Run terminal authentication, which is mandatory before the chip releases the non-mandatory data groups.
  4. Keep the ICAO-mandatory data groups readable without Extended Access Control, so countries that do not implement it can still inspect passports.

What to watch for

The compatibility requirement in the last step is the root of the downgrade problem. Protection covers only the extra data groups, and the anti-cloning benefit applies only where the document is read by a country that actually reads Extended Access Control.

Useful background: Basic Access Control in ICAO passports.

Papers

The three properties proven for TLS

The paper proves three properties: server authentication (a client that accepts really talked to a server holding the certified key), client authentication (the mirrored property when clients sign), and channel security (data sent afterwards is confidential and authenticated in the sense of stateful length-hiding authenticated encryption).

Why it is useful

The three-property shape is what ACCE security means and what the theorems deliver: server-only settings get server authentication plus channel security (SACCE), and adding a client certificate and a Certificate Verify signature yields full mutual ACCE.

How it works

  1. Server authentication: if an honest client accepts with a given peer identity, some honest server session shares its first three transcript messages; relaying is essentially the only way to make a client transmit.
  2. Client authentication: the client signs the transcript prefix with a certified signature key, and the matching condition extends to include the client certificate.
  3. Channel security: after a matching pair accepts, the adversary sees only a secure channel unless it reveals a key of that pair; the record layer must be sLHAE-secure.
  4. The mutual theorem needs the extracted KEM to be IND-CCCA secure, the certificate authority and client signatures to be unforgeable, and the record layer to be sLHAE-secure.

What to watch for

Client authentication is not implied by server authentication: in the server-only model a server session has no guarantee unless an honest client session matches it, and the channel-security game only scores sessions at honest clients.

Useful background: The two layers of TLS: handshake and record protocol.

Papers

The WireGuard handshake from the Noise framework

The handshake is meant to take one round trip: the initiator sends a hello carrying a fresh (ephemeral) Diffie-Hellman value plus its long-term public key encrypted under a key derived on the fly, and the responder answers with its own hello; both then derive the session keys.

Why it is useful

WireGuard is built from the Noise protocol framework, a family of Diffie-Hellman handshake patterns. Every possible combination of the two parties' long-term and ephemeral Diffie-Hellman values enters the key computations, which is intended to preserve security under various combinations of long-term and ephemeral key compromise.

How it works

  1. The initiator picks a fresh Curve25519 key pair and sends its public value together with its long-term public key encrypted under an intermediate key.
  2. The responder picks its own fresh key pair and replies, and an optional preshared symmetric key is mixed in near the end of the key schedule.
  3. Only Curve25519 is used for the Diffie-Hellman steps, and BLAKE2s serves everywhere: for hashing transcript pieces, inside HMAC, and inside HKDF for key derivation.
  4. At the end both sides hold the transport keys derived from the final chaining value.

What to watch for

Calling the handshake one round trip is optimistic: the responder should not treat the session as authenticated until it sees the first protected data message from the initiator, which makes the real exchange one and a half round trips - the subject of a later lesson.

Useful background: WireGuard.

Related ideas

Papers

Hybrid and multi-component key exchange

Protocol-level composition of establishment components, including post-quantum migration, transcript binding and downgrade resistance. Primitive KEM combiners are linked separately.

Muckle+

Muckle+ is a hybrid authenticated key-exchange construction combining multiple key-establishment components.

Papers

Password-authenticated key exchange

A password-authenticated key exchange creates a fresh session key without turning an eavesdropped conversation into an easy offline password test. It still needs to account for active guesses and for what happens if the server is compromised.

AuCPace

AuCPace is an augmented password-authenticated key-exchange construction related to CPace.

Papers

Basic Access Control in ICAO passports

Basic Access Control is the optional gate of the ICAO passport standard. Before the chip releases data, the reader must show that it knows information printed in the machine readable zone of the passport page: the passport number, the holder's date of birth and the expiry date. A symmetric key agreement then opens secure messaging for the session.

Why it is useful

The idea is that whoever can read the printed page, normally the holder handing the passport over, controls who may talk to the chip. It needs no infrastructure because the shared secret travels on paper.

How it works

  1. Derive the access key from the printed machine readable zone information, called MRZinfo.
  2. Let the reader prove to the chip that it knows that key.
  3. Run a key agreement based on the shared key to derive session keys.
  4. Protect all further communication with secure messaging under those keys.

What to watch for

The printed information has few possible values, about 56 bits of entropy in the work the paper cites, so an attacker can test guesses against recorded traffic offline instead of live. Learning it once grants unlimited permanent access without the holder, and the paper concludes that Basic Access Control should be abolished rather than repaired.

Useful background: Security goals for machine-readable travel documents.

Related ideas

Papers

CHIC PAKE

CHIC is a password-authenticated key-exchange construction using lattice-based KEMs.

Papers

Dragonfly

Dragonfly is a password-authenticated key-exchange design using a password-derived group element.

Papers

J-PAKE

J-PAKE is a password-authenticated key exchange using public-key operations and proofs of knowledge.

Papers

Owl PAKE

Owl is an augmented password-authenticated key-exchange scheme.

Papers

PACE replacing Basic Access Control

PACE, Password Authenticated Connection Establishment, is introduced with version 2 of Extended Access Control as the replacement for Basic Access Control. The paper characterizes it as password-based access control that resists active attacks, run with an access password that is a specific secret printed inside the passport.

Why it is useful

Basic Access Control used the machine readable zone information, which is personal data with another purpose and has few possible values. A dedicated printed secret separates the access credential from the holder's personal data, so guessing it no longer recovers a birth date or a passport number.

How it works

  1. Print a dedicated access password inside the passport, distinct from the machine readable zone data.
  2. Rely on that password being scanned by border staff when the document is opened for inspection.
  3. Use the password to run PACE between the reader and the chip, taking the place Basic Access Control had at the start of the exchange.
  4. Continue with terminal authentication and chip authentication as specified for Extended Access Control.

What to watch for

This survey describes the role and the credential of PACE, not its internals: no message flow, mapping step or key derivation appears in the paper. Learn the protocol itself from the Extended Access Control specification rather than from this entry.

Useful background: Basic Access Control in ICAO passports, The structure of Extended Access Control.

Related ideas

Papers

Password-authenticated key exchange

Password-authenticated key exchange, or PAKE, uses a shared password to establish a fresh cryptographic session key. Its goal is to stop a recorded exchange from becoming a convenient test for every password in an attacker's dictionary.

Why it is useful

Human passwords are often much easier to guess than randomly generated cryptographic keys. A protocol must account for that weakness instead of treating a password as a strong encryption key.

How it works

  1. Combine knowledge of the password with fresh random choices in a key-exchange protocol.
  2. Derive matching secret key material only through the intended exchange.
  3. Where the protocol provides confirmation, check that the other party obtained the matching key material.
  4. Derive the session keys for the application.

What to watch for

PAKE does not make weak passwords unguessable. Active guesses against a live participant still need controls such as rate limiting, and server-compromise protection depends on the particular protocol.

Related ideas

Papers

Pretty-Simple PAKE

This historical PAKE proposal masks Diffie-Hellman messages using a password-dependent group element. It then exchanges authentication values before deriving the session key.

Why it is useful

The proposal explores how to obtain password authentication with a small modification to a group-based key exchange.

How it works

  1. Agree on the group and generators required by the proposal.
  2. Each party creates a fresh ephemeral contribution and masks it with its password.
  3. Each party removes its own password mask from the received message and computes candidate shared material.
  4. Use distinct transcript-bound confirmation values, then derive the application session key if confirmation succeeds.

What to watch for

This is an explanation of an early proposal, not a deployment recommendation. Its historical primitive examples and security claims must not be substituted for the requirements of a current PAKE specification.

Papers

SPAKE2

SPAKE2 is a password-authenticated key exchange based on masked group elements.

Papers

SRP

SRP is a verifier-based password-authenticated key-exchange protocol.

Papers

SweetPAKE

SweetPAKE is a password-authenticated key-exchange design supporting decoy passwords.

Papers

Augmented and verifier-based PAKE

Client-server PAKE using a server-side record or verifier, including OPRF-assisted credential recovery. Server compromise can still enable guessing; resistance depends on the precise record and model.

OPAQUE

OPAQUE is an augmented password-authenticated key exchange using an oblivious PRF and credential envelope.

Papers

SPAKE2+

SPAKE2+ is an augmented password-authenticated key-exchange variant of SPAKE2.

Papers

Verifier-based password authentication

A verifier-based design stores a value related to the password at the server rather than using exactly the same secret representation at both ends. The protocol must specify what an attacker can do after stealing that stored value.

Why it is useful

The aim is to limit the damage from a server database compromise, not merely to change the format of stored passwords.

How it works

  1. Derive the server's stored verification value using the specified registration procedure.
  2. Run authentication using the client's password and the server's verifier.
  3. Analyze whether a stolen verifier permits impersonation immediately or only after additional work such as password guessing.

What to watch for

A verifier may still allow offline dictionary guessing after it is stolen. Storing a derived value is not automatically protection against every form of server compromise.

Papers

Balanced PAKE

Exchanges where peers hold equivalent password secrets. This classification concerns stored credentials, not message counts or post-quantum security.

CPace

CPace is a balanced password-authenticated key exchange using password-dependent group generators.

Papers

Password masking of group elements

Some password-authenticated exchanges combine an ephemeral group element with a group value determined by the password. A party using the matching password can remove the mask before computing its shared value.

Why it is useful

The password influences whether the exchange succeeds without being transmitted as a plainly testable password value.

How it works

  1. Create a fresh ephemeral group element.
  2. Combine it with the password-dependent mask specified by the protocol.
  3. Send the masked element.
  4. Remove the matching password mask from the received element and continue the key exchange.

What to watch for

This is a component of a PAKE, not a secure protocol on its own. The choice of group, generators, message checks and confirmation steps matters.

Useful background: Diffie-Hellman key exchange.

Papers

Unknown discrete-log relationships between generators

Two group generators can be different while still having an easily known relationship, such as one being the square of the other. Some password-masking constructions require that nobody using the protocol knows the exponent relating them.

Why it is useful

A known relationship can let an active attacker turn password guesses into predictions of the other party's candidate key material.

How it works

  1. Identify which generator relationships the construction assumes are hidden.
  2. Use the specified parameter-generation method rather than choosing one generator as a known power of the other.
  3. Keep this requirement distinct from merely checking that both values are valid group elements.

What to watch for

Different values do not imply an unknown relationship. Conversely, an unknown relationship alone is not a complete security proof for a PAKE.

Papers

Entity authentication and credential binding

Entity authentication in a single protocol run proves that the participant holds a particular secret key. This passport setting needs it in both directions: the reader proves it is an authorized terminal by signing a challenge from the chip, and the chip proves it is the genuine document rather than a copy in the chip authentication step.

Active Authentication against chip cloning

Active Authentication is an optional ICAO protocol in which the chip proves that it holds a private key. The reader sends a fresh challenge and the chip signs it, so a device that merely copied the passport's stored data cannot produce the response.

Why it is useful

Passive authentication only checks stored data, so a counterfeited chip that copies the data and the signature would pass it. Signing a fresh challenge requires the private key, which a copy of the stored data does not contain.

How it works

  1. The chip holds a private signing key.
  2. The reader sends the chip a fresh challenge.
  3. The chip signs the challenge with its private key.
  4. The reader verifies the signature with the chip's public key.

What to watch for

The paper reports that signing is slow for a chip with no power source of its own, that few countries implemented the mechanism, and that a man in the middle can forward the challenge to the genuine passport, which enables a cloning attack. The challenge can also carry semantics that leak information.

Useful background: Passive authentication with the document security object.

Related ideas

Papers

Chip authentication and the EACv2 ordering

In version 1 of Extended Access Control the chip authenticated itself before the terminal was checked. Version 2 reverses this: terminal authentication must be performed before chip authentication, so the chip proves itself only to a reader that has already proved its authorization.

Why it is useful

In the old order the chip released its authenticated material, including the face image and the security object, before knowing who was asking. The reordering restricts the release of that material to officially allowed terminals.

How it works

  1. Run the access-control step that opens the radio channel.
  2. Run terminal authentication, checking the reader's certificate chain and its signed answer to the passport's challenge.
  3. Only then run chip authentication and derive the secure messaging keys.
  4. Release the protected data groups under those keys.

What to watch for

The benefit is conditional. The specification note quoted in the paper says that when compatibility with ICAO is required, the chip must still grant less-sensitive data to terminals authenticated only by Basic Access Control. In the paper's words, any fake terminal reader can require the crippled ICAO standard, so the reordering helps only where Extended Access Control is enforced.

Useful background: The structure of Extended Access Control, Terminal authentication and the EAC certificate chain.

Papers

Key confirmation

Key confirmation lets a participant check that its peer derived the matching secret key material. It commonly uses an authentication tag over the exchange rather than sending the secret itself.

Why it is useful

Computing a local candidate key is not the same as knowing that the other participant obtained the same key for the same conversation.

How it works

  1. Derive candidate key material from the exchange.
  2. Authenticate the relevant transcript using a key derived or designated for confirmation.
  3. Check the peer's expected confirmation value.
  4. Reject the exchange and discard temporary secrets if the check fails.

What to watch for

The confirmation must be tied to the correct parties, roles and transcript. Receiving any valid-looking tag is not enough.

Related ideas

Papers

Role-separated authentication tags

Authentication tags can include different labels for the client, the server and other purposes. This prevents one kind of tag from being interpreted as another just because the parties share key material.

Why it is useful

A client's confirmation, a server's confirmation and session-key derivation are different jobs, even when they refer to the same exchange.

How it works

  1. Choose distinct, unambiguously encoded labels for each role or purpose.
  2. Include the relevant identities and transcript with those labels.
  3. Compute and verify the value for the specific role expected at that step.

What to watch for

A label must actually be included in the authenticated input. Implementations also need the exact primitive requirements of their protocol; authentication unforgeability alone does not imply pseudorandom key-derivation output.

Related ideas

Papers

Secure messaging protocols

A messaging protocol has to bring two people to a shared key, tolerate one of them being offline at the start, and keep refreshing keys as the conversation runs. This paper adds the question of what evidence the setup leaves behind: the handshake that creates the session key also decides whether anyone can later prove the session happened. Because message traffic after the handshake uses only session-key material, deniability established at the handshake covers the whole conversation.

Deniability of the Signal protocol

Signal is an initial key agreement (X3DH) that establishes a root key, followed by a message phase whose keys evolve by ratcheting: symmetric steps feed the current chain key to a key derivation function to produce the next chain key and a message key, and asymmetric steps add a fresh Diffie-Hellman exchange mixed with the chain key.

Why it is useful

The paper proves the whole conversation deniable once the opening agreement is: because ratcheting consumes only session-key material, no message phase reintroduces the long-term keys whose use would leave evidence.

How it works

  1. Run the initial agreement to obtain the root key, which fixes the first chain key and message key.
  2. Advance the chain with key derivation steps for each message and refresh it with a new Diffie-Hellman value whenever an ephemeral key changes.
  3. Observe that every message after the handshake is a function of the transcript, public inputs and session keys alone - never of a long-term secret key.
  4. Apply the session composition theorem: deniability of 3DH lifts to the whole session.
  5. Conclude Signal is offline deniable whenever its underlying agreement is, in particular under the KDH assumption.

What to watch for

This is offline deniability only - the online variant was already known to fail - and it is conditional: it stands on knowledge assumptions about the group and the random-oracle model, and the MQV counterexample shows such assumptions are not free.

Useful background: X3DH, Deniable sessions after the handshake.

Related ideas

Papers

Deniable sessions after the handshake

If the key exchange opening a session is deniable, and every later message depends only on the transcript, local inputs and the session key - never again on long-term secret keys - then the whole session is deniable.

Why it is useful

A deniability proof that stopped at the handshake would be useless if actually using the key reintroduced evidence. This composition theorem shows the property survives whatever the parties do with the key afterwards.

How it works

  1. Split the session into the key exchange run and the message phase that follows.
  2. Simulate the key exchange transcript together with the session key, which the definition of deniable key exchange already demands.
  3. Extend the simulation message by message, computing the honest party's outputs from the transcript so far, its public local inputs and the simulated key.
  4. Any judge that distinguished the full simulated session from a real one would distinguish the underlying key exchange simulation, contradicting its deniability.

What to watch for

The message phase must truly avoid long-term keys, and the extra inputs must not be tied to the party's identity - otherwise the simulator could not reconstruct the honest party's behavior.

Useful background: Offline deniability of key exchange.

Related ideas

Papers

Forward secrecy

Forward secrecy aims to protect past session keys even if a long-term authentication secret is exposed later. The long-term secret and the fresh secrets used for individual sessions have different roles.

Why it is useful

Losing a password or authentication key should not automatically decrypt all previously recorded conversations.

How it works

  1. Use fresh secret contributions for each session.
  2. Authenticate the session without making its key recoverable solely from the long-term secret.
  3. Erase temporary session-establishment secrets when they are no longer needed.
  4. Analyze what a later compromise reveals about earlier transcripts and keys.

What to watch for

Forward secrecy does not prevent an attacker with the stolen authentication secret from impersonating a party in future sessions. It also does not protect session keys that are stolen directly.

Related ideas

Papers

HMQV

HMQV keeps MQV's shape but makes hashing mandatory: the per-message exponents d and e come from hashing the exchanged values with identities, and the session key is a hash of the shared group element.

Why it is useful

The hash came out of a formal security analysis that exposed weaknesses in original MQV. For deniability the hash matters twice over - it rules out the unhashed counterexample, and in the random-oracle model it lets a simulator fall back on a random key.

How it works

  1. Derive d and e by hashing the transcript values together with the peer identities instead of truncating group elements.
  2. Compute the same combined exponentiation as MQV to get the shared group element.
  3. Hash that element to obtain the session key.
  4. Under the Knowledge of Diffie-Hellman assumption and key registration, a simulator that cannot recover the shared element outputs a random key that no judge can tell apart, giving a deniability proof in the random-oracle model.

What to watch for

The proof rests on a strong knowledge assumption about the group plus the random-oracle model, and on the simulator obtaining the accuser's long-term key through registered keys; without hashing the negative example applies.

Useful background: MQV, Knowledge of Diffie-Hellman assumption.

Papers

Immediate decryption and message-loss resilience

Immediate decryption requires that a message be decrypted the moment it arrives and be placed in its correct position in the conversation, without waiting for missing earlier messages. Message-loss resilience adds that a permanently lost message must not stop the parties communicating.

Why it is useful

Real messaging networks are asynchronous: messages get dropped, reordered and delivered late, and recipients stay offline for long stretches. A protocol that must receive everything in order stops working after a single loss, which is why the paper calls these properties essential rather than cosmetic.

How it works

  1. The receive algorithm returns an epoch number and a message index together with each message, which fixes its position in the overall order.
  2. The receiver keeps the keys of skipped messages in a dictionary, so a message that arrives before earlier ones is still decryptable.
  3. Because no key depends on receiving everything, a lost message costs only its own content; the conversation continues.
  4. The paper is the first to formalize this property, and observes that every deployed secure-messaging service has it.

What to watch for

Key evolution for forward secrecy and healing pulls against immediate decryption, which is exactly why earlier provable alternatives dropped it, and why their constructions stop working when a single message is dropped.

Useful background: Signal protocol.

Papers

Implicitly authenticated key exchange

A family of protocols where the messages on the wire are bare Diffie-Hellman values, independent of anyone's long-term private keys. Authentication is not signed into the transcript; the identity keys enter only inside the session-key computation, so only the right peers derive the same key.

Why it is useful

The design saves the cost of signatures or encryption on top of the ephemeral keys, and the transcript looks like something anyone could have generated - which is why this family, including Signal's key exchange, was long believed automatically deniable.

How it works

  1. Exchange only ephemeral Diffie-Hellman values, exactly as in plain Diffie-Hellman.
  2. Fold both parties' long-term public keys and their matching private keys into the derivation of the session key.
  3. Each party proves itself implicitly: an impostor without the right long-term secret ends up computing a different key.
  4. Treat the minimal transcript as evidence-free, and hope a simulator can reproduce it plus the key.

What to watch for

The paper's central lesson is that this hope is not automatic: over some groups the intuition fails outright, and elsewhere deniability requires strong knowledge assumptions about the group.

Useful background: Diffie-Hellman key exchange, Authenticated key exchange.

Related ideas

  • MQV: an early member of the family

Papers

Knowledge of Diffie-Hellman assumption

KDH says that for every efficient procedure outputting a group element Z, there is an extractor running on the same inputs and coins that either outputs the Diffie-Hellman value of a given group element with Z, or reports failure - and when it fails, no efficient procedure can compute that value.

Why it is useful

It resolves the simulator's central dilemma: the simulator cannot tell whether a malicious peer knows the Diffie-Hellman value it needs. With the extractor it either recovers the true session key or learns that a random key is safe.

How it works

  1. Model the malicious peer as the procedure that, given the honest party's public key and auxiliary input, outputs its ephemeral group element.
  2. Run the extractor guaranteed by the assumption on the peer's inputs and coins.
  3. If the extractor outputs the Diffie-Hellman value, combine it with the values the simulator can already compute and hash to the real session key.
  4. If the extractor reports failure, output a random key: no judge can compute the missing Diffie-Hellman value, hence cannot query the hash on the preimage of the real key, so random and real keys are indistinguishable.
  5. A stronger variant, SKDH, demands a value indistinguishable from the Diffie-Hellman value on failure and serves MQV; a generalized variant, EKDH, applies to the generation of long-term keys themselves and removes the need for key registration.

What to watch for

KDH is a strong knowledge assumption in the tradition of the Knowledge of Exponent assumption, and no standard group is known to satisfy it. Unlike extractable one-way functions, which are ruled out under indistinguishability obfuscation with shared auxiliary input, KDH's failure branch only requires that nobody can compute the value - a weaker demand that sidesteps that negative result.

Useful background: Computational Diffie-Hellman assumption, Random oracle model.

Related ideas

Papers

Knowledge of Discrete Log assumption

KDL says that whenever a procedure generating a group element carries enough internal information to determine its discrete logarithm, an extractor running on the same inputs and coins produces that logarithm - and is maximal: where it fails, every other procedure of comparable cost fails too.

Why it is useful

It grounds the deniability proofs on better-known territory: together with the classic Knowledge of Exponent assumption (KEA), it implies KDH, so the deniability of HMQV and 3DH follows from KEA plus KDL.

How it works

  1. Recall KEA: any procedure that, given g and g to the u, outputs a pair Z and Z to the u must internally know z, the discrete log of Z, and an extractor can produce it on the same coins.
  2. State KDL for arbitrary samplers of group elements: either the sampler's own computation yields the discrete log extractably, or it is infeasible for everyone.
  3. Combine: KEA converts any way of computing the Diffie-Hellman value into knowledge of a discrete log, and KDL's maximality then hands that log to the KDH extractor.
  4. Conclude that in groups where KEA and KDL hold, HMQV and 3DH are deniable in the random-oracle model.

What to watch for

These are knowledge assumptions - statements that certain computations necessarily leak their witnesses - and they are not implied by standard hardness assumptions; whether a candidate group satisfies them is a separate judgment.

Useful background: Discrete logarithm problem, Knowledge of Diffie-Hellman assumption.

Related ideas

Papers

MQV

MQV combines each party's long-term and ephemeral Diffie-Hellman keys into single exponentiations, so two messages and a few group operations yield an authenticated shared session key with no signatures.

Why it is useful

It was designed for efficiency: implicit authentication avoids sending certificates, signatures or ciphertexts alongside the ephemeral values, and the long-term keys never appear in the transcript.

How it works

  1. Exchange ephemeral values X = g to the x and Y = g to the y on top of certified long-term keys A = g to the a and B = g to the b.
  2. Derive short exponents d and e from bits of the exchanged values, d from X and e from Y.
  3. Alice, who knows a and x, raises the combined value of Bob's ephemeral and long-term keys to the exponent x plus d times a.
  4. Bob, who knows b and y, applies the mirrored computation, and both arrive at the same group element as the session key.
  5. In original MQV that group element is the key directly; hashing it is optional.

What to watch for

Precisely because hashing is optional, original MQV is the protocol the paper proves non-deniable over certain groups, so its bare form must not be treated as deniable.

Useful background: Implicitly authenticated key exchange.

Related ideas

  • HMQV: the hardened hashed variant

Papers

Signal protocol

Signal is a protocol for end-to-end encrypted conversations between two people, built into chat applications used by billions. Its engine is the Double Ratchet, which encrypts and authenticates every message under a symmetric key used for that message alone.

Why it is useful

It was the first widely deployed messaging design to combine three protections: past messages stay secret if today's state leaks, the channel heals after a leak, and a message that arrives late or out of order is still decrypted at once. Deployed before any formal analysis, it lacked a proof until papers like this one.

How it works

  1. The two parties start from one shared initial secret key; how that key is created sits outside the analysis, and deployed Signal in fact leaves it to a separate handshake called X3DH together with prekeys stored on a server.
  2. Every message is encrypted and authenticated with a fresh symmetric key.
  3. Two interleaved key-updating processes run through the conversation: a symmetric-key ratchet that advances with every message and a Diffie-Hellman ratchet that advances whenever the speaker changes.
  4. Each message carries a small header, so the receiver can work out where an out-of-order message belongs and decrypt it immediately.

Example

Two phones exchange chat messages over a flaky mobile network: some messages are delayed, some never arrive, and each is still decrypted on arrival and shown in the right place in the thread.

What to watch for

This paper models only the double-ratchet core. The generation of the initial shared key is assumed to come from a trusted setup; the authors themselves call the way Signal produces it slightly circular and leave modelling it to future work.

Useful background: Symmetric encryption with authentication.

Related ideas

Papers

Triple Diffie-Hellman key exchange

3DH authenticates a Diffie-Hellman exchange by hashing three Diffie-Hellman values at once: between one side's long-term key and the other's ephemeral, between the two ephemerals, and between the second side's long-term key and the first's ephemeral.

Why it is useful

Each side can compute all three of its values from its own two secrets, so two bare group messages yield an authenticated session key. This is the synchronous core of Signal's key setup, and deniability was one of its design goals.

How it works

  1. Publish long-term keys as in Diffie-Hellman-based protocols and exchange fresh ephemeral values X and Y.
  2. Each party computes the three shared secrets that mix one long-term key with the peer's ephemeral and the two ephemerals together.
  3. Concatenate the three values and hash them to derive the session key.
  4. Deniability for each side follows under the Knowledge of Diffie-Hellman assumption in the random-oracle model, without needing key registration, because the long-term-to-long-term value never enters the key.
  5. A simulator that extracts the one Diffie-Hellman value it cannot compute outputs the true key; otherwise it outputs a random key the judge cannot distinguish.

What to watch for

The hash is essential: an unhashed version that outputs the three values directly is provably non-deniable over the same groups where MQV fails.

Useful background: Implicitly authenticated key exchange, Diffie-Hellman key exchange.

Related ideas

  • X3DH: the asynchronous Signal variant built on it

Papers

X3DH

X3DH adapts 3DH to asynchronous messaging: the receiver publishes an ephemeral signed pre-key on a key server before anyone talks to him, and an initiator fetches it and derives the session key on her own, so the conversation can start while the receiver is offline.

Why it is useful

Asynchronous delivery means no simultaneous handshake is possible, and the key server must not be able to impersonate the receiver - which the signature on the pre-key prevents. The paper adds the missing piece: why this signature still leaves deniability intact.

How it works

  1. The receiver loads an ephemeral value Y on a key distribution server, signed with his long-term secret key.
  2. An initiator queries the server, verifies the signature, and runs the three-way Diffie-Hellman computation against the receiver's long-term key and signed pre-key.
  3. The result seeds a root chain key and the first message key, after which the parties continue with ratcheting.
  4. Deniability for the initiator carries over from the responder side of 3DH, since she acts on the value the receiver chose.
  5. Deniability for the receiver needs more: the signed Y is public auxiliary input, so the simulator lacks its discrete log and must extract two Diffie-Hellman values from the initiator instead - the K2DH assumption, which yields an extractor producing both or showing neither is computable, after which the simulator outputs the true or a random key.

What to watch for

The receiver-side proof uses the K2DH assumption and, in the theorem as stated, key registration; like all results here it holds in the random-oracle model and depends on the group satisfying the knowledge assumptions.

Useful background: Triple Diffie-Hellman key exchange, Knowledge of Diffie-Hellman assumption.

Related ideas

Papers

Asynchronous session establishment

Offline-recipient setup using published prekeys or encapsulation material. This differs from noninteractive agreement between reusable static keys.

PQXDH

PQXDH augments X3DH-style asynchronous key agreement with a post-quantum KEM.

Papers

Group key establishment and messaging

Contributory or controller-based group key management, tree-based agreement, dynamic membership and messaging epochs, including MLS-style protocols. Authentication and delivery consistency are distinct concerns.

Ratcheting and post-compromise security

Ratcheting is the practice of never reusing a message key: each message advances the state, so used keys are thrown away and a leaked state cannot walk backwards. This paper presents Signal's double ratchet, which combines that symmetric chain with a Diffie-Hellman agreement that restarts the chain whenever the speaker changes, giving forward secrecy, recovery after a compromise and out-of-order decryption at once.

Double Ratchet

The Double Ratchet is the key-scheduling algorithm inside Signal. Every message gets its own fresh symmetric key, produced by two interleaved ratchets: a symmetric-key ratchet that steps forward with each message, and a Diffie-Hellman ratchet that steps forward whenever the conversation changes direction.

Why it is useful

Evolving symmetric keys alone give forward secrecy but no recovery from a leak; fresh key agreement alone gives recovery but no per-message isolation. Running both, with the agreement messages carried inside the message headers, gives forward secrecy and healing together without delaying, buffering or reordering messages.

How it works

  1. Whenever it becomes a party's turn to speak, that party performs one step of continuous key agreement (the Diffie-Hellman ratchet) and attaches the resulting agreement message to every message it sends until the partner answers.
  2. Each agreement key is absorbed into a shared randomness pool, called the root generator, whose output becomes the key for a new epoch: a stretch of messages sent in one direction.
  3. Inside an epoch the symmetric ratchet derives a fresh message key from the previous one for every message sent or received.
  4. Keys for messages that were skipped over are stored in a dictionary, so a late or early message can still be decrypted without waiting for anything.

What to watch for

Healing is not instant: for a few epochs after a state leak the security definition deliberately gives no protection against active attacks, and recovery assumes the attacker stays passive and the parties can draw fresh randomness.

Useful background: Signal protocol, Diffie-Hellman key agreement.

Related ideas

Papers

Forward secrecy in messaging

Forward secrecy means that when an attacker steals a party's current secrets, messages that were sent earlier and then deleted from the state remain confidential.

Why it is useful

Without it, one seizure of a device would decrypt the whole stored history of a conversation. With it, the thief is limited to messages still in flight and to new messages until the channel heals.

How it works

  1. Keys are derived in a chain, and each used link is erased, so past keys cannot be recomputed from the stolen state.
  2. The security game encodes this by letting the attacker corrupt a party at any moment and still requiring that earlier protected messages stay hidden.
  3. In isolation, forward secrecy only needs a stream-cipher-style chain built from a pseudorandom generator; the hard part is keeping it while also healing and decrypting immediately.

What to watch for

The guarantee assumes old key material really is erased from the state, and it is stated for messages already removed from it. Notably, it holds in this paper even when the attacker controls the parties' local randomness.

Useful background: Symmetric encryption with authentication.

Papers

Post-compromise security in messaging

Post-compromise security, also called channel healing, says that once a leak of a party's state ends, the channel becomes fully secure again after a few rounds of back-and-forth, provided the attacker then stays passive.

Why it is useful

It bounds the damage of a temporary seizure: the attacker keeps whatever it read during the leak, but messages sent after recovery are again confidential and authentic, so a compromise is a window rather than a permanent break.

How it works

  1. Recovery is driven by new secret input that the attacker cannot predict from the stolen state: the fresh random choices inside the next key-agreement steps.
  2. The agreement component heals on its own within two rounds of the alternating conversation.
  3. Counting from the last leak, the full protocol resumes its guarantees after a fixed number of epochs (one epoch being one stretch of messages sent in a single direction), which the paper computes as two plus the agreement component's own delay.

What to watch for

Healing requires good randomness, and the basic definition only demands it against a passive attacker. An active attacker who has just stolen a state can always disrupt the session, for example by injecting messages, so those epochs are excluded rather than protected.

Useful background: Forward secrecy in messaging, Diffie-Hellman key agreement.

Papers

RHQC

RHQC is a code-based ratcheted key-exchange construction.

Papers

The Diffie-Hellman ratchet as continuous key agreement

Continuous key agreement (CKA) is this paper's abstraction of Signal's public-key ratchet: two parties take turns sending a short public message, and each round both derive the same fresh secret key.

Why it is useful

Each new shared secret is unpredictable from a stolen state, which is what makes healing possible. Casting it as its own primitive, rather than as Diffie-Hellman specifically, lets the same messaging protocol be rebuilt from any key encapsulation, a public-key operation that delivers a fresh shared secret inside a ciphertext, including post-quantum ones.

How it works

  1. The parties alternate: in odd rounds one sends the agreement message, in even rounds the other does, and both output the same round key on sending and receiving it.
  2. The required property is that, even given the entire public transcript of agreement messages, all the round keys still look uniformly random and independent.
  3. The key agreement also has its own forward secrecy: past round keys stay safe once the state leaks, measured by how many rounds a party must wait before its state holds nothing about older keys.
  4. Signal's Diffie-Hellman version reuses one public value first as a ciphertext and then as the next public key, halving communication at the price of holding the secret exponent one round longer than a generic construction would.

What to watch for

The primitive is defined as synchronous and passive: parties speak in turns and the attacker may not modify the agreement messages. Protection against tampering comes from the authenticated encryption wrapped around it, not from the agreement itself.

Useful background: Diffie-Hellman key agreement, Post-compromise security in messaging.

Papers

The secure-messaging security notion

The paper defines secure messaging as a single game against an attacker who schedules every send and delivery, injects forged ciphertexts, corrupts both parties' states as often as it likes, and may even choose the randomness used for encryption.

Why it is useful

Earlier formal treatments were either tied to Signal's implementation details or explicitly gave up immediate decryption and message-loss resilience. One explicit game states which guarantees a messaging protocol owes its users, and which attacks are unpreventable in principle.

How it works

  1. While both states are uncompromised, the scheme must resist active attack: injected ciphertexts are rejected and honestly delivered ones decrypt correctly and in the right order.
  2. Protected messages must stay hidden even if either party is corrupted afterwards, which encodes forward secrecy.
  3. After a corruption, security must return within a bounded number of epochs (one-directional stretches of messages) provided the attacker is passive; active attacks in that recovery window are simply ruled out, because no scheme can prevent them.
  4. Every property except healing must survive even when the attacker controls the parties' local randomness.

What to watch for

The game needs careful bookkeeping of messages in flight, of challenge messages and of compromised ones to rule out trivial wins, and the authors note the resulting definition is still rather complex; in practice it is attacked through three simpler games instead.

Useful background: Forward secrecy in messaging, Post-compromise security in messaging.

Papers

The symmetric-key ratchet as forward-secure AEAD

Forward-secure authenticated encryption with associated data (FS-AEAD) is this paper's abstraction of Signal's symmetric-key ratchet: it protects a one-directional stream of messages inside one epoch, providing forward secrecy and immediate decryption.

Why it is useful

Separating this piece out shows exactly what a symmetric chain can and cannot do. It gives cheap per-message key updates and rejects injected or replayed ciphertexts, but it cannot heal after a compromise, because both parties hold the same chain state.

How it works

  1. Both parties hold the same chain state; before each message, a pseudorandom generator (an algorithm whose output is indistinguishable from random) expands it into a new state plus a one-time authenticated-encryption key.
  2. The message counter and the header are bound in as associated data, that is, as extra information the encryption authenticates but does not hide, so a ciphertext cannot be moved to another position.
  3. If a received ciphertext has a higher index than expected, the receiver advances the chain at once and stores the skipped keys in a dictionary for later arrivals.
  4. Because the primitive is deterministic, meaning it makes no random choices of its own, it needs no good randomness at all.

What to watch for

There is no post-compromise security inside an epoch: leaking either party's state exposes that whole epoch. Epochs end when a message from the other party arrives, at which point the Diffie-Hellman ratchet takes over.

Useful background: Forward secrecy in messaging, Authenticated encryption with associated data.

Papers

What is proven for the generalized Signal protocol

The paper's main theorem: combining a secure continuous-key-agreement scheme, a secure forward-secure authenticated-encryption scheme and a secure two-input hash function yields a provably secure messaging scheme whose healing time is two epochs plus the agreement component's own delay, with an explicit security loss.

Why it is useful

It turns Signal from a deployed engineering artifact into one instance of a provable design, and shows what each component contributes, so any component can be swapped without redoing the whole argument.

How it works

  1. Security is first split into three simpler games, correctness, authenticity and privacy, which together imply the full notion.
  2. The proof then replaces, step by step, the agreement keys, then the outputs of the randomness pool, then the ciphertexts, by random values, reducing each step to one of the three component assumptions.
  3. Instantiating the components with the Diffie-Hellman agreement, a pseudorandom-generator chain and a hash function recovers Signal itself, up to small bookkeeping differences.
  4. Replacing the agreement component with any post-quantum key encapsulation gives a post-quantum variant of Signal, and that variant needs no random-oracle assumption, that is, no idealized model of hash functions, in the analysis.

What to watch for

The theorem covers the paper's variant of Signal, which differs from deployed Signal in minor internal bookkeeping, and it assumes the initial shared key comes from trusted setup. Stronger fine-grained compromise and post-impersonation recovery notions from related work are not achieved by this notion; the paper only sketches, without proof, an extension using public-key encryption and signatures that would strengthen it.

Useful background: The secure-messaging security notion, The Diffie-Hellman ratchet as continuous key agreement, The symmetric-key ratchet as forward-secure AEAD.

Papers

Secure-channel composition and resumption

Handshake/record composition, traffic-key schedules, rekeying, resumption, early data and channel binding. Channel security includes replay and ordering beyond individual AEAD ciphertexts.

IKEv2

IKEv2 negotiates keys and security associations for IPsec.

Papers

Noise protocol framework

Noise specifies patterns for combining Diffie-Hellman operations with handshake and transport encryption.

Papers

TLS 1.3

TLS 1.3 specifies a handshake and record protocol for establishing and using traffic keys.

Papers

Unauthenticated key agreement

Key agreement derives shared secrets through public messages. Without authentication, the participants may not know who shares the resulting key.

CTIDH

CTIDH is a CSIDH variant organized for constant-time group-action evaluation.

Papers

Diffie-Hellman key exchange

Diffie-Hellman lets two parties derive the same group value by exchanging public values formed from fresh secret exponents. Each party combines its own secret exponent with the other party's public value.

Why it is useful

The shared value need not be sent over the network, so an observer does not receive it directly.

How it works

  1. Agree on a suitable group and generator.
  2. Choose fresh secret exponents a and b, and exchange the public values g to the power a and g to the power b.
  3. Raise the received value to the local secret exponent. Both sides obtain g to the power ab.
  4. Use the specified key-derivation procedure before treating that group value as application key bytes.

What to watch for

Plain Diffie-Hellman does not authenticate the other party. An active intermediary can conduct separate exchanges unless the protocol adds authentication.

Related ideas

Papers

ECDH

ECDH performs Diffie-Hellman key exchange in an elliptic-curve group.

Papers

Noisy-key reconciliation

Converting nearby noisy values into matching keys with helper data, decoding or rounding. This computational use of noise differs from assuming a physically secret channel.

Lattice key reconciliation

Reconciliation procedures derive matching key bits from nearby noisy lattice values using helper information.

Papers

Noninteractive key agreement

Pairwise derivation from independently published keys, including algebraic actions and setup-dependent constructions. Posting asynchronous prekeys for an interactive design is a different use pattern.

Swoosh

Swoosh is a lattice-based noninteractive key-exchange construction.

Papers

TLS and standardized secure channels

A secure channel protocol has two jobs: agree on fresh keys between two identified parties, and then use those keys to protect the data that follows. This paper shows how easily the two jobs become entangled when the same key both confirms the handshake and encrypts data - the same entanglement that made SSL and TLS hard to analyse before version 1.3.

Authenticating a server with a KEM

KEMTLS replaces the server handshake signature with an encapsulation: the client encrypts a fresh shared secret to the long-term KEM public key in the server certificate.

Why it is useful

Only the holder of the certified secret key can recover that shared secret, so recovering it proves you are talking to the certificate owner, while transmitting KEM-sized objects instead of signature-sized ones.

How it works

  1. Phase 1: client sends an ephemeral KEM public key; server answers with an encapsulation against it, giving an unauthenticated secret.
  2. Phase 2: server sends its certificate holding a long-term KEM public key in the same flight; client encapsulates against it and sends the ciphertext back, giving a shared secret only the real server can compute.
  3. Phase 3: both sides MAC the transcript for explicit confirmation; the two KEM secrets are mixed through the TLS 1.3-style key schedule.

Example

Think of it as replacing "sign this transcript to prove your identity" with "decrypt this fresh secret to prove your identity".

What to watch for

Certificate authorities still sign certificates, so signatures do not disappear from the system, only from the live handshake; the client also still needs signature-verification code.

Useful background: Why post-quantum authentication is the harder half.

Papers

Bleichenbacher attack and the hidden-failure countermeasure

Bleichenbacher 1998 used a chosen-ciphertext attack on RSA PKCS #1v1.5 to let a man in the middle recover the pre-master secret and so the application keys, given only an oracle telling whether a ciphertext decrypted to a validly padded value; TLS answers by hiding decryption failures.

Why it is useful

This is the attack that shaped TLS-RSA: the server continues with a random pre-master secret when decryption fails, one error covers both failure types, and the paper proves this ad hoc countermeasure actually works inside the whole protocol.

How it works

  1. The attacker sends modified RSA ciphertexts to the server and watches for any signal that separates valid from invalid padding.
  2. TLS mandates suppressing the decryption error, substituting a random PMS, and continuing, which removes the validity oracle.
  3. In the model, the RSA ciphertext and the encrypted client Finished message are treated as one monolithic message, so the adversary never learns which part failed.
  4. Formally, decapsulation replaces a failed PMS with a random value to mask failure even against a timing channel.

What to watch for

The proof depends on implementations not leaking decryption failure through side channels such as timing; a token that mishandles PKCS #1v1.5 errors can reintroduce the attack.

Useful background: Why TLS resisted standard key-exchange models.

Papers

Downgrade resilience before the handshake completes

During the implicitly authenticated part of the handshake, the client cannot be pushed onto algorithms it distrusts, but an attacker can still force a choice the honest server would have refused; full resistance only once the stage-6 key is accepted.

Why it is useful

Algorithm negotiation is part of the transcript, so it becomes authenticated exactly when the transcript does, which happens one round trip later in a KEM-based handshake than with signatures.

How it works

  1. Before confirmation: the client keeps control of what it accepts, so no algorithm it disabled can be forced on it.
  2. During the window: an active attacker may steer the connection to a different client-supported algorithm the server would have rejected.
  3. After the server confirmation MAC: both parties have MACed the same negotiation messages, giving full downgrade resilience.

What to watch for

This is a real, if bounded, weakening compared with signed TLS 1.3 during the handshake; it disappears once the handshake completes, and confidentiality of early client data is never affected.

Useful background: Implicit authentication and when it becomes explicit, Transcript binding in the key schedule.

Papers

Handshake MAC fields and the cookie mechanism

Every handshake message ends with two short message authentication codes, called mac1 and mac2: mac1 is keyed with a hash of the recipient's long-term public key, and mac2 is keyed with a cookie value. The specification also defines Cookie Reply messages for peers that are under load.

Why it is useful

These fields let a receiver label and check incoming handshake messages cheaply, and the cookie machinery exists to protect a peer that is being flooded with junk handshakes.

How it works

  1. The sender hashes a fixed label together with the responder's long-term public key and uses the result as the mac1 key over the message built so far.
  2. It then computes mac2 with the cookie key over the message plus mac1, and appends both values to the message.
  3. The specification assumes both values are checked before the session keys are derived.

What to watch for

Neither field authenticates anything in the analysed form: both keys are public values - a hash of a public key, and the cookie - so anyone can compute these codes. The paper's security model also leaves the Cookie Reply messages out entirely, so their flood protection is unproven here.

Useful background: The WireGuard handshake from the Noise framework.

Related ideas

Papers

Implicit authentication and when it becomes explicit

A key is implicitly authenticated when the only party who could possibly compute it is the intended peer; explicit authentication is the later proof that the peer actually took part.

Why it is useful

The distinction decides what the client knows at each moment: when it first sends application data, only the genuine server can read it (implicit), but only one round trip later does a MAC confirmation show a live server participated (explicit).

How it works

  1. Track the shared secret encapsulated to the certified key: an attacker without the secret key cannot derive it, so any key derived from it is implicitly authenticated.
  2. Wait for the server Finished message: it MACs the whole transcript under a key derived from that shared secret, which converts implicit into explicit authentication.
  3. Read the security model as recording, per stage, whether a key is implicit, explicit, or not authenticated yet.

What to watch for

Implicit authentication alone gives no proof the server was live, and early client data is sent before the algorithm negotiation is fully authenticated; a KEM-based handshake also gains offline deniability that signatures do not give.

Useful background: Authenticating a server with a KEM.

Papers

KEM correctness error and decapsulation failures

A KEM is delta-correct when both sides compute the same shared secret except with some small probability; that failure chance has to be carried through the protocol proof.

Why it is useful

If decapsulation can silently return a different secret than encapsulation produced, two honest parties could derive different keys, so session-matching arguments must budget for the error.

How it works

  1. Define correctness as the probability that decapsulation of an honest ciphertext disagrees with the encapsulated secret.
  2. Add the error term to the match-security argument instead of assuming perfect agreement.
  3. Keep the failure probability small enough that it never dominates the security bound.

What to watch for

This paper treats decapsulation failure only as a correctness error; it does not discuss implicit-rejection KEM designs that answer invalid ciphertexts with pseudorandom secrets instead of an error.

Useful background: Authenticating a server with a KEM.

Papers

Kerberos ticket-based authentication

Kerberos is a deployed network login protocol: a user proves who she is once per day, and a trusted server then issues encrypted credentials, called tickets, that let her use many network services without typing her password again.

Why it is useful

It removes the need to share a secret with every mail, file and print server. Each server only has to trust the ticket issuer, and the user only has to remember one password.

How it works

  1. The user logs in once, typically at the start of her working day.
  2. A dedicated machine acts as the trusted server: the Key Distribution Center, made of a Kerberos Authentication Server and a Ticket-Granting Server.
  3. The client obtains a long-lived ticket-granting ticket from the authentication server and exchanges it for short-lived service tickets, one per server she wants to use.
  4. The client software runs in the background, so after the initial login the user notices nothing.

Example

Logging in to a campus machine in the morning, then reading mail, mounting files and printing without further passwords, is the everyday Kerberos case.

What to watch for

The Key Distribution Center is a single point of trust: it holds long-term keys for every user and server, so it must be protected. A ticket-granting ticket can stay valid for a day, so a stolen one remains useful for hours.

Related ideas

  • Authenticated key exchange: the task the exchanges perform
  • TLS: another deployed protocol for authenticating connections

Papers

Limits of this analysis

The guarantees cover one specific core: the three exchanges of basic Kerberos and the public-key mode of PKINIT, with every party either honest or adversarial and no clocks in the model.

Why it is useful

Knowing what is left out is what makes the positive results usable, because each omission marks a place where the deployed protocol can behave differently from the analysed fragment.

How it works

  1. Timestamps are replaced by nonces, which the paper argues does not change the authentication and confidentiality properties, but this rules out timestamp-dependent guarantees.
  2. The Diffie-Hellman mode of PKINIT is not considered.
  3. Cross-realm authentication, where tickets issued by one organisation are accepted in another, is not considered.
  4. Whether the concrete public-key encryption, signature and checksum algorithms allowed by PKINIT meet the assumptions of the proofs was left open; only the symmetric encryption profile had been checked at the time.

What to watch for

The two protocol variants need nearly identical but separate proofs, because the framework lacks modular proof techniques for splitting a large protocol into pieces.

Useful background: What is proven for Kerberos, and what is not.

Papers

One master secret feeds every handshake key

All handshake secrets come from a single master secret MS: the application key and both Finished-message values are derived from MS with different input labels, and MS itself comes from the pre-master secret mixed with both parties random values.

Why it is useful

This shared state is why a TLS session hangs together: the three early messages fix the nonces, the certificate and the pre-master secret, and from that point the keys and both Finished values are already determined.

How it works

  1. The client picks the pre-master secret PMS and sends it under the server public key; each side computes MS = Kdf(PMS, nonce pair) and deletes PMS.
  2. The application key AKEY and the unencrypted Finished values are computed as PRF outputs over MS with the label 0, 1 or 2 and the handshake transcript.
  3. Two sessions match when their transcripts begin with the same three messages, which pins down the nonces, the server identity and PMS, and therefore the keys.

What to watch for

Because one value feeds everything, a leak of MS compromises the session, and reusing MS across resumption weakens separation; the paper criticises exactly this design choice.

Useful background: The two layers of TLS: handshake and record protocol.

Papers

Per-mode assumptions: OW-PCA, IND-CCA and PRF-ODH

Each TLS mode is proven by showing its KEM meets CCCA security under its own assumption: TLS-RSA from one-wayness against plaintext-checking attacks in the random oracle model, TLS-CCA from ordinary IND-CCA security in the standard model, and TLS-DH or TLS-DHE from the PRF-ODH assumption.

Why it is useful

This is where the assumptions get matched to reality: the deployed RSA mode needs a weaker, custom assumption because PKCS #1v1.5 is not CCA-secure, while replacing it with a CCA-secure scheme gives a standard-model proof.

How it works

  1. TLS-RSA: RSA PKCS #1v1.5 is assumed OW-PCA secure, invertible even given an oracle that checks plaintext-ciphertext pairs; Kdf is modelled as a random oracle. This is the only mode proven in the random oracle model.
  2. TLS-CCA: with any IND-CCA encryption scheme replacing PKCS #1v1.5, security follows in the standard model, confirming IND-CCA as the right target.
  3. TLS-DH and TLS-DHE: the Diffie-Hellman KEM relies on PRF-ODH security of the key derivation function, which rules out related-key behaviour; for TLS-DH the assumption is provably necessary, since PRFs failing it make the protocol insecure.
  4. All modes additionally assume a secure PRF and an sLHAE-secure record cipher, and secure signatures when authentication is mutual.

What to watch for

OW-PCA for RSA PKCS #1v1.5 rests on an RSA-like assumption introduced in 2002 and not weakened since, but it is a strong, non-standard assumption; forward secrecy for TLS-DHE is inherited from earlier work, not proven here.

Useful background: The modular proof: extracting a KEM and CCCA security.

Papers

PKINIT: certificates instead of a password

PKINIT is an optional replacement for the first round in which the client and the authentication server use public-key pairs and certificates instead of the password-derived shared key.

Why it is useful

It removes the weakest link of basic Kerberos, where the first reply is protected by a password-derived key that an attacker can test guesses against, and it lets administrators reuse an existing public-key infrastructure rather than manage a shared secret per user.

How it works

  1. The client signs a time and a fresh nonce with her private key and sends that signature together with her certificates.
  2. The authentication server verifies the certificate chain and the signature, then invents a fresh symmetric key for this single reply instead of reusing a long-term key.
  3. It signs that fresh key together with a keyed hash, called a checksum, taken over the entire client request, encrypts the whole block under the client public key, and uses the fresh key to protect the new authentication key.

What to watch for

The reply mixes certificates, a signature, public-key encryption and symmetric encryption in one message, so it is more complex than the basic first round. Only the public-key encryption mode is analysed in the paper.

Useful background: The Authentication Service exchange.

Papers

Record-layer and negotiation attacks around the analysis

Real TLS attacks split into two groups relative to this paper: record-layer breaks caused by cipher options that are not sLHAE-secure, and negotiation-layer attacks (ciphersuite downgrade, renegotiation, CRIME compression) that the model does not represent at all.

Why it is useful

It marks the boundary of the theorem: attacks of the first kind are excluded by assuming an sLHAE-secure record cipher, while attacks of the second kind are simply out of scope because negotiation, compression and fragmentation are not modelled.

How it works

  1. BEAST, the short-MAC attack, Lucky 13 and the RC4 attacks all exploit record-layer components outside the sLHAE assumption; CBC done carefully or a strong stream cipher restores it.
  2. Ciphersuite downgrade, the renegotiation attack and CRIME need negotiation or compression features that the analysis omits.
  3. The paper states plainly that an interaction between omitted features and the core could still enable new attacks.

What to watch for

Because ciphersuite negotiation is not modelled, each key-establishment method gets only a stand-alone guarantee, not a guarantee about which method the parties agreed to use.

Useful background: The three properties proven for TLS.

Papers

The attack that forced the PKINIT fix

Before the fix, the signed part of the PKINIT reply contained the fresh key and a nonce but nothing that named the client, so a malicious legitimate client could obtain the reply to another client’s request and pass it off as her own.

Why it is useful

It shows concretely what goes wrong when a reply is not bound to the request it answers, and it is the bug that the checksum over the whole request now closes.

How it works

  1. The attacker intercepts another client’s request to the authentication server and reuses its signed data inside her own request.
  2. The server answers the attacker, because the request formally comes from her, and the reply decrypts under the attacker’s public key.
  3. The attacker forwards that reply to the victim client, who accepts it as if it had been made for her.
  4. The attacker then knows the new keys the victim believes she shares with her servers, either by translating messages or by impersonating those servers; in the first variation the victim ends up authenticated as the attacker.

What to watch for

The paper analyses the fixed specification, where the server signs a checksum of the entire request; the fix entered revision 27 of the PKINIT draft and the current RFC.

Useful background: PKINIT: certificates instead of a password.

Papers

The Authentication Service exchange

The first Kerberos round. The client asks the Kerberos Authentication Server for a ticket-granting ticket, and the server answers with a freshly made key plus the ticket, each protected by a different long-term shared key.

Why it is useful

This is the only round that involves the key derived from the user password; everything afterwards uses keys invented for the run, which limits how much any later leaked message can tell an attacker.

How it works

  1. The client sends her own name, the name of the ticket-granting server she wants a ticket for, and a fresh random number called a nonce.
  2. The authentication server invents a new key AK to be shared by the client and the ticket-granting server.
  3. One copy of AK travels encrypted under the long-term key shared by the client and the authentication server, together with the nonce, that server’s local time and the name of the ticket-granting server.
  4. A second copy of AK sits inside the ticket-granting ticket, encrypted under a long-term key shared between the authentication server and the ticket-granting server, so the client cannot read or alter it.

What to watch for

The long-term client key is usually derived from a password, so the strength of this round is capped by the user’s ability to choose and remember good passwords.

Useful background: Kerberos ticket-based authentication.

Papers

The modified handshake and its security proof

The paper's fix is a third handshake message, SenderConf, sent by the initiator and computed under a freshly derived key that is used for nothing else. With that message in place, the main theorem proves the modified handshake secure in the eCK-PFS-PSK model.

Why it is useful

Separating the confirmation key from the transport keys restores modularity: the handshake authenticates itself, and the transport keys are never spent on proving anything, so they can stay indistinguishable from random as the security game demands.

How it works

  1. Derive an extra key from the final chaining value, reserved for the confirmation message.
  2. The initiator sends a small authenticated-encryption ciphertext under that key; the responder accepts the session only if it decrypts.
  3. The change costs at most five extra symmetric key operations and no extra round trip, because the responder already had to wait for initiator traffic before sending data safely.
  4. The proof reduces security to the pseudorandomness of HKDF, the integrity of the AEAD scheme, two symmetric variants of the PRF-ODH assumption, and decisional Diffie-Hellman, all in the standard model.

What to watch for

The theorem is about the modified protocol, not about WireGuard as specified, and the PRF-ODH style assumptions are tailored to protocol analysis rather than being ordinary textbook assumptions; the authors note that gap-DH in the random oracle model is an alternative route.

Useful background: The eCK-PFS-PSK security model, A key-recovery attack on forward secrecy.

Related ideas

Papers

The modular proof: extracting a KEM and CCCA security

The handshake is rewritten as a labelled key-encapsulation mechanism whose encapsulation output is the client response and whose key bundles the application key together with both Finished values; proving this KEM IND-CCCA secure, plus a secure record cipher, yields security of the whole protocol.

Why it is useful

Modularity is what makes the analysis systematic: one theorem covers every TLS mode, and each mode only needs its own KEM argument rather than its own full-protocol proof.

How it works

  1. Abstract the handshake into a KEM; each TLS mode is one instantiation of it.
  2. Use constrained-CCA security: a decryption oracle that only answers when an auxiliary value, the encrypted client Finished message, passes a validity predicate, so a rejection never reveals which part failed - matching the Bleichenbacher fix.
  3. The challenge ciphertext in the CCCA game comes without its Finished message; this asymmetry between the challenge and oracle queries is what lets the proof bypass the key indistinguishability barrier.
  4. The hard step is a relaying adversary that mauls the encrypted client Finished message; the proof exploits the real-or-random key from the CCCA game to check it.
  5. The KEM key must include the Finished values: using MS as the KEM key would make the TLS-RSA derived scheme insecure.

What to watch for

The theorem also needs the certificate authority signature to be unforgeable and assumes the CA checks identity but nothing about the form of keys.

Useful background: Why TLS resisted standard key-exchange models, Bleichenbacher attack and the hidden-failure countermeasure.

Papers

The security proof and its assumptions

KEMTLS is proven secure in a multi-stage authenticated-key-exchange model adapted from the TLS 1.3 analysis, in the standard model.

Why it is useful

It shows the KEM-based handshake reaches the same style of guarantee as signed-Diffie-Hellman TLS 1.3: indistinguishable stage keys, matching sessions, and explicit authentication, under stated assumptions.

How it works

  1. Authenticate with the long-term KEM: its IND-CCA security is what makes the implicitly authenticated secret hidden from an impersonator.
  2. Strengthen the ephemeral KEM to IND-1CCA (secure even given one decapsulation query), because the proof must answer one challenge ciphertext while simulating the server.
  3. Use HMAC unforgeability for the confirmation MACs, and hash collision resistance plus HKDF pseudorandomness for the key schedule.
  4. Note the reduction is non-tight due to hybrid and guessing arguments, as with earlier TLS 1.3 proofs.

What to watch for

Non-tightness means the theorem justifies the design rather than yielding concrete parameter margins; parameters still have to be chosen with the loss in mind.

Useful background: Implicit authentication and when it becomes explicit, Transcript binding in the key schedule.

Papers

The two layers of TLS: handshake and record protocol

TLS is one protocol made of two cooperating parts: a Handshake Protocol that authenticates the server and establishes keys, and a Record Protocol that uses those keys to protect the data sent afterwards.

Why it is useful

Knowing the split is the entry point to every result in the paper, because the security claim is about how the two halves work together rather than about either half alone.

How it works

  1. The client and server exchange hello messages carrying fresh random values and the server certificate.
  2. A key-establishment step delivers a shared pre-master secret; the deployed options are RSA encryption of that secret (TLS-RSA), Diffie-Hellman with a static server key (TLS-DH), or Diffie-Hellman with ephemeral keys on both sides (TLS-DHE).
  3. Both sides derive application keys from the pre-master secret and then encrypt everything else, including data, under those keys.

Example

Browsing https is the everyday case: the handshake sets up the keys once, and every page element you fetch afterwards travels inside the record layer.

What to watch for

The paper analyses the cryptographic core of TLS 1.2 as specified in RFC 5246; negotiation, resumption and extensions sit outside this core.

Related ideas

  • Authenticated key exchange: the task the handshake performs
  • Authenticated encryption and AEAD: the task the record layer performs

Papers

Ticket-granting and client-server exchanges

The second and third rounds. The client trades her ticket-granting ticket for a service ticket naming one server, then presents that service ticket to the server, optionally receiving a reply that authenticates the server back to her.

Why it is useful

This is what makes a single login scale: a day-long ticket-granting ticket can be exchanged repeatedly for service tickets that live minutes and work for one server only, so a leaked service ticket has little value and little reach.

How it works

  1. The client sends the ticket-granting ticket, an authenticator (her name and a time, encrypted under the key inside that ticket), the name of the server she wants, and a nonce.
  2. The ticket-granting server opens the ticket to recover the key, uses it to open the authenticator, and if its checks pass, invents a fresh session key for the client and the server.
  3. It returns the session key to the client encrypted under the key from the first round, plus the service ticket, which holds the same session key encrypted under a key shared with the chosen server.
  4. The client sends the service ticket with a new authenticator under the session key; the server can then answer with the time from that authenticator encrypted under the same key, which authenticates the server to the client.

What to watch for

The client treats the ticket-granting ticket as data she cannot inspect, and the ticket-granting server local policies, such as freshness checks, are not modelled.

Useful background: The Authentication Service exchange.

Papers

Transcript binding in the key schedule

Every key KEMTLS derives is a function of both the shared secrets and a hash of all handshake messages exchanged so far.

Why it is useful

Binding keys to the transcript means any change to the conversation produces different keys, so tampering cannot pass unnoticed; the final MACs then pin the exact transcript both sides saw.

How it works

  1. Feed each new shared secret and the running transcript hash through HKDF extract-and-expand steps, exactly like the TLS 1.3 key schedule.
  2. Give each stage a session identifier built from a label plus the transcript up to that point, so two sessions match only if they saw identical messages.
  3. Finish with HMAC under keys derived from the master secret, covering the transcript end to end.

What to watch for

The binding argument assumes the hash is collision resistant and HKDF behaves as a pseudorandom function; the proof states these as assumptions rather than deriving them.

Useful background: Authenticating a server with a KEM.

Papers

Transport keys, packet protection and key rotation

After the handshake the two derived keys protect IP packets with ChaCha20-Poly1305, an authenticated encryption scheme. Each packet carries an explicit sequence number and the receiver keeps a sliding window so that late or reordered packets are still accepted, while old packets cannot be replayed.

Why it is useful

Packet networks lose traffic and deliver it out of order; explicit counters give each packet a distinct place in the stream, and rotating the keys over time limits how much data any single key protects.

How it works

  1. Derive the two transport keys from the final chaining value of the handshake.
  2. Encrypt each IP packet with ChaCha20-Poly1305, with its sequence number carried as part of the packet processing.
  3. The receiver tracks a sliding window of acceptable sequence numbers, which tolerates delay and reordering while rejecting replays.
  4. Key rotation is the mechanism that replaces the transport keys over time; the paper says such mechanisms exist but does not analyse them, so their details are not covered here.

What to watch for

The paper proves security for the handshake only. It states plainly that it did not analyse WireGuard's key rotation mechanisms, so nothing here certifies how or when transport keys are replaced.

Useful background: WireGuard, Chaining values and transcript hashes in WireGuard.

Related ideas

  • Authenticated encryption and AEAD: the protection applied to each packet

Papers

What is proven for Kerberos, and what is not

Two properties are proved symbolically for both basic Kerberos and the public-key version: the session key made by the ticket-granting server stays secret from the intruder, and a completed run implies the expected earlier steps really happened. Computationally, authentication holds, but full computational key secrecy does not.

Why it is useful

It tells an implementer which guarantee survives contact with real encryption: an attacker cannot impersonate users or servers, yet the session key does become distinguishable from random once the final round begins.

How it works

  1. Symbolic secrecy: if the ticket-granting server makes a key for an honest client and server, the intruder never learns it.
  2. Symbolic authentication: if a server completes a run apparently with a client, that client really started with an authentication server and then requested a service ticket; if a client completes a run, the server really sent its reply.
  3. Computational authentication: implemented with provably secure primitives, both protocols meet these requirements with overwhelming probability.
  4. Computational secrecy: the session key can be told apart from a fresh random key only between the second and third round. Once the third round uses it to encrypt a message the attacker can predict, namely a client name and a time, the attacker can distinguish the real key from a random one by decrypting and checking the time window. An optional sub-session key that is never used inside the protocol does stay computationally secret.

What to watch for

The authentication proved is entity authentication only; because timestamps are not modelled, guarantees that depend on the purpose of timestamps are out of reach.

Useful background: Lifting the symbolic proof to real cryptography, Ticket-granting and client-server exchanges.

Papers

What the modular analysis does and does not establish

The analysis proves that the cryptographic core of TLS-RSA, TLS-CCA, TLS-DH and TLS-DHE provides server authentication, client authentication when enabled, and a secure channel - while leaving negotiation, resumption, compression, extensions, forward secrecy and side channels outside the guarantee.

Why it is useful

Reading a proof as a map of both coverage and blind spots is the practical lesson: the theorems rule out many attacks, explicitly not all, and the paper lists which features could still interact badly with the core.

How it works

  1. Covered: the four key-establishment modes, server-only and mutual authentication, and channel security under an sLHAE-secure record cipher, with the Bleichenbacher countermeasure validated inside the full protocol.
  2. Not covered: ciphersuite negotiation and downgrade, renegotiation, session resumption, compression and fragmentation, TLS extensions, and forward secrecy beyond what earlier work gives.
  3. Model restrictions: corruptions are non-adaptive, honest parties stay honest for the whole game, and there is a single error message.
  4. The TLS-RSA proof assumes no side channel reveals decryption failures, which the authors call a non-robust property favouring CCA-secure encryption or Diffie-Hellman modes.
  5. Design guidance: separate key exchange from channel use so each part can be analysed alone, and derive separate keys for handshake authentication, application data and resumption instead of reusing the master secret.

What to watch for

Security of TLS-RSA is also somewhat accidental: had the client Finished message been omitted or sent after the server Finished message, TLS-RSA would be completely insecure, while the other modes would not be affected.

Useful background: The modular proof: extracting a KEM and CCCA security, Per-mode assumptions: OW-PCA, IND-CCA and PRF-ODH, Record-layer and negotiation attacks around the analysis.

Papers

Why post-quantum authentication is the harder half

Making TLS quantum-safe has two halves: protecting the session key (key exchange) and proving who you are talking to (authentication). Almost all real deployments so far only did the first half.

Why it is useful

Post-quantum signature schemes transmit much more data than post-quantum KEMs do, and authentication data travels inside certificates that are sent on every single handshake, so the size penalty is paid constantly.

How it works

  1. Compare object sizes: a signature plus its public key is typically far larger than a KEM ciphertext plus its public key.
  2. Notice that hybrid experiments mostly swapped only the key exchange, leaving certificates classical.
  3. Observe that switching authentication to anything post-quantum forces new certificates either way, which removes the usual deployment argument for keeping signatures.

What to watch for

Hybrid "transitional" deployments gain quantum-resistant confidentiality, but their authentication still rests on classical signatures, so a quantum attacker who can forge those signatures could impersonate servers; authentication only becomes post-quantum when certificates change.

Related ideas

  • TLS 1.3: the handshake being replaced

Papers

Why this exchange is unauthenticated on purpose

The design leaves authentication out so key exchange and signatures can evolve independently.

Why it is useful

Post-quantum confidentiality was judged urgent for stored transcripts, while pre-quantum signatures already authenticate sessions without weakening past traffic.

How it works

  1. Run the unauthenticated exchange for the session key.
  2. Authenticate it with a classical or hash-based signature at the protocol layer.
  3. Parameter choices for each part stay independent.

What to watch for

A hybrid deployment still trusts today’s signatures for identity; future compromise of those signatures breaks authentication of past handshakes, though not the exchanged keys.

Useful background: Ring-LWE key exchange as a KEM.

Related ideas

  • Transport layer security: the deployment target
  • Hash-based signatures: the suggested authentication pair

Papers

Why TLS resisted standard key-exchange models

The application key encrypts the last two handshake messages (the Finished messages), so the record layer switches on before the handshake ends; classical key-exchange models that demand the session key stay indistinguishable from random therefore declare the real TLS handshake insecure.

Why it is useful

It explains why a decade of proofs analysed modified protocols instead: truncated handshakes with unencrypted Finished messages, or RSA replaced by CCA-secure encryption that RSA PKCS #1v1.5 does not provide.

How it works

  1. The overlap means the adversary sees encryption under the key it is supposed to distinguish from random, breaking key indistinguishability.
  2. Earlier modular analyses removed the encryption of the Finished messages, so their results apply to truncated TLS, not to the deployed protocol.
  3. Other analyses assumed RSA PKCS #1v1.5 is IND-CCA secure, an assumption that is provably false, so they say little about TLS in use.

What to watch for

The paper treats this overlap as a design flaw, not just a proof obstacle: layering the handshake on top of a record layer that activates mid-handshake entangles two functions that should be separate.

Useful background: The two layers of TLS: handshake and record protocol, One master secret feeds every handshake key.

Papers

WireGuard

WireGuard is a virtual private network (VPN) protocol: it builds an encrypted tunnel for internet traffic by wrapping each IP packet inside a UDP packet protected by authenticated encryption. It was designed as a replacement for IPsec and OpenVPN that needs far less code.

Why it is useful

A VPN has to carry packets across a network you do not control, and the established alternatives were large and hard to review; WireGuard fits in under 4,000 lines, which makes the whole design small enough for one person to read and audit.

How it works

  1. Each device owns one long-term Diffie-Hellman key pair; there is no certificate authority, so keys are configured in advance or accepted on first use, as in SSH.
  2. Peers are selected by matching IP address ranges, and each range is tied to a static public key, which replaces the Security Association and Security Policy databases that IPsec needs.
  3. The protocol has two phases: a handshake that agrees on fresh session keys, and a data transport phase that uses those keys to protect the actual IP packets.
  4. The protected UDP packets travel inside ordinary IP packets, so the extra header cost per packet stays small.

Example

A laptop and an office gateway each store the other's public key; after one handshake, packets addressed to the office network travel encrypted inside UDP.

What to watch for

This lesson describes the design as the paper states it for the 2017 specification; it says nothing about any particular implementation, and because there is no certificate authority the long-term keys carry the entire trust load.

Related ideas

  • Authenticated key exchange: the handshake phase that sets up the tunnel keys
  • OpenVPN and IPsec: the older tunnelling protocols WireGuard was written to replace

Papers

Commitments and authenticated data

A commitment lets you fix a value now and reveal it later without being able to change it. Authenticated data structures let someone check an answer against a trusted summary of a larger collection.

Authenticated data structures and query answers

Data structures that authenticate stored values and query results. Integrity does not itself provide query privacy, availability or retrievability.

Merkle authentication paths

A Merkle authentication path contains the sibling hashes needed to connect one leaf to a tree's root. A verifier recomputes the path using the leaf's position and checks the resulting root against a trusted value.

Why it is useful

A small root can authenticate one selected value without sending the entire tree. Hash-based signatures use this to authenticate the one-time key used for a signature.

How it works

  1. Hash the leaf value using the specified encoding.
  2. Combine it with the sibling at the next level in the correct left-right order.
  3. Repeat with the remaining path nodes.
  4. Compare the final value with the trusted root.

What to watch for

The leaf index, tree shape, hash inputs and root binding matter. Supplying an arbitrary root together with a path does not establish that the leaf belongs to the intended tree.

Related ideas

Papers

Authenticated sequences and structured queries

Append-oriented sequences, consistency proofs, ordered ranges and aggregate query answers. Log governance and distributed availability remain system topics.

Merkle Mountain Range commitments

Merkle Mountain Range commitments authenticate an append-oriented sequence using a collection of trees.

Papers

Authenticated trees, dictionaries and zero-knowledge sets

Hash- or commitment-based trees and maps, including sparse structures and privacy-preserving membership interfaces. Zero-knowledge sets need privacy properties beyond a tree digest.

Authenticated proofs of absence

A proof of absence establishes that a requested key has no entry in a particular authenticated directory snapshot.

Why it is useful

A server's unsupported claim that a name is missing is insufficient when it may be hiding a record or changing lookup results.

How it works

  1. Compute and verify the requested name's index.
  2. Follow its prefix path until reaching an authenticated empty node or a different leaf.
  3. Verify that this node really rules out the requested index under the tree's rules.
  4. Recompute the root and compare it with the trusted snapshot.

What to watch for

The claim concerns the committed snapshot, not all possible epochs or providers. A stale root can authenticate an obsolete absence result. The proof must establish the path relationship, not merely show some other leaf.

Useful background: Merkle prefix trees.

Papers

Cuckoo commitments

Cuckoo hashing converts vector commitments into commitments to key-value maps.

Papers

Curve Trees

Curve Trees combine shallow Merkle trees and elliptic-curve cycles for set-membership proofs.

Papers

KVaC

KVaC commits to key-value maps using groups of unknown order and supports additive value updates.

Papers

Merkle commitments

Merkle commitments encode authenticated values in a hash tree.

Papers

Merkle prefix trees

A Merkle prefix tree organizes records by the bits of their indices. Child hashes authenticate the tree, while each branch identifies a longer bit prefix.

Why it is useful

One root can authenticate many directory entries, and a client can check one entry without downloading the whole directory.

How it works

  1. Follow successive index bits through the tree.
  2. Stop at an empty prefix or a leaf whose index has become unique among stored entries.
  3. Hash leaf records and combine child hashes toward the root.
  4. Provide the requested path plus sibling hashes so the client can recompute the root.

What to watch for

Hash encodings must distinguish node kinds and bind the index, depth and record. CONIKS also includes the username in the leaf commitment so an index collision cannot make one name's record a valid binding for another. Tree shape and path length can reveal structural information.

Useful background: Merkle authentication paths, Unambiguous encoding.

Papers

UltraFold

UltraFold distributes BaseFold using packed interleaved Merkle trees.

Papers

Verkle commitments

Verkle commitments use vector commitments in a tree-shaped authenticated data structure.

Papers

Commitment security, trapdoors and composition

Hiding and binding variants, extraction, equivocation, mercurial interfaces, non-malleability and selective-opening security. Trapdoor capabilities and setup are explicit security choices.

Binding and hiding of the LPN commitment

The LPN commitment is perfectly binding, meaning no commitment can be opened to two different messages, and computationally hiding, meaning the commitment looks random to anyone who cannot solve the LPN problem. Binding holds with overwhelming probability over the random choice of the public matrix.

Why it is useful

These are the two properties every commitment needs. Here they come from different sources: binding from the geometry of a random linear code, hiding from a hardness assumption, so one property is unconditional and the other is not.

How it works

  1. Choose k of order ℓ + v so that, with overwhelming probability, the random matrix A generates a code whose nonzero codewords all have weight above 2w.
  2. Suppose one commitment c opens as (m, r) and as (m′, r′). The difference of the two errors then equals A applied to the difference of the openings, so it is a codeword.
  3. Each error has weight at most w, so their sum has weight at most 2w, which contradicts the distance property unless the two openings are the same.
  4. For hiding, split A into A′ and A′′: the commitment is A′.r ⊕ e ⊕ A′′.m, and A′.r ⊕ e is pseudorandom under xLPN, so the whole commitment is pseudorandom.

What to watch for

Binding is unconditional but only for the matrix actually sampled; a bad matrix, which occurs with negligible probability, would allow two openings. Hiding is computational and rests on the xLPN assumption.

Useful background: LPN string commitment, Minimum distance of a linear code.

Papers

Lattice mercurial vector commitments

This construction equips lattice-based mercurial vector commitments with updates and aggregation.

Papers

Mercurial commitments

Mercurial commitments are commitment variants used in constructing zero-knowledge sets.

Papers

What Bulletproofs give up

The short proofs rest on commitments that are perfectly hiding and only computationally binding, verification is linear rather than constant, and the discrete log assumption fails against quantum attackers.

Why it is useful

Compressing a long vector into one group element is only possible for hiding commitments, so the size advantage and perfect binding cannot be had together.

How it works

  1. Accept that a prover who breaks discrete log could open a commitment outside the range; for currencies this is the more dangerous direction compared to losing privacy.
  2. Note that verification and proving time grow with the number of bits even though the proof does not, though batching makes the marginal verification cost small in practice.
  3. Publish an extra group element that commits to the hiding randomness, turning each Pedersen commitment into an ElGamal style one, so the scheme can later be switched to a quantum-secure, perfectly binding variant.
  4. Rely on the fact that over a small message space a bounded prover cannot build a commitment that an unbounded adversary could later open to a different value.

What to watch for

Perfectly binding and perfectly hiding are mutually exclusive, so the switch to quantum-secure proofs costs computational hiding, and succinct quantum-secure range proofs remained open at the time of the paper.

Useful background: Pedersen commitments and their vector form, Logarithmic range proofs and aggregation.

Related ideas

Papers

Commitments to messages and structured values

A commitment scheme lets a party publish a sealed value and open it later. This paper builds one by encoding the message with a random linear code and adding noise, then adds proofs of knowledge of an opening and proofs of relations among committed messages.

ABBA

ABBA constructs homomorphic commitments from sums of quaternion commutators.

Papers

All-but-one vector commitments

An all-but-one vector commitment opens every position except one selected position.

Papers

BACON

BACON uses a large correlated GGM tree and an abort mechanism for batched all-but-one commitments.

Papers

BalanceProofs

BalanceProofs provides vector opening updates and aggregation with a bucketing variant.

Papers

Batched all-but-one vector commitments

Batched AVCs combine multiple all-but-one commitments using a shared GGM tree.

Papers

BORG

BORG combines a sparse vector commitment with a reconfigurable coded storage layer.

Papers

Cauchyproofs

Cauchyproofs supports batched vector-proof updates using a Cauchy-matrix representation of KZG proofs.

Papers

ElGamal commitments

ElGamal commitments use a group-based encryption form for committed messages.

Papers

Grand Danois

Grand Danois modifies Hachi with structured commitments and sumcheck-based verification.

Papers

HACC

HACC arranges capacity-bounded pairing accumulators over ordered buckets in a tree.

Papers

Hiding and binding commitments

A commitment fixes a value while concealing it until an opening is supplied. Hiding protects the value; binding prevents the committer from opening the same commitment as two different values.

Why it is useful

CONIKS needs to authenticate a directory record without revealing the record's contents through every neighboring lookup proof.

How it works

  1. Commit to the username and its key data using fresh secret randomness.
  2. Place the commitment, rather than the clear record, in the authenticated tree.
  3. For an authorized lookup, return the record and the information needed to open the commitment.
  4. Check both the opening and the tree authentication path.

What to watch for

A bare hash of predictable key data can be tested against guesses. A randomized hash commitment needs an appropriate hiding assumption as well as binding; collision resistance alone does not imply hiding. The record must be encoded unambiguously.

Related ideas

  • Merkle prefix trees: Authenticate commitments without themselves supplying the hiding property.

Papers

HydraProofs

HydraProofs produces vector openings compatible with multilinear-encoded proof systems.

Papers

Hyperproofs

Hyperproofs organizes vector opening proofs into a maintainable tree and supports aggregation.

Papers

Incrementally aggregatable vector commitments

These vector commitments allow openings to be merged repeatedly and generated by distributed parties.

Papers

Matproofs

Matproofs extends vector commitments to matrices.

Papers

Morphic accumulators

Morphic accumulators encode set elements by discrete-logarithm maps before unknown-order accumulation.

Papers

Orbweaver

Orbweaver evaluates linear functions on committed vectors over cyclotomic rings and integers.

Papers

Pointproofs

Pointproofs supports aggregation of opening proofs across independently computed vector commitments.

Papers

Proving bitwise relations with masked vectors

A protocol that proves m3 = m1 ∘ m2 for any bitwise operation ∘ such as AND, NAND, OR or NOR between committed messages. It turns the bitwise question into a linear one by hiding the real messages inside longer, randomly arranged copies of them.

Why it is useful

NAND by itself can express any Boolean function, so this protocol is what makes statements about arbitrary circuits possible.

How it works

  1. The prover builds three strings of length 4v: m̃1, m̃2 and m̃3 = m̃1 ∘ m̃2, arranged so that each of the four bit pairs (0,0), (0,1), (1,0) and (1,1) occurs exactly v times.
  2. It picks a secret selection matrix R with exactly one 1 per row that maps each m̃i to the real message mi, so R is a permutation matrix extended with zero columns.
  3. The prover commits to R and to the m̃i, then runs the linear-relation protocol to prove R.m̃i = mi without naming R to the verifier.
  4. One additional challenge opens the m̃i so the verifier can check m̃3 = m̃1 ∘ m̃2 directly; because the four bit pairs are balanced, the opened strings are uniformly random and reveal nothing about the messages.
  5. The weight-checking challenge does not need R, so it is merged with the additional challenge and R stays hidden.

What to watch for

Neither R nor the m̃i may be revealed together with the values they determine: each one alone is independent of the messages, but both together fix them. The challenge structure is arranged so that no run opens both.

Useful background: Proving linear relations among committed messages.

Papers

Proving circuit relations over committed values

A method to prove that committed values satisfy m0 = C(m1, . . . , mu) for any Boolean circuit C, by committing to the value on every layer of the circuit and proving each layer with the linear or the bitwise protocol. The cost grows almost linearly in the message length times the circuit size.

Why it is useful

It avoids the generic route of rewriting an arbitrary statement as 3-colouring or a Hamiltonian cycle, which inflates the circuit before any proof starts, and it works directly on the committed bits.

How it works

  1. Write the circuit in layers C1 through Cd, where each layer is either a linear map or a bitwise operation such as NAND.
  2. Commit to the string of values on every layer: the input layer, each intermediate layer and the output layer.
  3. Prove each transition xi+1 = Ci(xi) with the linear protocol or the bitwise protocol.
  4. To prove knowledge of a witness, commit to the witness and to the constant 1 and prove that the circuit applied to the witness outputs 1.
  5. Cost: for soundness exponentially small in a parameter t, communication is O(t|C|ℓ log ℓ) bits and computation is O(t|C|ℓ) bit operations, mostly inner products of bit vectors; a single proof is quasilinear, Θ(k log k), in the length of the committed message.

Example

As an illustration of the intended use, one can prove that committed values satisfy m0 = AES(m1,m2), that is, that m0 is the output of the AES block cipher under key m1 on input m2.

What to watch for

The soundness error of one run is 2/3, so reaching the 2−16 or 2−32 error levels named in the ISO/IEC-9798-5 standard takes 28 or 55 parallel repetitions. The hidden constants are small, but the proofs are not short in absolute terms.

Useful background: Proving linear relations among committed messages, Proving bitwise relations with masked vectors.

Papers

Proving linear relations among committed messages

A protocol that proves three committed messages satisfy m3 = X1.m1 ⊕ X2.m2 for any binary matrices X1 and X2 named in the statement. It runs the opening protocol three times in parallel under one shared challenge, and checking the relation comes almost for free.

Why it is useful

Linear checks are the workhorse: complementing bits, xoring sums of messages and regrouping bits are all linear, and the protocol for bitwise operations is built on top of this one.

How it works

  1. Run three copies of the opening protocol with the same challenge, using masks v1 and v2 for the first two messages.
  2. Instead of choosing the third mask at random, define v3 = X1.v1 ⊕ X2.v2.
  3. On challenge 0 the verifier checks v3 = X1.v1 ⊕ X2.v2 on the opened masks, and on challenge 1 it checks the same relation on the masked messages.
  4. Answers to both challenges then yield openings that satisfy the relation, not merely openings of the three commitments.
  5. Affine statements follow by shifting a commitment: y ⊕ A.(0‖x) is a commitment to m ⊕ x with the same randomness and error.

Example

Taking X1 as the identity and X2 as the all-ones matrix states that m1 is the bitwise complement of m2.

What to watch for

The proof convinces only for the linear relation that is announced, and the verifier learns that this relation holds, which is the statement. Soundness per run is still 2/3, so repetitions are needed.

Useful background: Zero-knowledge proof of a commitment opening.

Papers

RSA-B accumulator

RSA-B is the second RSA-based accumulator reviewed for credential revocation.

Papers

Switch commitments

Switch commitments provide a conversion operation on previously recorded commitments.

Papers

Universal vector commitments

Universal vector commitments provide membership and non-membership openings.

Papers

Vector commitments with smallness proofs

This vector commitment supports proofs that entries are binary, ternary or norm-bounded.

Papers

Vector semi-commitments

Vector semi-commitments relax the conventional commitment interface for MPC-in-the-head constructions.

Papers

Zero-knowledge proof of a commitment opening

A three-move protocol, of the kind called a Sigma-protocol, in which the owner of a commitment convinces a verifier that it knows a valid opening: the randomness, the message and an error of the right weight, without revealing them. The prover first sends commitments, the verifier answers with one of three challenges, and the prover opens part of what it sent.

Why it is useful

It is the base case for every other proof in the paper. A direct copy of Schnorr's three-move identification protocol fails here, because the answer either leaks the error or lets a cheater answer every challenge, so the design hides the error's positions behind a random permutation.

How it works

  1. The naive copy commits to t0 = A.v ⊕ f, then opens t0 on challenge 0 and t0 ⊕ y on challenge 1. With a low-weight f the answer leaks e; with a uniformly random f a cheater can satisfy both challenges using an error of any weight.
  2. The fix, taken from Stern's syndrome decoding protocol, is to also commit to a random permutation π of the k error positions, together with π(f) and π(f ⊕ e).
  3. Challenge 0 opens the first commitment and π(f); the verifier checks that the difference lies in the image of A and that π is a genuine permutation.
  4. Challenge 1 opens the first commitment and π(f ⊕ e); the verifier checks that the difference with y added lies in the image of A.
  5. Challenge 2 opens π(f) and π(f ⊕ e); the verifier checks that their difference, which is the permuted error, has weight exactly w.
  6. Answers to all three challenges pin the secret: the first two give y = A.s′ ⊕ π′−1(t1 ⊕ t2), and the third bounds the weight of that error.

What to watch for

A single run catches a cheating prover only two times out of three, so the protocol must be repeated in parallel, and the base protocol simulates only an honest verifier. The opened permutations reveal nothing about e beyond its weight, which is why the weight has to be fixed.

Useful background: LPN string commitment, Sigma-protocols.

Related ideas

  • Stern syndrome decoding proof: the permutation trick is borrowed from this earlier zero-knowledge proof for code decoding

Papers

Bit, scalar, integer and group-element commitments

Commitment to individual values, including strings and group elements. Separate the committed domain from the algebra used to implement it.

Damgard-Fujisaki integer commitments

Damgard-Fujisaki commitments support committed integer values.

Papers

Fujisaki-Okamoto integer commitments

The Fujisaki-Okamoto construction commits to integers in groups of hidden order.

Papers

Groth-Sahai commitments

Groth-Sahai commitments encode scalars or group elements for algebraic proof relations.

Papers

Homomorphic group-element commitments (2009)

This construction commits directly to vectors of group elements using bilinear maps.

Papers

Inner-product functional commitments over small integers

These functional commitments open inner products over small integer vectors using unknown-order groups.

Papers

Integer inner-product commitments (2025)

These commitments open two integer vectors to their claimed inner product.

Papers

LPN string commitment

A commitment to a message m is the value A.(r‖m) ⊕ e, where A is a public random binary matrix, r is fresh random bits and e is a random error vector of a fixed weight w. To open, the committer reveals r and m, and anyone can subtract A.(r‖m) from the commitment and check that the difference has weight exactly w.

Why it is useful

It gives the usual sealed-envelope behaviour, but the whole object is one matrix-times-vector product plus noise, so statements about the committed message stay cheap to prove.

How it works

  1. Key generation publishes a random binary matrix A with k rows and ℓ + v columns, where ℓ is the length of the randomizer r, v the message length and k grows with their sum.
  2. To commit, pick r at random, pick an error e of weight exactly w = ⌊τk⌋ for a noise rate τ below one quarter, and send A.(r‖m) ⊕ e.
  3. To open, reveal m and r; the verifier recomputes e′ = c ⊕ A.(r‖m) and accepts exactly when e′ has weight w.
  4. Choose ℓ so that LPN with secrets of that length is hard, and keep v roughly the size of ℓ for efficiency.

Example

Illustration only, not a secure choice: with ℓ = 8 and v = 8, a 16-bit opening (r, m) hides an 8-bit message inside a 20-bit commitment whose error has weight 2.

What to watch for

The message length and the noise rate trade off against commitment size; the paper gives asymptotic guidance, not concrete parameters.

Useful background: Learning parity with noise, Commitment schemes.

Related ideas

Papers

Naor bit commitment

Naor commitment is a bit-commitment construction used as the starting point for a quantum adaptation.

Papers

Neo pay-per-bit commitment component

Neo instantiates Ajtai commitments using the bit-width of committed scalars.

Papers

NOVY commitment

The Naor-Ostrovsky-Venkatesan-Yung construction is an interactive bit commitment.

Papers

Pedersen commitments and their vector form

A Pedersen commitment hides a number inside a group element, and a whole vector of numbers can be hidden inside one group element the same way.

Why it is useful

Adding two commitments adds the hidden numbers, which is what lets Bulletproofs combine many constraints and many parties into one object. The commitment is perfectly hiding but only computationally binding.

How it works

  1. To commit to one value, raise a base g to the value and a second base h to random hiding randomness, then multiply.
  2. To commit to a vector, use one base per coordinate plus one extra base for the randomness; the product of all the powers is a single group element.
  3. Because the bases are independent group elements, opening the commitment to two different vectors would reveal a discrete logarithm relation between them, which is assumed hard.
  4. Anyone can reinterpret the same group element as a commitment to a different but related vector by changing the bases, for example rescaling each coordinate.

Example

With bases g1,g2 and h, the group element h^r times g1^3 times g2^5 commits to the vector (3,5) and reveals nothing about it.

What to watch for

Perfectly hiding means even an unbounded attacker learns nothing about the value; computationally binding means a computationally bounded attacker cannot open it two ways. Both at once are impossible, so the design picks hiding and accepts that binding rests on discrete log.

Related ideas

  • Bulletproofs: Uses these commitments as the statements it proves things about.

Papers

Range proofs from bit constraints

A value lies in a range exactly when it can be written as bits, and the bit conditions turn into three vector equations that one random linear combination merges into a single inner product identity.

Why it is useful

It avoids writing the commitment opening itself as a circuit, which would be huge, because the Pedersen commitment already lives in the same group the inner product argument uses.

How it works

  1. Write the value in binary as a vector of zeros and ones, and define a second vector that is the first minus one in every coordinate.
  2. The bit conditions become: the value equals the inner product of the bit vector with the powers of two, the two vectors multiply coordinate-wise to zero, and the second vector equals the first minus one everywhere.
  3. A random challenge from the verifier turns each zero-vector condition into a single inner product with a powers vector, which fails with only tiny probability if the vector is not zero.
  4. A second random challenge combines the three conditions into one inner product identity whose right side the verifier can compute from public values and the commitment.

Example

For a 64-bit range the bit vector has 64 entries and the powers vector is 1, 2, 4, ..., 2 to the 63.

What to watch for

The random combination only catches cheating with high probability, not certainty, and the range must be an interval whose width is a power of two unless extra tricks are used.

Useful background: Pedersen commitments and their vector form, Committing to a vector and its inner product in one group element.

Related ideas

  • Pedersen commitments: The committed value whose range is being proved.

Papers

Vector commitments over modular rings

This construction supports homomorphic vector commitments modulo a positive integer.

Papers

Functional commitments and committed functions

Open a function of committed data, or prove evaluations of a committed function. These are distinct interfaces and do not grant decryption rights as functional encryption does.

Dew PCS component

The commitment underlying Dew uses inner-product commitments in groups of unknown order.

Papers

Functional commitments to data

A functional commitment to data opens a chosen function of the committed message.

Papers

Functional commitments to secret functions

This commitment family commits to a function and supplies proofs of its input-output evaluations.

Papers

Linear map commitments

A linear map commitment opens the image of a committed vector under a linear map.

Papers

Testudo PCS component

The Testudo commitment component combines PST-style multivariate commitments with inner-pairing products.

Papers

Two-tier commitments for inner-product proofs

Two-tier commitments separate inner vector commitments from an outer commitment protocol.

Papers

Vector, matrix and subvector commitments

A vector commitment compresses a whole list of field elements into one group element, with one base per coordinate. Bulletproofs treat the group element produced by the inner product folding as such a commitment, and reinterpret it under rescaled bases to obtain commitments to related vectors without recomputing anything.

2D-Xproofs

2D-Xproofs is a two-dimensional matrix commitment supporting proof aggregation.

Papers

3D-Xproofs

3D-Xproofs uses a three-dimensional matrix commitment to support opening-proof updates.

Papers

Ajtai commitments

Ajtai commitments are lattice-based commitments used by folding constructions such as Neo.

Papers

aSVC

The aSVC construction derives aggregatable subvector proofs from polynomial commitments.

Papers

Committing to a vector and its inner product in one group element

The statement proved is not just that a group element opens to two vectors, but that those two vectors have a claimed inner product, and the claim is folded into the same group element using one extra base.

Why it is useful

An inner product is one number that summarizes a whole quadratic relation between two vectors, so proving one inner product correctly can carry many simpler constraints at once.

How it works

  1. Start from a group element built from two independent base vectors and the two witness vectors.
  2. Multiply in one more base u raised to the inner product of the two vectors.
  3. The resulting group element commits to both vectors and to their inner product simultaneously.
  4. A separate short step forces the inner product to equal a public value by raising u to a verifier chosen power.

What to watch for

The witness vectors themselves are not hidden by this argument; it gives soundness only. Zero knowledge has to be added around it by the protocols that use it.

Useful background: Pedersen commitments and their vector form.

Related ideas

  • Bulletproofs inner-product argument: The recursive protocol that proves this relation in logarithmic size.

Papers

Subvector commitments

A subvector commitment opens a set of positions in a committed vector.

Papers

Vector commitments

A vector commitment exposes values at specified positions of an ordered committed sequence.

Papers

Polynomial commitment interfaces

A polynomial commitment lets a prover publish a short digest of a polynomial and later convince a verifier that it evaluates to a claimed value at a chosen point, without sending the whole polynomial. Dory stores the coefficient tensor as a square matrix inside a two-tiered homomorphic commitment, then reduces the evaluation check to two inner products of about square-root length, which its folding argument proves with logarithmic communication and verifier work.

Behemoth

Behemoth is a polynomial commitment scheme with an evaluation-proof protocol.

Papers

Binary-tower Brakedown PCS component

This Brakedown adaptation commits to multilinear polynomials over tiny binary fields.

Papers

Bird

Bird composes sumcheck-related functional building blocks into a polynomial commitment.

Papers

Blaze PCS

Blaze commits to multilinear polynomials over binary fields using code switching and RAA codes.

Papers

Bolt PCS

Bolt is a multilinear commitment built using code switching and sketched codes.

Papers

Boomy

Boomy extends multivariate commitments with batch openings at multiple evaluation points.

Papers

Brakedown PCS component

The Brakedown commitment component uses an encodable linear code.

Papers

BrakeFold

BrakeFold instantiates SwitchFold with Brakedown codes.

Papers

BrakingBase

BrakingBase combines Brakedown commitments with BaseFold and sumcheck-based evaluation checks.

Papers

Carina

Carina applies a constant-term reduction in each coordinate and opens a bivariate point grid.

Papers

CELPC

CELPC is a lattice-based polynomial commitment used as a basis for Jindo.

Papers

DARK PCS

DARK commits to polynomials using integer representations and groups of unknown order.

Papers

DeepFold

DeepFold is a Reed-Solomon-based multilinear commitment with a batch evaluation construction.

Papers

DEPIPFRI

DEPIPFRI distributes a single polynomial across provers as a variant of PIPFRI.

Papers

DewTwo

DewTwo is a multilinear polynomial commitment using groups of unknown order.

Papers

Dolphin

Dolphin is the multilinear commitment in the Orca and Dolphin construction.

Papers

Dual polynomial commitments

Dual commitments link witnesses represented in univariate and multilinear commitments.

Papers

Equifficient polynomial commitments

Equifficient commitments link polynomial representations in designated bases.

Papers

Flare PCS

Flare combines expand-accumulate codes with code switching and interleaved-code folding.

Papers

FRI-Binius

FRI-Binius is the polynomial commitment used by the FRIVail data availability construction.

Papers

From polynomial evaluation to a vector-matrix-vector product

Rewrite any polynomial as a multilinear one by giving each power of a variable its own new variable, flatten the coefficient tensor into an approximately square matrix, and evaluate as a row vector times that matrix times a column vector.

Why it is useful

This converts an evaluation proof into two inner products of length about the square root of the number of coefficients, which is the shape the folding argument proves efficiently. The two outer vectors inherit multiplicative structure from the evaluation point.

How it works

  1. Replace each power of a variable by a fresh variable so the polynomial becomes multilinear.
  2. Flatten the coefficient tensor into a matrix, choosing the split so the matrix is close to square.
  3. Build the left and right outer vectors as Kronecker products from the evaluation point.
  4. Prove the vector-matrix-vector claim with the matrix commitment and the inner-product argument.

Example

A bivariate polynomial in powers of two variables becomes a four-variable multilinear polynomial whose two-by-two-by-two-by-two coefficient tensor flattens into a four-by-four matrix with one entry per monomial.

What to watch for

The proof system comes in two strengths. The basic variant only gives random evaluation extractability: the prover shows it can open the polynomial at a point the verifier samples after the commitment is published, which suffices when the surrounding protocol fixes the point late anyway. The full variant additionally opens at a random challenge point and is stated as an extractable polynomial commitment; the extra opening roughly doubles the work.

Useful background: The commitments Dory builds on, Structured verifier work: key symmetry and multiplicative structure.

Papers

Galois-ring BaseFold variant

This variant extends foldable codes and BaseFold commitments to multilinear polynomials over Galois rings.

Papers

Greyhound

Greyhound composes a lattice polynomial evaluation protocol with LaBRADOR.

Papers

HyperKZG

HyperKZG adapts Gemini for multilinear polynomial commitments.

Papers

Hyrax PCS component

The Hyrax construction includes a commitment scheme for multilinear polynomials.

Papers

InfoCommit

InfoCommit uses private two-party computation in its commitment phase to create a verifier key.

Papers

Inner-pairing-product PCS (2019)

This commitment construction applies generalized inner-pairing-product arguments to polynomial evaluation.

Papers

Jagged PCS

Jagged commitments stack differently sized trace tables while exposing their individual polynomial views.

Papers

Jindo

Jindo builds a lattice-based multilinear evaluation protocol on CELPC and Greyhound.

Papers

KZH

KZH is a multilinear polynomial commitment used as a component of KZH-Fold.

Papers

Lattice PCS (2024/281)

This lattice commitment provides an interactive evaluation protocol with a Fiat-Shamir version.

Papers

LiftWHIR

LiftWHIR combines interleaved coding, DEEP and WHIR for polynomial evaluation proofs.

Papers

Ligerito

Ligerito supports polynomial evaluation and inner-product commitments using linear codes.

Papers

LigeSIS

LigeSIS replaces Merkle hashing with a homomorphic subset-sum hash in a distributed code-based PCS.

Papers

Lightning PCS

Lightning uses its own code family within the Ligero-Brakedown commitment approach.

Papers

List polynomial commitments

A list polynomial commitment permits openings associated with a list of nearby low-degree polynomials.

Papers

Masked binary-field BaseFold variant

This variant applies Aurora-derived masking ideas to the Diamond-Posen binary-field commitment.

Papers

MERCURY

MERCURY uses univariate polynomial division to construct multilinear evaluation proofs.

Papers

Modified DARK PCS (2021)

This construction modifies DARK for time- and space-conscious proving.

Papers

Multi-polynomial commitments

A multi-polynomial commitment generalizes polynomial commitments to several polynomials.

Papers

Orion PCS component

The Orion commitment component extends Brakedown using Spielman codes.

Papers

PIPFRI

PIPFRI combines linear-code multilinear commitments with FRI.

Papers

QAFold

QAFold instantiates SwitchFold with quasi-Abelian codes.

Papers

QAPCS

QAPCS applies the Brakedown commitment approach directly to quasi-Abelian codes.

Papers

Quasar PCS (QA-code construction)

Quasar combines quasi-Abelian codes with BaseFold using code switching.

Papers

Ring-BASIS polynomial commitment (2023)

This lattice polynomial commitment uses ring-structured evaluation proofs.

Papers

SamaritanPCS

SamaritanPCS instantiates a univariate-to-multilinear commitment transformation with KZG.

Papers

Serval

Serval combines lattice polynomial evaluations with self-inner-product and binary norm checks.

Papers

SLAP

SLAP combines a lattice tree commitment with an FRI-inspired polynomial evaluation proof.

Papers

SmallWood PCS

SmallWood combines degree-enforcing commitments with techniques from Brakedown.

Papers

SwitchFold

SwitchFold recursively switches between codes of decreasing block lengths for polynomial commitments.

Papers

TensorSwitch

TensorSwitch constructs a multilinear commitment from tensor-code oracle protocols.

Papers

TFB-PC

TFB-PC provides polynomial commitment operations for both batch evaluation and batch opening.

Papers

The commitments Dory builds on

Dory uses two additively homomorphic commitments: Pedersen commitments to vectors of field elements, and the structure-preserving commitment of Abe, Fuchsbauer, Groth, Haralambiev and Ohkubo to vectors of group elements. Composing them gives a two-tiered homomorphic commitment to whole matrices.

Why it is useful

A polynomial is stored as a matrix, so the scheme needs a commitment that is homomorphic at both levels: scaling and adding rows, and scaling and adding commitments, must both preserve binding.

How it works

  1. Commit each row of the matrix with a Pedersen commitment, which is homomorphic in the row coefficients.
  2. Commit the resulting vector of row commitments with the structure-preserving commitment.
  3. The outer commitment lives in the target group; the inner ones live in a source group.
  4. Keep the vector of row commitments in the opening hint, because it speeds up evaluation proofs.

Example

A linear combination of the row commitments is itself a commitment to the same linear combination of rows, which is how the prover folds a matrix claim without touching the secret coefficients.

What to watch for

Hiding is statistical, but binding is only computational and rests on SXDH. Because the commitment key is a long vector of group points, the security argument needs those points to be unrelated, which is what the transparent sampling provides.

Useful background: Pedersen commitments.

Papers

Titan PCS

Titan combines Pedersen-style inner commitments with proximity protocols over groups.

Papers

Vela

Vela uses reciprocal-polynomial inversion symmetry and a univariate KZG opening.

Papers

Veloz-Lin

The linear-code instantiation of Veloz distributes a Brakedown-code multilinear commitment.

Papers

Veloz-RS

The Reed-Solomon instantiation of Veloz distributes a code-based multilinear commitment.

Papers

Vortex

Vortex is a list polynomial commitment derived by modifying Ligero.

Papers

Multivariate and multilinear evaluation commitments

Evaluation commitments in several variables, including multilinear tables, bivariate grids and joint commitments to multiple polynomials.

BaseFold

BaseFold commits to multilinear polynomials using foldable codes interleaved with sumcheck.

Papers

Bivariate KZG

A bivariate KZG scheme provides the underlying commitment used to instantiate CHOPIN.

Papers

CHOPIN

CHOPIN constructs multilinear commitments from a bivariate PCS and instantiates it with bivariate KZG.

Papers

CHOPIN bivariate-to-multilinear compiler

CHOPIN supplies a modular construction of multilinear commitments from a bivariate PCS.

Papers

Data-availability-derived multilinear PCS

This construction reuses encoded block data to support multilinear polynomial commitments.

Papers

Dory PCS

Dory is used to construct a multivariate polynomial commitment through Fiat-Shamir.

Papers

FRIttata

FRIttata is a distributed bivariate polynomial commitment based on FRI.

Papers

IPA-based polynomial commitments

These commitments express polynomial evaluation as an inner-product argument.

Papers

Multivariate KZG

A multivariate counterpart of KZG commits to polynomials in several variables.

Papers

Multivariate multi-polynomial commitments

MMP commitments commit jointly to multiple multivariate polynomials.

Papers

Orca

Orca is the bivariate commitment in the Orca and Dolphin construction.

Papers

Opening reductions, batching and representation links

Transform evaluation claims between commitment interfaces, combine openings, or link bases and fields. These reductions are components rather than complete proving systems.

Binary-tower ring-switching

Ring-switching converts multilinear commitments over an extension field into commitments over its ground field.

Papers

Black-box multipoint-opening compiler

This compiler turns a univariate PCS into a scheme supporting batch openings at multiple points.

Papers

Commitment linearization

Linearization reorganizes polynomial relations so that committed combinations can replace separate openings.

Papers

Degree-check batching

This technique batches separate polynomial degree bounds over homomorphic commitments.

Papers

fflonk FFT-like opening reduction

The fflonk opening technique converts many polynomials at one point into one polynomial at many points.

Papers

Gemini multilinear opening reduction

Gemini transforms univariate polynomial commitments into multilinear evaluation proofs.

Papers

Hachi

Hachi integrates Greyhound with ring-switching for multilinear evaluations over extension fields.

Papers

Hachi extension-field evaluation reduction

Hachi converts extension-field evaluation proofs to statements over cyclotomic rings.

Papers

Lexicographic-shift multilinear compiler

This univariate-to-multilinear commitment transformation supports lexicographic shifts over the Boolean hypercube.

Papers

LinKZG

LinKZG is a KZG variant formulated for linearization-based commitment openings.

Papers

MERCURY polynomial-division reduction

MERCURY reduces witness-folding checks through univariate polynomial division.

Papers

Polynomial-ring relation switching

This ring-switching technique converts polynomial-ring relations to finite-field or Galois-ring proof statements.

Papers

Reciprocal-polynomial constant-term reduction

This reduction expresses a multilinear evaluation as the constant coefficient of a reciprocal Laurent polynomial.

Papers

Subset-point KZG batching

This KZG extension batches evaluations of different polynomials over different point subsets.

Papers

Zeromorph

Zeromorph builds multilinear evaluation proofs from homomorphic univariate commitments and degree checks.

Papers

Univariate evaluation commitments

Evaluation openings for a polynomial in one variable, across algebraic and code-based constructions. Basis choice is a representation issue rather than a new function.

KZG

A pairing-based scheme commits to a univariate polynomial and opens its evaluations.

Papers

Samaritan univariate-to-multilinear compiler

This compiler transforms an arbitrary univariate PCS into a multilinear PCS.

Papers

Set and multiset accumulators

Compact commitments supporting membership relations for unordered collections. Proof-instance accumulation belongs under proof composition.

Dynamic accumulation and witness maintenance

Insertions, deletions and witness updates for changing collections, including distributed managers and privacy of update operations.

ALLOSAUR

ALLOSAUR is a multiparty pairing accumulator with credential-manager update protocols.

Papers

Oblivious accumulators

Oblivious accumulators combine set commitments with specialized addition and deletion protocols.

Papers

RingSIS dynamic accumulators

This accumulator construction uses RingSIS-based components for evolving sets.

Papers

Utreexo

Utreexo represents the Bitcoin UTXO set with a dynamic hash-based accumulator.

Papers

Membership, non-membership and subset witnesses

Accumulator witness interfaces for inclusion, exclusion and relations between sets, including universal accumulators and witness batching.

Determinantal accumulators

Determinantal accumulators are used as a component of set-membership and non-membership arguments.

Papers

RSA accumulator

The RSA accumulator encodes a set for membership checks and credential revocation.

Papers

Proving claims and checking computations

Cryptographic proofs let a verifier check a claim without repeating all the work. Zero-knowledge proofs can also hide the private information that makes the claim true.

Algebraic verification protocols

Protocols reducing structured algebraic claims to smaller checks. Their role in a proof is separate from polynomial commitment implementations and arithmetic libraries.

Approximate sumcheck

Approximate sumcheck verifies polynomial sum claims with error-tolerant round checks.

Papers

Aurora univariate sumcheck

This IOP verifies the sum of a Reed-Solomon codeword over a subgroup.

Papers

Boolean word-parallel GKR

This GKR variant packs bits into univariate polynomials and precomputes binary circuit operations.

Papers

Convolution VE

This VE protocol handles convolution with multiple input-output channels and batching.

Papers

Count

Count proves univariate sum claims using inner-product commitments.

Papers

cqlin

cqlin proves a linear-map relation between the evaluation vectors of two KZG-committed polynomials.

Papers

Dory inner-pairing batch reduction

This Dory component reduces a pair of committed inner-pairing claims to one claim.

Papers

Libra masked GKR component

This GKR variant introduces small masking polynomials within Libra.

Papers

LiteBullet

LiteBullet is an inner-product proof for matrix computations based on folding and sumcheck.

Papers

Losum

Losum proves univariate sum claims using KZG commitments.

Papers

Packed sumcheck

Packed sumcheck combines repetition with folding while computing in a small prime field.

Papers

Projective sumcheck

Projective sumcheck replaces Boolean-hypercube interpolation with an infinity-hypercube representation.

Papers

RoK, Paper, SISsors

RoK, Paper, SISsors combines reductions for bounded-norm relations over cyclotomic rings.

Papers

Sigma-Check

Sigma-Check uses sumcheck during amortization and compression of polynomial-relation Sigma protocols.

Papers

Sumcheck arguments over modules

These arguments apply sumcheck to module-based commitments to prove commitment openings.

Papers

Verifiable evaluation on fingerprinted data

VE abstracts sumcheck-based evaluation proofs into composable data-processing steps.

Papers

Layered-circuit and data-parallel verification

Layer-by-layer evaluation checking with wiring predicates, including arithmetic and Boolean circuits and data-parallel layouts.

GKR

GKR verifies layered arithmetic circuits using sumcheck and wiring predicates.

Papers

Sparrow

Sparrow is a SNARK for data-parallel arithmetic circuits using a space-oriented proof protocol.

Papers

Relations over committed values

Proofs of linear maps, inner products, pairing products, ranges and other algebraic relations between committed values. An argument component is not automatically a PCS.

Applications of Groth-Sahai proofs

The anonymity protocols built from these proofs soon after the paper: group signatures, ring signatures of sub-linear size, proofs of shuffle correctness, non-interactive anonymous credentials, universally composable oblivious transfer, and verifiable encryption for optimistic fair exchange.

Why it is useful

Anonymous signatures and credentials need to show that a hidden key is certified without revealing it, which is exactly a non-interactive proof about pairing equations; before this framework each protocol needed its own ad hoc proof.

How it works

  1. Group signatures: Boyen and Waters built non-interactive proofs for group signatures independently, of the same shape as the subgroup decision instantiation; Groth used the DLIN instantiation for a fully anonymous group signature scheme.
  2. Ring signatures: Chandran, Groth and Sahai used the subgroup decision instantiation for ring signatures of sub-linear size.
  3. Credentials and transfer: the SXDH and DLIN instantiations gave non-interactive anonymous credentials and a universally composable adaptive oblivious transfer protocol.
  4. Verifiable encryption: attaching these proofs to semantically secure encryption yields a verifiable cryptosystem, suggested for optimistic fair exchange with a trusted but lazy third party.

What to watch for

These are the paper's own reports of contemporary and follow-up work, not constructions developed here; each application carries its own security definitions and assumptions beyond the proof system.

Useful background: Groth-Sahai proofs, Group signatures.

Papers

Binding and hiding commitment keys over modules

A commitment scheme built by viewing the groups as modules, that is as abelian groups whose elements can be scaled by ring elements. A value is committed by embedding it into a larger module and adding random multiples of public key elements. Two flavors of public key exist: a binding flavor where a hard-to-compute linear map recovers the committed value, and a hiding flavor where the randomness spans the whole space.

Why it is useful

One object then serves both halves of the proof system: on binding keys the proof is sound, and on hiding keys it conceals the witness. The paper rests on a single computational requirement, namely that no efficient algorithm can tell a binding key from a hiding key.

How it works

  1. Fix modules with a bilinear map and linear maps that embed the small module into the big one, plus a projection back that is hard to compute without secret information.
  2. To commit, output the embedding of the value plus random multiples of the public key elements.
  3. On a binding key the projection sends every public key element to zero, so the commitment pins down a unique value - it is perfectly binding.
  4. On a hiding key the embedded values already lie in the span of the public key elements, so the commitment is a uniformly random element - it is perfectly hiding.
  5. The commitments are homomorphic with respect to the module operations and the bilinear map, so equations between commitments mirror equations between values.

What to watch for

The projection map is hard only without secret information; whoever generated the keys can compute it, which is exactly what a proof simulator or an extractor exploits, and which is why the key generator must be trusted with the flavor choice.

Useful background: Module, Commitment scheme, Groth-Sahai proofs.

Papers

Cougar

Cougar combines two-tier commitments with disjoint interpolation for inner-product arguments.

Papers

Dory inner-pairing argument

Dory proves inner-pairing products between committed source-group vectors.

Papers

Generalized inner-pairing-product argument

This generalized inner-product argument proves evaluation of pairings between committed source-group vectors.

Papers

Group-scalar inner-product argument

This argument proves inner products between group-element vectors and scalar vectors in bilinear groups.

Papers

LatticeFold+

LatticeFold+ combines algebraic range proofs and double-commitment folding.

Papers

Pairing equations as a statement language

The four equation shapes the framework can prove: a pairing product equation combining paired values in the target group, a multi-scalar multiplication equation in either source group, and a quadratic equation among the exponents. Both group elements and exponents may be the unknowns.

Why it is useful

Practical pairing-based statements such as "this ciphertext encrypts a signature on this message" translate into a handful of these equations, so no reduction to Circuit Satisfiability is needed and the proof stays proportional to the statement itself.

How it works

  1. Choose the secret variables: group elements in either source group and scalars modulo the group order.
  2. Write each claimed relation as one of the four equation types, with public group elements and scalars as constants.
  3. Combine claims with AND by listing several equations that share variables; OR and other logical operations can be encoded with standard arithmetization tricks.
  4. Commit to each secret variable exactly once and reuse that commitment in every equation it appears in, so one consistent choice of the variable satisfies all equations at once.

What to watch for

Not every protocol statement is short in this language; the number of equations grows with the protocol being described, and translating a scheme into these equations is real design work.

Useful background: Bilinear pairings, Groth-Sahai proofs.

Papers

Proofs of equal discrete logarithms

An equality-of-discrete-logarithms proof shows that two public group elements use the same hidden exponent relative to two specified bases. It can certify a participant's partial exponentiation without revealing its secret share.

Why it is useful

A verifier needs to reject an invented output, not merely confirm that it is a valid group element.

How it works

  1. Commit to one fresh random exponent under both bases.
  2. Obtain a challenge, or derive it from the full statement and commitments in the noninteractive form.
  3. Respond with the nonce plus the challenge times the hidden exponent.
  4. Check both group equations against the same challenge and response.

What to watch for

Soundness needs the appropriate group and nondegenerate statement, correctly bound challenges and fresh prover randomness. Membership checks alone do not prove the claimed relation.

Related ideas

Papers

Randomizing proof terms for witness indistinguishability

A randomization step applied to the correction terms before sending them. Fresh random choices, including a random matrix and random multiples of special matrices published in the common reference string, make the terms uniform among all values that satisfy the verification equation.

Why it is useful

If the correction terms were left as computed, their distribution could depend on the witness. Uniformity for every possible witness is exactly what makes the proof witness-indistinguishable: any two witnesses produce the same distribution of published terms.

How it works

  1. If only one correction value can satisfy the verification equation, it carries no witness information and can be sent as is.
  2. Otherwise the prover adds a uniformly random matrix times the commitment key to one part of the proof, and compensates the other part so the verification equation still holds.
  3. The common reference string may also list matrices whose pairings with the key vectors vanish; adding random multiples of these changes nothing the verifier can see.
  4. After this, every satisfying witness yields the same uniform distribution over proofs that pass the check.

What to watch for

The randomization must stay invisible to the verification equation - only differences that cancel under the pairing check may be added - and the number of special matrices needed depends on the instantiation: none for the SXDH pairing equations, several for DLIN.

Useful background: Substituting commitments into the equation, Binding and hiding commitment keys over modules.

Papers

Ring-polynomial inner-product argument

The MyOPE component proves inner-product relations for vectors over polynomial rings.

Papers

SIPA

SIPA adapts a Bulletproofs-style inner-product argument to groups of unknown order.

Papers

Substituting commitments into the equation

The central proof step: replace each secret variable in the equation by its commitment. Because the commitments are homomorphic and carry their own bilinear map, the substituted equation evaluates to the true statement plus extra terms produced by the commitment randomness, and the prover publishes exactly those extra terms.

Why it is useful

This is what keeps proofs short and readable: the verifier checks essentially the original equation, lifted to commitments, plus one correction term, with no circuit and no cut-and-choose.

How it works

  1. Commit to all secret variables.
  2. Plug the commitments into the equation in place of the variables.
  3. Expand using bilinearity; the result equals the embedded target plus terms that depend on the commitment randomness.
  4. The prover computes those randomness terms and sends them as the proof.
  5. The verifier checks one pairing equation linking the commitments, the public constants and the correction terms.
  6. For soundness, applying the projection maps to a valid check shows the committed values themselves satisfy the original equation, since the public key elements vanish under the projection.

What to watch for

Handing over the raw correction terms can reveal which witness was used, so they must be randomized before being sent; soundness itself is perfect but only relative to the binding flavor of the keys.

Useful background: Binding and hiding commitment keys over modules, Groth-Sahai proofs.

Papers

TENET

TENET is a pairing-based inner-product argument.

Papers

Sum verification and vanishing reductions

Sumcheck, zero-check and related algebraic reductions for polynomial sums, including univariate, multivariate and module-valued forms. Incentive-based rational proofs are a separate model.

Binary-tower constraint packing

Constraint packing combines binary-tower constraints within a modified zero-check reduction.

Papers

Group-valued sumcheck

Group-valued sumcheck permits coefficients in a group rather than a field.

Papers

NeutronNova

NeutronNova constructs folding schemes by reducing circuit, product, and lookup relations to zero-check.

Papers

Sumcheck

Sumcheck reduces a claimed hypercube sum of polynomial evaluations to evaluation checks.

Papers

Zero-check reduction

Zero-check reduces the vanishing of constraints to an equality-weighted sumcheck instance.

Papers

Coding techniques for proofs

Use of codes for oracle proofs, proximity testing and proof composition. Code construction, decoding and hardness assumptions have their main mathematical treatment elsewhere.

Batched FRI

Batched FRI applies the FRI proximity protocol to a batch of inputs.

Papers

Brakedown expander code

The Brakedown expander code uses sampled expansion graphs in its encoding construction.

Papers

Circle-domain Reed-Solomon codes

These Reed-Solomon codes evaluate over a unit-circle domain in an extension of a Mersenne prime field.

Papers

DEEP-FRI

DEEP-FRI combines Reed-Solomon proximity testing with out-of-domain evaluation queries.

Papers

Expand-accumulate codes

Expand-accumulate codes combine sparse expansion with accumulation and are used by Flare.

Papers

Galois-ring random foldable codes

These random foldable codes operate over Galois rings as a BaseFold component.

Papers

Generalized RAA codes

Generalized RAA codes extend the binary RAA construction to non-binary prime fields.

Papers

Group BaseFold variant

This group-valued BaseFold variant replaces the inner-product verifier multiscalar multiplication.

Papers

Interleaved Reed-Solomon codes

Interleaved Reed-Solomon codes combine multiple RS codewords and are used in Ligero.

Papers

Lightning code

Lightning code derives a new encoding from a chosen base code.

Papers

Orion (argument system)

Orion is a circuit argument system built using code-based proof techniques.

Papers

Quasi-Abelian codes

Quasi-Abelian codes are the linear-code family used in QAPCS and Quasar.

Papers

RAA codes

Repeat-Accumulate-Accumulate codes combine repetition with two accumulation stages.

Papers

Random foldable codes

Random foldable codes are punctured Reed-Muller codes used in BaseFold.

Papers

Restricted-sampling proximity testing

This technique samples from a restricted subset of an affine space when testing proximity to a linear code.

Papers

Spielman codes

Spielman codes are expander-based linear codes used by Brakedown and Orion commitments.

Papers

STIR

STIR recursively changes the rate of the Reed-Solomon code tested by a proximity protocol.

Papers

Systematic LDPC codes

Systematic LDPC codes expose message symbols and use sparse parity checks in code-based proof protocols.

Papers

Tensor codes

Tensor codes combine component linear codes across multiple dimensions.

Papers

Code switching and encoding consistency

Reductions linking the same message across encodings, fields or proof oracles. This differs from cryptographic key switching in homomorphic encryption.

Code switching for proof composition

Code switching proves that a second argument uses the same message encoded by a linear code.

Papers

FACS

FACS is an accumulation scheme built using code-switching oracle reductions.

Papers

Masked constrained-interleaved-code IOPP

This proximity protocol composes sumcheck and code-switching oracle reductions for constrained interleaved codes.

Papers

Masked sumcheck oracle reduction

This sumcheck oracle reduction composes with other masked oracle reductions.

Papers

Low-degree and codeword proximity testing

Interactive oracle tests of proximity to polynomial evaluation codes or other linear codes, including constrained and batched tests. Commitment and evaluation-binding layers must be supplied separately.

BaseFold foldable-code IOPP

This component generalizes FRI proximity testing to foldable linear codes.

Papers

DEEP sampling

DEEP sampling queries an interpolating polynomial outside the codeword evaluation domain.

Papers

FRI

FRI is an interactive oracle proximity protocol for Reed-Solomon codewords.

Papers

WHIR

WHIR tests proximity to constrained Reed-Solomon codes that express polynomial queries.

Papers

Proof and argument models

Models of interaction, oracle access and verification cost. Proof versus argument concerns soundness; zero knowledge is a separate privacy property.

Algebraic-interactive-proof SNARK compiler

This compiler converts public-coin algebraic interactive proofs into SNARKs.

Papers

AntMan

AntMan uses polynomial authentication to prove batches of circuit executions.

Papers

Aurora

Aurora is an IOP-based SNARK for R1CS.

Papers

AuroraLight

AuroraLight combines Aurora ideas with a Sonic-like SNARK construction.

Papers

Basilisk

Basilisk is a SNARK obtained from checkable subspace sampling arguments.

Papers

Batch polynomial evaluation interactive proofs

These MA and AMA protocols delegate evaluation of one or several polynomials at multiple points.

Papers

Bezout uniqueness and disjointness arguments

These algebraic interactive proofs use polynomial Bezout identities to check uniqueness and disjointness of address accesses.

Papers

BinarySpartan

BinarySpartan instantiates Spartan over a binary field using Ligerito commitments and ring switching.

Papers

Binius (proof system)

Binius is a proving system over binary extension fields.

Papers

Boojum

Boojum is a proof system using FRI-based components.

Papers

BooLigero

BooLigero adapts Ligero to word-oriented Boolean-circuit constraints.

Papers

Brakedown (SNARK)

Brakedown combines a code-based commitment construction with Spartan-style proofs for R1CS.

Papers

Bulletproofs+

Bulletproofs+ is a variant for range and arithmetic-circuit arguments.

Papers

Bulletproofs++

Bulletproofs++ uses reciprocal set-membership arguments in the Bulletproofs family.

Papers

Ceno

Ceno proves grouped execution segments and reconstructs program control and data flow.

Papers

Checkable subspace sampling arguments

CSS arguments check whether a vector was sampled from a subspace according to verifier coins.

Papers

Circle STARKs

Circle STARKs use the circle curve for polynomial evaluation domains.

Papers

Cirrus

Cirrus distributes HyperPlonk proof generation across workers and a coordinator.

Papers

CompGroth16

CompGroth16 adapts Groth16 for disjunctions mixing algebraic and arithmetic statements.

Papers

Dew

Dew compiles an information-theoretic proof system using an unknown-order-group PCS.

Papers

Dora

Dora proves RAM programs using the ZKBag abstraction for processor instructions.

Papers

Dynasaurs

Dynasaurs builds dynamic SNARKs from sparse linear arguments.

Papers

Eden zkVM

The Eden zkVM instantiates the Eden instruction set as a STARK.

Papers

eSTARK

eSTARK extends STARK proofs using the eAIR representation and additional arguments.

Papers

ethSTARK

ethSTARK is a concrete STARK construction accompanied by a computational-integrity specification.

Papers

EZEE

EZEE parallelizes ZEE program-execution proofs across epochs.

Papers

fflonk

fflonk is a PLONK variant using FFT-inspired batching of polynomial openings.

Papers

Flock

Flock proves batches of Boolean R1CS computations and input-output relations between them.

Papers

Garuda

Garuda is a SNARK with custom gates and a dedicated treatment of linear gates.

Papers

Geppetto

Geppetto uses Multi-QAPs and proof bootstrapping for computations that share state.

Papers

Giraffe

Giraffe uses an interactive data-parallel proof protocol in a verifiable-ASIC system.

Papers

Halo2

Halo2 is a circuit-oriented proving system.

Papers

Hobbit

Hobbit is a streaming SNARK for arithmetic circuits based on a modified HyperPlonk protocol.

Papers

HybridPlonk

HybridPlonk compiles a Plonkish PIOP using a modified sumcheck component.

Papers

HybridSpartan

HybridSpartan compiles a R1CS PIOP using a modified sumcheck component.

Papers

Hydra (pipelined arguments)

Hydra pipelines interactive circuit proofs at the subcircuit and circuit-layer levels.

Papers

HyperFond

HyperFond distributes a HyperPlonk-based proof system using multilinear commitments.

Papers

HyperPianist

HyperPianist distributes a multivariate PIOP inspired by Pianist and HyperPlonk.

Papers

HyperPianist-D

HyperPianist-D instantiates distributed HyperPianist with Dory commitments.

Papers

HyperPianist-K

HyperPianist-K instantiates distributed HyperPianist with multivariate KZG commitments.

Papers

HyperPlonk

HyperPlonk adapts PLONK to Boolean-hypercube encodings and multilinear commitments.

Papers

Hyrax (SNARK)

Hyrax combines an interactive circuit argument with a non-interactive compiler.

Papers

JesseQ

JesseQ contains two VOLE-based proof protocols for field circuits.

Papers

Jolt-b

Jolt-b is a Jolt variant using BaseFold commitments for recursive verification.

Papers

JQv1

JQv1 is a circuit-proof protocol within the JesseQ suite.

Papers

JQv2

JQv2 is a circuit-proof protocol within the JesseQ suite.

Papers

Kopis

Kopis is the other named R1CS SNARK construction presented under the Quarks title.

Papers

LegoUAC

LegoUAC is a pairing-based arithmetic-circuit SNARK in the LegoSNARK collection.

Papers

Libra

Libra combines a layered-circuit proof protocol with polynomial masking.

Papers

Libra GKR prover algorithm

Libra uses a specialized prover algorithm for the GKR interactive proof.

Papers

Ligero (argument system)

Ligero uses an interleaved-code proof construction for circuit statements.

Papers

Ligero++

Ligero++ is a proof construction instantiated within a composite-statement proof system.

Papers

Limber-based integer SNARK

This integer SNARK combines the Limber integer mod-PCS with an integer R1CS PIOP.

Papers

Linear non-interactive proof models

In this proof model, a prover chooses a matrix from the statement, witness and its own randomness, then multiplies that matrix by the setup vector. The matrix choice is independent of the sampled setup vector.

Why it is useful

The restriction exposes the algebra that can later be encoded in group elements and checked with pairings.

How it works

  1. Represent setup information as a field vector.
  2. Choose the proof matrix without inspecting that sampled vector.
  3. Compute the proof as the matrix-vector product.
  4. Check polynomial equations in the setup and proof values.

What to watch for

An unrestricted real prover is not automatically constrained this way. Compiling the model into a cryptographic argument needs an explanation of why its adversaries are covered.

Related ideas

  • Generic group model: Is used to justify the algebraic restrictions in this paper's compiled argument.

Papers

LUNA+

LUNA+ refines the designated-verifier lattice-based LUNA construction through changes to re-randomization.

Papers

Mac'n'Cheese

Mac'n'Cheese proves Boolean and arithmetic circuits with nested disjunctions using authenticated values.

Papers

MicroSpartan

MicroSpartan is a SNARK listed among sumcheck-based proof systems.

Papers

Miden VM

Miden VM is a virtual machine that operates natively over a finite field.

Papers

MIRAGE

MIRAGE proves randomized computations and uses them to check universal circuits.

Papers

MuxProofs

MuxProofs uses vector lookups to assemble proofs of executed machine instructions.

Papers

Mystique

Mystique combines conversions among arithmetic, Boolean, committed, and authenticated representations in proofs.

Papers

Pari

Pari is a SNARK construction using equifficient polynomial commitments.

Papers

Pianist

Pianist distributes PLONK-based proofs across multiple participants.

Papers

PlonKup

PlonKup integrates Plookup into PLONK.

Papers

Plonky2

Plonky2 is a Plonk-like proof system using low-degree proximity testing.

Papers

Plonky3

Plonky3 supplies a STARK backend for AIR-based proofs.

Papers

Polymath

Polymath is a SNARK for square arithmetic programming built using KZG commitments.

Papers

Polynomial holographic IOPs

PHPs are an algebraic IOP model used by Lunar to express R1CS proof protocols.

Papers

Quadratic span programs

QSPs extend span programs to characterize NP statements for succinct arguments.

Papers

RedShift

RedShift instantiates a SNARK transformation using list polynomial commitments.

Papers

RISC Zero

RISC Zero is a proof system using FRI-based components.

Papers

RoK and Roll

RoK and Roll is a lattice argument system using structured random projections.

Papers

SALSAA

SALSAA incorporates sumcheck-based norm checking into lattice argument constructions.

Papers

Samaritan

Samaritan compiles the LogSpartan PIOP with SamaritanPCS.

Papers

Scribe

Scribe uses read-write streams on disk for intermediate SNARK prover state.

Papers

Siniel

Siniel delegates PIOP-and-PCS proof generation to multiple workers.

Papers

Soloist

Soloist distributes proof generation for R1CS statements.

Papers

Sonic

Sonic is an arithmetic-circuit SNARK built around a universal updatable reference string.

Papers

SP1

SP1 is a zkVM with chip-level AIR constraints for instruction execution.

Papers

Spartan

Spartan is a family of SNARKs for rank-1 constraint satisfiability.

Papers

Stwo

Stwo is a STARK prover used for client-side proof generation.

Papers

SublonK

SublonK specializes PLONK proving to the active portion of a circuit.

Papers

Succinct vector lookup arguments

These vector lookups build machine executions from instruction-sized vectors.

Papers

Symplex

Symplex is a pairing-based R1CS SNARK using partial-fraction techniques.

Papers

Trinocchio

Trinocchio distributes Pinocchio proving across workers.

Papers

TurboPLONK

TurboPLONK is a PLONK variant with custom gates used to express hash computations.

Papers

UltraHonk

UltraHonk is a proving backend used with the Noir language.

Papers

UltraPLONK

UltraPLONK is a proving backend used with Noir circuits.

Papers

UniPlonK

UniPlonK uses a common verifier for families of PLONK circuits.

Papers

Vampire

Vampire is a pairing-based SNARK built using the Count univariate argument and aggregated polynomial commitments.

Papers

Virgo (argument system)

Virgo is a layered-circuit argument system built using polynomial delegation.

Papers

Wolverine

Wolverine is an interactive proof protocol for Boolean and arithmetic circuits.

Papers

Xiphos

Xiphos is one of the R1CS SNARK constructions presented under the Quarks title.

Papers

ZEE

ZEE is an interactive program-execution proof system supporting C programs.

Papers

ZEE200

ZEE200 combines CPU and RAM proving techniques for high-level programs.

Papers

Zilch

Zilch compiles programs into instruction sequences for proofs over a MIPS-like processor.

Papers

Zinc

Zinc proves integer arithmetic using hash-based arguments and proximity to integer encodings.

Papers

Identification and interactive verification

Identification, Sigma protocols, interactive proofs and arguments, including multi-prover and incentive-based models. Signature-and-MAC key exchange named SIGMA is a different topic.

Parallel repetition of public-coin proofs

Parallel repetition runs several instances of a public-coin proof together.

Papers

Rational sumchecks

Rational sumchecks use an incentive-based prover model in delegation protocols.

Papers

Noninteractive and succinct argument interfaces

NIZKs, succinct arguments and succinct arguments of knowledge, including public and designated verifiers. Succinctness, zero knowledge and setup transparency are independent attributes.

Lower bounds for generic pairing-based arguments

The paper rules out proofs consisting of only one group element for a specified class of Type III pairing-based arguments for languages with hard decisional problems.

Why it is useful

It explains why the construction's three elements are close to a model-specific limit without claiming they are universally optimal.

How it works

  1. Restrict setup, proving and verification to the specified generic-group algorithms.
  2. Have the verifier accept by checking the prescribed pairing-product equations.
  3. Observe that omitting either source group makes the proof dependence linear.
  4. Use that linearity to contradict the assumed difficulty of distinguishing true and false instances.

What to watch for

The result requires elements from both source groups and establishes a lower bound of two, not three. It does not rule out every two-element construction, arbitrary proof-dependent verification, concrete-encoding tricks or non-pairing proof systems.

Papers

LUNA

LUNA is a designated-verifier lattice-based argument system.

Papers

Non-interactive zero knowledge and the common reference string

A zero-knowledge proof convinces a verifier that a statement is true while leaking nothing beyond that fact. A non-interactive zero-knowledge (NIZK) proof is a single message that anyone can later check, but such proofs are impossible with no shared setup at all: Blum, Feldman and Micali showed they become possible once everyone shares a common reference string (CRS), a public string produced by a trusted generator.

Why it is useful

One generated proof can be re-verified by any number of verifiers, which matters for applications like electronic voting. The impossibility in the plain model means some trust is unavoidable, and the paper also recalls that random-oracle-based constructions can fail for every real hash function, so a CRS is the setup it works with.

How it works

  1. A trusted generator samples and publishes the CRS once.
  2. The prover reads the CRS plus the statement and its witness, and outputs a single argument message.
  3. Any verifier checks the argument against the CRS; no further interaction happens.
  4. If no trusted generator exists, the verifier can send its own first message in place of the CRS, and the prover checks that message is well formed before answering; this two-message variant is a zap.

Example

The CRS works like a public bulletin board: once it is posted, proofs can be produced and checked offline by anyone.

What to watch for

Soundness is only computational (hence the word argument rather than proof), and the zap fallback is witness-indistinguishable, not fully zero-knowledge.

Related ideas

  • Circuit satisfiability: the NP-complete statement being proved

Papers

Preprocessing succinct arguments

A preprocessing succinct argument uses a potentially large setup string for a fixed relation, but has a short proof and verification cost bounded by the security parameter and public-statement size.

Why it is useful

It allows a verifier to check a large computation without receiving the full witness or redoing all of that computation.

How it works

  1. Build the reference string for the relation.
  2. Let the prover perform the substantial witness-dependent computation.
  3. Send a proof whose size does not grow with the full circuit.
  4. Verify using the statement and the smaller verifier parameters.

What to watch for

Short proofs do not imply cheap setup, cheap proving or constant-time verification for arbitrarily large public inputs. The paper distinguishes preprocessing succinctness from also requiring a short reference string.

Related ideas

Papers

Rinocchio

Rinocchio constructs designated-verifier SNARKs for arithmetic over commutative rings.

Papers

Statements, witnesses and proof relations

A proof relation specifies which private witnesses make a public statement true. The verifier receives the statement and proof; the prover also uses a witness satisfying the relation.

Why it is useful

It separates the claim being checked from the information used to justify that claim.

How it works

  1. Define the allowed public inputs and private witness values.
  2. Write a relation that accepts exactly the intended combinations.
  3. Generate a proof for one public statement using a matching witness.
  4. Verify against that same relation and statement.

Example

For public y and private x, the relation x squared = y over a field proves the existence of a square root in that field. It does not automatically prove an integer square root in a chosen numerical range.

What to watch for

A proof establishes the encoded relation. It does not add omitted authorization rules, integer ranges, input freshness or real-world meaning.

Papers

The monomial bottleneck: quadratic to quasilinear

Groth constructed in 2010 the first NIZK Circuit-SAT argument whose communication is sublinear in the worst case. This paper pinpoints the quantity that dominates its cost: the number of monomials, that is distinct powers, of one polynomial. In Groth’s version that count is quadratic in the tuple length n, which is exactly why the CRS needs quadratic many group elements and the prover quadratic many exponentiations. Collapsing the monomial count to about n makes both quasilinear.

Why it is useful

The diagnosis turns an efficiency question into a combinatorial one: choose the exponent set so that the powers an honest prover needs are few and never collide with the powers that encode the constraints.

How it works

  1. Write the pairing check as an equality about exponents: one polynomial F(x) split into a constraint part and an argument part.
  2. The constraint part has one monomial per constraint and vanishes for an honest prover; the argument part is everything the prover must supply.
  3. Groth’s exponent choice makes the argument part span quadratically many distinct powers, one CRS generator and one exponentiation each.
  4. Choosing exponents from a dense progression-free set collapses the count to n to the power 1+o(1); balancing CRS against argument length yields total communication of about |C| to the power 1/2+o(1) group elements.

What to watch for

The prover still does quadratic many cheap additions in Zp to assemble coefficients; what shrinks is the group exponentiation count and the CRS, and the o(1) hides slowly decaying factors.

Useful background: Committing to a tuple as one lifted polynomial.

Papers

Why the security needs a knowledge assumption

Abe and Fehr showed that no statistically zero-knowledge non-interactive argument for an NP-complete language can have a direct black-box reduction to a standard assumption unless NP is contained in P/poly. So soundness here rests on an explicit knowledge assumption, a power version of the knowledge-of-exponent assumption: whoever outputs a valid paired element must effectively know the exponents. Binding of the commitments instead rests on a power discrete-logarithm assumption, which the paper proves holds in the generic group model.

Why it is useful

Succinct arguments cannot be proven sound from ordinary falsifiable assumptions; the knowledge assumption hands the reduction an extractor that reads the committed witness out of the adversary, and the power discrete-log assumption replaces the stronger assumption Groth used.

How it works

  1. Knowledge assumption: if an adversary outputs a value and its doubled-secret copy after seeing the published powers, an extractor with the adversary’s coins outputs the exponents behind the value.
  2. Power discrete log: given the published powers, no efficient adversary recovers the secret exponent; in the generic group model this holds for any polynomial-size exponent set.
  3. In the soundness proof a cheating prover yields a non-zero polynomial that vanishes at the secret exponent; factoring that polynomial recovers the secret and breaks the assumption.
  4. Because the polynomial now has degree about lambda n instead of order n squared, the reduction tightness improves: factoring time is that of a degree lambda n polynomial rather than a degree order n squared one.

What to watch for

Knowledge assumptions are unfalsifiable - no efficient experiment can refute them - and the paper’s claim that its assumption is presumably weaker than Groth’s is a heuristic comparison, not a theorem.

Useful background: What a NIZK argument must guarantee.

Papers

PCP, IOP and algebraic oracle models

Probabilistically checkable proofs, interactive PCPs, IOPs and polynomial or vector oracle models, including holographic preprocessing. Oracle access is not a concrete commitment.

Algebraic holographic proofs

AHPs are holographic proof protocols used in preprocessing SNARKs.

Papers

BCS transformation

BCS compilation turns interactive oracle proofs into non-interactive arguments.

Papers

ECLIPSE

ECLIPSE compiles decomposable algebraic holographic proofs into commit-and-prove SNARKs.

Papers

FICS

FICS is a code-switching IOP of proximity for multilinear polynomial evaluation.

Papers

Interactive oracle proofs

An IOP gives the verifier query access to messages exchanged in an interactive proof.

Papers

IPCP masked sumcheck

This sumcheck variant uses algebraic commitments in the interactive-PCP model.

Papers

Kilian PCP-to-argument construction

Kilian compilation combines a probabilistically checkable proof with a vector commitment.

Papers

Limbo

Limbo builds interactive oracle proofs from multi-round MPC-in-the-head executions.

Papers

Marlin

Marlin constructs preprocessing SNARKs from algebraic holographic proofs for R1CS.

Papers

Micali CS proofs

Micali compilation uses a random oracle to convert a PCP into a non-interactive succinct argument.

Papers

Polynomial interactive oracle proofs

A PIOP expresses proof checks through oracle queries to polynomial relations.

Papers

Supersonic

Supersonic compiles the PLONK polynomial IOP using DARK commitments and Fiat-Shamir.

Papers

SuperSpartan

SuperSpartan extends the Spartan polynomial IOP to customizable constraint systems and combines it with a PCS.

Papers

Proof composition and reusable verification

Combine proof obligations across statements or computation steps while preserving their binding and security. Distinguish final proofs from unfinished verification claims.

aPlonK

aPlonK aggregates PLONK statements through multi-polynomial commitments.

Papers

BOIL

BOIL uses oracle batching to accumulate correlated holographic IOPs.

Papers

Bulletproofs*

Bulletproofs* applies ProtoStar-style folding to Bulletproofs arithmetic circuit proofs.

Papers

Commit-and-fold

Commit-and-fold simplifies the relation used by folding-based IVC through commitments.

Papers

Commitment-carrying IVC

Commitment-carrying IVC carries an incremental commitment to advice across computation steps.

Papers

CycleFold

CycleFold instantiates folding-based recursive arguments over a cycle of elliptic curves.

Papers

Cyclo

Cyclo uses partial range checks and amortized norm refreshing in lattice-based folding.

Papers

FLI

FLI folds lookup instances by folding the elementary-basis-row property of addressing matrices.

Papers

FLI+SOS

FLI+SOS extends FLI to SOS-decomposable lookup tables.

Papers

FLIP

FLIP folds multiple R1CS instance-witness pairs using a two-tier commitment.

Papers

Hekaton

Hekaton distributes computation chunks to provers and aggregates the resulting proofs.

Papers

Interstellar

Interstellar combines circuit interpolation and GKR with folding and IVC.

Papers

KZH-Fold

KZH-Fold accumulates polynomial claims using the KZH multilinear commitment scheme.

Papers

LaBRADOR

LaBRADOR is a lattice-based argument for R1CS using recursive amortization.

Papers

LatticeBlindFold

LatticeBlindFold adapts SuperNeo with commitment-backed masking in an interactive folding protocol.

Papers

LatticeFold

LatticeFold uses lattice commitments to fold low-degree and high-degree constraint relations.

Papers

Lova (unstructured-lattice folding)

Lova is a folding scheme using unstructured lattices and power-of-two modular arithmetic.

Papers

Mangrove

Mangrove combines a uniformizing compiler with commit-and-fold techniques for folding-based SNARKs.

Papers

MicroNova

MicroNova produces folding-based incremental proofs followed by a final compression step.

Papers

Mira

Mira folds pairing-based arguments directly, including applications to Groth16 aggregation.

Papers

Mova

Mova folds R1CS instances using evaluations in place of commitments to error and cross terms.

Papers

Nebula

Nebula combines commitment-carrying IVC, memory arguments, and switchboard circuits for machine execution.

Papers

Neo

Neo is a lattice-based folding scheme for SIMD instances of CCS.

Papers

Non-homomorphic accumulation

This accumulation scheme spot-checks encoded vectors rather than combining commitments homomorphically.

Papers

NovaBlindFold

NovaBlindFold uses the blinding operation of Nova folding to randomize proofs.

Papers

PikkuFold

PikkuFold uses layered random projections in lattice-based folding.

Papers

Proofs for Deep Thought

This memory-proving IVC construction uses accumulation for computations with large memories.

Papers

ProtogaLattice

ProtogaLattice adapts algebraic folding ideas to high-degree polynomial relations over lattices.

Papers

ProtoGalaxy

ProtoGalaxy builds on ProtoStar ideas to fold multiple instances at a step.

Papers

ProtoStar

ProtoStar constructs non-uniform IVC for PLONK using accumulation of special-sound protocols.

Papers

Reverie

Reverie combines PLONK and CycleFold for IVC carried between collaborating provers.

Papers

RoKoko

RoKoko is a lattice-based argument system using recursive split-and-fold reductions.

Papers

Selective-verification folding

Selective-verification folding allows individual statements to be checked against an aggregated statement.

Papers

SnarkFold

SnarkFold aggregates SNARK proofs through IVC and deferred proof verification.

Papers

Snarktor

Snarktor organizes decentralized recursive aggregation by independent provers.

Papers

Statement-hider folding compiler

This compiler applies statement hiders before folding instances for selective verification.

Papers

SuperNeo

SuperNeo extends the Neo line of lattice folding to non-SIMD CCS relations.

Papers

SuperNova

SuperNova uses folding for non-uniform incremental verification of stateful-machine programs.

Papers

WARP

WARP uses hash-based accumulation and oracle reductions of proximity.

Papers

WARPfold

WARPfold adapts ProtoStar folding to computations over non-native fields.

Papers

Commit-and-prove and modular statement composition

Link specialized proofs through committed values, authenticated inputs and shared witnesses, including conjunctions and disjunctions. Composition requires explicit consistency relations.

LegoGro16

LegoGro16 adds commit-and-prove support to Groth16 using Pedersen-committed data.

Papers

LegoSNARK

LegoSNARK composes specialized commit-and-prove proof gadgets.

Papers

Lunar

Lunar constructs SNARKs and commit-and-prove variants from polynomial holographic IOPs.

Papers

r-Groth

r-Groth is a commit-and-prove variant of Groth16 for relaxed R1CS.

Papers

Relaxed R1CS

Relaxed R1CS extends the R1CS relation for use in folding and commit-and-prove protocols.

Papers

Proof aggregation, batching and selective verification

Combine proofs or verification work across statements, including selective checks against an aggregate. Commitment-opening batching is a related lower-level operation.

SnarkPack

SnarkPack aggregates Groth16 proofs using an inner-product-style argument.

Papers

Recursive verification, IVC and proof-carrying data

Verify earlier proofs within later computations, maintain incremental computation claims, or carry proofs across a computation graph. Folding and curve cycles are possible components rather than definitions.

Halo

Halo implements recursive proof composition over elliptic-curve cycles.

Papers

Halo Infinite

Halo Infinite constructs proof-carrying data using additive polynomial commitment schemes.

Papers

Holography accumulation

Holography accumulation carries public polynomial-evaluation checks across recursive proof steps.

Papers

Recursive proof composition and its assumptions

Recursive proof composition proves that another proof verifies, so many verification claims can be represented by a further proof. Small proofs and cheap verifiers reduce the work inside that next circuit.

Why it is useful

It is a way to combine verified computations, but it requires a soundness argument that survives the composition.

How it works

  1. Describe the earlier verifier as an actual computation.
  2. Constrain that computation inside the outer proof relation.
  3. Bind the inner statements and their connections.
  4. Check that the security model supports this use of the inner proof system.

What to watch for

This paper explicitly warns that its generic-group soundness guarantee is not automatically preserved under recursion: encoding verification in a circuit uses concrete group representations. Its discussion of recursive use is conditional on suitable standard-model knowledge soundness.

Related ideas

  • Generic group model: Restricts operations in a way that must not be silently discarded during composition.

Papers

Testudo

Testudo combines a Spartan variant with multivariate commitments and recursive opening-proof compression.

Papers

Witness folding and verification-claim accumulation

Combine instance-witness pairs or accumulate pending verification claims. These are different interfaces; neither operation alone implies a complete recursive proof or zero knowledge.

Arc

Arc accumulates claims about proximity to Reed-Solomon codes.

Papers

Nova

Nova constructs incrementally verifiable computation using a folding scheme.

Papers

Quasar

Quasar combines a multi-cast reduction with folding for multi-instance accumulation.

Papers

Accumulation schemes

Combining verification claims into an accumulator and its final decision procedure.

Folding schemes

Ways of combining instances and witnesses for later verification. Folding and complete recursive proof systems are distinct.

Proof construction and compilation methods

Methods that turn idealized proof protocols or private-computation components into concrete arguments. Algebraic, coding and assumption choices remain separate topics.

Disclosure-free setup in linear-proof compilation

Disclosure-freeness says that the allowed algebraic equality tests on a sampled setup give, except with small probability, the same answers as on an independently sampled setup.

Why it is useful

It prevents those tests from giving a generic prover useful setup-specific information for choosing an otherwise restricted proof matrix.

How it works

  1. Specify the class of bilinear tests available in the compilation.
  2. Compare a fixed allowed test on two independent setups.
  3. Distinguish formal polynomial identities from accidental equalities at sampled points.
  4. Use the resulting bound in the argument that adapts the linear-proof model to generic adversaries.

What to watch for

This is a particular proof-model property, not a claim that the setup reveals no information of any kind. It depends on the allowed tests and the setup distribution.

Useful background: Linear non-interactive proof models, Generic group model.

Papers

Groth16

Groth16 is a pairing-based preprocessing argument for quadratic arithmetic programs. Its proof contains two elements of the first source group and one of the second.

Why it is useful

It gives a compact proof of a large field-arithmetic computation while keeping the witness private.

How it works

  1. Generate relation-specific reference strings using secret setup scalars.
  2. Compute the QAP quotient from a satisfying assignment.
  3. Use fresh randomizers to construct the three proof elements.
  4. Combine the public inputs with the verifier parameters.
  5. Check group membership and the pairing equation for that statement.

What to watch for

The retained paper proves knowledge soundness against polynomially many generic bilinear-group operations, with its setup and auxiliary-input qualifications. It is not an unconditional proof for a concrete curve, a compiler or a recursive deployment.

Useful background: Quadratic arithmetic programs, Bilinear pairings, Preprocessing succinct arguments.

Related ideas

Papers

Binding public inputs in Groth16

Groth16 verification forms a weighted sum of setup elements using the public inputs in their assigned positions, including the fixed constant input. That sum enters the pairing equation.

Why it is useful

It connects the proof to the statement the verifier intends to accept.

How it works

  1. Fix the relation, input count and input ordering.
  2. Supply the actual public field values for that relation.
  3. Compute their weighted sum using the matching verifier key.
  4. Check the proof against that sum and preserve the application's intended interpretation of the values.

What to watch for

A coordinate left unconstrained by the relation can legitimately vary without changing the claim. Application meanings, canonical byte encodings and range checks are not supplied by the pairing equation itself.

Papers

Groth16 proof randomization

Two independently uniform field elements randomize the first two Groth16 proof components. The third is adjusted so that the verification equation still holds.

Why it is useful

In the paper's algebra, the first two encoded exponents become uniformly random, and the equation uniquely fixes the third. This gives the same distribution as the simulator.

How it works

  1. Sample the two randomizers from the full scalar field.
  2. Add their masked contributions to the first two proof exponents.
  3. Include the corresponding correction terms in the third component.
  4. Use the same public statement and reference string in verification.

What to watch for

The privacy argument relies on the specified sampling. A short or fixed-randomness proof is not covered merely because its pairing equation passes. Valid proofs are not unique identifiers of a statement or action.

Useful background: Zero knowledge through simulation.

Papers

Groth16 setup and simulation trapdoors

Groth16 setup publishes group encodings of values derived from secret scalars and the QAP. The full scalar trapdoor lets the simulator create accepting proofs without a witness.

Why it is useful

The simulation algorithm explains both the zero-knowledge proof and why ordinary attackers must not receive the setup trapdoor.

How it works

  1. Generate the relation-specific encoded parameters from the prescribed nonzero setup scalars.
  2. Separate the public reference string from the secret scalar trapdoor.
  3. Give proving and verification only the public parameters they need.
  4. Use an appropriate setup procedure and keep the full simulation trapdoor unavailable to parties whose proofs must be sound.

What to watch for

The single-party setup algorithm is not a complete multiparty ceremony, update protocol or audit procedure. Sharing the full trapdoor defeats the stated soundness model; knowledge of one arbitrary component is not asserted to have the same consequence.

Papers

Witness-gated proofs from obfuscated programs

The paper's noninteractive argument uses a public obfuscated prover that checks a witness and, only if it is valid, outputs a secret function value for the statement. A second obfuscated program verifies the proof through a one-way function.

Why it is useful

The output depends on the statement rather than on which valid witness was supplied, allowing a simulator with setup information to reproduce the proof distribution.

How it works

  1. Fix statement and witness size bounds at setup.
  2. Publish obfuscated proving and verification programs as the reference string.
  3. The prover supplies a statement and witness to the proving program.
  4. For a valid witness, return the statement's function value as the proof.
  5. Check it with the public verification program.

What to watch for

Perfect zero knowledge concerns the proof distribution, not unconditional soundness. The displayed soundness argument fixes the false statement before setup; it does not establish adaptive soundness or knowledge extraction.

Papers

Oracle commitments and succinct-argument compilation

Compile PCP, IOP and polynomial-oracle checks into arguments using commitments and transcript transforms. Includes SNARK and STARK construction routes without assigning all of them zero knowledge.

KiloNova

KiloNova is a preprocessing recursive SNARK for machine execution using holographic folding.

Papers

PIOP compilation with polynomial commitments

This compiler commits to polynomial oracles and converts their interactive checks into a SNARK.

Papers

STARK

STARKs combine computation arithmetization with low-degree testing and oracle commitments.

Papers

Proofs from MPC, garbling and authenticated correlations

MPC-in-the-head, garbling-based proofs and interactive proofs using OT or VOLE-authenticated values. Private-computation primitives and their preprocessing are owned by MPC.

QuickSilver

QuickSilver provides interactive proofs for circuits and polynomial relations over fields.

Papers

TurboIKOS

TurboIKOS uses Beaver-triple sacrificing within an MPC-in-the-head circuit proof.

Papers

ZKB++

ZKB++ is a Boolean-circuit proof protocol in the MPC-in-the-head line.

Papers

ZKBoo

ZKBoo constructs Boolean-circuit arguments using MPC-in-the-head transcripts.

Papers

Transcript transforms and round reduction

Fiat-Shamir and other noninteractive transforms, challenge repetition, abort handling and round elimination. Hashing a transcript alone does not establish transform security.

AHE-backed Sigma compiler

This compiler augments a Sigma protocol with homomorphic encryption before applying Fiat-Shamir.

Papers

Batched Fischlin transform

This variant applies Fischlin compilation to batches of proof statements.

Papers

COCO lifting

COCO is a generic lifting transformation applied to SNARKs.

Papers

Commit-and-open round elimination

This transformation collapses initial rounds of multi-round identification protocols.

Papers

Duplex-sponge Fiat-Shamir

This Fiat-Shamir variant absorbs and squeezes transcript data through a duplex sponge.

Papers

Extended Unruh transform for five-pass identification

This extension of Unruh compilation applies to five-pass identification schemes.

Papers

Fiat-Shamir transform

The Fiat-Shamir transform replaces a verifier's random challenges with challenges computed by hashing the public claim and the proof transcript. This can turn an interactive protocol into a proof that can be sent as one object.

Why it is useful

The prover no longer needs a live verifier to send each challenge during the protocol.

How it works

  1. Start with an appropriate protocol whose verifier sends public random challenges.
  2. Encode the statement and the relevant messages already fixed by the prover.
  3. Hash that information to derive the next challenge.
  4. Let the verifier reconstruct the same challenges when checking the completed proof.

What to watch for

The transform is not automatically sound for every protocol. The proof must justify the construction and the data included in each hash; the paper does this for its logarithmic-round halving protocol.

Related ideas

Papers

Strong Fiat-Shamir

In this use of Fiat-Shamir, the challenge is bound to the statement being proved as well as the prover's commitment. The verifier and prover must hash the same complete statement.

Why it is useful

If a prover can change the claimed result after seeing a challenge, a proof may certify a different statement from the one the verifier intended.

How it works

  1. Fix the public input and the claimed output before deriving the challenge.
  2. Include those values and the relevant proof message in the hash input.
  3. Recompute the challenge from those same values during verification.

What to watch for

Which fields must be included depends on the protocol. This paper specifically explains why omitting the claimed VDF output lets a prover construct an incorrect statement that passes a reduction step.

Papers

Fischlin transform

Fischlin compilation requires multiple accepting transcripts selected through a proof-of-work mechanism.

Papers

Fixed-weight challenge repetition

Fixed-weight repetition restricts challenge vectors to have a fixed number of designated entries.

Papers

Lamassu

Lamassu uses key-homomorphic signatures in a generic SNARK-lifting transformation.

Papers

OCOCO

OCOCO modifies the COCO SNARK-lifting construction.

Papers

Randomized Fischlin transform

This compiler variant randomizes Fischlin compilation for Sigma protocols.

Papers

Unruh transform

Unruh compilation converts an interactive proof into a non-interactive proof.

Papers

VOProof

VOProof compiles vector-oracle protocols into SNARKs.

Papers

Weak Fiat-Shamir

This Fiat-Shamir variant hashes the prover commitment without the statement.

Papers

Proof privacy, soundness and composition models

Security definitions for proof systems rather than a partition by computational assumption. Concrete constructions may satisfy only a subset.

Fractal

Fractal uses holographic preprocessing proofs for recursive SNARK composition.

Papers

Poppins

Poppins combines polynomial, inner-product, and Hadamard-product arguments with proof composition.

Papers

Knowledge extraction and compositional soundness

Soundness errors, knowledge extraction, simulation soundness, non-malleability and extraction under composition. Fiat-Shamir and quantum access require their own model checks.

Soundness and knowledge soundness

Soundness prevents convincing proofs of false statements. Knowledge soundness adds an extraction requirement: a successful prover must have enough information for the specified extractor to recover a valid witness.

Why it is useful

A true statement may have a witness that the prover does not know. Knowledge soundness distinguishes this case from ordinary truth of the statement.

How it works

  1. Specify the prover's allowed information and computation.
  2. Define when the verifier accepts.
  3. For knowledge soundness, give the extractor the access allowed by the definition.
  4. Require extraction to succeed except with the stated small probability whenever the prover succeeds.

What to watch for

The extractor in this paper can inspect the adversary's state and coins. It is not an ordinary verifier extracting a secret from a published proof. The paper also restricts auxiliary-input generation; arbitrary auxiliary inputs are not covered without qualification.

Useful background: Statements, witnesses and proof relations.

Papers

Special soundness of three-move proofs

Special soundness extracts a witness from two accepting transcripts with the same first prover message and different verifier challenges.

Why it is useful

It explains how responding successfully to unpredictable challenges can demonstrate knowledge rather than merely producing one plausible transcript.

How it works

  1. Hold the public statement and first prover message fixed.
  2. Obtain accepting responses to two distinct challenges.
  3. Subtract the response equations.
  4. Divide by the nonzero challenge difference to recover witness information.

What to watch for

One accepting transcript does not give an extractor two challenges. Exceptional zero values and computational assumptions can affect whether the recovered information is a valid witness; a noninteractive proof needs its own transform analysis.

Papers

Zero knowledge and witness privacy

Simulation-based zero knowledge, witness indistinguishability and witness hiding, including auxiliary-input and concurrent settings. These notions are not interchangeable.

BubbleRAM

BubbleRAM is a read-write memory construction for a garbling-based zero-knowledge processor.

Papers

Honest-verifier zero knowledge with setup leakage

An honest-verifier zero-knowledge argument simulates transcripts for a verifier following the challenge rule. In this paper's BBS proofs, the simulator is additionally given a random group pair related by the signing secret.

Why it is useful

The leakage allowance makes explicit which information the simulator needs for the type-3 pairing setting, rather than claiming simulation from the verification key alone.

How it works

  1. Define the real proof transcript.
  2. Specify the extra setup-related input allowed to the simulator.
  3. Generate a simulated transcript without the hidden attributes or signature witness.
  4. Compare the resulting distributions under that precise definition.

What to watch for

This is a qualified simulation notion. The paper explains that a valid message-signature pair already provides the relevant related group pair, but a complete credential-system privacy claim still needs a system-level proof.

Papers

Proving nullifier validity in zero knowledge

The published nullifier comes with a zero-knowledge SNARK stating that the value was computed from a secret key whose public key belongs to an approved set, without revealing which key.

Why it is useful

Naming the public key would defeat the purpose, since anyone could look the account up. The proof keeps the key inside the witness while the nullifier and the membership claim become public.

How it works

  1. The secure enclave emits the signals that depend on the secret key; a client-side prover builds the SNARK outside the enclave.
  2. The circuit checks the challenge hash, which implicitly checks the enclave arithmetic, and adds application checks such as membership of the public key in a Merkle tree.
  3. Only the nullifier, the response value and the proof go on chain.
  4. A SNARK is chosen over a Sigma protocol so that applications can add their own checks inside the same proof.

What to watch for

Zero knowledge protects the inputs of the proof, not the nullifier itself. The nullifier is public by design and becomes recognizable the moment an attacker learns the underlying key.

Useful background: PLUME: computing the nullifier inside a secure enclave.

Papers

Zero knowledge through simulation

Zero knowledge compares real proofs with proofs produced by a simulator that does not receive the witness. If the distributions are identical, the property is perfect zero knowledge; weaker definitions allow statistical or computational indistinguishability.

Why it is useful

It states precisely what it means for a proof not to disclose witness information beyond its public claim.

How it works

  1. Specify the statement and setup information available to the observer.
  2. Generate a real proof using a witness.
  3. Generate a simulated proof using the simulator's permitted information.
  4. Compare the two distributions under the chosen privacy definition.

What to watch for

Simulation may use a trapdoor unavailable to real attackers. Public statements can still reveal sensitive facts, and zero knowledge does not provide soundness by itself.

Useful background: Statements, witnesses and proof relations.

Papers

Zero-knowledge vSQL variant

This vSQL variant adapts the database proof system for witness-hiding queries.

Papers

Prover algorithms and resource tradeoffs

Protocol-specific time, space, streaming, batching and scheduling improvements, including opening generation and sumcheck algorithms. Generic MSM, FFT and hardware kernels belong under implementation or mathematics.

Cauchy-matrix KZG proof representation

Cauchyproofs represents KZG opening computations with Cauchy matrices.

Papers

Epistle

Epistle is an elastic SNARK for PLONK constraints with streaming prover configurations.

Papers

Equality-factor sumcheck optimization

This optimization exploits the decomposable tensor structure of an equality-polynomial factor.

Papers

Fast amortized KZG proof generation

This algorithm computes batches of KZG opening proofs for a polynomial.

Papers

Fold-and-Batch

Fold-and-Batch performs partial FRI folding locally before a central batched FRI protocol.

Papers

FRI proof packing

Packing places polynomial evaluations in shared Merkle leaves and combines their validity functions.

Papers

Gemini (elastic SNARK)

Gemini proves R1CS with configurable streaming and in-memory prover execution.

Papers

GUO accumulator proof batching

These batching methods combine membership and non-membership proofs for unknown-order accumulators.

Papers

High-degree product sumcheck prover

This algorithm specializes sumcheck proving for products of many multilinear polynomials.

Papers

Inverted expander graphs

Inverted expander graphs reorganize Spielman encoding memory accesses.

Papers

Lossless-expander testing for provers

This algorithm checks sampled bipartite graphs for the expander property needed by code-based provers.

Papers

Modular split-and-pack

Modular split-and-pack divides a witness into sub-witnesses and packs their proof checks.

Papers

Multilinear sumcheck time-space algorithms

This family exposes selectable time-space configurations for a multilinear sumcheck prover.

Papers

On-the-fly expander sampling

This encoding algorithm generates expander graphs on-chip instead of streaming their stored descriptions.

Papers

Packed interleaved Merkle layout

UltraFold arranges partially encoded values into interleaved Merkle leaves and packs the trees.

Papers

Shred-to-shine

Shred-to-shine partitions a committed polynomial into independently handled fragments.

Papers

Small-value sumcheck prover

This sumcheck algorithm handles bounded integers and small-subfield evaluations using smaller-domain operations.

Papers

Streaming product sumcheck prover

This streaming prover handles sumcheck claims about products of multilinear polynomials.

Papers

Subfield-oriented sumcheck prover

This prover moves multiplications into a base field when evaluating polynomials over an extension field.

Papers

Statement encoding and proof front ends

Represent programs and mathematical claims as relations accepted by proof protocols. Compiler correctness and witness assignment are separate from backend soundness.

Cairo architecture

Cairo is a CPU architecture whose program executions are expressed by polynomial equations.

Papers

CoBBl

CoBBl combines direct compilation with CPU emulation to generate constraints for executed program paths.

Papers

eAIR

eAIR extends AIR for the additional relations used by eSTARK.

Papers

Eden ISA

Eden encodes the Nock combinator model using Dyck encodings for use in proof systems.

Papers

First-order polynomial semantics

This translation maps first-order logical connectives compositionally to operations on polynomials.

Papers

FREPack

FREPack is a front-end transformation for repeated computations crossing small-field and large-field circuit representations.

Papers

Hadamard product relation

HPR represents arithmetic circuit relations through Hadamard products.

Papers

High-dimensional R1CS

HD-R1CS encodes matrix-circuit satisfiability with structured sparse matrices.

Papers

Multi-QAPs

Multi-QAPs organize shared state across computations in Geppetto.

Papers

PLONK constraint system

The PLONK constraint system is a circuit format targeted by the Plonkify transpiler.

Papers

Plonkify

Plonkify translates R1CS circuits to PLONK circuits with vanilla or custom gates.

Papers

Power circuits

Power circuits use linear operations and squaring to express wiring for layered-circuit proofs.

Papers

Quadratic ring programs

QRPs characterize NP computations with arithmetic over a ring.

Papers

R1CS-lite

R1CS-lite is a variant of R1CS used by constructions in Lunar.

Papers

Square arithmetic programs

SAP is an arithmetic constraint representation used by Polymath.

Papers

Square span programs

SSPs encode NP statements using a single series of polynomials.

Papers

Switchboard circuits

Switchboard circuits combine instruction circuits while allowing unused constraints to be turned off.

Papers

TinyRAM

TinyRAM is a random-access machine model tailored to program-execution proofs.

Papers

ZMIPS

ZMIPS is a MIPS-like processor model used to compose instruction-execution proofs.

Papers

Arithmetic, encoding and cryptographic gadgets

Reusable relations for bits, ranges, integers, non-native arithmetic and cryptographic operations, including consistency between representations. Standalone range arguments also link to committed relations.

Cross-Modulus Consistency PIOP

CMC checks whether witnesses over coprime moduli encode the same canonical integer.

Papers

GlueLUT

GlueLUT performs residue-ring lookups through an auxiliary field and cross-modulus consistency checks.

Papers

Symphony (folding-based SNARK)

Symphony compiles high-arity lattice folding into SNARKs without embedding hash computations in recursive circuits.

Papers

Circuit constraints and algebraic representations

A proof circuit represents a claim as equations over a finite field. Public variables describe the statement; private variables include the witness and intermediate values. Multiplication constraints and linear combinations can be collected into a QAP for a pairing-based argument. Field equations alone do not impose integer ranges, Boolean values or the intended meaning of an application input.

Arithmetic constraints over a field

An arithmetic constraint can require that one weighted sum of wire values times another weighted sum equals a third. A collection of these constraints describes which assignments are valid.

Why it is useful

It translates a computation into algebraic conditions that a proof system can check.

How it works

  1. Assign field variables to public inputs and private wires.
  2. Reserve a fixed variable a0=1 to express constants.
  3. Encode multiplication and linear combinations with weighted-sum equations.
  4. Require every constraint to hold for the same assignment.

Example

Over the field with 7 elements, 3 times 3 equals 2. That equation is correct in the field, even though the corresponding integer equation is false.

What to watch for

Field arithmetic wraps modulo the field characteristic. Boolean values, integer comparisons, overflow rules and byte encodings need their own constraints when the intended application requires them.

Papers

Customizable constraint system

CCS is a constraint representation generalizing R1CS, Plonkish constraints, and AIR.

Papers

Hamming-weight bits from symmetric polynomials

The bits of the number of ones in a Boolean vector can be written as elementary symmetric polynomials over the two-element field. Bit i is the parity of the degree-2^i elementary symmetric polynomial.

Why it is useful

It converts counting into algebraic operations and helps the paper build a low-degree decryption computation for sparse inputs.

How it works

  1. Form products of distinct input bits and sum products of the required degree modulo two.
  2. Read the resulting parity as the selected bit of the Hamming weight.
  3. Compute the needed coefficients incrementally rather than enumerating every subset.
  4. Use a known weight bound to avoid computing unnecessary high bits.

Example

The second bit of a count is the XOR of all pairwise products. For three one-bits there are three such products, so that bit is 1, as in the binary count 11.

What to watch for

The identity assumes Boolean inputs and arithmetic modulo two. Degree and circuit depth are different measures; the paper's dynamic program need not be shallow to compute a low-degree polynomial.

Papers

HyperNova

HyperNova uses folding for incremental computations expressed with customizable constraint systems.

Papers

PANCAKE

PANCAKE combines wiring and addition constraints into general linear constraints for Plonkish proofs.

Papers

Pinocchio

Pinocchio proves computations described by quadratic arithmetic programs.

Papers

Plonkish constraint systems

Plonkish constraints describe circuits with configurable gate relations and wiring constraints.

Papers

Quadratic arithmetic programs

A quadratic arithmetic program, or QAP, combines many arithmetic constraints into one polynomial divisibility condition.

Why it is useful

It gives the proof system an algebraic way to check that every gate uses a consistent assignment.

How it works

  1. Choose a distinct field point for each constraint.
  2. Interpolate polynomials describing the left input, right input and output coefficients at those points.
  3. Combine those polynomials using the wire assignment.
  4. Require the product of the two input polynomials minus the output polynomial to be divisible by the polynomial vanishing at every constraint point.

Example

To prove that public z is a fourth power, introduce private x and y and constrain x*x=y and y*y=z. The QAP combines these two constraints without making x or y public.

What to watch for

The points must be distinct and the field large enough. The QAP only represents the constraints supplied to it; correctness of a compiler or application circuit is a separate obligation.

Useful background: Arithmetic constraints over a field, Vanishing polynomials.

Related ideas

  • Groth16: Uses a QAP as the relation proved by its three-element argument.

Papers

Rank-1 constraint system

R1CS expresses circuit relations using rank-one multiplicative constraints.

Papers

Spartan++

Spartan++ uses Shout for SNARKs over customizable constraint systems.

Papers

Universal constraint systems

UCS combines algebraic constraints and ideal-membership predicates over multiple polynomial rings.

Papers

Zinc+

Zinc+ builds SNARKs for algebraic and ideal-membership constraints over polynomial rings.

Papers

Execution traces, control flow and machine semantics

Trace and transition encodings, instruction sets, dynamic control flow and non-uniform execution. Whole-machine proof systems belong under verifiable computation.

Algebraic intermediate representation

AIR encodes computational integrity statements for STARKs as algebraic constraints.

Papers

BabySpartan

BabySpartan combines SuperSpartan and Lasso for non-uniform constraint systems.

Papers

Preprocessed AIR

PAIR is the preprocessed variant of algebraic intermediate representation studied for STARKs.

Papers

SpeedySpartan

SpeedySpartan uses Shout for SNARKs over non-uniform Plonkish constraints.

Papers

Memory consistency and persistent state

Read-only, read-write, stack and queue relations, including initialization, ordering and persistent state commitments. Access-pattern privacy belongs under oblivious access.

Address cycle method

The address cycle method organizes memory consistency checks without sorting the entire memory trace.

Papers

gcq

gcq is a lookup-argument construction used with memory consistency checks.

Papers

Permem

Permem checks memory consistency using the address cycle method.

Papers

Persistent RAM algebraic arguments

These memory arguments address computations whose RAM has a maintained commitment.

Papers

Sparse persistent RAM algebraic arguments

These arguments specialize persistent-memory checking to sparse RAM.

Papers

Twist

Twist is a family of memory-checking protocols for read-write memories.

Papers

Volatile RAM algebraic arguments

These memory arguments address computations whose RAM is initially zero.

Papers

Table lookups, permutations and multiset relations

Membership in public or committed tables and equality of multisets or permutations, including indexed and updatable lookups. Memory chronology requires additional relations.

Baloo

Baloo is a lookup argument supporting commitments to the subtable used by a prover.

Papers

BiPerm

BiPerm reduces permutation checking to sumcheck with restrictions on the commitment interface.

Papers

Caulk

Caulk uses position-hiding linkability of vector commitments for membership and lookup arguments.

Papers

Caulk+

Caulk+ replaces a Caulk subprotocol with a polynomial divisibility check.

Papers

Celer

Celer is a lookup argument for workloads with many queries relative to table entries.

Papers

Committed index lookup

Committed index lookup is a sub-vector relation with committed indices used to model RAM updates.

Papers

cq

cq uses cached quotients for table lookups.

Papers

cq+

cq+ is a lookup-argument variant in the cq line of constructions.

Papers

cq++

cq++ is a lookup-argument variant in the cq line of constructions.

Papers

DUPLEX (RSA-group lookup)

DUPLEX constructs lookup arguments over an RSA group.

Papers

flookup

flookup is a lookup argument based on fractional decomposition.

Papers

Generalized pole multiplicities for LogUp

This LogUp technique abstracts pole multiplicities to handle field-characteristic restrictions.

Papers

GlueLUT-v1

This GlueLUT variant targets residue rings whose modulus is a product of two primes.

Papers

GlueLUT-v2

This GlueLUT variant targets residue rings whose modulus is a prime power.

Papers

Grand-product permutation checks

PLONK uses grand products to compare permutations of wire values.

Papers

HyperPianist+

HyperPianist+ adds a Lasso-based lookup argument to HyperPianist.

Papers

Lasso

Lasso is a lookup-argument family using multilinear commitments and structured tables.

Papers

Locq

Locq builds a lookup argument using the Losum component.

Papers

LogSpartan

LogSpartan is a multilinear PIOP for R1CS using lookup-argument techniques.

Papers

LogUp

LogUp is a logarithmic-derivative lookup argument using multiplicities of table entries.

Papers

LogUp over rings

LogUp over rings adapts its field-based lookup PIOP to a cyclotomic residue ring.

Papers

Logup*

Logup* adapts LogUp to indexed lookups in small tables.

Papers

MPlookup

MPlookup is a collaborative lookup argument over secret-shared data.

Papers

Multilinear cq-style lookup

This cq-inspired lookup construction uses multilinear polynomial encodings for compatibility with multilinear SNARKs.

Papers

One-hot addressing and increments

This method represents memory accesses using one-hot addressing and increments.

Papers

Paired-access stack checks

This stack memory check pairs reads with writes to specialize a RAM construction.

Papers

Permutation-matrix multilinear checking

This method represents a permutation by the multilinear extension of its permutation matrix.

Papers

Plookup

Plookup checks that committed polynomial values lie in a table.

Papers

Plookup over rings

Plookup over rings adapts its field-based lookup PIOP to a cyclotomic residue ring.

Papers

Queue checks by polynomial evaluation

This queue check compares ordered read and write sequences through random polynomial evaluations.

Papers

RapidUp

RapidUp is a multi-domain permutation protocol for lookup tables.

Papers

Reciprocal set-membership arguments

These arguments use reciprocal relations for set-membership checks within Bulletproofs++.

Papers

Rogue

Rogue supports updatable matrix lookups for verifiable databases.

Papers

Shout

Shout is a family of lookup protocols for read-only memories.

Papers

Two-shuffle arithmetic RAM

This arithmetic RAM construction uses shuffles for read-write memory checks in circuit-based proofs.

Papers

Univariate-to-multilinear lookup compiler

This compiler converts univariate-compatible lookup arguments into multilinear-compatible lookup arguments.

Papers

Updatable lookup arguments

Updatable lookup arguments permit table changes between lookup proofs.

Papers

zkcq+

zkcq+ is a lookup-argument variant in the cq line of constructions.

Papers

Grand-product and permutation arguments

Products used to check permutation, multiset and table relations.

MulPerm

MulPerm is a permutation argument formulated for a general polynomial commitment interface.

Papers

PLONK

PLONK combines subgroup-evaluation arithmetization with a permutation argument.

Papers

Logarithmic-derivative lookups

Lookup arguments built from rational-function identities and logarithmic derivatives.

Fractional sumcheck via GKR

This GKR instantiation proves sums of fractions appearing in logarithmic-derivative lookups.

Papers

GKR-based LogUp

This LogUp variant uses GKR to prove the fractional relations in logarithmic-derivative lookups.

Papers

Verifiable computation and delegated services

Verify computations or storage services performed elsewhere, with or without zero knowledge. Delegating the application and delegating proof generation are separate roles.

Buffet

Buffet compiles C programs with RAM accesses and dynamic control flow for verifiable computation.

Papers

Ginger

Ginger extends Pepper for outsourced computation with a broader computational model.

Papers

Pantry

Pantry composes verifiable computation with untrusted storage through state digests.

Papers

Pepper (verifiable computation)

Pepper combines PCP machinery with cryptographic techniques for interactive verification of outsourced computation.

Papers

Database, storage and application-specific verification

Proofs for queries, authenticated data, stateful services and specialized workloads such as machine learning, plus data possession and retrievability. Integrity and recoverability are distinct service guarantees.

ADSNARK

ADSNARK proves computations over data authenticated by another party.

Papers

Spice (verifiable state machines)

Spice builds verifiable state machines for request-processing services, including concurrent services.

Papers

vSQL

vSQL proves SQL queries over dynamic outsourced databases.

Papers

Outsourced, collaborative and distributed proving

Parallel proof generation, MPC-assisted proving and proving over encrypted inputs. Worker parallelism does not by itself keep witnesses private from workers or coordinators.

DFS

DFS co-designs a SNARK with multiparty computation for delegated proof generation.

Papers

DIZK

DIZK distributes proof generation across a compute cluster.

Papers

Phalanx

Phalanx is a SNARK designed for homomorphic evaluation of proofs over encrypted data.

Papers

Verifiable machines and program execution

End-to-end proof systems for processor, virtual-machine and high-level program execution. A zkVM name does not establish which inputs or execution details a variant hides.

Jolt (lookup-based zkVM front-end)

Jolt translates instruction-set programs into lookup-centered constraints for a zkVM.

Papers

Non-interactive zero knowledge

Zero-knowledge proofs sent as a single message, usually enabled by a shared reference string or by the Fiat-Shamir transformation, including zaps and quasi-adaptive variants.

Committing to a tuple as one lifted polynomial

A commitment scheme locks a value without revealing it, and lets the sender open it later. The paper commits to a whole tuple a = (a1, ..., an) at once with a constant number of group elements: pick one secret exponent x, publish generators whose exponents are powers x raised to chosen values, and let the commitment be the group element whose exponent is the polynomial r plus the sum of ai times x to the lambda_i. The committer evaluates this lifted polynomial from the published generators while never learning x.

Why it is useful

One short object then carries n values and is homomorphic, so sums of tuples can be checked by multiplying commitments. A second copy of the commitment, computed under a second secret times x, makes it a knowledge commitment: whoever produces one can be forced to reveal the hidden coefficients.

How it works

  1. CRS generation picks secrets x and a second secret, and publishes the needed powers g to the x-lambda and their doubled-secret copies for every exponent lambda in a chosen set.
  2. Commitment: multiply the published generators raised to the tuple entries, with fresh randomness r.
  3. Validity is checked by a pairing equation linking the commitment and its doubled-secret copy.
  4. The trapdoor is x itself: whoever knows it can open an equivocal commitment to any tuple.

What to watch for

Binding is only computational, and the trapdoor x breaks binding completely, so it must stay with the CRS generator and with the simulator.

Useful background: Bilinear pairings.

Related ideas

  • Pedersen commitment: the scheme being extended

Papers

Composing basic arguments into a Circuit-SAT proof, and simulating it

The final construction treats Hadamard product, permutation and entry-wise sum as the basic operations of a small programming language for NP: a circuit is compiled into a constant number of parallel sub-arguments over tuples of dimension twice the circuit size plus one, each verified by pairing equations. The simulator, holding the CRS trapdoor, commits to all-zero tuples and still produces arguments perfectly distributed like real ones.

Why it is useful

Each sub-argument alone is not zero-knowledge, but the composed argument is: the simulator creates every commitment itself, so it can open them to whatever makes the sub-arguments go through.

How it works

  1. The prover commits to every wire value; the circuit structure is described by public permutations, one grouping wires that must carry equal values and one matching inputs to outputs.
  2. A product argument enforces the gates: left input times right input equals one minus output, with the last gate forced to output one.
  3. Permutation arguments enforce wire consistency between gate outputs and the inputs they feed.
  4. The simulator generates the CRS together with the trapdoor, commits to all-zero tuples, and simulates every sub-argument using fake satisfying values.

What to watch for

Soundness of the composition extracts openings from every commitment through the knowledge assumption and then applies each sub-argument’s weak soundness; the perfect zero knowledge holds in the CRS model with the simulator controlling the trapdoor.

Useful background: The Hadamard product argument in one pairing equation, Permutation arguments and the Moser-de Bruijn obstacle, Why the security needs a knowledge assumption.

Papers

Groth-Sahai proofs

A general recipe for non-interactive proofs about equations in pairing groups. The prover publishes a commitment to each secret value plus one short correction term per equation, and anyone can check the claim by evaluating pairings. Proof size is a constant number of group elements per secret variable and per equation, instead of growing through a circuit reduction.

Why it is useful

Non-interactive zero-knowledge proofs existed for all of NP before this work, but converting a natural cryptographic statement into a Boolean circuit produced proofs with thousands of group elements. Proving the pairing equations directly removes that blowup and made such proofs usable inside protocols.

How it works

  1. Write the statement as a set of equations over the bilinear groups: pairing product equations, multi-scalar multiplication equations in either source group, and quadratic equations among the exponents.
  2. Commit to every secret value once, using a homomorphic commitment built from the same groups.
  3. Substitute the commitments into each equation and publish the extra terms created by the commitment randomness as the proof.
  4. The verifier re-checks each equation with pairings, using the published correction terms.
  5. Each extra equation costs a fixed number of group elements: one in the subgroup decision setting, two per variable under SXDH and three under DLIN.

Example

A proof in the composite-order subgroup decision setting uses one group element per secret variable and one per equation - this count is an illustration from the paper, not a parameter recommendation.

What to watch for

The framework covers statements expressible as these equations; arbitrary programs still have to be encoded as such equations first, each instantiation depends on a pairing-based hardness assumption, and the size counts are in group elements whose bit lengths differ between the settings.

Useful background: Bilinear pairings, Common reference string.

Related ideas

Papers

Permutation arguments and the Moser-de Bruijn obstacle

A permutation argument proves that committed tuple b is the rearrangement of committed tuple a under a public permutation, entry by entry. Applying the same monomial technique now demands that every integer have at most one representation of the form twice lambda k plus lambda j, which forces the exponent set into the Moser-de Bruijn sequence - the numbers whose base-4 digits are only 0 or 1 - whose largest element grows quadratically, cancelling the whole improvement.

Why it is useful

Wire consistency in a circuit, meaning that a gate input equals the output of its predecessor gate, is exactly a permutation check, so Circuit-SAT cannot drop it. The repair keeps the quasilinear CRS.

How it works

  1. Define a public, easily computed multiplier for each position: the number of j for which the two colliding representations coincide.
  2. The pairing argument then guarantees a weaker claim: the rearranged entry equals that multiplier times the committed entry.
  3. Commit separately to the scaled tuple, prove the scaling with one extra Hadamard product argument, and combine the two claims to recover the plain permutation statement.

What to watch for

The repair costs communication - the new permutation argument uses 12 group elements against Groth’s 5 - and when the permutation is part of the statement the verifier performs linearly many group multiplications, though these can be precomputed for a fixed permutation.

Useful background: The Hadamard product argument in one pairing equation, Progression-free sets and Elkin's bound.

Papers

Progression-free sets and Elkin's bound

A set of positive integers is progression-free if no three of its elements form an arithmetic progression, that is, lambda i plus lambda j equals twice lambda k only in the trivial case where all three coincide. The paper needs such sets because soundness requires the doubled exponents to avoid the pairwise sums of distinct exponents, and that condition is exactly the no-progression condition; taking the integers odd keeps the set away from the doubled exponents.

Why it is useful

The CRS length is bounded by roughly twice the largest exponent used, so a denser progression-free set inside a range means a shorter CRS. Constructions of Behrend and Elkin supply such a set with largest element about n to the power 1+o(1).

How it works

  1. Pick the exponent set as a large progression-free set of odd integers.
  2. Elkin’s set of integers can be shifted to odd integers by mapping each element to twice it plus one, keeping the size bound.
  3. The set is efficiently constructible in quasi-linear time, so the CRS generator can actually build it.

What to watch for

The savings are asymptotic: the o(1) shrinks slowly, and upper bounds of Bourgain and Sanders show that the range must grow faster than any constant multiple of n, so quasilinear is close to the best possible.

Useful background: The Hadamard product argument in one pairing equation.

Related ideas

Papers

Subgroup decision, SXDH and DLIN instantiations

Three concrete ways to realize the two key flavors. Composite-order groups where a random element of a hidden subgroup is indistinguishable from a random element of the full group (subgroup decision); prime-order asymmetric pairing groups where decision Diffie-Hellman is hard in both source groups (SXDH); and prime-order groups where the decisional linear problem is hard (DLIN).

Why it is useful

The abstract framework needs only one property: binding and hiding setups that cannot be told apart. Each assumption supplies that property in a different group setting, with different commitment sizes - one group element per commitment under subgroup decision, two under SXDH, three under DLIN.

How it works

  1. Subgroup decision: publish one group element as the commitment key, generated either in the order-q subgroup (binding) or of full order (hiding).
  2. SXDH: commitments are ElGamal-style pairs in one source group; the second key element is either a multiple of the first (binding) or a multiple shifted off the diagonal (hiding).
  3. DLIN: commitments are triples from linear encryption; the third key element is either a combination of the first two (binding) or shifted away from their span (hiding).
  4. In each case the stated assumption is exactly the statement that the binding and hiding key distributions are computationally indistinguishable.

What to watch for

The cost tables count group elements, not bits: element sizes differ between the settings, and the paper expects the SXDH instantiation to give the smallest proofs only once element sizes are taken into account; SXDH additionally requires two distinct source groups with hard Diffie-Hellman in each, which restricts curve choices.

Useful background: Groth-Sahai proofs, Binding and hiding commitment keys over modules, Decisional Diffie-Hellman assumption.

Papers

The Hadamard product argument in one pairing equation

Given commitments to tuples a, b and c, this argument proves that ai times bi equals ci at every position, using one pairing equation. A pairing is a map that sends two group elements to a third group and turns products into products, so the single equation is really a statement about the exponents behind the commitments.

Why it is useful

Entry-wise product constraints are the heart of circuit satisfiability - a NAND gate is exactly such a constraint - and all n of them are checked at once.

How it works

  1. Commit to a, b and c; a fixed CRS element commits to the all-one tuple.
  2. Take the exponent difference F(x) and split it: the constraint polynomial has coefficient ai bi minus ci on one monomial per constraint, which is zero exactly when that constraint holds.
  3. An honest prover, whose constraint polynomial vanishes, computes the group element for the remaining argument polynomial from CRS generators.
  4. For soundness the CRS must contain the powers of the argument polynomial but never the powers of the constraint polynomial, and the two power sets must be disjoint.

What to watch for

Stood alone the argument is only weakly sound: the commitment to c always opens to the entry-wise product for some randomness, so soundness is stated for provers that also reveal openings; the sub-argument by itself is not zero-knowledge either.

Useful background: Committing to a tuple as one lifted polynomial, What a NIZK argument must guarantee.

Papers

Turning witness-indistinguishable proofs into zero-knowledge proofs

An upgrade trick for the same proof system. Introduce one extra secret variable standing for the number one, move each equation's public right-hand side into the equation multiplied by that variable, and the all-zero assignment becomes a satisfying witness. The simulator holds a trapdoor that opens a commitment of one as a commitment of zero, then runs the ordinary prover with the trivial witness.

Why it is useful

The simulator of a zero-knowledge proof must answer statements without knowing a real witness. After the rewrite it always knows the trivial witness, and because commitments on the simulation string are perfectly hiding, simulated proofs are distributed exactly like real ones.

How it works

  1. The simulator generates a hiding common reference string together with a trapdoor that equivocates one special commitment.
  2. Each equation is rewritten so its public target becomes a term in the new variable, making the all-zero assignment a valid witness.
  3. The simulator commits to all zeros, opens the special commitment as zero using the trapdoor, and produces the usual correction terms.
  4. The resulting proofs are exactly the same objects as honest proofs, so there is no extra cost for the equation types where this works.

What to watch for

For pairing product equations with an arbitrary target the paper gives no zero-knowledge version, only witness-indistinguishable ones; zero knowledge is available when every target equals one or factors into pairings of known elements, and the zero-knowledge proof of an equation can be larger than its witness-indistinguishable proof.

Useful background: Witness indistinguishability versus zero knowledge, Binding and hiding commitment keys over modules.

Papers

What a NIZK argument must guarantee

Four formal properties define the target. Perfect completeness: an honest prover is always accepted. Adaptive computational soundness: after seeing the CRS, no efficient adversary can make a false statement accept except with negligible probability. Perfect witness indistinguishability: any two witnesses of the same statement yield identically distributed arguments. Perfect zero knowledge: a simulator with a trapdoor can produce arguments with exactly the real distribution, without any witness.

Why it is useful

Adaptive matters because the cheating prover picks its false statement after studying the CRS. Computational marks the difference between an argument and a proof: soundness holds only against efficient provers and under assumptions, while the privacy properties are exact, distribution-level statements.

How it works

  1. Completeness: for every true statement and valid witness, verification accepts.
  2. Soundness: a CRS, a false statement and an accepting argument cannot be produced together by any efficient adversary.
  3. Witness indistinguishability: the argument carries no information about which witness was used.
  4. Zero knowledge: the simulator first generates the CRS together with a trapdoor, then answers statements without the witness, and the joint distribution matches the real experiment.

What to watch for

The definitions are about whole distributions, not single runs; the simulator experiment is what makes privacy checkable without knowing what leakage would look like.

Useful background: Non-interactive zero knowledge and the common reference string.

Papers

Witness indistinguishability versus zero knowledge

Two privacy notions for proofs. Witness indistinguishability says the proof does not reveal which of several possible witnesses the prover used. Zero knowledge is stronger: a simulator that knows only a trapdoor can produce proofs with the same distribution without any witness at all, so the proof can be simulated and hence leaks nothing.

Why it is useful

Many pairing statements have several witnesses, and for some of them no simulator can find any witness, so the weaker notion is what is available; the paper therefore builds witness-indistinguishable proofs first and upgrades to zero knowledge only where possible.

How it works

  1. Witness indistinguishable: proofs built from different witnesses of the same statement are identically distributed.
  2. Composable witness indistinguishability strengthens this: a simulated common reference string is indistinguishable from the real one, and on the simulated string proofs reveal nothing about the witness.
  3. Zero knowledge: a two-part simulator first generates the string together with a trapdoor, then answers any statement without a witness.
  4. Composable zero knowledge adds that even an adversary holding the simulation trapdoor cannot tell real proofs from simulated ones on a simulated string.

What to watch for

Witness indistinguishability does not hide information that is common to all witnesses, so it is not a drop-in substitute for zero knowledge in anonymous credentials or voting; the composable variants also presume the shared string model.

Useful background: Groth-Sahai proofs, Zero-knowledge proof.

Papers

Succinct arguments and SNARKs

A succinct argument is a proof whose size grows slowly, here logarithmically in the number of constraints, and whose verification is meant to be cheap. Bulletproofs achieve logarithmic size and no trusted setup from the discrete log assumption alone, but verification time still grows linearly with the witness size, so they trade verifier cost for transparency and short transcripts.

Batching many evaluations

Pending evaluation claims are combined with a random challenge into one claim, so a batch shares a single logarithmic argument and each extra item adds only a small amount.

Why it is useful

Applications open many polynomials at once, so marginal cost matters more than single-proof cost. Batching makes the verifier cost depend on the number of openings rather than on a fresh logarithm of the polynomial size for each one.

How it works

  1. Collect the pending claims and the cross terms between them.
  2. The verifier sends one random challenge per batch step.
  3. Both sides fold the claims together, keeping the number of live claims constant.
  4. Finish with one inner-product argument covering the whole batch.

Example

At around one million coefficients the paper reports each extra batched evaluation costing under a kilobyte, about thirty milliseconds of prover time and about one millisecond of verifier time, with roughly an eleven-fold prover saving over separate proofs.

What to watch for

Not everything batches: the field work on the evaluation vectors does not combine, so the verifier still pays a logarithmic number of field operations per extra evaluation. Small batches gain little; the quoted savings are for large ones.

Useful background: Prover and verifier costs.

Papers

Blinding the vectors for zero knowledge

The two vectors that satisfy the inner product identity would reveal the bits, so the prover sends linear polynomials in those vectors and evaluates them at a random point instead.

Why it is useful

The verifier still learns that the identity holds, because a low degree polynomial identity that holds at a random point holds everywhere, while the random evaluation hides the constant terms that contain the secret.

How it works

  1. Commit to two random blinding vectors alongside the bit vectors.
  2. Build two vector polynomials whose constant terms are the vectors of the inner product identity and whose linear terms are the blinding vectors.
  3. Commit to the non-constant coefficients of their inner product polynomial, which is quadratic, using two more commitments.
  4. After a random evaluation point is chosen, send the two evaluated vectors, the evaluated inner product, and the blinding values that make the commitments check out.

What to watch for

The evaluated vectors themselves are not secret once the blinding is in place, which is exactly why the next step can hand them to an argument that provides no zero knowledge of its own. Switching the second base vector to powers of a challenge lets the verifier form a commitment to a coordinate-wise product.

Useful background: Range proofs from bit constraints.

Related ideas

  • Bulletproofs: The proof system this blinding step protects.

Papers

Dory: transparent arguments for generalised inner products

Dory is a public-coin interactive argument for a generalised inner product: a sum of term-by-term products between two committed vectors, one made of points of the first source group of a pairing and the other of points of the second source group, so that each product lands in the target group.

Why it is useful

A general proof system for these products is the engine underneath a polynomial commitment: once you can prove that a committed matrix was folded correctly, you can prove that a committed polynomial evaluates to a claimed value. Dory reaches logarithmic communication and logarithmic verifier work with no trusted setup ceremony.

How it works

  1. Both parties fix public parameters: long lists of random group points that act as commitment keys.
  2. The prover commits to two vectors using those keys and states the claimed product.
  3. Over several rounds the verifier sends random field challenges and the claim shrinks to a single product of two group elements, checked with one pairing.
  4. The Fiat-Shamir transform then compiles the interaction into a non-interactive proof.

Example

For vectors of length n the proof is 6 log n target-group elements plus a constant number of extra elements, and the verifier does one O(log n) multi-exponentiation and O(1) pairings.

What to watch for

Soundness is computational, from the SXDH assumption on a pairing-friendly curve, and this is an argument rather than an information-theoretic proof. The scheme is interactive until Fiat-Shamir is applied.

Related ideas

  • Polynomial commitment interfaces: the application the argument is built for

Papers

Folding an inner product in half

Split both vectors into left and right halves. One random challenge rewrites the original inner-product claim as a claim about two half-length vectors, plus two small cross terms that the prover sends.

Why it is useful

Halving is what makes the proof short: repeat it log n times and the vectors have length one, so rounds and communication both grow only logarithmically.

How it works

  1. Cut each vector into a left and a right half.
  2. The prover sends the two cross inner products that the identity discards.
  3. The verifier replies with one random non-zero scalar.
  4. Both sides combine the halves with that scalar and obtain a claim about vectors half as long.
  5. Repeat down to length one, then finish with a small sigma protocol for a single product.

Example

With challenge a, the identity turns a claim about the concatenation of the halves into a claim about a-weighted sums of the halves, minus two correction terms the prover supplies.

What to watch for

Soundness is argued by rewinding: an extractor collects several accepting transcripts for different challenges and interpolates the prover messages as polynomials in the challenge. The paper needs a Laurent-polynomial vanishing lemma for this, because the folded combinations contain negative powers of the challenge.

Useful background: Dory: transparent arguments for generalised inner products.

Papers

Halving the vectors: the logarithmic inner-product argument

Each round the prover sends two group elements built from cross halves of the two vectors, then folds both vectors in half using a random challenge, until the vectors have length one.

Why it is useful

This is what makes the proof logarithmic: every round halves the problem, so a vector of length n needs only about log2 of n rounds and the prover sends two group elements per round.

How it works

  1. Split each vector into a left and a right half.
  2. Send two group elements: one built from the left of the first vector with the right of the second, and one from the right of the first with the left of the second.
  3. Receive a random challenge and form each new vector as left times the challenge plus right times the challenge inverse, for one vector, and the opposite pairing for the other.
  4. Fold the bases the same way, so the same group element remains a commitment to the new, half length vectors.
  5. Recurse until each vector is a single number, then send those two numbers; the verifier checks one group equation.

Example

A vector of length 8 needs three rounds: 8 to 4, 4 to 2, 2 to 1, sending six group elements plus the two final numbers.

What to watch for

The verifier could naively spend a linear number of exponentiations recomputing folded bases; unrolling the recursion into one multi-exponentiation of size about 2n removes that cost. The prover still does linear work.

Useful background: Committing to a vector and its inner product in one group element.

Related ideas

  • Pedersen commitments: Supplies the vector commitment the argument is about.

Papers

How Dory compares with earlier schemes

The paper groups transparent polynomial commitments into discrete-log folding schemes, Reed-Solomon interactive oracle proofs, and unknown-order-group schemes, and contrasts them with trusted-setup KZG-style commitments.

Why it is useful

Each family fails somewhere for large applications, which is the gap Dory aims at: a linear-time prover and a logarithmic verifier together, with no trusted setup.

How it works

  1. Discrete-log folding schemes have the linear prover but a square-root verifier and commitments of a similar size.
  2. Reed-Solomon based schemes need repetitions linear in the security level to reach provable security, which erodes their concrete advantage over curve arithmetic.
  3. Unknown-order groups can be built transparently, but sub-exponential attacks and weak classes of groups force slow group operations.
  4. Trusted-setup KZG commitments are fast but rest on knowledge-of-exponent style assumptions.

Example

Against the Spartan baseline the paper measures Dory committing about 2.7 times slower, and verifier time growing logarithmically rather than as a square root, overtaking the baseline for polynomials above roughly the sixteen-million-coefficient mark.

What to watch for

The comparison is partly asymptotic: implementations bundle the commitment with different polynomial IOPs, so isolated concrete comparisons are hard. Against its own discrete-log baseline Dory commits about 2.7 times slower and its proofs are about 24 times larger, so it only wins on verifier time above a size threshold.

Papers

Logarithmic range proofs and aggregation

The two evaluated vectors are replaced by an execution of the inner product argument, and one proof can cover many commitments at once by concatenating all their bits into one long vector.

Why it is useful

Proof size stops growing with the number of bits and grows only logarithmically, and aggregating m range proofs costs only an additive logarithmic number of extra group elements instead of m times a single proof.

How it works

  1. Run the range proof up to the point where the two evaluated vectors would be transmitted.
  2. Replace that transmission with the logarithmic inner product argument, which only needs soundness because the vectors are already blinded.
  3. To aggregate, place the bits of all m values one after another into a single vector and adjust the right side so each commitment is checked with its own power of a challenge.
  4. The inner product argument then runs once on the concatenated vectors, so only log2 of the total length matters.

Example

A single 64-bit range proof is 688 bytes in the reference implementation, while an aggregated proof for 32 ranges is still about 1 KB.

What to watch for

Verification and proving stay linear in the total number of bits, so aggregation saves communication, not verifier work; batch verification is what addresses the verifier.

Useful background: Blinding the vectors for zero knowledge, Halving the vectors: the logarithmic inner-product argument.

Related ideas

  • Mimblewimble: A ledger design whose range proofs these replace.

Papers

Many provers, one proof

Several parties who each hold one committed value can produce a single aggregate range proof without showing each other their values, by splitting the proof into per-party shares that a dealer adds together.

Why it is useful

Joint transactions then carry one short proof and also hide which inputs match which outputs, which a set of separate proofs cannot do.

How it works

  1. Give each party its own set of generators, and interleave all the sets so the combined base vector has all parties’ bases mixed together.
  2. Each party computes its own share of every proof component from its own inputs.
  3. A dealer, possibly one of the parties, multiplies or adds the shares homomorphically to form the real proof component, since the commitment scheme adds like its messages.
  4. The dealer derives each round’s challenge by hashing the combined components, so no party sees another party’s witness.
  5. In the final round the parties hand over their folded vector entries and the dealer finishes the inner product argument.

What to watch for

One variant uses a constant number of rounds with communication linear in the number of parties and the range width; the other uses a logarithmic number of rounds with communication linear only in the number of parties. The dealer is assumed honest but curious, and general circuits are not covered.

Useful background: Logarithmic range proofs and aggregation.

Related ideas

  • Mimblewimble: Aggregates transactions that carry these proofs.

Papers

No trusted setup

All public parameters are just independent group elements derived by hashing a small seed, and the interactive protocol is made non-interactive by hashing the transcript, so nobody has to generate secret setup data.

Why it is useful

Setup ceremonies are the main operational weakness of pairing-based succinct arguments: whoever knows the trapdoor can fake proofs, and distributing the generation is expensive.

How it works

  1. Hash a seed into group elements to obtain every base, which also allows random access to any base without storing them all.
  2. Derive every verifier challenge as a hash of the whole transcript so far, including the statement being proved.
  3. Always include the statement in the hash; leaving it out lets an adversary prove invalid statements.
  4. Use an established transcript library rather than hand-rolling the hashing order.

What to watch for

The security of the non-interactive form is in the random oracle model, and multi-round transforms need their own care even though later work confirms this approach.

Useful background: Halving the vectors: the logarithmic inner-product argument.

Related ideas

  • Bulletproofs: The proof system whose setup is transparent.

Papers

Prover and verifier costs

Committing costs linear multi-exponentiation work in one source group; proving an evaluation is dominated by a square-root number of pairings; verification is one logarithmic multi-exponentiation plus a constant number of pairings.

Why it is useful

Costs decide whether a transparent scheme is usable, because polynomial commitments are produced routinely and in large numbers inside larger proof systems. Dory keeps the prover near-linear while cutting the verifier to logarithmic.

How it works

  1. Commitment: multi-exponentiations of size about n in one source group, plus one multi-pairing.
  2. Evaluation proof: work dominated by roughly n-to-the-one-half pairings for univariate or multilinear polynomials.
  3. Verification: a multi-exponentiation of size about 9 log n in the target group, plus constant exponentiations and pairings.
  4. Both sides also do field arithmetic that grows only logarithmically.

Example

At around one million coefficients the paper reports 128-byte commitments taking about ten seconds to generate, with evaluation proofs of roughly eighteen kilobytes taking a few seconds to produce and tens of milliseconds to check.

What to watch for

The prover does real pairing work, and pairings are expensive per operation, so Dory is not the fastest prover at small sizes. Concrete numbers come from one core of one machine in the paper and should be read as indicative, not as a benchmark promise.

Papers

Soundness by rewinding: witness or discrete-log relation

If a cheating prover succeeds, an extractor that rewinds it to several different challenges can either reconstruct the two vectors, or the accepted transcripts contradict each other in a way that exposes a discrete logarithm relation between the independent bases.

Why it is useful

This is the whole security story of the argument: there is no separate assumption, just the discrete log assumption stated as no non-trivial relation between independently chosen group elements.

How it works

  1. Rewind the prover to collect several accepting transcripts that share the same first message but use different challenges.
  2. Take a linear combination of the resulting equations to peel off the two group elements sent in the round and the original commitment.
  3. Compare the coefficients across challenges; if they disagree anywhere, the disagreement itself is a non-trivial relation between the bases.
  4. If they agree, the combined coefficients are a valid pair of vectors for the folded relation, and recursion handles the smaller instance.

What to watch for

Extraction needs many transcripts, growing with the square of the vector length, so this is an argument with computational soundness rather than a statistically sound proof.

Useful background: Halving the vectors: the logarithmic inner-product argument.

Related ideas

  • Bulletproofs inner-product argument: The protocol whose soundness this argument establishes.

Papers

Structured verifier work: key symmetry and multiplicative structure

Two structural facts shrink the verifier side. The structure-preserving commitment is symmetric, so a message vector in one source group pairs with a key in the other, and the verifier may commit to parts of the key itself. Separately, the public scalar vectors that appear in polynomial evaluation are Kronecker products of tiny vectors, which the paper calls multiplicative structure.

Why it is useful

Older folding arguments leave the verifier with a large final computation, because the folded commitment key depends on every challenge and must be collapsed into a single point. Committing to the key, and exploiting the product shape of public vectors, moves that linear work to the prover or removes it.

How it works

  1. Combine the two halves of the commitment key using the first challenge; commitments to those halves are public, so this costs the verifier constant time.
  2. Let the prover perform the remaining length-n inner product against the committed key.
  3. Fold the public scalar vector alongside the committed vectors in each round.
  4. Finish by multiplying one factor per variable instead of summing n terms.

Example

The paper works the length-eight case: the monomial vector in three variables dotted with a challenge vector equals a product of three two-term factors, so eight multiplications become three.

What to watch for

Both tricks lean on structure that plain discrete-log schemes lack, so they do not transfer to Bulletproofs or Hyrax. For arbitrary public scalars the verifier is back to linear field work, since even reading such a vector costs linear time.

Useful background: Folding an inner product in half.

Papers

Transparent setup and structured public parameters

The public parameters are lists of uniformly random group points: a commitment key for every power-of-two length up to the maximum, together with commitments to the left and right halves of each of those keys.

Why it is useful

No trusted party samples a secret or keeps a trapdoor, so anyone can regenerate and check the parameters. The precomputed structure is also what later lets the verifier hand its linear work over to the prover.

How it works

  1. Sample random points in both source groups, publicly and independently.
  2. Build commitment keys of every power-of-two length.
  3. Commit to the left and right halves of each key using a key of half the length.
  4. Do this linear-size work once, then reuse it for every proof.

Example

Paying setup work to make each later proof cheap is the bargain the paper also attributes to Spartan: linear-size computation once, fast online proofs afterwards.

What to watch for

Setup is not free: it costs linear-size sampling and pairing work, and the parameters take space proportional to the vector length. Transparency removes trust, not computation.

Related ideas

  • Trust and setup assumptions: the model this avoids

Papers

Secret sharing and threshold cryptography

A secret can be divided among several participants so that only an authorized group can use it. Threshold protocols let a group sign or decrypt without handing the complete private key to one participant.

Blakley secret sharing

Blakley sharing is a geometric threshold secret-sharing construction.

Papers

GRand

GRand generates distributed secret and public keys represented as group elements.

Papers

Mignotte secret sharing

Mignotte sharing uses Chinese-remainder reconstruction of modular shares.

Papers

Distributed key generation

Jointly generate public keys and secret shares without a trusted dealer, including interactive key generation, bias resistance and distributed generation of special key material. SRS ceremonies belong to distributed infrastructure.

Distributed key generation

Distributed key generation creates a common public key and private key shares without appointing one participant to learn the complete secret key. In the method described here, participants each deal a sharing and recipients add their received contributions.

Why it is useful

It avoids relying on a single dealer to generate, distribute and then erase the entire signing secret.

How it works

  1. Agree on the participant set and threshold.
  2. Each participant creates and commits to a random sharing polynomial.
  3. Send private shares through protected channels and verify them against consistent commitments.
  4. Combine valid contributions into each participant's long-lived share and the group public key.

What to watch for

Key generation also needs agreement on commitments and a policy for complaints, aborts and retries. The paper's aborting Pedersen-style variant is not a guarantee that adversarial restarts cannot bias the output.

Related ideas

  • Feldman VSS: Checks the contributions in this form of key generation.

Papers

EthDKG

EthDKG adapts distributed key generation to EVM-compatible smart-contract communication.

Papers

GJKR DKG

GJKR DKG modifies the Pedersen distributed key-generation protocol.

Papers

Pedersen DKG

Pedersen DKG jointly generates discrete-logarithm keys through verifiable sharing.

Papers

DKG agreement, complaints and network faults

Completion and agreement for key generation across synchronous, partially synchronous or asynchronous networks; complaint resolution, dealer qualification and fault accountability.

Public transcripts and non-interactive DKG

Publicly checkable dealings, non-interactive key generation and aggregation of DKG transcripts. Aggregation alone does not establish non-interactivity or unbiased output.

Aggregatable DKG

This DKG combines publicly verifiable transcripts through aggregation and gossip.

Papers

Golden DKG

Golden uses a two-party exponent VRF to encrypt shares during non-interactive DKG.

Papers

Long-lived distributed key management

Maintain shared keys over time, covering proactive security, changing holders, recovery and key retirement. Establishing a fresh key remains under DKG.

Proactive refresh and mobile adversaries

Replace shares without changing the underlying secret, with epoch-specific corruption bounds and secure erasure requirements.

COBRA proactive sharing

COBRA is a dynamic-committee proactive secret-sharing protocol.

Papers

Resharing and dynamic committees

Transfer an existing secret to new holders or access policies, including asynchronous handoff and refresh during committee changes.

CHURP

CHURP refreshes secret shares as the committee holding them changes.

Papers

DyCAPS

DyCAPS transfers and refreshes secret shares between asynchronous committees.

Papers

Share repair, backup and retirement

Repair lost shares and recover authorized access without exposing the whole key; authenticate backup state and revoke obsolete shares and presignatures.

Secret-sharing structures

Distribute a secret under a reconstruction policy, with explicit privacy and reconstruction guarantees. Verifiability and share maintenance have separate topics.

Access structures and linear sharing

Threshold and general access policies; linear, polynomial, replicated and residue-based sharing. Algebraic representations are examples, not separate functional branches.

Additive secret sharing

Additive shares are values whose sum is the shared secret, using arithmetic modulo a chosen modulus. In joint generation, participants can independently select their contributions, so no one needs to assemble the resulting secret.

Why it is useful

Summing independent contributions is simple and can avoid a separate interactive polynomial-sharing procedure for a fresh nonce.

How it works

  1. Choose the field or modular arithmetic in which the shares live.
  2. Generate contributions with the required independent randomness.
  3. Treat their sum as the shared value.
  4. Use operations on the shares to obtain the needed joint result without exposing the full value.

What to watch for

An ordinary additive sharing requires all of its shares for reconstruction. A threshold protocol needs additional structure or share conversion; additive sharing alone does not create an arbitrary t-of-n scheme.

Related ideas

  • FROST: Uses additive nonce contributions during signing.

Papers

Asmuth-Bloom secret sharing

Asmuth-Bloom sharing encodes threshold shares through modular residues.

Papers

Linear secret sharing

A linear secret-sharing scheme computes shares as linear expressions in a secret and fresh randomness. An authorized set recovers the secret with a linear combination of its shares; an unauthorized set learns nothing about it.

Why it is useful

Linear reconstruction works well inside cryptographic protocols because the same coefficients can often be applied to commitments or group elements that hide the shares.

How it works

  1. Represent the access rule with a suitable matrix.
  2. Combine the secret with random field elements.
  3. Use the matrix rows to compute the shares.
  4. For an authorized set, find reconstruction coefficients that recover the secret.

What to watch for

Privacy depends on the chosen sharing construction and randomness. Ordinary linear sharing alone does not verify dishonest shares or provide attribute-encryption collusion resistance.

Related ideas

  • GPSW ABE: Uses secret-sharing reconstruction in exponents.

Papers

Monotone access structures

An access structure specifies which sets of attributes or participants are authorized. It is monotone when adding more attributes or participants to an authorized set cannot make it unauthorized.

Why it is useful

This captures rules built from positive requirements, such as a conjunction, a choice or a threshold.

How it works

  1. Define the relevant attributes or participants.
  2. Specify the authorized subsets.
  3. Check that every superset of an authorized set is also authorized.

What to watch for

An ordinary monotone rule cannot express the absence of an attribute. Representing a negative condition as its own positive attribute requires consistent, trustworthy labeling; it is not a test for missing data.

Papers

Monotone span programs

A monotone span program expresses an access rule using rows of a matrix labeled by attributes. A set is accepted when its available rows can be linearly combined to obtain a fixed target vector.

Why it is useful

This gives a linear-algebra representation of policies that can be used by linear secret-sharing schemes.

How it works

  1. Label each matrix row with its required attribute.
  2. Keep the rows whose labels appear in the input set.
  3. Solve for coefficients that combine these rows into the target vector.
  4. Accept exactly when such coefficients exist.

What to watch for

The paper uses the all-ones vector as its target; other descriptions use a first-coordinate unit vector after changing representation. Matrix size matters, and not every policy has a compact representation.

Related ideas

Papers

Ramp secret sharing

Ramp sharing separates the reconstruction threshold from the privacy threshold.

Papers

Replicated secret sharing

Replicated sharing distributes overlapping subsets of additive shares among participants.

Papers

Shamir secret sharing

Shamir sharing places a secret at the constant term of a random polynomial. A threshold number of evaluations determines that constant, while fewer evaluations reveal no information about it when the other coefficients are sampled correctly.

Why it is useful

It separates possession of individual shares from the ability to recover the full secret.

How it works

  1. Choose a finite field and distinct nonzero participant identifiers.
  2. For threshold t, set the constant term to the secret and sample the other t-1 coefficients uniformly.
  3. Give each participant the polynomial value at its identifier.
  4. Use Lagrange interpolation on at least t shares to reconstruct the value at zero.

What to watch for

Shares must remain private and their identifiers must be valid and distinct. Basic Shamir sharing does not detect a dealer sending inconsistent shares or a participant returning a false share.

Papers

Threshold access trees

An access tree represents a policy with attributes at its leaves and threshold gates at its internal nodes. A gate is satisfied when enough of its children are satisfied.

Why it is useful

A tree gives a concrete representation for combinations of AND, OR and at-least-k requirements.

How it works

  1. Mark each leaf according to whether its attribute is present.
  2. Work upward through the tree.
  3. At each gate, count satisfied children and compare the count with its threshold.
  4. Accept the attribute set if the root is satisfied.

Example

An OR gate is one-of-n; an AND gate is n-of-n.

What to watch for

The same attribute can appear in multiple places; a tree position is not a new independent credential. Tree size also affects key size and decryption work.

Related ideas

Papers

Homomorphic secret sharing

Local evaluation on shares of input data followed by output reconstruction. Function secret sharing instead distributes a function and is linked separately.

Homomorphic secret sharing

Homomorphic secret sharing lets parties locally evaluate functions on shares and combine the resulting outputs.

Papers

Packed and communication-efficient sharing

Share multiple secrets together and reduce dealing or reconstruction cost, including amortized and communication-efficient reconstruction.

Packed secret sharing

Packed sharing places several secrets in one sharing polynomial.

Papers

Sparsely packed Shamir sharing

This Shamir packing variant is used to route shares within multiparty computation.

Papers

Publicly verifiable secret sharing

Publish encrypted dealings and evidence checkable by outsiders; distinguish public verification from participant-only VSS and from unbiased key generation.

Class-group PVSS

This PVSS construction uses class groups and reconstructs the original shared secret.

Papers

Publicly verifiable secret sharing

PVSS publishes encrypted shares together with publicly checkable dealing and reconstruction data.

Papers

Verifiable and complete secret sharing

Check share consistency and enable reconstruction despite faulty dealers or holders, including asynchronous VSS and complete sharing. Network guarantees must be stated separately.

Bingo

Bingo is a packed asynchronous verifiable secret-sharing protocol used in DKG construction.

Papers

Feldman VSS

Feldman verifiable secret sharing publishes group commitments to a sharing polynomial's coefficients. Each recipient checks that its private share matches those commitments without receiving the other private shares.

Why it is useful

A dishonest dealer should not be able to give a participant an inconsistent share that only fails later during reconstruction or signing.

How it works

  1. Create polynomial shares as in Shamir sharing.
  2. Publish a group element for each polynomial coefficient.
  3. Raise these commitments to powers determined by the recipient's identifier.
  4. Compare their product with the group element derived from the received share.

What to watch for

All recipients need a consistent view of the commitments. These commitments are not information-theoretically hiding: the commitment to the constant term reveals a group element derived from the secret.

Related ideas

Papers

Haven++

Haven++ combines packing and batching in asynchronous complete secret sharing.

Papers

HAVSS

HAVSS uses an asymmetric bivariate polynomial for high-threshold asynchronous verifiable sharing.

Papers

Pedersen VSS

Pedersen VSS checks polynomial shares using randomized commitments.

Papers

Verifiable secret sharing

Verifiable secret sharing adds procedures for checking the consistency of distributed shares.

Papers

Threshold decryption and decapsulation

Distributed decryption or KEM decapsulation, including correctness proofs for shares and resistance to malicious ciphertext queries. Collective HE uses this function but has its own evaluation and key-management questions.

Ferveo

Ferveo applies threshold decryption to transaction mempools in BFT networks.

Papers

Tiresias

Tiresias is a distributed threshold Paillier construction.

Papers

Threshold keyed-function evaluation

Evaluate PRFs and related keyed pseudorandom functions with a distributed key. Input obliviousness and public verifiability are additional properties, not implied by threshold evaluation.

Great-LaKeys threshold PRF

This LaKey variant changes the distributed bit-truncation protocol used in PRF evaluation.

Papers

LaKey threshold PRF

LaKey distributes evaluation of an LWR-based pseudorandom function.

Papers

Threshold signature protocols

Produce signatures using shares of one signing key, with threshold access and protocol-specific security. Independent-key multisignatures and aggregation stay under signatures.

Dual-threshold signatures

A dual-threshold signature scheme distinguishes the maximum corruption count t from the number k of valid shares needed to construct a signature. Its guarantee remains meaningful even when k is greater than t+1.

Why it is useful

Agreement protocols may need a certificate showing broad support rather than just one honest contribution beyond the corrupted group.

How it works

  1. Choose n participants, a corruption bound t and reconstruction threshold k.
  2. Distribute key shares and verification information.
  3. Generate and verify signature shares for a specific message.
  4. Combine k valid shares from distinct participants.

What to watch for

The paper's definition requires security until at least k-t honest shares have been requested. A scheme that merely needs k shares for reconstruction but loses security after one honest share is not equivalent.

Papers

Nonce and presigning lifecycle

Generation, validation, storage, consumption and destruction of per-signature randomness and presignatures across retries, crashes and concurrent sessions.

Single-use nonce storage for threshold signing

Preprocessing stores secret nonce material for later signing. Its public commitments may be distributed beforehand, but the secret material must be consumed only once.

Why it is useful

Moving work offline saves a communication round while creating sensitive state that must survive crashes and concurrent requests correctly.

How it works

  1. Generate fresh private nonce pairs and identify their public commitments.
  2. Select an unused pair for the signing request.
  3. Prevent concurrent or later reuse of that pair.
  4. Remove the consumed private material before releasing the response, as the paper's signing algorithm specifies.

What to watch for

Aborts, backups and rollback must not make consumed nonces available again. Publishing a commitment does not disclose its nonce, but reusing the secret pair can expose a long-lived key share.

Related ideas

  • FROST: Its preprocessed nonce pairs are single-use even when signing sessions run concurrently.

Papers

Post-quantum threshold signing

Threshold versions of classical signature functions targeting quantum-resistant security, including lattice and hash-based designs. This is a security-target topic, not a quantum communication protocol family.

Ringtail

Ringtail is a lattice-based threshold signature protocol.

Papers

Signing availability and fault accountability

Scheduling and wrappers for threshold signing, identifiable abort, blame and progress despite unresponsive signers. Availability claims depend on the base protocol and network.

ROAST

ROAST wraps compatible threshold signing protocols in an asynchronous signing scheduler.

Papers

Signature-share verification and identifiable abort

A coordinator can check each signature share against that signer's public verification share and nonce commitments. An invalid contribution causes the signing attempt to abort and identifies which contribution failed the equation.

Why it is useful

This helps distinguish a malformed share from an otherwise correct signing transcript instead of discovering only that the final signature is invalid.

How it works

  1. Recompute binding factors, commitments and the common challenge.
  2. Check each response with its public verification share and interpolation coefficient.
  3. Abort on a failed equation.
  4. Combine responses only after successful checks.

What to watch for

Identification requires authenticated messages and a consistent signing package. A malicious coordinator can deny service or falsely report blame. The protocol does not guarantee completion despite a malicious selected signer.

Related ideas

  • FROST: Trades guaranteed progress in a faulty signing attempt for fewer rounds.

Papers

Threshold BLS-family signing

Combine signature shares under a shared pairing-based signing key, with share verification and interpolation. Beacon uses link to randomness rather than defining this branch.

tlock

tlock combines time-indexed IBE identities with a threshold BLS beacon.

Papers

Threshold ECDSA signing

Distributed ECDSA nonce inversion and multiplication, auxiliary encryption, presigning and malicious-party checks. An ordinary ECDSA entry is not evidence of a threshold construction.

Abort, not blame

When anything goes wrong - a failed zero-knowledge proof, a refused decommitment, an invalid signature - the protocol halts. It does not identify which player misbehaved, and it makes no attempt to complete the signing anyway.

Why it is useful

The paper allows the adversary to corrupt up to n−1 players. Without an honest majority there is no coalition that can be trusted to name and exclude a cheater, so the paper gives up robustness entirely and proves only that such an adversary cannot forge.

How it works

  1. Every check that fails is an abort condition; there is no error recovery path.
  2. If all players behave, failure can only come from an accidental wraparound in one of the roughly 4n^2 MtA subroutines, which happens with probability at most 4n^2/q - negligible for a 256-bit q.

What to watch for

This is not identifiable abort: after an abort the group knows someone cheated but not who, so a deployment must restart from scratch or add its own accountability mechanism. Naming the culprit is a separate goal, and this paper does not address it.

Useful background: Check the signature before revealing it.

Papers

Cancelling the consistency check with Endemic OT

DKLs proved its VOLE secure in an idealised world where an Endemic OT functionality supplies the oblivious transfers. Endemic OT lets a corrupted Sender hand-pick its own inputs. This paper shows that in exactly that world a cheating Sender can arrange its inputs so the protocol’s consistency check always passes, no matter how inconsistent its behaviour.

Why it is useful

The consistency check is what forces the Sender to use the same secret row everywhere; if a cheater can neutralise it for free, correctness of the multiplication - and therefore of the signature - is gone. The lesson reaches beyond this paper: proof in a hybrid model can silently lose a binding property that only exists in the concrete implementation.

How it works

  1. The check works by a random challenge chi acting as a universal hash: if any two rows of the Sender’s hidden matrix differ, their images under chi should differ.
  2. DKLs derives chi by hashing only part of the Sender’s message, and in the hybrid model there is no oblivious transfer transcript to include, because the parties only exchange inputs and outputs with an ideal box.
  3. A corrupted Sender therefore computes chi first from its own message, then fills the last column of its matrix so that every row hashes to the same value v, perfectly neutralising the test.
  4. It then picks its two OT input matrices so the Receiver’s verification equation holds identically, and the check passes although the rows are not equal.
  5. Two fixes: hash the entire concrete transcript of the real oblivious transfer when deriving chi, or use Sender Random OT, which forces even a malicious Sender to accept functionality-chosen inputs and makes the attack infeasible without any transcript hashing.

What to watch for

The author reports having seen implementations that missed this nuance when translating the hybrid-model proof into code, which is why the paper spells the attack out. Hashing the transcript only helps if the concrete OT protocol actually commits the sender to its input, so that property must be checked too.

Useful background: Vector oblivious linear evaluation, Too few oblivious transfers in DKLs.

Papers

Check the signature before revealing it

Phase 5 verifies that the assembled (r, s) is a genuine signature before anyone reveals their share s_i in the clear, using random group-element masks and a distributed Diffie-Hellman-style check.

Why it is useful

With a dishonest majority, an aborted run must not leak either. Naively broadcasting the s_i is not provably secure: a cheater can force the signature to be invalid and then study the honest players’ revealed pieces. The paper admits it has no concrete attack on the naive reveal - only that no proof is known, which is reason enough.

How it works

  1. Run optimistically, then test the result: if the signature does not verify, at least one player deviated.
  2. Each player masks its piece as V_i = R^(s_i)·g^(λ_i) with a random λ_i; the group then forms V = g^(−m)·y^(−r) times the product of all V_i, which equals g^λ if everyone behaved - so V is checkable without unmasking any s_i.
  3. Because g^λ cannot be opened without unmasking, the group instead checks a randomized relation (U = g^(λρ) against T) computed through a distributed Diffie-Hellman exchange; only if this passes do players broadcast s_i.
  4. The players then verify the final signature; on failure the protocol aborts with the honest shares still hidden.

What to watch for

This distributed check is what makes the abort case simulatable in the security proof. It is a cost-avoidance design: proving each s_i correct with zero-knowledge proofs would work but is far more expensive than one masked group computation.

Useful background: The signing protocol, phase by phase.

Papers

Cost and deployment limits of the repaired protocol

With the corrected parameters the online signing phase is very cheap - about 1900 bits, roughly 0.2 KB, sent by each party in two rounds, against about 200 KB for the offline phase - and each party stores roughly 304 bytes of preprocessing state. The expensive part moves off the critical path but does not disappear.

Why it is useful

The numbers show where the design wins and where it still pays. Knowing that base oblivious transfers cannot safely be shared between sessions is as important for a deployment as the headline bandwidth figure.

How it works

  1. Offline: run a few hundred oblivious transfers and send the VOLE matrix; which variant is chosen fixes the exact count (436, 696 or about 1405 transfers) and the bandwidth.
  2. Online: two short messages per party, about 1400 bits then 512 bits, plus the stored 304-byte state.
  3. OT extension looks attractive at these counts, but even honest executions of extension protocols can leak information about the base OT inputs, and after an abort the base OTs must not be reused.
  4. That forces an uncomfortable choice: share base OTs as long-lived key material and risk unsafe reuse across concurrent sessions, or re-run the base OTs for every signature and accept the extra communication and one extra round.

What to watch for

Halting every concurrent signing session after one abort is hard in practice, and propagating that information fast enough to prevent parallel misuse is harder still, which is why the paper recommends no shared state. All figures are for secp256k1 with a 128-bit computational and 60-bit statistical security parameter, and exclude network latency.

Useful background: Three repaired VOLE variants, Presignature-safe preprocessing.

Papers

DKLs threshold ECDSA

DKLs is a family of threshold ECDSA protocols written by Jack Doerner, Yashvanth Kondi, Eysa Lee and abhi shelat. The 2024 journal version signs in three rounds by bolting a signing protocol onto a multiplication subroutine built from oblivious transfer, and it is already used by many cryptocurrency custody providers. This paper re-reads that protocol and finds that its parameters, and one step of its security argument, need repair before the promised security level is actually reached.

Why it is useful

Because real money moves through DKLs wallets, a gap between what the proof covers and what the implementation does is a direct financial risk, not a theoretical footnote. Understanding what DKLs is and where it was optimistic is the starting point for every fix the paper proposes.

How it works

  1. Split one ECDSA key into shares so that no single party can sign alone; DKLs grew out of a 2018 two-party protocol and a 2019 multiparty extension by the same four authors.
  2. Reduce signing to secure multiplication: ECDSA needs products of two secret values, so the protocol asks for a subroutine that multiplies without revealing the factors.
  3. Build that subroutine from oblivious transfer on random inputs, so no public-key encryption or trusted setup is needed.
  4. This paper then re-derives the security and reports three weak spots: too few oblivious transfers, a mis-derived consistency challenge, and a signing phase that can be made much cheaper.

Example

The abstract names Coinbase, Taurus Group, Utila, Vultisig, Copper, Sodot and others as DKLs users.

What to watch for

The 2024 paper is the object being repaired, not the final word: this work states that implementations following it exactly may miss their stated security level. The claim that DKLs began as a two-party protocol in 2018 rests on the bibliography entry of this source rather than on body prose.

Related ideas

Papers

Generating the key without a dealer

Distributed key generation lets the n players create the shared signing key themselves: each player picks a random piece, they jointly build the public key y = g^x, and each ends with a (t, n) Shamir share of the secret x. No trusted dealer ever sees the key.

Why it is useful

A dealer would reintroduce exactly the single point of failure threshold signing is meant to remove. Earlier threshold-optimal protocols avoided the dealer but needed the players to jointly generate a Paillier key, which means jointly generating an RSA modulus - a protocol so heavy it had never been implemented in the malicious multiparty setting.

How it works

  1. Each player commits to g raised to their random value u_i, then opens the commitment.
  2. Each player runs Feldman VSS (Shamir sharing with public consistency checks in the exponent) on u_i; the group public key is the product of all opened values.
  3. Every player sums the shares received from the n Feldman protocols, obtaining one Shamir share x_i of x = sum of u_i, with each g^(x_i) public.
  4. Each player proves in zero knowledge that they know x_i matching the public g^(x_i), and that their Paillier modulus is square-free (no repeated prime factors).

What to watch for

Feldman VSS deliberately leaks g raised to each shared secret; a simulation argument shows nothing beyond that leaks. And since the paper assumes a dishonest majority, any complaint during VSS aborts rather than recovering - there is no honest majority to outvote a complainer.

Useful background: One key held by many machines.

Papers

MtA: turning multiplicative shares into additive ones

MtA (multiplicative-to-additive) is a two-party subroutine. Alice holds a and Bob holds b, so their secret is multiplicatively shared as x = ab. At the end Alice holds α and Bob holds β with α + β = ab mod q: the same secret, now additively shared.

Why it is useful

Additive shares are the convenient currency for the rest of the protocol, because sums need no interaction. Since a product of sums expands into all pairwise products a_i·b_j, running MtA on every pair converts a shared product into a shared sum.

How it works

  1. Alice encrypts her value under her own additively homomorphic public key (the paper uses Paillier) and sends the ciphertext with a zero-knowledge range proof that her input is small.
  2. Bob multiplies the ciphertext by his value b using the homomorphic property, adds a fresh encryption of a random mask β′, and returns it with proofs that b and β′ are small.
  3. Alice decrypts to get ab + β′ and reduces mod q; Bob sets β = −β′ mod q. Their shares now add up to ab mod q.

Example

Think of 3 × 7 = 21 shared multiplicatively as (3, 7). After MtA the same 21 is shared additively as (15, 6): either form reconstructs 21, but only the additive form lets parties sum shares without interaction.

What to watch for

Correctness relies on no wraparound: with honest inputs and a Paillier modulus N larger than q^8, the value ab + β′ never exceeds N, so the modular reduction in the decryption step never fires. This is why every input needs a range proof, covered in the next lesson.

Useful background: Why ECDSA is hard to share.

Papers

One key held by many machines

A threshold signature scheme splits one signing key among n machines so that any t+1 of them can sign together, while any t or fewer learn nothing about the key. The signature still verifies under the ordinary, single-key verifier.

Why it is useful

It removes the single stored secret that attackers target. The paper motivates this with Bitcoin: funds are stolen by compromising the one machine holding the signing key, and splitting that key across machines with a threshold defeats any breach below the threshold.

How it works

  1. Agree on a threshold t for n players.
  2. Run a distributed key generation protocol so each player holds a share and everyone learns the same public key.
  3. Have any t+1 players run a distributed signing protocol on a message; the output is an ordinary ECDSA signature.
  4. Anyone verifies it with the standard verification algorithm - no special verifier is needed.

Example

With t = 2 and n = 5, any three of the five machines can sign a transaction; two compromised machines cannot sign and cannot reconstruct the key.

What to watch for

The model assumes a broadcast channel plus private point-to-point channels between every pair, and only static corruption: the adversary picks its victims before the protocol starts.

Related ideas

  • Digital signatures: the primitive being distributed

Papers

Presignature-safe preprocessing

The signing protocol is split into an offline preprocessing phase and a two-message online phase. Preprocessing commits to the nonce point and runs the whole random VOLE, storing under 0.3 KB of state; the online phase sends scalar corrections and the two final values. Crucially the public nonce point R stays hidden until the message is fixed, and preprocessing touches neither the message nor the secret key.

Why it is useful

Earlier threshold ECDSA work used so-called presignatures that revealed R before the message was chosen, which lets an adversary pick the message as a function of R and weakens the security proof. Being independent of the secret key also means two devices can prepare signing material before knowing which derived address will be used.

How it works

  1. Run preprocessing any time: choose nonces, commit to the nonce points, execute a fully random VOLE, and store a handful of field elements plus the commitment information.
  2. When a message arrives, each party sends a correction that shifts the random VOLE values onto its real nonce and key share, opens its commitment, and proves the two are consistent.
  3. Because R was never revealed, the adversary cannot condition the message on it, so the standard security argument goes through.
  4. Because the secret key is not used, the same prepaid material serves any key derived later from the same root, as hierarchical wallets do.
  5. Each preprocessing state is single-use: after a successful signature or an abort it is discarded and a fresh one is needed.

Example

A phone and a laptop sharing one key can prepare states overnight, then sign a transaction in two short messages when the user confirms it.

What to watch for

The preprocessing is not reusable, so a wallet must keep generating fresh states in the background, and the offline phase still costs about 200 KB of communication per signature. The comparison is against roughly 600 times more communication for a direct run of the full protocol.

Useful background: DKLs threshold ECDSA, Vector oblivious linear evaluation.

Papers

Range proofs and the wraparound leak

A range proof is a zero-knowledge proof that an encrypted number lies in a small interval. Here every value fed into MtA must be proven to sit below q^3 (and the mask below q^7), so that the arithmetic inside the Paillier modulus never wraps around.

Why it is useful

If wraparound could happen, then whether the final signature verifies becomes a single bit that depends on the size of the honest party’s secret input. A malicious player can force this oracle to fire and observe it, and later work showed how to repeat the trick until the honest party’s share - and then the whole group key - is recovered.

How it works

  1. Each party encrypts its MtA input and attaches a range proof, built from Strong-RSA-based commitments, convincing the peer the plaintext is small.
  2. The Paillier modulus must be checked to be large enough (about q^8, i.e. a 2048-bit modulus next to a 256-bit group order); the paper stresses the parties must verify this size rather than trust it.

What to watch for

This is a cautionary tale: the earlier CCS 2018 version of this very protocol skipped the range checks, its security proof was wrong, the authors’ guess that omitting the proofs was still safe was disproven, and the proof-free variant kept in Section 5 is explicitly marked insecure and retained only as a historical record.

Useful background: MtA: turning multiplicative shares into additive ones.

Papers

Speed, communication, and what the numbers do not show

The authors implemented the protocol in C (libsecp256k1 for the curve, libhcs for Paillier) on one core of an i7-6700 over secp256k1. Signing time is r(t) = 29 + 24·t milliseconds and each player sends and receives d(t) = 2,328 + 5,024·t bytes; key generation finishes in under a second.

Why it is useful

The numbers are the paper’s deployment argument: cost grows only with the number of active signers t+1, not with the total group size n, and the per-player traffic is a few kilobytes rather than the tens of kilobytes of earlier designs.

How it works

  1. Fixing the number of active participants fixes the cost, since only the t+1 signers run the protocol.
  2. Each measurement was averaged over 1000 single-threaded iterations, excluding network latency.
  3. Key generation is simple enough that the authors report it as faster than any prior threshold ECDSA key generation - prior ones had never even been implemented.

What to watch for

The headline numbers come with an asterisk: the benchmarked build is the Section 5 variant without range proofs, and the paper itself states that variant is insecure and kept only as a historical record. No benchmarks for the corrected full protocol appear in this version, so treat the timings as indicative of the design’s shape, not of the secure configuration’s cost.

Useful background: Range proofs and the wraparound leak.

Papers

The signing protocol, phase by phase

Signing runs in five phases. The t+1 active players first reshape their long-term (t, n) shares into a (t, t+1) sharing, then build additive sharings of the two products they need, open one value, invert the nonce, and finally release the signature.

Why it is useful

The structure exists because both hard operations reduce to products of shared values: the protocol needs k·γ to invert k, and k·x to build s. Everything expensive happens in Phase 2 as pairwise MtA calls.

How it works

  1. Each active player uses the public Lagrange coefficients for the active set to convert its share x_i into w_i, so x = sum of w_i over the t+1 active players - a purely local computation.
  2. Players pick random additive shares of k and γ, commit to g^(γ_i), then every pair runs MtA twice (on k_i, γ_j and on k_i, w_j), yielding additive sharings of δ = kγ and σ = kx.
  3. All players broadcast their δ shares and reconstruct δ = kγ in the clear, then compute δ^(-1) mod q.
  4. Multiplying each local γ-share by the public δ^(-1) gives an additive sharing of k^(-1) without ever revealing k - the Bar-Ilan and Beaver inversion trick. Then R is the product of the opened g^(γ_i) each raised to δ^(-1), and each player’s signature piece is s_i = m·k_i + r·σ_i.
  5. Each player opens its commitment and proves in zero knowledge it knows γ_i matching the opened group element, tying R to the same γ used in Phase 2.

What to watch for

Ephemeral secrets use a (t, t+1) sharing rather than the long-term (t, n) structure, so exactly the t+1 active players are needed and no more. The commitment to g^(γ_i) before any MtA traffic is what stops a player from choosing γ after seeing others’ values (the adversary is allowed to rush and speak last in each round).

Useful background: MtA: turning multiplicative shares into additive ones, Generating the key without a dealer.

Papers

Three repaired VOLE variants

The paper repairs the counting problem with three variants of the VOLE protocol, differing in when the vector g is fixed. Variant I sends g at the end and needs the fewest transfers but one extra round; Variant II derives g by hashing the transcript and keeps the original round count; Variant III is the original DKLs protocol with g fixed at the start, and needs by far the most transfers.

Why it is useful

There is no free lunch between bandwidth and rounds. Picking g last makes the leftover hash lemma apply cleanly, but the Receiver learns beta later and an extra message must travel; picking g first preserves the original shape but forces a much larger union bound.

How it works

  1. Variant I: let the Receiver choose g uniformly at the end and send it. The standard leftover hash lemma then applies directly, so m can be as small as log q plus 3s, about 436 transfers at s = 60.
  2. Variant II: derive g by hashing the Sender’s final message, in the spirit of the Fiat-Shamir transformation. A cheating Sender can now try many candidate messages and keep the best one, which costs an extra 2k transfers where k is the computational security parameter: m at least log q plus 3s plus 2k, that is 692 transfers, rounded to 696 in implementations.
  3. Variant III: keep g fixed at the outset as DKLs did, and pay for the stronger guarantee that almost every g is good against every adversarial source. This needs m at least log q plus 7s plus extra logarithmic terms, about 1405 transfers.
  4. The paper deliberately keeps the analysis simple - one application of the leftover hash lemma plus a union bound - and prefers verifiably correct parameters over tight ones.

What to watch for

The paper also flags a small inconsistency in the original text: DKLs asks for two extra masking columns per row where one suffices for secp256k1, which looks like a typo in the ratio. The reported bandwidth figures exclude the cost of the oblivious transfers themselves, which roughly doubles the total in the implementation.

Useful background: Too few oblivious transfers in DKLs.

Papers

Too few oblivious transfers in DKLs

The Receiver’s random value beta is built as an inner product: a public vector g chosen by hashing, times the Receiver’s random bit string w. The leftover hash lemma is what promises that this beta looks uniformly random. This paper shows DKLs under-counted how many oblivious transfers are needed, because it applied the lemma in a setting the lemma does not cover.

Why it is useful

If beta is not close to uniform, a cheating Sender gains information about the Receiver’s secret mask, and the whole signature stops being private. The fix is a parameter change, so getting the count right is what separates a secure deployment from an insecure one that looks identical.

How it works

  1. The leftover hash lemma says: pick a hash function from a universal family, feed it a source with enough min-entropy (min-entropy measures how hard the most likely outcome is to guess), and the output is close to uniform - but only if the hash function and the source are chosen independently.
  2. DKLs set the number of transfers m to log q plus 2s, where q is the curve order and s the statistical security parameter, treating g and w as independent.
  3. In the real protocol g is fixed first, so a malicious Sender can shape its messages so that only bit strings passing its consistency check survive - that is, it effectively picks the source after seeing the hash function.
  4. The lemma does not exclude a fixed g for which some adversarially chosen high-min-entropy source hashes to a badly skewed output, so the original bound does not apply.
  5. A brute-force experiment on toy parameters backs this up: with q = 7, s = 2 and m = 7, over 26 percent of all possible g vectors admit a bad source that breaks the 2^-s bound.

What to watch for

The experiment uses tiny parameters and a single constraint, so it demonstrates that the old bound is not valid, not that a full-size deployment is broken in practice. It also affects the earlier 2018 and 2019 versions of the protocol, which used the same reasoning.

Useful background: Vector oblivious linear evaluation, DKLs threshold ECDSA.

Papers

Two-party signing from shared products

To sign, the two parties build additive shares of k times beta and of sk times beta, where k is the joint nonce, sk the joint key and beta the sum of the two VOLE masks. From these they form two numbers u and w whose quotient is exactly the ECDSA value s, so the signature falls out of one division without anyone ever reconstructing k or sk.

Why it is useful

ECDSA needs the inverse of the nonce and the product of nonce and key, both nonlinear in the secrets. Wrapping both in a common random factor beta means the parties can divide at the very end, when both quantities are public, instead of ever inverting a shared secret.

How it works

  1. Recall single-party ECDSA: pick a random k, set R = k times the generator, take rx as the x-coordinate of R, and compute s = k^-1 times (H(m) plus sk times rx).
  2. Each party i knows its own ki and betai and holds shares of the two cross-products, so ui = ki times betai plus the shares it holds; adding the two parties’ values gives u = (k0 + k1) times (beta0 + beta1) = k times beta.
  3. The same construction with the key shares gives shares of v = sk times beta, and each party forms wi = H(m) times betai plus rx times vi.
  4. Adding the w values gives w = H(m) times beta plus rx times sk times beta, so s = w divided by u is exactly the ECDSA signature value, and the pair (rx, s) is verified with the ordinary verifier.
  5. In the preprocessed version, the parties first "fix" the random VOLE values onto their real nonce and key share by sending offset scalars, then run these last steps.

What to watch for

Correctness relies on the verification equations that tie each party’s correction messages to its public nonce point and public key share; a failure aborts and burns the preprocessing state. The security proof additionally assumes the parties’ inputs are valid and consistent, which requires a compatible key-generation procedure.

Useful background: DKLs threshold ECDSA, Presignature-safe preprocessing.

Papers

Two-party threshold signing

Two-party threshold signing splits one signing key between exactly two parties, so each holds a share and neither can produce a signature alone. It is the smallest useful threshold setting, and this paper argues it already contains everything hard about threshold signing.

Why it is useful

Wallet products overwhelmingly use two devices, and the two-party case lets several steps of the general multiparty protocol be deleted outright. Fewer messages means a faster signing phase and fewer places for a cheater to hide.

How it works

  1. Give each party a share of the secret key and a public key share, with the joint public key being the sum of the two.
  2. Notice that with only two parties there is no group of maskings to reconcile: the multiparty protocol forces every party to align the several random masks it received into one global mask, which costs an extra message and pins down when that mask must be known.
  3. Drop the helper that hands out shares of zero, which the multiparty protocol needs to hide the key shares but the two-party protocol does not.
  4. What remains is a short exchange of corrections and two final values per party.

What to watch for

The savings are specific to two parties. Going back to three or more signers reintroduces the mask-alignment messages and the zero-sharing helper, so this streamlined protocol is not a drop-in replacement for the multiparty case.

Useful background: DKLs threshold ECDSA.

Papers

Vector oblivious linear evaluation

Vector oblivious linear evaluation, or VOLE, is a two-party correlation. One party (the Sender) holds a list of numbers a1 through a-l, the other (the Receiver) holds a single number beta, and the goal is for the two parties to end up with additive shares of every product ai times beta, without either learning the other side’s values. Additive shares are two numbers that add up to the secret, so each party sees only its own piece.

Why it is useful

VOLE is the multiplication engine of the protocol. ECDSA forces the parties to multiply secret values together, and a supply of VOLE correlations turns that multiplication into plain local addition. It is also the arithmetic cousin of oblivious transfer: where oblivious transfer picks one of two strings, VOLE evaluates a linear function on a hidden input.

How it works

  1. Think of oblivious transfer first: the Sender offers two strings, the Receiver has one bit and learns only the string it selected, and the Sender learns nothing about the bit.
  2. Replace the binary choice with arithmetic over the scalar field of the curve: the output becomes shares of a times beta.
  3. DKLs produces this correlation from oblivious transfer on random inputs, so the Receiver’s beta is not chosen by anyone; it is sampled implicitly by the protocol.
  4. This paper adds a fully random version, where the Sender’s inputs are also random and unknown at generation time, which is what makes an input-free preprocessing phase possible.

Example

If the Sender holds (3, 5) and the Receiver holds 7, a VOLE run leaves one party with (x1, x2) and the other with (21-x1, 35-x2): the pairs add up to (21, 35) yet neither side saw the other’s input.

What to watch for

The number of oblivious transfers needed to make beta look random is the whole security question, and it is exactly the parameter this paper corrects. VOLE here is the OT-based flavour; other works build VOLE from Paillier, ring-LWE or silent pseudorandom correlation techniques instead.

Related ideas

Papers

Why ECDSA is hard to share

Two steps of ECDSA are nonlinear in the secrets: the nonce point R needs the inverse of the secret nonce k, and the signature value s needs the product of the nonce k with the key x. Sharing the scheme means doing an inversion and a multiplication on secret-shared data.

Why it is useful

For comparison, in a Schnorr signature the answer is a linear combination of nonce and key, so players can just add their shares; and RSA threshold decryption has no inversion of a shared secret. ECDSA forces the group to invert one shared value and multiply two shared values, which is why threshold ECDSA arrived much later than threshold RSA or threshold Schnorr-style schemes.

How it works

  1. Recall the signing shape: R = g^(1/k), r is derived from R, and s = k(m + x·r) mod q.
  2. Multiplying two Shamir-shared secrets doubles the degree of the sharing polynomial, so the classic protocol needs 2t+1 players to reconstruct - which rules out n-of-n policies.
  3. A multiplicative split of the key (x = x1·x2) sidesteps the degree problem for two parties but does not scale past two.
  4. The paper instead converts multiplicative shares into additive shares pairwise, which keeps t+1 players sufficient.

What to watch for

The RSA and Schnorr comparison is background for orientation; this paper measures itself against earlier threshold ECDSA designs, not against threshold RSA or Schnorr protocols.

Useful background: One key held by many machines.

Papers

Threshold RSA signing

Distributed RSA private-key operations for signatures, including shared exponents, modulus generation and verification of partial signatures.

Threshold Schnorr-family signing

Shared-key signing with Schnorr-style equations, including compatible Edwards-curve variants, signer-set binding and nonce commitments.

FROST

FROST lets a threshold-sized subset of key-share holders jointly create a Schnorr signature without reconstructing the secret key. Each signer contributes a response formed from its long-lived share and a single-use pair of nonces.

Why it is useful

It reduces online coordination: nonce commitments can be prepared before the message and signing subset are selected.

How it works

  1. Prepare private nonce pairs and publish their commitments.
  2. Select a signing subset and distribute the message with an ordered commitment list.
  3. Each signer checks the request and derives binding factors and the common challenge.
  4. Consume the nonces and return a signature share.
  5. Check the shares and combine them into a Schnorr signature.

What to watch for

A malicious selected signer can force an abort. This December 2020 paper proves a separate interactive variant and explicitly gives a heuristic extension to plain FROST; it is not a substitute for later specifications and analyses.

Related ideas

  • Schnorr signatures: The final signature uses the corresponding Schnorr verification equation.

Papers

FROST binding factors

A binding factor combines a signer's two nonce commitments using a hash of the signer identifier, message and ordered commitment list. Each response is therefore tied to the particular signing package.

Why it is useful

A threshold protocol must resist attacks that combine responses from concurrent signing sessions, not just produce the right equation during one honest execution.

How it works

  1. Build a consistently ordered list of signer identifiers and commitment pairs.
  2. Derive a separate factor for each signer from the required transcript.
  3. Combine each commitment pair using its factor.
  4. Use the resulting group commitment in the Schnorr challenge.

What to watch for

Hashing only the message or only one signer's commitments is not this construction. Binding does not make nonce reuse safe. The exact transcript encoding belongs to the concrete protocol version.

Papers

ICE FROST

ICE FROST adds participant identification during FROST key generation.

Papers

Lagrange weighting in threshold signing

A signer multiplies its polynomial key share by a coefficient determined by the selected signing subset. The weighted shares sum to the same group secret even when a different valid subset signs.

Why it is useful

Simply adding Shamir shares does not generally reconstruct the secret at zero.

How it works

  1. Fix the distinct participant identifiers for this signing subset.
  2. Compute each identifier's interpolation coefficient at zero.
  3. Weight each long-term share contribution by that coefficient.
  4. Combine responses so their key terms represent the group secret.

What to watch for

The coefficients depend on the actual subset, not just on the threshold. Duplicate or invalid identifiers make the interpolation formula unsuitable.

Related ideas

Papers

Computing together without sharing private inputs

Secure multiparty computation lets participants compute an agreed result from their private inputs. They learn the permitted output rather than simply sending all their inputs to one another.

ABY3

ABY3 switches between arithmetic, binary, and Yao sharing in three-party computation.

Papers

Ferret

Ferret generates correlated oblivious transfers through correlation expansion.

Papers

GMW MPC

GMW evaluates circuits using shared wire values and interactive gate computation.

Papers

HighGear

HighGear uses somewhat homomorphic encryption and knowledge proofs for SPDZ preprocessing.

Papers

LowGear

LowGear is an Overdrive preprocessing protocol for generating MPC multiplication triples.

Papers

MiniMac

MiniMac is a Boolean-circuit MPC protocol with an offline preprocessing phase.

Papers

Naor-Pinkas adaptive OT

This Naor-Pinkas OT construction handles adaptive receiver queries.

Papers

Overdrive

Overdrive provides homomorphic-encryption-based preprocessing protocols for SPDZ.

Papers

QuietOT

QuietOT generates oblivious transfers using a public-key setup.

Papers

Trident MPC

Trident combines arithmetic, Boolean, and garbled representations in four-party computation.

Papers

Corruption, output and composition models

Compare passive, covert and malicious adversaries; honest versus dishonest majorities; static, adaptive or mobile corruption; fairness, identifiable abort and composability. Models are not duplicate protocol-family branches.

ATLAS MPC

ATLAS is an honest-majority multiparty computation protocol.

Papers

Dishonest-majority security with abort

The security target of the protocol: an active adversary may corrupt all but one player, honest players still learn either the correct output or nothing, and detected cheating stops the run without identifying the cheater.

Why it is useful

With more than half the players corrupt, unconditional security is impossible and guaranteed delivery of output cannot be promised, so the strongest achievable goal is correctness and privacy with the option to abort.

How it works

  1. Model the adversary as actively corrupting up to n minus 1 of the n players and taking full control of them.
  2. Let the online phase be statistically secure given correct prepared data, independent of any computational assumption.
  3. Answer any failed check by aborting, so no one learns a wrong answer, and accept that the run may stop early.
  4. Assume a setup in which the decryption key is already shared, since universal composability cannot be obtained without one.

What to watch for

The abort option means a cheater can deny everyone their output, and the protocol does not reveal who caused it; identifying cheaters is possible but would cost more than linear work. The security claim for the online phase is static, while the preparation phase is additionally only computationally secure. A weaker covert model, where cheating is detected only with some probability, is not developed here.

Useful background: Active and passive adversaries, Universal composability, SPDZ.

Related ideas

  • SPDZ: The protocol that meets this target.

Papers

The dishonest-minority corruption model

The exact setting of this paper: an odd number n = 2t + 1 of players with private synchronous channels and a broadcast channel, facing an unbounded active adversary that may corrupt up to t players at any time during the run.

Why it is useful

An honest majority is the boundary of what is possible: with strictly fewer than half the players corrupt, privacy and correctness are achievable without assumptions, but the jump from tolerating a third to tolerating just under half needs a broadcast channel on top of private point-to-point channels.

How it works

  1. Take n = 2t + 1 players connected by secure synchronous channels, plus a broadcast channel everyone can read.
  2. Let the adversary corrupt up to t players, possibly during the protocol and based on what it has seen so far, then fully control them.
  3. Security target: the adversary can only affect the result by choosing the corrupt players’ inputs, and learns nothing about the honest inputs beyond what the result itself reveals.

What to watch for

The private channels and the broadcast channel are assumed primitives; the paper counts communicated bits and broadcast bits separately, charging broadcast at a premium, and does not discuss how broadcast itself is realized.

Useful background: Unconditional versus computational security.

Related ideas

Papers

Unconditional versus computational security

A security guarantee that holds against an adversary with unlimited computing time and that assumes no problem is hard, compared with a guarantee that only holds against attackers who cannot afford to solve some hard problem.

Why it is useful

The first multiparty-computation protocols were computational: they tolerated up to half the players cheating, but an attacker with enough time could break them. Information-theoretic results then showed that with private channels no assumptions are needed at all: up to a third of the players may cheat with perfect security, and just under half with a broadcast channel. Which regime you are in decides which tools you may use.

How it works

  1. Computational security: the adversary is assumed to be computationally bounded, so commitments and signatures can be used to pin players down.
  2. Unconditional security: the adversary is unbounded and no cryptographic assumption is allowed; only information theory is available.
  3. The worst combination is unconditional security with just under half the players corrupt: there, commitments and signatures are unavailable, and the error-correcting-code tricks that work for a third corruption threshold do not apply either.

What to watch for

Unconditional security still permits a tiny failure probability; only the settings with fewer corrupt players reach perfect security, where the failure probability is exactly zero.

Useful background: Secure multiparty computation.

Related ideas

Papers

Network scheduling and participation

Secure computation with synchrony constraints, asynchronous delivery, participant churn, ephemeral roles and outsourced workers; track liveness separately from privacy and correctness.

Dumbo-MPC

Dumbo-MPC performs multiparty computation in a fully asynchronous network.

Papers

YOSO MPC

YOSO assigns computation to stateless ephemeral roles whose participants each speak once.

Papers

General secure-computation protocol families

A general secure-computation protocol family is a recipe that evaluates an arbitrary function over the private inputs of several parties, classified by how the recipe represents and moves secrets: shares exchanged interactively, garbled encodings, or ciphertexts evaluated homomorphically. This paper contributes the homomorphic route in its cheapest interactive form: each party broadcasts one encryption of its input under its own multi-key homomorphic key, anyone evaluates the function on the ciphertexts, and a second broadcast of partial decryptions reveals only the output.

On-the-fly participation and computation on the web

Since keys are chosen individually and expansion happens only after all ciphertexts are public, a party can encrypt before knowing who else will take part; the participant set is fixed by the public keys that show up.

Why it is useful

This matches settings where the parties cannot talk to each other and can only post to a central server: each party logs in twice, once to deposit its ciphertext and once to post a partial decryption.

How it works

  1. Encrypt your input under your own key, with no knowledge of the other participants.
  2. Collect the public keys of everyone who appeared.
  3. Expand your ciphertext towards that list and let anyone evaluate the function on the expanded ciphertexts.
  4. Post your partial decryption in the second round.

What to watch for

Expansion still needs the complete list of public keys before evaluation, and the scheme requires common public parameters available at key generation, so participation is flexible but the setup is not.

Useful background: The two-round protocol shape.

Papers

Round complexity of secure computation

A round is one pass in which every party broadcasts a message; the round complexity of a protocol is how many such passes are needed before the output is known. This paper gives a general multiparty computation protocol that finishes in two rounds in the common random string model, which is the fewest possible there.

Why it is useful

Rounds measure how much live coordination a protocol needs. A two-round protocol only asks each party to speak twice, so parties that come online late, or that can only reach a server and not each other, can still take part.

How it works

  1. Count one round each time all parties broadcast, assuming a rushing adversary that waits to see the honest messages before choosing its own.
  2. Compare with earlier constant-round protocols built from oblivious transfer, which appear to need at least four rounds.
  3. Recall the two-round lower bound that holds once a common random string is available, so two rounds is optimal.
  4. Note that the previous two-round protocol needed indistinguishability obfuscation, while this one needs only the learning with errors assumption plus, for malicious security, non-interactive zero knowledge arguments.

What to watch for

Optimality is tied to the common random string model with a broadcast channel. Without the string, stronger lower bounds of four and five rounds are known for malicious adversaries.

Useful background: Secure multiparty computation.

Related ideas

Papers

Semi-malicious security and the one-honest-party barrier

The basic two-round protocol is proved secure against a static adversary corrupting all but one party, and against a semi-malicious adversary: one that must follow the protocol but may pick its inputs and randomness in any adversarial way.

Why it is useful

The obstacle is real rather than technical. The simulator of a partial decryption needs every other secret key, so it can stand in for only one honest party at a time, and the proof breaks with two or more honest parties.

How it works

  1. Prove the basic protocol for the single case of exactly one honest party.
  2. Redefine the function that the protocol computes, adding a mode flag and a pseudorandom function key so one designated honest party can mask the inputs of the others.
  3. Argue security for any number of corruptions using only pseudorandom functions, which adds no new assumption.
  4. Compile to fully malicious, universally composable security with non-interactive zero knowledge arguments, adding no rounds.

What to watch for

Corruption is static, so the adversary must choose its victims before the protocol starts, and adaptive security is left as an open problem. The generic compiler for malicious security needs an extra assumption.

Useful background: The two-round protocol shape, One-round threshold decryption with smudging noise.

Papers

The three-round threshold FHE template

The earlier recipe for secure computation from fully homomorphic encryption has three steps: the parties jointly create one encryption key whose decryption key is shared among them, everyone encrypts an input under that common key, and finally they jointly decrypt the homomorphic output.

Why it is useful

It shows where the third round comes from. The distributed key generation must finish before anyone can encrypt, so it costs a full round in addition to the input round and the output round.

How it works

  1. Run a one-round protocol for threshold key generation, so the public key is known to all and the secret key exists only as shares.
  2. Each party encrypts its input under the common public key and broadcasts it; no incomplete set of parties can decrypt.
  3. Anyone evaluates the function homomorphically on the broadcast ciphertexts.
  4. Run a one-round protocol for threshold decryption of the resulting output ciphertext.

What to watch for

The two distributed steps can be run generically for any fully homomorphic scheme using general multiparty computation, but that costs many rounds; only special schemes give one-round steps.

Useful background: Round complexity of secure computation, Homomorphic evaluation of encrypted data.

Papers

The two-round protocol shape

The complete protocol has two broadcasts. In round one each party posts a public key and an encryption of its input; in round two each party posts partial decryptions of the ciphertext that encrypts the output. Everything in between is local computation on ciphertexts.

Why it is useful

Because no step needs a reply before the next honest message is sent, the parties never have to be online together beyond those two broadcasts, and the round count matches the lower bound.

How it works

  1. Round one: generate a key pair, encrypt the input bit by bit under your own public key, and broadcast the key with the ciphertexts.
  2. Between rounds: expand every received ciphertext towards the full list of public keys and evaluate the circuit, obtaining an encryption of the output.
  3. Round two: compute partial decryptions of the output ciphertext with your own secret key and broadcast them.
  4. Combine all partial decryptions and read off the output bits.

What to watch for

The functionality is deterministic and all parties receive the same output; randomized functionalities and individual outputs need additional standard techniques the paper does not detail.

Useful background: The three-round threshold FHE template, Multi-key fully homomorphic encryption, One-round threshold decryption with smudging noise.

Papers

TinyOLE

TinyOLE builds arithmetic two-party computation from oblivious linear evaluation.

Papers

Garbling and randomized encodings

A Boolean circuit computes with bits through gates such as AND and XOR. Garbling replaces those bits with labels so another party can evaluate the circuit without seeing the intermediate values. The choice of labels controls both security and communication cost: free-XOR removes XOR tables, row reduction removes predictable rows, and half gates reduce private AND tables to two blocks. A full private-computation protocol must also deliver input labels safely and define which outputs each party may learn.

BMR garbling

BMR extends garbled-circuit evaluation to multiparty computation.

Papers

Correlation assumptions for garbling hashes

A garbling hash must remain suitable when secret labels have structured relationships. In free-XOR, many pairs differ by the same hidden offset, and hashed values may also be combined with that offset.

Why it is useful

Ordinary collision resistance or independent-key security does not by itself describe the oracle behavior used in the half-gates proof.

How it works

  1. Specify the related inputs and outputs that an attacker can observe.
  2. Compare hash-derived oracle answers with random-function answers.
  3. Restrict the oracle queries exactly as the security definition requires.
  4. For this paper's weaker natural-key definition, generate labels using the permitted operations and use sequential fresh oracle indices.

What to watch for

The natural-key restriction is part of the assumption, not a restriction that real attackers obey when calling the public hash. The paper allows unrestricted direct hash access. Reusing indices or changing label derivation can leave the proved construction.

Related ideas

  • Free-XOR: Introduces the shared-offset correlations that the hash assumption must handle.

Papers

Evaluator half-gates

An evaluator half-gate is an AND gate for which the evaluator knows one logical input. That knowledge lets it select how to combine a decrypted value with the other input label.

Why it is useful

It handles the complementary case to a generator half-gate, again with one transmitted block after row reduction.

How it works

  1. When the known input is zero, derive the fixed zero output label.
  2. When it is one, derive a correction string and XOR it with the label for the other input.
  3. Use the known input's label to mask the appropriate result.
  4. Choose the zero-case output label so that the first row need not be sent.

What to watch for

The evaluator still needs the corresponding valid label. Knowing a logical bit is not permission to manufacture either label. Revealing an originally secret input just to use this construction would change the privacy goal.

Useful background: Garbled row reduction, Free-XOR.

Papers

Fixed-key blockcipher hashing for garbling

A public fixed-key blockcipher can be used as a permutation inside a garbling hash. Secrecy comes from the wire labels, not from keeping that blockcipher key secret.

Why it is useful

This permits fast hardware blockcipher instructions while keeping the hash input dependent on the secret label and a public gate index.

How it works

  1. Combine a label and index into an internal value K.
  2. Apply the fixed public permutation to K.
  3. XOR the permutation output with K.
  4. Analyze the whole construction, including access to the inverse permutation and the allowed label correlations.

What to watch for

The paper analyzes an ideal random permutation, not arbitrary concrete AES behavior. Its doubling operation is in a binary extension field, not ordinary integer multiplication; index encoding and field representation require a concrete specification.

Related ideas

Papers

FleXOR

FleXOR allows different wire-label offsets rather than requiring one offset throughout a circuit. An XOR gate may then need translation data to combine differently encoded wires.

Why it is useful

It trades some XOR-gate communication for compatibility with the earlier two-block GRR2 method for AND gates.

How it works

  1. Choose offsets with the circuit structure in mind.
  2. Use no translation blocks where an XOR already has compatible labels.
  3. Use one or two blocks where translations are needed.
  4. Combine this with GRR2 for the non-XOR gates.

What to watch for

The half-gates paper summarizes FleXOR; its primary construction has not been independently read here. Costs depend on the circuit and offset choices. FleXOR and free-XOR are related techniques, not interchangeable names.

Related ideas

  • Free-XOR: Uses one shared offset and therefore avoids offset translation at XOR gates.

Papers

Free-XOR

Free-XOR chooses the two labels on every wire to differ by the same secret string. XORing two available input labels then produces the label for the XOR of their hidden bits.

Why it is useful

XOR gates need no transmitted table and no cryptographic hash calls, which can substantially reduce the cost of a Boolean circuit.

How it works

  1. Choose a circuit-wide secret offset R.
  2. Represent a wire's labels as A and A XOR R.
  3. For an XOR gate, use the XOR of the input zero-labels as the output zero-label.
  4. The evaluator XORs its two available labels; the R terms combine according to the logical input XOR.

What to watch for

The common offset must stay hidden from the evaluator, and the hash construction for the other gates must tolerate the resulting key correlations. Free means no garbled-table blocks for XOR, not zero processing, storage or whole-protocol communication.

Useful background: Wire labels in garbled circuits.

Papers

Garbled row reduction

Garbled row reduction saves transmission by choosing an output label so that one encrypted table row becomes a known all-zero string.

Why it is useful

The evaluator can reconstruct an omitted zero row instead of receiving it over the network.

How it works

  1. Begin with the gate table and its label-based masks.
  2. Choose an output label equal to the mask for a selected row.
  3. That row now encrypts to zero and can be omitted.
  4. Transmit the remaining rows and make the omitted-row convention part of evaluation.

What to watch for

The choices constrain the output labels. GRR3 leaves room for the common offset needed by free-XOR; the historical GRR2 interpolation method fixes both labels and is not directly compatible with it. Half gates use a different two-block construction.

Papers

Generator half-gates

A generator half-gate is an AND gate for which the generator knows one logical input in advance. It can encode that choice while keeping it hidden from the evaluator.

Why it is useful

Knowing one input reduces the table to two cases, and row reduction removes one of the two transmitted blocks.

How it works

  1. If the known input is zero, both cases must produce the zero output label.
  2. If it is one, the output follows the other input.
  3. Mask the required output label using each possible label of the other input.
  4. Choose an output label to make one row zero, and transmit the other row.

What to watch for

The generator must actually know the designated input. This is a specialized component, not a one-block private AND gate with two arbitrary unknown inputs.

Useful background: Garbled row reduction, Free-XOR.

Papers

Half-gates garbling

Half-gates garbling expresses a private AND gate as two simpler AND gates followed by a free XOR. One simpler gate uses a bit known to the generator; the other uses a masked bit known to the evaluator.

Why it is useful

It uses two transmitted label-length blocks per AND gate while preserving zero-block XOR gates.

How it works

  1. Split a AND b into (a AND r) XOR (a AND (b XOR r)).
  2. Use the secret permutation bit on wire b as r.
  3. The generator knows r; the evaluator sees b XOR r as the selection bit of its label.
  4. Garble the two halves with opposite orientations, then XOR their output labels.

Example

For a=1, b=1 and r=1, the two halves output 1 and 0. Their XOR is 1, which equals a AND b.

What to watch for

The gate costs four hash calls for the generator and two for the evaluator. These are gate-table costs, excluding input transfer, output handling and security wrappers. The paper's benchmark percentages are not universal speedups.

Useful background: Generator half-gates, Evaluator half-gates, Point-and-permute.

Papers

Lower bounds for linear garbling

A lower bound identifies what a specified class of constructions cannot achieve. This paper proves that its linear single-AND-gate model needs at least two label-length blocks when privacy is required.

Why it is useful

It explains why reducing four rows to three and then two does not automatically suggest another similar one-block construction.

How it works

  1. Fix a model using random-oracle queries and linear operations over a binary extension field.
  2. Restrict queries within one atomic gate to be nonadaptive and table lengths to whole blocks.
  3. Require security scaled to the label length, so shortening labels cannot fake an improvement.
  4. Use correctness and privacy to force at least two independent transmitted components.

What to watch for

The result is not a universal lower bound for all garbling or all circuits. Combining gates introduces adaptive queries outside this model. The paper leaves arbitrary constructions and a stronger multi-gate analysis open.

Papers

MYao

MYao brings row reduction and half-gates to multiparty Yao-style garbling.

Papers

Privacy, obliviousness and authenticity of garbling

Garbling privacy hides inputs beyond the permitted output. Obliviousness hides inputs when decoding information is withheld. Authenticity prevents an evaluator from producing a different accepted encoded output.

Why it is useful

The properties support different uses of the same circuit encoding and must not be treated as interchangeable.

How it works

  1. For privacy, simulate the garbled circuit, encoded input and decoding information using the circuit and its output.
  2. For obliviousness, simulate the circuit and encoded input without knowing the output.
  3. For authenticity, require a different candidate encoded output to fail decoding except with negligible probability.
  4. Choose the decoding interface and security property needed by the surrounding protocol.

What to watch for

The paper's basic selection-bit decoder accepts arbitrary strings and does not provide authenticity. It separately proposes output-label hash checks with rejection. These games do not make a malicious generator supply the intended circuit.

Papers

Privacy-free garbling

Privacy-free garbling retains authenticity while dropping input privacy for the evaluator. It is useful when the evaluator already knows the entire input and the values on intermediate wires.

Why it is useful

A protocol should not pay to hide data from a party that already knows it. In a cited zero-knowledge protocol, the evaluator is the prover who knows the witness.

How it works

  1. Use the evaluator's knowledge of a logical input at every AND gate.
  2. Encode each AND using only an evaluator half-gate.
  3. Keep XOR gates free.
  4. Add the required authenticated output decoding and use the garbling inside the separately analyzed protocol.

What to watch for

This does not hide inputs from the evaluator. Its use inside a zero-knowledge protocol depends on the surrounding protocol and reversed party roles; replacing private garbling with it in ordinary two-party computation would remove a needed guarantee.

Useful background: Evaluator half-gates, Privacy, obliviousness and authenticity of garbling.

Papers

Yao garbled circuits

A garbled circuit replaces each bit on a circuit wire with a secret-looking label and each logic gate with a table that operates on those labels. An evaluator can compute an encoded output without learning the intermediate bits.

Why it is useful

This separates knowing how to carry out a computation from knowing the values it processes. It is a building block for two-party private computation.

How it works

  1. Express the computation as a circuit of Boolean gates.
  2. The generator prepares wire labels, encoded gate tables and output-decoding information.
  3. Give the evaluator only the labels corresponding to the chosen input.
  4. Evaluate gates in dependency order, then decode the output that the protocol permits.

What to watch for

Garbling alone does not provide the whole input-transfer protocol or protection against a generator that supplies the wrong circuit. The paper makes the circuit public and analyzes a single encoded input; function hiding, reuse, fairness and malicious-party security require separate guarantees.

Related ideas

  • One-out-of-two oblivious transfer: Can deliver one input label without revealing the evaluator's choice; this paper does not replace the surrounding transfer protocol.

Papers

Point-and-permute

Point-and-permute gives each wire label a visible selection bit. The bit tells the evaluator which encrypted table row to use without revealing whether the label means zero or one.

Why it is useful

It removes the need to try every encrypted row at each gate.

How it works

  1. Give the two labels on a wire opposite selection bits.
  2. Choose the association between selection bits and logical values secretly.
  3. Arrange the gate table by the input selection bits.
  4. Use the available labels and their selection bits to select and open one row.

Example

If the zero-label selection bit is r, the label for logical bit b has selection bit b XOR r.

What to watch for

A selection bit is a masked logical value, not the logical value itself. The secret association and the surrounding label construction must remain secure; adding visible bits to arbitrary encodings is not sufficient.

Papers

Wire labels in garbled circuits

A wire has two labels: one encodes zero and the other encodes one. The evaluator normally holds only the label for the value on that wire, without knowing which logical value it represents.

Why it is useful

A label lets later gates process a value while keeping that value hidden. It is also a secret capability: learning the other label can enable an extra evaluation path.

How it works

  1. Associate two strings with each wire.
  2. Keep their logical meanings hidden from the evaluator except where output decoding is intended.
  3. Use the available input labels to derive the appropriate output label.
  4. In free-XOR constructions, preserve a common hidden difference between the two labels on every wire.

What to watch for

Labels need not be mutually independent: free-XOR deliberately correlates them. Learning both labels on one wire reveals the shared offset in that construction, so labels cannot be treated as public identifiers.

Papers

Garbling for RAM and branching programs

Garbled RAM, stacked garbling and branch encodings for computations with memory or conditional execution, with explicit leakage of program shape and access behavior.

LogStack

LogStack is a stacked-garbling construction for branching computation.

Papers

NanoGRAM

NanoGRAM is a garbled-RAM construction for evaluating memory-accessing programs.

Papers

Stacked garbling

Stacked garbling overlays encodings of alternative branches of a computation.

Papers

Interactive computation on shared values

Evaluate operations on shares with interaction where local linear evaluation is insufficient; covers authenticated and unauthenticated sharing without presuming a particular corruption threshold.

Arithmetic sharing protocols

Secure field and ring arithmetic on shared values, including polynomial, additive and replicated representations and authenticated arithmetic protocols.

Authenticated shares under a global MAC key

Each value is held as two additive sharings at once: shares of the value and shares of its MAC, the product of the value with a secret global MAC key that is itself additively shared.

Why it is useful

The MAC (message authentication code) ties every value to a key no corrupted party knows, so substituting a false value at opening time will fail a later check; values can be partially opened while the MAC shares stay hidden.

How it works

  1. Share a global MAC key α additively between all players.
  2. For each value a, give player Pi a share ai of a and a share γ(a)i of α · a.
  3. Additions and scalar multiplications need no communication.
  4. Partial opening reveals only the value shares ai; the MAC shares remain secret.

What to watch for

If the MAC key ever becomes public, every remaining shared value can be forged, which is exactly what the MAC-checking procedure is built to avoid.

Useful background: Splitting SPDZ into offline and online phases.

Papers

Authenticated shares with one global MAC key

A representation of a secret value that stores additive shares of the value together with additive shares of a single authentication tag. The tag is the value multiplied by a secret key that is itself shared among the players.

Why it is useful

Earlier schemes gave every player their own authentication key, so each of the n shares needed n tags and the cost grew with the square of the number of players. Authenticating the value once with one global key removes that quadratic blowup, which is what makes the online phase scale.

How it works

  1. Choose one secret key at random in the field; it is never given to any single player.
  2. For a secret value, store n additive shares that sum to the value, and n more shares that sum to the key times the value.
  3. Adding two secrets, or multiplying a secret by a public constant, is done coordinate-wise on both sets of shares, so no communication is needed.
  4. A public constant can also be added to a secret by adjusting one share and a public offset, which is why the representation carries a public modifier.

What to watch for

Checking a tag requires the key, and revealing the key would let a cheater forge tags, so the key is only opened once, at the very end of the computation. The statistical guarantee is relative to the size of the field, so small fields need extra machinery.

Useful background: Additive secret sharing, Message authentication codes, SPDZ.

Related ideas

Papers

Authentication tags computed by a mini MPC

A way to pin a player to his share: attach a tag τ = µ · σi + ν to share σi, where the key (µ, ν) is known only to another player acting as verifier, and compute that tag jointly by all players instead of letting any single player compute it.

Why it is useful

In the setting with just under half the players corrupt, plain Shamir shares do not carry enough redundancy to reconstruct a value when some shares are wrong, so lying must be detectable. Earlier solutions had a dealer compute the tag, which only works if the dealer knows the key; guarding against a dishonest dealer forced every share to be shared again, giving at least quadratic cost. Computing the tag as a small multiparty computation keeps the key with the verifier and removes the double sharing.

How it works

  1. Give each player a long-term key µ and fresh one-time keys ν per verifier, per block and per share holder.
  2. Run a mini MPC that takes the share holder’s share and the verifier’s key as private inputs and outputs the tag to the share holder.
  3. Skip re-sharing the share: by the symmetry of Shamir’s scheme the other players’ shares already form a sharing of σi, so the tag is computed from the sharing that already exists, using twisted sharings of the key.
  4. Verify the tags in batches by cut-and-choose, so that a wrong tag is caught with negligible error probability.

Example

With a key µ and one-time pad ν, a tag on the value 7 might be τ = 5 · 7 + ν; changing the value to 8 without knowing µ and ν forces a guess of 5 · 7 + ν again, which succeeds only with tiny probability.

What to watch for

The guarantee is statistical: a player who does not know the key produces a consistent wrong share and tag with probability at most 1/|K|. An adversary who corrupts t players other than the share holder can actually learn that holder’s verifier key, but then that share holder is guaranteed to remain honest, so the knowledge is useless.

Useful background: Multiplication with Beaver triples, Packing secrets into a bigger field.

Related ideas

Papers

BGW MPC

BGW evaluates multiparty computations using polynomial secret sharing.

Papers

Catching cheaters by opening seeds

The covert-security mechanism used throughout the paper: run a sub-protocol several times from committed random seeds, then open all runs except one and replay the opened runs from their seeds to verify they were executed honestly.

Why it is useful

It replaces expensive zero-knowledge proofs with cheap commitments plus replay, and because the checks happen before any private input exists, a caught cheater learns nothing from the attempt.

How it works

  1. Each player commits to random seeds, one per planned run of the sub-protocol.
  2. All runs execute in parallel.
  3. All but one run are opened: players reveal their seeds so that everyone can recompute each step and compare.
  4. If any opened run is inconsistent, the protocol aborts; otherwise the single unopened run is trusted.
  5. A cheater therefore succeeds only with probability at most 1/c, where c is the number of runs.

Example

The implementation uses c = 5, 10 and 20, so the detection probabilities are 4/5, 9/10 and 19/20.

What to watch for

The guarantee is a bound of 1/c: raising the detection probability costs running the sub-protocol c times, and a detected cheat aborts the run instead of repairing it.

Papers

Checking MACs without revealing the key

A batch MAC check that keeps the MAC key secret: for all partially opened values, players locally compute shares of a random linear combination of values and MACs, then open that single combination and accept only if it is zero.

Why it is useful

The original SPDZ check opened the MAC key, which made all unrevealed shared data useless and restricted the protocol to one function evaluation; keeping the key secret allows continuing, reactive computation and moves the sacrifice checks into the offline phase.

How it works

  1. Collect all partially opened values and their MAC shares.
  2. Take a random linear combination of the values and their MACs; every player computes its share locally.
  3. Open the one combined value and check it equals zero.
  4. A wrong value or MAC passes only with probability 2/p, where p is the field size.
  5. The same procedure lets the offline phase sacrifice tuples to verify them before use.

What to watch for

The check certifies only the batch it examined, with soundness error 2/p, so the field size and the batching choice set the concrete guarantee.

Useful background: Authenticated shares under a global MAC key, Multiplying shared values with a triple.

Papers

Generating the encryption key without a trusted party

A distributed key generation protocol in which the players themselves create the public key of the encryption scheme and additive shares of the matching secret key, made covertly secure by the seed-opening technique.

Why it is useful

The original SPDZ paper assumed this key material was produced by an unspecified generic MPC setup; an explicit, covertly secure protocol removes that assumed trusted setup.

How it works

  1. Run the basic key generation c times in parallel, each from committed seeds.
  2. Each player contributes a low-weight secret-key share and a public-key element; the combined values form one key pair.
  3. Extra key-switching material is built by encrypting secret-key shares under the resulting public key, since no player ever knows the whole key.
  4. All but one run are opened and verified from their seeds; cheating survives with probability at most 1/c.

What to watch for

Encrypting secret-key shares under the resulting public key requires an extra assumption, called circular security, that encrypting messages which depend on the secret key itself stays safe - something the standard lattice hardness assumption does not cover.

Useful background: Catching cheaters by opening seeds, Producing triples with somewhat homomorphic encryption.

Papers

Multiplying shared values with a Beaver triple

A multiplication rule for shared values: subtract a prepared random product from the two factors, open the differences, and recombine. One prepared triple of random values with a known product buys one secure multiplication.

Why it is useful

Additive sharing is linear, so additions and multiplications by public constants are free, but a product of two secrets is not linear and would leak information if opened directly. The triple randomises the opened differences so they reveal nothing about the factors.

How it works

  1. Take a prepared triple of shared values where the third is the product of the first two.
  2. Partially open the difference between the first factor and the first triple value, and likewise for the second factor.
  3. Locally compute the shared product as the triple value plus each opened difference times the other triple value, plus the product of the two differences.
  4. Consume the triple; it is never reused.

What to watch for

The rule is only correct if the triple really satisfies the multiplicative relation, so each triple must be validated before use. The opened differences also have to be checked at the end, since they are broadcast before any authentication is verified.

Useful background: Authenticated shares with one global MAC key, Beaver triples.

Related ideas

Papers

Multiplying shared values with a triple

Beaver-style multiplication: to multiply two shared values, partially open their differences from a preprocessed triple and finish the product with local arithmetic; a square pair does the same for squaring with a single opening.

Why it is useful

It turns each multiplication into two openings plus free local work, and squaring into one opening, so the online phase stays fast; shared random bits then support comparison and fixed-point operations on top.

How it works

  1. Take a triple of authenticated shares {a, b, c} with c = a · b.
  2. Open x − a and y − b to get ε and δ.
  3. Compute the sharing of z = x · y as c + ε · b + δ · a + ε · δ.
  4. To square, open x − a once and use a square pair with b = a².
  5. Shared bits, where a ∈ {0, 1}, feed higher-level operations such as comparison and bit decomposition.

What to watch for

Each triple and square pair is consumed once, and the opened differences reveal nothing about x and y only because the triple values are uniformly random.

Useful background: Authenticated shares under a global MAC key.

Papers

Opening values and the final MAC check

A procedure for revealing a shared value to everyone and verifying, at the very end, that every revealed value was honest. Shares are sent to one designated player who sums and broadcasts, and all checks are postponed and then combined into one.

Why it is useful

Checking a tag needs the secret key, but once the key is public anyone can forge tags. Postponing the check and binding everyone to their answers first means that learning the key is too late to be useful.

How it works

  1. During the computation, open values partially: each player sends their share to one designated player, who adds the shares and broadcasts the result; the tag shares stay secret.
  2. At output time, open a random value and use its powers as coefficients of one linear combination of all values opened so far.
  3. Each player commits to their share of the combined tag, and to their shares of the output value and its tag.
  4. Only now open the shared key, and check that the combined tag equals the key times the combined value; abort if not, otherwise accept and open the output.
  5. If any opened value was dishonest, the combined check fails except with probability about two over the field size.

What to watch for

Values opened earlier in the run may be wrong for a while, so intermediate results cannot be trusted until the final check passes. A large field is what makes the single combined check convincing; the paper handles small fields by moving keys and checks to an extension field.

Useful background: Authenticated shares with one global MAC key.

Related ideas

  • SPDZ: The protocol whose output step this is.

Papers

Packed secret sharing and the price of using it

A classical amortization idea: put several secrets into one Shamir sharing by evaluating a single low-degree polynomial at several points, so one sharing and one reconstruction handle a whole batch of secrets.

Why it is useful

It is the standard way to make information-theoretic MPC cheaper, and the paper points out exactly when it can be used: only after lowering the corruption threshold t by a constant fraction. This paper refuses that trade and keeps optimal resilience, which is why it needs the field packing, batch verification and tag techniques instead.

How it works

  1. Packed secret sharing: one polynomial of degree t carries several secrets, one per evaluation point; the price is that the effective tolerance drops, because k packed secrets behave like extra corruption.
  2. The cheap route: lower t by a small constant fraction, then use packed secret sharing or committee selection.
  3. This paper’s route: keep t just under n/2 and get the amortization from packing secrets into an extension field, batch-checking triples and batch-authenticating shares.

What to watch for

The mechanics of packed secret sharing are background for these lessons, not material quoted from this paper: the paper mentions the technique once, as a tool it deliberately does not use.

Useful background: Packing secrets into a bigger field.

Related ideas

Papers

Packing secrets into a bigger field

A way to make one sharing carry many secrets: identify a block of e elements of the small field F with a single element of a big extension field K, so a Shamir sharing over K hides a whole vector of small-field values at once.

Why it is useful

Sharing, verifying and authenticating each secret separately would cost a constant amount per secret, which would break the near-linear target. By working over K, a cost that is constant per big-field element is divided by e secrets, and with the right block sizes the per-secret share of that cost becomes negligible.

How it works

  1. Fix a linear bijection between e-tuples of F-elements and elements of K, so a vector (s1, . . . , se) is one element σ ∈ K.
  2. Because Shamir sharing is linear, e separate sharings over F can be re-read as one sharing of σ over K using the same evaluation points, with each player holding one K-element share.
  3. Each player’s second-level sharings are compressed into O(M/n) local base sharings, each block of which is treated as one sharing over K, so communicating all subshares costs only a linear number of field elements per multiplication triple.
  4. One set of tag shares then authenticates a large block of base sharings at once, making the cost per triple negligible.

Example

If K extends F by degree e = 10, one player-share in K (one big element) represents ten secrets of F, so sending that one share moves ten secrets’ worth of information.

What to watch for

Packing this way creates statistical dependencies: the second-level shares of different secrets are not fully independent, so revealing them requires padding with fresh independent sharings of zero. The packing changes how cheap things are, not how many players may cheat.

Useful background: Shamir secret sharing, The near-linear claim and its fine print.

Related ideas

Papers

Producing triples with somewhat homomorphic encryption

The offline phase encrypts each player’s random choices under a somewhat homomorphic encryption scheme that can multiply ciphertexts once, forms the product under encryption, and decrypts it jointly so the players end up holding shares of c = a · b.

Why it is useful

Homomorphic multiplication computes on encrypted shares without ever revealing them, and the SIMD packing of the BGV scheme (many message slots processed in parallel inside one ciphertext) yields many triples per ciphertext, so triple production amortizes well.

How it works

  1. Each player encrypts its shares of a and of b under the joint public key.
  2. The players use the one available level of multiplicative depth to get an encryption of c = (a1 + · · · + an) · (b1 + · · · + bn).
  3. Distributed decryption turns that ciphertext into shares of c, with each player adding random smoothing noise so the decryption shares do not leak the secret key.
  4. MACs, square pairs and shared bits are produced with similar steps.

What to watch for

Only multiplicative depth one is available, parameters must fit the noise budget for exactly that one multiplication, and decryption shares must carry extra noise to stay secure.

Useful background: Splitting SPDZ into offline and online phases, Authenticated shares under a global MAC key.

Papers

SPDZ

A protocol in which any number of players jointly compute an arithmetic circuit over a finite field, staying correct and private even if all but one of them cheat. Every secret value is held as additive shares plus shares of one message authentication code made with a single secret key, and all the expensive public-key work is pushed into a separate preparation phase.

Why it is useful

When a majority of players may cheat, protocols with unconditional security cannot exist, and earlier computationally secure ones needed work that grew with the square of the number of players. This design brings the online work down to roughly what a single computer would spend on the same circuit, and a matching lower bound shows the amount of prepared data is close to the best possible.

How it works

  1. Before any inputs exist, the players run a preparation phase that produces shared random values, a shared secret key and multiplication triples.
  2. Each player masks a private input with a prepared random value and broadcasts the difference.
  3. Additions are done locally on the shares; each multiplication consumes one prepared triple.
  4. At the end, one combined authentication check on all opened values decides whether to accept the output or abort.

Example

For three players and a 64-bit prime field, the paper reports a secure multiplication in about 0.05 milliseconds online and about 13 milliseconds to prepare.

What to watch for

The online phase is only unconditionally secure if the prepared data is correct; the preparation phase itself relies on a lattice assumption and on a setup assumption for the shared decryption key. Cheating is answered by aborting the whole computation, not by naming the cheater.

Useful background: Additive secret sharing, Message authentication codes.

Related ideas

  • Beaver triples: Consumed one per multiplication in the online phase.

Papers

SPDZ2k

SPDZ2k adapts SPDZ-style computation to arithmetic modulo a power of two.

Papers

Splitting SPDZ into offline and online phases

The preprocessing model of SPDZ: an offline phase produces shared randomness before the function or the inputs are known, and an online phase consumes that material to run the actual secure computation, tolerating up to n − 1 corrupted parties out of n.

Why it is useful

Moving the expensive cryptography ahead of the inputs keeps the online phase almost as cheap as passively secure secret sharing, and no honest majority is assumed, so security rests on cryptography alone.

How it works

  1. Offline: produce multiplication triples, square pairs and shared bits as authenticated shares.
  2. Online: evaluate the circuit on shared values, consuming the preprocessed material as it goes.
  3. Dishonest majority is tolerated, so correctness comes from MACs and encryption rather than from a majority of honest parties.

What to watch for

Preprocessed material is single-use: every triple, square pair and bit is consumed as the online computation runs, so the offline phase must keep producing at the required rate.

Papers

The near-linear claim and its fine print

The paper’s headline result: a protocol for the dishonest-minority setting whose communication is about n log n + κ bits per multiplication gate, asymptotically matching the best protocol that assumes nobody cheats at all.

Why it is useful

Before this paper, the best protocol with the same unconditional guarantee and the same resilience cost about n squared times κ bits per multiplication gate, so the gap between the cheating and non-cheating settings was a factor of about n. Closing it settles the asymptotic question in the hardest of the three classical settings, and the authors argue nobody can do much better: not even a passive-secure protocol is known below n log n bits per gate.

How it works

  1. The general bound is O(ctot · (nφ + κ) + dM n2κ + n7κ) bits plus O(n3κ) broadcast bits, where φ is the number of bits per field element, ctot counts the circuit’s inputs, outputs and multiplications, and dM is the multiplicative depth.
  2. Amortized means the circuit is assumed large enough that the terms independent of its size are ignored.
  3. Trading a slightly larger exponent on n in the fixed terms brings κ down to κ/n raised to any fixed constant, so for security parameter κ polynomial in n the per-gate cost is just O(n log n) for binary circuits.

What to watch for

The fine print: the near-linear per-gate bound needs circuits that are not too narrow, meaning the multiplicative depth dM is well below the number of multiplication gates (the depth term dM n2κ is what breaks otherwise); the circuit-size-independent terms, such as O(n7κ), dominate for small circuits and improving them is left open; and the depth restriction is inherited from earlier near-linear protocols, not known to be inherent.

Useful background: The dishonest-minority corruption model.

Related ideas

Papers

What covert security promises

A security level between passively secure and fully actively secure MPC: a party that deviates from the protocol is caught with a chosen, noticeable probability such as 90 percent, rather than with overwhelming probability.

Why it is useful

Active security for more than two parties was at the time vastly more expensive, and Aumann and Lindell argued that a high chance of catching a cheater is already a practical deterrent, so a protocol can be much cheaper while remaining good enough for real applications.

How it works

  1. Fix a detection probability, for example 9 in 10.
  2. Treat an undetected deviation as accepted residual risk: the adversary can still succeed, but only with the complementary probability, here 1 in 10.
  3. Contrast with active security, where cheating succeeds only with negligible probability.

Example

A partner who tries to falsify a joint computation is publicly caught nine times out of ten; for many commercial settings that reputational risk already prevents the attempt.

What to watch for

Detection is a deterrent, not a barrier: a participant willing to accept a one-in-ten chance of success is merely gambling, so the detection probability must be chosen with that residual risk in mind.

Papers

Where the speed comes from

The reported gains come from replacing zero-knowledge proofs with seed-based cut-and-choose, tightening the noise analysis so parameters shrink, dropping the requirement to amortize over millions of triples, and a Montgomery, multi-threaded implementation.

Why it is useful

Each change removes a cost: proofs become seed commitments, a smaller enforced noise gap allows smaller ciphertexts, short offline runs fit more uses, and the code uses several cores.

How it works

  1. A sub-protocol EncCommit replaces the earlier zero-knowledge proof of plaintext knowledge by committing to seeds and using cut-and-choose.
  2. The gap between the noise honest players put in and what corrupt players can be forced to use becomes essentially linear instead of exponential, so parameters shrink.
  3. Offline runs can produce a few thousand triples instead of millions per batch.
  4. Modular arithmetic uses Montgomery form, a way of multiplying modulo p without trial division, and the offline phase runs on several threads.

Example

For covert security the paper reports checked 64-bit triples at a run-time comparable to the earlier unchecked ones, while improving the detection probability from 1/2 or 1/4 to 4/5, 9/10 or 19/20.

What to watch for

The active-security variant is not yet faster in practice: in the measured test it ran about twice as slowly as the earlier proof-based protocol, and its claimed advantage relies on extrapolating to larger batch sizes that were not run because of memory constraints.

Useful background: Producing triples with somewhat homomorphic encryption, Catching cheaters by opening seeds.

Papers

Boolean sharing protocols

Bit-level circuit evaluation using shared wires and interactive nonlinear gates, including OT-based and authenticated-binary protocols.

TinyOT

TinyOT uses OT-based preprocessing and authenticated binary shares for circuit evaluation.

Papers

Mixed-representation computation

Combine arithmetic, Boolean and garbled representations in one computation, choosing domains by operation cost and converting between them.

ABY

ABY combines arithmetic sharing, Boolean sharing, and Yao garbling for two-party computation.

Papers

MPC languages, runtimes and deployment

Compilers, intermediate representations, scheduling, transport and implementation systems for secure computation, including hybrid protocols and hardware-assisted execution. Hardware trust and leakage are linked to implementation.

ABY2.0

ABY2.0 is a mixed-protocol two-party computation system organized around offline and online work.

Papers

Offline resources and online consumption

Produce and consume circuit-independent or circuit-dependent resources before private inputs arrive; account for setup trust, authentication and one-use state.

MASCOT

MASCOT uses oblivious transfer to generate arithmetic preprocessing for MPC.

Papers

Offline and online phases with a replaceable dealer

A way of organising a secure computation into two parts: a preparation (offline) phase that produces raw material before anyone knows the function or the inputs, and an online phase that does the actual computation using only cheap information-theoretic tools.

Why it is useful

It separates the expensive public-key machinery from the interactive computation. The online phase then needs no heavy cryptography at all, and the prepared material can be produced in advance, in parallel, or even by a different method.

How it works

  1. Design the online protocol as if a trusted dealer handed out random raw material on demand.
  2. Replace the dealer by a cryptographic protocol that produces indistinguishable material; this protocol becomes the offline phase.
  3. Run the offline phase ahead of time and stockpile triples, random values and the shared authentication key.
  4. During the online phase, consume the stockpile while computing the circuit on the real inputs.

What to watch for

The two phases are only connected through the specification of the raw material, so any method that produces it correctly can be swapped in. Fairness is not attempted: with a dishonest majority the protocol may abort instead of delivering output.

Useful background: SPDZ, Beaver triples.

Related ideas

Papers

SUPERPACK

SUPERPACK provides dishonest-majority MPC with circuit-dependent or circuit-independent preprocessing.

Papers

TurboPack

TurboPack is an honest-majority MPC protocol with offline preprocessing and online arithmetic evaluation.

Papers

Cross-domain bits and decompositions

Preprocess matching arithmetic and binary sharings of bits or integers, including daBits and edaBits used for conversion and numeric operations.

daBits

daBits link arithmetic and binary sharings of the same bit for mixed-domain computation.

Papers

edaBits

edaBits link an arithmetically shared integer with a binary sharing of its bit decomposition.

Papers

Multiplication correlations and triples

Generate scalar, matrix or packed multiplication correlations using OT, HE or sharing-based methods, and consume them for shared multiplication.

Multiplication triples from somewhat homomorphic encryption

A preparation method that uses an encryption scheme supporting a limited amount of encrypted arithmetic to create multiplication triples: shared random values whose third component is the product of the other two.

Why it is useful

Only one multiplication has to be done under encryption, so a somewhat homomorphic scheme is enough and no bootstrapping or fully homomorphic machinery is needed. Many values are packed into each ciphertext, which amortises the public-key cost.

How it works

  1. Each player encrypts their own random contributions to the two triple values and broadcasts the ciphertexts, with a proof that they know the encrypted content.
  2. The players add the ciphertexts homomorphically to get encryptions of the two random values, and multiply them to get an encryption of the product.
  3. A resharing step decrypts each encrypted value into fresh additive shares, and encrypted multiplications by the global key produce the tag shares.
  4. Packing many field elements into one ciphertext means one round of ciphertext operations yields many triples at once, which are buffered and handed out on demand.

What to watch for

The whole preparation phase is only computationally secure, and it assumes the decryption key was already shared among the players. Its cost is dominated by public-key operations, so the packing factor directly controls throughput.

Useful background: Offline and online phases with a replaceable dealer, Somewhat homomorphic encryption, Beaver triples.

Related ideas

Papers

Multiplication with Beaver triples

A rule for multiplying two shared values using a prepared random triple: a triple of shared values (a, b, c) with c = a · b, where a and b are random and unknown to everyone including the adversary.

Why it is useful

Additions and multiplications by public constants are free: every player just applies the operation to their own shares. A product of two secrets is not linear, and opening the raw product would leak information, so a random triple is spent to mask it.

How it works

  1. Prepare a list of correctly shared random triples in a preparation phase, before any input is known.
  2. For a gate with shared inputs x and y, take a fresh triple and open the differences x − a and y − b to everyone.
  3. Every player then computes the shared product locally as (x−a)(y−b) + (x−a)·b + (y−b)·a − c, which equals x · y because c = a · b.
  4. The opened differences reveal nothing about x and y, since a and b are uniformly random and unknown.

What to watch for

The triples must be correct before use: here the preparation phase produces them with an optimistic multiplication and then verifies them in large batches, rather than sacrificing triples one by one.

Useful background: Shamir secret sharing.

Related ideas

Papers

Packed Beaver triples

Packed Beaver triples extend multiplication correlations to packed secret shares.

Papers

Reshare: turning a ciphertext into fresh shares

A subprotocol that converts a public ciphertext into additive shares of the value it contains, optionally producing a new ciphertext that encrypts the same value with small noise.

Why it is useful

Homomorphic multiplication leaves a ciphertext with large noise that cannot be reused, and the players need shares rather than ciphertexts to continue. Reshare bridges the encrypted world and the shared world.

How it works

  1. Every player encrypts a fresh random masking value and broadcasts it, with a proof of plaintext knowledge.
  2. The players add all masking ciphertexts to the input ciphertext, obtaining an encryption of the value plus the combined mask.
  3. The players run distributed decryption on that ciphertext and learn the masked value in the clear.
  4. The first player sets their share to the decrypted value minus their own mask; every other player negates their own mask as their share.
  5. If a new ciphertext is wanted, the players encrypt the masked value again with default randomness, so the new ciphertext matches the shares that were just created.

What to watch for

Distributed decryption here is only secure against passive cheating, so a cheater can shift the decrypted value by a known amount. That is tolerated because any resulting wrong share is caught later by the authentication check.

Useful background: Multiplication triples from somewhat homomorphic encryption, Additive secret sharing.

Related ideas

Papers

Preprocessing validation and sacrifice

Check multiplication relations, authentication and cross-domain consistency before use, including sacrifice and alternatives that establish the same required relation.

LowGear 2.0

LowGear 2.0 changes triple generation to omit LowGear's sacrifice step.

Papers

Masked linear consistency checks

A linear consistency check combines many claimed relations into shorter field values. Random extra data masks the summary so that checking the relations does not disclose the protected inputs.

Why it is useful

A check must satisfy two goals: detect inconsistent data and avoid leaking the secret values it is meant to protect.

How it works

  1. Fix the data to be checked before receiving the challenge weights.
  2. Combine blocks using the challenge weights.
  3. Add an unused random masking block.
  4. Check the corresponding relation between the summaries.
  5. Discard the masking material rather than treating it as application output.

What to watch for

The exact relation, timing, masking and challenge distribution need a proof for the particular protocol. A random linear combination alone does not establish active security.

Related ideas

  • SoftSpokenOT: The paper describes a simplified instance with a masked summary and one check per column.

Papers

Sacrifice: validating one triple with another

A check that a multiplication triple really satisfies the multiplicative relation, performed by spending a second triple as a random test. A bad triple survives only with probability about one over the field size.

Why it is useful

The preparation phase lets a cheater inject an error into the relation, and using a bad triple would corrupt every later result. Sacrifice validates triples before they are consumed, at the price of burning some of them.

How it works

  1. Take the triple to be checked and a second triple that will be spent.
  2. Open a random challenge value, partially open the challenge times the first triple minus the second, and partially open a combined expression that cancels everything but the difference of the two relations.
  3. If the opened result is not zero, abort; otherwise keep the checked triple and discard the sacrificed one.
  4. To check many triples cheaply, interpolate all their components into polynomials, evaluate them at one random point of a field extension, and test the multiplicative relation there; then the number of triples burned per triple checked approaches one.

What to watch for

Sacrificing is wasteful by design, so batching matters: the polynomial method checks a large batch while burning only about as many triples as it validates, plus a polylogarithmic overhead. The error probability is governed by the size of the field used for the random evaluation point, not by the base field alone.

Useful background: Beaver triples, Authenticated shares with one global MAC key.

Related ideas

Papers

Verifying many triples with one random check

A batch test for multiplication triples: lay the N triples out as three lists, interpolate them into low-degree polynomials f, g and h over a large extension field, and check h = f · g at one randomly chosen point.

Why it is useful

Verifying one triple at a time over the small field fails with probability 1/|F|, which is far too large, and doing it over the big field costs about n κ bits per multiplication gate, which would destroy the near-linear target. The batch test verifies N triples for essentially the cost of one check, with an error probability of about 2N/|K| controlled by the big field.

How it works

  1. Write the a-lists and b-lists of N triples as evaluations of degree N − 1 polynomials f and g, and the c-list as a degree 2N − 2 polynomial h.
  2. Extend all three lists to 2N − 1 points by local computation, and compute the extra products optimistically, assuming players behaved.
  3. Generate one random challenge σ in the extension field; every player forms their share of f(σ), g(σ) and h(σ) as a linear combination of shares they already hold.
  4. Run one ordinary multiplication verification on f(σ) · g(σ) = h(σ). By the fundamental theorem of algebra, if any triple is wrong then f · g and h differ as polynomials, so they agree at σ with probability at most (2N − 1)/|K|.

What to watch for

The check is probabilistic, its error depends on the extension field rather than the small field, and the idea is imported from low-degree tests that appear in PCP constructions; an independent two-party batch zero-knowledge proof of committed triples appeared at the same time.

Useful background: Multiplication with Beaver triples.

Related ideas

Papers

Zero-knowledge proof of plaintext knowledge

A proof in which a player who broadcast a ciphertext convinces the others that they know a small plaintext and small encryption randomness inside it, without revealing either.

Why it is useful

Every ciphertext used in the preparation phase must decrypt correctly later. This proof forces cheaters to stay inside the size bounds that the decryption procedure can handle, while honest encryptions stay secret.

How it works

  1. The prover commits to a batch of masked ciphertexts built from random plaintexts and randomness in the allowed ranges.
  2. A random challenge string is produced by a public coin-flipping functionality.
  3. The prover answers with combinations of the committed values and the true ciphertexts, scaled by the challenge.
  4. The verifier re-encrypts the answer and checks it against the committed ciphertexts, and checks the size bounds directly.
  5. A prover who answers two different challenges consistently can be solved for the plaintext and randomness, which is why knowledge is extracted by rewinding in the reduction.

What to watch for

The proof is honest-verifier zero-knowledge and is made straight-line by taking the challenge from a public randomness functionality rather than from the verifier. Soundness is only statistical, with error controlled by a parameter, and repeating the proof lowers the error at a matching cost in time.

Useful background: Somewhat homomorphic encryption, Zero-knowledge proofs.

Related ideas

Papers

Private two-party functions and correlation resources

OT, affine correlations, distributed function evaluation and keyed oblivious evaluation used as secure-computation components. A functionality, its sampled correlations and its generator are distinct objects.

Function secret sharing

Distribute a function into locally evaluated function keys whose outputs combine, covering point, interval and richer function classes. This differs from sharing data for homomorphic evaluation.

Function secret sharing

Function secret sharing splits a function into locally evaluated shares whose outputs combine.

Papers

Pika

Pika uses function secret sharing for computation over rings.

Papers

Distributed point functions

Compact shares of functions supported at one input, including programmable and reusable offline material; applications do not imply identical key-reuse guarantees.

Distributed point functions

Distributed point functions share a function that is zero except at one input.

Papers

Programmable distributed point functions

Programmable DPFs reuse an input-independent offline key when sharing multiple point functions.

Papers

Oblivious and verifiable PRF evaluation

Evaluate a server-keyed PRF on a hidden client input, with optional proofs of key-consistent evaluation. Threshold key ownership is a separate extension.

Oblivious pseudorandom functions

An oblivious pseudorandom-function protocol evaluates a function using one party's secret key and another party's private input. The input holder learns the function value, while the key holder should not learn that input.

Why it is useful

It gives a client a comparable secret-key tag for a record without disclosing the record to the server.

How it works

  1. The server holds the function key.
  2. The client supplies an input through the oblivious evaluation protocol.
  3. The client obtains the keyed output without obtaining the key.
  4. For set intersection, compare client outputs against the server's tags for its own set.

What to watch for

An evaluation protocol needs a stated adversary model and query policy. Ordinary oblivious evaluation does not automatically prove that every response uses one consistent public key; verifiable variants add such a requirement.

Useful background: Pseudorandom functions.

Related ideas

Papers

Verifiable oblivious pseudorandom functions

A VOPRF adds a proof linking an oblivious function evaluation to a public verification key.

Papers

Oblivious linear evaluation and vector correlations

OLE and VOLE affine-evaluation functions and correlations over fields or rings, including vector-scalar and small-field forms.

FOLEAGE

FOLEAGE evaluates Boolean circuits using OLE over the field with four elements.

Papers

Oblivious linear evaluation

OLE evaluates a sender-defined affine function on a receiver input.

Papers

Oblivious transfer and extension

Oblivious transfer lets a receiver obtain one selected message while hiding its choice and leaving the other message hidden. OT extension makes large batches affordable by expanding a smaller set of base transfers.

Correlated oblivious transfer

In correlated OT, the sender's two possible messages have a specified relationship, such as differing by one common secret XOR offset. The receiver learns the message selected by its private bit.

Why it is useful

Many secure-computation protocols need structured random values rather than arbitrary messages. Keeping the correlation can save work.

How it works

  1. Specify the relation between the two sender outputs.
  2. Generate matching sender and receiver shares of the transfer.
  3. Let the receiver obtain the output selected by its bit while keeping the other branch hidden.

What to watch for

A construction producing correlated values with adversarial errors is not yet the same as a secure correlated-OT functionality. The errors must be handled by the surrounding protocol.

Related ideas

Papers

Oblivious transfer

In oblivious transfer, a sender holds several values and a receiver chooses which permitted values to obtain. The sender should not learn the receiver's choice, and the receiver should not learn the unchosen values.

Why it is useful

It provides private selection with protection for both sides, making it a useful building block for secure computation.

How it works

  1. The sender supplies the possible values.
  2. The receiver supplies a private choice.
  3. The protocol delivers only the allowed selection while hiding that choice from the sender.

What to watch for

The security model matters. A protocol secure when the receiver follows its instructions need not remain secure when the receiver sends a deliberately malformed query.

Related ideas

  • Private information retrieval: Protects the requested index, but does not by itself impose the same limit on information learned by the receiver.

Papers

One-out-of-two oblivious transfer

In one-out-of-two oblivious transfer, a sender has two messages and a receiver chooses one. The receiver learns the chosen message, while the sender does not learn which one was selected and the receiver does not learn the other.

Why it is useful

It supplies a private choice operation used inside secure computation and private set intersection protocols.

How it works

  1. The sender supplies two messages.
  2. The receiver supplies a secret choice bit.
  3. Run the transfer protocol.
  4. The receiver obtains only the message selected by that bit.

Example

The sender holds messages A and B. A choice bit of one delivers B without revealing that choice to the sender.

What to watch for

These are privacy guarantees, not a promise that a malicious participant cannot abort. The protocol must state whether it protects against passive observers or participants who deviate from its steps.

Papers

Oblivious transfer from commitments and obfuscation

In this semi-honest construction, the receiver commits to a choice bit. The sender returns an obfuscated program that reveals a message only when given a valid opening of that commitment.

Why it is useful

Commitment hiding conceals the choice from the sender, while binding restricts which message the receiver can obtain through the program.

How it works

  1. The receiver commits to its choice with fresh randomness.
  2. The sender creates a program containing the commitment and both messages.
  3. The program checks an opening and releases the corresponding message only when it is valid.
  4. The receiver runs the obfuscated program with its known opening.

What to watch for

The sketch proves security for parties following the protocol while inspecting their views. Malicious security needs the additional transformation cited by the paper; it is not supplied merely by the opening check.

Related ideas

Papers

Random oblivious transfer

Random OT supplies random sender messages rather than messages chosen by the sender. The receiver learns the random message selected by its choice bit.

Why it is useful

Random transfer material can be generated before application messages are known, then used to protect those messages later.

How it works

  1. Generate two random outputs for each sender transfer.
  2. Give the receiver only its selected output.
  3. Keep the outputs secret until they are consumed by the application or converted into a chosen-message transfer.

What to watch for

Random OT is not simply an arbitrary pair of hashes. Its security definition still requires receiver-choice privacy and hiding the unchosen output.

Related ideas

Papers

Converting random OT to chosen-message OT

Random OT outputs can act as pads for the sender's actual messages. The sender sends two masked messages, and the receiver can remove only the mask it obtained through OT.

Why it is useful

This separates expensive transfer preparation from the point at which the sender knows the application messages.

How it works

  1. Obtain two random pads at the sender and one selected pad at the receiver.
  2. XOR each sender message with its corresponding pad.
  3. Send both masked messages.
  4. The receiver removes its known pad to recover the selected message.

What to watch for

The pads must have the required length, remain secret and not be reused for different messages. This conversion inherits the security of the random OT underneath it.

Papers

Two-message oblivious transfer from projective hashing

A sender holds two strings and a receiver holds a choice bit; at the end the receiver must learn only its chosen string and the sender must learn nothing about the choice. The protocol needs one message in each direction.

Why it is useful

Oblivious transfer is a bottleneck primitive for secure multiparty computation, and cutting the interaction to two messages removes an entire round of dependency between the parties.

How it works

  1. The receiver generates the hashing parameters, samples a member with its witness and a non-member, places the member in the position of its choice bit, and sends the parameters plus both elements.
  2. The sender hashes each element under a fresh key pair and masks each string with the corresponding hash value, then returns the two projective keys and the two masked strings.
  3. The receiver recomputes only the chosen hash value from the projective key and its witness, and removes the mask from the chosen string.

Example

The hash value acts as a one-time pad key: the sender hides each string by combining it with a hash value, and only the chosen hash value can be recomputed by the receiver.

What to watch for

Receiver privacy comes from the hardness of telling a member from a non-member, so swapping the two elements is indistinguishable. Sender privacy comes from smoothness: on the non-member, the mask is statistically close to random. As stated here the protocol tolerates only an honest-but-curious receiver; the next lessons add the missing pieces.

Useful background: Smooth projective hashing: two keys and six algorithms, Smoothness versus projection.

Papers

What secure oblivious transfer means here

Security is defined by indistinguishability, not by simulation: the two possible first messages of an honest receiver must be computationally indistinguishable, and the sender’s reply must statistically hide one of the two strings for every first message, even a malicious one.

Why it is useful

The distinction matters when the protocol is used inside something bigger. An indistinguishability-based guarantee does not compose the way a simulation-based one does, which makes it harder to use as a building block in general secure computation.

How it works

  1. Against a corrupted sender, a simulator can still work: it plays the receiver with one choice bit, resets the sender, and plays the other bit to extract both strings.
  2. Against a corrupted receiver, no efficient simulation is promised, because a malicious receiver may not know its own choice bit, so the simulator cannot tell the trusted party which string to hand over.
  3. What is guaranteed instead is an exponential-time simulation of the receiver’s view: the interaction gives no more than an unbounded receiver could derive from the chosen string alone.

What to watch for

For a standalone transfer this notion is meaningful and sufficient for some uses; for composable multiparty computation the weaker guarantee must be weighed carefully.

Useful background: Two-message oblivious transfer from projective hashing.

Papers

Why the sender hashes with two independent keys

The sender draws two independent key pairs, one for each element, instead of reusing a single pair for both hash values.

Why it is useful

With one shared key pair, the two masked strings could be linked. Nothing in the definitions rules out that each hash value separately reveals information about the key when the family happens to be smooth on both elements, and then the reply would leak a relation between the two secrets.

How it works

  1. Draw key pair zero and hash the first element; draw an independent key pair one and hash the second element.
  2. The security proof can then replace either masked string by a random-looking one without disturbing the other.
  3. A cheating receiver who makes both elements smooth still gains nothing, because the two keys are unrelated.

What to watch for

The price is doubled key material and roughly doubled work for the sender compared with a naive single-key design.

Useful background: Two-message oblivious transfer from projective hashing.

Papers

OT extension

Expanding a smaller set of base transfers into many transfers, with protocol-specific security conditions.

IKNP OT extension

IKNP uses pseudorandom seed expansions arranged as a bit matrix to extend base OTs. Matrix columns come from the base transfers; rows become the correlated material for many new transfers.

Why it is useful

The construction replaces most of the public-key work with pseudorandom generation, XORs, matrix transposition and hashing.

How it works

  1. The future extended-OT receiver provides pairs of seeds in the base OTs.
  2. The future sender privately selects one seed from each pair.
  3. Expand the seeds into matrix columns and exchange correction vectors.
  4. Transpose the matrices to obtain one row per extended transfer.
  5. Process the correlated rows as required by the desired OT variant.

What to watch for

The basic passive construction assumes the participants follow the protocol. A malicious receiver can use inconsistent choice vectors unless a suitable active-security mechanism prevents it.

Related ideas

Papers

KOS OT extension

The Keller-Orsini-Scholl extension adds a consistency check to IKNP-style correlated transfers before hashing them into random OTs. The original check combines many transfer relations using random field weights.

Why it is useful

The goal is to detect maliciously inconsistent choices with much less overhead than repeatedly running and inspecting whole extensions.

How it works

  1. Generate the correlated transfer material.
  2. Compute and exchange a check on the claimed correlations.
  3. Abort if the check fails.
  4. For the outputs retained by the protocol, hash the correlated material with the transfer index.

What to watch for

The paper's 2022 update states that the original proof lemma is false and that the original protocol is not as secure as claimed. Section 4 gives a replacement check based on SoftSpokenOT; the original check and the repaired variant must not be treated as interchangeable.

Related ideas

  • SoftSpokenOT: Supplies the replacement consistency-check approach described in the update.

Papers

Oblivious transfer extension

OT extension turns a small set of base oblivious transfers into a much larger set using cheaper symmetric operations. The base transfers establish correlations that the extension expands and processes.

Why it is useful

Secure computations may need millions of private transfers. Paying a public-key cost for every transfer would often be too expensive.

How it works

  1. Execute the required base OTs.
  2. Expand the resulting secret seeds with pseudorandom generators.
  3. Exchange the protocol's correction data.
  4. Check consistency if active security is required.
  5. Produce the extended transfer outputs.

What to watch for

Extension does not remove the need for secure base OTs. Its assumptions, corruption model and permitted reuse of seeds must match the full protocol.

Related ideas

Papers

SoftSpokenOT

SoftSpokenOT builds transfer correlations through a more general linear-correlation tool called subspace VOLE, then converts them into random OT by hashing. The updated KOS paper explains a simplified one-out-of-two instance.

Why it is useful

The construction supplies a consistency-check approach that addresses the earlier KOS proof problem, while the full design also explores communication savings.

How it works

  1. Expand base-transfer seeds into correlated columns.
  2. Check each column against a shared, masked summary of the receiver's choices.
  3. Transpose the checked columns into transfer rows.
  4. Hash each row with its transfer index to form the sender and receiver outputs.

What to watch for

The simplified instance omits optimizations from the full SoftSpokenOT construction. Its parameters and checks are specific to the given protocol, not a generic replacement for every OT-extension check.

Related ideas

Papers

Transfer-index domain separation

An OT extension can include the transfer index in the hash input used to derive each output. This distinguishes different transfer positions even when their underlying correlated values are related.

Why it is useful

Hashing only the row value can leave unintended relationships between outputs from different transfers. The updated paper explicitly warns that the index is security-critical.

How it works

  1. Encode the transfer position unambiguously.
  2. Combine it with the correlated row value.
  3. Apply the specified hash construction to this indexed input.

What to watch for

Adding an index does not repair an unrelated consistency-check problem. The hash must also meet the protocol's correlation-related security requirements.

Related ideas

Papers

Silent OT and correlation generation

Communication-efficient transfer/correlation generation from compact setup.

Silver OT/VOLE

Silver uses structured LDPC codes in silent OT and vector-OLE generation.

Papers

Pseudorandom correlation generation

Expand short correlated seeds into large structured correlations, including silent preprocessing. Setup costs and distributional security are separate from online expansion.

Pseudorandom correlation generators

PCGs locally expand correlated short seeds into longer correlated randomness.

Papers

Silent OT extension

Silent OT extension uses correlation generators to expand transfer correlations after seed setup.

Papers

Protocol compilation and security amplification

Protocol transformations for malicious security or hidden functions, including cut-and-choose, authentication, proof-assisted input checks and universal circuits. MPC-in-the-head belongs to proofs rather than online MPC.

Dispute control: paying only when someone cheats

A way to run a protocol against malicious players without paying for full verification everywhere: split the work into segments, and when a segment fails, single out two players who are in dispute, at least one of whom is corrupt, and re-run the segment so those two never interact again.

Why it is useful

It converts active misbehaviour into a bounded amount of repetition. Since two honest players never get into a dispute, there can be at most n squared disputes, so a segment is executed at most twice on average over the whole run, and the asymptotic cost is preserved.

How it works

  1. Divide each phase of the protocol into n2 segments of equal size and execute them one after another.
  2. When a segment fails, identify a pair of players in dispute; re-execute the segment with that pair forbidden from talking to each other.
  3. Silence between players in dispute is enforced by Kudzu shares, shares that a dealer constructs to be zero for the player he is in dispute with, so nothing needs to be sent.
  4. Any other message between them travels through a relay: a player who is in dispute with neither of them.
  5. Track the dispute set and the set of players caught corrupt; players in dispute keep participating, caught players are excluded.

What to watch for

Dispute control means work is repeated after failures, so the worst-case total running time grows with the number of detected disputes, and the bookkeeping of disputes, corruptions and relays makes the full protocol long and case-heavy - the authors themselves advise skipping the fault-localization subprotocols on a first reading.

Useful background: The dishonest-minority corruption model.

Related ideas

Papers

DUPLO

DUPLO combines cut-and-choose techniques for checking garbled circuits.

Papers

Secure operators and value representations

Reusable protocols for conversion, numerical operations and data-oblivious control on private values. Operator semantics must specify range, precision and observable failures.

Comparison, truncation and numerical evaluation

Secure comparison, equality, bit decomposition, truncation, division and fixed- or floating-point approximations, including rounding error and wraparound analysis.

Selection, sorting and data-oblivious control

Conditional selection, secure sorting, permutation, joins and memory primitives that hide data-dependent control flow. Stateful ORAM and garbled RAM have linked topics.

MOTIF

MOTIF uses vector-scalar multiplication to implement conditional branches in GMW computation.

Papers

Sharing and representation conversion

Convert fields, rings, bit decompositions or garbled labels while preserving represented values, authentication and agreed interpretation.

Sharing transformation

Sharing transformation converts linear sharings and applies linear maps to packed secrets.

Papers

MPC-friendly symmetric primitives

MPC-friendly primitives are block ciphers and pseudorandom functions redesigned so that a multiparty computation can evaluate them on secret-shared data at low cost. In secret-sharing MPC, adding two shared values is free while multiplying them costs preprocessed data and a round of communication, so the designer counts secure multiplications and rounds instead of CPU cycles. Conventional designs such as AES work on bytes and bit-level tables that map badly onto prime-field arithmetic, and even ciphers built for low multiplicative depth over bits pay for a conversion between field elements and shared bits. This paper studies three replacements - the Naor-Reingold PRF, a PRF from the Legendre symbol, and the MiMC block cipher - and shows that each wins on a different measure, so no single primitive is optimal everywhere.

Choosing among the MPC-friendly PRFs

No candidate wins on every measure: latency, throughput, preprocessing cost, and cleartext speed rank the PRFs differently, so the application picks the winner.

Why it is useful

It closes the design loop: the criteria fixed at the start - shared or public input and output, external parties or not - are exactly what separates the recommendations.

How it works

  1. Latency is the wait for one evaluation; throughput comes from batching many evaluations to cut the number of round trips, and the two trade off.
  2. The Legendre PRF has the lowest latency and the highest throughput for bit outputs, so it suits short-output applications with no party outside the engine.
  3. MiMC gives the best throughput for full field-element outputs and the cheapest preprocessing, plus usable cleartext speed.
  4. Naor-Reingold has low latency but poor throughput; LowMC and AES serve only as baselines because of the field mismatch.

Example

Table 1 of the paper lists online cost as multiplications and rounds: two multiplications in three rounds for the bit Legendre PRF against 146 in 73 for MiMC.

What to watch for

The recommendations come from the paper's LAN and WAN benchmarks on two parties, and the cheapest preprocessing still has to be produced offline.

Useful background: The Legendre symbol PRF, MiMC: cubing over a prime field, Naor-Reingold PRF with public output.

Papers

Naor-Reingold PRF with public output

A number-theoretic PRF whose value is a hash of a group element built from a shared key; naive evaluation needs exponentiation with a secret exponent, but revealing the output makes that exponentiation almost free.

Why it is useful

It shows how the public-versus-shared output choice from the design criteria changes a protocol: one extra assumption about who sees the result removes the dominant cost.

How it works

  1. Share the exponent additively, so each party broadcasts the group element for its own share; multiplying the broadcasts gives the element for the secret exponent.
  2. For active security, also exponentiate a random multiple of the secret and check the two results against each other, which acts as a one-time MAC on the exponent.
  3. Cheating then requires guessing an unknown random value, which succeeds with probability about 1/p.
  4. The inner product of key and message bits is computed as a multiplication tree, taking a logarithmic number of rounds.

Example

Security rests on the decisional Diffie-Hellman assumption in the group, unlike the purely symmetric candidates.

What to watch for

The construction needs a 256-bit prime field for 128-bit security while the other candidates use 128-bit fields, inputs must be bit-decomposed, and elliptic-curve work made up over seventy percent of its runtime.

Useful background: What makes a primitive MPC-friendly.

Papers

The arithmetic black box cost model

An idealised machine in which parties hold secret-shared field elements and can add, multiply, and draw random values; additions are free while each multiplication costs preprocessed data and one communication round.

Why it is useful

Every claim of "MPC-friendly" is measured against this model, so the design target becomes: few secure multiplications, and few rounds of interaction.

How it works

  1. Secrets live as shares over a prime field; addition of shares is local and free.
  2. A multiplication consumes a preprocessed triple and sends two field elements in one round; a squaring sends one element.
  3. Random squares and random bits are available as preprocessing, which some protocols exploit.
  4. Concretely the paper implements the model with SPDZ, splitting work into an input-independent offline phase and a fast online phase.

Example

Costs are counted per operation, not per second, so the model transfers to any secret-sharing protocol, not just SPDZ.

What to watch for

Rounds and multiplications pull in different directions: fewer multiplications usually means deeper, longer-dependent computation, and preprocessing has its own price.

Papers

The Legendre symbol PRF

A PRF defined by the Legendre symbol of the sum of key and message: one bit saying whether a field element is a square, which in MPC costs about two secure multiplications and three rounds.

Why it is useful

The Legendre symbol is multiplicative, so a random square can be multiplied into a shared value to mask it without changing the symbol, and that trick is what makes evaluation cheap.

How it works

  1. For a public output, multiply the shared value by a preprocessed random square and open the product; its Legendre symbol equals the original one.
  2. For a shared output, also prepare a random value that is a square or non-square chosen by a shared random bit, using a public non-residue to build the non-square case.
  3. Open the product of the target and that random value, then correct the public symbol with the shared random bit; no Legendre symbol is ever computed inside MPC.
  4. Run instances in parallel with independent keys to get a full field element of output.

Example

The paper calls it the only PRF it knows of that can be evaluated in a constant number of rounds on secret-shared data with any arithmetic MPC protocol.

What to watch for

One evaluation gives a single bit; a field-element output needs about 128 parallel instances, whose preprocessing is expensive, and evaluation on cleartext data is slow.

Useful background: The arithmetic black box cost model.

Papers

The shifted Legendre symbol problem

The assumption behind the Legendre PRF: given an oracle that reports the Legendre symbol of a hidden shift plus any chosen input, no efficient algorithm recovers the shift, and its outputs cannot be distinguished from random.

Why it is useful

The extremely cheap protocol is paid for with an assumption far less studied than discrete logarithms or factoring, so the paper surveys what is actually known about it.

How it works

  1. Recovering the shift naively costs about p squared operations, and the best known classical attack, using bounds on exponential sums, still costs about p.
  2. A quantum algorithm recovers the shift efficiently, but only if the oracle may be queried in superposition.
  3. Whether a quantum algorithm exists with classical queries only is an open question, unlike discrete log and factoring.
  4. Generalisations where the oracle returns other powers of the shifted input have known attacks, but those attacks do not apply to the Legendre case.
  5. PRF security follows from the decisional version of the problem, which currently has no attack that avoids recovering the key.

What to watch for

This is an assumption survey, not a proof of security; confidence is lower than for standard number-theoretic assumptions.

Useful background: The Legendre symbol PRF.

Papers

What makes a primitive MPC-friendly

A symmetric key primitive that the MPC engine can evaluate directly on secret-shared data, so that shared data can be encrypted, decrypted, or pseudorandomly expanded inside the computation instead of around it.

Why it is useful

Storing or importing data the trivial way costs each of the N servers a public-key encryption per share, or an N-fold blowup in storage; a PRF the engine can run itself removes that overhead.

How it works

  1. Decide whether the input is public or itself secret-shared, since shared input forces the input field to match the engine field.
  2. Decide whether the output must stay shared for further processing or may be revealed.
  3. Decide whether the primitive must also be fast on cleartext data, which matters when an external party encrypts data for the engine to decrypt.
  4. Because these cases conflict, no single PRF is optimal across applications.

Example

Higher-level goals such as searchable or order-revealing encryption reduce to a good PRF, so the PRF is the blocking piece.

What to watch for

The label describes a cost profile, not a security level; an MPC-friendly primitive still needs its own cryptanalysis.

Useful background: Why AES is an awkward benchmark in MPC.

Papers

Why AES is an awkward benchmark in MPC

AES became the standard yardstick for MPC speed, yet its structure fights the way secret-sharing MPC does arithmetic, so evaluating it costs far more secure operations than a primitive designed for the setting.

Why it is useful

MPC engines represent secrets as elements of a large prime field and charge for multiplications; AES is built from byte tables and XOR, which do not map onto that arithmetic, so the benchmark measures the wrong thing.

How it works

  1. A byte-oriented cipher must be simulated with field operations, turning cheap CPU steps into expensive secure multiplications.
  2. Benchmark implementations run SPDZ over the AES field embedded in a larger field, so the engine must convert data between that field and its own prime field.
  3. The paper reports 960 secure multiplications in 50 rounds for AES in its Table 1, against 146 multiplications in 73 rounds for MiMC.
  4. The field conversion is expected to cost more than the PRF evaluation itself.

Example

The paper's AES benchmark runs an MPC system defined over the AES field rather than over a prime field, which is exactly the mismatch the new designs remove.

What to watch for

Numbers come from the paper's two-party SPDZ setup and are comparison figures, not a claim that AES is weak as a cipher.

Related ideas

  • AES: the benchmark being questioned

Papers

Why bit-oriented ciphers still miss the target

Lightweight, SHE-friendly, and LowMC-style ciphers cut gate count or multiplicative depth over bits, but an engine working over a prime field must first convert shared field elements into shared bits, and that conversion dominates the runtime.

Why it is useful

It explains why "fewer bit multiplications" is not the same as "cheap in MPC": the expensive step is the representation change, not the cipher.

How it works

  1. LowMC has low multiplicative depth but operates in characteristic two, so like AES it does not fit a prime-field engine.
  2. Applying such a cipher means splitting field data into a shared bit representation, which the paper calls expensive.
  3. SNARK-friendly design optimises constraint count instead, favouring large data types and ignoring circuit depth - MiMC came from that line of work.
  4. The result is three different cost measures - gate count, multiplicative depth, and secure field multiplications - that do not rank designs the same way.

What to watch for

The paper keeps LowMC and AES only as baselines; their raw benchmark numbers can look good while the surrounding conversion cost makes them unsuitable.

Useful background: The arithmetic black box cost model.

Papers

Computing on encrypted data

Homomorphic encryption lets a server perform certain calculations on ciphertexts. After decryption, the result corresponds to a calculation on the original data.

Ciphertext and plaintext representations

Represent messages, ciphertexts and evaluation keys using polynomial, matrix, integer or residue structures; organize transformations without duplicating the mathematics branch.

External product for GSW-LWE ciphertexts

The external product combines a GSW ciphertext with an LWE ciphertext in homomorphic evaluation.

Papers

GSW

GSW expresses homomorphic computation through an approximate-eigenvector matrix representation.

Papers

Encoding, packing and slot transforms

Map plaintext values into coefficients or SIMD slots, including rational encodings, canonical embeddings, batching, rotations and slot-to-coefficient linear transforms.

Canonical-embedding packing

Canonical-embedding packing maps plaintext polynomials to vectors of complex numbers.

Papers

Centered modular remainders

A centered remainder chooses the representative closest to zero instead of the usual representative between zero and the modulus. This distinction matters when a decryption rule reads the remainder's parity.

Why it is useful

Changing a representative by an odd modulus flips its parity, so ordinary programming-language remainder operations cannot be substituted blindly.

How it works

  1. Divide by the modulus and round the quotient to the nearest integer using a specified tie convention.
  2. Subtract that integer multiple of the modulus.
  3. Obtain the small signed remainder.
  4. Apply the plaintext decoding rule to that representative.

Example

With p=23 and c=22, the centered remainder is -1, whose parity is 1. The nonnegative remainder is 22, whose parity is 0. These yield different decrypted bits.

What to watch for

The retained paper uses the interval (-p/2, p/2]. Other representations can be valid only with the corresponding decoding adjustment. This convention is separate from the plaintext being reduced modulo two.

Papers

PIE encoding

PIE uses p-adic techniques to encode rational numbers for homomorphic arithmetic.

Papers

Scaling for approximate homomorphic encryption

Scaling multiplies a numerical input by a known factor before rounding it to the integer representation used by encryption. Decoding divides by the appropriate scale to recover an approximation.

Why it is useful

Without scaling, small encoding and encryption errors could overwhelm the meaningful digits of a fractional input.

How it works

  1. Choose a scale large enough for the required precision.
  2. Multiply by that scale and encode into the permitted integer polynomial.
  3. Track how additions, multiplications and rescaling change the scale.
  4. Use the final scale when decoding.

Example

As an unencrypted illustration, scale 1.23 by 100 to represent it as 123. Multiplying two such representations gives scale 10,000, not 100.

What to watch for

A larger scale consumes more numerical range. Adding ciphertexts with incompatible scales does not automatically add the intended numbers.

Papers

Slot permutations by ring automorphisms

Certain substitutions in a plaintext polynomial permute the values stored in its slots. Applying the same substitution to ciphertext components performs that transformation on encrypted data.

Why it is useful

Packed computations need ways to move values between positions, for example when combining entries of a vector.

How it works

  1. Choose a permitted substitution that sends the needed slot to its destination.
  2. Apply the ring automorphism to every ciphertext component.
  3. Recognize that the resulting ciphertext uses a transformed secret.
  4. Key-switch back to the original secret using the required evaluation material.

What to watch for

A single automorphism implements a structured permutation, not every arbitrary rearrangement. The conversion requires evaluation keys and adds computational cost and error.

Related ideas

Papers

Key, scheme and parameter switching

Convert ciphertexts across keys, dimensions or encryption representations, including relinearization, field or ring switching, scheme switching and amortized key-switch operations.

Key switching for HE

Key switching changes the secret-key representation under which a ciphertext can be decrypted while preserving its intended plaintext. Evaluation-key material makes the conversion possible without giving the evaluator the decryption key.

Why it is useful

Some homomorphic transformations naturally produce ciphertexts associated with a changed secret, even though later computation should use the original secret.

How it works

  1. Identify the secret representation required by the transformed ciphertext.
  2. Apply the conversion material specified by the scheme.
  3. Obtain a ciphertext under the target representation.
  4. Include switching error and key-generation assumptions in the analysis.

What to watch for

The details depend on the encryption scheme and published evaluation keys. This does not permit conversion to an arbitrary unrelated recipient without the necessary key material.

Papers

PEGASUS HE

PEGASUS converts between packed CKKS ciphertexts and FHEW ciphertexts.

Papers

Relinearization for HE

Multiplying two ciphertexts can produce a decryption expression containing the square of the secret key. Relinearization uses evaluation-key material to turn that larger representation back into the usual ciphertext form.

Why it is useful

Without a size-control step, repeated multiplication would increase the number of secret-key powers represented by a ciphertext.

How it works

  1. Multiply the ciphertext components to obtain coefficients for the constant, secret and squared-secret terms.
  2. Use the evaluation key to replace the squared-secret contribution.
  3. Combine the result into the regular ciphertext representation.
  4. Account for the extra switching and rounding error.

What to watch for

Relinearization does not perform the same job as rescaling. Publishing evaluation keys related to the secret also needs a security argument; correctness algebra alone does not supply one.

Related ideas

  • CKKS rescaling: Manages magnitude and scale rather than the number of secret-key powers.

Papers

Noise, scale and precision management

Track ciphertext noise and message scale using parameter selection, modulus switching, rescaling and deliberate noise addition. Noise flooding has privacy roles beyond correctness budgets.

Error tracking in approximate encrypted arithmetic

An encrypted numerical calculation carries both a bound on the represented values and a bound on their error. Operations update these bounds so the final approximation has a meaningful accuracy claim.

Why it is useful

Successful decryption alone does not show that the numerical answer is useful.

How it works

  1. Track encoding error and encryption noise.
  2. For addition, add the relevant absolute error bounds.
  3. For multiplication, include message-times-error terms, the product of errors and evaluation overhead.
  4. Include rescaling error and check the remaining modulus range.

What to watch for

The paper normalizes error by a declared magnitude bound, which need not equal the actual result. A small normalized bound does not imply small relative error when cancellation produces a value near zero. Its concrete noise estimates also use heuristics.

Papers

Noise flooding

Noise flooding adds a much wider independent noise distribution so that smaller differences in existing ciphertext noise become hard to distinguish.

Why it is useful

It can help hide information about a homomorphic computation that the original noise would reveal to the decryptor.

How it works

  1. Bound the noise or shift that needs to be hidden.
  2. Choose a larger masking-noise distribution whose shifts are statistically close.
  3. Retain enough modulus space for correct decryption after adding that noise.
  4. Randomize other revealing ciphertext components too, if the privacy argument requires it.

What to watch for

Adding arbitrary noise is not sufficient: the distribution, ratio of magnitudes and remaining correctness margin matter. The integer paper also randomizes the quotient and assumes bounded ciphertext size and an honest public key.

Related ideas

Papers

Modulus switching and rescaling

Changing modulus or scale during encrypted computation, with scheme-specific error behavior.

Modulus reduction without rescaling

A ciphertext can sometimes be reduced to a smaller modulus while preserving its encoded plaintext and scale. This differs from rescaling, which deliberately divides the represented message.

Why it is useful

Ciphertexts at different levels need compatible representations before they can participate in one arithmetic operation.

How it works

  1. Identify the target modulus supported by both ciphertexts.
  2. Check that the message and error still fit the smaller modulus.
  3. Reduce coefficients modulo the target without dividing the encoded value.
  4. Align scales separately when the operation requires it.

What to watch for

Reducing the modulus too far can destroy correctness through wraparound. Matching modulus levels alone does not establish matching scales.

Related ideas

Papers

Modulus switching for HE

Modulus switching changes a ciphertext modulus during homomorphic computation.

Papers

Ciphertext refresh and functional bootstrapping

Refresh ciphertexts by encrypted decryption, including packed arithmetic refresh, blind rotation, programmable lookup evaluation and circuit bootstrapping. Functional bootstrapping is distinct from functional encryption.

Blind rotation

Blind rotation uses encrypted inputs to rotate a polynomial encoding a lookup table.

Papers

Bootstrapping

Bootstrapping evaluates a decryption procedure homomorphically, using an encrypted secret key, to turn a noisy ciphertext into another encryption of the same message with a renewed computation budget.

Why it is useful

It allows a scheme with a limited evaluation budget to support longer computations.

How it works

  1. Express decryption as a circuit.
  2. Provide the required secret-key bits in encrypted form under the appropriate next key.
  3. Evaluate decryption on the old ciphertext without revealing those bits or the plaintext.
  4. Ensure the refreshed result leaves room for further operations.

What to watch for

The scheme must support enough computation for its own decryption plus the required next gate. Publishing encrypted secret keys introduces a key-dependency question; the paper distinguishes a depth-bounded key chain from a construction relying on circular security.

Useful background: Homomorphic evaluation of encrypted data, Circular security for encrypted secret keys.

Papers

Circuit bootstrapping

Circuit bootstrapping converts LWE ciphertexts to ring-GSW ciphertexts for subsequent evaluation.

Papers

PaCo

PaCo bootstraps CKKS using partial coefficient-to-slot conversion and blind rotations.

Papers

Programmable bootstrapping

Programmable bootstrapping evaluates an encoded function while refreshing a ciphertext.

Papers

Squashing a decryption circuit

Squashing replaces an expensive decryption computation with a shallower one by publishing carefully structured helper data related to the secret key.

Why it is useful

The original integer decryption circuit is too demanding for the base scheme's own evaluation budget. A cheaper equivalent computation can make bootstrapping possible.

How it works

  1. Publish rational helper values with a hidden sparse subset whose sum approximates the reciprocal of the secret modulus.
  2. Use that subset's indicator bits as the modified secret key.
  3. Preprocess a ciphertext against the public helper values.
  4. Decrypt through a low-degree computation on the secret indicator bits, with explicit rounding margins.

What to watch for

Publishing helper data changes the security problem. Squashing is not bootstrapping itself and does not follow for free from approximate-GCD hardness; the paper introduces an additional sparse-subset assumption.

Useful background: Bootstrapping.

Related ideas

Papers

Sparse subset-sum decryption hints

A sparse decryption hint publishes many values while hiding a small subset with a useful sum. In this integer construction, that sum approximates the reciprocal of the secret modulus.

Why it is useful

The public values let the evaluator do most preprocessing, leaving only a sparse selection and summation for the encrypted decryption circuit.

How it works

  1. Choose a secret indicator vector with a specified small Hamming weight.
  2. Sample public helper values subject to the required subset-sum relation.
  3. Keep the subset hidden while using the public values to preprocess ciphertexts.
  4. Include the hint distribution and its correlation with the base key in the security assumptions.

What to watch for

A sparse relation can be attacked by subset search and lattice methods. Merely declaring a subset-sum problem hard does not justify arbitrary helper data or arbitrary parameter choices.

Papers

Programmable bootstrapping

Combining ciphertext refresh with evaluation of a function or lookup.

FDFB

FDFB embeds a lookup table into a full-domain functional bootstrapping procedure.

Papers

FDFB2

FDFB2 uses sparse polynomial multiplication for functional bootstrapping.

Papers

Encrypted-computation compilers and hybrid execution

Compile numerical or Boolean programs to HE, schedule packing and depth, combine HE with MPC, and use transciphering for symmetric-ciphertext inputs. Hardware arithmetic belongs to implementation.

Transciphering

Transciphering homomorphically decrypts symmetric ciphertexts into a homomorphic-encryption representation.

Papers

Homomorphic evaluation capabilities

Homomorphic encryption specifies which operations can be evaluated on encrypted data and what decryption must return afterward. Limited schemes support only some operations or a bounded computation budget. Compactness limits the size of evaluated ciphertexts; bootstrapping can extend the computation budget under additional conditions. Circuit privacy and verification of the evaluator's work are separate requirements.

Approximate eigenvector method

This method represents encrypted messages through approximate matrix eigenvalue relations.

Papers

BEHZ RNS-BFV

BEHZ is a residue-number-system variant of BFV.

Papers

BV homomorphic encryption

BV is a lattice-based homomorphic encryption construction used as a base for proxy re-encryption.

Papers

Carousel FHE

Carousel uses automorphism-group operations to rotate encoded lookup tables during bootstrapping.

Papers

Double hoisting

Double hoisting reorganizes repeated key-switch work within homomorphic linear transformations.

Papers

Field switching for BGV

Field switching moves homomorphic ciphertext computations between number fields of different dimensions.

Papers

Homomorphic evaluation of encrypted data

Homomorphic encryption lets a public evaluation algorithm transform ciphertexts so that decryption gives the result of a chosen computation on the original plaintexts.

Why it is useful

A party can process encrypted data without receiving its decryption key.

How it works

  1. Encrypt the input values.
  2. Describe a computation within the scheme's supported class.
  3. Evaluate that computation on the ciphertexts using public information.
  4. Decrypt the resulting ciphertext to obtain the intended plaintext result.

What to watch for

Confidentiality does not prove that an untrusted evaluator performed the requested computation. The permitted circuit class, output size and leakage about the computation also need explicit guarantees.

Related ideas

Papers

HPS RNS-BFV

HPS is a BFV residue-number-system variant with specialized scaling and basis extension.

Papers

Hybrid key switching

Hybrid key switching combines ciphertext decomposition methods in word-wise homomorphic encryption.

Papers

Leveled homomorphic encryption

A leveled construction fixes a maximum computation depth when setting up the scheme. Its keys or setup cost can depend on that bound while evaluated ciphertexts remain compact.

Why it is useful

The paper's bootstrapping theorem gives a way to handle any chosen finite depth without assuming that a secret key can safely encrypt itself.

How it works

  1. Choose the required depth before setup.
  2. Build the depth-bounded construction from a bootstrappable base scheme.
  3. Use the prescribed sequence of encrypted-key transitions.
  4. Keep the ciphertext and decryption size within the scheme's fixed bound.

What to watch for

This differs from one fixed setup that supports arbitrary further depth. A sufficiently deep chosen bound does not remove parameter, key-generation or computation costs.

Useful background: Bootstrapping, Compactness of homomorphic encryption.

Papers

META-BTS

META-BTS composes repeated CKKS bootstrapping operations.

Papers

MHEAAN

MHEAAN generalizes HEAAN packing to tensor-structured plaintext slots.

Papers

ModHE

ModHE adapts homomorphic encryption to module-lattice ciphertext structures.

Papers

RNS-CKKS

RNS-CKKS represents CKKS ciphertext coefficients in a residue number system.

Papers

SHIP bootstrapping

SHIP is a CKKS bootstrapping algorithm organized for shallow parallel evaluation.

Papers

Slot-to-coefficient transformation

This transformation moves packed plaintext data between slot and polynomial-coefficient representations.

Papers

YASHE

YASHE is a scale-invariant leveled homomorphic encryption scheme.

Papers

Approximate numerical evaluation

Approximate homomorphic encryption computes with encrypted numerical data while tracking error. Encoding scale, multiplication depth, rescaling and the accuracy of any polynomial approximations must be planned together.

Approximate reciprocals by repeated squaring

When x is close enough to one, its reciprocal can be approximated by multiplying factors built from repeated squarings of 1-x. After r factors, the residual is governed by (1-x) raised to 2^r.

Why it is useful

This replaces division with additions and multiplications that can be evaluated on ciphertexts.

How it works

  1. Ensure the input lies in the approximation domain; the paper first uses absolute value of 1-x at most one half.
  2. Set the initial residual to 1-x.
  3. Repeatedly square that residual and multiply the factors one plus the successive residuals.
  4. Stop when further reduction of approximation error is outweighed by arithmetic error and cost.

What to watch for

A reciprocal is undefined at zero, and this expansion does not converge for arbitrary inputs. More iterations spend levels and accumulate encrypted-arithmetic error.

Related ideas

Papers

CKKS

CKKS supports approximate arithmetic on encrypted real or complex numbers. It encodes scaled numerical data so that encryption noise becomes part of the tolerated numerical error rather than a value that must be removed exactly.

Why it is useful

Many statistical and scientific calculations need useful numerical precision, not exact recovery of every intermediate digit.

How it works

  1. Choose scales, modulus levels and parameters for the intended computation.
  2. Encode and encrypt numerical inputs.
  3. Evaluate additions and multiplications, managing scale and error as the calculation proceeds.
  4. Decrypt and decode an approximation to the result.

What to watch for

The construction in this paper is leveled: it supports a planned computation budget and does not include bootstrapping. Its historical parameters and benchmarks are not current security recommendations.

Papers

CKKS rescaling

Rescaling divides a ciphertext by a chosen factor, rounds its coefficients and moves to a smaller modulus. This reduces the scale of the encoded message and its existing error while introducing a new rounding error.

Why it is useful

Multiplication increases the scale and numerical magnitude. Rescaling prevents them from growing unchecked through a long computation.

How it works

  1. Choose the lower modulus level and corresponding division factor.
  2. Scale down and round the ciphertext coefficients.
  3. Update the message scale and error bound.
  4. Continue only while enough modulus and precision remain.

What to watch for

Rescaling spends modulus levels and is not a noise-free operation. It neither refreshes a ciphertext indefinitely nor repairs an already unreliable result.

Papers

Complex-slot packing in CKKS

Packing places several complex numbers in one plaintext polynomial. Evaluating that polynomial at selected roots of unity recovers the slots, so polynomial addition and multiplication act on all slots in parallel.

Why it is useful

One ciphertext operation can process many values instead of carrying a separate ciphertext for each number.

How it works

  1. Extend the desired slots with their complex conjugates.
  2. Use the inverse canonical embedding to obtain polynomial coefficients.
  3. Scale and round to an integer polynomial for encryption.
  4. After decryption, evaluate at the selected roots and divide by the scale.

What to watch for

The degree-N power-of-two construction carries N/2 complex slots. This is approximate numerical packing, not the finite-field packing of every other homomorphic scheme; rounding still contributes error.

Papers

Polynomial approximation under encryption

A nonlinear function can be replaced on a chosen input range by a polynomial that the encryption scheme can evaluate using addition and multiplication.

Why it is useful

Functions such as the exponential or logistic function are not directly supplied by an arithmetic homomorphic-encryption interface.

How it works

  1. Choose a domain on which the approximation error can be bounded.
  2. Select and encode a suitable polynomial.
  3. Evaluate it with a schedule compatible with the available levels and scales.
  4. Combine function-approximation error with coefficient-rounding and encrypted-evaluation error.

What to watch for

An approximation valid on one interval can be inaccurate outside it. Greater polynomial degree uses more work or depth and does not eliminate encryption error.

Papers

Boolean and lookup-based evaluation

Bit, small-integer and lookup-table computations on ciphertexts, including gate-by-gate evaluation and encrypted selection; bootstrapping is an enabling mechanism, not the function itself.

FHEW

FHEW performs homomorphic bit operations with bootstrapping-based ciphertext refresh.

Papers

TFHE

TFHE performs torus-based homomorphic computation using LWE and ring-GSW ciphertext operations.

Papers

Exact modular and integer evaluation

Homomorphic arithmetic with exact plaintext semantics in finite domains, including bounded-depth and bootstrapped evaluation. Ciphertext noise is not plaintext approximation.

BFV

BFV is a ring-based scale-invariant homomorphic encryption scheme for modular arithmetic.

Papers

BGV

BGV is a lattice-based homomorphic encryption scheme with ciphertext noise management by modulus switching.

Papers

DGHV

DGHV is an integer-based homomorphic encryption construction. A bit is encoded in the parity of a small remainder around a multiple of a secret odd integer.

Why it is useful

Its integer arithmetic gives a direct example of why encrypted addition and multiplication can work, and why accumulated noise eventually prevents decryption.

How it works

  1. Keep an odd integer p secret and publish suitably distributed noisy multiples of it.
  2. Encrypt a bit by combining public samples with fresh noise so that the centered remainder modulo p has the desired parity.
  3. Evaluate additions and multiplications over ciphertext integers.
  4. Decrypt by taking the centered remainder modulo p and then its parity.
  5. For deeper computation, use the paper's additional squashing and bootstrapping construction under its extra assumptions.

What to watch for

The base scheme handles only a bounded class of computations. Full homomorphism does not follow from integer multiplication alone. The retained 2010 parameter analysis and variants are historical, not current implementation recommendations.

Useful background: Homomorphic evaluation of encrypted data, Centered modular remainders.

Papers

Compressing final integer ciphertexts

The paper compresses an integer ciphertext c by transmitting a group element g^c. The group order contains the secret modulus, allowing a qualified decryptor to recover the needed residue.

Why it is useful

It trades the very large integer ciphertext for a shorter final output representation.

How it works

  1. Choose the special smooth secret modulus and the additional group parameters.
  2. After evaluation finishes, exponentiate the group generator by the integer ciphertext.
  3. Use the secret group-order information and small-prime discrete logs to recover the residue.
  4. Convert to the required remainder convention before decoding the bit.

What to watch for

This is a final-output transformation, not a drop-in replacement for ciphertexts used by later multiplication or bootstrapping. It changes the secret-key distribution and adds a decision-subgroup or phi-hiding-type assumption.

Papers

Degree and coefficient bounds for encrypted circuits

The integer scheme bounds an evaluated polynomial using both its degree and the size of its coefficients. Multiplication raises degree, while additions can increase coefficient magnitudes.

Why it is useful

Counting gates alone is not enough to know whether a computation can be decrypted correctly.

How it works

  1. Translate the Boolean arithmetic circuit into the corresponding integer polynomial.
  2. Bound the magnitudes of its encoded inputs.
  3. Use the degree and sum of absolute coefficient values to bound the output.
  4. Check that bound against the secret-modulus decoding margin.

What to watch for

A low-degree polynomial may have a deep implementation. The base scheme's analysis can still apply to it, but inserting intermediate modulus reductions makes the actual circuit and its added errors relevant too.

Papers

Noise growth in integer homomorphic encryption

In the integer scheme, the small signed remainder contains both the plaintext bit and an even error term. Addition adds these remainders; multiplication multiplies them. Decryption works only while the resulting remainder stays in the intended range.

Why it is useful

It explains the computation limit without attributing failure to a broken encryption key: arithmetic can exhaust the decryption margin even when the scheme was used honestly.

How it works

  1. Write each ciphertext as a multiple of p plus its small encoded remainder.
  2. Track the sum or product of those remainders during evaluation.
  3. Include plaintext terms and multiplication cross-terms in the bound.
  4. Require the final magnitude to stay below the decoding threshold, with any additional margin needed by later transformations.

Example

For the deliberately insecure toy modulus p=23, c=28 has remainder 5 and decrypts to 1. Squaring gives c=784, whose centered remainder is 2 and decrypts to 0: the noise budget was exceeded.

What to watch for

Correctness can fail when the remainder crosses the centered interval and wraps by an odd multiple of p. A small final plaintext does not imply small ciphertext noise.

Papers

Reducing ciphertexts by noisy public multiples

Reducing an integer ciphertext modulo a public value close to a multiple of the secret modulus changes the ciphertext's noise. The size of the reduction quotient controls how much error is introduced.

Why it is useful

It explains why a tempting size-saving operation can destroy decryption correctness.

How it works

  1. Write the public modulus as a secret-modulus multiple plus an error.
  2. Track the multiple subtracted during reduction.
  3. Include that multiple of the public error in the new ciphertext-noise bound.
  4. Use a justified sequence of reductions or a separately analyzed exact-multiple variant when appropriate.

What to watch for

The paper explicitly forbids simply reusing its encryption-time reduction after arbitrary multiplication. Its ladder of larger noisy multiples changes the public-key distribution, and its optimized bootstrapping noise analysis is omitted.

Papers

Restricted homomorphisms

Encryption supporting restricted algebraic operations such as addition, multiplication or bounded combinations, with explicit plaintext domain and permitted evaluation depth.

Additive homomorphic encryption

An additive homomorphic encryption scheme supports an operation on ciphertexts that corresponds to adding the hidden plaintexts. It usually also permits multiplication of a hidden value by a known constant.

Why it is useful

A server can compute totals or linear combinations without first decrypting the input values.

How it works

  1. Encrypt each input under the appropriate public key.
  2. Apply the scheme's ciphertext operation for addition.
  3. Use known coefficients to form a weighted sum if the scheme supports that operation.
  4. Decrypt only the final result.

What to watch for

Adding encrypted values and multiplying an encrypted value by a public constant are not the same as multiplying two independently encrypted unknown values.

Related ideas

Papers

Paillier encryption

Paillier is a public-key encryption system with an additive homomorphism: multiplying two ciphertexts gives an encryption of the sum of their plaintexts. Someone can therefore add protected values without having the decryption key.

Why it is useful

This supports protocols that need encrypted sums or private selection using encrypted zeroes and ones.

How it works

  1. Generate the public modulus and encryption parameters, keeping the required factorization secret.
  2. Encrypt a message using fresh randomization.
  3. Multiply ciphertexts to add their plaintexts, or raise a ciphertext to a known integer to multiply its plaintext by that integer.
  4. Decrypt the result with the private key.

Example

Encrypting 3 and 5 and multiplying the two ciphertexts yields an encryption of 8, provided the intended interpretation accounts for the modulus. This example shows the operation, not secure parameter sizes.

What to watch for

Arithmetic is modulo the plaintext modulus, so a sum may wrap around. This homomorphism is not arbitrary computation on ciphertexts, nor does it by itself give protection against maliciously chosen ciphertexts.

Useful background: Additive homomorphic encryption.

Papers

Ownership and joint evaluation keys

Key ownership, evaluation-key publication and joint decryption for encrypted computation. Independent input keys and shares of a collective key require different protocols.

Collective and threshold homomorphic encryption

Homomorphic evaluation under collectively managed keys, covering threshold decryption, distributed evaluation-key generation and collective refresh. Generic threshold decryption stays under threshold.

Noah's Ark threshold FHE

Noah's Ark combines noise flooding, parameter switching, and TFHE bootstrapping for threshold FHE.

Papers

Threshold fully homomorphic encryption

Threshold FHE combines homomorphic evaluation with decryption performed by multiple share holders.

Papers

Evaluation across independent keys

Evaluate ciphertexts originating under distinct secret keys, including dynamic key sets and mixed-key outputs. Joint output decryption does not imply a single shared input key.

Griffin mixed-key HE

Griffin extends Pegasus-style scheme switching to multi-key homomorphic encryption.

Papers

Multi-key homomorphic encryption

Multi-key HE evaluates ciphertexts encrypted under different participants' keys.

Papers

Security definitions and safe output release

Circuit privacy, evaluation-key assumptions, malicious ciphertext handling, verified evaluation and leakage through decrypting evaluated outputs. Homomorphic malleability is intentional and needs an appropriate security model.

Circuit privacy for homomorphic encryption

Circuit privacy hides which computation produced an evaluated ciphertext, beyond what its output reveals, even from a recipient holding the decryption key.

Why it is useful

Protecting encrypted inputs from the evaluator does not automatically protect the evaluator's computation from the decryptor.

How it works

  1. Specify what the output recipient may learn about the circuit.
  2. Account for ciphertext length, noise and other representation-dependent traces.
  3. Apply a circuit-privacy transformation under its stated assumptions.
  4. Compare output distributions for computations with the same permitted output information.

What to watch for

The paper's circuit-privacy treatment assumes honestly generated public keys. It does not establish privacy against a malicious key generator or prove that the evaluator computed the requested function.

Useful background: Homomorphic evaluation of encrypted data.

Papers

Circular security for encrypted secret keys

Circular security concerns encryption systems in which secret keys are themselves encrypted in a cycle, including a key encrypted under its own public key.

Why it is useful

Some bootstrapping designs use this arrangement to avoid a key chain whose length is fixed by the intended computation depth.

How it works

  1. Describe which secret key is encrypted under which public key.
  2. Identify cycles in those dependencies.
  3. State the additional security assumption for the published key encryptions.
  4. Separate that assumption from ordinary security for independently chosen messages.

What to watch for

Ordinary semantic security does not automatically imply circular security. In this paper, the claim for a single fixed fully homomorphic scheme is conditional on this additional property; the depth-bounded theorem is separate.

Papers

Compactness of homomorphic encryption

Compactness requires the evaluated ciphertext to have a size bounded by the security parameter rather than by the size of the computation performed.

Why it is useful

Without a compactness requirement, an evaluator could simply return the original encrypted inputs with a program and leave all meaningful work to the decryptor.

How it works

  1. Fix the encryption scheme and security parameter.
  2. Evaluate a supported circuit on encrypted inputs.
  3. Bound the output ciphertext size independently of the circuit size.
  4. Keep the scheme's decryption interface separate from the evaluation workload.

What to watch for

Compactness does not mean evaluation is cheap, that the public key is small, or that a recipient learns nothing about the circuit. The paper treats those as separate matters.

Papers

Fully homomorphic encryption schemes

Fully homomorphic encryption is an encryption scheme that lets anyone holding only the public key run computations on encrypted data without learning it: the evaluator combines ciphertexts according to any circuit and returns a ciphertext that decrypts to the circuit output on the original messages. This paper makes the goal practical to reason about by basing it on the standard Learning With Errors assumption, using re-linearization for multiplication and dimension-modulus reduction instead of the squashing step earlier schemes needed.

A ciphertext as a linear function of the secret key

Every ciphertext (a, b) defines a linear function f(x) = b minus the inner product of a and x, and decrypting just means evaluating that function at the secret key and reducing modulo two. Homomorphic operations then become operations on functions: adding ciphertexts adds their functions, and multiplying ciphertexts multiplies them.

Why it is useful

This viewpoint pinpoints exactly where multiplication breaks: the product of two linear functions is a degree-two polynomial whose coefficient list is roughly n squared over two entries long.

How it works

  1. Interpret each ciphertext as a linear function of an unknown vector x.
  2. Add ciphertexts by adding functions, which stays linear.
  3. Multiply ciphertexts by symbolically opening the product of the two functions into a degree-two polynomial.
  4. Notice that the ciphertext now needs about n squared over two coefficients instead of n plus one, which is the blow-up to fix.

What to watch for

The quadratic form only decrypts if it is evaluated at the true secret key, so the construction must somehow convert it back into a linear form under a usable key.

Useful background: Somewhat homomorphic encryption from Learning With Errors.

Papers

Bootstrapping into leveled fully homomorphic encryption

Gentry observed that if a somewhat homomorphic scheme can evaluate its own slightly augmented decryption circuit, it can be converted into a fully homomorphic one. Dimension-modulus reduction pushes the decryption circuit down to depth of order log k plus log log p, which the scheme can evaluate, so the construction becomes bootstrappable and each bootstrapping step refreshes the noise.

Why it is useful

This is the route from "somewhat" to "fully" homomorphic: the decryption polynomial in the bits of the secret key otherwise has degree at least the maximum of n and log q, which exceeds what the scheme can homomorphically evaluate.

How it works

  1. Evaluate the circuit homomorphically in the large parameters, obtaining a level-L ciphertext.
  2. Reduce its dimension and modulus down to (k, p), where decryption is a shallow inner-product circuit.
  3. Homomorphically evaluate that shallow decryption circuit, which decrypts and re-encrypts the message and resets the noise.
  4. To reach any fixed depth without extra assumptions, generate keys for all levels up front; the key generator takes the depth bound as an input.
  5. A scheme independent of the depth bound requires the additional assumption of weak circular security: the scheme stays secure even given encryptions of its own secret key bits.

What to watch for

What is proved from LWE alone is the leveled variant: only the evaluation key grows with the target depth, and the depth-unbounded variant leans on circular security, which is not implied by LWE.

Useful background: Dimension-modulus reduction: switching to a small key and modulus.

Papers

Ciphertext expansion through a masking scheme

Expansion turns a ciphertext made under one party's key into an equivalent ciphertext under the concatenation of all parties' keys. This conversion is what makes homomorphic arithmetic across different keys possible at all.

Why it is useful

Running GSW operations directly on ciphertexts from different keys gives nothing meaningful, so a shared format has to be created before any evaluation.

How it works

  1. At encryption time, release the ciphertext C together with helper information U, which consists of encryptions of the entries of the random matrix used to make C; the pair computationally hides the message.
  2. Later, given the public key of another party, combine the ciphertexts inside U into one matrix X that cancels the mask the other key would otherwise see.
  3. Place X beside C in a block matrix so that the combined secret key reads the same message in every block.
  4. Run ordinary GSW operations on the expanded ciphertexts, with dimensions scaled up by the number of parties.

What to watch for

The helper information holds one encryption per entry of the encryption randomness, so it is quadratic in the ciphertext dimension, and expanded ciphertexts grow with the number of participants. Expansion, not evaluation, dominates communication.

Useful background: Why GSW is the base scheme.

Papers

Dimension-modulus reduction: switching to a small key and modulus

The same mechanism that changes the secret key can also change the parameters: a ciphertext with dimension n and modulus q is converted into a ciphertext with much smaller dimension k and modulus p that encrypts the same bit. The intuition is that arithmetic modulo p approximates arithmetic modulo q, by scaling with p over q and rounding.

Why it is useful

It shrinks ciphertexts to about (k plus one) times log p bits, roughly as short as ordinary non-homomorphic LWE encryption, and it makes the decryption circuit small enough for bootstrapping.

How it works

  1. Publish, in the evaluation key, values that encode scaled bits of the long secret key under the short secret key, modulo p.
  2. After homomorphic evaluation in the large parameters, express the result as a linear function of the long secret key.
  3. Scale each coefficient by p over q and replace each term using the published values modulo p.
  4. Accept the extra rounding error of at most one half per term plus fresh small noise, which keeps the converted ciphertext decryptable under the short key.
  5. Security now rests on LWE hardness for both parameter sets: (n, q) and (k, p).

What to watch for

The smaller parameters look weaker, but the (k, p) instance can use much higher relative noise because it never needs to support homomorphism, so the two assumptions end up roughly balanced; the reduction still only works while the incoming noise is well below q.

Useful background: Re-linearization: multiplication without ciphertext growth.

Papers

Multi-key fully homomorphic encryption

Multi-key FHE lets each party pick its own key pair and encrypt under its own public key, and still allows homomorphic computation across all those ciphertexts. The result is a single ciphertext that no individual party can open, because opening it needs every secret key together.

Why it is useful

It removes the distributed key generation step that forced the extra round in the threshold FHE template: nothing has to happen before the parties encrypt.

How it works

  1. Each party generates an independent key pair and encrypts its input under its own public key.
  2. The ciphertexts are converted into a common multi-key format.
  3. The circuit is evaluated homomorphically on the converted ciphertexts.
  4. The evaluated ciphertext decrypts only when all the secret keys contribute.

What to watch for

The first such scheme, by Lopez-Alt, Tromer and Vaikuntanathan, rested on an NTRU-type assumption and did not support the simple one-round distributed decryption that the second round of the protocol needs.

Useful background: Homomorphic evaluation of encrypted data, The three-round threshold FHE template.

Papers

No squashing and no sparse subset-sum assumption

All earlier fully homomorphic schemes had to squash their decryption circuit and pay with an extra assumption, the average-case sparse subset-sum problem. This paper removes that step: dimension-modulus reduction makes the decryption circuit genuinely small, so no additional assumption beyond LWE is needed.

Why it is useful

Removing that assumption was seen as the main open problem in the design of fully homomorphic encryption, and dropping it is the second headline contribution of the paper.

How it works

  1. Start from the somewhat homomorphic LWE scheme with re-linearization.
  2. Shrink the ciphertext parameters with dimension-modulus reduction instead of squashing decryption with extra hint bits.
  3. Check that the resulting decryption circuit fits inside the function class the scheme can already evaluate.
  4. Apply the bootstrapping theorem to obtain a leveled fully homomorphic scheme under LWE hardness alone.

What to watch for

The gain is in the assumption, not in every cost: the evaluation key is large and, in the leveled scheme, its size grows linearly with the depth of the circuit to be evaluated.

Useful background: Dimension-modulus reduction: switching to a small key and modulus.

Papers

One-round threshold decryption with smudging noise

To open a multi-key ciphertext, each party broadcasts one value, its partial decryption, computed from its own slice of the ciphertext and its own secret key, with fresh random noise added. Adding up all the partial decryptions reveals the message.

Why it is useful

Decryption is the only interaction left after homomorphic evaluation, so it must cost a single round per party for the overall protocol to stay at two rounds, and the broadcast values must not give away the secret keys.

How it works

  1. Cut the evaluated ciphertext into one horizontal block per party and let each party act on its own block with its secret key.
  2. Add random smudging noise whose range is much larger than the error inside the ciphertext.
  3. Sum the partial decryptions and round the total to whichever of zero and half the modulus it is closer to.
  4. Simulate any single party's partial decryption given the plaintext and every other secret key, so the broadcast value hides that party's key.

What to watch for

The simulation guarantee covers one party at a time rather than a whole subset at once, and this weakness is exactly what complicates the security proof of the multiparty protocol built on top.

Useful background: Ciphertext expansion through a masking scheme.

Papers

Re-linearization: multiplication without ciphertext growth

Re-linearization publishes, in the evaluation key, LWE-style encodings of every linear and quadratic term of the current secret key under a fresh secret key. Any degree-two expression in the old key can then be rewritten as a linear expression in the new key, so after every multiplication the ciphertext shrinks back to n plus one elements.

Why it is useful

It lets an LWE scheme multiply without ciphertext blow-up and without assuming that ideals in polynomial rings are hard, which is what earlier fully homomorphic schemes needed.

How it works

  1. Publish pairs that encode each s[i] and each product s[i]s[j] under the new key t.
  2. Multiply two ciphertexts symbolically to get a quadratic polynomial with known coefficients.
  3. Replace each quadratic term using the published encodings, which turns the polynomial into a linear function of t.
  4. Because the polynomial coefficients can be large, decompose each one into bits and publish one encoding per bit position, so every encoding is only ever used with a zero-or-one multiplier.
  5. Post a chain of L secret keys, each encoding the quadratic terms of its predecessor, to allow up to L levels of multiplication at fixed ciphertext size.

What to watch for

The noise still grows with every multiplication, and beyond a depth of about a small constant times log n the accumulated error destroys the ciphertext unless bootstrapping is used.

Useful background: A ciphertext as a linear function of the secret key.

Papers

Short ciphertexts and the private information retrieval payoff

Because dimension-modulus reduction leaves ciphertexts of about (k plus one) times log p bits, the scheme can drive single-server private information retrieval (PIR): a user fetches one entry from a database without revealing which entry was wanted. The user encrypts a symmetric key once during setup, sends only a short symmetric encryption of the index per query, and the server homomorphically decrypts and evaluates the lookup.

Why it is useful

It shows a concrete payoff of short ciphertexts: communication close to the log N lower bound needed merely to name an entry of an N-entry database, which earlier homomorphic-encryption-based PIR did not achieve.

How it works

  1. During setup, the receiver publishes an encryption of a symmetric key together with the public key.
  2. Per query, encrypt only the index under the symmetric scheme, keeping the query itself short.
  3. The server homomorphically decrypts the index and evaluates the database access function on encrypted data.
  4. The response is a single short ciphertext thanks to dimension-modulus reduction.
  5. Total communication per query lands near the information-theoretic log N lower bound.

What to watch for

The public key is large and is only excluded from the communication count under the public-key model, and the best parameters assume that approximate shortest-vector problems take nearly exponential time in the lattice dimension.

Useful background: Dimension-modulus reduction: switching to a small key and modulus.

Papers

Somewhat homomorphic encryption from Learning With Errors

A Learning With Errors (LWE) ciphertext is a random vector a together with a value b that equals the inner product of a with a secret vector s, plus twice a small error, plus the message bit. Decryption recomputes the inner product, subtracts it, and reduces modulo two, which works because the error is much smaller than the modulus q. Adding two ciphertexts adds both the messages and the errors, so this scheme is additively homomorphic for free.

Why it is useful

This is the building block that the whole construction upgrades, and it uses only plain vectors, so its security can rest on the general LWE assumption instead of assumptions about special algebraic structure.

How it works

  1. Encrypt a bit m by sampling a random vector a and a small error e, and output the pair (a, b) where b equals the inner product of a and s plus 2e plus m.
  2. Decrypt by recomputing and subtracting the inner product with the secret s, which removes the secret mask and leaves 2e plus m.
  3. Reduce modulo two to strip the error: this is legal because e is tiny compared with q.
  4. Add ciphertexts coordinate by coordinate: messages add and errors add, so the same form is preserved.

Example

With secret s = (3, 5), a = (7, 2), error e = 1, message bit 1: b = 7·3 + 2·5 + 2·1 + 1 = 34, so the ciphertext is ((7, 2), 34). Decrypting gives 34 − 31 = 3, and 3 mod 2 = 1.

What to watch for

Multiplication is the hard part: multiplying two such ciphertexts multiplies the noise terms together and turns the decryption formula into a quadratic expression, so the scheme on its own cannot evaluate deep circuits.

Related ideas

  • Fully homomorphic encryption: the overall goal

Papers

Why GSW is the base scheme

The construction starts from the Gentry-Sahai-Waters scheme. There a ciphertext of a bit is a matrix that the secret key maps to the message times a fixed public matrix G, so adding ciphertexts is matrix addition and multiplying them is a product taken through a short representation of the second ciphertext.

Why it is useful

GSW needs no evaluation key, so there is nothing to distribute before encryption. The only shared value is a random public matrix, which can be published once as a common parameter and read from a common random string.

How it works

  1. Publish a random matrix B as a common parameter; every public key is built from the same B.
  2. Encrypt a bit by adding a random bit-matrix times the public key to the message times G.
  3. Add ciphertexts entrywise and multiply them as a product through the short preimage function.
  4. Homomorphic evaluation of any circuit works as long as the accumulated error stays small.

What to watch for

The scheme is leveled: its parameters must be chosen for the depth of the circuit being evaluated, which is why the resulting multiparty computation protocol also depends on the circuit depth.

Useful background: Multi-key fully homomorphic encryption, Learning with errors as lattice decoding.

Papers

Multilinear maps and graded encodings

A multilinear map generalizes a pairing: instead of combining two hidden exponents into one element that depends on their product, it combines many at once. This paper argues that the useful object is not one map on groups but a graded encoding scheme, a system of encodings of ring cosets with levels, where encodings add within a level, multiply across levels and can be tested for equality at the top level. The encodings are randomized, so one hidden value has many representations, and they are noisy, so only a bounded number of multiplications is supported.

Encoding a coset as a short numerator over a secret denominator

A level-i encoding of a coset is a fraction: a short numerator taken from that coset, divided by the i-th power of the secret denominator z, all reduced modulo a large modulus q. Adding encodings adds cosets, and multiplying them multiplies cosets and adds levels, exactly as long as the numerators stay short.

Why it is useful

This single rule is the whole mechanism: it gives the limited homomorphism that pairings give, but graded by level, and it is why the scheme earns the name graded encoding.

How it works

  1. Sample a short level-zero element; it is a plaintext representative of a random coset.
  2. Multiply by a published level-one encoding of one to move up one level, which is the same as dividing the numerator by the secret denominator once.
  3. Add two encodings at the same level: the numerators add and the sum stays in the sum of the two cosets.
  4. Multiply up to a bounded number of encodings: the numerators multiply and the denominators power up, so the result is a higher-level encoding of the product coset.

What to watch for

Division in the ring modulo q would undo an unprotected encoding, since the denominator is invertible, so fresh encodings must be re-randomized; and correctness is only promised while the numerator stays small, below roughly the eighth root of the modulus.

Useful background: Ideal lattices: the ring, the ideal and what gets encoded.

Papers

From bilinear maps to graded encodings

A bilinear map, usually called a pairing, takes two group elements that hide secret exponents and returns one element that depends on the product of those exponents. Cryptographers wanted a multilinear map that combines many inputs at once, so that several parties could agree on a shared key after a single broadcast each. This paper does not build that ideal object; it builds an approximation and calls it a graded encoding scheme.

Why it is useful

Pairings already give identity-based encryption, three-party key agreement and much more. Boneh and Silverberg argued that multilinear maps would give multipartite Diffie-Hellman key exchange and very efficient broadcast encryption, but their attempts from algebraic geometry hit serious obstacles, so the target stayed open for a decade.

How it works

  1. Start from pairing groups, where the encoding of a secret exponent is a group element and the pairing multiplies two hidden exponents.
  2. Ask for the same capability with many inputs, so N parties each publish one value and everyone can compute the product of all N secrets.
  3. Replace the groups by collections of encodings of ring elements, where one hidden value has many different valid representations.
  4. Let any subset of encodings be multiplied, up to a level bound, instead of exactly a fixed number of them.

Example

With a pairing, e(g^a, g^b) hides the product a times b; a multilinear map would let N parties compute one shared value from g to the product of all their secrets.

What to watch for

The authors are explicit that the maps are noisy, bounded in degree, and unlike the ideal multilinear maps of Boneh and Silverberg: some problems that stay hard with pairings become easy here.

Useful background: Pairings and bilinear maps.

Papers

One-round N-party Diffie-Hellman key exchange

Each of N parties publishes one level-one encoding of a secret random coset and keeps the level-zero encoding to itself. Multiplying your own secret encoding by the public values of the other N minus one parties gives a top-level encoding of the product coset, and extraction turns that into the shared key.

Why it is useful

Two parties can do this with ordinary Diffie-Hellman and three parties with a pairing; beyond that, nothing was available without multilinear maps. This is the application the paper actually works out end to end.

How it works

  1. Run the setup once; the parameters and the zero-testing parameter become public.
  2. Each party samples a secret level-zero encoding and publishes a level-one encoding of the same coset.
  3. Each party multiplies its secret by all the other public values, obtaining a level N minus one encoding of the product coset.
  4. Each party extracts the most significant bits of the tested value; agreement of extraction gives everyone the same key, and the graded decision Diffie-Hellman assumption says an eavesdropper cannot tell that key from random.

What to watch for

Because the setup parameters hide secrets, the protocol lives in the common reference string model, so someone must generate the parameters honestly; security is only as good as the graded decision Diffie-Hellman assumption.

Useful background: Zero-testing and extracting a shared bit string, Noise growth bounds the multilinearity degree.

Papers

Stated assumptions and problems that become easy

The security target is a graded version of the decision Diffie-Hellman problem: given level-one encodings of random cosets, it should be hard to tell a top-level encoding of their product from a top-level encoding of a random coset. The authors say the assumptions behind this are new and unconventional, and they do not expect a reduction to established problems; meanwhile other pairing-style problems are easy here.

Why it is useful

Knowing which problems stay hard and which collapse decides what the primitive can be used for. A scheme that only supports the Diffie-Hellman-style assumption cannot simply inherit the whole pairing toolbox.

How it works

  1. State the graded computational and decision Diffie-Hellman problems for the encoding system.
  2. Check the scheme against generic attackers modeled as straight-line programs, which the paper proves cannot solve the computational version.
  3. Combine the published encodings of zero with the zero-testing parameter to obtain plaintext-like values at levels below the top.
  4. Use those values to break subgroup membership and decision-linear style problems, which is why the paper says they are easy.

What to watch for

The authors ask for more cryptanalysis and wrote their survey sections as a starting point for cryptanalysts, so the assumptions are offered as plausible rather than established.

Useful background: Zero-testing and extracting a shared bit string.

Related ideas

Papers

Zero-testing and extracting a shared bit string

A published zero-testing parameter lets anyone check whether a top-level encoding hides the zero coset: multiply the encoding by the parameter and test whether the result is small. Because encodings can be subtracted, this also decides whether two top-level encodings hide the same value, and reading off the most significant bits of the tested value gives one shared bit string for every encoding of the same coset.

Why it is useful

Without a zero-test, two parties holding different encodings of the same product could never tell, and no key agreement or equality test would be possible. Extraction is what turns the algebra into a usable key.

How it works

  1. Publish a zero-test parameter built from a somewhat small element h multiplied by the top power of the denominator and divided by the secret generator.
  2. Multiply a top-level encoding by this parameter and reduce modulo q.
  3. If the encoding hides zero, the division cancels and the result is small; otherwise it is large, so a size threshold separates the two cases.
  4. To extract, take the most significant bits of each coefficient of the tested value and apply a randomness extractor with a public seed; encodings of the same coset agree on those bits, encodings of different cosets do not.

What to watch for

The paper warns that publishing encodings of zero together with the zero-testing parameter gives the adversary significant power, and that the test is only reliable at the top level.

Useful background: Encoding a coset as a short numerator over a secret denominator.

Papers

Private searches and hidden storage accesses

These methods protect what you look up in stored data. Some hide a query from a database; others also hide which memory locations a program reads and writes.

DORY encrypted search

DORY distributes keyword search over encrypted files across multiple servers.

Papers

FASTIO

FASTIO changes FAST's encrypted-search index processing for storage I/O.

Papers

MulPIR

MulPIR uses multiplicative homomorphism for recursive PIR query evaluation.

Papers

Onion ORAM

Onion ORAM uses homomorphic processing of layered encrypted memory blocks.

Papers

Onion Ring ORAM

Onion Ring ORAM combines the Onion ORAM design with leveled TFHE operations.

Papers

PaXoS-based PSI

This two-party PSI protocol uses PaXoS encodings and oblivious transfer.

Papers

Respire

Respire uses query compression and ring-switching response packing for PIR over small records.

Papers

Ring ORAM

Ring ORAM is a tree-based ORAM construction with bucket-local access processing.

Papers

SpOT-Light

SpOT-Light constructs private set intersection from sparse OT extension.

Papers

Square-root ORAM

Square-root ORAM combines periodic data reshuffling with a smaller access buffer.

Papers

Stateful OnionPIR

Stateful OnionPIR uses homomorphic copy-network evaluation for stateful retrieval.

Papers

Access-pattern leakage and query protection

Specify and reduce query equality, access, result-volume, update and timing leakage through padding, batching, oblivious access or related controls. Leakage attacks and general analysis methods belong to analysis.

Access-pattern leakage

Encrypting a file hides its contents, but a storage provider can still see which encrypted blocks you read and when you return to them. That pattern can reveal information about your searches or activity.

Why it is useful

This explains why keeping the encryption key secret does not by itself make a remote database private.

How it works

  1. Separate the contents of a request from the address it touches. Encryption protects the contents, not automatically the address.
  2. Repeated addresses reveal that requests concern the same stored item, even if the server cannot decrypt it.
  3. Oblivious storage changes the physical accesses so that different logical requests produce indistinguishable observations.

Example

An encrypted medical database may hide each record while repeated reads of one address still show that the same record is being consulted.

What to watch for

Hiding addresses does not automatically hide request timing or the total number of requests.

Related ideas

Papers

Encrypted search interfaces

Search encrypted collections using symmetric or public-key query mechanisms, covering keyword predicates, authorization and database-query interfaces. Detailed leakage belongs to the linked topic.

FAST encrypted search

FAST constructs searchable symmetric encryption using symmetric cryptographic primitives.

Papers

Findex

Findex is a searchable-encryption construction supporting concurrent database operations.

Papers

TWORAM

TWORAM is an oblivious-RAM construction applied to searchable encryption.

Papers

Searchable symmetric encryption

Symmetric encrypted indexes for static or dynamic keyword queries, including conjunctive search, update concurrency and forward or backward privacy requirements.

DISCO encrypted search

DISCO combines range-constrained PRFs with a global counter for dynamic encrypted search.

Papers

OXT encrypted search

OXT supports conjunctive keyword search over a symmetric encrypted index.

Papers

Sophos

Sophos is a dynamic searchable symmetric-encryption construction.

Papers

Structured encryption and richer queries

Encrypt data structures supporting range, graph, proximity, relational or key-value queries. Structure-aware query privacy is distinct from the encoding used to store records.

ProxCode

ProxCode uses error-correcting codes for proximity queries over encrypted data.

Papers

Oblivious key-value encodings and retrieval

Encode key-value mappings for oblivious protocols, including dense or sparse OKVS and keyed decoding. An encoding alone does not establish PIR, ORAM or a complete private retrieval protocol.

Oblivious key-value retrieval

OKVR retrieves values for selected keys using a sparse oblivious key-value store.

Papers

Oblivious key-value stores

An OKVS encodes key-value pairs into a data structure that supports keyed decoding.

Papers

PaXoS encoding

PaXoS encodes mappings as probe-and-XOR combinations of stored strings.

Papers

Sparse oblivious key-value stores

Sparse OKVS is an encoding used to retrieve selected key-value pairs in unbalanced circuit-PSI.

Papers

Oblivious memory and storage access

Even encrypted storage can reveal which items you read. Oblivious RAM changes where data is stored and how it is fetched so the server cannot tell which logical item an access concerns.

FutORAMa

FutORAMa is a hierarchical oblivious-RAM construction.

Papers

Oblivious RAM

Oblivious RAM, usually shortened to ORAM, lets a client read and update remote storage while hiding which data items it accesses. The server sees physical reads and writes, but should not be able to distinguish two logical request sequences of the same length.

Why it is useful

It protects the pattern of memory or storage accesses, which ordinary encryption leaves visible.

How it works

  1. Keep a secret mapping between logical data items and their physical storage locations.
  2. Move and re-encrypt data during accesses so repeated requests cannot be linked by their physical addresses.
  3. Make reads and writes follow the same externally visible procedure.

What to watch for

The client and its private state must be trusted. The definition in this paper does not hide when requests occur, and integrity against a dishonest storage server requires an additional mechanism.

Related ideas

Papers

Path ORAM

Path ORAM stores encrypted data in a tree. To access one item, the client reads and rewrites an entire path from the root to a leaf, hiding which item on that path was needed.

Why it is useful

A tree path provides a simple, uniform access procedure without reading the entire remote database.

How it works

  1. Give each logical data block a secret, randomly chosen leaf label. Store the block somewhere on that leaf's path, or in a small private overflow buffer.
  2. Look up the requested block's old leaf and immediately choose a fresh random leaf for its next location.
  3. Read the whole old path into private memory, then read or update the requested block.
  4. Fill the old path with eligible buffered blocks, starting at the leaf and moving toward the root. Pad empty spaces and freshly encrypt everything written back.

Example

With four leaves, a block assigned leaf 2 may be at the root, the middle node on that path, or leaf 2 itself. Reading the whole path does not tell the server which of those blocks was wanted.

What to watch for

The private overflow buffer can fill up; its size is part of the construction's failure analysis. This protocol also needs separate integrity protection against a server that changes or replays data.

Useful background: Oblivious RAM, ORAM position map, ORAM stash.

Papers

Authenticated Path ORAM

Authenticated Path ORAM adds checks that the storage server returned the expected, current tree contents. It combines access-pattern hiding with a Merkle tree over the storage buckets.

Why it is useful

Hiding which block is accessed does not stop a dishonest server from changing a block or replaying an old version.

How it works

  1. Hash each bucket together with the hashes of its two children.
  2. Keep a trusted commitment to the current root.
  3. When reading a path, obtain the sibling information needed to recompute and check the root.
  4. When rewriting the path, update its hashes and the trusted root.

What to watch for

Freshness depends on keeping the current root trusted. Checking against an old, attacker-supplied root would not establish that the data is current.

Related ideas

Papers

ORAM position map

A position map is the client's secret directory from logical block names to their assigned locations. In Path ORAM it stores a leaf label, rather than an exact physical slot.

Why it is useful

The client needs to find a requested item even though accesses keep changing where items may be stored.

How it works

  1. Use the block identifier to look up its current leaf label.
  2. Fetch the path associated with that old label.
  3. Replace the label with a fresh random choice on every access, including repeated reads of the same block.

What to watch for

The map is private state. Storing it openly at the server would expose the relationship that the ORAM is trying to hide.

Related ideas

Papers

ORAM stash

A stash is a small private buffer for blocks that do not currently fit into the permitted tree buckets. It also holds blocks temporarily while a path is being processed.

Why it is useful

Random placement can crowd some parts of the tree. The stash lets an access finish without dropping a block or revealing a special overflow location to the server.

How it works

  1. Read the requested path into the client's private storage.
  2. Write eligible blocks back into buckets that have room.
  3. Keep any remaining blocks privately for later eviction.

What to watch for

Persistent overflow storage and the temporary space needed to read a path are different costs. The paper's proven overflow bound uses bucket capacity at least five; the smaller capacity of four is supported there by experiments, not the same theorem.

Papers

Path eviction

Path eviction moves buffered blocks back into the tree after an access. A block can only enter a bucket that lies on the path to its currently assigned leaf.

Why it is useful

Eviction makes room in the private stash while preserving the rule that allows every block to be found later.

How it works

  1. Start with the deepest bucket on the path being rewritten.
  2. Choose buffered blocks whose assigned paths pass through that bucket, up to its capacity.
  3. Remove those blocks from the stash, then repeat for the next bucket toward the root.
  4. Fill unused slots with dummy blocks and freshly encrypt real and dummy blocks alike.

What to watch for

A block cannot simply be written to any empty bucket. Breaking the path rule can make a later lookup miss it.

Papers

Recursive Path ORAM

Recursive Path ORAM stores the position map in another, smaller ORAM. It repeats this idea until the final map is small enough to keep at the client.

Why it is useful

Without recursion, the client's position map grows with the entire remote database and can become too large.

How it works

  1. Put the data blocks in the first ORAM.
  2. Pack that ORAM's position-map entries into blocks of a second ORAM.
  3. Repeat for further position maps, keeping only the smallest one directly at the client.
  4. Resolve a lookup starting from the smallest map and work back toward the data block.

What to watch for

Recursion saves private storage but adds lookups. The bandwidth claim depends on the block sizes chosen for the data and the position maps.

Papers

Shared ORAM stash

A recursive ORAM can let its different levels share one private overflow buffer instead of reserving a separate maximum-sized stash for every level.

Why it is useful

Pooling overflow storage reduces the total client memory requirement: the design does not reserve every level's worst-case capacity simultaneously.

How it works

  1. Keep track of which recursive ORAM each buffered block belongs to.
  2. Store overflow blocks from the different levels in a common private area.
  3. Choose the common capacity using the bound for the sum of the levels' stash occupancies.

What to watch for

The shared buffer still needs an overflow analysis. The paper derives its bound from the stash distributions and randomness of the recursive levels; pooling alone is not a proof.

Papers

OptORAMa

OptORAMa is an oblivious-RAM construction using a hierarchical organization.

Papers

PanORAMa

PanORAMa is a hierarchical oblivious-RAM construction.

Papers

Distributed and computation-integrated ORAM

Oblivious memory implemented across multiple servers or within MPC and circuit evaluation, including secret-shared addresses and memory contents.

Circuit ORAM

Circuit ORAM organizes oblivious memory access for circuit-based evaluation.

Papers

Duoram

Duoram is a distributed ORAM for two-party and three-party computation.

Papers

Stateless ORAM

A stateless ORAM lets a client keep very little information between accesses. It downloads the protected working state before an access and uploads the updated state afterward.

Why it is useful

This is useful when multiple authorized clients need to use the same remote storage without each holding a permanently changing local copy of the full ORAM state.

How it works

  1. Keep the long-term secret key locally.
  2. Retrieve the current protected client state before processing a request.
  3. Perform the ORAM access using temporary private memory.
  4. Save the updated state and discard the temporary copy.

What to watch for

Stateless does not mean the operation needs no private memory, and simultaneous clients still need a consistent view of the current state.

Related ideas

Papers

ORAM layouts, eviction and rebuilding

Tree, hierarchical and buffered memory organizations, with stash management, eviction, recursive position maps and rebuild schedules. Homomorphic processing is an implementation choice within these designs.

Hierarchical ORAM

Hierarchical ORAM organizes outsourced memory into levels that are periodically rebuilt.

Papers

Private information retrieval

Private information retrieval hides which database entry you want. A short reply can still require a large query or substantial server computation, so these costs must be considered separately.

Gentry-Ramzan PIR

Gentry-Ramzan is a number-theoretic private information retrieval scheme.

Papers

PIRANA

PIRANA uses constant-weight codes for multi-query private information retrieval.

Papers

Private information retrieval

Private information retrieval, or PIR, lets someone retrieve an item from a database without revealing which item they requested. Downloading the whole database would achieve that privacy trivially; a PIR protocol tries to use less communication.

Why it is useful

It protects the choice of a record, even when the database server is the party that must answer the request.

How it works

  1. Encode the desired index into a query that hides the index.
  2. Let the server compute a reply using that query and its database.
  3. Decode the reply to recover the selected item.

What to watch for

Query privacy is not the same as hiding the database from the client or proving that the answer is correct. Also distinguish reply size from query size and server computation.

Related ideas

  • Oblivious RAM: Protects a sequence of storage accesses, including updates, rather than only a single database query.
  • Oblivious transfer: Also restricts what the receiver learns about the other items.

Papers

SealPIR

SealPIR is a homomorphic-encryption-based private information retrieval construction.

Papers

XPIR

XPIR is a single-server private information retrieval construction.

Papers

YPIR

YPIR performs single-server private information retrieval with silent preprocessing.

Papers

Multi-server and coded PIR

Queries distributed over replicated or coded databases, including information-theoretic and computational constructions with explicit server-collusion thresholds.

TreePIR

TreePIR combines two-server retrieval with a smaller single-server PIR subquery.

Papers

Single-server computational PIR

Private queries to one logical database server using computational assumptions, including HE-based evaluation and compressed queries or responses.

DoublePIR

DoublePIR is a separate hint-based single-server PIR construction presented alongside SimplePIR.

Papers

Encrypted indicator vectors

An indicator vector contains one 1 at the chosen position and 0 everywhere else. Encrypting those entries lets a server use the vector to select data without seeing which position contains the 1.

Why it is useful

Homomorphic evaluation can multiply each stored value by its hidden selector and add the results, leaving only the selected value.

How it works

  1. Create a vector with a 1 at the requested position.
  2. Encrypt every vector entry with fresh randomness.
  3. Have the server form the corresponding encrypted weighted sum of database values.
  4. Decrypt the sum to obtain the selection.

Example

To choose the middle value from [a, b, c], the illustrative selector is [0, 1, 0]. The server must receive encryptions of those bits, not this readable selector.

What to watch for

A dishonest client might encrypt a different vector. Whether that is allowed, leaks additional data or must be ruled out depends on the full protocol.

Papers

FrodoPIR

FrodoPIR is a stateful single-server PIR scheme with client-independent offline work.

Papers

OnionPIR

OnionPIR composes two lattice-based somewhat homomorphic encryption schemes for single-server PIR.

Papers

Piano PIR

Piano uses PRF-based client preprocessing for single-server PIR.

Papers

PIR with an encrypted row and column

This private-retrieval construction arranges a database as a matrix and hides the requested row and column in encrypted indicator vectors. The server reduces the matrix in stages rather than receiving an encrypted selector for every database position.

Why it is useful

Representing an index by coordinates can reduce the size of the query, while homomorphic computation keeps those coordinates hidden.

How it works

  1. Lay out the database as rows and columns.
  2. Encrypt a row selector and a column selector.
  3. Use the column selector to produce an encrypted selected-column value for every row.
  4. Split the intermediate ciphertexts into pieces that fit the plaintext space, then use the encrypted row selector to select the required pieces.
  5. Decrypt and reconstruct the selected result.

What to watch for

The server still performs substantial computation over the database. A short reply does not mean the query, computation and total communication are all equally small.

Useful background: Paillier encryption, Encrypted indicator vectors.

Papers

Ciphertext splitting in recursive PIR

In this construction, an intermediate Paillier ciphertext is too large to be treated as one plaintext for the next selection. It is split into smaller pieces, selected piece by piece, and reconstructed by the client.

Why it is useful

This lets encrypted selection be repeated across database dimensions without pretending that a ciphertext and a plaintext have the same size.

How it works

  1. Represent the intermediate ciphertext as two base-modulus pieces.
  2. Perform the next encrypted selection separately on each piece.
  3. Decrypt the selected pieces and reconstruct the intermediate ciphertext.
  4. Continue the reconstruction and decryption steps until the requested data item is recovered.

What to watch for

The number of returned pieces grows as this recursion adds dimensions. The paper uses that tradeoff to balance query size against reply size.

Papers

Spiral PIR

Spiral composes homomorphic encryption techniques for single-server PIR.

Papers

ThorPIR

ThorPIR uses homomorphic Thorp shuffles for single-server PIR.

Papers

Stateful, preprocessed and updatable PIR

Amortize retrieval with client hints or server preprocessing, including reusable state, batched queries and updates; distinguish who performs offline work and who stores its results.

InsPIRe

InsPIRe performs PIR with server-side preprocessing.

Papers

Plinko PIR

Plinko uses invertible PRFs to maintain client hints for updatable PIR.

Papers

SimplePIR

SimplePIR uses client hints and lattice-based query processing for single-server retrieval.

Papers

Symmetric PIR and database privacy

Protect unrequested database contents as well as client selections, including relation to OT, priced retrieval and authorized access. Symmetric here means two-sided privacy, not symmetric-key encryption.

Verifiable and delegated retrieval

Detect incorrect, inconsistent or stale PIR answers, including delegated server work and authenticated database versions. Privacy and answer correctness are separate guarantees.

DPIR messaging

DPIR delegates server PIR work to messaging clients and checks their responses.

Papers

VeriSimplePIR

VeriSimplePIR adds stateful verification to SimplePIR query responses.

Papers

Comparing and analysing private data

Organizations may want to find shared customers, add up measurements or publish statistics without revealing every input. Different methods protect against different kinds of information leakage.

Two-server model for private machine learning

Several data owners hand their data to two computing servers that never share notes; each server alone sees only random-looking shares, and the pair together trains a model on the combined data.

Why it is useful

Hospitals, banks and payment networks often cannot pool raw data because of competition, privacy law or data-sovereignty rules. Splitting each value between two non-colluding servers lets them compute on the union without either one seeing it.

How it works

  1. Each owner splits every value into two random pieces that add up to it, and sends one piece to each server; a piece on its own reveals nothing.
  2. The two servers run a secure two-party computation on the shared data and keep intermediate results shared as well.
  3. Only the trained model is reconstructed at the end, so a server learns nothing beyond what it owns and what the output says.

Example

Two banks secret-share their transaction records between two cloud providers; the providers jointly fit a fraud model and return the coefficients.

What to watch for

The whole design rests on the assumption that the two servers do not collude. If they exchange their shares, every value opens up. The clients also stop participating after the setup phase, so they cannot watch what the servers do.

Useful background: Secret sharing.

Related ideas

Papers

Private set and relational operations

Jointly compute on private sets or relations, including two-party, multiparty, delegated and unbalanced inputs. Output function, update pattern and adversary model are separate choices.

Cardinality and secret-shared set outputs

Compute intersection size or aggregate functions of matches, or leave matched results shared for later computation rather than revealing the intersection.

Circuit-PSI

Circuit-PSI leaves the intersection secret-shared for a subsequent computation.

Papers

Private set intersection and matching

Private matching protocols control which comparison results are revealed. Start by distinguishing one-way intersection, mutual intersection, authorized queries and transfer of matching records. They have different output and trust requirements; none automatically hides set sizes or every consequence of repeated queries.

Authorized private set intersection

Authorized private set intersection restricts matching to client elements carrying authorization from a trusted authority, such as a signature on each allowed record identifier.

Why it is useful

It addresses the problem that an ordinary private intersection protocol may accept arbitrary client guesses rather than an approved set of queries.

How it works

  1. The authority authorizes specific client elements.
  2. The client obtains the required authorization material.
  3. The intersection protocol ties successful matching to that material.
  4. Return the intersection permitted by both the server set and the authorizations.

What to watch for

The authority must enforce a meaningful issuance policy. This paper assumes an honest authority and an honest-but-curious server; the authorization requirement does not imply that its protocols withstand arbitrary malicious behavior.

Papers

Blind RSA-based private set intersection

This historical construction obtains comparable record tags through blinded RSA evaluations. The client hides each hashed record with a random multiplicative factor, receives the server's RSA evaluation and removes the factor.

Why it is useful

The client can recognize matching server tags while much of the server-set work is moved into preprocessing.

How it works

  1. Hash records into the prescribed RSA unit group.
  2. Blind each client hash using a fresh invertible factor raised to the public exponent.
  3. The server applies its private exponent to the blinded value.
  4. The client divides out the factor and hashes the result into a comparison tag.
  5. Compare against server tags produced by the same mapping.

What to watch for

The source analyzes a restricted honest-but-curious setting using a one-more-RSA assumption and random oracles, not ordinary RSA hardness alone. Fixed server tags reveal changes across repeated sessions; this construction is not automatically an authorized or malicious-secure intersection protocol.

Papers

Offline and online costs of private intersection

Preprocessing moves work before an interactive request, reducing the latency or computation visible during the request. It does not remove that work from the total cost.

Why it is useful

It helps compare protocols for a weak client, a large server database or repeated use of an unchanged server set.

How it works

  1. Separate work depending only on server data and keys from work depending on client requests.
  2. Record client-specific work that can be done once the client input is known.
  3. Measure the remaining online operations and transmitted data.
  4. Account for rebuilding precomputed values after data, key or session changes.

What to watch for

The paper's experiments exclude precomputed operations and use historical parameters. Its lower online exponentiation count is not a claim of lower total cost or better performance on current systems.

Papers

Polynomial-root encoding for private intersection

A set can be represented by a polynomial having its elements as roots. Evaluating that polynomial at a candidate gives zero when the candidate is a set member, providing an algebraic route to private matching.

Why it is useful

Homomorphic encryption can hide the polynomial coefficients while allowing the other party to evaluate membership-related expressions.

How it works

  1. Encode the client elements as roots of a polynomial.
  2. Encrypt the coefficients using a suitable homomorphic scheme.
  3. Evaluate the encrypted polynomial at server elements.
  4. Randomize nonmatching results and return matching information through the intended output rule.

What to watch for

The zero-test and randomization arguments need the right algebraic domain. Over composite rings, nonzero values may fail to be invertible and products can vanish unexpectedly. This paper summarizes earlier protocols; their full primary proofs are not reconstructed here.

Papers

Private set intersection

Private set intersection lets parties identify the elements common to their private sets while limiting what they learn about the other elements. In the one-way version studied here, only the client receives the intersection.

Why it is useful

Two organizations can check for shared records without sending each other their complete lists in plaintext.

How it works

  1. Agree on how records are represented and what output is allowed.
  2. Run a protocol on the two private sets.
  3. Return matching elements to the designated recipient.
  4. Include permitted leakage, such as set-size bounds, in the security definition.

Example

For sets {red, green} and {green, blue}, a one-way intersection can reveal {green} to the client without revealing blue. Set sizes may still be exposed.

What to watch for

The output itself reveals membership for queried values. A party allowed to submit an entire guessable domain can learn more through legitimate queries; cryptographic privacy does not establish input authorization. Running a one-way protocol twice also does not guarantee fair delivery if a party aborts.

Papers

Private set intersection with data transfer

Private set intersection with data transfer releases associated records for matching items, rather than only identifying which set elements match.

Why it is useful

An authorized match can retrieve the corresponding database payload while unrelated payloads remain hidden.

How it works

  1. Generate matching per-item secret material through the intersection protocol.
  2. Derive a separate payload-encryption key from that material.
  3. The server encrypts each item's associated data.
  4. The client decrypts payloads for items whose matching secret material it obtained.

What to watch for

The source uses separate hash functions for comparison tags and payload keys and assumes chosen-plaintext-secure payload encryption. That argument does not by itself add integrity against active modification or establish a malicious-secure complete system.

Papers

PSImple

PSImple is a multiparty private set-intersection protocol.

Papers

VOLE-PSI

VOLE-PSI builds set intersection using a batched OPRF, Vector-OLE, and PaXoS.

Papers

Private union, difference and joins

Private union, difference, deduplication and relational joins, including multi-owner queries whose output leakage differs from intersection.

Prism private set operations

Prism uses secret sharing for intersection, union, and aggregate queries over outsourced multi-owner data.

Papers

Reactive and updatable private sets

Maintain private set computations over changing inputs, including delegated updates and repeated intersection. Single-execution privacy does not settle cross-query leakage.

Feather PSI

Feather supports delegated multiparty set intersection with updates.

Papers

Linkability across repeated private intersections

Repeated private intersections can reveal relationships between sessions even when each run hides individual unmatched records. Stable server tags let a client recognize recurring, added or removed opaque entries.

Why it is useful

It distinguishes privacy within one run from information revealed by comparing several runs.

How it works

  1. Identify which tags or public values remain stable between sessions.
  2. Compare the views available to a participant across time.
  3. If unlinkability is required, choose fresh session-dependent cryptographic material.
  4. Reassess preprocessing and synchronization when changing that material.

What to watch for

Seeing a tag change need not reveal the underlying record identity. The paper discusses rekeying and session-dependent hashing, but defers formal unlinkability proofs for several protocols; these discussions are not a universal multi-session privacy theorem.

Papers

RePSI

RePSI provides reactive private set intersection across evolving inputs.

Papers

Secure aggregation and private telemetry

Combine contributions without exposing individual inputs, using sharing, masking or encryption; includes dropout-tolerant aggregation and single-interaction collection. An exact aggregate can still leak individual information.

Bit-length bounds from Boolean shares

Each number in a client's update is written in binary and split bit by bit between the two servers, so each server holds bits that look random. Refusing any submission that uses more than a fixed number of bits per entry becomes a check on how large the entries can be.

Why it is useful

Arithmetic secret sharing, where a value is split into two shares that add up to it, makes adding updates free, but it gives no easy handle on size. Sharing bits lets the servers enforce a magnitude limit simply by counting the shares, which is the idea ELSA inherits from Prio+.

How it works

  1. The client clips its update to the public bound and writes each entry using w bits.
  2. It secret-shares those bits between the servers; over a ring of size two this is the same as arithmetic sharing, where two shares combine by exclusive-or.
  3. The servers reject any submission with more than w bit shares per entry, so surviving entries are at most a fixed magnitude.
  4. To keep computing, the servers convert the shared bits back into a shared number. The one step that needs interaction is multiplying two shared bits, because a shared exclusive-or equals the sum of the shares minus twice that product.

Example

With three bits per entry, magnitudes up to 7 are expressible. An entry of 8 would need a fourth bit, so the submission carrying it is rejected.

What to watch for

Counting bits bounds each entry, not the length of the whole vector, which is why this is combined with the separate norm check. Negative values need an extra shared sign bit and a secure selection step, which the paper treats in an appendix.

Useful background: Federated learning and gradient privacy.

Related ideas

  • Prio+: Collects aggregate statistics from client data shared as bits.

Papers

Clients as untrusted correlation dealers

The random correlated data that secure computation consumes, multiplication triples and oblivious transfer instances, is normally manufactured by the two servers through an expensive interactive protocol. ELSA instead has each client generate and secret-share the material the servers will need for that client's own update.

Why it is useful

Generating that material between servers was the dominant cost of the protocol. A client can sample the needed random values locally, subject to simple algebraic conditions, which moves work off the server-to-server channel and onto the client upload.

How it works

  1. For the norm computation the client prepares random triples: two random values together with their product, shared between the servers.
  2. For the bit conversions the client sends a special form of correlated oblivious transfer material, which the servers convert into the shape they need.
  3. Because clients may be malicious, the servers verify this material before using it.
  4. Clients that cannot afford the extra upload can opt out and let the servers generate that part on the fly, at the cost of more server work.

Example

Rather than the two servers interacting to create one multiplication triple, the client picks two random numbers, multiplies them on its own machine, and gives each server a share of all three values.

What to watch for

This is a trusted-dealer design in which the dealer is not trusted: correctness now depends entirely on the verification steps, and client uploads grow. The comparison numbers come from the paper's own implementation and benchmark setup, not from an independent run.

Useful background: Bit-length bounds from Boolean shares.

Related ideas

  • Additive secret sharing: Clients split each correlation between the two servers, so neither server alone learns the random values.

Papers

One-shot private aggregation

OPA aggregates client contributions through a single client interaction.

Papers

Sacrifice checks on client correlations

Two checks let the servers accept randomness that came from a possibly malicious client. Triples and square correlations, meaning a random value together with its square, are checked by spending one correlation to validate another. The transfer material is checked as one batch using a random linear combination.

Why it is useful

A malicious client could hand over material that is not what it claims, which would let its update pass a defense it should have failed. The checks make bad material survive only with small probability, at a cost far below generating the material interactively.

How it works

  1. The client sends candidate correlations in pairs, and the servers open a combination of one pair to test the algebraic relation.
  2. For triples this is the SPDZ sacrifice: one triple is consumed to statistically verify another.
  3. For squares the random challenge must be an odd number; the client's values are made over a slightly larger ring and the top bits are dropped after the check, so guessing succeeds only with probability controlled by a statistical security parameter.
  4. The transfer material is verified by combining all instances with random coefficients and testing the offset property, so the test does not grow with the number of instances.

Example

A client sharing the pair of a random value and its square lets the servers compute a shared square without interaction. The sacrifice check burns one such pair to confirm that another one is genuine.

What to watch for

These are probabilistic checks with a stated statistical security parameter, not a proof that the client's whole submission is well formed. The error bounds are the paper's lemmas about the verification steps alone.

Useful background: Clients as untrusted correlation dealers.

Papers

Private histograms and heavy hitters

Discover frequent values, histograms and sketches over distributed client data, with explicit candidate-discovery, verification and output-disclosure rules.

Doplar

Doplar changes the interaction pattern of Poplar-based distributed aggregation.

Papers

Poplar

Poplar computes heavy hitters from client-supplied strings using distributed data-collection servers.

Papers

Verifiable distributed aggregation

Validate hidden client contributions while computing aggregates, including VDAFs and proof-assisted input checks. Valid inputs alone do not prevent all poisoning or ensure differential privacy.

Prio

Prio aggregates client data through shares and client-input validation.

Papers

Prio3

Prio3 is a Prio-derived verifiable distributed aggregation construction.

Papers

Verifiable distributed aggregation functions

VDAFs combine distributed aggregation with validation of client contributions.

Papers

Secure statistics and data analysis

Compute statistical summaries, models or optimization results over protected data, including secure sampling, quantiles and linear algebra. Protecting inputs during computation is distinct from limiting output inference.

Prio+

Prio+ collects aggregate statistics using Boolean shares.

Papers

Differential privacy and cryptographic intersections

Differential privacy limits what a released statistic reveals about changing one individual's contribution. Noise calibration, repeated-query accounting and the definition of one individual's data are all part of the guarantee.

Composition of private releases

Several individually private releases disclose more than one release on its own. Composition tracks the privacy guarantee of the combined observations, including sequences whose later queries depend on earlier results.

Why it is useful

An analyst cannot reset the privacy cost merely by calling each release a separate query. Repeatedly averaging independently noised answers can reveal increasingly accurate information.

How it works

  1. Specify the complete sequence of releases.
  2. Establish each step's privacy bound, conditional on previous outputs when the sequence is adaptive.
  3. Apply the composition rule for the privacy notion being used.
  4. Compare the cumulative bound with the intended privacy budget.

What to watch for

Conditional guarantees matter: separate marginal guarantees alone do not justify arbitrary correlated randomization. Under the required composition conditions, zCDP rho parameters add.

Related ideas

Papers

Differential privacy

Differential privacy limits how much a released result can change in probability when one person's record changes. It protects participation in a statistical analysis while allowing useful population-level results.

Why it is useful

Even an aggregate can expose individuals when compared with other results. The guarantee concerns the complete randomized release procedure, rather than removing names from a table.

How it works

  1. Specify which two datasets count as neighbors, such as replacing one record.
  2. For every neighboring pair, compare the probabilities of every possible set of outputs.
  3. Bound the probability ratio by the parameter epsilon; approximate differential privacy also permits an additive slack delta.

Example

A noisy count should have similar output probabilities whether one particular record is included in the counted group or replaced by a record outside it.

What to watch for

The guarantee depends on the neighboring-dataset definition and chosen parameters. It does not promise that nothing can be inferred about a person, or that the raw database is protected from its operator.

Papers

Group privacy

Group privacy asks what happens when several records change together. A guarantee for one changed row becomes weaker as the group grows.

Why it is useful

One person may contribute several rows, or a question may concern an entire household. Row-level privacy and person-level privacy are therefore not interchangeable.

How it works

  1. Count the number of records that can change together.
  2. Connect the two datasets through single-record changes.
  3. Apply the group bound of the chosen privacy definition.
  4. Use the resulting weaker parameters when interpreting the guarantee.

What to watch for

For rho-zCDP, a group of k records has the bound k squared times rho. Approximate differential privacy has a different group behavior; the bounds cannot be interchanged.

Papers

Postprocessing of private outputs

A computation that uses only an already private output and public information cannot worsen its differential-privacy guarantee. The result can be rounded, plotted or otherwise transformed without consulting the private dataset again.

Why it is useful

A private release remains useful: downstream users can analyze it without charging a fresh privacy cost for every display or calculation.

How it works

  1. Obtain an output from the private mechanism.
  2. Apply a deterministic or independently randomized transformation using that output and public inputs.
  3. Retain the original privacy guarantee for the transformed result.

What to watch for

Accessing the raw dataset again is not postprocessing. The paper also distinguishes zCDP from mean-concentrated privacy, which does not retain identical parameters under arbitrary postprocessing.

Papers

Privacy loss random variable

Privacy loss measures how much one observed output favors one neighboring dataset over another. It is the logarithm of the ratio between the output's probabilities under those two datasets.

Why it is useful

Looking at its distribution helps account for rare revealing outcomes and for the accumulated effect of repeated releases.

How it works

  1. Fix an ordered pair of neighboring datasets.
  2. Run the randomized mechanism on the first dataset.
  3. For its observed output, divide the likelihood under the first dataset by the likelihood under the second.
  4. Take the logarithm of that ratio.

What to watch for

The value depends on the observed output and the ordered pair of datasets. It is not a numerical measure of everything an attacker knows about someone.

Papers

Gaussian mechanism

The Gaussian mechanism releases a numerical query answer with independent Gaussian noise added. Its privacy guarantee depends on the query sensitivity relative to the noise standard deviation.

Why it is useful

It supports approximate statistical answers and admits a particularly simple concentrated-privacy analysis.

How it works

  1. Compute the query with its established sensitivity bound.
  2. Sample Gaussian noise with the specified variance.
  3. Add the noise and release only the noisy result.
  4. Include the release in the cumulative privacy accounting.

What to watch for

Finite-precision sampling and every additional observable output need analysis in an implementation. Arbitrarily rounding or approximating a Gaussian sampler is not automatically equivalent to the mathematical mechanism.

Related ideas

Papers

Query sensitivity

Sensitivity bounds how much a query's exact answer can change between neighboring datasets. It determines how much random noise is needed for mechanisms calibrated to that change.

Why it is useful

A count and a sum of unbounded salaries have very different worst-case changes when one record changes. Using the same noise scale for both would not provide the same guarantee.

How it works

  1. Specify the neighboring-dataset relation.
  2. Bound the largest possible change in the query answer.
  3. For a vector of answers, use the norm required by the mechanism.
  4. Choose noise using that bound, not the observed variation in one dataset.

Example

For a fixed-size dataset, changing one row changes a count of rows with a property by at most one.

What to watch for

An unbounded contribution may give unbounded sensitivity. Any contribution limits must be enforced consistently and included in the definition of the query.

Papers

Zero-concentrated differential privacy

Zero-concentrated differential privacy, or zCDP, bounds how different the output distributions can be on neighboring datasets using Renyi divergence at every order greater than one. It gives strong bounds on large privacy-loss outcomes.

Why it is useful

The parameter rho adds cleanly across appropriately composed releases, giving a convenient way to account for repeated noisy analyses.

How it works

  1. Compare the mechanism's output distributions for every neighboring pair.
  2. Bound their order-alpha Renyi divergence by rho times alpha for every alpha greater than one.
  3. Combine the rho bounds for the full sequence of releases.
  4. When needed, convert the result to an epsilon-delta differential-privacy bound.

What to watch for

Zero refers to the zero intercept in this divergence bound, not zero privacy loss. zCDP is stronger than a guarantee at one fixed epsilon-delta pair and does not cover every approximately private mechanism.

Related ideas

  • Differential privacy: A rho-zCDP mechanism implies epsilon-delta privacy with epsilon = rho + 2 times the square root of rho times ln(1/delta), for 0 < delta < 1.

Papers

Approximate zero-concentrated differential privacy

Approximate zCDP allows a small exceptional probability in addition to a concentrated-privacy bound. Outside suitably chosen exceptional events, the neighboring output distributions satisfy the required Renyi-divergence bounds.

Why it is useful

This broader definition can account for mechanisms that concentrated privacy alone excludes and can combine different kinds of privacy guarantees.

How it works

  1. For each neighboring pair, bound the exceptional probability in both output distributions.
  2. Condition on the remaining events.
  3. Bound the divergence of the conditional distributions in both directions.
  4. Track both the exceptional probability and the concentrated-privacy parameters under composition.

What to watch for

It does not retain all the same group-privacy and lower-bound properties as ordinary zCDP. The exceptional events are part of a distributional definition, not a claim that each user is independently exposed with that probability.

Papers

Private training and inference

Cryptographic protection for training, inference, model evaluation and collaborative learning, including protected models and inputs. Federated placement of data alone is not a privacy guarantee.

SWIFT MPC

SWIFT supplies ring-based three-party computation for outsourced machine learning.

Papers

Federated learning privacy

Federated learning trains one shared model across devices or organizations that keep their data local. Each round, chosen clients send an update instead of their data, and the updates are averaged into the next model. Those updates can reveal information about local data, so privacy has to protect each client's update while the average becomes public.

Distributed trust between two servers

Instead of one central aggregator, the coordinating role is split between two servers run in separate trust domains. Each server receives a share of every client's update, and neither server can reconstruct an individual update on its own.

Why it is useful

A single aggregator must be trusted by every participant. Splitting the role means privacy survives as long as at least one of the two servers behaves, which is a weaker assumption than trusting one operator with everything.

How it works

  1. The application developer sets up two servers in separate trust domains, following the practice of already deployed systems.
  2. Both servers agree on the round's participants and broadcast the current global model, which each server holds in the clear.
  3. Clients send each server its share of their update.
  4. The servers run a protocol between themselves to check the defenses and add the shares, then reconstruct only the final aggregate.

Example

Two organizations in different jurisdictions each run one server. A client sends each of them a share that looks like random noise on its own; only the two servers together can process the update.

What to watch for

The guarantee rests on the assumption that the two servers are not compromised at the same time, and on the two domains being genuinely independent, which is an operational question the paper delegates to prior systems. Compared with a single-aggregator design based on a hard problem, distributed trust is a somewhat weaker notion of security.

Useful background: Federated learning and gradient privacy.

Related ideas

  • Prio+: A prior two-server design that shares client data as bits and only defends against a semi-honest server.

Papers

Federated learning and gradient privacy

Federated learning trains one shared model on data that never leaves the devices or organizations that own it. In each round, chosen clients train locally and send the coordinator an update, and the coordinator averages all updates into the next global model.

Why it is useful

Keeping raw data local is not yet privacy. The update a client sends is itself derived from that client's data, so the individual updates have to stay hidden while the average is the only value that becomes public.

How it works

  1. A coordinator holds the current global model and picks which clients take part in the round.
  2. Each chosen client trains the model on its own data for a few local epochs and produces a gradient update: a vector of suggested changes, one entry per model parameter.
  3. The coordinator averages the updates of the participating clients and installs the result as the new global model.
  4. In ELSA the coordinator's job is shared by two servers, and clients hand over secret shares of their updates rather than the updates themselves.

Example

Ten thousand phones each train on the photos stored on that phone. Every phone sends one vector of suggested changes, and the average of those vectors becomes the next version of the shared model.

What to watch for

Averaging many updates hides each one to a degree, not by itself. The paper treats the system as meaningful only when at least two honest clients take part, so the output does not trivially expose a single honest update.

Papers

Malicious privacy and its limits

Malicious privacy is the property ELSA proves: honest clients' updates stay private even when one server deliberately breaks the rules and colludes with malicious clients. Correctness of the output is deliberately not part of that guarantee.

Why it is useful

Full malicious security, privacy plus correctness, would force every client into a large multiparty computation. Splitting the two properties keeps the strong privacy claim while admitting that a corrupt server can ruin the result.

How it works

  1. State the threat model: corrupt clients are malicious, and at most one of the two servers is corrupt.
  2. If the corrupt server is semi-honest, it follows the protocol and only studies its transcript; privacy and correctness both hold.
  3. If the corrupt server is malicious, it may send arbitrary messages; privacy still holds, but neither the final aggregate nor the defense checks are guaranteed correct.
  4. Formally, privacy is defined like malicious security, but against a corruptible ideal functionality: the adversary learns what the function computes and then chooses what it outputs.

Example

With a semi-honest corrupt server the published average is the true average of the accepted updates. With a malicious one, the published number can be wrong, but the honest clients' updates are still hidden.

What to watch for

A malicious server can also censor clients by falsely reporting their inputs as malformed, so the protocol only opens the aggregate once a minimum number of gradients has been collected, and fairness, meaning every honest client's input is actually used, is not guaranteed.

Useful background: Distributed trust between two servers.

Papers

Norm defenses against boosted gradients

A malicious client can poison the model by sending an update scaled up far beyond what honest updates look like. ELSA filters these by checking a norm bound: the length of the update vector, computed from the sum of its squared entries, must stay under a public limit.

Why it is useful

The average is extremely sensitive to out-of-proportion values, and many model poisoning attacks rely on exactly that. A norm check is also simple enough to evaluate while the update is still split into secret shares.

How it works

  1. Fix the bound publicly before the round; choosing a good bound is a separate problem the paper leaves to prior work.
  2. While the update is shared, compute the sum of the squared entries of the client's vector.
  3. Compare that value with the bound and reveal only the comparison outcome, nothing else.
  4. Drop the client's update if the bound is violated.

Example

If honest updates have entries near 0.01 and one client sends entries near 1000, the average moves almost entirely in that client's chosen direction. A limit on the vector's length rejects it.

What to watch for

The protocols compute over finite rings, where numbers wrap around the modulus. A norm bound alone can therefore be defeated by overflow, so ELSA pairs it with a per-entry bit-length bound. No norm filter stops every poisoning attack; the paper calls the existing defenses heuristic.

Useful background: Federated learning and gradient privacy.

Papers

One-shot clients with distributed Fiat-Shamir

Verifying client-supplied randomness needs a random challenge that must stay hidden until the client has handed over its material, which would force the client to wait for a second round. ELSA derives that challenge from a hash of everything sent so far, so the client sends a single message.

Why it is useful

Clients on phones or other unreliable devices cannot be counted on to come back for a second exchange, and a single client message also removes the need for a separate coin-flipping protocol between the two servers.

How it works

  1. Cast the verification as a public-coin protocol: the clients are provers and the two servers together play the verifier.
  2. The Fiat-Shamir transform replaces the verifier's random challenge with a hash of the statement and the transcript so far, so the prover can compute it alone.
  3. Because the verifier here is a virtual party spread over two servers, the plain transform does not apply; ELSA uses the distributed variant, where each server hashes its own share into the challenge.
  4. The client submits its shares, its correlations and its transcript digest in one round.

Example

Instead of waiting for the servers to send a random challenge, the client computes the challenge as the hash of everything already sent, the same trick that turns an interactive identification protocol into a signature.

What to watch for

The argument for the transform lives in the random-oracle model. The servers still need several rounds between themselves, dominated by the secure comparison used to enforce the norm bound.

Useful background: Clients as untrusted correlation dealers, Sacrifice checks on client correlations.

Papers

Transcript emulation against a malicious server

To stop a malicious server from extracting information through malformed messages, each client computes the entire conversation the two servers should have while processing its own update, and sends a short digest of that conversation. The honest server compares the digest with what it actually observes.

Why it is useful

A malicious server can hide a probe inside an error. The paper's example is a message that only takes effect when the other server's secret bit is one, so the opened result leaks that bit. If the legitimate messages are predictable, any deviation becomes visible.

How it works

  1. Every per-client step, meaning verification, bit conversion, norm computation and norm enforcement, is run as its own instance for that client. Only the final aggregation mixes clients, and errors there are additive, so they appear in the output rather than leaking anyone's update.
  2. Knowing the servers' messages in advance does not help a malicious client cheat the defense, so the client loses nothing by predicting them.
  3. The client sends a hash digest instead of the full transcript, and the servers postpone opening the results of intermediate checks until the digest has been verified.
  4. If the digest does not match, the servers censor that client's input and continue; if too many clients are censored, the honest server aborts.

Example

The client works out what server A should say to server B at each step of handling its update, hashes that conversation, and sends the hash. If the live conversation differs, the honest server stops processing that client.

What to watch for

The digest must leave out messages that convey intermediate check results, and the security argument needs the server traffic before that point to look uniform. The paper reports the whole mechanism at 7 to 25 percent extra runtime over the semi-honest variant.

Useful background: Malicious privacy and its limits.

Papers

Machine-learning model privacy

Private machine learning asks what it costs to train or evaluate a model when the data is split into random shares, and what still leaks afterwards. This paper answers the cost side with shared arithmetic plus small circuits for non-linear steps, and it is explicit that the released model and the per-epoch training decisions remain observable.

A secure-computation-friendly activation function

Replace the logistic curve with a function that is flat at zero below minus one half, flat at one above one half, and a straight line in between: it equals one clipped linear unit subtracted from another.

Why it is useful

The logistic function needs a division and an exponentiation on real numbers, which neither arithmetic nor boolean circuits handle well. Low-degree polynomial stand-ins diverge on the tails, and an input far outside the training range then produces an output far outside the zero-to-one interval, wrecking the update step.

How it works

  1. Keep the two properties that matter: outputs stay between zero and one, and the function rises smoothly in the middle.
  2. Build it from two shifted clipped linear units, each needing only a sign test, which a small garbled circuit supplies.
  3. Apply the same substitution at the output layer: replace each exponential with a clipped linear unit, add the results, and divide each by the total with one division circuit so the outputs still form a probability distribution.

Example

For an input of 3 the function returns 1; for -3 it returns 0; for 0.1 it returns 0.6, exactly the middle line x plus one half.

What to watch for

The replacement is an engineering choice validated by experiments, not a proof that the substitution is always safe: in the neural-network experiment accuracy drops from 94.5 percent with the true softmax to 93.4 percent with the replacement, and for logistic regression a degree-three polynomial collapses to 42 percent. The authors themselves call for more work on such functions.

Useful background: Stochastic gradient descent inside secure computation.

Related ideas

Papers

Generating multiplication triplets offline

Two ways for the servers to build the shared triplets before any data arrives: homomorphic encryption that is light on communication, or oblivious transfer that is fast but chatty; clients can also deal the triplets directly.

Why it is useful

The offline phase dominates the total cost, so its design decides whether the system is usable. The two server-only options trade computation against communication, and the client-aided option removes cryptography altogether at the price of a weaker trust assumption.

How it works

  1. Homomorphic route: one server encrypts its share of the vector, the other multiplies the ciphertexts together, masks the result and sends it back for decryption; the decryptor learns only a masked value.
  2. Transfer route: the bits of one share select correlated messages derived from the other share, so each party ends with a piece of the product.
  3. Both routes exploit the matrix shape, so one selection bit masks a whole row of values instead of one element; the paper reports the transfer route getting about four times faster and the encryption route 41 to 66 times faster from this alone.
  4. Client-aided route: since owners already share their data, they also share triplets for it, which needs no cryptography but forbids any collusion between a server and a client.

What to watch for

The encrypted route is slow per operation; the transfer route moves tens of gigabytes for datasets of tens of megabytes and suffers on slow networks. The client-aided route is the fastest but changes who must be trusted, and it forces the online phase back to independent inner products.

Useful background: Matrix multiplication triplets, Oblivious transfer extension.

Related ideas

Papers

Leakage and limits of the security model

What the proof actually guarantees: privacy against one honest-but-curious server, with no protection once the model is published, and small extra leaks from the training decisions themselves.

Why it is useful

A reader who stops at the word secure may miss that the activations never leak here but other things do: the learning-rate and stopping decisions each reveal one bit per epoch, published predictions are rounded because exact values reveal more about the input, and the final model can still memorize training data.

How it works

  1. The adversary model is semi-honest: a follower of the protocol that tries to learn from its view. Deviating parties are out of scope.
  2. One server plus any set of clients may be corrupt; the second server must stay honest. Clients colluding with clients or with a server is allowed in the standard setting.
  3. To adjust the learning rate or stop, the servers test shared accuracy after each epoch; each such decision is a public bit, traded against fewer epochs.
  4. In the client-aided variant, a colluding client and server can reconstruct a round’s coefficient vector, so that variant forbids server-client collusion entirely.
  5. To protect the published model itself, the paper notes the servers can add differential-privacy noise to the shared updates; this is sketched as a composition, not implemented or measured.

What to watch for

Non-collusion is an assumption about organizations, not a cryptographic property, and it is the single point of failure. The guarantees are also not comparable to systems that share model updates in the clear, whose leakage the paper reports as unquantified.

Useful background: Two-server model for private machine learning, Private neural network training.

Related ideas

Papers

Matrix multiplication triplets

One random matrix shared by both servers masks a whole block of data at once, and the matching triplet for the whole matrix product is prepared in advance.

Why it is useful

A naive reading of triplet multiplication needs one fresh random triple per scalar product, which wastes both randomness and bandwidth. Plain-text training gets its speed from matrix operations, and this construction keeps that speed under sharing.

How it works

  1. Agree the sequence of mini-batches in advance; this needs only the data dimensions, not the data itself.
  2. Prepare shared random matrices U, V and Z with Z equal to the matrix product of U and V, sized so U masks the whole data matrix once.
  3. Open the masked data E once at the start of training; afterwards every iteration just selects rows of E.
  4. Because the mask is opened once and the rest of the computation is local, reusing one mask across epochs leaks nothing.

What to watch for

The saving depends on agreeing the batch schedule before seeing the data, and on masking each element with the same randomness through all epochs. The paper argues safety from its simulation proof rather than from a general masking rule.

Useful background: Truncation for shared decimal numbers.

Related ideas

  • Beaver triples: The scalar case that the matrix version generalizes.

Papers

Private neural network training

Extending the shared gradient-descent machinery to layered networks: matrix products per layer in arithmetic sharing, clipped linear units evaluated by a tiny circuit, and the same replacement at the output layer.

Why it is useful

It was the first implemented system for training a neural network on secret-shared data, and it shows where the cost of private training actually sits: almost entirely in the non-linear parts.

How it works

  1. Treat each neuron as a regression: forward propagation is a chain of shared matrix products, one per layer.
  2. For each neuron output, one small garbled circuit adds the two shares and returns the sign bit; the function value and its derivative come out of the same evaluation, the derivative feeding the backward pass.
  3. Keep every layer’s values shared; only the final model is opened.
  4. If the circuits dominate, swap the clipped linear unit for squaring, which turns a circuit into one shared multiplication at the cost of more triplets and slightly lower accuracy.

What to watch for

The circuits for the non-linear units dominate the online time, and the offline triplet cost grows with the number of neurons. Training a small three-layer, 266-neuron network took the authors about 21,000 seconds in total, and they state that wide-area training of this size is not yet practical.

Useful background: Switching between arithmetic and garbled sharing, Truncation for shared decimal numbers.

Related ideas

Papers

Stochastic gradient descent inside secure computation

Training by repeated small updates on random mini-batches, rather than by solving one big system of equations, so that the secure computation only has to add and multiply.

Why it is useful

Earlier private linear-regression systems built a matrix product and then solved the resulting linear system inside a garbled circuit, using the Cholesky algorithm or a variant of it. That circuit depends on the number of features, does not shrink with more data, and cannot be extended to models with non-linear activation functions. Gradient descent only needs the arithmetic that secret sharing already supports cheaply.

How it works

  1. Pick a mini-batch of samples and compute the predicted outputs (forward propagation) as a matrix-vector product.
  2. Compare predictions with labels and push the difference back through the same products to get the update (backward propagation).
  3. Scale the update by a learning rate divided by the batch size, chosen as a power of two so the scaling becomes a bit shift.
  4. Repeat over shuffled epochs until accuracy stops improving; each step uses only additions, multiplications and truncations on shared values.

What to watch for

Gradient descent changes the model a little at a time, so approximate arithmetic is tolerable here while it would break an exact linear-system solver. On the three datasets tested, the models it produces score within about a percentage point of the linear-system solutions.

Useful background: Two-server model for private machine learning.

Related ideas

  • Beaver triples: The tool that makes shared multiplication cheap enough for thousands of iterations.

Papers

Switching between arithmetic and garbled sharing

Keep the bulk of the training in arithmetic sharing, and convert to garbled-circuit sharing only for the one comparison an activation needs, then convert straight back.

Why it is useful

A garbled circuit is good at bit-level tests and bad at long chains of multiplications, while arithmetic sharing is the opposite. Mixing them means each part of the computation runs in the representation that suits it.

How it works

  1. Finish the shared inner product, then feed both servers’ shares of the value into a garbled circuit.
  2. The circuit adds the shares and reports only the sign bits; the rest of the function is left outside the circuit because it would cost a linear number of AND gates.
  3. Convert the garbled output to boolean sharing using the permutation bits, which costs nothing.
  4. Use a couple of oblivious transfers to fold the boolean bits back into arithmetic shares of the activation output, and continue in arithmetic sharing.

What to watch for

The conversion is customized to this computation; a general mixed-protocol framework would pay more rounds and more transfers. Each activation still costs one extra interaction per iteration, which is what makes wide-area training expensive.

Useful background: A secure-computation-friendly activation function, Yao garbled circuits.

Related ideas

Papers

Truncation for shared decimal numbers

Represent decimals as integers with a fixed number of fractional bits, multiply as integers, then have each server chop low bits off its own share of the product.

Why it is useful

Exact fixed-point multiplication on shared values normally needs a boolean circuit with a number of gates quadratic in the bit length, once per multiplication, and training needs millions of them. Truncating shares separately needs no interaction at all.

How it works

  1. Scale each decimal so the fractional part becomes an integer number of bits, for example 0.75 becomes 12 with four fractional bits.
  2. Multiply the scaled integers with multiplication triplets; the product now has twice as many fractional bits.
  3. Each server drops the low bits of its own share; the two shortened shares still add up to nearly the right value.
  4. The reconstruction can be off by one unit in the last fractional bit, with a probability that shrinks as the field grows; the paper bounds it and reports no failure in its runs.

Example

With four fractional bits, 0.75 and 0.5 are stored as 12 and 8; the product 96 is truncated to 6, which reads back as 0.375, the exact answer here.

What to watch for

The error is one bit of the fractional part with small probability, not an exact result. Coarse quantization shows up in practice: with only six fractional bits the training accuracy oscillates because each error pushes the model off course, while thirteen bits tracks plaintext training closely.

Useful background: Stochastic gradient descent inside secure computation, Beaver triples.

Related ideas

  • Beaver triples: Integer multiplication of the scaled values before truncation.

Papers

Encryption with access rules

Sometimes a single public key is not enough to describe who may read a message. These encryption methods attach conditions to access, or let a key reveal only a particular function of protected data.

GLUE ABE

GLUE supports unbounded attribute universes, policy negations, and online/offline ABE processing.

Papers

Inversion-based Boneh-Boyen IBE

This Boneh-Boyen IBE variant uses an exponent-inversion construction.

Papers

SK-IBE

SK-IBE applies the Fujisaki-Okamoto transformation to a simplified Sakai-Kasahara construction.

Papers

Spatial encryption

Spatial encryption encodes decryption relationships with affine spaces.

Papers

Access-encryption security and construction methods

Selective and adaptive identity or policy security, collusion, function privacy and proof techniques such as dual-system hybrids and pair encodings. A proof method is not an encryption interface.

Collusion resistance in attribute-based encryption

Collusion resistance prevents several keys that each lack permission from being combined to decrypt a protected ciphertext. Authorization is evaluated for each key, not by freely mixing its components with those from other keys.

Why it is useful

Ordinary secret sharing is designed to let participants combine shares. Attribute-based encryption instead needs to stop unauthorized combinations across independently issued keys.

How it works

  1. Allow an attacker to obtain several keys whose policies do not authorize the target.
  2. Let it pool and process all their components.
  3. Require the target plaintext to remain hidden despite this pooling.

What to watch for

This cannot stop a holder of an authorized key from sharing the plaintext or that key. It also does not mean that the union of rights already held must disappear when keys are combined.

Papers

Dual system encryption

Dual system encryption uses semi-functional keys and ciphertexts in encryption proof hybrids.

Papers

Game-based security for functional encryption

The game-based definition is an indistinguishability test. An attacker collects secret keys of its own choosing, then tries to tell which of two plaintexts was encrypted.

Why it is useful

It generalizes the semantic security game for public-key encryption, but the freedom to ask for keys creates a problem the older game does not have: the two challenge plaintexts must be indistinguishable even after the attacker decrypts them with every key it holds.

How it works

  1. Let the attacker adaptively request secret keys for any key descriptions it wants.
  2. Require the two challenge plaintexts to produce identical outputs under every function for which the attacker holds a key, since otherwise it could simply decrypt and compare.
  3. Note that this restriction forces equal plaintext lengths, because the empty key reveals the length.
  4. Hand over the encryption of one of the two plaintexts, allow further key requests under the same restriction, and require the final guess to be only negligibly better than chance.

What to watch for

The restriction is what makes the definition satisfiable, and it is also where it becomes too weak for some functionalities. Any functionality whose key space has only polynomially many keys can be met by encrypting every function output under its own public key, at a cost proportional to that number of keys, and only if the lengths of those outputs are already part of what the empty key reveals.

Useful background: Functionality and the empty key.

Papers

Pair encodings

Pair encodings describe algebraic key and ciphertext components for predicate-encryption constructions.

Papers

Selective-set security for attribute-based encryption

Selective-set security requires an attacker to choose the challenge attribute set before seeing the system's public parameters. It may then obtain keys that do not authorize that set and try to distinguish which message was encrypted.

Why it is useful

The timing restriction lets the proof construct public parameters around a known challenge set.

How it works

  1. Commit to the challenge attributes before setup.
  2. Receive public parameters and request permitted non-authorizing keys.
  3. Choose two equal-length messages.
  4. Try to identify which message was encrypted under the committed attributes.

What to watch for

Adaptive choice of the challenge attributes after setup is a stronger requirement. A proof in the selective-set, chosen-plaintext game does not by itself establish chosen-ciphertext security.

Papers

Simulation-based security for functional encryption

The simulation-based definition asks for a simulator that reproduces everything an attacker sees using only the function outputs the attacker is allowed to learn. If such a simulator exists, the ciphertext and the keys together leak nothing beyond those outputs.

Why it is useful

It is the definition that rejects the leaking scheme from the previous lesson, and it matches the intuition that a key should reveal only its own function value and nothing more.

How it works

  1. Run the real system and record the public parameters, the challenge plaintexts, the ciphertexts and the final output of the attacker.
  2. In the ideal world, let a simulator produce a matching view without ever seeing the plaintexts, asking only for the permitted function outputs.
  3. Require the real and the ideal views to be computationally indistinguishable.
  4. For a functionality with a small key space, masking each function output with a random oracle value gives a scheme that meets this definition in the random oracle model.
  5. For public-index schemes, a game-secure system can be converted into a simulation-secure one by encrypting a random pad and using the oracle to define the mask that later recovers the payload.

What to watch for

The definition cannot be met without idealized tools. A random oracle is an idealized public random function that proofs treat as freely queryable; the paper shows that even for identity-based encryption no scheme is simulation-secure when the simulator may only query the same random oracle as the attacker and not program its answers. The obstacle is the same one that makes non-interactive non-committing encryption impossible, where a ciphertext cannot stay explainable as an encryption of either of several messages once more information arrives. Every positive statement therefore lives in the stronger, programmable random oracle model.

Useful background: Why the game-based definition is insufficient, Random oracle model.

Papers

Why the game-based definition is insufficient

For some functionalities a scheme can pass the game and still hand the attacker the entire plaintext. The paper builds such a scheme for a functionality whose only key is the empty key and whose output is a one-way permutation of the plaintext, meaning an operation that is easy to compute in one direction and believed hard to undo.

Why it is useful

It shows that the game compares function values only as information, and ignores applications whose security also rests on the function being hard to invert.

How it works

  1. Take a functionality that outputs a one-way permutation applied to the plaintext under the empty key; the honest scheme simply publishes that permutation of the plaintext.
  2. Build instead the scheme that publishes the plaintext itself, which releases strictly more than the functionality asks for.
  3. Check the game: two challenge plaintexts are allowed only when the functionality gives the same output on both, and a permutation gives the same output only when the two plaintexts are equal.
  4. So the challenge becomes trivial and the leaking scheme passes, while a real attacker recovers every plaintext without ever inverting the permutation.
  5. The same trick survives with one non-trivial key by wrapping the released value in an ordinary public-key encryption.

What to watch for

This is a statement about definitional strength, not about a broken deployed system. The paper is careful to add that for predicate encryption with a public index the game-based definition is adequate.

Useful background: Game-based security for functional encryption, One-way permutation.

Papers

Attribute and predicate access control

Encrypt messages under attribute or predicate conditions, with explicit policy location, privacy and authority structure. Releasing a computed value is classified under functional encryption.

FAME

FAME provides pairing-based key-policy and ciphertext-policy ABE constructions.

Papers

Large-universe attribute-based encryption

A large-universe construction permits attribute names beyond a fixed list enumerated at setup. The paper's variant derives attribute components from a public function and can map strings into attribute values.

Why it is useful

New descriptive labels need not force a complete regeneration of public parameters.

How it works

  1. Set up the public attribute-encoding function.
  2. Map each attribute to the construction's allowed value space.
  3. Derive the matching encryption and key components from that value.
  4. Respect the construction's bounds on attribute-set size.

What to watch for

Large universe does not mean unlimited attributes in one ciphertext. The standard-model variant fixes a size bound; the paper separately discusses a random-oracle alternative.

Related ideas

  • GPSW ABE: Includes a large-universe variant with different key components.

Papers

Predicate encryption as a sub-class

Predicate encryption is the sub-class of functional encryption in which the plaintext is a pair: an index that describes the data and a payload message that stays hidden. A key carries a predicate, and decryption returns the payload exactly when the predicate accepts the index.

Why it is useful

Most systems built before this paper fit this shape, and the shape splits privacy into two levels that are worth telling apart: systems where anyone can read the index, and systems where the index is secret as well.

How it works

  1. Split the plaintext into an index and a payload message.
  2. Define a predicate that outputs one bit for each key description and each index.
  3. Set the functionality to return the payload when the predicate accepts, and a rejection symbol otherwise.
  4. In the public-index variant the empty key returns the index together with the payload length, so the index travels in the clear inside the ciphertext.
  5. In the hidden-index variant the empty key returns only the payload length, which is what anonymous identity-based encryption does, so the index stays hidden from everyone without the matching key.

Example

Illustration: an email system where the index is the sender name and the payload is the body; a key for a sender pattern recovers only the bodies whose index matches that pattern.

What to watch for

A hidden index is a strictly stronger requirement, and public-index systems cannot compute on the encrypted data, they only gate the release of one payload. Hidden vector encryption, where a key holds a pattern with wildcards that is matched against a vector in the ciphertext, is one hidden-index example.

Useful background: Functionality and the empty key.

Papers

Key-policy and ciphertext-policy encryption

Attribute-based encryption connects decryption rights to descriptive labels and policies. Key-policy and ciphertext-policy encryption place those two ingredients on opposite sides of the key-ciphertext relationship.

Access structures as LSSS matrices

The policy is written as a monotone access structure, and then compiled into a linear secret-sharing matrix whose rows are labeled with attributes.

Why it is useful

A single algebraic object then describes any monotone formula, so encryption, decryption, and the security proof can all reason about one matrix instead of a tree.

How it works

  1. Read the parties of a secret-sharing scheme as attributes; the authorized sets of attributes are exactly the key sets that may decrypt.
  2. Convert any monotone boolean formula or binary access tree into a share-generating matrix M with one row per node.
  3. A satisfying set of rows spans the target vector (1, 0, ..., 0); an unsatisfying set leaves a separating vector w orthogonal to all its rows.

What to watch for

Only monotone structures are native. Negation ("NOT Student") can be faked by doubling the attribute universe, which the paper itself calls inefficient.

Useful background: Ciphertext-policy versus key-policy encryption.

Related ideas

  • Access structures and linear sharing: the underlying sharing theory

Papers

Attribute sets in decryption keys

A decryption key is issued for a plain set of attributes and is randomized by one fresh exponent t shared by all of its components.

Why it is useful

The shared randomization is the anti-collusion device: two users pooling key components cannot line up their exponents, so mixed keys cancel to garbage instead of decrypting.

How it works

  1. The authority holds a master key and issues one private key per attribute set S.
  2. Each key picks one random t and builds every component from that same t.
  3. During decryption every share is multiplied by this t in the exponent, so shares only recombine inside the single key they came from.

What to watch for

Collusion resistance holds only against combining whole keys from this authority; the master key holder can decrypt everything, so the authority is fully trusted.

Useful background: Ciphertext-policy versus key-policy encryption.

Papers

Attribute-based encryption as functionalities

Attribute-based encryption replaces the equality predicate with a boolean formula over attributes. In key-policy systems the key holds the formula and the ciphertext holds the attribute values; in ciphertext-policy systems the two swap places.

Why it is useful

Formulas express conjunctions, disjunctions and other access rules, which is what fine-grained access control needs. Writing both variants as the same kind of predicate shows that they differ only in which side stores the formula.

How it works

  1. Fix a number of boolean variables.
  2. For key-policy encryption, let keys be formulas over those variables and let the ciphertext index be the list of their values; decryption succeeds when the formula evaluates to true.
  3. For ciphertext-policy encryption, let keys be value lists and let the ciphertext index be the formula; the same evaluation rule decides decryption.
  4. Read the empty key as before: it exposes the index, so in one variant the formula is public and in the other the attribute values are public.

Example

Illustration: a key for the formula "department is security AND level above three" opens exactly those ciphertexts whose attribute values make the formula true.

What to watch for

The paper restricts its description to boolean formulas for simplicity and notes that the underlying constructions also handle threshold gates and monotone span programs, which are a linear-algebra way of describing the same kinds of policies. Which side carries the policy decides what an eavesdropper can read off a ciphertext without any key.

Useful background: Predicate encryption as a sub-class.

Papers

Ciphertext-policy ABE

Ciphertext-policy attribute-based encryption places the access rule in the ciphertext and associates attributes with the recipient's key. This reverses where the policy is stored in key-policy encryption.

Why it is useful

The sender can state which attribute combinations are allowed to read a particular message.

How it works

  1. An authority issues attribute-bearing decryption keys.
  2. The encryptor selects a policy for the ciphertext.
  3. Decryption succeeds for keys whose attributes satisfy the policy.

What to watch for

This paper explains the distinction but leaves its general ciphertext-policy construction as future work. Its key-policy algorithm cannot be converted just by swapping labels.

Related ideas

Papers

Ciphertext-policy versus key-policy encryption

Two ways of attaching an access policy in attribute-based encryption: to the user key (key-policy) or to the ciphertext (ciphertext-policy). This paper builds the ciphertext-policy side.

Why it is useful

Ordinary public-key encryption targets one known recipient. In attribute-based encryption the sender instead states a rule, and anyone whose credentials fit the rule can decrypt.

How it works

  1. In key-policy ABE the ciphertext is labeled with attributes and the user key carries the formula that decides which ciphertexts it may open.
  2. In ciphertext-policy ABE the roles swap: the key carries the attribute set and each ciphertext carries the formula chosen by its encryptor.
  3. Key-policy ABE with expressive formulas existed from 2004-2006 work; an equally expressive ciphertext-policy scheme with a standard proof was left open.

Example

A hospital file encrypted under (Cardiologist AND Night-Shift) is ciphertext-policy; the same rule baked into a doctor’s key is key-policy.

What to watch for

The two flavors are not interchangeable in practice: ciphertext-policy matches how a data owner thinks ("who may read this file"), while key-policy matches how an authority issues standing permissions.

Related ideas

  • Identity-based encryption: simpler ancestor with one attribute

Papers

Easy-ABE

Easy-ABE is a ciphertext-policy attribute-based encryption construction.

Papers

FABEO

FABEO provides pairing-based key-policy and ciphertext-policy ABE constructions.

Papers

Fixed universe, monotone policies, and extensions

What the main system does not do out of the box, and the paper’s own remedies: hashing for large universes, attribute deletion for delegation, and a transform for chosen-ciphertext security.

Why it is useful

These boundaries decide whether the scheme fits a real deployment, where new attribute names appear over time and users hand narrowed keys to assistants.

How it works

  1. The public parameters enumerate the attribute universe at setup, so new attributes cost new parameters.
  2. Hashing attribute strings in the random-oracle model gives constant-size parameters for any string as an attribute; a standard-model variant instead grows parameters with a per-key attribute bound.
  3. Delegation removes key components and re-randomizes the rest, shrinking the attribute set a key carries.
  4. Chosen-ciphertext security follows by applying the Canetti-Halevi-Katz transformation on top of delegation.

What to watch for

Each remedy imports its own price: a random oracle, or parameter growth; the base scheme also remains monotone and selectively secure.

Useful background: Ciphertext-policy versus key-policy encryption, Trading efficiency for weaker assumptions.

Papers

Fuzzy IBE

Fuzzy IBE bases decryption eligibility on overlap between identity attributes.

Papers

Key-policy ABE

Key-policy attribute-based encryption labels each ciphertext with descriptive attributes and puts the access rule in a decryption key. A key can decrypt when the ciphertext's attributes satisfy that rule.

Why it is useful

A recipient can receive permission to read a selected class of encrypted records without being given the authority's master secret or every other record's contents.

How it works

  1. An authority creates public parameters and a master secret.
  2. An encryptor labels a message with attributes and encrypts using the public parameters.
  3. The authority issues a key containing the permitted access rule.
  4. The recipient decrypts only when the attributes satisfy that rule.

Example

A key for project-A AND year-2024 opens records labeled with both attributes, but not a project-B record.

What to watch for

The authority controls key issuance. The construction here reveals ciphertext attributes and does not automatically provide revocation, authenticity or protection against an authorized reader redistributing plaintext.

Papers

GPSW ABE

The GPSW construction combines secret sharing over an access policy with bilinear pairings. A satisfying set of ciphertext attributes lets one decryption key reconstruct a group-valued mask and remove it from the message.

Why it is useful

It enforces richer policies than a single attribute-overlap threshold while resisting the pooling of incompatible keys.

How it works

  1. Share the authority's secret down the policy tree using fresh polynomials during key generation.
  2. Encode leaf shares in secret key components tied to their attributes.
  3. Encrypt with a fresh random exponent and public components for the ciphertext attributes.
  4. Pair matching leaf components and interpolate up satisfied gates.
  5. Remove the reconstructed mask to recover the message.

What to watch for

The paper proves selective-set, chosen-plaintext security under its bilinear assumption. This is not automatically adaptive or chosen-ciphertext security. The small- and large-universe variants have different parameters and key components.

Papers

Programming the challenge matrix into the public parameters

The proof technique that makes standard-model CP-ABE possible: the reduction embeds the entire challenge access matrix into the public key before the adversary starts.

Why it is useful

Earlier proofs could treat each challenge attribute as simply present or absent, but a challenge policy is much larger than the parameter list and may repeat attributes, so there is no on/off switch to flip.

How it works

  1. The simulator receives the committed challenge matrix and folds each row of it into the group element for the attribute labeling that row.
  2. Repeated attributes are handled by using distinct terms of the parallel BDHE assumption to program several rows into one element without conflict.
  3. Key queries are answered with a separating vector, guaranteed by the target-vector convention, and the challenge ciphertext is assembled around the unknown pairing value.

What to watch for

The embedding is why the strongest assumption is needed: programming an arbitrary matrix with repeated labels costs assumption terms, and weaker assumptions force the padded variants of the next lesson.

Useful background: Access structures as LSSS matrices, The selective security game for CP-ABE.

Papers

Sharing the encryption exponent across a policy

Encryption hides the message under one random exponent s, splits s into shares along the rows of the policy matrix, and packages each share with one attribute.

Why it is useful

Decryption becomes linear algebra: a user whose attributes label a satisfying set of rows multiplies the matching ciphertext pieces in the pairing, the shares and the key randomness cancel, and e(g, g) to the alpha times s falls out.

How it works

  1. Choose a random vector whose first entry is s; the matrix times this vector gives one share per row.
  2. Blind each share with its own fresh randomizer and attach the attribute labeling that row.
  3. A decryptor finds reconstruction weights for the rows its attributes cover, pairs and multiplies, then divides the recovered value out of the ciphertext header.

What to watch for

Cost tracks the policy, not the user list: ciphertext size and encryption and decryption time grow linearly with the formula, and decryption work depends on how many nodes the user actually satisfies.

Useful background: Access structures as LSSS matrices, Attribute sets in decryption keys.

Papers

The selective security game for CP-ABE

A chosen-plaintext game in which the adversary may request any keys whose attribute sets fail the challenge policy, then must tell which of two messages was encrypted.

Why it is useful

Granting those key requests is what makes collusion attacks legal in the model; forbidding keys that would satisfy the challenge is what keeps the game winnable at all.

How it works

  1. The adversary asks for private keys for arbitrary attribute sets throughout the game.
  2. It then names a challenge policy and two equal-length messages; the challenger encrypts one of them.
  3. Further key requests are allowed only for sets that do not satisfy the challenge policy.
  4. The adversary wins by guessing the encrypted message with advantage beyond one half.

What to watch for

All constructions here are selective: the adversary must commit to the challenge policy before seeing the public parameters, a weaker guarantee than full adaptive security. Chosen-ciphertext attacks are noted as an extension, not proven for the base schemes.

Useful background: Ciphertext-policy versus key-policy encryption.

Related ideas

  • Access-encryption security and construction methods: the surrounding proof landscape

Papers

TinyABE

TinyABE is a ciphertext-policy ABE construction configured for embedded-device use.

Papers

Trading efficiency for weaker assumptions

Three constructions on one framework: fastest under q-parallel BDHE, then variants under decisional BDHE and finally plain decisional BDH, each paying in size.

Why it is useful

Assumption strength is a cost like any other; the paper prices it explicitly so a deployer can choose between a strong tailored assumption and a standard one.

How it works

  1. The main system keeps O(n) ciphertexts and O(A) keys but rests on decisional q-parallel BDHE.
  2. The BDHE variant restricts each attribute to one policy row and relabels repeats as fresh strings, so keys grow by a factor kmax.
  3. The BDH variant fixes a maximum number of policy columns nmax at setup and pads every policy out to it, growing parameters by that factor.

Example

A policy that uses "Professor" twice would need the strings Professor:1 and Professor:2 in the BDHE variant.

What to watch for

None of the three is free: q must bound the challenge matrix dimensions, kmax caps attribute reuse, and nmax caps policy width, so each guarantee is conditioned on a pre-declared bound.

Useful background: The selective security game for CP-ABE, Programming the challenge matrix into the public parameters.

Papers

Multi-authority, decentralized and registered access keys

Attribute issuance and public-key registration across authorities or users, including collusion and authority trust boundaries. Registered keys do not imply threshold issuance.

Multi-authority ABE

Multi-authority ABE distributes attribute-key issuance across authorities.

Papers

Registered ABE

Registered ABE lets users create keys and register public keys with their attributes.

Papers

Predicate matching and hidden attributes or policies

Predicate-controlled decryption and privacy of attributes, identities, predicates or access policies. Inner-product predicates gate message recovery rather than reveal the numerical inner product.

FABESA

FABESA includes key-policy and ciphertext-policy ABE variants with attribute-anonymous forms.

Papers

Hidden vector encryption

Hidden vector encryption matches vector attributes against patterns containing wildcards.

Papers

Inner-product predicate encryption

Inner-product predicate encryption gates message decryption on an inner-product relation.

Papers

Functional decryption and output control

Functional decryption means a key releases a selected function of an encrypted input rather than the whole plaintext. Reading this family means keeping three things apart: the functionality, which says what may be learned; the scheme, which implements it; and the security definition, which says what leaking nothing else should mean. This paper argues that the last part is the hard one, because a natural game can be satisfied by schemes that hand out the plaintext.

DFA-based functional encryption

DFA-based encryption associates decryption with automaton acceptance of an encrypted string.

Papers

Functional encryption

Functional encryption is an encryption system in which a decryption key releases a chosen function of the plaintext instead of the whole plaintext. A trusted authority keeps a master secret key and hands out these restricted keys, so different readers can learn different things from the same ciphertext.

Why it is useful

Ordinary public-key encryption is all or nothing: the one holder of the secret key reads everything and everyone else learns only the length of the data. Cloud storage, searching over encrypted data and policy-based sharing all need partial access, which that older model cannot express.

How it works

  1. Start from public-key encryption, where a single secret key uncovers the entire message.
  2. Replace the single full-power key with many restricted keys, each tied to a description of a function.
  3. Let an authority holding a master secret key derive a restricted key whenever a user is authorized to see that function.
  4. Decrypt with a restricted key and obtain the value of that function on the hidden plaintext, and nothing else.

Example

Illustration: a cloud stores encrypted photos and is given a key that returns each photo blurred everywhere except one face, so the unblurred original never leaves encryption.

What to watch for

The paper defines the concept and studies how to define its security; it does not give a scheme for every function. Its motivating examples, such as a blurred image or a search for one face, describe goals rather than constructions it builds.

Useful background: Public-key encryption.

Papers

Functionality and the empty key

A functionality is the mathematical object a functional encryption scheme serves. It is a deterministic function that takes a key description from a key space and a plaintext from a plaintext space, and returns a string. The scheme itself is four algorithms: setup, keygen, enc and dec.

Why it is useful

Separating the functionality from the scheme lets one definition cover identity-based, attribute-based and searchable encryption at once, so that security can be stated for the functionality instead of separately for every system.

How it works

  1. Write down the key space and the plaintext space the system will use.
  2. Define the functionality as a deterministic program; each key description selects which function of the plaintext the matching secret key computes.
  3. Run setup to produce public parameters together with a master secret key.
  4. Derive a secret key for a chosen key description with keygen, encrypt a plaintext with enc, and let dec return the function value; correctness requires that it always does.
  5. Include one special key, called the empty key, that everyone can evaluate without holding any secret key.

Example

Ordinary public-key encryption is the functionality whose key space holds two keys: the full key returns the plaintext itself and the empty key returns only its length.

What to watch for

The functionality is a deterministic machine, so the permitted outputs are fixed functions of the plaintext, and the syntax by itself says nothing about security. The key and plaintext spaces may also depend on values that setup itself produces, such as a modulus or a prime.

Useful background: Functional encryption.

Papers

Open problems in functional encryption

The paper ends with the questions it could not settle: build functional encryption for all polynomial-time functionalities, realize useful complex functionalities such as releasing a fitted model over encrypted data, and separate functionalities by black-box impossibility results.

Why it is useful

In 2010 the most general construction available handled predicates expressed as inner products, so the distance between the definition and what could actually be built was the central obstacle in the area.

How it works

  1. State the headline goal, which the paper calls the grand challenge: one secure scheme covering every polynomial-time functionality.
  2. Record the state of the art: predicates defined by inner products, built from bilinear maps, which are pairing operations that combine two hidden values into one; the paper blames the two-sided nature of the pairing for the limit on expressiveness.
  3. Ask whether a key can compute a statistical model over an encrypted data set and release only that model.
  4. Ask for black-box separations, which are impossibility proofs that treat a construction only as an opaque box; only one such separation was known at the time.
  5. Add the extension questions: delegated keys that are more restricted than the key they came from, functionalities that take several keys at once, and systems whose parameters come from several independent authorities.

Example

Illustration: a data-mining key that returns a decision tree fitted to an encrypted data set and nothing else about the individual records.

What to watch for

This list is a snapshot of the field in 2010. Several of the questions were answered in later work, so the list should be read as the motivation of the paper and not as a report on what is possible today.

Useful background: Functional encryption, Predicate encryption as a sub-class.

Papers

Circuit, randomized and stateful functional encryption

Some functional-encryption systems support richer computations, including bounded circuits, randomized functions or decryption with changing state. Support for one capability does not imply support for all of them.

Steel FE

Steel supports stateful and randomized functional encryption using hardware.

Papers

Linear, inner-product and polynomial-output encryption

Functional decryption for numerical linear maps, inner products and bounded-degree polynomials. This output interface differs from predicate-gated recovery of a separate message.

Inner-product functional encryption

Inner-product FE releases a numerical inner product specified by a functional key.

Papers

Multi-input, multi-client and decentralized FE

Functions over separately encrypted input slots or client contributions, including decentralized functional-key generation. Multi-input and multi-client models have different key and input ownership.

Decentralized multi-client FE

DMCFE distributes functional-key generation among clients contributing encrypted inputs.

Papers

Multi-input functional encryption

Multi-input FE evaluates a function over several separately encrypted input slots.

Papers

Multi-input quadratic FE

Multi-input quadratic FE evaluates quadratic functions across separately encrypted inputs.

Papers

Two-step multi-client quadratic FE

This construction builds multi-client quadratic FE from decentralized function-hiding inner-product FE.

Papers

Group recipients and accountable decryption

Encryption for selected recipient sets and attribution of unauthorized decryption devices. Access exclusion and traitor tracing solve different problems.

Broadcast encryption and recipient revocation

Ciphertexts or key updates that select groups of recipients and exclude revoked users. Credential revocation and group messaging ratchets have separate lifecycle semantics.

Traitor tracing and accountable decryption keys

Identify contributors to pirate decryption capability, including black-box tracing and trace-and-revoke systems. Software watermark extraction is related but has a different protected object.

Identity-based and hierarchical key addressing

Identity-based encryption lets a name or address act as a public key, with a trusted authority that derives the matching secret key for each identity. The scheme studied here hashes each identity to a public key of an ordinary encryption scheme, and the paper carries the identity-based security guarantee over to attackers with quantum access to that hash.

BBG HIBE

The Boneh-Boyen-Goh HIBE construction delegates identity-based keys along a hierarchy.

Papers

Boneh-Boyen BB1 IBE

BB1 is a Boneh-Boyen identity-based encryption construction.

Papers

Boneh-Franklin IBE

Boneh-Franklin IBE uses pairings to encrypt to identity-derived public keys.

Papers

Cocks IBE

Cocks IBE is an identity-based encryption construction using quadratic residues.

Papers

Gentry IBE

Gentry IBE is an exponent-inversion identity-based encryption construction.

Papers

Gentry-Silverberg HIBE

Gentry-Silverberg HIBE organizes identity-based encryption keys hierarchically.

Papers

Identity-based encryption as a functionality

Identity-based encryption is predicate encryption with equality as the predicate. Keys and ciphertexts are both labelled with strings, and a key decrypts a ciphertext exactly when the two strings are the same.

Why it is useful

It removes the need to look up a public key certificate for each recipient, since any string can serve as an address. The paper also singles it out as the first functionality that cannot be built directly out of ordinary public-key encryption.

How it works

  1. Take the key space to be all binary strings plus the empty key.
  2. Take the plaintext to be a pair whose index is also a binary string.
  3. Define the predicate to accept exactly when the key string and the index string are equal.
  4. Carry the index and the message length in the clear inside each ciphertext, so that the empty key behaves as the public-index rule requires.

What to watch for

Equality is the simplest interesting predicate, and the schemes known when the paper was written differed in how strong their proofs were: random oracle proofs first, then selective security in the standard model, then adaptive security, with lattice constructions appearing later. The paper lists this history without re-proving any of it.

Useful background: Predicate encryption as a sub-class.

Papers

Identity-based encryption from lattice trapdoors

Encryption where any identity string works as a public key, and an authority derives private keys using the lattice trapdoor.

Why it is useful

It brings identity-based encryption to lattice assumptions, an alternative to pairing-based constructions.

How it works

  1. Flip Regev’s cryptosystem: keys live in the primal space, encryption in the dual space.
  2. Every point of the primal space becomes a usable public key with many equivalent secret keys.
  3. The authority extracts a correctly distributed secret key for an identity by Gaussian sampling.
  4. Extraction is equivalent to signing the identity under the hash-and-sign scheme.

What to watch for

Proven in the random oracle model, or in the plain model under an interactive assumption; key sizes are quadratic in the security parameter.

Useful background: Lattice trapdoors from short bases.

Related ideas

Papers

Iterating the proof over hierarchical identity levels

For hierarchical identity-based encryption, where identities form a tree and each node can issue keys for its subtree, the planting step is repeated level by level with a fresh random value planted in a λ fraction of the identities at each level.

Why it is useful

A hierarchical identity is a chain of prefixes, so the reduction must plant the right value at every level of the identity the attacker finally targets, while avoiding the levels of every key it hands out on the way.

How it works

  1. Guess which level of the tree holds the target identity.
  2. At each level, plant a fresh random value on a λ fraction of the identities at that level.
  3. Count the run as a win only if every prefix of the target identity is planted and no key request touched a planted identity.
  4. Each level squares the advantage gained so far and divides it by a polynomial in the query counts, so the loss compounds over the depth.
  5. The same treatment covers the Cash et al. scheme, whose reduction is more involved because a second random oracle has to be handled the same way.

What to watch for

After d levels the advantage is roughly the original advantage raised to the power 2 to the d, while the classical proof loses only a single exponential. At equal parameters this proof covers much shallower identity trees, and making the reduction first-order in the advantage is left open.

Useful background: Quantum security of the GPV identity-based encryption, Planting a challenge value in many hash inputs.

Papers

Quantum security of the GPV identity-based encryption

The lattice identity-based encryption scheme of Gentry, Peikert and Vaikuntanathan stays secure when the adversary queries the identity hash in superposition, provided the underlying encryption scheme is itself secure against quantum adversaries.

Why it is useful

The scheme converts any encryption scheme with the right trapdoor structure into identity-based encryption by hashing identities to public keys, and that hash was the one component without a quantum proof. The underlying scheme already had one, because its reduction treats the adversary as a black box.

How it works

  1. Start from a pre-image sampleable function: public values are images of sampled inputs, and the master secret key can invert the function.
  2. Hash each identity to a public key of the underlying scheme, so an identity becomes a public key.
  3. The authority issues a user key for an identity by sampling a pre-image of the hashed value.
  4. Encryption and decryption then run the underlying scheme under the hashed key.
  5. The reduction plants its own challenge public key on a λ fraction of identities and hands out user keys for the rest, using one oracle for pre-image randomness and one for the planting decisions.
  6. If the attacker attacks a planted identity and wins, the reduction breaks the underlying scheme.

What to watch for

Key requests in the security game are classical while hash queries are quantum, so the proof covers attackers that only superpose the hash. The guarantee is a reduction: quantum security of the identity-based scheme follows from quantum security of the underlying scheme, not from lattices directly.

Useful background: Identity-based encryption from lattice trapdoors, Planting a challenge value in many hash inputs.

Related ideas

Papers

Restrictive delegation of access keys

In the paper's large-universe scheme, a user can derive a new key for a more restrictive policy without returning to the master authority. The delegated key grants a subset of the original permissions.

Why it is useful

A recipient can hand off limited access instead of disclosing a broader key.

How it works

  1. Start with the current policy and key.
  2. Apply supported policy transformations that restrict the authorized sets.
  3. Transform the associated key components consistently.
  4. Re-randomize the result before issuing it as a delegated key.

What to watch for

Delegation does not revoke the original key. The general construction may represent the new rule as the conjunction of the old and desired policies, so semantic equivalence does not promise the shortest key.

Related ideas

Papers

Sakai-Kasahara IBE

Sakai-Kasahara is a pairing-based identity-based encryption construction.

Papers

Waters IBE

Waters IBE is an identity-based encryption variant of the Boneh-Boyen construction.

Papers

Proxy re-encryption and delegated ciphertext transformation

Transform ciphertexts between recipients, policies or key epochs without exposing plaintext to the transformer. Homomorphic key switching is related but need not implement this delegation interface.

Witness encryption and relation-based release

Encrypt relative to a statement so that a qualifying witness enables decryption. Security for false statements and extractable variants must not be conflated with proof-system soundness.

Cassiopeia witness encryption

Cassiopeia implements witness encryption for on-chain use.

Papers

Witness encryption

Witness encryption associates a ciphertext with an NP statement and decryption with a witness.

Papers

Credentials, anonymity and privacy systems

These systems protect what people reveal when they identify themselves, pay, vote or communicate. The right guarantee depends on who can observe the system and which information must remain public.

Cryptographic randomized response

Cryptographic randomized response combines randomized survey answers with cryptographic polling procedures.

Papers

Lelantus Spark

Spark modifies Lelantus with one-time recipient addressing and transaction-viewing keys.

Papers

Rate-limited Privacy Pass

This Privacy Pass variant adds a mediator for rate-limited token issuance.

Papers

Zerocoin

Zerocoin adds anonymous mint-and-spend transactions to Bitcoin-like ledgers.

Papers

Zether

Zether uses encrypted account balances and cryptographic proofs for smart-contract payments.

Papers

Anonymous communication and metadata privacy

Encryption hides what is said, but deniability addresses a different question: what a participant can later prove about who took part. The goal is that the transcript of an exchange cannot serve as evidence to a third party that two specific people communicated, even when one of them tries deliberately to manufacture such evidence. The paper shows this is a property of the whole system - the group, the key derivation and how the session key is used - not something that follows from encrypting or from keeping transcripts small.

AsynchroMix

AsynchroMix applies asynchronous MPC to anonymous communication.

Papers

Bad samplers characterize non-deniability

A bad sampler, given a random group element A, outputs a Y whose Diffie-Hellman value with A is hard to compute even for the sampler, yet easy for anyone to verify. The paper proves that such a sampler exists exactly when MQV can be framed - it is the only incrimination strategy.

Why it is useful

The equivalence turns a question about a whole protocol into a clean question about the group, separating where deniability can hold from where it provably cannot.

How it works

  1. Suppose a bad sampler exists; a malicious responder randomizes the honest party's keys, feeds the product to the sampler and sends the resulting Y.
  2. Any simulator either outputs the authentic key - which would mean computing the Diffie-Hellman value the sampler cannot, contradicting hardness - or outputs something else, which the sampler's distinguisher flags.
  3. Conversely, from any successful framing adversary and judge one builds a bad sampler by running the adversary inside the sampler and using the judge as the distinguisher.
  4. Conclude: if bad sampling is infeasible in the group, the protocol is deniable.

What to watch for

The conclusion is non-constructive: knowing that bad sampling is impossible does not exhibit a simulator, yet plausible deniability in court needs one a judge can actually run. The simulator still does not know whether the peer can compute the Diffie-Hellman value - which motivates the knowledge assumptions.

Useful background: Framing attack on unhashed MQV, Computational Diffie-Hellman assumption.

Related ideas

Papers

Framing attack on unhashed MQV

A concrete strategy for a malicious Bob to prove that Alice communicated with him, in groups where deciding Diffie-Hellman triples is easy. Bob picks his ephemeral value so that nobody - including Bob - can know its discrete logarithm, and then shows the judge the session key Alice computed.

Why it is useful

It refutes the belief that a transcript free of signatures is automatically deniable. The key Alice alone can derive is itself evidence, because correctness of that key can be checked publicly.

How it works

  1. Run the protocol with Alice, but choose Y by hashing a public unpredictable string, such as today's newspaper front page, into a group element - Bob can demonstrate he never knew y, the discrete log of Y.
  2. Obtain the authentic session key Alice computed, for example when the key is used as a bearer token presented back to Bob's server for access to a resource.
  3. Hand his long-term secret b to the judge.
  4. The judge computes the part of the key that depends only on public values and Bob's key, then uses the easy Diffie-Hellman test to check the remainder against DH of Alice's combined key and Y.
  5. Any value other than the authentic key fails the test, so no simulator can succeed - and computing the authentic key without Alice's secret would break the protocol's own security.

Example

Alice runs the exchange to get a bearer token and submits it to Bob's printing service. Bob keeps the token: since its computation requires Alice's secrets and is checkable with his key, it proves Alice's intention to talk to him specifically.

What to watch for

The attack needs a group where the Diffie-Hellman decision problem is easy, such as a bilinear or trapdoor-DDH group. Groups used in deployed messaging are believed to make that problem hard, so this breaks the deniability argument, not Signal itself; the same reasoning applies to an unhashed 3DH.

Useful background: MQV, Decisional Diffie-Hellman assumption, Implicitly authenticated key exchange.

Related ideas

Papers

Offline deniability of key exchange

A key exchange is deniable when a malicious peer cannot use the record of the run to convince anyone else that you took part. Everything the peer walks away with - the transcript and the resulting session key - must be reproducible by a simulator that never touches your long-term secret key.

Why it is useful

Traffic protected by a shared symmetric key is naturally deniable, since either side could have produced it alone. The danger sits in the authenticated key exchange that creates the shared key, because identity keys are involved there. Requiring simulability of the transcript and the key together closes that gap.

How it works

  1. Let a malicious peer interact with an honest party in any number of concurrent sessions, with any auxiliary information it likes.
  2. Define the peer's view as its coin tosses, the full transcript, and the session keys of its sessions.
  3. A simulator stands in for the honest party using only public keys and the same auxiliary input, without the honest party's long-term secret key.
  4. Deniability holds when the simulated views are computationally indistinguishable from real views.
  5. The simulator must survive in the real world: it cannot program the random oracle or use trapdoored setup, because the judge checking the evidence also sees those.

Example

Bob shows a judge a transcript and a key, claiming Alice ran the protocol with him. If a simulator fed only public data reproduces the same joint distribution, the judge learns nothing about Alice's participation.

What to watch for

Deniability can be one-sided - a protocol may be deniable for the initiator but not the responder. The requirement is stricter than zero-knowledge-style simulation, which is only a thought experiment; here the simulator must actually run against the peer.

Useful background: Authenticated key exchange, Diffie-Hellman key exchange.

Related ideas

Papers

Online versus offline deniability

Offline deniability faces a judge who only examines evidence after the conversation ended. Online deniability faces a judge who participates in the protocol while it runs, without holding the malicious party's secret keys.

Why it is useful

The distinction decides how strong the guarantee must be. A judge who is present and holds the accuser's private keys can simply impersonate the accuser and watch the honest party respond, so no protocol can be deniable against that.

How it works

  1. An offline judge receives a transcript, keys and coins from the accuser after the fact and decides whether they prove participation.
  2. An online judge interacts during the run, so sessions must look simulatable even while they happen.
  3. If the accuser hands his long-term private keys to the judge, the judge can pose as the accuser and get direct confirmation - online deniability is then impossible.
  4. The offline case is the practically relevant one: a protocol that fails it leaves behind proofs that anyone can verify later, possibly with the accuser's help.

What to watch for

For Signal, online deniability has already been shown to fail; what remained open, and what the paper studies, is only the offline variant.

Useful background: Offline deniability of key exchange.

Papers

Unique pseudonymity: one anonymous identity

A nullifier can also run as a stable pseudonym: posting under the same nullifier several times tells readers it is the same person, while nothing says who that person is.

Why it is useful

Anonymous forums need continuity for reputation and threads just as much as they need privacy, and an account name would give away both.

How it works

  1. Fix one message per context, for example the identifier of one thread.
  2. Compute and publish the nullifier for that message together with each post.
  3. Anyone can group posts by equal nullifiers; nobody can map a nullifier to the wallet that made it.

What to watch for

The pseudonym lasts exactly as long as the key stays secret. If the secret key leaks, every nullifier ever produced by that key is recognized at once.

Useful background: Nullifier.

Papers

Anonymous broadcast and DC-net protocols

Anonymous transmission through shared broadcast or cancellation of correlated masks, including disruption detection and accountable DC-nets. Reliable delivery is distinct from sender anonymity.

Mixing, onion routing and anonymous message formats

Layered routing, message shuffling and mix formats, including MPC-assisted mixes. Voting shuffle proofs and network anonymity share tools but have different system guarantees.

Clarion

Clarion constructs anonymous communication from multiparty shuffling.

Papers

Loopix

Loopix is a continuous stop-and-go mixnet using per-message delays.

Papers

MCMix

MCMix uses multiparty computation for anonymous message mixing.

Papers

Sphinx mix format

Sphinx is a layered cryptographic message format for mix networks.

Papers

Traffic analysis, cover traffic and unobservability

Hide communication patterns or the fact of participation using delays, cover traffic or private presence mechanisms. Steganographic channels are a related use of information hiding, not its full scope.

Stadium messaging

Stadium distributes metadata-private messaging work across providers and adds noisy cover traffic.

Papers

Anonymous credentials and attribute presentation

Issue and present certified claims while controlling disclosure and linkability. The system includes credential lifecycle and accountability, not only a proof or signature primitive.

U-Prove

U-Prove is an attribute-based anonymous credential system.

Papers

ZEBRA credentials

ZEBRA uses SNARK-based anonymous credentials for on-chain access control.

Papers

zk-creds

zk-creds builds anonymous credentials from zkSNARKs and existing identity infrastructure.

Papers

Credential revocation, tracing and accountable anonymity

Revoke credential access or anonymity under stated authority rules, including public auditing and moderation callbacks. Credential invalidation, identity revelation and blocking are distinct operations.

PAPR

PAPR provides public auditing of privacy revocation in anonymous credentials.

Papers

Protego credentials

Protego combines anonymous credential presentation with revocation and audit procedures.

Papers

zk-promises

zk-promises uses credential callbacks for asynchronous moderation, reputation, and blocking.

Papers

Private issuance and selective-disclosure presentation

A credential can be a signature over several attributes. Issuance creates that signature; presentation proves that a holder has one and reveals the selected attributes. Hiding attributes from the issuer and hiding them from a later verifier are separate protocol goals.

BBS presentation proof variants

The paper gives several proofs of knowledge of a BBS signature. They trade proof size against the assumptions needed when only part of the signed message is disclosed.

Why it is useful

Shortening a proof can change the extraction argument even when the verifier still checks a similar pairing equation.

How it works

  1. Randomize the signature point and a related group element.
  2. Prove the algebraic representation involving the hidden attributes.
  3. Check the pairing relation and representation proof.
  4. Choose the proof variant together with its soundness and simulation conditions.

What to watch for

For partial disclosure, the compact proof and Appendix A need additional assumptions excluding exceptional extracted relations. Appendix B uses a larger CDL-style proof with a generator-relation assumption. The revision history explicitly warns against presenting these as identical guarantees.

Papers

Blind issuance of BBS credentials

In blind issuance, a user submits a group commitment to attributes and receives a BBS signature without revealing the entire attribute vector to the issuer.

Why it is useful

It lets an issuer certify a credential while leaving designated user attributes private.

How it works

  1. Encode attributes in the prescribed commitment form.
  2. Include independent blinding where the intended commitment needs hiding.
  3. Have the issuer sign the group element.
  4. Retain the opening and signature for later presentation.

What to watch for

Signing a hidden commitment does not establish that its attributes are true or authorized. If issuance must enforce visible fields, format rules or eligibility, additional consistency proofs and application checks are required.

Papers

Camenisch-Lysyanskaya credentials

CL credentials use attribute-bearing signatures with issuance and presentation protocols.

Papers

Coconut credentials

Coconut provides attribute-based credentials issued by threshold authorities.

Papers

One-more unforgeability for BBS issuance

This security goal limits the number of distinct valid BBS message-signature pairs an attacker can obtain after a bounded number of requests to an oracle that signs group elements.

Why it is useful

An issuer needs to know that blind signing requests cannot be turned into more credentials than it issued.

How it works

  1. Let the attacker make q signing requests on group elements.
  2. Require it to output more than q distinct valid BBS message-signature pairs.
  3. Count valid openings to messages, rather than merely algebraically related signed group elements.
  4. Apply the theorem with its algebraic-attacker restriction and scalar-collision term.

What to watch for

BBS is not ordinarily unforgeable as a signature on arbitrary group elements: squaring a signed element and its signature produces another valid pair. The paper proves a narrower one-more property in the algebraic group model and leaves a full credential-system analysis outside scope.

Related ideas

Papers

Selective disclosure of signed attributes

Selective disclosure proves that a valid signature covers a complete attribute vector while revealing only designated positions. The remaining attributes become private witnesses in the presentation proof.

Why it is useful

A verifier can check the certified fields it needs without receiving the entire credential.

How it works

  1. Specify the disclosed attribute positions and their values.
  2. Keep the remaining attributes and signature as the witness.
  3. Randomize the proof representation and prove the required signature relation.
  4. Bind the disclosed values and positions into the noninteractive challenge.

What to watch for

Revealing a unique combination of attributes can identify the holder even when the proof hides everything else. Selective disclosure alone does not prove a range predicate such as age at least 18, handle revocation or hide network metadata.

Related ideas

  • BBS signatures: Supports algebraic proofs of possession with selected attributes hidden.

Papers

Anonymous tokens and privacy-preserving authentication

Unlinkable issuance and redemption, anonymous attestation, limited-use access and private rate limits. Device assurance and underlying signature or OPRF primitives remain separate topics.

Direct anonymous attestation

DAA authenticates a hardware module through anonymous-attestation credentials.

Papers

Nullifier

A nullifier is a short public value that stands for one anonymous account performing one action. Anyone can see whether the value has been published before, but the value alone does not say which account produced it.

Why it is useful

Anonymous systems cannot write an account name next to each action, because that name would tie every action to one person. Something else has to carry the message that this account has already acted, without carrying the account itself.

How it works

  1. Derive the value in a fixed, deterministic way from the account secret key and from a message that names the action, such as a particular airdrop or thread.
  2. Publish the value together with the action, and let the network record every nullifier it has seen.
  3. Reject a second action whose nullifier is already on record.
  4. Check the derivation with public information only, never with the secret key itself.

Example

Two posts under one forum pseudonym: readers see the same handle twice and learn nothing about the wallet behind it.

What to watch for

The protection is per message. Sharing one nullifier space across unrelated applications, or deriving the value from something guessable like a public key hash, links actions that were meant to stay separate.

Related ideas

Papers

PLUME: computing the nullifier inside a secure enclave

PLUME (Pseudonymously Linked Unique Message Entity) has the secure part of the wallet compute one fixed nullifier, the hash of the message and public key raised to the secret key, together with one Schnorr-style response value, and hands those to a separate prover.

Why it is useful

Hardware wallets cannot run SNARK provers and should not be tied to one proof system, so the computation that touches the secret key must stay small and standard, independent of the circuit that later proves it correct.

How it works

  1. The enclave, the only holder of the secret key and fresh randomness r, publishes the nullifier hash[m, pk] to the power sk and the response s = r + sk * c.
  2. The challenge c is a hash of public values: the generator, the public key, the hash point, the nullifier, and two masked points.
  3. Because s = r + sk * c, anyone can divide g to the s by the public key to the c and recover g to the r, which checks the enclave arithmetic without the secret key.
  4. The construction is a DDH-VRF style deterministic signature adapted to the secp256k1 curve that Ethereum keys already use.

What to watch for

The equation lines in the source are PDF extractions of math symbols; read hash[m, pk] as a curve point produced by hashing the message and public key to the curve.

Useful background: Three properties a nullifier function must satisfy.

Papers

PMBTokens

PMBTokens embeds an issuer-readable metadata bit in anonymous trust tokens.

Papers

Privacy Pass

Privacy Pass exchanges issuer-approved tokens for later service access.

Papers

The quantum anonymity tradeoff

A large quantum computer that breaks ECDSA breaks PLUME anonymity retroactively: derive the secret keys of the whole anonymity set, recompute all their nullifiers, and match.

Why it is useful

In a deterministic nullifier the secret key is the only source of randomness, so exposing the key exposes the link between account and nullifier. The paper states this holds for any deterministic ECDSA nullifier, not just PLUME.

How it works

  1. Accept the risk for anonymity that only needs to last a short time, such as a DAO vote.
  2. Or give up non-interactivity: each account first commits publicly to a fresh semaphore identity, and later claims prove membership against those commitments.
  3. Deployers are asked to disclose the quantum risk wherever the scheme is used.

What to watch for

The committed route shrinks the anonymity set to accounts that opted in before the first claim, so an early claimer can stand out almost alone.

Useful background: Non-interactive nullifiers versus random-secret schemes.

Papers

Three properties a nullifier function must satisfy

A nullifier function N(sk, pk) is judged on correctness, uniqueness and secrecy: honest runs verify, one key cannot produce two nullifiers for the same message, and the published value does not reveal which key made it.

Why it is useful

Without uniqueness a user can act twice, and without secrecy the nullifier turns into a public trace of the account. Correctness keeps verification possible from public data alone.

How it works

  1. Correctness: verification takes only public inputs, so anyone can check a nullifier and its proof.
  2. Uniqueness: the function is deterministic, so the same key and message always give the same value.
  3. Secrecy: an adversary holding every candidate public key cannot match a nullifier to its key better than guessing.
  4. The paper proves its scheme meets these properties and existential unforgeability in the random oracle model.

What to watch for

The definitions are written for one keypair and one message. They say nothing about several applications sharing a nullifier space, which is a deployment decision.

Useful background: Nullifier, Why ordinary signatures and hashes fail as nullifiers.

Papers

Why ordinary signatures and hashes fail as nullifiers

Each obvious candidate for a nullifier fails in its own way: an ECDSA signature differs on every signing run, a hashed public key can be guessed by trying every address, and a hash of the message with the secret key cannot be checked without the secret key.

Why it is useful

Ethereum keys already sign messages, so reusing what wallets already compute would be the cheapest path. The failure of each candidate is what forces a new construction.

How it works

  1. Signature: each signing run uses fresh randomness, so one key has a huge set of valid signatures for one message, and no repeat can be detected.
  2. Hash of the public key: the set of chain addresses is small enough to enumerate, so the hash hides almost nothing.
  3. Hash of the message and secret key: unique and cheap to compute, but a verifier holding only the public key cannot recompute it.

What to watch for

The paper writes the number of valid signatures per message as 2 to the power 256; the flattened text shows the exponent without its superscript.

Useful background: Nullifier.

Papers

Cryptographic voting and election privacy

Election protocols combining voter privacy with eligibility, tally correctness and public verification. Cryptography alone does not settle registration or election administration.

Ballot and tally verification

Individual and universal verifiability, ballot validity, homomorphic tallying and verifiable shuffling. These mechanisms do not by themselves establish coercion resistance.

Belenios voting

Belenios is an internet voting system with cryptographic election-verification procedures.

Papers

Helios voting

Helios is an internet voting system using cryptographic ballot and tally procedures.

Papers

Scantegrity

An end-to-end verifiable election system used as the commitment-dating application. Appendix B describes publishing digests of its pre-election commitment files through the simplified, fund-burning CommitCoin variant for the 2011 Takoma Park election.

Papers

Receipt-freeness and coercion-resistant voting

Prevent transferable voting evidence or resist an adversary directing voter behavior, including revoting and credential-based approaches. Receipt-freeness and coercion resistance have different threat models.

Private payments and electronic cash

Transfer value with limited disclosure of participants, amounts or transaction links. Central issuance and ledger-based settlement have different double-spend and trust models.

A Merkle tree over every coin commitment

All coin commitments ever published are hashed into one growing Merkle tree, and only its root is used inside proofs.

Why it is useful

A proof that "my commitment is somewhere in this list" would otherwise have to mention the list, which grows without bound. A Merkle tree is a binary tree of hashes: to show a leaf belongs, you only need the sibling hash on each level going up, which is one short string per level.

How it works

  1. Append each new commitment as a leaf.
  2. Recompute the path up to the root; updating costs work proportional to the tree depth, not the number of coins.
  3. Inside the proof, quote the root and supply the sibling hashes as a secret witness.
  4. The verifier recomputes upward and checks the result matches the quoted root.

What to watch for

The tree depth is fixed in advance and built into the proving circuit, so the number of coins has a hard cap rather than being unlimited.

Useful background: Coins as hidden commitments.

Papers

Coins as hidden commitments

A coin is a secret list of values plus one short string, the coin commitment, which is the only part that ever reaches the ledger.

Why it is useful

The commitment is what lets the ledger prove a coin exists without learning which address owns it or what its serial number will be. Commitment here means a locked box: anyone can see the box, only the holder can open it, and each box can only be opened to one contents.

How it works

  1. Pick a secret serial-number seed and a secret address key.
  2. Wrap the address key and the seed together in an inner commitment.
  3. Wrap that inner commitment together with the coin value in an outer commitment.
  4. Publish only the value and the outer commitment; keep the rest in your wallet.

What to watch for

The nesting is not decoration. Because the value sits outside the inner commitment, anyone can check the denomination without being able to reach the owner or the serial number inside.

Useful background: Decentralized anonymous payments.

Papers

Decentralized anonymous payments

A decentralized anonymous payment scheme is a digital currency that needs no bank and no operator, and in which a payment hides who sent it, who received it, and how much it was worth.

Why it is useful

Bitcoin records every payment in a public ledger that anyone can download, and studies of that ledger have linked pseudonyms to real people. A user who wants the privacy of ordinary cash needs the currency itself to hide these details, rather than relying on a mixing service that can delay, trace, or steal coins.

How it works

  1. Start from a public ledger of transactions, as Bitcoin does, so that no central bank is needed to authorise anything.
  2. Add a second kind of transaction that proves the payment is legitimate without naming the coins it consumes.
  3. Require three properties: the ledger leaks nothing beyond public data, a posted transaction cannot be rewritten, and nobody can spend more than they minted or received.

What to watch for

Anonymity here covers the ledger only. The paper is explicit that announcing transactions over the network still leaks identifying information, so an anonymity network is needed on top.

Related ideas

  • Anonymous electronic cash: the design goal
  • Bitcoin: the starting system

Papers

Minting anonymous coins

Minting turns public base-currency coins into an anonymous coin: the payer publishes a value and a commitment, and locks the same value aside.

Why it is useful

It is the doorway between the transparent world and the private one. Without a backing deposit the commitment would be worthless, since nothing would tie it to real value; with the deposit, the commitment becomes a claim on real funds.

How it works

  1. Choose a value and a destination address key.
  2. Build the nested commitment and keep the opening information as the coin itself.
  3. Post a small mint transaction holding the value and the commitment.
  4. Pay the matching amount of base currency into the backing pool; the base coins are destroyed in exchange.

What to watch for

The value is visible in the mint transaction, so entering the private system leaks how much you brought in. The paper measures minting at microseconds and 72 bytes, so the cost is small in practice.

Useful background: Coins as hidden commitments.

Papers

Pouring coins into new coins

A pour consumes up to two existing coins and produces up to two fresh ones, plus an optional public amount, with the total preserved.

Why it is useful

One operation therefore does everything a payment needs: splitting change, merging small coins, and handing ownership to somebody else. Because the outputs are brand-new commitments with brand-new secrets, the old owner cannot follow them and the recipient can spend them freely.

How it works

  1. Take two input coins and their address secret keys, plus authentication paths to the current tree root.
  2. Choose two output values and destination addresses, and any public amount to release back to the transparent system.
  3. Build the fresh coins and their commitments, encrypt the coin secrets to each recipient, and prove the whole thing in zero knowledge.
  4. Post the root, the two revealed serial numbers, the two new commitments, the public amount, the ciphertexts, and the proof.

What to watch for

The transaction shows the total only if a public amount is declared; otherwise even the split between the two outputs stays hidden. Pours take about two minutes to generate in this implementation, which is the main user-facing delay.

Useful background: The zk-SNARK proved with every pour.

Papers

Quisquis

Quisquis combines updatable keys with transaction proofs for anonymous cryptocurrency payments.

Papers

Receiving coins through the public ledger

The payer encrypts the new coin secrets to the recipient under a key in the address, and embeds the ciphertext directly in the transaction.

Why it is useful

It avoids a private side channel between payer and payee. Without it, the two would have to arrange a secure message outside the system, which would need extra infrastructure and assumptions, and would leak the fact of the payment anyway.

How it works

  1. Extend each address with a public encryption key alongside the payment key.
  2. Encrypt the value, serial-number seed, and commitment randomness under the recipient encryption key.
  3. Include the ciphertext in the pour transaction.
  4. The recipient scans pour transactions on the public ledger, tries decryption with the matching secret key, and reconstructs any coin that opens correctly and has not been spent.

What to watch for

The encryption must be key-private so a ciphertext cannot be linked to the address or to other ciphertexts for the same key. Worst case the recipient must attempt decryption on every ciphertext on the chain, which the paper flags as a cost.

Useful background: Pouring coins into new coins.

Papers

Serial numbers stop double spending

Every coin carries one secret serial number. Spending the coin reveals that number, and the network keeps a list of every serial number already seen.

Why it is useful

In Bitcoin a spent coin is simply gone from the list of unspent outputs, so the list shrinks. Here the network can never tell which coin was spent, so it cannot prune anything; the only reusable signal is the revealed number itself. A repeat means someone is spending twice, and the transaction is thrown out.

How it works

  1. Derive the serial number secretly from a seed only the owner knows.
  2. Publish it in the clear as part of the spending transaction.
  3. Nodes check the list of spent serial numbers before accepting anything, and reject a repeat.
  4. The balance property says no attacker can end up with more than they minted or were paid.

What to watch for

The serial-number list only grows, and the paper notes this becomes a real storage cost that later sections work around.

Useful background: Coins as hidden commitments.

Papers

The trusted setup and its risks

Before the currency starts, one trusted run of a key-generation algorithm produces the proving and verification keys everyone will use.

Why it is useful

The soundness of every pour proof rests on those keys having been generated honestly and the secret randomness then destroyed. If the generator kept the trapdoor, it could forge valid-looking proofs and mint value out of nothing for as long as the keys stay in use.

How it works

  1. Run the setup once, producing a large proving key and a small verification key.
  2. Publish both as public parameters and embed them in the software, with no ongoing trusted party and no global secrets kept.
  3. Note that anonymity does not depend on this trust: even a corrupted setup cannot break the privacy of past transactions.
  4. Suggest, as future work, spreading the setup across many parties with secure multiparty computation so no single one holds the trapdoor.

What to watch for

The proving key is enormous in this implementation, close to a gigabyte, which is a distribution problem in its own right. The multiparty mitigation is explicitly left as future work in this paper, not solved by it.

Useful background: The zk-SNARK proved with every pour, Zerocash: the system that resulted.

Papers

The zk-SNARK proved with every pour

Each spending transaction carries one short non-interactive zero-knowledge proof, called a zk-SNARK, that the hidden inputs satisfy all the rules.

Why it is useful

Succinct means the proof is short and fast to check no matter how large the computation being proved is. That is what makes this practical where earlier designs broadcast proofs of tens of kilobytes. Zero knowledge is what stops the proof from giving away which coins were consumed, and the knowledge-soundness part is what stops anyone inventing a proof without actually holding the coins.

How it works

  1. State publicly what must be true: the consumed commitments exist in the tree, the revealed serial numbers belong to them, the new commitments are well formed, and the values balance.
  2. Keep everything that would identify the coins, owners, and amounts as a secret witness.
  3. Run the prover once on the circuit for this statement and attach the resulting proof to the transaction.
  4. Any node checks the proof against the public verification key; no interaction with the payer is needed.

What to watch for

Proving is expensive for the payer - minutes in this implementation - even though verifying is milliseconds. The proof is also only computationally binding, and the paper discusses a stronger statistical variant separately.

Useful background: A Merkle tree over every coin commitment, Serial numbers stop double spending.

Papers

Zerocash: the system that resulted

Zerocash is the working implementation of this design, with every ingredient built out of SHA-256 and a hand-written arithmetic circuit for the pour proof.

Why it is useful

The abstract construction is only useful if the prover, the proof size, and the verification time fit a live network. Instantiating everything on one hash keeps the circuit small, and a small circuit is what makes a pour transaction fit in under a kilobyte and verify in milliseconds.

How it works

  1. Set the Merkle depth to 64, supporting a bounded number of coins.
  2. Hand-optimise a circuit for the SHA-256 compression function, then assemble the pour circuit from it.
  3. Rely on a state-of-the-art implementation of zk-SNARKs for arithmetic circuits.
  4. Measure: pours are about 996 bytes plus a public string, and verifying one is a few milliseconds.

What to watch for

This is a research prototype measured on specific hardware in 2014, not a deployment recommendation; the parameters and the circuit sizes are those of the paper.

Useful background: The zk-SNARK proved with every pour, Pouring coins into new coins.

Papers

Issued e-cash, wallets and offline spending

Issuer-backed withdrawal and spending, including compact wallets, divisibility, transferability and offline double-spend detection. Quantum money is a separate physical-information model.

Brands e-cash

Brands e-cash is a blind-signature-based electronic cash construction.

Papers

Compact E-Cash wallet construction

This e-cash construction supports withdrawal of a wallet containing multiple spendable coins.

Papers

Divisible e-cash

Divisible e-cash supports spending portions of a previously withdrawn monetary value.

Papers

Ledger payment privacy and transaction unlinkability

Confidential or anonymous ledger transactions, including amount hiding, ring authorization and joint transactions. A mixing technique does not necessarily provide the same privacy as a shielded ledger.

CoinJoin

CoinJoin combines multiple users' payment inputs and outputs into a joint transaction.

Papers

Lelantus

Lelantus is a decentralized anonymous payment protocol with confidential transaction amounts.

Papers

Mimblewimble

Mimblewimble combines confidential transactions, transaction aggregation, and spent-output cut-through.

Papers

Non-interactive nullifiers versus random-secret schemes

Zerocash and tornado.cash build nullifiers from a secret the user picks and must then guard; PLUME derives the nullifier from an existing ECDSA key, so nothing has to be registered or stored before the first action.

Why it is useful

Random-secret nullifiers only work when the user can create and protect that secret in advance, and tornado.cash had to move the secret material through its website front end. A key-derived nullifier avoids both steps.

How it works

  1. Random-secret scheme: pick a random string once, publish a hash of it when acting, keep the preimage private.
  2. Key-derived scheme: publish a deterministic function of the message and the existing secret key, and verify it with a proof.
  3. The second shape needs no interaction with the application before the first nullifier appears, which is what the authors call non-interactivity.

What to watch for

Deriving from the key ties the pseudonym to the lifetime of that key, so key compromise unmasks past nullifiers retroactively.

Useful background: Nullifier.

Papers

One action per anonymous account

A zero-knowledge membership proof becomes unsafe the moment one account can act twice: the same proof could claim an airdrop twice, spend a hidden coin twice, or cast a second vote.

Why it is useful

Many privacy applications only check that the prover belongs to some approved set. That check has no memory of past proofs, so the same wallet can prove membership again and again.

How it works

  1. Ask every claimer to publish, next to the zero-knowledge proof, a nullifier computed from their key and the message that names this claim.
  2. Record every published nullifier on the ledger or in the contract.
  3. Treat a repeat as invalid and refuse the action.

Example

An airdrop contract that pays each eligible address exactly once: the proof shows eligibility, the nullifier shows the address has not claimed yet.

What to watch for

The nullifier has to be tied to the account rather than to one run of the protocol. If one key can produce two different nullifiers for the same message, double claiming returns.

Useful background: Nullifier.

Papers

Proving the balance without revealing the real input

Instead of checking that input commitments equal output commitments in the clear, the difference is left as a commitment to zero whose secret key the signer knows, and that difference becomes one row of the ring.

Why it is useful

In a ring only one candidate input belongs to the spender. If the network could test the balance equation directly, it could find which input balances the outputs and the anonymity of the ring would be gone.

How it works

  1. Take the input commitment and the output commitments with their masks; the input minus the outputs then equals zG, because the amount parts cancel to zero.
  2. Read zG as a public key whose secret key is z; that is exactly what a commitment to zero allows.
  3. For every candidate input form the pair consisting of its public key plus its commitment minus the output commitments.
  4. Ring-sign the whole set of pairs; only the real input has a known secret key for its pair, so only one column can be signed.

Example

Spending a hidden 10 into outputs 7 and 3 leaves a difference of zG; the verifier sees one ring signature over all candidate key-plus-balance pairs and learns no amount and no sender.

What to watch for

What is proved is that the committed amounts balance, not that any visible numbers match, and range proofs are still needed to rule out negative amounts. Whoever sent the spender their coins knows the amount key but cannot compute z without the output masks, and a change address removes even that.

Useful background: Why visible amounts break anonymity, and how commitments fix it, MLSAG: one ring signature over a vector of keys.

Papers

Range proofs that stop negative amounts

A proof attached to each output commitment that the committed amount is positive and below a fixed bound, built by splitting the amount into bits and ring-signing each bit.

Why it is useful

Amounts live in a finite group, so −1 behaves like an enormous positive number: without a range check a sender could commit to a negative output and manufacture value out of nothing.

How it works

  1. Write the amount in binary as a sum of bits times powers of two.
  2. Commit separately to each bit times its power of two, and check that the parts add up to the output commitment.
  3. For each bit produce a two-key ring signature on the pair consisting of that commitment and the same commitment minus the power of two times H; knowing one of the two secret keys proves the committed bit is 0 or 1.
  4. Aggregate the per-bit signatures so one compact object covers all bits of all outputs.

Example

For the amount 5 the bits are 1, 0, 1, so the prover shows three commitments opening to 1, 0 and 4, which rules out any value needing a negative or oversized bit.

What to watch for

Every output carries a range proof, so size and verification cost grow with the bit length times the number of outputs; the demonstration in the paper uses 14 binary digits.

Useful background: Why visible amounts break anonymity, and how commitments fix it, How the Back-style linkable ring signature works.

Related ideas

  • Pedersen commitments: The proof restricts what the commitment is allowed to open to.

Papers

RingCT

The assembled Ring Confidential Transactions protocol: MLSAG authorization over key-plus-commitment rows, commitment-hidden amounts, range proofs on outputs, and a path for migrating the visible amounts Monero already used.

Why it is useful

It records the constraints a confidential ledger meets in practice: fees must be checkable by miners, old visible outputs must stay spendable, the receiver must learn the amount somehow, and coin generation must remain verifiable without a trusted setup.

How it works

  1. Pay the miner fee as a plain multiple of the amount base point with a standardized amount, so a miner can confirm the fee exists without a masked commitment.
  2. Spend an old visible output as its amount times H; that input amount is still readable, but the outputs it funds are hidden, and no range proof is needed for such an input.
  3. Give the receiver a shared ECDH secret that unmasks the blinding value, so they recover the amount by matching against every allowed value.
  4. Keep coin generation on proof of work, so mining rewards are commitments anyone can verify and no trusted generation key exists to collect.

Example

A 14-binary-digit range keeps the receiver’s lookup table near 500 kilobytes, while the wider bound used in the Bitcoin-style Confidential Transactions would make the same search slow.

What to watch for

Recovering an amount is a brute-force search whose table grows with the allowed range, so the range width is a real design limit; the paper ships a demonstration implementation rather than a deployed and audited one, and leaves further size optimizations open.

Useful background: Proving the balance without revealing the real input, Range proofs that stop negative amounts.

Related ideas

  • Zerocash: Contrasted on proof-of-work coin generation versus a trusted setup.

Papers

RingCT 2.0

RingCT 2.0 is an accumulator-based variant of the Ring Confidential Transaction protocol.

Papers

Why visible amounts break anonymity, and how commitments fix it

Hide each output amount inside a Pedersen commitment, C(a, x) = xG + aH, so the ledger can add and compare commitments without ever seeing a value.

Why it is useful

CryptoNote rings must be assembled from outputs carrying the same visible amount, so rare amounts shrink the anonymity set; visible amounts also let an analyst match a .9-coin transfer to candidate senders and put bounds on what was sent. Splitting amounts into change to confuse the analysis creates dust outputs instead.

How it works

  1. Commit to each amount a with a random mask x, using the base point G and a second base point H.
  2. Keep the discrete logarithm of H with respect to G unknown; then a commitment to a nonzero amount has no known secret key, while a commitment to zero does.
  3. Use a separate amount key, known only to the spender and to whoever sent them the coins, as the mask of the input commitment, so it stays distinct from the usual spend key.

Example

A commitment to 7 with mask x is the group element xG + 7H, and two such commitments add up to a commitment to the sum of the amounts with no one seeing either value.

What to watch for

Hiding rests on the mask staying secret: reusing masks or leaking the amount key exposes amounts. Binding rests on the discrete logarithm between G and H remaining unknown.

Useful background: Pedersen commitments, Ring signatures hide which key spent.

Related ideas

  • Pedersen commitments: Supplies the hiding, additively homomorphic amount encoding.

Papers

Zerojoin

Zerojoin combines Zerocoin-style spending with non-interactive transaction mixing.

Papers

Protecting programs and restricting their use

Program protection covers ways of running a program without exposing it: which program ran, what data it touched, or how it works. Zexe reaches this with proofs rather than with obfuscation: a transaction says nothing about the program that produced it, yet convinces anyone that the program followed the rules for consuming and creating records.

Function privacy and records with birth and death predicates

Function privacy means a transaction does not reveal which program produced it, only that some valid program did. In Zexe a unit of data is a record holding a payload plus two predicates: a birth predicate that must accept when the record is created and a death predicate that must accept when it is consumed.

Why it is useful

Earlier systems hid inputs and outputs but not the transition function, so a transaction still identified the application, which shrinks the set of transactions it can hide among. But if any hidden program may run, a malicious one could forge records that look legitimate.

How it works

  1. Give every record a data payload, a birth predicate and a death predicate.
  2. A transaction lists the records it consumes and creates, plus shared data that the predicates may read.
  3. The transaction is valid only when every consumed record’s death predicate and every created record’s birth predicate accept that shared data.
  4. A predicate can inspect the whole transaction and refuse to take part if other records carry predicates it does not trust.

What to watch for

Predicates only see the data of their own transaction, not the full ledger, and a transaction still reveals an upper bound on how many records it consumed and created.

Useful background: Zexe.

Papers

Proving a proof instead of a program

The transaction’s proof never evaluates the user’s program. Instead the user first makes a short proof that the predicates were satisfied, and the transaction’s proof merely checks those short proofs.

Why it is useful

One proof system able to check arbitrary user programs would need a universal circuit, which is expensive and would charge every user for the most complicated program anyone might write. Checking a proof is a fixed computation of the same shape for all programs.

How it works

  1. For each record, prove its death or birth predicate over a statement tailored to that predicate.
  2. Store in the record a verification key, or a hash of it, identifying the parameters for that predicate.
  3. The outer proof checks each inner proof with those keys, a fixed computation whose size grows only with the number of records.
  4. Because the outer proof is zero knowledge, it hides the inner proofs, so the inner proofs need not hide which predicate they checked.

What to watch for

Only one level of nesting is used: the inner proofs must not themselves verify proofs, or the field mismatch returns. Each predicate needs its own setup parameters, stored with the record, so a program’s parameters are chosen when the program is written.

Useful background: Function privacy and records with birth and death predicates.

Papers

Zexe

Zexe is a design for a public ledger in which a user runs a program on their own computer and then posts a short transaction that proves the program ran correctly. The transaction hides everything about the run: the data used, the data produced and which program it was.

Why it is useful

Checking a ledger normally means re-running every transaction, and private-payment systems still show which application executed. Zexe makes every transaction the same size and equally cheap to check, and hides the computation itself, so no transaction can be picked out or censored by its content.

How it works

  1. Represent data as records, each guarded by two small programs called predicates.
  2. Consume old records and create new ones in a transaction, satisfying the predicates of all of them.
  3. Attach one zero-knowledge succinct proof that all the rules were followed.
  4. Anyone checks that single proof, in time that does not grow with the offline computation.

Example

A transaction with two consumed and two created records is 968 bytes, whatever the program did.

What to watch for

Producing the proof is the expensive part: under a minute for a standard transaction on the authors’ machine, and it grows with the program. The proofs also need parameters from a trusted setup ceremony.

Related ideas

  • Zerocash: Zexe extends its record and commitment design from one fixed payment function to user-defined programs.

Papers

Copy resistance, leasing interfaces and software revocation

Security goals for resisting program duplication or reuse after return or revocation. Quantum copy protection and secure software leasing are developed under the quantum root, not duplicated here.

Cryptographic software watermarking and attribution

Embed marks in programs or keyed functions and recover them after allowed transformations, including unremovability and unforgeability. This differs from media watermarking and decoder traitor tracing.

Program obfuscation definitions and constructions

Hide program internals while preserving functionality under explicit obfuscation definitions. Representations and implementation tools do not identify the achieved security notion.

5Gen-C

5Gen-C implements multi-input FE and program obfuscation for arithmetic circuits.

Papers

Indistinguishability-based obfuscation

Indistinguishability of obfuscations for equivalent programs, including differing-inputs variants with separate definitions. Mathematical candidate assumptions remain cross-cutting topics.

Indistinguishability obfuscation

Indistinguishability obfuscation transforms a circuit while preserving its input-output behavior. Its security compares two equal-size circuits computing exactly the same function: their obfuscations should be computationally indistinguishable.

Why it is useful

A proof can replace a program containing sensitive information with an equivalent program that does not need that information.

How it works

  1. Specify the circuit class and size bound.
  2. Preserve the original output on every input.
  3. Compare equivalent circuits after matching their sizes.
  4. Use indistinguishability only for replacements meeting those conditions.

What to watch for

This does not promise that the program reveals only what black-box access would reveal. The paper assumes an obfuscator; its applications do not establish a practical, generally secure software-obfuscation tool.

Papers

Punctured-program proof technique

The punctured-program technique rewrites an obfuscated program so it no longer contains a particular secret function value. The rewrite must preserve the entire function before indistinguishability obfuscation can justify exchanging the programs.

Why it is useful

It separates hiding the program representation from proving that a challenge value remains pseudorandom.

How it works

  1. Identify the secret evaluation that would help distinguish or forge the challenge.
  2. Arrange an equivalent program that never needs that evaluation, or handles the relevant case without it.
  3. Replace the full key with the punctured key and match circuit sizes.
  4. Apply obfuscation security, then the punctured function's pseudorandomness.

What to watch for

A rarely used input is not automatically an unreachable input. Removing behavior on even one reachable input generally prevents an equivalence-based obfuscation argument.

Related ideas

Papers

Obfuscation for restricted function classes

Function-specific obfuscation such as point, conjunction and evasive programs. Function class is separate from the VBB or indistinguishability guarantee.

Hidden sparse triggers in deniable encryption

A hidden sparse trigger is a special, rare input encoding that causes an obfuscated encryption program to return a designated ciphertext. An explanation program creates such encodings so they look like ordinary encryption randomness.

Why it is useful

Randomly chosen coins should almost always encrypt normally, while deliberately generated explanation coins must reproduce the ciphertext being explained.

How it works

  1. Make valid trigger encodings occupy a tiny part of the randomness space.
  2. Have the encryption program recognize them without exposing the recognition secrets.
  3. Use the explanation program to encode a ciphertext and claimed message as a trigger.
  4. Protect the encodings against distinctions obtained by modifying them and querying the public program.

What to watch for

Rarity is insufficient. The trigger encodings must remain indistinguishable even in the presence of the public programs and relevant modification attacks.

Related ideas

Papers

Program protection applications claimed beyond key exchange

The paper lists follow-up works that use these maps to hand out restricted access to a secret function rather than the secret itself: attribute-based encryption for general circuits, a succinct single-use functional encryption scheme built on top of it, and witness encryption, where the ability to decrypt comes from knowing a witness for a relation fixed by the encryptor.

Why it is useful

These are the program-protection payoffs of multilinear maps: instead of hiding a key, the system controls which inputs or which knowledge lets a user evaluate the protected function. They are why the candidate mattered beyond key exchange.

How it works

  1. Attribute-based encryption for general circuits was built from these maps by a follow-up work, with a concurrent independent construction from Learning with Errors.
  2. Combining that scheme with fully homomorphic encryption yields a succinct single-use functional encryption scheme, which in turn gives reusable garbled circuits.
  3. Witness encryption drops the notion of a decryption key entirely: anyone holding a witness for the chosen relation can decrypt, and the encryptor need not know a witness.
  4. Each construction uses the graded encoding scheme as its algebraic engine, with the level budget set by the degree the application needs.

What to watch for

These applications are other people’s papers building on this candidate; the authors state that in this paper they only demonstrate multipartite Diffie-Hellman key exchange, and every listed application inherits the new assumptions and the degree bound.

Useful background: From bilinear maps to graded encodings, Noise growth bounds the multilinearity degree.

Related ideas

  • Multilinear maps and graded encodings: the primitive these applications consume

Papers

Virtual-black-box and simulation-based obfuscation

Simulation-based program hiding and its limitations, including distributional and auxiliary-input variants. General-purpose impossibility does not settle every restricted class.

Virtual-black-box obfuscation

Virtual-black-box obfuscation asks that inspecting an obfuscated program reveal no more, in the formal simulation sense, than being able to query its input-output behavior.

Why it is useful

It expresses the intuitive hope that hidden implementation details stay hidden even when the executable is public.

How it works

  1. Compare an attacker inspecting the obfuscated code with a simulator that can only query the original function.
  2. Require the simulator to reproduce the permitted information the attacker obtains.
  3. Specify which class of functions the requirement covers.

What to watch for

General-purpose virtual-black-box obfuscation is impossible under the cited results. This does not rule out every restricted function class, and the weaker indistinguishability definition is different.

Related ideas

Papers

Restricted program evaluation capabilities

Grant selected evaluations or bounded uses of a program. Input restriction and use-count restriction require different mechanisms and do not inherently hide the entire program.

Constrained, puncturable and delegatable PRFs

Keys that evaluate a pseudorandom function only on permitted inputs, or everywhere except punctured inputs. Applications may use these keys without being standalone PRF constructions.

Puncturable pseudorandom functions

A puncturable pseudorandom function supports a restricted key that still evaluates the function everywhere except a selected set of inputs. Even someone holding that restricted key should not distinguish the excluded outputs from random values.

Why it is useful

It lets a security proof remove exactly the secret evaluations associated with a challenge while preserving other computations.

How it works

  1. Generate the full secret function key.
  2. Select the inputs to exclude under the security definition.
  3. Derive a punctured key.
  4. Preserve the function on other inputs and hide the excluded outputs.

What to watch for

Puncturing does not make the excluded input names secret. The definition used here selects the puncture set before receiving the key; a stronger adaptive requirement needs its own argument.

Papers

One-time and bounded-use programs

Limit the number of permitted program evaluations. Classical copyable software alone cannot enforce generic one-time use; hardware, interaction or quantum resources must be stated.

Tamper-resilient and white-box cryptographic programs

Cryptographic computation under code or state modification, including non-malleable encodings and white-box key protection. Physical leakage and fault countermeasures are linked implementation topics.

Randomness and delayed computation

Cryptography needs random choices that attackers cannot predict. Other constructions use deliberately sequential work to delay an output, or let someone check that such work was completed.

Golden two-party exponent VRF

Golden's two-party exponent VRF supplies pairwise pads for encrypted DKG shares.

Papers

GRandLine

GRandLine uses GRand-generated keys to emit successive distributed beacon outputs.

Papers

RandHerd

RandHerd uses RandHound during setup and secret-sharing groups to emit successive beacon outputs.

Papers

SPURT

SPURT builds a distributed randomness beacon using publicly verifiable secret sharing.

Papers

STROBE beacon

STROBE supports deriving earlier beacon outputs from current beacon state and a public key.

Papers

TSUBAKI VRF

TSUBAKI is a separately named VRF construction in the same group-action and isogeny study.

Papers

Delay and time-conditioned cryptography

Cryptographic functions whose guarantees depend on sequential work, resource expenditure, release events or time assumptions.

Non-interactive timestamping in the bounded-storage model

A prior timestamping scheme in which stampers retain message-dependent subsets of broadcast random strings and verifiers retain their own sketches. The comparison here requires verifiers to have participated at the relevant time, unlike the late-arriving verifier intended by carbon dating.

Papers

Resource puzzles and proofs of expenditure

Client puzzles, proof of work, memory-hard puzzles and proofs of space or sustained resource use. These need not enforce sequential delay.

Bitcoin

The proof-of-work transaction ledger used by CommitCoin to retain commitment evidence and accumulate work after its inclusion. The paper's argument relies on limits on constructing an alternative chain; it does not obtain exact wall-clock timestamps merely by trusting displayed block times.

Papers

CommitCoin

A commitment-dating protocol that puts a randomized commitment into a temporary Bitcoin signing key, then deliberately reveals that key through ECDSA nonce reuse. Subsequent blockchain work supplies the dating evidence. The paper proposes a fund-recovering protocol but demonstrates a different, fund-burning variant.

Papers

Commitment carbon dating

Estimates whether a commitment predates a pivot time by tying it to a proof-of-work puzzle. The dating is approximate and depends on the committer not having unusually large computational resources; it does not prevent committing to many candidate messages.

Papers

Entropy-preserving puzzle chaining for commitment dating

Extending a commitment-dating interval by using a puzzle solution to instantiate the next puzzle. The proposed extension requires entropy-preserving puzzles; it is not an instantiated, independently evaluated construction in this paper.

Papers

Grinding over alternative proofs

Grinding is the practice of trying several permitted choices and selecting the one whose downstream result benefits the attacker. In the example here, a miner can choose among several valid proofs to influence a later challenge.

Why it is useful

It explains why merely proving that work was done may not be enough when the result is used to generate future randomness.

How it works

  1. Identify a choice that can be varied without paying the full intended cost again.
  2. Generate several valid alternatives.
  3. Compute the later challenge produced by each alternative.
  4. Publish the alternative with the most favorable result.

What to watch for

Using a uniquely determined VDF output can remove this particular choice of outputs for a fixed input. It does not by itself settle how the input is chosen or every other source of bias.

Related ideas

Papers

Leading-zero hash proof-of-work puzzle

Searches for a nonce such that hashing the commitment and nonce produces a digest with a prescribed leading-zero prefix. Solutions are publicly checkable, but the search can be parallelized. CommitCoin uses Bitcoin's chain of this type of puzzle rather than the ideal non-parallelizable puzzle discussed in Section 3.

Papers

Sequential functions and verifiable delay

A long computation is useful as a delay only if an attacker cannot shortcut it. A verifiable delay function adds a short check so other people can verify the answer without waiting through the whole computation.

MinRoot

MinRoot iterates an algebraic transformation as a candidate sequential function for VDF use.

Papers

Sloth

Sloth is a tunable sequential function used in publicly checked random-number generation.

Papers

Sloth++

Sloth++ is an algebraic delay candidate based on finite-field exponentiation.

Papers

VeeDo

VeeDo is an algebraic delay candidate using finite-field exponentiation.

Papers

Verifiable delay functions

A verifiable delay function produces an output that is intended to require a long sequence of dependent computation steps. It also produces a proof that lets someone else check the result much faster than recomputing it.

Why it is useful

Applications can require delayed outputs without making every verifier repeat the delay. The output for a fixed input must be unique, even if the proof itself is not.

How it works

  1. Generate the public parameters and choose the input.
  2. Evaluate the specified sequential computation.
  3. Produce a proof that the output is correct.
  4. Verify the proof without repeating the entire computation.

What to watch for

There are two separate questions: can someone compute the right output too quickly, and can someone make a wrong output pass verification? A sound proof does not by itself establish the required delay.

Related ideas

Papers

Pietrzak VDF

Pietrzak's verifiable delay function makes repeated squaring publicly checkable. A proof repeatedly reduces one long exponentiation claim to a shorter claim until a verifier can check the remaining work directly.

Why it is useful

The verifier does not need either the full repeated-squaring computation or the secret factorization used during an RSA-style setup.

How it works

  1. Compute the repeated-squaring output.
  2. Provide a midpoint of the computation.
  3. Use a challenge to combine the two half-length claims into one half-length claim.
  4. Repeat the reduction and finish with a directly checkable small computation.
  5. For a non-interactive proof, derive the challenges from the claim and proof messages using a hash function.

What to watch for

The RSA-based version needs a suitable group and setup in which the evaluator does not learn the factors. Its non-interactive security analysis models the challenge hash as a random oracle.

Useful background: Rivest-Shamir-Wagner time-lock puzzle, Fiat-Shamir transform.

Papers

Checkpointing for VDF proof generation

A VDF evaluator can keep selected intermediate squaring results and reuse them when building its proof. This avoids recomputing every midpoint from the beginning.

Why it is useful

Finishing the delayed computation should not be followed by another equally long wait just to construct the proof.

How it works

  1. While evaluating the squaring chain, retain intermediate values at selected positions.
  2. Combine those saved values to form the first proof midpoints.
  3. Recompute the shorter remaining portions when that costs less than storing more checkpoints.

What to watch for

This trades storage and extra algebra for proof-generation speed. It does not eliminate the sequential work needed for the VDF output itself.

Papers

Early stopping in recursive VDF verification

A verifier can stop the halving proof before reaching a single squaring and directly perform a somewhat larger final computation instead.

Why it is useful

A few extra squarings may be cheaper than checking more proof rounds, and removing those rounds also shortens the proof.

How it works

  1. Choose how many final halving rounds to omit.
  2. Verify the provided reductions up to that point.
  3. Compute the remaining short squaring chain directly and compare its result with the reduced claim.

What to watch for

The stopping rule and remaining work must agree between prover and verifier. It is a tradeoff, not permission to leave the last claim unchecked.

Papers

Recursive halving proof

A halving proof reduces the claimed result of a long sequence of squarings to a claim about half as many squarings. A random challenge prevents a prover from choosing two inconsistent halves that cancel deliberately.

Why it is useful

Repeating this reduction gives a verifier a short proof instead of a transcript of every squaring.

How it works

  1. The prover supplies the claimed midpoint of the squaring chain.
  2. The verifier chooses a challenge after that midpoint is fixed.
  3. Combine the starting value, midpoint and claimed output into one new statement using the challenge.
  4. Repeat on the shorter statement until the verifier can check it directly.

Example

For the claim y = x to the sixteenth power, the midpoint is x to the fourth power. The two claims are that the midpoint is correct and that raising it to the fourth power gives y. The protocol combines these claims using a challenge.

What to watch for

The algebra and group-membership conditions are part of the soundness argument. Omitting them or letting the prover choose a convenient challenge is not the same protocol.

Papers

Wesolowski VDF

Wesolowski's VDF combines sequential exponentiation with a proof of the result.

Papers

Time-lock puzzles and timed-release encryption

Delayed secret recovery through work-based puzzles or scheduled key release, including homomorphic evaluation and composable timing models.

Astrolabous

Astrolabous is a time-lock encryption construction developed for a composable protocol setting.

Papers

Homomorphic time-lock puzzles

Homomorphic time-lock puzzles allow computations on puzzles before solving the combined result.

Papers

Rivest-Shamir-Wagner time-lock puzzle

The Rivest-Shamir-Wagner puzzle asks for repeated squaring modulo a large composite number. The intended solver must perform the squarings in order, while someone who knows the factorization can take a shortcut.

Why it is useful

The puzzle can delay access to an encryption key. A message is encrypted with a key derived from the puzzle's eventual solution.

How it works

  1. Choose a modulus made from two secret primes and a starting value in the specified group.
  2. Specify the number of squarings.
  3. Use the factors to compute the solution efficiently when constructing the puzzle.
  4. A solver without those factors computes the chain one squaring at a time.

Example

A chain starts x, x squared, x to the fourth power, x to the eighth power, and so on. Each step squares the result of the preceding step.

What to watch for

The delay relies on a sequential-squaring assumption and on the solver not knowing the factorization. A number of squarings is not a hardware-independent number of seconds.

Papers

TARDIS time-lock construction

TARDIS presents time-lock puzzle constructions within a composable time model.

Papers

Tempora-Fusion

Tempora-Fusion combines time-lock puzzles homomorphically and supplies computation-verification procedures.

Papers

Randomness generation and conditioning

Turning weak or seeded randomness into cryptographic outputs; theoretical entropy definitions live under foundations and devices under implementation.

Unicorn randomness generation

Unicorn uses Sloth in public random-number generation.

Papers

Deterministic random-bit generation

Stateful pseudorandom generation, reseeding and compromise recovery, distinct from physical source measurement and generic PRG definitions.

Extraction and privacy-amplification procedures

Construction and composition of procedures that turn specified weak sources or reconciled noisy secrets into usable key material, including privacy amplification with quantum side information. Entropy definitions, extractor existence results and abstract secure-sketch or fuzzy-extractor interfaces have their primary theoretical home under foundations.entropy. Device characterization and enrollment engineering remain under implementation.entropy.

Verifiable and shared randomness

Publicly checked function outputs and jointly generated randomness, with separate notions for unpredictability, bias and agreement.

RandHound

RandHound groups randomness servers through a client-coordinated public randomness protocol.

Papers

Common coins and distributed coin tossing

Shared-coin subprotocols for agreement or multiparty tasks, including asynchronous scheduling and weak versus strong coin guarantees.

Eventually Perfect Common Coin

EPCC is a common-coin protocol used to build asynchronous agreement and DKG.

Papers

Threshold common coins

A threshold common coin gives honest parties the same bit for a named protocol event. The bit is hidden until enough participants release valid shares, then any party with enough shares can compute it.

Why it is useful

A shared unpredictable choice helps an asynchronous agreement protocol escape disagreement that an adversarial scheduler could otherwise prolong.

How it works

  1. Assign the coin a name that identifies its protocol instance and round.
  2. Have participants generate shares only when the protocol permits release.
  3. Verify and combine enough shares.
  4. Use the resulting bit consistently wherever that named coin is required.

What to watch for

The coin is not secret after reconstruction. Its unpredictability threshold and the timing of share release matter; agreeing on a biased or prematurely known bit does not provide the same progress guarantee.

Papers

Diffie-Hellman threshold coin

This construction hashes a coin name to a group element, raises it to a secret shared exponent and hashes the reconstructed result to a bit. Participants supply partial exponentiations rather than disclosing the exponent.

Why it is useful

It generates coins on demand from long-lived shares instead of consuming a finite store of pre-distributed random bits.

How it works

  1. Hash the coin name to the required group.
  2. Each participant exponentiates with its secret share.
  3. Attach a proof that the partial exponentiation matches its public verification share.
  4. Verify shares and interpolate in the exponent.
  5. Hash the reconstructed group element to the coin bit.

What to watch for

The source analyzes static corruption in the random-oracle model. Its proof uses computational Diffie-Hellman for k=t+1 and decisional Diffie-Hellman for the more general threshold, so these assumptions should not be conflated.

Papers

Public randomness beacons

Repeated public randomness production using contributions, sharing, threshold evaluation or delays, including abort and reconfiguration behavior.

Bicorn

Bicorn combines commit-reveal randomness with time-lock recovery for missing openings.

Papers

CRAFT timed beacon constructions

CRAFT builds randomness beacons from VDFs and publicly verifiable time-lock puzzles.

Papers

drand

drand is a distributed public randomness beacon system.

Papers

HydRand

HydRand uses publicly verifiable secret sharing to generate a sequence of beacon values.

Papers

RANDAO

Ethereum's RANDAO combines proposer contributions to produce consensus randomness.

Papers

SCRAPE beacon

SCRAPE constructs public randomness using a coin-tossing protocol built on PVSS.

Papers

Verifiable random functions

Keyed functions with proofs of output correctness, including distributed evaluation, aggregation and evolving keys.

CAPYBARA VRF

CAPYBARA is a VRF construction studied through group actions and isogenies.

Papers

Discrete-log VRFs with equality proofs

The retained CONIKS appendix evaluates a VRF by hashing an input to a group element and raising it to a secret exponent. An equality-of-discrete-log proof links that evaluation to the public key.

Why it is useful

It gives clients evidence that the provider used the same secret exponent for the public key and the name-specific group element.

How it works

  1. Publish a group public key g raised to the secret exponent k.
  2. Hash the input m to a group element h and compute v = h^k.
  3. Use fresh proof randomness to prove that the discrete logarithm of v to base h equals that of the public key to base g.
  4. Bind the complete statement and proof commitments into the challenge hash, then verify the response equations.

What to watch for

This retained construction uses a prime-order group, random-oracle hashes and a DDH-based pseudorandomness argument. Hashing a name to a known exponent and then computing g to that exponent would expose the evaluation through the public key. Group checks and a concrete hash-to-group specification are required; this is not a current ciphersuite.

Useful background: Verifiable random functions, Proofs of equal discrete logarithms.

Related ideas

  • Diffie-Hellman threshold coin: Also uses exponentiation and equal-log proofs, but adds distributed shares and a different release and unpredictability model.

Papers

Dodis-Yampolskiy VRF

The Dodis-Yampolskiy VRF is a number-theoretic verifiable random function construction.

Papers

ECVRF

ECVRF is an elliptic-curve verifiable random function construction.

Papers

Great-LaKeys exponent VRF

This exponent VRF proves evaluations of an LWR-based pseudorandom function.

Papers

MUSEN

MUSEN combines VRF proof aggregation with evolving secret keys.

Papers

Verifiable random functions

A verifiable random function produces a deterministic, secret-key-dependent output and a proof that the output belongs to a particular public key and input. Outputs at unqueried inputs should look random to someone without the secret key.

Why it is useful

A directory can assign hidden-looking indices to names while allowing clients to verify the index used for a name they query.

How it works

  1. Generate a secret evaluation key and a public verification key.
  2. Evaluate the function on the input and produce a proof.
  3. Verify the proof using the public key and that same input.
  4. Require a unique valid output for the fixed key and input, while protecting unqueried outputs.

What to watch for

A deterministic signing implementation is not enough if its verifier accepts multiple valid outputs for the same input. Once an output is revealed it is public and repeatable. A VRF does not force the key owner to publish an output, or prevent bias from choosing among inputs or keys.

Papers

Quantum cryptography

Quantum cryptography uses quantum information to perform cryptographic tasks. It differs from post-quantum cryptography, which uses classical algorithms designed to resist attackers with quantum computers.

Quantum algorithms and cryptanalytic resource costs

Quantum search, period finding, hidden-structure algorithms and quantum-assisted cryptanalysis, including circuit, memory and query costs.

Grover search

Grover search amplifies a marked state's amplitude to search an unstructured space.

Papers

Grover's Search Algorithm

Quantum algorithm that provides quadratic speedup for unstructured search, implying that symmetric key lengths should be doubled in the presence of large-scale quantum computers.

Papers

Kuperberg sieve

Kuperberg's quantum sieve combines phase states to solve dihedral hidden-subgroup problems.

Papers

Shor algorithm

Shor's quantum algorithm uses period finding for integer factorization and discrete logarithms.

Papers

Shor's Algorithm

Quantum algorithm providing exponential speedup for factoring and discrete logarithm problems, threatening RSA, DLP, and ECC-based public key schemes.

Papers

Quantum communication security

Security tasks that transmit or distribute quantum states, including key establishment and protection of quantum messages.

Quantum Repeaters

Proposed devices that overcome distance limitations in QKD by establishing shared quantum states between distant parties through entanglement swapping and purification.

Papers

Quantum encryption and authentication

Confidentiality, integrity and key recycling for quantum messages or states, with classical or quantum keys.

Quantum key distribution

Quantum key distribution combines quantum measurements with authenticated classical discussion. Testing, information reconciliation and privacy amplification are necessary parts of turning measurement outcomes into a shared secret key.

DARPA Quantum Network

U.S. experimental quantum network; mentioned as an example of a QKD network with optical switches.

Papers

Decoy State Method

Technique for improving QKD security against photon number splitting attacks; mentioned as a theoretical method proposed to improve QKD implementation security.

Papers

QKD Networks

Network architectures for QKD systems including point-to-point links, optical switch networks, trusted relay networks, and quantum repeater networks.

Papers

QKD Protocol Stages

The sequential phases of a QKD protocol: quantum state transmission and measurement, key sifting, error reconciliation, security parameter estimation, privacy amplification, and key confirmation.

Papers

Quantum Key Distribution

Quantum key distribution establishes a shared secret key using quantum communication and authenticated classical messages. The parties test part of their data, repair disagreements and shorten the remaining data into a key.

Why it is useful

Under the protocol and device assumptions, the key can remain secret even against later increases in an observer's computing power.

How it works

  1. Exchange and measure quantum states according to the chosen protocol.
  2. Authenticate the classical discussion that selects and tests the data.
  3. Abort if the observations do not support the required security bound.
  4. Reconcile the remaining bits and apply privacy amplification.

What to watch for

Quantum key distribution does not authenticate an unknown peer by itself. Its guarantees depend on device behavior, randomness, leakage and correct classical processing; it does not guarantee availability.

Papers

BB84

BB84 encodes random bits in one of two quantum measurement bases. The receiver measures in independently selected bases; the parties retain suitable matching-basis outcomes to build a key.

Why it is useful

The two bases prevent an observer from learning every transmitted bit by measuring in one fixed basis without affecting the statistics used for security testing.

How it works

  1. The sender selects independent data bits and basis choices, then prepares the corresponding quantum states.
  2. The receiver selects measurement bases and records outcomes.
  3. After measurement, exchange authenticated basis information and sift the data.
  4. Reveal a test sample and estimate the errors.
  5. Reconcile the unrevealed data and shorten it through privacy amplification.

What to watch for

This describes the idealized protocol analyzed in the paper. Real optical sources and detectors need the security analysis appropriate to their imperfections; a small observed error rate alone is not a complete proof.

Papers

Basis sifting in BB84

Basis sifting discards positions where the sender's encoding basis and receiver's measurement basis differ. The remaining positions are candidates for correlated secret data.

Why it is useful

Even a noiseless transmission does not make outcomes in incompatible bases agree reliably.

How it works

  1. Record each party's basis choices alongside the transmitted positions.
  2. Authenticate the exchange of basis information after measurement.
  3. Keep the positions allowed by the protocol's matching rule.
  4. Reserve some retained positions for testing rather than key output.

What to watch for

Basis choices may become public after measurement, but revealing them to an active attacker beforehand changes the security problem. Sifting does not itself produce a final secret key.

Papers

Information reconciliation in quantum key distribution

Information reconciliation makes two nearby bit strings agree by exchanging helper information. The helper data can be public, but its leakage must be charged against the secrecy of the eventual key.

Why it is useful

Noise can leave honest parties with different raw strings even when the protocol has not detected an unacceptable amount of eavesdropping.

How it works

  1. Compute the helper information specified by a reconciliation method.
  2. Authenticate and send it to the other party.
  3. Use it to correct the disagreements or declare failure.
  4. Include the revealed information in the privacy-amplification calculation.

What to watch for

The appendix's description of guessing errors and checking a hash explains the information requirement, not an efficient decoder for large blocks. Reconciliation alone does not remove the observer's information.

Papers

Parameter estimation in quantum key distribution

The parties reveal a sample of their measurement data and use its disagreement rate to bound what an eavesdropper could know under the protocol's physical model.

Why it is useful

A final key length must reflect the actual observations rather than assuming a noiseless, unobserved channel.

How it works

  1. Choose the test positions as required by the security proof.
  2. Compare those values over authenticated classical communication.
  3. Use a statistical bound to relate the sample to the unrevealed data.
  4. Abort or reduce the output key length if the bound is insufficient.

What to watch for

Finite samples require a failure allowance. The paper's illustrative threshold and asymptotic formulas are not universal operating parameters for every BB84 implementation.

Papers

SECOQC Quantum Network

European research network of QKD links; mentioned as an example of a QKD network with trusted relays, and as a source of critical analysis of QKD's role.

Papers

Continuous-variable QKD

Key distribution using continuous-variable quantum measurements.

Device-independent and measurement-device-independent QKD

QKD models that reduce particular device trust requirements; the models are not interchangeable.

Discrete-variable QKD

Key distribution using discrete quantum encodings and protocol-specific post-processing.

Quantum mistrustful-party protocols

Cryptographic tasks among mutually distrustful parties with quantum capabilities, including their resource-dependent feasibility limits.

Quantum commitments, transfer and coin flipping

Quantum-state or quantum-assisted commitments, oblivious transfer and coin-flipping tasks; the variants need separate binding and bias definitions.

Secure quantum multiparty computation

Joint computation with quantum inputs, outputs or communication, including adversary thresholds and quantum correlated resources.

Quantum proofs and computation verification

Proof and verification tasks involving quantum statements, witnesses, provers or computations.

Private and verifiable delegated quantum computation

Blind, authenticated or verifiable outsourcing of quantum computation, with classical or limited-quantum clients.

Quantum proofs, knowledge and quantumness

Quantum proof and argument models, zero knowledge, knowledge extraction, and protocols certifying quantum capability.

Quantum resources, assumptions and adversary models

This paper works with a quantum-accessible oracle: the hash function is treated as a random function, and the attacker may evaluate it on a superposition of inputs rather than one input at a time. Proofs then have to survive queries that never expose a single hash value, which is what separates this adversary model from the classical one.

Device-Independent Security Proofs

Proof techniques that minimize assumptions about the physical devices used in QKD, aiming to secure key distribution even with imperfect or partially compromised hardware.

Papers

Long-term secrecy with temporary authentication

In this model, an attacker is limited during the protocol but may perform unbounded quantum computation afterward. A successful quantum key distribution session can retain secrecy if its authentication held while the session ran.

Why it is useful

An authentication scheme might resist attacks today without resisting all future algorithms. Later ability to forge a signature cannot retroactively alter a completed exchange.

How it works

  1. Authenticate the live protocol against the assumed online adversary.
  2. Analyze the completed session and all classical and quantum information the attacker retained.
  3. Require its key to remain indistinguishable from a random key under the allowed later computation.

What to watch for

This is not protection against an attacker who could already forge the live authentication, or against later disclosure of the session key or raw secret data. Protecting application traffic also depends on how that key is used.

Related ideas

Papers

Planting a challenge value in many hash inputs

The quantum replacement for guessing a single hash query: embed the challenge value into a λ fraction of all inputs at once, so the oracle becomes semi-constant, and rely on the attacker touching a planted input by chance.

Why it is useful

The attacker cannot detect the planting, yet the chance of using a planted input is about λ instead of exponentially small, so the reduction goes through without ever learning which inputs the attacker cared about.

How it works

  1. Choose λ, and let each input independently be planted with probability λ.
  2. Answer every hash query with the semi-constant oracle: planted inputs return the challenge value, all others return independent random values.
  3. Abort if the attacker asks for a secret that would reveal a planted input, and answer all other key requests normally.
  4. If the target the attacker finally attacks is planted and the attack succeeds, the reduction solves its own challenge.
  5. Balance λ against the indistinguishability loss: with advantage ε for the attacker, the reduction keeps roughly ε squared divided by a polynomial in the query counts.
  6. The same argument proves Full Domain Hash signatures secure, given a trapdoor permutation that is one-way for quantum algorithms.

Example

As an illustration, with λ equal to one thousandth the challenge sits on about a thousandth of all identities, so a random target hits one with probability near one in a thousand.

What to watch for

The reduction loses quadratically in the attacker advantage, and the approach does not reach every classical technique: the Fiat-Shamir conversion resists it because its plugging step has no obvious quantum analog.

Useful background: Semi-constant oracle distributions, Where classical random oracle proofs fail against quantum queries.

Related ideas

Papers

Quantum Mechanics Correctness

Assumption that quantum mechanics is correct and eavesdroppers are bounded by quantum physical laws; one of three minimal assumptions for QKD security.

Papers

Quantum random oracle proofs before this paper

Earlier proofs in the quantum random oracle model handled other schemes, and they needed an extra assumption: a pseudorandom function that stays secure against quantum adversaries, used to simulate the oracle.

Why it is useful

The extra assumption came from the simulation problem. A reduction that must answer superposition queries looks like it needs a compact object that behaves randomly, and a quantum-secure pseudorandom function was the obvious candidate, which made those results conditional.

How it works

  1. A separation result showed the model matters: one random-oracle scheme stays secure when the oracle is queried classically and falls once queries are quantum.
  2. The same work showed that some classical reductions do carry over, but not to the schemes studied here.
  3. Its proofs simulated the oracle with a quantum-secure pseudorandom function, so the theorems held only if such functions exist.
  4. This paper replaces the pseudorandom function with k-wise independent functions, which exist unconditionally and need no assumption.

What to watch for

Removing the assumption changes what the theorems mean: the results become unconditional statements about the idealized model rather than statements contingent on a further primitive.

Useful background: The quantum random oracle model, Where classical random oracle proofs fail against quantum queries.

Papers

Semi-constant oracle distributions

A semi-constant distribution is a way of drawing a random function that is biased towards one value: pick a target value y at random, then send each input to y with probability λ and to an independent random value otherwise. Inputs sent to y are called distinguished.

Why it is useful

It is exactly the shape a function takes when a proof plants one challenge value into a small but significant fraction of the inputs instead of a single input. The proof then needs the attacker to be unable to tell this function from a truly random one.

How it works

  1. Pick the target value y uniformly from the output set.
  2. For each input independently, mark it distinguished with probability λ and set H of it to y.
  3. Every other input gets an independent uniformly random value.
  4. With λ equal to zero nothing is distinguished and the distribution is an ordinary random function.
  5. For any k inputs, the probability that H maps them to chosen values is a polynomial of degree k in λ whose first derivative vanishes at λ equal to zero.
  6. A quantum algorithm making q hash queries therefore distinguishes this distribution from random only to second order in λ, with a bound on the order of λ squared times a polynomial in q.

Example

As an illustration, with λ equal to one hundredth, roughly one input in a hundred maps to the shared value y while the rest behave like an ordinary random function.

What to watch for

The bound may not be tight. A collision-finding algorithm adapted to this distribution distinguishes with probability on the order of q cubed times λ squared, and the paper leaves the gap open.

Useful background: The quantum random oracle model.

Related ideas

Papers

Simulating quantum random oracles with k-wise independent functions

A reduction can answer superposition hash queries using a function that is only k-wise independent, computed on the fly from a short random seed, instead of a truly random function or a quantum-secure pseudorandom function.

Why it is useful

It removes the exponential randomness problem and the extra assumption at once: no oracle table is ever stored, and no unproven primitive is needed, which makes the security results unconditional.

How it works

  1. Note that the stand-in function only has to fool the one algorithm being simulated, not all adversaries.
  2. That algorithm makes a known number of queries to each oracle, say q queries.
  3. A function that is 2q-wise independent agrees with a random function on every 2q inputs, so by the 2q-query indistinguishability result the simulated algorithm behaves exactly as with random oracles.
  4. Build such functions over a finite field from a matrix whose every k rows are independent, such as a Vandermonde matrix, and a short random seed vector.
  5. Compute a single value from one row of the matrix at a time, so the function is evaluated lazily and never tabulated.
  6. For an oracle that must output 1 with probability λ, approximate λ by a fraction and threshold a k-wise independent function over a suitable range.

What to watch for

The simulation preserves the exact output distribution of the idealized game, so it does not add security; it only removes the need for the reduction itself to hold quantum-accessible randomness.

Useful background: What quantum queries reveal about an oracle, Quantum random oracle proofs before this paper.

Papers

The quantum random oracle model

A random oracle is an idealized hash function whose answers are independent random values, available to everyone including the attacker. The quantum random oracle model keeps that idealization but lets the attacker query the function in superposition, receiving a superposition of answers.

Why it is useful

When a design is deployed, the random oracle is replaced by a real hash function, and a quantum computer can run that hash on a blend of many inputs at once. A proof that only allows single-input queries does not describe that attacker.

How it works

  1. Give every party, including the adversary, oracle access to a function H drawn at random.
  2. A classical query sends one input x and learns the single value H(x).
  3. A quantum query sends a superposition of inputs and receives the matching superposition of H values, without any value becoming visible.
  4. State and prove security for adversaries that mix such quantum hash queries with their own quantum computation.

Example

As an illustration, a classical query is one phone call asking for one table entry; a quantum query slides the whole table through a machine that tags every entry at once, and only a later measurement picks out entries.

What to watch for

The model idealizes the hash. As with the classical random oracle model, a proof here does not by itself certify any concrete hash function, and the idealized oracle has structure a real hash does not.

Useful background: Random oracle model.

Related ideas

Papers

What quantum queries reveal about an oracle

A quantum algorithm making q queries to a randomly drawn oracle has an output distribution that is a fixed linear combination of ordinary probabilities: the chances that the oracle maps each list of at most 2q inputs to chosen values.

Why it is useful

It turns a question about an arbitrary quantum attacker into a finite list of classical-looking probabilities that can be checked by hand, and it is the reason k-wise independent objects behave randomly to quantum attackers.

How it works

  1. Write the algorithm as quantum transformations interleaved with the oracle, and track its mixed state rather than any list of queries.
  2. Each oracle value enters the state together with its conjugate, so only the values at the queried inputs survive, at most 2q of them.
  3. Call two oracle distributions k-wise equivalent when they agree on every k inputs; then 2q-wise equivalence forces identical behaviour for any q-query algorithm.
  4. If those input probabilities are polynomials in a parameter λ, the acceptance probability is a polynomial too, since it is a linear combination of them.
  5. When the first derivatives of those polynomials vanish at λ equal to zero, an inequality of the Markov brothers on bounded polynomials limits how fast the acceptance probability can grow.

What to watch for

The statement is about joint probabilities on 2q inputs, not about inputs the attacker "really" queries: a quantum query has no such list, and reading the theorem that way is a mistake.

Useful background: The quantum random oracle model.

Related ideas

Papers

Where classical random oracle proofs fail against quantum queries

Two habits of classical random-oracle proofs stop working: answering the oracle one query at a time, and guessing which single query the adversary will use to break the scheme.

Why it is useful

Both habits assume a query has a visible input and a single answer. A quantum query has neither, so the usual reductions cannot even be written down.

How it works

  1. Classical simulations fill in oracle values lazily, drawing fresh randomness only for inputs that are actually asked about.
  2. A quantum query touches an exponential superposition of inputs, so making even the first answer look random seems to need an exponential table of randomness.
  3. The Bellare-Rogaway argument for Full Domain Hash picks one query, embeds its challenge value there, and hopes the adversary uses that query.
  4. Embedding the challenge into every output of one chosen query makes the oracle visibly non-random.
  5. Embedding it at one fixed input keeps the oracle random-looking, but the guess now succeeds with exponentially small probability.

What to watch for

Not every classical argument collapses: some classical reductions do survive quantum access, and that fact is separate from the failures above.

Useful background: The quantum random oracle model.

Papers

Unclonable cryptographic resources

Cryptographic uses of limits on copying quantum states, including transferable value, controlled program use and deletion.

Certified deletion and revocable quantum information

Protocols giving evidence of deletion or revocation of access to quantum-encoded information, including later key exposure.

Quantum copy protection and software leasing

Quantum encodings of programs intended to limit copying or require return of a usable program state.

Quantum money, tokens and credentials

Quantum states used as value, authorization tokens or credentials, with public or private verification and reuse constraints.

Post-quantum standardization and implementations

The NIST post-quantum process compared candidate algorithms at named security levels rather than at one fixed strength. In this paper L1, L3 and L5 mean security comparable to breaking AES-128, AES-192 and AES-256, so L1 is roughly 128 bits of classical security and 64 bits against a quantum attacker. Every benchmark in the paper is labelled with one of these three levels, which is why a size or speed claim should always be read together with its level.

Compact keys from quasi-cyclicity

With a CCA-2 conversion the QC-MDPC public key can be written in systematic form and shrinks to n - r bits: 4801 bits at 80-bit security, against roughly 460,647 bits for a Goppa-based McEliece key.

Why it is useful

A public key that small brings code-based encryption into the size range of everyday protocols, which is the headline result of the paper.

How it works

  1. Publish only the non-identity part of the systematic generator matrix; the circulant blocks regenerate the rest.
  2. Compare against QC-LDPC, quasi-dyadic Goppa and plain Goppa keys at the same security level.
  3. Choose the block size r prime, which blocks attacks that exploit non-prime quasi-cyclicity.

What to watch for

The key-size table compares 2012 proposals using the decoding attacks known then; the numbers are historical evidence, not parameter recommendations.

Useful background: MDPC-McEliece encryption, Quasi-cyclic MDPC codes.

Related ideas

Papers

Constant-time reference implementation for Dilithium

The reference implementation never branches on secret data and never chooses memory addresses based on secret data; modular reductions avoid the C remainder operator in favor of Montgomery reduction, and centered rounding is computed without branches.

Why it is useful

Timing and cache behavior are observable, so any secret-dependent branch or table lookup can leak the key; the paper documents which paths are protected and, just as important, which are deliberately not.

How it works

  1. Replace secret-dependent branches with arithmetic: the centered remainder is computed by subtracting, shifting arithmetically, and masking, so the sign bit of an intermediate selects the correction without a conditional jump.
  2. Use Montgomery reductions without correction steps plus routines specific to the prime q for all modular arithmetic.
  3. Keep the challenge computation and the rejection conditions outside the constant-time discipline, because they handle public information.
  4. Revealing which rejection condition fired, and even which coefficient violated a bound, is argued to be safe since the rejection probability of each coefficient is independent of the secret.

What to watch for

Constant-time is a claim about the described code paths; verifying it in a real build needs tooling, and later standard versions added further hardening such as masking against differential power analysis.

Useful background: Gaussian-free design against side channels.

Related ideas

  • Cache and microarchitectural attacks: The attack class that secret-dependent memory access would enable.
  • Montgomery multiplication: The reduction technique used to avoid variable-time division.

Papers

Decryption failures in MDPC codes

Bit-flipping decoding is probabilistic, so some ciphertexts fail to decrypt; the paper measures this as the decoding failure rate and treats it as a design constraint to be budgeted.

Why it is useful

A public-key scheme that silently corrupts messages is unusable, so either the failure rate must be made negligible or the protocol must react safely when a failure happens.

How it works

  1. Start from the theoretical error-correction bound and lower the number of corrected errors until the measured failure rate is adequate; the suggested parameters reach a rate below one in ten million.
  2. A second option switches to a stronger decoder on failure, at a significantly higher decoding cost.
  3. A third option wraps the scheme in a CCA-2 secure conversion, a transform that stops an adversary from probing ciphertexts adaptively, so that on failure a fresh encryption can be requested and the redundancy carries no exploitable information.

What to watch for

The remedies given address correctness and message indistinguishability under the conversion; the paper does not analyse repeated decryption failures as a route to recovering the secret key.

Useful background: MDPC-McEliece encryption, Bit-flipping decryption of MDPC codes.

Related ideas

  • BIKE: the later scheme whose security analysis had to bound this failure rate

Papers

Dilithium in the NIST post-quantum competition

The paper positions Dilithium as a signature candidate for the NIST post-quantum standardization call, which explicitly required stateless schemes, and compares it against hash-based, multivariate and other lattice signatures.

Why it is useful

Stateful schemes such as XMSS become insecure if a backed-up key is restored to an older state, which many systems cannot rule out; NIST therefore asked for stateless proposals, and applications like certificate chains transmit public keys and signatures together, so their sum is the number that matters.

How it works

  1. Stateful hash-based signatures (XMSS, then under IETF CFRG standardization) suit systems that can guard state strictly; stateless SPHINCS avoids that burden but costs about 40 KB signatures and tens of millions of cycles.
  2. Multivariate schemes offer tiny signatures but very large public keys, and efficient variants rely on hidden structure that earlier attacks exploited; MQDSS gets a proof from the MQ problem but with signatures no shorter than SPHINCS.
  3. NTRU-based lattice signatures are the smallest but need Gaussian sampling with no known constant-time implementation, and rest on NTRU rather than Module-LWE.
  4. Ideal and module lattice signatures are presented as the sweet spot of small keys and signatures, good speed and simple constant-time implementations; Dilithium cuts the public key of its closest predecessor by about 2.5 (over 2 KB) for about 100 extra signature bytes.
  5. The comparison table lists the recommended parameters at 125-bit claimed security, constant-time yes, about 508 thousand cycles to sign, 175 thousand to verify, a 1472-byte public key and a 2701-byte signature.

What to watch for

This is a submission-stage comparison written by the scheme authors, using their own security accounting against 2017 contemporaries; the competition continued for years afterwards, and the selected and standardized ML-DSA differs in parameters and details from what is described here.

Useful background: Dilithium.

Related ideas

  • SPHINCS: The stateless hash-based baseline for size and speed.
  • MQDSS: The multivariate alternative with provable MQ reduction.

Papers

MDPC-McEliece encryption

A McEliece variant where the public key is the generator matrix of an MDPC or QC-MDPC code and the private key is the sparse parity-check matrix itself.

Why it is useful

Because the secret matrix is only moderately sparse, the public generator matrix is dense enough not to reveal it, so the usual scrambling matrix and permutation can be dropped from the description.

How it works

  1. Key generation: draw a parity-check matrix H of row weight w for a t-error-correcting MDPC code and derive a generator matrix G in row-reduced echelon form.
  2. Encryption: compute the ciphertext as the message times G plus a random error vector of weight at most t.
  3. Decryption: run an LDPC decoding algorithm that knows H, recover the codeword, and read the message from its first positions.

What to watch for

Decryption is probabilistic and can fail, and the systematic public form is only safe together with a CCA-2 secure conversion.

Useful background: Moderate-density parity-check codes, Why McEliece keys are huge.

Related ideas

Papers

Measured impact: bandwidth and server CPU

Concrete measurements of KEMTLS against TLS 1.3 with post-quantum signatures, over emulated networks.

Why it is useful

It quantifies the design win: less than half the transmitted public-key data in size-optimized setups and close to a ninety percent cut in server asymmetric-crypto work in speed-optimized ones.

How it works

  1. Compare total bytes of public-key objects: a size-optimized KEMTLS handshake needs under half the bandwidth of the corresponding signed TLS 1.3 one.
  2. Switching a Kyber-plus-Dilithium deployment to KEMTLS cuts handshake bytes by 16 percent including an intermediate certificate, 24 percent without it.
  3. Measure asymmetric-crypto time: server effort drops by more than 75 percent in the module-lattice case and almost 90 percent in the NTRU case.

Example

A server doing many handshakes spends most of its asymmetric-crypto budget signing in TLS 1.3; KEMTLS replaces that signing with one cheap decapsulation.

What to watch for

Numbers are for round-2 parameter sets at NIST level 1 (with an updated round-3 table in the appendix), on specific network settings; the smallest-handshake variants pay for their size with very slow SIKE computations.

Useful background: Authenticating a server with a KEM, What KEMTLS means for post-quantum signature design.

Papers

Number-theoretic transform performance

Polynomial multiplication in Zq[X]/(X^256 + 1) is done with the number-theoretic transform (NTT), an FFT over the finite field Zq instead of the complex numbers, and the authors speed it up by about a factor of 2 with AVX2 integer vector code.

Why it is useful

Multiplying the matrix A into vectors dominates signing and verification, so transform speed translates directly into scheme speed; the techniques also apply to other lattice schemes.

How it works

  1. Choose the prime q so that q leaves remainder 1 when divided by 512, which supplies a 512-th root of unity (concretely 1753) and makes X^256 + 1 split into linear factors.
  2. Represent each polynomial by its values at those roots (a Chinese remainder form); products then become coordinate-wise, and the forward and inverse transforms carry the cost.
  3. Use integer AVX2 instructions rather than the floating-point approach of the NewHope implementation, packing four coefficients per 256-bit register and interleaving multiplications with reductions to hide latency.
  4. The faster transform speeds up the whole scheme by 25 percent for signing and 15 percent for verification against the same code with the adapted floating-point NTT.

Example

The paper reports about 1.5 thousand cycles for its forward transform against 3.2 thousand for the adapted NewHope version on the same Dilithium parameters.

What to watch for

Cycle counts are 2017-era measurements on Haswell and Skylake processors and are not comparable with modern implementations; only the NTT and the SHAKE expansion were vectorized, so further gains were left available.

Useful background: FFT and NTT kernels.

Related ideas

  • NewHope: The earlier lattice key exchange whose NTT was the baseline.
  • Kyber: Shares the transform-first implementation strategy.

Papers

One board and four implementation tiers

A benchmarking framework that runs every NIST post-quantum candidate on the same development board and labels each piece of code by how much it has been tuned.

Why it is useful

Numbers that mix hand-written assembly with plain reference C measure the programmers as much as the mathematics; one fixed board and clear tier labels keep scheme cost and engineering effort separable.

How it works

  1. Run everything on the STM32F4DISCOVERY board: an ARM Cortex-M4 processor with 196 KiB of working memory and 1 MiB of flash storage for code.
  2. The Cortex-M4 sits at the higher end of microcontrollers, so more candidates fit and the weak spots show where smaller devices would struggle.
  3. Label each implementation clean (tidy reference C), ref (the code submitted to NIST), opt (optimized C) or m4 (tuned with Cortex-M4 assembly).
  4. Every scheme exposes the same NIST-defined interface, so one harness drives them all.

Example

NIST itself pointed submission teams at the Cortex-M4 as an optimization target for the second round of the competition.

What to watch for

A tier says how much tuning happened, not what was tuned: an m4 entry may optimize a single inner routine while the rest stays reference code.

Useful background: Post-Quantum Cryptography, Key encapsulation mechanism.

Papers

Picnic3 and the NIST round status

Combining 16 parties, a full S-box layer LowMC instance and the three MPC changes gives a new parameter set called Picnic3. At the lowest NIST security level it signs in about 5 milliseconds and verifies in about 4 milliseconds on the paper's workstation, with signatures of about 12.6 kilobytes.

Why it is useful

The stated goal was to speed Picnic up while keeping the existing security analysis applicable, so that the changes could be adopted as tweaks to the submission rather than as a new design. At the time of writing Picnic was a second-round candidate in the NIST post-quantum project.

How it works

  1. Reuse the Fiat-Shamir compiled signature shape and only change the party count, the LowMC instance and the MPC internals.
  2. Keep the hash function and block cipher from the existing specification, because the faster alternatives such as KangarooTwelve and Haraka are newer and less analysed, even though hashing is roughly a third of signing time at the lowest level.
  3. Compare against other candidates at the same named security level, and judge protocols that sign once and verify once by the sum of the two times.

What to watch for

The benchmark numbers are the paper's own measurements on one 2020-era x86 machine and are not advice for choosing parameters today, and the NIST status quoted here is only the status the paper states: second-round candidate, with adoption of these changes depending on selection for a later round.

Useful background: Picnic, Full S-box layer LowMC instances, Moving the linear layer into preprocessing.

Related ideas

  • Picnic: the scheme being improved
  • SPHINCS+: the hash-based candidate compared against
  • KangarooTwelve: a faster hash that was considered and set aside

Papers

The scheme families under test

The framework covers 10 key encapsulation mechanisms and 5 signature schemes spanning the main mathematical families of the NIST competition: structured lattices, unstructured lattices, isogenies, multivariate equations and hash-based signatures.

Why it is useful

The central practical question of the competition is which of these families can actually run on a small processor, and each family stresses the device differently: polynomial arithmetic, large matrices, or sheer hashing volume.

How it works

  1. Lattice key encapsulation built on polynomial rings dominates the list (Kyber, Saber, NewHope, NTRU, NTRU Prime, Round5, LAC, ThreeBears); tuned implementations attack the number-theoretic transform or the polynomial multiplication.
  2. FrodoKEM avoids ring structure for a conservative assumption and pays for it with a large matrix that must be sampled on the fly to fit in memory at all.
  3. SIKE, the isogeny entry, needed its big-integer arithmetic rewritten from the GMP library into plain C before it could run.
  4. The signatures range from lattice-based Dilithium, qTESLA and Falcon to the multivariate LUOV and the hash-based SPHINCS+.

Example

Kyber512 tuned for the M4 encapsulates in 652 769 cycles, while FrodoKEM’s smallest fitting parameter set needs 79 745 404.

What to watch for

The list is what could be integrated and made to fit on this board, not a judgement about the excluded families.

Useful background: Key encapsulation mechanism, Kyber, Number-theoretic transform, SIKE.

Related ideas

Papers

What keeps a scheme off the board

Eleven second-round candidates are absent from the framework, each for one of three reasons: public keys too large by construction, an implementation that needs more memory than the board has, or code tied to external libraries.

Why it is useful

The reason matters: a scheme whose keys simply do not fit is arguably unsuited to small devices, while a memory-hungry or library-dependent implementation might be rescued by a rewrite aimed at microcontrollers.

How it works

  1. Key size rules out Classic McEliece (255 to 1 326 KiB public keys), NTS-KEM, GeMSS and most of Rainbow.
  2. Measured memory rules out the larger LUOV parameter sets (155, 270 and 199 KiB), MQDSS (196.5 and 413.6 KiB of stack), every Picnic parameter set (up to 32.9 MiB), and the submitted Falcon code, which allocates over 200 KiB while signing.
  3. Library dependencies keep BIKE, HQC, RQC and ROLLO out, because their submissions lean on OpenSSL, NTL and GMP.
  4. A scheme only enters the framework if every routine runs on the device; covering a subset of routines does not count.

Example

The smallest Classic McEliece public key alone, 255 KiB, is larger than the board’s entire 196 KiB of memory.

What to watch for

The measurements describe particular implementations: the authors note that a different implementation might still make some excluded parameter sets work.

Useful background: One board and four implementation tiers.

Papers

What KEMTLS means for post-quantum signature design

Once signatures move out of the live handshake and into offline certificates, the properties that matter change: signing latency stops mattering, while signature size, public-key size and verification cost matter more.

Why it is useful

It redirects how NIST candidates should be picked per role: fast online signing was motivated by handshake use, which KEMTLS removes.

How it works

  1. Use certificates signed offline, so signing throughput and latency become secondary.
  2. When intermediate certificates are cached, prioritize small signatures, which favours multivariate schemes with tiny signatures and large keys.
  3. Reserve stateful hash-based signatures for certificate authorities that can manage state safely, not for ordinary servers.

What to watch for

Stateful schemes such as XMSS lose security if state is reused or rolled back, which typical TLS servers cannot be trusted to avoid; the reasoning is about the paper round-3 candidates, not a current parameter recommendation.

Useful background: Why post-quantum authentication is the harder half, Authenticating a server with a KEM.

Related ideas

  • TLS 1.3: whose signature requirements are being relaxed

Papers

What the benchmarks do and do not prove

The published tables are a snapshot that gives an order-of-magnitude view of how practical each scheme is on a microcontroller, not a ranking of the candidates.

Why it is useful

Rows differ in security level, mathematical assumption, safety margin, constant-time discipline and how much tuning each implementation received, and new implementations or compiler versions shift the numbers over time.

How it works

  1. Treat any number as provisional and consult the repository for newer results.
  2. Compare implementation tiers of the same scheme to see engineering effects; compare schemes only within matching security levels and assumptions.
  3. Account for partially tuned entries: NewHope’s m4 code optimizes only the transform, and NTRU’s key generation still runs reference code.
  4. Expect wide run-to-run spread where a scheme uses rejection sampling.

Example

NTRU’s ntruhps2048509 encapsulation drops from 2 876 597 cycles in clean C to 645 329 with tuned polynomial multiplication, a 4.5-times gap inside a single scheme.

What to watch for

Reference implementations are explicitly not intended to be optimized, so a slow reference row says little about a scheme’s potential.

Useful background: One board and four implementation tiers.

Papers

Why McEliece keys are huge

The McEliece scheme encrypts with an error-correcting code: it publishes a disguised generator matrix (a matrix whose rows span the code, so a message times it gives a codeword) and keeps the code structure that allows fast decoding secret. That public matrix is enormous, hundreds of thousands of bits.

Why it is useful

Code-based encryption is one of the oldest public-key designs and is believed to resist quantum computers, which made it a candidate replacement for RSA-style systems. The key size is what kept it out of everyday use.

How it works

  1. The receiver picks a code with a fast decoder and publishes a scrambled version of its generator matrix.
  2. To encrypt, multiply the message by the public matrix and add a random error vector of limited weight.
  3. Only the receiver can remove the error, because only the receiver can decode the hidden code.
  4. Keys shrink when the code has many symmetries, such as quasi-cyclic codes, but the compact proposals built on algebraic code families were broken by algebraic attacks.

What to watch for

Security rests on two assumptions: that the code family cannot be distinguished from a random code, and that decoding a random linear code is hard. The indistinguishability half is the fragile one, and a distinguisher for high-rate Goppa codes was already known.

Useful background: McEliece encryption.

Related ideas

Papers

Cryptography in distributed systems

Distributed systems must coordinate despite failures or dishonest participants. Cryptography helps authenticate messages, check shared histories and distribute trust, but does not replace a protocol for reaching agreement.

Random-beacon SNARK parameter generation

This MPC setup removes a precommitment round and generates an extended Groth SNARK reference string.

Papers

Snarky Ceremonies Groth setup

This construction modifies the Groth SNARK ceremony to operate without a random beacon.

Papers

Cryptographic agreement and ledger mechanisms

Authentication, proof and randomness mechanisms used to reach agreement under adversarial participants and network scheduling.

Robust public transaction ledger

The ledger application of the backbone. Persistence: once one honest party reports a transaction more than k blocks from the end of its chain, all honest parties report it, in the same position, from that round on. Liveness: a transaction from an honest holder that is given as input for u consecutive rounds ends up stable for everyone.

Why it is useful

These are the two things a payment system actually needs. A credit cannot be undone later, which is precisely what a double spend tries to do, and an honest user cannot be silently censored by the adversary.

How it works

  1. Content validation accepts a chain only if its transaction sequence is a valid ledger: signatures verify, debited accounts hold enough funds, and no two transactions conflict.
  2. The input function inserts the pending transactions that are not already in the chain, together with a coinbase transaction paying the miner.
  3. Reading returns the whole sequence of transactions.
  4. Persistence is common prefix applied to the pruned chains.
  5. Liveness is chain growth, which supplies enough blocks in u rounds, plus chain quality, which guarantees one of the recent blocks is honest and honest blocks carry the transaction.
  6. The rule that the adversary cannot fabricate a conflicting transaction on behalf of an honest account follows from unforgeability of the underlying signatures.

What to watch for

Both properties need an honest hashing majority and a network that synchronizes much faster than blocks are found. The wait time u is the confirmation delay a merchant has to accept, and the model has the environment hand every transaction to all honest parties.

Useful background: Common prefix, Chain quality, Chain growth, Bitcoin backbone protocol.

Related ideas

  • Bitcoin: the system whose ledger is analyzed

Papers

Authenticated broadcast and Byzantine agreement

Agreement here is built on authenticated broadcast: every replica signs what it sends, so any recipient can check a message and forward it, and a leader that sends two conflicting blocks leaves behind two signed messages that prove the equivocation to everyone. State machine replication then reduces to agreeing on one signed chain of blocks.

Asynchronous Byzantine agreement

Byzantine agreement asks honest parties to decide the same value despite parties that send false, conflicting or missing messages. In an asynchronous network there is no known upper bound on message delay.

Why it is useful

A distributed service needs a consistent decision even when it cannot distinguish a slow participant from a faulty one.

How it works

  1. State agreement: honest decisions must not conflict.
  2. State validity: the decision must satisfy the chosen relationship to proposed inputs.
  3. State progress conditions separately, including what message delivery is assumed.
  4. Use a protocol whose fault bound and randomness assumptions match that model.

What to watch for

Agreement is a safety property, not a promise of timely delivery. The paper's progress measure is conditional on messages being delivered and does not bound elapsed time under arbitrary network delay.

Papers

ABBA asynchronous binary Byzantine agreement

This ABBA protocol combines justified votes with a shared unpredictable coin to decide a binary value. Threshold signatures summarize the supporting votes, while the coin helps honest parties converge when their preferences differ.

Why it is useful

Randomization supports progress in the asynchronous model without relying on a fixed timeout to identify every faulty participant.

How it works

  1. Exchange initial values and collect sufficient support for the first vote.
  2. Send justified pre-votes for zero or one.
  3. Collect pre-votes and send a main-vote for a supported value or abstain.
  4. Decide when the required main-votes agree.
  5. Otherwise reveal the round's common coin and use the protocol's rules to continue.

What to watch for

The protocol assumes fewer than one third Byzantine parties, static corruption, suitable threshold primitives and authenticated messages. Its setup uses a trusted dealer. It is unrelated to the catalogue's quaternion-commitment construction also named ABBA.

Papers

Coin-release ordering in asynchronous agreement

The protocol delays reconstruction of a round's coin until sufficient voting progress has constrained the adversary's choices. The proof needs the relevant preference to be fixed before the adversary learns the random bit.

Why it is useful

An unpredictable coin offers little help if the scheduler can see it first and then arrange the votes to avoid convergence.

How it works

  1. Track which voting state permits an honest party to release a coin share.
  2. Account for the shares already held by corrupted parties.
  3. Relate the release threshold to the number of honest parties that have progressed.
  4. Preserve this ordering when changing thresholds or merging protocol phases.

What to watch for

Simply substituting a lower-threshold coin can invalidate the progress argument. The paper's t+1-threshold alternative adds a ready-message exchange before releasing shares.

Related ideas

Papers

Decision certificates in Byzantine agreement

A decision certificate is transferable evidence that enough valid votes support a decision in a particular instance and round. A lagging party can verify it instead of waiting to reproduce every earlier local step.

Why it is useful

Parties that decide early must not leave slower honest parties unable to finish.

How it works

  1. Combine the required main-vote signature shares into a certificate.
  2. Bind it to the transaction, round and decided value.
  3. Broadcast it before stopping.
  4. On receiving a valid certificate, adopt the decision, relay the evidence and finish.

What to watch for

The certificate must represent the protocol's actual decision condition. A signature on a bare value is not enough to establish which instance or phase authorized it.

Related ideas

Papers

OptRand

OptRand combines publicly verifiable random sharing with state-machine replication and committee reconfiguration.

Papers

Quorum intersection

Two sufficiently large sets of participants must overlap in an honest participant. Protocols use this counting fact to rule out conflicting certificates when honest parties follow a non-equivocation rule.

Why it is useful

A certificate proves support from enough distinct parties; it is not merely a list of many messages.

How it works

  1. Specify the total membership and maximum number of faulty participants.
  2. Choose a quorum size.
  3. Bound the minimum intersection of two quorums.
  4. Require that intersection to contain an honest participant and bind votes to the same instance, phase and round.

Example

With seven parties and at most two faults, two sets of five overlap in at least three parties, so their intersection includes an honest party.

What to watch for

Intersection alone is insufficient if identities can repeat, membership views differ or honest parties are allowed to vote for both alternatives in the same context.

Papers

State machine replication

A state machine replication protocol turns n computers, called replicas, into one fault-tolerant service that keeps working while up to f of them are broken or malicious. Clients send requests, and every honest replica records the same requests in the same order in its own copy of a log.

Why it is useful

One server is a single point of failure and one lie can corrupt shared state. Replication survives faults only if all honest replicas agree on the log, so the service behaves like a single reliable machine even while some of its parts misbehave.

How it works

  1. Run n replicas, of which up to f may be faulty; this paper sets n = 2f + 1.
  2. Clients send requests to the replicas, and the protocol batches requests into blocks that extend a chain.
  3. Each honest replica commits one value per log position and executes the committed requests in order, so their states stay in step.
  4. Replicas talk over pairwise authenticated channels with digital signatures and a public-key infrastructure, so a message cannot be forged in an honest replica’s name.

Example

Illustration: with one allowed faulty replica, the synchronous protocol in this paper needs only n = 2f + 1 = 3 replicas; a partially synchronous protocol needs 3f + 1 = 4 for the same fault count.

What to watch for

The two guarantees, safety and liveness, hold inside the stated model: honest replicas must never commit different values at one log position, every client request must eventually be committed by all honest replicas, and the paper additionally assumes clocks that run at the same rate.

Useful background: Digital signatures.

Papers

Cryptographic ledger consensus and committee selection

Ledger consensus needs a defensible answer to who may add the next block and how everyone else can check that answer. Algorand answers with stake-weighted, privately self-computed selection: a user runs a verifiable random function on its own key and the round seed, learns whether it was chosen, and attaches a proof that others verify against its recorded balance.

Choosing and refreshing the sortition seed

The lottery needs a seed that everyone knows and nobody can steer. Algorand derives it from the previous round, refreshes it only every R rounds, and reads user weights from a block far enough back that keys were fixed before the seed existed.

Why it is useful

If an adversary could choose the seed, it could grind through candidate seeds until corrupted users won the draw. Refreshing rarely, and tying selection to keys committed long before the seed is known, keeps the draw unpredictable even while the adversary controls the network part of the time.

How it works

  1. Each round’s winning proposer publishes a new seed, computed as a VRF of the previous seed and the round number, inside its block.
  2. If the block carries no valid seed, users fall back to hashing the previous seed with the round number.
  3. Committees for rounds in a block of R consecutive rounds all come from the same seed, seed r−1−(r mod R).
  4. Weights and keys are read from a block at least a look-back period old, so the relevant keys predate the seed they will be selected under.

What to watch for

The look-back is a trade-off the paper leaves partly open: a long look-back makes grinding harder but lets users spend their coins and keep influencing a system whose security no longer costs them anything, which the authors call the “nothing at stake” problem. The paper’s own suggested fix, minimum of current and look-back balance, is not explored further.

Useful background: Cryptographic sortition: selecting yourself.

Related ideas

Papers

Cryptographic sortition: selecting yourself

Cryptographic sortition is a self-run lottery. Every user evaluates the VRF on the current seed and the role name; the hash output says how many times that user was selected, and the accompanying proof lets everyone else confirm it. No registration, no interaction, no central draw.

Why it is useful

Because selection is private and non-interactive, an adversary cannot learn who is on a committee until those users start speaking, which removes the window for attacking them in advance. Because each coin is treated as a separate “sub-user” in the draw, splitting money among many accounts does not change how often the same person is selected.

How it works

  1. Set the selection probability p to τ/W, where τ is the expected number of selections for the role and W is the total money.
  2. Treat each of a user’s coins as one sub-user, so the number of that user’s selected sub-users follows a binomial distribution with the user’s weight and p.
  3. Read the VRF hash as a number in [0,1); the binomial interval it lands in gives j, the number of selections, which is also the number of votes the user casts.
  4. Verifiers redo the same interval arithmetic from the VRF proof and the user’s ledger weight.
  5. For block proposers the hash is hashed again with each sub-user index, giving a priority that users can compare to pick one winning proposal.

Example

With an expected 26 proposers per round, the paper bounds the typical count between 1 and 70, and everyone adopts the proposal with the best priority hash.

What to watch for

A user can be selected several times, so votes scale with wealth, and the lottery is only fair while the seed is unpredictable and weights are read from an agreed block. Several proposers usually win at once, and the priority rule rather than the draw decides whose block is used.

Useful background: Verifiable random functions for sortition, Stake weights against Sybil attacks.

Related ideas

Papers

Guaranteed-output coin flipping for epoch randomness

The committee members elected for an epoch each deal shares of a random value using publicly verifiable secret sharing, post them on the blockchain, and reveal later. The epoch seed is derived from the reconstructed values.

Why it is useful

Ordinary commit-and-reveal coin tossing can be aborted: a party who dislikes the outcome just refuses to open. Sharing each secret among many parties means the value can still be reconstructed when some of them stop cooperating.

How it works

  1. Each committee member deals shares of its own random value and posts encrypted shares plus verification information on the chain.
  2. Anyone can check the posted shares are well formed without learning them, because the sharing is publicly verifiable.
  3. After a fixed delay the members reveal the shares they hold; commitments of members who never revealed can be force-opened.
  4. The epoch randomness is the hash of the reconstructed secrets.
  5. The blockchain itself serves as the broadcast channel, so no extra network assumption is introduced.

What to watch for

The proof that this imitates an ideal beacon is given in the random oracle model, with a reference string in the genesis block as the alternative, and relies on the computational Diffie-Hellman assumption together with an honest majority among the elected committee.

Useful background: Secret sharing, Epochs and frozen stake snapshots.

Related ideas

Papers

Hash-to-address CommitCoin variant

The demonstrated CommitCoin variant encodes a commitment digest as a Bitcoin address and sends funds to it. It leaves the digest in the transaction history but burns the funds rather than recovering them through the private-key protocol. The Scantegrity demonstration uses this variant.

Papers

Stake weights against Sybil attacks

Every user carries a weight equal to the money in its account, and all selections and votes are counted by weight rather than by counting users. A Sybil attack is the trick of registering many free identities to gain influence; weighting by money removes the payoff.

Why it is useful

Byzantine agreement protocols normally assume a known set of participants and count heads, which breaks when anyone can join for free. Tying influence to account balance makes influence something an attacker has to buy, so the protocol keeps working in an open network.

How it works

  1. The ledger records a balance for each public key, and that balance is the key’s weight.
  2. Block proposers and committee members are drawn in proportion to these weights, and a member selected several times casts several votes.
  3. The security condition is stated over money: agreement is guaranteed while a constant fraction greater than 2/3 of all money is honest.

Example

An attacker who splits 100 coins across 10,000 fresh accounts still carries the weight of 100 coins.

What to watch for

Weights here only stop an attacker from multiplying itself through pseudonyms. Unlike deposit-and-slash proof of stake, Algorand does not seize a malicious proposer’s money, and reading balances from an older block raises the “nothing at stake” trade-off discussed with the sortition seed.

Useful background: Algorand.

Related ideas

  • Bitcoin: Buys Sybil resistance with hash work instead of money.

Papers

Verifiable random functions for sortition

A verifiable random function (VRF) is a keyed function: with a secret key it turns any input into a hash value plus a proof, and with the matching public key anyone can check that this hash really belongs to that input. To everyone else the hash looks random.

Why it is useful

Algorand needs a lottery that each user can enter privately, using only its own key and public information, yet that everyone can check afterwards. A plain public hash would let an attacker compute every user’s outcome in advance and target the winners; a VRF hides the outcome until its holder chooses to reveal the proof.

How it works

  1. Evaluate the VRF with your secret key on the round’s seed and the name of the role you are running for; you get a hash and a proof.
  2. Keep the result to yourself if you were not selected, or attach the proof to your messages if you were.
  3. Recipients verify the proof against your public key and recompute the same hash.
  4. The guarantees must hold even when a malicious user picks its own key pair.

What to watch for

The paper treats the VRF as a building block (it uses one by Goldberg et al.) and states its properties informally here; uniqueness and pseudorandomness are formalised in the cited VRF literature, not in this paper.

Useful background: Verifiable random functions, Stake weights against Sybil attacks.

Related ideas

Papers

Cryptographic setup and parameter generation

Generation, updating and public checking of shared cryptographic parameters and reference strings; application DKG belongs under threshold.

Reference-string ceremonies and updates

Circuit-specific, universal and updatable reference-string generation, including specialization phases, contribution checks and ceremony coordination.

Asynchronous Powers of Tau

This protocol generates q-SDH public parameters over an asynchronous network.

Papers

Blockchain-mediated Powers of Tau

These setup protocols use blockchain coordination and on-chain or off-chain parameter storage.

Papers

Multivariate SNARK SRS ceremony

This setup generates multivariate reference strings through universal and circuit-specialized phases.

Papers

Pinocchio CRS MPC

This multiparty protocol constructs public parameters for the Pinocchio zk-SNARK.

Papers

Powers of Tau setup

Powers of Tau jointly generates a universal structured reference string of exponent powers.

Papers

Updatable universal CRS

An updatable universal CRS admits participant updates and later relation-specific specialization.

Papers

Transparent and distributed parameter generation

Publicly derived curves and constants, shared moduli or hidden-order parameters, with bias controls and provenance of generation inputs.

trx curve-generation service

trx uses Unicorn randomness to generate random elliptic curves.

Papers

Fair exchange and contract signing

Protocols for exchanging signatures, digital goods or payment claims with explicit fairness and termination guarantees, including contract signing, optimistic trusted-party resolution and ledger-assisted exchange. MPC output fairness, gradual exchange and payment privacy are related but distinct questions. Do not restrict this topic to ledgers or adaptor signatures.

Public-key trust and accountability infrastructure

Distribution of public-key trust, revocation information and publicly auditable records for deployed cryptographic services.

Certification, naming and revocation

Binding public keys to names or roles, trust-path validation and revocation, including decentralized trust arrangements.

Passive authentication with the document security object

Passive authentication lets a reader check that the data in the chip was really written by the issuing country and was not altered afterwards. The chip stores a security object: a digital signature by the issuing country over the list of hashes of the data groups, together with the certificate for the verifying key.

Why it is useful

Anyone who can talk to the chip could otherwise rewrite the stored name, picture or fingerprint template. A signature makes the whole data set unforgeable, because producing it would require the country's private signing key.

How it works

  1. The issuing country hashes every stored data group, for example the copy of the printed zone and the face image.
  2. It signs the list of those hashes and loads the signature, plus a certificate for its verifying key, into the chip.
  3. A reader verifies the signature after reading the data groups, and checks the certificate chain back to a root key it already trusts.
  4. The stored data is accepted only if the hashes match the signed list.

What to watch for

Passive authentication proves authenticity, not authorization: it says nothing about who is reading. The paper argues that even releasing the face image or the security object has privacy costs, since the image is a biometric reference an attacker can train against and the object is transferable evidence, for example of a true date of birth. Its list of hashes also leaks information about the protected data groups.

Related ideas

Papers

Terminal authentication and the EAC certificate chain

Terminal authentication is the step in which the reader proves to the passport that it owns the secret key behind a certified public key, typically by signing a challenge from the passport. The certificate chain roots in the passport's home country, and its leaves are the reading terminals.

Why it is useful

A passport cannot ask an online server whether a reader is trustworthy, because it has no network connection. Certificates carry the answer inside the conversation, together with a validity period and a statement of what the reader may access.

How it works

  1. Each country runs a Country Verifying Certificate Authority that issues certificates for document verifiers and for documents.
  2. A document verifier, an organizational unit inside a country, applies for a certificate at each foreign authority whose passports its terminals may encounter.
  3. The document verifier creates and maintains the terminal certificates; their validity period and access rights are inherited from its own certificate and can only be narrowed further.
  4. Access rights are encoded in binary in each certificate, and a chain member cannot grant more rights than it holds, so the passport computes the logical AND of the rights along the whole chain.
  5. During the session, the reader signs a challenge from the passport to prove possession of the certified private key.

What to watch for

The chain decides authorization entirely offline: there is no way to consult a current revocation list, and validity periods are checked against the passport's weak substitute for the current date.

Useful background: The structure of Extended Access Control.

Papers

Terminal revocation without a clock

Passports have no clock and no network connection, so they cannot know the current time or fetch revocation lists. Instead the chip keeps a trusted past date in memory, updated from dates seen in accepted certificates, and revocation relies on certificate expiry measured against that stored date.

Why it is useful

Without a trusted time, a certificate's validity period cannot be checked for real. The stored date is the best available substitute, but it only moves forward when the passport meets suitable certificates.

How it works

  1. The chip stores the latest trusted date it has accepted.
  2. To check a certificate, it verifies that the expiration date is later than the stored date.
  3. If verification succeeds and the certificate's issuing date is later than the stored date, the stored date is replaced by that issuing date.
  4. One proposed repair is to offer domestic clock-update booths before departure, so interactions with accurate terminals keep the stored date closer to real time.
  5. Another proposal replaces single-terminal trust with a threshold proof, where a terminal can authenticate only together with several neighbouring terminals and several document verifiers.

What to watch for

A passport that rarely runs terminal authentication keeps an old date, so a terminal certificate can stay usable long after it expires. The paper adds that the stored date is usually refreshed through foreign document verifier certificates, so revocation of terminals is not fully solved, and the threshold proposal does not help when a whole country is no longer trusted.

Useful background: Terminal authentication and the EAC certificate chain.

Papers

Transparency logs and accountable directories

A signature tells you who endorsed a directory entry, but the signer can endorse different entries for different people. Transparency systems make entries and histories checkable across observers. In a key directory, the owner also needs to monitor whether a globally visible key change was actually authorized. Detection, prevention, recovery and privacy are separate design choices.

Auditing directory forks

Fork auditing compares the signed directory histories seen by different observers. Conflicting provider-signed snapshots can be evidence that the provider is equivocating.

Why it is useful

A client that only asks its own provider can be kept on a self-consistent but false branch indefinitely.

How it works

  1. Validate the snapshot history available to the client.
  2. Query independently chosen auditors for the provider snapshots they observed.
  3. Compare snapshots for corresponding epochs and check their authenticated history links.
  4. Retain conflicting signed evidence so others can verify the discrepancy.

Example

With no colluding auditors and five independent checks by each of two clients, the model gives a failure bound of 1/1024. This is a joint detection calculation, not a guarantee for each isolated client.

What to watch for

Detection depends on reaching observers with a different view. In the paper's independent uniform-sampling model, if a fraction p of auditors colludes and each of two targeted clients makes k checks, the worst-case probability that neither detects the fork is at most ((1+p)/2)^(2k). Correlated choices, network isolation and unavailable evidence are outside that calculation.

Useful background: Signed tree-root histories.

Papers

CONIKS key transparency

CONIKS lets users check a provider's directory of names and public keys. Users monitor their own entries, while comparisons of signed directory snapshots help expose a provider that shows different directories to different people.

Why it is useful

End-to-end encryption still depends on obtaining the intended recipient's key. A compromised directory can otherwise substitute a key and impersonate the recipient.

How it works

  1. Publish signed snapshots of a cryptographically authenticated key directory.
  2. Return a proof with each key lookup.
  3. Have each client check its own key entry for unexpected changes.
  4. Compare snapshot histories through auditors to detect conflicting views.

What to watch for

Consistency does not establish a person's real-world identity or prevent every attack before it happens. The design needs trusted client devices, authenticated provider keys, retained local state and access to independent communication paths. A provider willing to misbehave openly can still cause harm.

Papers

Key-change authorization and recovery

A key directory needs a policy for replacing keys. CONIKS contrasts a default policy that permits account-recovery changes with a strict policy requiring authorization by an existing key.

Why it is useful

The recovery policy determines whether the provider can substitute a key on its own and what happens when a user loses every old key.

How it works

  1. Under a strict policy, verify each key-change statement using an already trusted key.
  2. Under the default policy, allow recovery through the provider's account-authentication process.
  3. Include the policy in the authenticated directory record and monitor it for unexpected changes.
  4. Treat enrollment of another device as a key-authorization decision too.

What to watch for

The default policy lets the provider claim a user requested an unsigned change. Strict authorization prevents that route but can make loss of all authorizing keys unrecoverable. Neither policy protects a compromised endpoint or a stolen authorizing key.

Papers

Monitoring after missed epochs

A client returning after an absence must check what happened while it was offline. An unchanged current key does not prove the provider kept that key unchanged throughout the interval.

Why it is useful

A provider might temporarily substitute a key and restore the original before the owner reconnects.

How it works

  1. Retain the last trusted snapshot and binding.
  2. Obtain the intervening snapshot history and relevant binding proofs.
  3. Check every missed epoch for changes and verify the history links.
  4. Only skip these checks if a separately justified history mechanism supplies the missing guarantee.

Example

If a key is A at epoch 10, changes to M at epoch 11 and returns to A at epoch 12, comparing only epochs 10 and 12 misses the substitution.

What to watch for

A change counter written by the same untrusted provider is not sufficient by itself. The paper's proposed version-history optimization adds an auditor that checks updates across all changed leaves; it changes the trust and workload assumptions.

Papers

Private directory indices

Private directory indices use a provider-held verifiable random function to place names in a tree without exposing an offline-computable name-to-position map.

Why it is useful

Hashing a predictable username publicly lets an observer test likely names against tree structure. Secret-key evaluation blocks that particular offline enumeration route.

How it works

  1. Evaluate the provider's VRF on a username and derive its tree index.
  2. Store a commitment to the full name and key data at that index.
  3. Return the VRF result and proof when answering a permitted lookup.
  4. Verify the index and commitment before accepting the tree proof.

What to watch for

This does not hide the queried name from the provider or stop online guessing through allowed lookups. Authentication and rate limits remain relevant. Known indices stay linkable across epochs unless the layout changes; the paper describes update leakage through neighboring paths.

Useful background: Verifiable random functions, Hiding and binding commitments.

Papers

Self-monitoring key bindings

Self-monitoring means repeatedly checking that the directory still associates your name with the keys and policies you expect.

Why it is useful

Other users may verify that a binding is present but cannot necessarily tell whether you authorized it. Your own client has information they lack.

How it works

  1. Fetch your binding and its proof for each epoch.
  2. Verify the private index, record opening and authentication path.
  3. Compare key data and policy flags with your retained state and authorized changes.
  4. Notify the user about unexpected changes, and separately audit the snapshot history for forks.

What to watch for

An inclusion proof does not prove the key is authorized. Default-policy monitoring can detect a change after another client has already used the substituted key, and an unsigned recovery change may not yield publicly attributable evidence.

Papers

Signed tree-root histories

A signed tree root authenticates a directory snapshot. Including a hash of the previous signed snapshot commits the provider to a particular history as well as the current tree.

Why it is useful

A provider that forks its history cannot later merge the conflicting branches without exposing a broken link to clients that remember earlier snapshots.

How it works

  1. Sign the epoch, root, previous epoch and previous signed-root hash together with relevant provider policy.
  2. Verify the provider signature using an authenticated key.
  3. Check that the predecessor link matches the retained history.
  4. Keep a trusted checkpoint and compare it with later snapshots and other observers' views.

What to watch for

A valid signature alone does not establish freshness or global agreement. Epoch numbers increase but need not be consecutive. Clock and missed-epoch handling matter, and a mutable directory history is not the same data structure as an append-only list of every issued key.

Papers

Temporary directory bindings

A temporary binding is a provider-signed promise to include a new name-to-key binding in the next directory snapshot.

Why it is useful

It allows a new user to begin communicating before the next periodic snapshot is published.

How it works

  1. Register the name and public key.
  2. Receive a signed promise tied to the current snapshot and the new binding.
  3. Retain the promise while the update is pending.
  4. At the next epoch, require the promised binding and its directory proof.

What to watch for

A promise is not a present inclusion proof. Clients must distinguish temporary status and check fulfillment; missing or delayed snapshots need an explicit failure policy.

Papers

Verifiable storage, availability and cross-system services

Proof-backed storage and retrievability, data availability, light-client or bridge verification, and cryptographic state-transition integration.

Consensus protocols: BFT, proof of work, proof of stake

A consensus protocol is the set of rules by which replicas that do not fully trust each other settle on one shared log of client requests. Sync HotStuff is one such protocol: it assumes a known maximum message delay ∆ and tolerates faulty replicas forming a minority, where protocols without that timing assumption tolerate only one-third faults, and it adds a mode that runs at actual network speed when faults stay below one-quarter.

Algorand

Algorand is a cryptocurrency in which each new block is fixed by a Byzantine agreement vote among a randomly chosen subset of users, instead of by a proof-of-work race. Byzantine agreement means that honest users settle on one value even if some participants lie, so a block that is confirmed cannot later be undone by a competing block.

Why it is useful

In Bitcoin two miners can extend the chain at the same time, producing a fork; neither branch is wrong, so users are told to wait about an hour before trusting a payment. Algorand replaces that waiting with an explicit agreement decision that honest users reach in about a minute, and it keeps this speed while anyone is allowed to join.

How it works

  1. Time is divided into rounds, and each round appends one block of transactions to the ledger.
  2. A randomly selected user proposes a block of pending transactions, and a fresh random committee runs the BA⋆ agreement protocol to pick one block for that round.
  3. All users gossip the votes, so even users outside the committee see which block won.
  4. A transaction is treated as confirmed once its block, or a later block, reaches final consensus.

Example

A payment counts as confirmed roughly a minute after it is broadcast, instead of after six ten-minute blocks.

What to watch for

The speed and fork-freedom hold only while more than two thirds of the money is in honest hands and the network is adversarial for bounded periods only. All timing and throughput numbers come from the authors’ 1,000-machine prototype, not from a deployed currency.

Useful background: Bitcoin, Byzantine agreement.

Related ideas

  • Bitcoin: Confirms probabilistically after waiting out possible forks.

Papers

BA⋆ Byzantine agreement

BA⋆ is the agreement protocol that picks the block for a round. It runs in two phases: first it reduces the many possible proposals to a choice between one block hash and a default empty block, then it runs a binary agreement on that choice, in repeated steps with a freshly selected committee each step.

Why it is useful

Block proposal alone cannot guarantee that everyone saw the same block, and classic Byzantine agreement does not scale to hundreds of thousands of users. BA⋆ gets scale by letting a small random committee speak while everyone else listens, and it gets robustness by replacing that committee at every step.

How it works

  1. Users start BA⋆ from the highest-priority proposal they received, or from the empty block if none arrived in time.
  2. In each step, users selected for that step’s committee broadcast one signed vote, and everyone counts votes by weight.
  3. As soon as one value passes a threshold of T·τ votes, users adopt it for the next step; if the step times out, the next vote follows a rule fixed by the step number.
  4. Every third step of the binary phase falls back on a common coin, a bit that most users observe alike, so that honest users who are split cannot be kept apart forever.
  5. When the network behaves and the top proposer was honest, the whole protocol finishes in four steps.

Example

A vote counts once per selected sub-user, so a committee member drawn three times contributes three votes.

What to watch for

The common coin is only mostly common: if a malicious committee member holds the lowest hash it may reveal different bits to different users, and liveness then relies on the honest fraction rather than on agreement. The threshold T trades committee size against how easily an attacker reaches quorum by luck.

Useful background: Algorand, Cryptographic sortition: selecting yourself.

Related ideas

Papers

Bitcoin backbone protocol

The chain-building engine inside Bitcoin, with everything Bitcoin-specific removed. Each participant keeps a chain of blocks, swaps it for a longer valid chain whenever one arrives, and spends the rest of the round trying to extend what it now holds.

Why it is useful

Bitcoin mixes a general agreement engine with payment rules. Pulling the engine out means it can be analyzed once and then reused for other tasks, and the analysis can state exactly what the engine contributes and what the application must add on top.

How it works

  1. Start from the empty chain; a block is only accepted if its hash value links it to the block before it.
  2. Each round, collect the chains that arrived and keep the best valid one, where longest wins.
  3. Ask the application what value should go into the next block.
  4. Try up to q hash queries to find a counter ctr with H(ctr, G(s, x)) below the target T; if one turns up, append the block and broadcast the new chain.
  5. When asked to read, hand the chain to the application’s reading function.

Example

Keep the engine and swap the three functions: one choice of V, I, R turns it into a consensus protocol, another into a payment ledger.

What to watch for

The backbone only promises things about the chain as a data structure. It says nothing about whether the content rules are sensible or whether mining is worth doing; those are the application’s business.

Useful background: Bitcoin.

Related ideas

  • Bitcoin: the system the protocol was extracted from

Papers

Blame and view change

The rules for replacing a bad leader: replicas blame a leader that stalls or equivocates, quit the view, exchange their locks, and let the next leader restart from the highest certified block it can collect.

Why it is useful

A leader can attack progress in two ways, stalling by proposing nothing and equivocating by proposing conflicting blocks to different replicas. Both must be detected and survived without losing agreement on what was already committed.

How it works

  1. Views are numbered periods of steady state with one leader each, scheduled round-robin as replica (v mod n); keeping a stable leader follows the Paxos and PBFT tradition.
  2. Blame and quit: if fewer than p proposals earn this replica’s votes within (2p + 4)∆, it broadcasts a blame, and after collecting f + 1 blames it broadcasts them and quits the view; seeing two signed conflicting messages from the leader makes a replica quit at once.
  3. Status: after quitting, a replica waits ∆, picks the highest certified block it knows, locks on it, sends that certificate to the new leader and enters the next view.
  4. New view: the new leader waits 2∆ and broadcasts a new-view message with the highest certified block it knows; replicas forward it and vote only if it ranks at least as high as their own lock.

What to watch for

View changes carry the protocol’s long synchronous waits, ∆ before locking and 2∆ for the new leader, so they are safe but slow; they run only when a leader misbehaves or stalls, which is why the steady state stays fast.

Useful background: Leader-based commit phases in Sync HotStuff, Blocks, quorum certificates and locks.

Papers

Blocks, quorum certificates and locks

Client requests are batched into blocks chained by hash digests; a quorum certificate is a set of signed votes on one block from a quorum of replicas in the same view; and at the start of every view a replica locks on the highest certified block it knows.

Why it is useful

Certificates are portable evidence that a block was voted on, and locks carried from view to view are what stop honest replicas from later helping certify a block that conflicts with something already committed.

How it works

  1. A block stores its payload and a hash digest of its predecessor, so blocks form a chain and voting for a block also votes for its uncommitted ancestors.
  2. Certificates are ranked first by view number and then by block height, which gives every replica a common way to compare blocks.
  3. A quorum in this protocol is f + 1 votes out of 2f + 1 replicas, so a certificate is cheap to form.
  4. A replica locks on its highest certified block when a view begins, and in later views only votes for proposals ranked at least as high as that lock.

Example

Illustration: with n = 3 and f = 1, a quorum is 2 votes, and the two Byzantine-plus-honest overlaps mean certificates alone prove too little to be final.

What to watch for

The small quorum is the catch: with all f Byzantine replicas voting as well, one honest vote can complete a certificate, so two conflicting blocks can both collect certificates. Safety comes from the 2∆ wait and the locks, not from quorum intersection as in PBFT-style protocols.

Useful background: State machine replication.

Papers

Bounded-depth longest-chain rule

In the long-lived protocol a party accepts a longer chain only if it does not diverge from the chain the party already holds by more than k blocks.

Why it is useful

Stake moves, so a group that once held most of the stake may hold none of it today, and its old keys can be corrupted. A plain longest-chain rule would let such a group rebuild a long alternative history from the distant past.

How it works

  1. Remember the chain you held the last time you were online.
  2. Among the valid chains received, keep only those that share all but the last k blocks with it.
  3. Choose the longest of the survivors.
  4. Reject blocks whose slot numbers are far ahead of the current time.

What to watch for

The rule obliges participants to come back online at least about every k slots, and long-range or past-majority attacks are excluded only under the theorem’s preconditions on stake shifts and availability.

Useful background: Proof-of-stake slot leader election, Ledger persistence and liveness.

Related ideas

Papers

Byzantine agreement from the backbone

A consensus protocol obtained by instantiating the three functions: every party keeps writing its own input bit into its blocks, and once the chain is long enough everyone outputs the majority bit of the first k blocks of the chain after cutting k blocks from the end.

Why it is useful

In an anonymous network with no identities and no trusted setup, deterministic agreement is impossible and the usual shared-coin constructions are unavailable. Proof of work supplies both the proportionate influence and the randomness, which is why the backbone can carry a consensus protocol at all.

How it works

  1. Content validation accepts blocks carrying a bit and a fresh nonce.
  2. The input function always inserts the party’s own input, never the value already sitting in the chain.
  3. The reading function outputs the majority of the first k bits once the chain has at least 2k blocks.
  4. Agreement follows from common prefix, since everyone’s first k blocks coincide.
  5. Validity follows from chain quality: with adversarial hashing power below one third, honest bits are the majority among those k blocks.

What to watch for

Nakamoto’s own suggestion, copying into new blocks the value already in the chain, loses Validity unless the adversary is negligible, because the first adversarial block drags every later honest block with it. Reaching the one-half bound needs a second construction that stores proof-of-work transactions in a ledger, plus a 2-for-1 trick so the adversary cannot shift work between the two puzzles it faces each round.

Useful background: Common prefix, Chain quality, Bitcoin backbone protocol.

Papers

Chain growth

Over any s consecutive rounds, every honest party’s chain gets at least tau times s blocks longer, with tau equal to (1 minus epsilon) times f in a typical execution.

Why it is useful

Agreement about a frozen history is useless if the history never advances. Getting new transactions into the stable part of the ledger, and getting the consensus protocols to terminate, both need the chain to keep moving no matter what the adversary does.

How it works

  1. A chain that an honest party holds was broadcast earlier, so by the next round everyone holds at least that length.
  2. Every round in which some honest party succeeds therefore lifts everyone’s minimum length by one.
  3. Induction turns this into a lower bound written in terms of the count of successful rounds.
  4. Concentration in a typical execution replaces that count by (1 minus epsilon) f per round.

What to watch for

The rate is stated for stretches of at least lambda rounds, so it says nothing about a single round, and it is expressed through f: a badly calibrated difficulty shows up directly as slow growth, which then delays transaction confirmation.

Useful background: Typical executions and the honest majority assumption.

Papers

Chain quality

In any sufficiently long run of consecutive blocks of an honest party’s chain, the fraction of blocks mined by the adversary stays below roughly t over n minus t.

Why it is useful

Applications read the chain and trust what they read. A ledger needs honest blocks to carry honest transactions, and a voting-style protocol needs honest inputs to outnumber adversarial ones. Chain quality is the promise that the adversary cannot flood a stretch of chain with its own blocks.

How it works

  1. Look at a window of consecutive blocks and the rounds in which it was produced.
  2. In a typical execution the adversary’s successes over those rounds sit close to their expectation, which stays below honest production whenever t is at most (1 minus delta) times (n minus t).
  3. Comparing the two counts gives the honest fraction mu equal to 1 minus (1 plus delta over 2) times t over (n minus t) minus a small error term.
  4. A corollary: any stretch of about 2 lambda f consecutive blocks contains at least one honest block.

What to watch for

This is not proportional representation. The adversary can beat its share of hashing power in blocks by holding back a private chain and releasing blocks just as honest ones appear, a selfish-mining style attack. The paper shows its upper bound is tight in its model, so block share, and therefore reward share, need not track power.

Useful background: Common prefix, Typical executions and the honest majority assumption.

Papers

Characteristic strings and forkable strings

Write down one bit per slot: 0 if an honest party led that slot, 1 if the adversary did. A fork is a tree-shaped summary of the chains honest parties could end up holding, and the string is called forkable when it lets the adversary make two honest observers adopt equally long chains that split apart.

Why it is useful

It turns a question about a distributed protocol into a counting question about bit strings, so the security proof can measure how rarely the adversary receives a string that permits splitting the chain.

How it works

  1. Mark each slot honest or adversarial to build the characteristic string.
  2. Honest parties always extend a longest available chain, so the chains they broadcast form a tree in which honest vertices appear at strictly increasing depths.
  3. Two observers who leave and return can be shown different chains only if the string admits two edge-disjoint chains of equal maximal length.
  4. Counting shows such forkable strings are rare when each slot is adversarial with probability below one half: the chance of a common-prefix violation drops exponentially in the depth parameter.
  5. Common prefix, chain growth and chain quality are then stated as properties of the string and transferred back to the protocol.

Example

A string of all honest slots forces every observer onto one chain; a long run of adversarial slots gives the adversary room to grow two separate histories.

What to watch for

The bound proved in this paper is sub-exponential: it falls like two to the minus square root of the depth parameter. The authors report that follow-up work closes this gap to a fully exponential drop.

Useful background: Ledger persistence and liveness, Proof-of-stake slot leader election.

Papers

Common prefix

Cut the last k blocks off any honest party’s chain. What remains must be a prefix of the chain held by every other honest party, at that round and at every later round.

Why it is useful

This is the agreement statement of the engine. Every conclusion of the form "everyone sees the same history" is derived from it, including the fact that a transaction k blocks deep cannot be removed by rebuilding the chain, which is exactly what a double-spending attacker needs to do.

How it works

  1. A round in which exactly one honest party succeeds is special: its block reaches everyone, and no other honest party can produce a competing block at the same height in that round.
  2. To keep two deep chains alive that disagree, the adversary must answer each such uniquely successful round with a block of its own.
  3. Counting both sides over the rounds in question shows the adversary falls behind whenever t over n minus t is bounded below one.
  4. So two chains that both survive pruning by k blocks cannot disagree, and k of about 2 times lambda times f blocks suffices.

What to watch for

The guarantee weakens as f grows: on a slow network, where messages take about as long as a block, almost everyone has to be honest for common prefix to hold at all.

Useful background: Proof of work as the source of randomness, Bitcoin backbone protocol.

Papers

Covert adversaries in proof of stake

A covert adversary never signs two different blocks for the same slot. It may still extend short chains, but everything it does can be explained as network delay.

Why it is useful

A general adversary can sign several blocks for one slot, and each extra signature is visible evidence of cheating. Restricting to one block per slot models attackers who prefer not to be caught, and makes the counting simple enough for tighter bounds.

How it works

  1. Treat each broadcast block for a slot beyond the first as an audit trail the adversary cannot deny.
  2. Under the one-block-per-slot restriction, a string is covertly forkable exactly when adversarial slots are at least half of it, a plain majority count.
  3. The tighter analysis shortens confirmation times, so a user waits fewer minutes for the same assurance.

Example

At 99.9 percent assurance against a party holding 20 percent of the stake, the reported wait is 7 minutes for the covert case and 12 minutes in general, against 110 minutes for Bitcoin.

What to watch for

The faster numbers hold only against attackers who keep to one block per slot; against general adversaries the paper reports a smaller speedup. The comparison also depends on the parameters chosen, here 20-second slots against 10-minute Bitcoin blocks.

Useful background: Characteristic strings and forkable strings.

Papers

Epochs and frozen stake snapshots

Time is grouped into epochs of R slots. The leaders for an epoch are computed once, from a snapshot of who owns what, taken from a block that is already old when the epoch starts.

Why it is useful

Stake moves constantly. Freezing it once per epoch gives every party the same distribution to elect from and gives the analysis a fixed target, while ownership changes still take effect at the next boundary.

How it works

  1. The first epoch uses the stake list written into the genesis block.
  2. For each later epoch, the effective distribution is read from the most recent block stamped before a cutoff placed a fixed number of slots before the epoch boundary.
  3. The cutoff is early enough that all honest parties already agree on that block.
  4. The committee elected for the epoch runs the randomness protocol; its output fixes the whole leader schedule for the following epoch.
  5. Transfers made inside an epoch are simply ignored until the next snapshot.

What to watch for

The cutoff and the whole argument assume the chain properties held up to that point. Participants must also come back online often enough to know the recent chain.

Useful background: Proof-of-stake slot leader election.

Related ideas

Papers

Final versus tentative consensus

BA⋆ labels its outcome. Final consensus means no other block can be agreed for that round, and a transaction in a final block is confirmed. Tentative consensus means the protocol settled on a block for this user but could not prove that no one else settled differently, so confirmation waits for a later final block.

Why it is useful

A user can pass the vote threshold because an adversary delivered extra votes to it alone, or because the network was partitioned; in those cases two honest users could hold different blocks for the same round. Splitting the outcome into final and tentative keeps that possibility visible instead of hiding it, and safety is promised only for final blocks.

How it works

  1. A block is marked final only if agreement was reached in the very first step and a special final-step vote confirms that enough users saw it.
  2. Tentative outcomes arise either with small probability under a good network, or whenever the network was only weakly synchronous and forks may exist.
  3. Users on different forks stop counting each other’s votes, so Algorand periodically runs agreement again on which fork to adopt, using seeds and weights from before the fork.
  4. Under weak synchrony every period of length b must contain a strongly synchronous stretch of length s for that recovery to succeed.

Example

If a partition makes two groups agree on two different blocks, both results are tentative and the next final block, after the network heals, decides which history survives.

What to watch for

Tentative blocks are not yet money in the bank: a user confirms their transactions only when a successor block reaches final consensus. The paper bounds how long recovery takes by assumption, not by construction.

Useful background: BA⋆ Byzantine agreement, Algorand.

Papers

Honest-majority and synchrony assumptions

Algorand’s guarantees are conditional. Safety needs more than 2/3 of all money held by honest users; liveness additionally needs a strongly synchronous network most of the time, where most honest users can reach most other honest users within a known bound.

Why it is useful

Agreement protocols cannot succeed against an arbitrary majority of faults, so the design question is what fraction and what network to assume, and how expensive the recovery is when the assumption temporarily fails. Stating the assumptions over money, and over bounded adversarial periods, is what lets Algorand stay safe through a bad day and still make progress afterwards.

How it works

  1. Safety rests on weak synchrony: the adversary may control the whole network for a bounded period, but every window of length b must contain a strongly synchronous stretch of length s.
  2. Liveness rests on strong synchrony: most honest users (the paper suggests 95%) must deliver messages to most other honest users within a known time bound.
  3. The honest fraction h of money must carry over to the committee, so the expected committee size τ and the vote threshold T are chosen so that a sampled committee is honest enough except with tiny probability.
  4. As h approaches 2/3 the required committee size grows quickly; at h = 80% a committee of 2,000 keeps the failure probability near 5×10^-9.

Example

With 80% of the money honest, the prototype uses committees of 2,000 for ordinary steps and 10,000 for the final step, which is why finality costs extra votes.

What to watch for

These are assumptions, not achievements: an attacker holding a third of the money, or a network outage longer than the assumed bound, breaks the corresponding guarantee. The paper also assumes bug-free honest software, standard signature and hash security, and loosely synchronized clocks for recovery.

Useful background: BA⋆ Byzantine agreement, Stake weights against Sybil attacks.

Papers

HotStuff

HotStuff is the partially synchronous Byzantine fault tolerance protocol this paper builds on: a stable leader drives voting in phases, blocks are chained by hashes and certificates, and replicas collect votes into certificates instead of all-to-all exchanges.

Why it is useful

It supplies a simple leader-based shape that already worked in practice and an open-source implementation, so the synchronous variant could share the code base and be compared against it fairly.

How it works

  1. A leader proposes a block extending the previous one; replicas vote, and a quorum of votes forms a certificate for the block.
  2. Blocks are chained by hash digests and by certificates, an idea the paper traces to Bitcoin and says was brought into Byzantine fault tolerance by Casper and HotStuff.
  3. Sync HotStuff keeps HotStuff’s two-phase leader-based structure and block chaining; what changes is what the timing assumption buys, not the overall shape.
  4. For the same number f of faults, HotStuff runs on 3f + 1 replicas where the synchronous protocol needs only 2f + 1.

Example

Illustration: to tolerate one fault, HotStuff needs 4 replicas while the synchronous protocol needs 3, which is why the synchronous setting can look faster at high fault counts.

What to watch for

This lesson reports only what this paper says about HotStuff as a baseline; HotStuff does not assume synchrony, so the authors themselves call the head-to-head performance comparison not entirely fair.

Useful background: State machine replication.

Related ideas

Papers

Input endorsers and the reward mechanism

Each slot gets a second elected role besides the leader: an input endorser that collects and signs the transactions to be included. Rewards are paid from a pool of transaction fees shared among the committee members and endorsers of an epoch.

Why it is useful

If rewards depended only on issuing blocks, a coalition could withhold blocks and starve honest parties of income. Paying for endorsed inputs, which survive block withholding, removes that lever and makes honest behavior an approximate Nash equilibrium.

How it works

  1. Endorsers are selected by stake weight in the same way as slot leaders.
  2. A leader must include any endorsed inputs from the previous d slots that are not yet in the chain; if there is nothing to include it issues an empty block.
  3. Fees collected in an epoch go into one pool shared among that epoch’s leaders and endorsers.
  4. Committee members are rewarded for being elected whether or not they issued a block, and endorsers are paid per endorsed input.
  5. Because endorsed inputs eventually enter the chain, a coalition cannot reduce honest parties’ shares by withholding blocks.

What to watch for

The equilibrium theorem assumes a fixed player set, no stake movement, negligible protocol cost and a bounded total reward. Bribery attacks and finer-grained reward rules are left open by the authors.

Useful background: Proof-of-stake slot leader election, Ledger persistence and liveness.

Related ideas

Papers

Leader-based commit phases in Sync HotStuff

The steady state is three phases, propose, vote and commit: the leader proposes a block, each replica forwards the proposal and broadcasts a signed vote, and a background commit timer of 2∆ decides finality.

Why it is useful

Putting the waiting into a timer instead of a blocking round is what makes a synchronous protocol practical: replicas keep voting on new blocks while older blocks are still becoming final, so the conservative bound ∆ never throttles throughput.

How it works

  1. Propose: when the leader holds a certificate for block k − 1, it broadcasts a new block k that extends it, together with that certificate.
  2. Vote: a replica that has detected no leader equivocation forwards the proposal to all other replicas and broadcasts its vote, so a proposal spreads even if the leader sends it to only a few replicas.
  3. Commit: the voter sets a commit timer for that height to 2∆ and commits the block, and all its ancestors, if the timer runs out with no equivocation and no view change.
  4. Chain: because blocks are linked by hashes, a vote for a block is also a vote for its uncommitted ancestors, so one commit finalizes a whole suffix of the log.

What to watch for

A commit by one honest replica does not force a commit by all: a Byzantine leader can send conflicting proposals to a subset of replicas before their timers expire, so view-change rules are still needed to stop later conflicts.

Useful background: Sync HotStuff, Blocks, quorum certificates and locks.

Papers

Ledger persistence and liveness

A transaction ledger is called robust when two properties hold. Persistence says that once a transaction is buried more than k blocks deep, every honest party reports it in the same position. Liveness says that a transaction honest parties keep trying to include becomes stable within a bounded number of slots.

Why it is useful

These are the promises a user actually sees: a confirmed payment does not vanish or move, and a submitted payment eventually confirms. The rest of the analysis exists to make both hold with high probability.

How it works

  1. A transaction counts as stable only when it sits more than k blocks deep, so k is how much certainty a user buys by waiting.
  2. Both properties are derived from three easier-to-check chain properties: common prefix, honest chain growth and existential chain quality.
  3. Common prefix: the chains held by two honest parties agree once the last k blocks are removed from the earlier one.
  4. Honest chain growth: over any long enough stretch of slots, the chain of an honest party gains at least a fixed fraction of that many blocks.
  5. Existential chain quality: every long enough stretch of an honest chain contains at least one honestly generated block.

What to watch for

The guarantees are conditional on the model: a synchronous network where a message always arrives within one slot, honest parties holding a majority of the stake, and participants not staying offline for long periods.

Useful background: Proof-of-stake slot leader election.

Papers

Player replaceability

A committee member speaks once per step and then becomes useless to the protocol: no state, keys aside, is kept between steps, and the next step selects a fresh committee. Anyone can therefore verify votes and follow the agreement without being selected at all.

Why it is useful

Once a member sends a message its identity is exposed, and a fast adversary could corrupt or disconnect exactly those users. Because members carry no private state beyond their key and serve only one step, attacking them after the fact buys nothing; the protocol simply moves on with new people.

How it works

  1. Each step starts with a new sortition, so the set of speakers changes constantly.
  2. A selected user signs and gossips one message, and the secret it needed for that message is its ordinary signing key.
  3. Every other user passively verifies signatures and sortition proofs, counts votes, and reaches the same decision without ever being selected.
  4. The paper notes a forward-security variant: users could delete a key after signing and pre-commit to a chain of future keys, so stolen keys cannot forge old certificates.

Example

A committee member that is disconnected right after voting has already finished its job for that step, and the vote it sent still counts.

What to watch for

Replacement blunts, but does not remove, targeted attacks: a very fast adversary can still knock a user offline while that user’s block is still being transmitted, so liveness in practice assumes the attacker needs at least the seconds it takes to send a block.

Useful background: BA⋆ Byzantine agreement, Cryptographic sortition: selecting yourself.

Papers

Proof of work as the source of randomness

A block counts only when someone finds a counter ctr with H(ctr, G(s, x)) below the target T and ctr at most q. The search is a lottery: each query wins with probability near T over 2 to the kappa, so the chance of mining the next block tracks how many queries a party can afford.

Why it is useful

The network is anonymous. There are no identities, no membership list and no trusted setup, so there is no fair way to name the next writer. Paying for influence with computation is the substitute: it cannot be faked, it is roughly proportional, and the winner is unpredictable to everyone, including an adversary who moves last in each round.

How it works

  1. Model the hash function as a random oracle, so every fresh query returns an independent random value.
  2. Give every honest party the same quota of q queries per round, and the adversary t times q for the t parties it controls; a mining pool is just several flat parties glued together.
  3. Watch f, the probability that at least one honest party solves the puzzle in a round. It is the one knob the whole analysis turns.
  4. Retune the target T as participation changes, to keep f inside a chosen range.

What to watch for

The random oracle is an idealization of SHA-256, and the analysis covers a single execution in isolation, so work done in another run cannot be imported. The difficulty also has to sit in a window: the paper notes Bitcoin retunes every 2016 blocks to keep f around 2 to 3 percent.

Useful background: Bitcoin backbone protocol.

Papers

Proof-of-stake slot leader election

Instead of racing to solve hash puzzles, the protocol divides time into slots and gives one party the sole right to issue the block for each slot. That party, the slot leader, is drawn at random with probability equal to its share of the coins recorded in the ledger.

Why it is useful

Proof of work elects the next block issuer roughly in proportion to computing power, and pays for that with electricity. Proof of stake pursues the same goal while the only resource consumed is stake the party already owns, so the ledger maintains itself.

How it works

  1. A first block (the genesis block) lists every participant by public key, with its stake and a random seed value.
  2. A leader selection function takes the stake list, the seed and a slot number, and returns one participant, chosen with probability equal to that participant’s stake divided by the total stake.
  3. The choices for different slots are independent, so one lucky draw does not concentrate power.
  4. The leader of a slot signs the block it produces, and everyone else checks that signature against the leader recorded for that slot.
  5. Everyone extends the longest valid chain it has seen, as in Bitcoin.

Example

A party holding 30 percent of the stake leads about 30 percent of slots on average; a party holding 1 percent leads about one slot in a hundred.

What to watch for

Proportionality holds only while honest parties hold most of the stake and the seed is unbiased. The paper notes that in proof of work, deviations from the protocol can distort the corresponding proportionality, as in selfish mining.

Useful background: Digital signatures, Proof-of-work blockchains.

Related ideas

Papers

Responsiveness and optimistic responsiveness

A protocol is responsive when its commit latency depends only on the actual network delay δ and not on the assumed maximum ∆; it is optimistically responsive when it manages that only while extra conditions hold, here fewer than one-quarter of the replicas being faulty.

Why it is useful

With minority fault tolerance a single honest vote can complete a certificate, so a replica must wait long enough to hear every honest replica before committing, which ties latency to ∆. Larger quorums, which cannot be assembled twice for conflicting blocks, remove the need to wait.

How it works

  1. In the synchronous mode, a replica waits to hear all honest replicas’ votes and checks that none voted for a conflicting block, so commit latency inherently depends on ∆.
  2. Partially synchronous protocols such as PBFT use quorums above two-thirds of replicas, where two conflicting certificates cannot both exist, so they commit as soon as the quorum arrives and their latency does not depend on ∆.
  3. Sync HotStuff gives each leader two views: odd views run the synchronous protocol, even views run a responsive one in which certificates need more than three-quarters of the replicas.
  4. Above a 3n/4 quorum, two conflicting certificates would require more than n/2 faulty voters, impossible with minority faults, so the responsive view commits after two voting rounds at network speed; if faults reach one-quarter, the protocol falls back to the synchronous mode.

Example

Illustration with n = 100 replicas: while fewer than 25 are actually faulty, blocks finalize at network speed; between 25 and 50 faults, blocks still finalize safely but only after the 2∆ wait.

What to watch for

Responsiveness is conditional: with more than one-quarter of replicas faulty but fewer than one-half, agreement survives while speed does not. The idea comes from Thunderella, whose one-round decision cannot be conveyed to external clients, which is why this protocol commits in two rounds.

Useful background: Sync HotStuff, Leader-based commit phases in Sync HotStuff, Blocks, quorum certificates and locks.

Related ideas

  • HotStuff: the responsiveness notion the HotStuff line inherits and the synchronous variant re-earns under weaker assumptions

Papers

Stake grinding on leader-selection randomness

Grinding is an attack on the randomness that picks slot leaders. The adversary privately tries many candidate blocks or continuations and publishes only the one that makes future leader draws favor it.

Why it is useful

Proof of stake needs fresh randomness for every election, but anything the adversary can influence, such as data taken from its own blocks, becomes a knob it can turn to bias the next election.

How it works

  1. Simulate the protocol privately for many candidate continuations.
  2. Keep the continuation that awards the adversary the most future leadership slots.
  3. Repeat every time new randomness is derived from attacker-influenced data.
  4. Ouroboros instead draws randomness from a multiparty coin-tossing protocol run by the elected committee, and proves the resulting value is uniform, so there is no knob to turn.

What to watch for

The defense rests on the coin-tossing protocol producing unbiased output. Designs that read randomness out of block headers or contents remain exposed to grinding.

Useful background: Proof-of-stake slot leader election.

Related ideas

Papers

Standard synchrony and minority fault tolerance

Standard synchrony is the promise that every message an honest replica sends reaches every other honest replica within a known time bound, written ∆. The paper writes δ for the delay actually observed, which is usually far smaller than ∆.

Why it is useful

Agreement has limits without timing information. With a known delay bound a protocol tolerates faulty replicas forming a minority (n = 2f + 1), while asynchronous and partially synchronous protocols tolerate only one-third faults.

How it works

  1. Fix ∆, a maximum message delay known before the protocol runs, and let δ be what the network actually does.
  2. Use ∆ to time waits: a message that has not arrived after ∆ was either never sent or the bound is wrong.
  3. Treat silence as evidence, because delivery within ∆ is guaranteed, so a missing message accuses its sender.
  4. Compare the fault tolerance honestly: synchrony buys one-half faults, at the price of an assumption an attacker can attack by delaying traffic.

Example

Illustration: with ∆ = 50 milliseconds as in the paper’s experiments, a commit wait of 2∆ is 100 milliseconds even when the real network delay δ is under 1 millisecond.

What to watch for

A protocol proven safe under standard synchrony can lose safety if a single honest-to-honest message is slower than ∆, and the model also assumes replica clocks do not drift, which real deployments do not guarantee.

Useful background: State machine replication.

Related ideas

Papers

Sync HotStuff

Sync HotStuff is the paper’s synchronous Byzantine fault tolerance protocol for state machine replication: a leader broadcasts a proposal, the replicas echo it, and each replica commits after waiting one maximum round-trip (2∆) unless it hears an equivocating proposal signed by the leader.

Why it is useful

Synchronous protocols tolerate minority faults but were considered impractical, because they needed many rounds, lock-step execution and a fragile timing promise. Sync HotStuff keeps the fault tolerance while running at network speed in the common case and needing no lock-step.

How it works

  1. In each view a leader proposes blocks, replicas forward each proposal and vote for it.
  2. A replica that voted sets a timer of 2∆ and commits the block if the timer expires with no leader equivocation and no view change.
  3. Committing a block commits all its ancestors, so blocks pipeline: the next block is proposed before the earlier one is final.
  4. When the leader stalls or equivocates, replicas blame it and change views; under the mobile sluggish model, extra pre-commit and commit rounds replace the assumption that every honest replica hears everything.

Example

Illustration of one block: the leader signs block 7 extending block 6, each honest replica forwards it and votes, and if no conflicting signed proposal appears within 2∆ then block 7, and with it block 6, is final for every replica that voted.

What to watch for

Safety rests on the synchrony bound and on equal-rate clocks, the 2∆ wait is only conjectured to be necessary (the proven bound is ∆), and the reported throughput comes from a prototype on machines with sub-millisecond network delay.

Useful background: State machine replication, Standard synchrony and minority fault tolerance, Blocks, quorum certificates and locks.

Related ideas

Papers

The mobile sluggish model

A weaker synchrony model in which some honest replicas are sluggish: messages sent to or by them may be delayed arbitrarily, while prompt replicas still deliver within ∆. The adversary chooses which replicas are sluggish at every instant.

Why it is useful

Under standard synchrony, one delayed honest message can break safety, and counting every delayed replica as Byzantine eventually makes a majority look dishonest over a long run. A realistic model has to tolerate slow-but-honest replicas instead of blaming them.

How it works

  1. Call a replica sluggish when the delay bound fails for its messages, and prompt otherwise.
  2. Let the sluggish set change arbitrarily over time, so no replica can be written off permanently.
  3. Keep sluggish plus Byzantine replicas below one-half of all replicas, so at any moment a majority is honest and prompt.
  4. Adapt the protocol rather than the fault count: start a block’s timer only once a proposal carrying its certificate arrives from f + 1 replicas, and commit only after f + 1 replicas report no leader equivocation during the period.

What to watch for

The model captures short network glitches, not a replica going offline for a long stretch, and liveness still needs f + 1 honest replicas, the leader included, to stay prompt long enough to finish committing a block.

Useful background: Standard synchrony and minority fault tolerance.

Related ideas

  • Sync HotStuff: the protocol this model forces the paper to modify

Papers

Typical executions and the honest majority assumption

The proofs do not cover every execution. They define a typical one, where over any lambda consecutive rounds the honest and adversarial block counts stay near their expectations and no block was inserted, copied or predicted, and then show that almost all executions are typical.

Why it is useful

Each property is a statement about counts of random events over long stretches. Concentration bounds deliver exactly that, and collecting all the unlucky outcomes into one definition keeps the later proofs short.

How it works

  1. For each round record whether some honest party succeeded (X), whether exactly one did (Y), and how many adversary queries succeeded (Z).
  2. Typical means X and Y stay near their expectations and Z does not overshoot by much, and none of the three structural accidents happened.
  3. A Chernoff bound plus the absence of hash collisions gives failure probability that is negligible in the security parameter.
  4. The honest majority assumption, t at most (1 minus delta) times (n minus t) with 3f plus 3 epsilon below delta, then leaves the honest side enough margin to absorb the slack.

What to watch for

Typicality is probabilistic. An adversary that gets unusually lucky, or two honest parties that query the oracle on the same input, are excluded only with overwhelming probability, and the random-oracle idealization is doing real work in that step.

Useful background: Proof of work as the source of randomness.

Papers

What the backbone analysis does not promise

The guarantees are proved for a fixed participant set, an idealized hash function, a stand-alone execution and a network that synchronizes much faster than blocks are found. Separately, chain quality does not make a miner’s block share equal to its share of the hashing power.

Why it is useful

Each condition marks a boundary. Step outside it and the system keeps running while the proofs stop applying, so it is worth knowing where the edges are before choosing a block interval or a reward schedule.

How it works

  1. Compare message propagation time with the block interval. The paper puts Bitcoin’s roughly ten-minute interval against propagation measured in seconds and warns that chains with one-minute blocks sit far outside the analysis.
  2. Use t over (n minus t), not t over n, as the ceiling on the adversary’s share of blocks, and remember that rewards follow block share.
  3. Treat difficulty recalibration, changing populations and purely rational miners as unproved; the paper points to follow-up work for composition, incentives and variable difficulty.

What to watch for

These are limits of the theorem statements rather than defects of any particular deployment, and later work extends the model rather than contradicting these results.

Useful background: Robust public transaction ledger, Chain quality.

Papers

The mathematics behind cryptography

Learn the number systems, groups, curves, lattices and algorithms used by cryptographic constructions. The same mathematical object can support several different security goals.

Bernstein-Rabin-Winograd polynomials

Bernstein-Rabin-Winograd polynomials organize message blocks for polynomial hashing.

Papers

Bitslicing

Bitslicing evaluates Boolean circuit operations in parallel across machine-word bits.

Papers

Boyar-Peralta circuit optimization

Boyar-Peralta heuristics search for Boolean circuits implementing linear maps and S-box components.

Papers

Double-base number system

Double-base number systems encode integers as sums of products of powers of two bases.

Papers

Integral Gram-root Gaussian sampling

Integral Gram-root sampling replaces a real covariance-matrix decomposition with a wider integer decomposition.

Papers

Klein sampler

Klein's algorithm samples lattice vectors using randomized nearest-plane steps.

Papers

Nussbaumer multiplication

Nussbaumer multiplication uses polynomial-ring transforms for recursive multiplication.

Papers

Peikert Gaussian sampler

Peikert's lattice sampler uses perturbation and rounding to sample discrete Gaussian lattice vectors.

Papers

Toom-Cook multiplication

Toom-Cook multiplication splits operands and reconstructs their product through evaluation and interpolation.

Papers

Boolean functions and discrete structures

Boolean and vectorial functions, combinatorial designs, expanders and algebraic group actions used as cryptographic building blocks.

Coding theory for cryptography

Error-correcting codes, code equivalence and decoding mathematics, shared by code-based primitives and proof systems.

Code metrics, equivalence and decoding

Hamming and rank metrics, syndromes, code equivalence, and efficient or hard decoding regimes for structured and random codes.

Bit-flipping decryption of MDPC codes

The decoder is Gallager bit flipping: count how many parity checks each bit violates, flip the bits with the worst counts, recompute the syndrome, and repeat until it is zero.

Why it is useful

It is the standard way to exploit a sparse parity-check matrix, and its cost grows with the product of code length, row weight and the number of iterations.

How it works

  1. At each iteration, count the unsatisfied parity-check equations associated to each bit.
  2. Flip every bit whose count exceeds a threshold b, then recompute the syndrome.
  3. Set b one small step below the current maximum count, that is b = Maxupc - δ.
  4. On failure, lower δ by one and restart; δ near 5 cut the iteration count from about 65 to under 10.

What to watch for

The threshold offset δ is tuned empirically rather than derived, and denser rows plus short cycles in the Tanner graph, the bipartite graph linking bits to the checks that cover them, push the iteration count up.

Useful background: Moderate-density parity-check codes.

Papers

Moderate-density parity-check codes

A moderate-density parity-check (MDPC) code is a linear code that admits a parity-check matrix of constant row weight w, where w is neither tiny nor full: the paper lets it grow on the order of the square root of n log n.

Why it is useful

Making the rows only moderately heavier pushes the cost of finding low-weight dual codewords above the cost of the best decoding attacks, with no extra disguising matrices needed on top.

How it works

  1. Pick a random parity-check matrix of row weight w; with overwhelming probability it has full rank.
  2. The row weight is the security knob: heavier rows hide the dual codewords, lighter rows decode more errors.
  3. Error correction degrades relative to LDPC codes, but cryptography only needs to correct enough errors to match the security target.

Example

The 80-bit quasi-cyclic parameters use row weight w = 90 at length n = 9602, against row weights below 10 for communications LDPC codes.

What to watch for

The definition fixes a magnitude, not a number; the paper separates LDPC from MDPC only by how w scales, and the error-correction analysis for MDPC codes is coarser because of short cycles in the associated Tanner graph.

Useful background: Why low-density parity-check codes were attacked.

Papers

Quasi-cyclic MDPC codes

A QC-MDPC code is an MDPC code whose parity-check matrix is a row of circulant blocks, square blocks where each row is the previous row shifted one place, so the entire matrix is determined by one secret row of weight w.

Why it is useful

Cyclic shifts are free to store: each block is its own rotations, so the key material collapses to a single row while the code stays as long as security needs.

How it works

  1. Set n = n0 p and r = p so the matrix H is a concatenation of circulant blocks.
  2. Draw the first row of H at random with weight w; the other rows are its cyclic shifts.
  3. Circulant blocks behave like polynomials modulo x^p - 1, so products reduce to polynomial arithmetic.

What to watch for

The cyclic structure is public, not hidden; the argument for keeping it is empirical, that quasi-cyclicity alone has not helped attackers when no algebraic code structure is present.

Useful background: Moderate-density parity-check codes.

Papers

Rank-metric cryptography

Rank-metric constructions encode errors by matrix rank over an extension-field representation.

Papers

The security basis: one decoding problem

Under one stated assumption, breaking MDPC-McEliece is no easier than syndrome decoding for a random linear code, that is, finding the low-weight error vector that produces a given syndrome; for the quasi-cyclic variant the target problem is syndrome decoding for a random quasi-cyclic code.

Why it is useful

The original McEliece needed two assumptions and the indistinguishability half was the weak one; folding both into a single well-studied decoding problem is the central security argument of the paper.

How it works

  1. A generic reduction turns any adversary into either a decoder for random codes or a distinguisher for the key space.
  2. The assumption states that distinguishing the MDPC key space is no easier than deciding whether the dual code has words of weight w.
  3. Deciding and finding such words are polynomially equivalent, and finding them is equivalent to syndrome decoding.
  4. In practice the best attacks, key distinguishing, key recovery and decoding, are all costed with information-set decoding.

What to watch for

The reduction is conditional on the assumption, and the quasi-cyclic variant rests on the hardness of decoding random quasi-cyclic codes, a less studied problem than decoding fully random codes.

Useful background: MDPC-McEliece encryption.

Related ideas

Papers

Why low-density parity-check codes were attacked

Low-density parity-check (LDPC) codes have a very sparse parity-check matrix, and that sparsity betrays them here: the sparse rows are low-weight codewords of the dual code, the code spanned by the rows of the parity-check matrix itself, and an attacker can search for those words directly.

Why it is useful

Sparse rows are exactly what makes LDPC decoding fast, and such codes carry no algebraic structure, so they looked ideal for a McEliece variant until the dual-codeword search proved feasible at ordinary LDPC densities.

How it works

  1. The private key is a sparse parity-check matrix H of constant row weight w; the public key is a dense scrambled generator matrix.
  2. An attacker searches the dual of the public code for low-weight codewords.
  3. Finding one such word gives an equivalent sparse parity-check matrix, which breaks the scheme.

What to watch for

The analysis applies at the small row weights used in communications; raising the row weight changes the cost of the search completely, which is the idea of the next lesson.

Useful background: Why McEliece keys are huge.

Related ideas

Papers

Evaluation codes and algebraic coding

Polynomial and algebraic-geometric evaluation codes, folding, interleaving and list decoding. Interactive proximity protocols belong under proofs.

Folded Reed-Solomon codes

Folded Reed-Solomon codes group evaluation symbols of an RS codeword.

Papers

Reed-Muller codes

Reed-Muller codes encode multivariate polynomial evaluations.

Papers

Reed-Solomon codes

Reed-Solomon codes encode polynomial evaluations over a selected domain.

Papers

Univariate multiplicity codes

Univariate multiplicity codes encode polynomial values together with derivative evaluations.

Papers

Computational number theory and groups

Integer, number-field and group algorithms underlying cryptographic arithmetic and computational problems.

Signed quadratic residues

Signed quadratic residues are a way to represent a group of squares modulo a composite number while treating an element and its negative as the same signed representative. Group operations include converting the result back to its chosen representative.

Why it is useful

In the paper's safe-prime setting, membership can be checked efficiently. This avoids requiring a verifier to solve the harder quadratic-residuosity membership problem.

How it works

  1. Use the modulus and group conditions required by the construction.
  2. Represent the pair of signs by the prescribed nonnegative representative.
  3. Multiply modulo the modulus and then convert back to that representative.
  4. Check the representation and Jacobi-symbol conditions for values supplied to the verifier.

What to watch for

This description depends on the safe-prime algebraic setting in the paper. It is not a rule for replacing arbitrary groups by absolute values.

Related ideas

  • Pietrzak VDF: Uses this representation to make the proof's group-membership checks practical.

Papers

Class groups and hidden-order arithmetic

Ideal class groups, quadratic forms and other hidden-order group representations, including arithmetic and order computation.

Factoring and discrete-logarithm algorithms

Classical algorithms for integer factorization and discrete logarithms in generic or explicitly represented groups.

Index calculus

Index-calculus algorithms collect relations over a factor base to compute discrete logarithms.

Papers

Number field sieve

The number field sieve collects algebraic and rational relations for integer factorization or finite-field discrete logarithms.

Papers

Pollard rho

Pollard rho uses pseudorandom walks and collision detection for discrete-logarithm or factorization problems.

Papers

The exponent q-SDH problem and discrete log

The exponent q-SDH problem: given (g1, g1^x, g1^(x^2), ..., g1^(x^q)), output g1^(x^(q+1)) - the next power on the ladder, one rung past the last one handed over.

Why it is useful

It is equivalent to q-wDH, and it is the precise member of the family whose security Cheon analyzed, which is where these problems sit relative to the discrete logarithm problem.

How it works

  1. A discrete-log solver finishes it immediately: recover x from g1^x, then compute x^(q+1) yourself and raise g1 to it.
  2. Cheon's analysis - cited by the note but not reproduced in it - showed that for large q, with suitable divisibility between q and the group order p, the secret x can be recovered faster than the generic square-root cost of discrete log.
  3. For parameter selection this means a pairing scheme resting on q-SDH must choose p so the family stays hard against these faster algorithms, not merely against generic discrete log.

What to watch for

The note's only sentence on this is that Cheon deeply investigated the problem; the description of his result above is context from the cited literature, not something this note states or proves.

Useful background: The q-SDH reduction ladder, The q-weak Diffie-Hellman problem.

Related ideas

  • Discrete logarithm: the problem a solver of which finishes this one outright

Papers

Curves, pairings and isogeny geometry

Algebraic curves as the source of cryptographic groups: the paper works with the Jacobian of a hyperelliptic curve, a finite abelian group whose discrete logarithm problem underlies hyperelliptic cryptosystems, and studies how the difficulty of that problem depends on the genus and the size of the base field.

A simplified double large prime algorithm

A deliberately weakened version of the double large prime attack that can be analysed: the large prime graph grows only as a tree rooted at the special vertex, and the run is split into three phases.

Why it is useful

The cycle structure of the full algorithm resists analysis, so the authors simplify until the running time can be bounded rigorously, at a small cost in efficiency, and prove a complexity of order q to the power 2 minus 2 over g.

How it works

  1. Phase 0: discard everything until one FP relation appears, and attach its large prime to the special vertex as the first edge.
  2. Phase 1: keep only PP relations, and add an edge only if it both touches the existing tree and creates no cycle.
  3. Phase 2: freeze the graph and accept any relation whose large primes all lie in the tree; rewriting those large primes along the tree turns each accepted relation into a row of the matrix.
  4. Choose the target tree size to balance relation collection against linear algebra; the optimum sets the factor base exponent r to 1 minus 1 over g.
  5. The expected running time is then of order q to the power 2 minus 2 over g for fixed genus at least 3.

Example

From the paper’s table for almost-prime-order groups: at genus 3 the cost drops from q to the 1.5 (Pollard rho) and q to the 10 over 7 (single large prime) to q to the 4 over 3 (double large prime); at genus 4 from q squared to q to the 1.5.

What to watch for

The proof covers hyperelliptic curves in imaginary Weierstrass form with cyclic Jacobian group. Restricting to a tree also shrinks memory well below the full algorithm’s needs, but the full algorithm is the faster one in practice.

Useful background: The double large prime variation.

Related ideas

Papers

Bandersnatch curve

Bandersnatch is an elliptic curve defined over the 255-bit scalar field of BLS12-381. It has j-invariant 8000, order 4r for a prime r, and a fundamental discriminant D = -8, so its endomorphism ring is Z[sqrt(-2)]. Its quadratic twist, a companion curve over the same field whose order complements the original, has order 2^7 * 3^3 * r' with r' a 244-bit prime.

Why it is useful

It is a statement curve for proofs over BLS12-381 whose very small discriminant makes the multiplication by sqrt(-2) endomorphism cheap, so scalar multiplications inside circuits are faster than on the earlier embedded curve Jubjub.

How it works

  1. Search discriminants with the CM method over the fixed field of size q.
  2. Require an order of the form 4r with r prime, which permits a Montgomery model, a curve shape with fast arithmetic, and cofactor handling with Decaf or Ristretto.
  3. Require a twist order with a large prime factor, which blocks twist subgroup attacks.
  4. Use the endomorphism with the GLV technique to split one scalar multiplication into two smaller ones.

Example

Over the same field the paper finds a second embedded curve of order 4r with discriminant D = -4 * 1030258, showing that Bandersnatch-style security is reproducible.

What to watch for

The paper argues that this curve is lucky rather than unique: tiny discriminant, order 4r and twist security at once is unlikely, and curves with the same order shape exist at larger discriminants, only with a slower endomorphism.

Useful background: BLS12-381, The complex multiplication method for curves of chosen order.

Related ideas

  • Jubjub: The earlier embedded curve over the same scalar field, found by point counting.

Papers

BLS12-381

BLS12-381 is a specific pairing-friendly elliptic curve from the BLS12 family, meaning a curve that supports an efficient bilinear map, called a pairing, which combines two points into a field element. It is generated by the seed x0 = -0xd201000000010000; its base-field prime has 381 bits and its large prime subgroup has a 255-bit order q.

Why it is useful

Many zero-knowledge projects run their proofs on BLS12-381 because its pairing supports pairing-based SNARKs, and its 255-bit scalar field is small enough that statement curves embedded over it stay efficient.

How it works

  1. Evaluate the BLS12 family polynomials p(x), t(x) and q(x) at the seed to obtain the base prime, the trace that fixes the number of points, and the subgroup order.
  2. Derive the curve coefficients with the CM method.
  3. Build the statement curve over the field of size q, so its arithmetic matches the proof circuit field.
  4. Optionally continue the construction with the plain curve that closes a 2-cycle above the embedded curve.

Example

The paper contrasts this with a BN half-cycle: folding happens over 255-bit fields instead of fields of about 384 bits, and the final proof uses the more efficient BLS12-381 pairing.

What to watch for

Once BLS12-381 is fixed, its scalar field is fixed too, so an embedded curve over it cannot also demand a special field shape: the paper's prime-order embedded curve above BLS12-381 lacks the high 2-adicity wanted for Fourier-transform based polynomial arithmetic.

Useful background: Bilinear pairings.

Related ideas

  • BLS12 curves: The pairing-friendly family whose polynomials generate BLS12-381.
  • Bandersnatch curve: An embedded curve defined over the BLS12-381 scalar field.

Papers

BN254

BN254 is a Barreto-Naehrig curve generated by the seed x0 = 0x44e992b44a6909f1; the number 254 is the bit length of its base-field prime. Its family has embedding degree 12, the extension degree its pairing lands in, with discriminant D = -3 and subgroup order polynomial q(x) = 36x^4 + 36x^3 + 18x^2 + 6x + 1.

Why it is useful

It is one of the two pairing-friendly curves that early SNARK constructions were built on, so deployed proof systems compute over its fields, and embedded curves above it keep those systems usable.

How it works

  1. Evaluate the BN family polynomials at the seed to obtain the base prime, the trace and the subgroup order.
  2. Derive the curve with the CM method, using the family discriminant D = -3.
  3. Pair it with a plain embedded curve to form a half-cycle in which proofs alternate between pairing-based and discrete-logarithm steps.

Example

The BN-254 and Grumpkin pair forms the hybrid cycle used by Aztec, alternating a pairing-friendly curve with a plain one.

What to watch for

The paper reports that a BN half-cycle folds over fields of about 384 bits, larger than the 255-bit fields available above BLS12-381, and that the BLS12-381 pairing is more efficient than the one on a prime-order BN curve of that size.

Useful background: BLS12-381.

Related ideas

Papers

brainpoolP256t1

brainpoolP256t1 is a short Weierstrass curve y squared equals x cubed minus 3x plus b over the field modulo the dense 256-bit prime 76884956397045344220809746629001649093037950200943055203735601445031516197751. The constant b is generated by a deterministic Brainpool seed procedure, and the curve is one of the three examples in the paper's Table 1.3.1.

Why it is useful

Brainpool, published in 2005, was a reaction to the unexplained NIST seeds, and its requirements go further in several places: primes congruent to 3 modulo 4, an embedding degree of at least (ℓ−1)/100, and a class number above 1000000. The paper still finds gaps: the seed-generation mechanism was only partially explained, and the twist of this curve does not hold up against combined attacks.

How it works

  1. Field: a "random", dense prime, which makes arithmetic roughly twice as slow as with structured primes and can push protocol designers toward smaller curves.
  2. Equation: short Weierstrass form with a = −3, like the NIST curves.
  3. Generation: a deterministic procedure from digits of pi and e; the paper lists open questions about it and generated more than a billion equivalent alternatives.
  4. Twist: the combined attack costs only about 2 to the power 44.5, the weakest of the paper's three example curves.

Example

Table 1.3.1 of the paper lists this curve next to NIST P-256 and Curve25519, and marks its prime and constant as "dense" and "large" rather than structured.

What to watch for

Brainpool addresses rigidity more seriously than the NIST process did, and its stated requirements are stricter in several places, but the paper still finds the seed procedure only partially explained and shows the twist of this curve does not hold up against combined attacks.

Useful background: Safe curves: ECC security beyond ECDLP security, Rigidity: how the curve was generated.

Related ideas

  • NIST P-256: The curve family whose seeds Brainpool was designed to improve upon.

Papers

Choosing genus for hyperelliptic curve cryptography

The design consequence of the attack: a genus 3 cryptosystem must be sized against index calculus, not only against Pollard rho, and its parameters should be about 12.5 percent larger than a rho-only estimate suggests.

Why it is useful

Index-calculus cost depends on the size of the whole Jacobian, not on the subgroup actually used, so a hyperelliptic group behaves like the multiplicative group of a finite field in this respect and must be sized accordingly.

How it works

  1. Compare attack costs for the genus in question before fixing the field size; at genus 3 the double large prime method costs about q to the 4 over 3 against Pollard rho’s q to the 3 over 2.
  2. Enlarge the group size by about 12.5 percent to keep the intended security level.
  3. Prefer small genus with a large field over large genus with a small field, since large genus makes the problem subexponential.
  4. Do not rely on working inside a proper subgroup, because index calculus ignores subgroups and attacks the full Jacobian order.
  5. Watch memory and parallelism: the attack needs far more storage than Pollard rho and its linear algebra step parallelises poorly.
  6. The same penalty reaches some elliptic-curve systems, namely those over extension fields whose degree is a multiple of 3: Weil descent translates their problem into a genus 3 Jacobian over a smaller field, where this attack applies.

Example

Experiment reported in the paper: for a genus 3 curve over a field of about 2 to the 27 elements, relation search took 9 days and linear algebra 5.8 days on a 1.7 GHz Pentium-M, against an estimated 79 days for Pollard rho, a speed-up of 5.3. Historical timing, not a parameter recommendation.

What to watch for

These are 2005 asymptotic and experimental results. The 12.5 percent figure comes from the proven exponent for cyclic Jacobians, and later work has improved hyperelliptic index calculus further.

Useful background: The double large prime variation, Discrete logarithms in a Jacobian group.

Related ideas

Papers

Curve25519

Curve25519 is the Montgomery curve y squared equals x cubed plus 486662 x squared plus x over the field of integers modulo the prime 2 to the power 255 minus 19. Its group order is 8 times a prime, so its cofactor is 8. It is the one curve among the paper's three examples that meets every SafeCurves criterion.

Why it is useful

The curve was chosen so that the simplest implementation is also the secure one: the Montgomery ladder gives constant-time single-coordinate scalar multiplication, the quadratic twist has a large prime factor, the birationally equivalent Edwards curve gives complete addition formulas for signatures, and an Elligator 2 bijection exists. The 2006 software introducing X25519, which is Diffie-Hellman on this curve, was more than twice as fast as the previous NIST P-256 results, and the paper's appendix shows X25519 and Ed25519 still ahead on every CPU measured.

How it works

  1. Field: p = 2 to the power 255 minus 19, a prime slightly below 2 to the power 255, so field elements fit in 32 bytes.
  2. Equation: Montgomery form with A = 486662, usable for ladder arithmetic; an equivalent twisted Edwards curve carries Ed25519 signatures.
  3. Order: cofactor 8 with a prime subgroup of about 2 to the power 252, so there are 8 points T for which 8T is the neutral element; rho cost about 2 to the power 125.8, and combined twist attacks about 2 to the power 124.3.

Example

X25519 for key exchange and Ed25519 for signatures are the two standard deployments of this curve.

What to watch for

The cofactor of 8 means protocols whose security analysis assumes the prime-order subgroup must handle the extra points explicitly; Monero learned this in 2017 when a vulnerability let each coin be spent eight times.

Useful background: Safe curves: ECC security beyond ECDLP security, Ladders and complete addition formulas.

Related ideas

  • Ed25519: The signature system that uses the Edwards form of this curve.
  • Montgomery ladder: The scalar-multiplication algorithm the curve was designed around.

Papers

Cycles of curves for recursive proofs

A cycle of elliptic curves is a collection in which the scalar field of each curve is the base field of another. A 2-cycle is the smallest case: curve E1 is defined over Fp and has subgroup order q, while E2 is defined over Fq and has subgroup order p.

Why it is useful

Recursive proofs verify earlier proofs inside later ones. A proof over one field can only be checked by a circuit over the matching field, so unbounded recursion needs the fields to chain, and a cycle closes the chain so that it can repeat forever.

How it works

  1. Verify a proof on E1 inside a circuit on E2, which works because E2 computes over the field where E1 stores its scalars.
  2. Swap roles at each step so proofs alternate between the two curves.
  3. Pick the cycle type to match the commitment scheme: pairings available on both curves give MNT cycles, while a plain cycle drops pairings and keeps 256-bit primes.
  4. A half-cycle instead alternates one pairing-friendly curve with one plain curve without closing the loop.

Example

The BN-254 and Grumpkin pair is a half-cycle, also called a hybrid cycle, and Pluto-Eris is a 446-bit example.

What to watch for

The paper reports that pairing-based MNT cycles need very large primes, which makes the computations slow, and that plain cycles trade away the constant proof size of pairing-based SNARKs for proofs that grow logarithmically.

Useful background: Embedded curves and the field mismatch in zero-knowledge proofs.

Related ideas

Papers

Decaf and the Goldilocks implementation strategy

The published implementation turns the cofactor-4 curve into a prime-order group using Decaf, a point-compression strategy that quotients the curve by its 2-torsion points so that each encoded element stands for a whole class of equivalent points. Internally the code runs on the twisted Edwards curve with a = -1 and d = -39082, which is related to the published curve by a 4-isogeny, because Decaf works identically on both forms and the twisted one is slightly faster.

Why it is useful

A cofactor of 4 means the curve has small subgroups, and callers would have to defend against small-subgroup tricks themselves; Decaf removes that burden by making every element the user sees have prime order. The library then ships complete point and scalar arithmetic, compression, invertible maps to the curve and example primitives.

How it works

  1. Represent group elements as Decaf classes, so cofactor multiplication and small-subgroup attacks disappear from the caller’s code.
  2. Run key generation with signed all-bits-set combs, tables of precomputed multiples that trade memory for speed: 15kiB of tables on 64-bit and 12kiB on 32-bit platforms.
  3. Sign with Schnorr signatures, reusing the same comb set as key generation.
  4. Verify in variable time using wNAF and a 6kiB table of multiples of the generator, acceptable because verification handles public data.
  5. Do ECDH with the Montgomery ladder, marginally faster because it does not decompress the peer point; the ladder is enhanced to preserve sign information and to reject points on the twist.

Example

Two points that differ by the 2-torsion element (-1, 0) encode to the same Decaf string, so an attacker cannot hand over a twisted variant of someone’s public key.

What to watch for

Rejecting twist points in the ladder is defensive: the paper notes it is believed safe to allow them. Batching of verification was untested.

Useful background: Ed448-Goldilocks.

Related ideas

  • Decaf: The cofactor-eliminating encoding used here.
  • Montgomery ladder: The ECDH path that avoids decompression.

Papers

Discrete logarithms in a Jacobian group

The problem attacked in the paper: given a divisor D1 that generates a cyclic subgroup G of the Jacobian, and another divisor D2 in G, find the integer lambda with D2 equal to lambda times D1.

Why it is useful

Hyperelliptic cryptosystems, proposed by Koblitz, rest on this problem being hard, so its real difficulty decides how large the parameters of such a system must be.

How it works

  1. Take a generating reduced divisor D1 of the subgroup G and a second reduced divisor D2 in G.
  2. Search for the integer lambda between 0 and the order of G minus one such that D2 equals lambda times D1 in the Jacobian.
  3. Treat the group order as part of the input; for fixed genus it can be computed in polynomial time.
  4. If the group order factors into small pieces, the Pohlig-Hellman method solves the problem piece by piece, so cryptographic instances use groups of almost prime order, meaning a large prime times a tiny factor.

What to watch for

The paper assumes the group order is known and restricts its cost comparisons to almost-prime-order groups, which is the case that occurs in cryptography.

Useful background: Hyperelliptic curves and their Jacobians, Discrete logarithm problem.

Related ideas

  • Pollard rho: the generic attack whose cost sets the baseline

Papers

Ed25519

Ed25519 is a standardized signature scheme on an Edwards curve over the prime field of size 2^255 - 19, with curve order 8r for a large prime r. The paper treats it as a statement curve and builds a proof curve above it.

Why it is useful

Because it is a widely deployed standard, statements about Ed25519 signatures appear inside zero-knowledge proofs, and proving them efficiently needs a proof curve whose scalar field is exactly the Ed25519 base field.

How it works

  1. Fix Ed25519 over its field of size 2^255 - 19 as the statement curve.
  2. Search square-free discriminants d congruent to 3 modulo 4, up to about 10^10, for a prime-order curve E1 whose order is exactly 2^255 - 19.
  3. Close a plain 2-cycle with the complementary curve E0, of prime order p, defined over the Ed25519 field.
  4. Check the twist orders; the published E1 has a quadratic twist of prime order.

Example

The cycle curve E0 has equation y^2 = x^3 - 3x + bq over Fq with q = 2^255 - 19, so Ed25519 statements and the proofs about them share one 255-bit field.

What to watch for

The search takes about a day of computation and stops at discriminant D = -65012179, so the endomorphism is too costly for GLV acceleration, and the two fields lack the high 2-adicity used for fast polynomial multiplication.

Useful background: Cycles of curves for recursive proofs.

Related ideas

  • Curve25519: The Montgomery curve over the same prime field, used for key exchange.

Papers

Ed448-Goldilocks

Ed448-Goldilocks is an elliptic curve proposed in 2015 by Mike Hamburg for high-strength cryptography. An elliptic curve is the set of pairs (x, y) that satisfy one fixed equation in two variables; here the coordinates are integers modulo the prime p = 2^448 - 2^224 - 1 and the equation is the untwisted Edwards form x^2 + y^2 = 1 + d x^2 y^2 with d = -39081. The curve has order 4q, four times a large prime q (the paper writes q as 2^446 minus a constant spelled out in hexadecimal), and its quadratic twist, the companion curve obtained by replacing d with d times a non-square, also has order four times a prime.

Why it is useful

A 256-bit-field curve such as Curve25519 targets about 128 bits of security. Ed448-Goldilocks is meant to be a single stronger curve for users who want a larger margin, while staying fast enough that people actually deploy it, so it can supplement Curve25519 and Ed25519 rather than replace them.

How it works

  1. Start from the Edwards curve shape, whose addition formulas are complete: no input pair triggers the division by zero that special cases in older formulas can cause.
  2. Search for the coefficient d with the smallest absolute value such that the curve and its twist both have order 4 times a prime, and such that the order is below p for easy implementation.
  3. Keep d = -39081. Because d is not a square modulo p, the strongly unified Edwards addition formulas apply to every pair of points, including doubling.
  4. Generate the curve under the safecurves.cr.yp.to rules, which rule out known curve-generation mistakes and show that nothing is hidden in the choice of d.

Example

Adding two points on this curve uses only additions, multiplications and modular reductions of the coordinates, with one branch-free formula for every case.

What to watch for

Edwards and twisted Edwards curves always have an order divisible by 4, so this curve is not prime-order like the NIST curves; the prime-order group is recovered with the Decaf encoding described later. Also, the base point published in the first revision of the paper was later changed by adding the 2-torsion point (-1, 0), so early copies list a point of order 2q.

Useful background: Elliptic Curve Cryptography.

Related ideas

  • Curve25519: The 128-bit-level curve that Ed448-Goldilocks is meant to supplement.
  • Ed25519: The signature scheme on the smaller Curve25519-family curve.

Papers

Ed448-Goldilocks performance and standardization

The paper benchmarks key generation, ECDH, signing and verification for Ed448-Goldilocks against E-521, Microsoft Research’s ed-384-mers and ed-512-mers, and OpenSSL’s NIST curves, on a Haswell desktop and two ARM chips. Ed448-Goldilocks and ed-384-mers come out around 4x as fast as OpenSSL’s NIST-P384 on x86-64, on ARM Goldilocks is faster than even OpenSSL’s NIST-P256, and NEON vector instructions give it roughly a 2x speedup.

Why it is useful

Speed is the argument that a conservative 448-bit curve is deployable at all: the extra security costs less than the NIST curves people already run. The paper concludes that Ed448-Goldilocks is a suitable standardization target in place of both secp384r1 and secp521r1, and notes that as of June 2015 the IRTF CFRG favored it for inclusion in future TLS standards.

How it works

  1. Measure with hyperthreading and TurboBoost disabled, so clock boosting does not distort cycle counts.
  2. State up front that implementation effort, table sizes, functions measured and measurement technique differ per curve and platform.
  3. Compare against ed-384-mers head to head: about 17% faster key generation, 16% slower verification and 6% slower ECDH, differences the paper attributes to point compression and comb tuning rather than the field.
  4. Treat 32-bit comparisons as unproven, because no fair pair of implementations existed at the time.

Example

On the Haswell test machine a Goldilocks shared secret costs about 531 thousand cycles, against about 2.1 million for OpenSSL’s NIST-P384 ECDH.

What to watch for

The numbers are 2015 measurements on specific processors with differently matured software, and the paper itself says to take them with a grain of salt; the CFRG statement is a snapshot of that month, not a final standard.

Useful background: Ed448-Goldilocks, Decaf and the Goldilocks implementation strategy.

Related ideas

  • Ed25519: The smaller-curve counterpart whose deployment pattern this curve follows.
  • Curve25519: The curve CFRG paired with Ed448-Goldilocks for TLS.

Papers

Elligator and scalar bias with a near-power-of-two field

Because p = 2^448 - 2^224 - 1 sits just below the round number 2^448, the shortcut of taking a random 448-bit string and reducing it modulo p is almost unbiased: the bias is about 2^-224, the same order as 1/sqrt(p). Scalars are likewise safe to make by truncating a random string to 446 bits, because the order 4q of any curve modulo p lies within 3*2^224 of 2^448 by Hasse’s bound.

Why it is useful

Cheap, near-uniform sampling matters in practice. Elligator, which encodes curve points so they look like random strings, needs to lift random field elements to the curve, and signature nonces need uniform scalars; a modulus far from a power of two would force longer inputs or rejection sampling.

How it works

  1. Take a random 448-bit string and reduce it modulo p: the low residues occur only slightly more often, with bias about 2^-224.
  2. Note that detecting that bias costs about as much as a rho attack on the curve, so it gives an attacker nothing useful.
  3. Truncate a random string to 446 bits for a scalar; the resulting bias modulo q is about 3*2^-224, negligible.
  4. If more conservatism is wanted, choose a random 512-bit number and reduce it modulo q instead.

Example

Only 2^448 - p = 2^224 + 1 of the 2^448 possible strings wrap around during reduction, which is why the over-representation is about one part in 2^224.

What to watch for

These bias statements are estimates for this specific prime shape; they do not transfer to fields whose size is far from a power of two.

Useful background: The Goldilocks prime 2^448 - 2^224 - 1.

Related ideas

  • Elligator: The point encoding whose indistinguishability relies on this small bias.

Papers

Elliptic-curve discrete logarithms on a small board

The elliptic-curve discrete logarithm problem asks: given a point P on the curve and a second point Q that is known to equal k times P for some secret number k, find k. Multiplying a point by a number is easy, because it is just repeated doubling and adding of points. Going backwards from the result to the number is believed to be hard.

Why it is useful

Every protocol in this paper rests on that gap. ECDH turns it into a shared secret that an eavesdropper cannot compute, and ECDSA turns it into a signature that cannot be forged without the private key.

How it works

  1. Agree on a curve and a base point P.
  2. Compute k times P for a secret k; this is the fast direction and is what the device actually spends its time on.
  3. Rely on the fact that an observer who sees both P and k times P cannot recover k.

What to watch for

This is a belief backed by decades of failed attacks, not a proof, and it only holds against ordinary computers: a large quantum computer running Shor's algorithm would recover k. The paper's remark that "a 256-bit finite field provides a sufficient security level" refers to the field size, not to a 256-bit attack cost.

Useful background: The prime field under the curve.

Papers

Embedded curve families of fixed discriminant

A family of embedded curves is a set of curve parameters written as polynomials in a single seed x. Evaluating the polynomials at an integer seed produces, at once, a pairing-friendly proof curve and an embedded curve above it, and the embedded curve keeps one fixed discriminant D, the integer that fixes its endomorphism structure, across the whole family.

Why it is useful

A single embedded curve is tied to one fixed proof curve. A polynomial family lets a designer pick a new seed to obtain a new proof curve and a matching embedded curve together, for example to gain many roots of unity in the fields for fast polynomial arithmetic.

How it works

  1. Start from a pairing-friendly family whose subgroup order polynomial q(x) takes prime values at allowed seeds.
  2. Solve the norm equation 4q(x) = t'(x)^2 - D y'(x)^2 in polynomials of degree at most half the degree of q(x), using a half-greatest-common-divisor computation.
  3. Read off the embedded curve order r(x) = q(x) + 1 - t'(x) and the orders of its twists, keeping the branches that can take prime values.
  4. Choose a seed so that the base prime, the subgroup order and the embedded order are all prime under the family's congruence conditions.

Example

The paper's Figure 6 chains an inner BLS12 curve with its embedded curves and an outer pairing-friendly curve, an arrangement called a 2-chain.

What to watch for

Prime order needs D congruent to -3 modulo 4; other discriminants give an even order, as with D = -4 on KSS16 curves. Families with large denominators, such as KSS18, only yield their polynomial solution after a change of variable.

Useful background: Embedded curves and the field mismatch in zero-knowledge proofs, Cycles of curves for recursive proofs, The complex multiplication method for curves of chosen order.

Related ideas

Papers

Embedded curves and the field mismatch in zero-knowledge proofs

An embedded curve is an elliptic curve whose base field, the field its coordinates live in, is the scalar field of a second curve, that is, a field whose size equals the order of that curve's large prime subgroup. The second curve carries the zero-knowledge proof and the embedded curve carries the statement being proved, such as a signature check. No map between the two curves is meant: embedded only records that the numbers describing one curve are the scalars of the other.

Why it is useful

A proof system does its circuit arithmetic in one field while the statement it verifies, for example a signature or a hash-based commitment, computes in another. Bridging two different fields inside one circuit is expensive, and the paper calls this mismatch the primary performance bottleneck of such systems.

How it works

  1. Fix the proof curve first, for example a pairing-friendly curve whose prime subgroup has order q.
  2. Search for an elliptic curve defined over the field of size q, so statement arithmetic and circuit arithmetic share one field.
  3. Reject the shortcut of one curve whose base field equals its own scalar field: such anomalous curves are not secure.
  4. Check the candidate for prime order, or a small cofactor times a prime, and check its quadratic twist as well.

Example

Proving knowledge of a signature key: the verification runs on the embedded curve, and each of its coordinates is an ordinary circuit element because both live over the same field.

What to watch for

The embedded curve is searched for after the proof curve is fixed, so its remaining properties, such as a tiny endomorphism discriminant or extra roots of unity in the field, cannot all be guaranteed at once.

Useful background: Elliptic Curve Cryptography.

Related ideas

  • BLS12-381: A proof curve whose 255-bit scalar field carries several embedded curves.

Papers

FourQ: a complete twisted Edwards curve over a Mersenne prime field

FourQ is a specific elliptic curve, published by Costello and Longa in 2015, whose points live over the quadratic extension field F_{p^2} with p = 2^127 - 1 and whose cryptographic subgroup has prime order N of 246 bits.

Why it is useful

It was designed to make scalar multiplication - the core operation behind Diffie-Hellman key exchange and Schnorr-type signatures - as fast as possible at the 128-bit security level, while still using ordinary elliptic-curve discrete logarithms.

How it works

  1. The curve equation is the twisted Edwards form -x^2 + y^2 = 1 + d x^2 y^2, with a constant d that is not a square in F_{p^2}.
  2. The full group of F_{p^2}-rational points has order 2^3 * 7^2 * N, and cryptography happens inside the subgroup of order N.
  3. The same model, coordinates and addition formulas serve every protocol, so the library wraps around one fixed routine.

Example

A Diffie-Hellman public key is a point on FourQ; multiplying it by a secret 256-bit scalar gives the shared secret.

What to watch for

The group order is not prime: the cofactor 2^3 * 7^2 means a point taken from an untrusted source need not lie in the order-N subgroup, so callers must decide whether to validate or to multiply by the cofactor.

Related ideas

  • Curve25519: comparison curve at the same security level
  • Twisted Edwards curves: the curve model used

Papers

Golden-ratio Karatsuba multiplication

Multiplying two elements of the Goldilocks field uses Karatsuba’s trick driven by the golden-ratio relation. Split each 448-bit element into a low and a high half, writing it as a + b*phi with phi = 2^224. Then (a + b*phi)(c + d*phi) works out to (ac + bd) + ((a + b)(c + d) - ac)*phi modulo p.

Why it is useful

A schoolbook 448-by-448-bit multiply needs four half-size multiplications; this form needs only three, namely ac, bd and (a + b)(c + d), which is the classic Karatsuba saving. The rule phi^2 = phi + 1 turns the overflowing phi-squared term into a plain sum, so reduction is fused into the multiplication rather than done as a separate pass.

How it works

  1. Treat a field element as the polynomial a + b*phi and expand the product.
  2. Replace bd*phi^2 with bd + bd*phi, using phi^2 = phi + 1 modulo p.
  3. Collect ac + bd as the low half and (a + b)(c + d) - ac as the high half.
  4. Compute the three half-products with limbs spaced phi apart, so the shared additions serve both halves of the result at once.

Example

Take phi = 2^224 and multiply phi by phi: the schoolbook product 2^448 reduces to 2^224 + 1, that is phi + 1, with a single subtraction of p.

What to watch for

The saving assumes each coefficient is computed and then reduced; a different interleaving changes the overflow analysis discussed in the next lesson.

Useful background: The Goldilocks prime 2^448 - 2^224 - 1.

Papers

How hard discrete logarithms must be on a safe curve

Three numbers decide how hard the discrete-logarithm problem is on a given curve: the order of the base point, the embedding degree, and the CM field discriminant. The order is the number of points in the group the base point generates; the rho method, the best generic attack, finds a discrete logarithm using about 0.886 times the square root of that many curve additions. The embedding degree says how easily the problem can be moved ("transferred") into a finite field where index-calculus algorithms apply. The CM field discriminant measures how much extra internal symmetry the curve has: a small value means the curve admits fast endomorphisms, maps from the curve to itself that speed up computations.

Why it is useful

These are the classical attack paths against ECDLP itself. If the order is small, rho wins. If the order divides p to the power k minus 1 for small k, the problem transfers to a finite field where subexponential attacks win; the extreme case is the additive transfer, where the order equals p and the problem becomes trivial. If the discriminant is small, fast endomorphisms give a modest speedup to attacks and the security story becomes harder to analyze.

How it works

  1. Choose a base point of prime order ℓ large enough that 0.886√ℓ additions is hopeless: SafeCurves raised its lower limit from 2 to the power 200 to 2 to the power 220 to keep pace with chip efficiency.
  2. Require the order ℓ to be different from p, which blocks the additive transfer.
  3. Require a large embedding degree, so no small-power transfer into a finite field exists; SafeCurves copies the Brainpool bound of at least (ℓ−1)/100 rather than the weaker "at least 20" of older standards.
  4. Require the absolute value of the CM field discriminant to exceed 2 to the power 110, which almost all curves satisfy anyway.

Example

The paper quotes rho costs of about 2 to the power 111.8 for NIST P-224, 2 to the power 125.8 for Curve25519 and 2 to the power 127.8 for NIST P-256.

What to watch for

The rho cost is an average, and it drops as the square root of the number of targets: breaking a million keys costs only about a thousand times one key, so shared curves need margin. The limits are engineering judgements tied to hardware estimates, not theorems.

Useful background: Safe curves: ECC security beyond ECDLP security.

Related ideas

Papers

Icart map

Icart's map constructs elliptic-curve points from field elements with deterministic algebraic formulas.

Papers

Index calculus for small-genus Jacobians

An index-calculus attack collects relations among a chosen set of Jacobian elements, the factor base, then solves a linear algebra problem to recover the discrete logarithm. For small genus the factor base consists of prime divisors of weight 1, roughly the rational points of the curve.

Why it is useful

It beats attacks that treat the group as a black box, such as Pollard rho, which need about the square root of the group order steps, because a relation is found by factoring a polynomial, a structured lucky event that happens often enough to be exploited systematically.

How it works

  1. Choose a factor base B of weight 1 prime divisors.
  2. Form random linear combinations of D1 and D2 using Cantor’s algorithm.
  3. Factor the u-polynomial of the result; if it splits completely over the factor base, record the exponents as a row of a matrix.
  4. Once there are more relations than factor base elements, find a nonzero combination of rows that sums to zero, giving alpha and beta with alpha times D1 plus beta times D2 equal to zero.
  5. Read off the logarithm whenever beta is invertible modulo the group order, which happens with high probability.
  6. Harley’s balancing trick restricts the factor base to about q to the r elements so that relation search and linear algebra cost roughly the same.

What to watch for

The plain algorithm costs about q squared group operations, and the balanced version brings genus 3 down to about q to the power 1.5. These are asymptotic exponents with logarithmic factors hidden in the notation.

Useful background: Discrete logarithms in a Jacobian group, Divisor arithmetic and the Mumford representation.

Related ideas

  • Index calculus: the general relation-collection strategy this attack instantiates
  • Pollard rho: the baseline generic attack being beaten

Papers

Jubjub

Jubjub is the first embedded curve proposed over the scalar field of BLS12-381. It was found with the Schoof-Elkies-Atkin point-counting algorithm rather than the CM method, and its discriminant is larger than Bandersnatch's.

Why it is useful

It shows that the embedded-curve idea predates CM searches: a statement curve over the BLS12-381 scalar field lets proof circuits do curve arithmetic natively instead of simulating a second field.

How it works

  1. Generate candidate curves over the fixed 255-bit field.
  2. Run point counting to learn each curve's order.
  3. Keep a curve with a prime-order subgroup and twist security; no endomorphism is engineered, so scalar multiplication follows the usual double-and-add path.

Example

A circuit proving knowledge of a Jubjub secret key multiplies points whose coordinates are ordinary elements of the proof field.

What to watch for

Without a tiny discriminant the curve has no comparably cheap endomorphism, and the paper reports that scalar multiplications are slower than on Bandersnatch, which was later built over the same field with the CM method.

Useful background: BLS12-381.

Related ideas

Papers

Koblitz curves

A Koblitz curve is an elliptic curve over a binary field given by y^2 + x*y = x^3 + a*x + 1 with a equal to 0 or 1. The equation is defined over the two-element field F2 and the curve is then used over the extension field F_{2^m}; the paper calls these anomalous binary curves.

Why it is useful

They are the second curve family in Android's library, they are available in Bouncy Castle, and they appear in standards, so a practical attack on them matters beyond the laboratory. Their point arithmetic avoids point doublings, which made them attractive in hardware and, once processors grew carryless multiply instructions, in software too.

How it works

  1. Fix a in {0, 1} and work over F_{2^m}; the NIST K-163 curve is one standardized example, and the paper measures its large subgroup order as 162 bits.
  2. The curve was proposed by Koblitz in 1991; Solinas later gave the efficient recoding algorithms and the Guide to Elliptic Curve Cryptography treats them formally.
  3. Because the equation has coefficients in F2, the map (x, y) -> (x^2, y^2) is a curve endomorphism, and scalar multiplication can be organized around it instead of around doublings.

Example

NIST K-163 is the concrete curve the authors used for their Koblitz experiments, with a 162-bit group order.

What to watch for

Do not confuse Koblitz curves with the Bitcoin curve secp256k1. That curve is defined over a prime field, and the paper's own footnote corrects the earlier description of it as a Koblitz curve; the prime-field attack still applies to it.

Related ideas

Papers

Large prime variations for index calculus

A large prime variation also keeps relations that miss the factor base narrowly: those containing exactly one weight 1 divisor outside it. That stray divisor is a large prime, and two relations sharing the same large prime can be combined.

Why it is useful

Relations with one large prime are much easier to find than fully smooth ones, that is ones using only factor base elements, and matching them in pairs, a birthday-paradox effect, turns cheap relations into the smooth ones the matrix needs.

How it works

  1. Keep the factor base at about q to the r elements and call the remaining weight 1 divisors large primes.
  2. Collect relations that contain at most one large prime.
  3. Wait for two relations involving the same large prime; combining them cancels it and leaves a fully smooth relation.
  4. The number of useful matches grows like the square of the number of relations collected, which is the birthday paradox at work.
  5. Balancing this against the linear algebra step yields an algorithm asymptotically faster than Pollard rho already for genus 3 curves.

What to watch for

The single-large-prime analysis leans on the assumption that large primes are hit uniformly; the paper cites it as the starting point that it extends.

Useful background: Index calculus for small-genus Jacobians.

Related ideas

Papers

Limb sizes and overflow headroom

A Goldilocks implementation stores each field element as several limbs, machine words that each hold a slice of the number, and picks the limb width so accumulated products cannot overflow the word. On 32-bit machines the paper recommends radix 2^28 with 16 limbs instead of the natural radix 2^32 with 14 limbs; on 64-bit machines it uses radix 2^56 with 8 limbs.

Why it is useful

Carry propagation, the shifting of overflow from one limb to the next, is the expensive part of a multiply, especially in vector code. Leaving headroom below the top of each word lets several additions happen without a carry pass, so a slightly wider number buys many fewer carries.

How it works

  1. Pick radix 2^28 with 16 limbs on 32-bit and vector targets, keeping each limb below 2^28 times a slack factor c.
  2. Check the worst case: the paper bounds the largest unreduced coefficient by 38 * 2^56 * c^2, which stays below 2^64 whenever c < 2^4/sqrt(38) = 16/sqrt(38), about 2.6.
  3. Start from coefficients reduced below 2^28 * 5/4, which still allows one unreduced addition to each multiplicand without overflow.
  4. On 64-bit machines use radix 2^56 with 8 limbs; the paper notes limbs can be magnified by chains of additions and subtractions by a factor of up to 2^8/sqrt(38), about 41, before overflowing.

Example

A 28-bit limb in a 32-bit word leaves the top 4 bits as room for sums and carries, so additions do not immediately force a carry chain.

What to watch for

The bound assumes ordinary wrapping arithmetic. Saturating instructions such as ARM NEON’s VQDMLAL clamp instead of wrapping, so there the slack factor is tightened to around 2.

Useful background: Golden-ratio Karatsuba multiplication.

Related ideas

Papers

NIST P-224

NIST P-224 is the short Weierstrass curve y squared equals x cubed plus ax plus b over the field modulo the 224-bit prime 2 to the power 224 minus 2 to the power 96 plus 1, with a = −3 and the specific 224-bit constant b quoted in the paper.

Why it is useful

It illustrates the smaller security tier of the same NIST family: the rho cost is about 2 to the power 111.8, below the SafeCurves lower limit of 2 to the power 220 even before considering anything else. The paper also uses it as its clearest example of a twist problem.

How it works

  1. Field: a special prime of the form 2 to the power 224 minus 2 to the power 96 plus 1, allowing fast reduction.
  2. Equation: short Weierstrass form with a = −3.
  3. Rho cost: about 2 to the power 111.8 additions for the order of its base point.
  4. Twist: the combined small-subgroup and twist attack costs only about 2 to the power 58.4, far below the rho cost, because the twist is not secure.

Example

The paper quotes P-224 alongside P-256 and Curve25519 when comparing rho and twist-attack costs across curves of similar vintage.

What to watch for

Like the other NIST curves it fails the rigidity criterion, and like other short Weierstrass curves it fails the ladder, completeness and indistinguishability criteria.

Useful background: NIST P-256, Twist security against invalid-curve attacks.

Related ideas

  • NIST P-256: The larger curve from the same standardized family.

Papers

NIST P-256

NIST P-256 is the short Weierstrass curve y squared equals x cubed minus 3x plus b over the field modulo the 256-bit prime 2 to the power 256 minus 2 to the power 224 plus 2 to the power 192 plus 2 to the power 96 minus 1. The constant b is the hash of a public seed. Its cofactor is 1, so the whole group has prime order.

Why it is useful

It is one of the curves NSA produced that were standardized by ANSI X9.62, SEC 2 and NIST FIPS 186-2, and it remains one of the most deployed curves. The paper uses it as the main contrast case: its discrete-log parameters are fine (rho cost about 2 to the power 127.8, combined twist attack about 2 to the power 120.3), but its shape and its unexplained seed fail the SafeCurves software-side and rigidity criteria.

How it works

  1. Field: a "special" prime chosen so modular multiplication is fast, which the paper endorses; the coefficients a = −3 also speed up Jacobian-coordinate formulas.
  2. Equation: short Weierstrass form, which pushes protocols toward sending both coordinates and toward addition formulas with failure cases.
  3. Generation: b = H(s) for a large public seed s; SafeCurves calls the process manipulatable because the seed is a large unexplained input.
  4. Order: cofactor 1 with a prime of about 2 to the power 256.

Example

The 5G subscription-identifier system supports both P-256 and Curve25519; the cited attack worked against the P-256 option and failed against the X25519 option.

What to watch for

The paper's vulnerability chronology for this curve family includes timing attacks on certified hardware (Minerva, TPM-FAIL), a Mozilla announcement about the NSS library, and invalid-curve attacks on P-256 deployments; none of these solved a discrete logarithm.

Useful background: Safe curves: ECC security beyond ECDLP security.

Related ideas

Papers

Pallas and Vesta: the Pasta cycle

Pallas and Vesta are two elliptic curves forming the Pasta cycle, a plain 2-cycle designed for Halo 2: each curve is defined over the base field of the other, both primes are about 256 bits, and neither curve carries a pairing.

Why it is useful

The cycle supports recursive proofs built on a discrete-logarithm polynomial commitment, which needs no pairing-friendly structure and therefore allows far smaller primes than pairing-based cycles.

How it works

  1. Use the discrete-logarithm polynomial commitment as the proof system, so ordinary curves suffice.
  2. Choose two 256-bit primes and arrange each curve's base field to equal the other's scalar field.
  3. Alternate proofs between the two curves to recurse indefinitely; the Rust implementation of NOVA uses this cycle.

Example

A folding scheme verifies one proof inside the next by switching between Pallas and Vesta at every layer.

What to watch for

The paper records the trade-off of this route: the proof size is no longer constant, although it stays logarithmic in the size of the inputs.

Useful background: Cycles of curves for recursive proofs.

Related ideas

  • BLS12-381: The pairing-friendly alternative, whose proofs keep a constant size.

Papers

Prime shapes for fast field arithmetic

Before fixing the Goldilocks prime, the paper surveys the six families of primes used for elliptic-curve fields: random Brainpool-style primes, Mersenne primes such as 2^521 - 1, Crandall primes of the form 2^k - c, special Montgomery primes of the form 2^(k*c) - 1, Granger-Moss primes built from cyclotomic polynomials, and Solinas primes 2^k - 2^l plus or minus further terms.

Why it is useful

Each family buys speed by making reduction after a multiplication cheap, and each has a cost, such as a special form, a limited size range or dependence on one implementation method. Working through the trade-offs shows why a three-term prime aligned to several radices was picked.

How it works

  1. Random primes avoid special-form worries but cost severe performance, and it is hard to argue their coefficients were chosen honestly rather than maliciously.
  2. Mersenne primes are very fast for their size, but the good ones are enormous, which the paper believes hurts deployment.
  3. Crandall primes need a small c to limit carry propagation during multiply-reduce, which leaves only a few fast choices such as 2^379 - 19.
  4. Special Montgomery primes lose their carry advantage above about 2^256 and add more bias when hashing and reducing.
  5. Granger-Moss primes excel near 240 or 360 bits on 64-bit machines but need one specific implementation method and weaken past 360 bits.
  6. Solinas primes stay fast across platforms when they have few coefficients sitting on powers of the radix, which motivates the Goldilocks choice.

Example

The Mersenne prime 2^521 - 1 reduces with one shift-and-add because 2^521 = 2 modulo it; Goldilocks instead folds 2^448 onto 2^224 + 1.

What to watch for

These rankings are 2015 judgements tied to the processors and compilers of that time, not permanent laws.

Useful background: The Goldilocks prime 2^448 - 2^224 - 1.

Papers

Rigidity: how the curve was generated

A curve is rigid when its generation procedure is explained so completely that the people who produced it had no meaningful hidden choice. The concern is a three-step scenario: cryptographers miss an attack that works on a small fraction of curves, an attacker knows it, and the attacker searches through many possible curves until landing inside the weak fraction while claiming the result was chosen at random.

Why it is useful

A hash of a "seed" proves only that the curve coefficients are hash outputs; it does not prove the seed was picked before the curve was inspected. Scott pointed this out for the NIST curves in 1999, and the paper shows the same objection applies in a weaker form to Brainpool: its procedure was only partially explained, and the authors generated more than a billion Brainpool-like curves that would all have counted as "verifiably pseudorandom".

How it works

  1. Prefer generation with no unexplained inputs: for example, coefficients taken from digits of well-known constants with stated, fixed rules.
  2. Count how many alternative curves a generator with the stated freedom could have produced; a billion alternatives means a one-in-a-billion weakness could have been targeted.
  3. Check the base point separately when the protocol needs it: a certificate system was broken in 2020 by letting certificates choose their own base points, although a mathematically "weak" base point would break every base point, since logarithms base one point can be converted to logarithms base another by taking ratios.

Example

The SafeCurves rigidity criterion rejects the NIST curves as manipulatable because of the unexplained seed input, and accepts the Brainpool curves while still listing open questions about their seed rules.

What to watch for

Rigidity cannot be proven, only measured by how much unexplained freedom remains. Recovering a lost seed would not demonstrate innocence either, because a malicious search over meaningful messages works exactly like a search over random seeds.

Useful background: How hard discrete logarithms must be on a safe curve.

Related ideas

  • NIST P-256: The curve whose unexplained seed made rigidity a criterion.

Papers

Safe curves: ECC security beyond ECDLP security

A safe curve is an elliptic curve chosen so that both the mathematics and the software built on it are hard to break. The elliptic-curve discrete-logarithm problem (ECDLP) asks: given a base point G and the point nG, find n. The SafeCurves project argues that a curve can resist ECDLP and still be unsafe, because real systems also fail on rare inputs, leak secrets through timing, and accept points that are not on the curve at all. One basic requirement is that the curve is defined over a prime field, meaning its coordinates are numbers modulo a prime p rather than modulo a power of 2.

Why it is useful

Standards written around 2000 judged curves only against discrete-log attacks and assumed implementations would be correct. The paper answers this with a long list of real breaks that never solved a discrete logarithm, and argues that curves which make the simple code also the secure code remove most of that risk. Prime fields are required because attacks that exploit subfields are known for curves over non-prime fields, and excluding that structure makes the security analysis simpler and more stable.

How it works

  1. Check the field: the prime p must define a prime field, which removes the subfield structure used by known attacks on binary and other extension fields.
  2. Check the discrete-log side: the order of the base point, the embedding degree, and the CM field discriminant must all be large enough.
  3. Check the software side: the curve must support ladder arithmetic, twist security, complete addition formulas, and encodings of bit strings as points.
  4. Treat every criterion as a margin, not a proof: better curves make implementation failures less likely, and protocol-level choices still matter.

Example

Table 1.3.1 of the paper lists three proposed curves: NIST P-256, brainpoolP256t1 and Curve25519. Only Curve25519 is classified as safe under all of the criteria.

What to watch for

Meeting every SafeCurves criterion does not stop quantum computers, undiscovered attacks, or protocol mistakes such as reusing signature randomness; the paper says better curves rule out "most", not all, real-world breaks.

Useful background: Elliptic Curve Cryptography.

Related ideas

  • ECDH: The key-exchange task whose real-world implementations motivated the criteria.

Papers

Secp256r1

Secp256r1 is a named elliptic curve published by the Standards for Efficient Cryptography Group (SECG) in its SEC 2 list of recommended parameters. A point on it is a pair of numbers (x, y) that satisfies y squared equals x cubed minus 3x plus b, where all arithmetic is done modulo a 256-bit prime p written as 2 to the power 224 times (2 to the power 32 minus 1) plus 2 to the power 192 plus 2 to the power 96 minus 1. The coefficient a is fixed at minus 3 and the coefficient b is a fixed constant that the curve generators produced by a seeded random-looking procedure. NIST publishes the same curve under the name P-256, and web browsers and servers use it in Transport Layer Security (TLS).

Why it is useful

Naming a curve is what makes two machines agree without negotiating constants. If both sides say Secp256r1, they already share the prime, the equation, the base point and its order, so a key exchange or a signature can start immediately. P-256 is also one of the curves nearly every TLS implementation supports, which makes it a safe default for a device that must talk to arbitrary servers.

How it works

  1. Take the name Secp256r1 (or the equivalent name P-256) from the SEC 2 document rather than inventing parameters.
  2. Store the prime p, the coefficients a = -3 and b, the base point G and the order of G as fixed constants in the code.
  3. Run the protocols that need a group: ECDSA for signatures and ECDH for key agreement, as this paper does.

Example

A browser and a web server that both offer P-256 in a TLS handshake end up doing ECDH and ECDSA on exactly this curve.

What to watch for

The paper calls this a "256-bit security level", but a 256-bit curve gives about 128 bits of security against the best known attacks, and the same paper elsewhere says it picked the curve for 128-bit security. The paper also calls b "randomly selected"; in the standard it is derived from a public seed by a hash, which is repeatable rather than a fresh dice roll each time.

Related ideas

Papers

Security level and stated caveats

The best known attack on the discrete logarithm in FourQ's order-N subgroup is Pollard's rho with the negation map, at about 2^122.5 group operations on average, which the paper calls closely comparable to other 128-bit curves.

Why it is useful

The whole design only makes sense if the extra structure - the extension field, the small discriminant, the two endomorphisms - does not give an attacker a shortcut. The paper checks each of these.

How it works

  1. Neither psi nor phi has a small orbit on the subgroup and both cost more than an amortized addition, so they do not speed up Pollard's rho the way some GLV and GLS endomorphisms can.
  2. The 7^2 factor in the group order costs about 2.8 bits of security relative to a prime-order group of the same size, which the authors accept as the price of the fast field plus the four-dimensional decomposition.
  3. The curve lives over a quadratic extension field and has small discriminant, unlike most standardized curves; the paper notes that no better-than-generic attack is known that exploits either property, and cites the view that such specially chosen curves may be no less conservative.

What to watch for

These are the authors' 2015 statements, not an independent assessment; the paper also concedes it would have preferred a group order without the 7^2 factor.

Useful background: FourQ: a complete twisted Edwards curve over a Mersenne prime field, The endomorphisms psi and phi.

Papers

The complex multiplication method for curves of chosen order

The complex multiplication (CM) method constructs an elliptic curve over a fixed prime field with a chosen number of points. Each curve it produces carries a negative fundamental discriminant D, an integer recording the curve's endomorphisms, which are self-maps of the curve that respect the group law; a small |D| means one such map is cheap to evaluate and speeds up scalar multiplication.

Why it is useful

For an embedded curve the field is already fixed by the proof curve, and the order must hit a target such as a prime or four times a prime. Point counting can only test candidate curves, while the CM method builds curves with the wanted order directly.

How it works

  1. Enumerate square-free integers d and solve 4q = t^2 + d y^2 with a two-dimensional lattice reduction, which yields candidate traces t cheaply.
  2. Keep the candidates whose order q + 1 - t and twist order q + 1 + t meet the security targets.
  3. Compute one Hilbert class polynomial modulo q; its roots are the j-invariants of curves with that discriminant, and the curve equation follows from a root.
  4. Use a discriminant congruent to -3 modulo 4 when a prime-order curve is required, since other congruence classes force an even order.

Example

Bandersnatch was found with D = -8, and the paper's faster search reaches discriminants such as D = -6673027 above BLS12-381.

What to watch for

CM curves have a small discriminant by construction. A survey cited by the paper treats discriminants of size at least 2^110 as safe, far beyond the method's reach, so small |D| is a particularity implementers prefer to avoid even though it is not a known weakness.

Useful background: Elliptic Curve Cryptography.

Related ideas

Papers

The double large prime variation

The contribution of the paper: also keep relations containing exactly two large primes, called PP relations, and recombine them by finding cycles in a graph whose vertices are large primes and whose edges are the relations that use them.

Why it is useful

PP relations are far more frequent than relations with one large prime, so harvesting them and recombining them cuts the number of random Jacobian operations needed before enough usable relations exist.

How it works

  1. Call a relation Full if it uses only factor base elements, FP if it uses exactly one large prime, and PP if it uses exactly two.
  2. Halve the bookkeeping by identifying each weight 1 divisor with its image under the hyperelliptic involution, which is free to compute.
  3. Insert each FP or PP relation as an edge of the large prime graph: FP edges hang off a special vertex, PP edges join two large primes.
  4. When a new edge would close a cycle, combine the relations around that cycle by linear algebra to cancel the large primes on it; a cycle through the special vertex yields a Full relation.
  5. Maintain the graph with a union-find structure, a classical bookkeeping device that remembers which large primes are already connected, so each relation costs almost constant time to process.
  6. Stop when the number of independent Full or recombined relations passes the size of the factor base, then run the usual linear algebra step.

What to watch for

The length of the cycles that appear in this full algorithm is not proven to stay small; the paper measures it experimentally and bounds it only in its simplified variant.

Useful background: Large prime variations for index calculus.

Related ideas

Papers

The Goldilocks prime 2^448 - 2^224 - 1

The Goldilocks prime is the prime number p = 2^448 - 2^224 - 1, the modulus for all arithmetic in Ed448-Goldilocks. It is a Solinas prime: a prime written as a power of two plus or minus a few very sparse terms, here a trinomial with exactly three terms. Writing phi = 2^224, the relation phi^2 = phi + 1 holds modulo p, which is the same equation the golden ratio satisfies, and that is where the name comes from.

Why it is useful

Modular arithmetic dominates the cost of elliptic curve operations, so the shape of the prime decides how fast and how simple the implementation is. Because 224 = 32*7 = 28*8 = 56*4, the same prime cuts cleanly into limbs, the machine words that hold the number, on many word sizes, so one prime serves 32-bit, 64-bit and vector processors.

How it works

  1. Write the prime as 2^448 - 2^224 - 1 and note that it has only three nonzero terms, the minimum for a prime that is not of Mersenne form.
  2. Reduce with the identity 2^448 = 2^224 + 1 modulo p: any multiple of 2^448 folds down onto the middle and the bottom of the number.
  3. Store a field element as 16 limbs of 28 bits, 8 limbs of 56 bits or 14 limbs of 32 bits, depending on the target machine.
  4. Follow the Solinas rule that the exponents should sit on powers of the radix, which is why the NIST primes with 32-bit-aligned exponents suit 32-bit code.

Example

Reduce 2^448 modulo p by subtracting p once: the result is 2^224 + 1, so the top half of a product wraps onto both the middle and the bottom limbs.

What to watch for

A sparse prime is a special form, and attacks aimed at special-form fields are one of the risks the paper lists; the paper judges it better to spend the saved performance on a larger field than on a random prime.

Useful background: Ed448-Goldilocks.

Related ideas

Papers

The prime field under the curve

A finite field (also called a Galois field) is a finite set with an addition and a multiplication in which subtraction and division by nonzero elements always work. Its order, the number of elements, can only be a prime power q equal to p to the power n. When n is 1 the field is a prime field: the elements are 0, 1, up to p minus 1, and both operations are ordinary arithmetic followed by taking the remainder modulo p.

Why it is useful

Every coordinate of every point on Secp256r1 is an element of such a prime field, so all curve arithmetic reduces to additions and multiplications modulo p. Choosing p with a special shape, such as powers of two added and subtracted, is what makes those reductions cheap on a small processor.

How it works

  1. Pick the prime p; for Secp256r1 it is the 256-bit value 2^224(2^32 - 1) + 2^192 + 2^96 - 1.
  2. Represent each coordinate as an integer between 0 and p - 1.
  3. Add and multiply normally, then replace the result by its remainder modulo p.

What to watch for

In the paper the prime is printed with the exponents flattened by the PDF extraction, so "2224(232-1)" must be read as 2 to the power 224 times (2 to the power 32 minus 1). The paper also only defines the field; it does not describe the reduction trick that the shape of p enables.

Useful background: Secp256r1.

Papers

Twist security against invalid-curve attacks

When a protocol sends only one coordinate, every incoming value is a valid point on the intended curve or on its quadratic twist, a related curve with a different number of points. Twist security means the twist is also strong: its order has a large prime factor and only a small cofactor. Without it, an attacker sends points of small order on other curves and recovers the victim's secret key piece by piece.

Why it is useful

The standard short Weierstrass formulas never use the constant coefficient of the equation, so they happily compute with points on other curves that share the same x-cubed term; the software never notices. Checking each incoming point works, but the paper lists invalid-curve vulnerabilities reported in 2019, 2021, 2022 and 2023, more than twenty years after the attack was published, so SafeCurves moves the defense into the curve choice instead of relying on the check being written.

How it works

  1. Send only a single coordinate, which limits the attacker to the curve and its twist.
  2. Choose the curve so that both the curve and its twist have a small cofactor and a large prime subgroup, which makes small-subgroup and invalid-curve attacks no cheaper than the rho method.
  3. Evaluate the combined attack quantitatively: SafeCurves requires at least the square root of its rho limit (2 to the power 110 after the update) against attacks mixing small subgroups and the twist.
  4. Optionally validate incoming points anyway; with a twist-secure curve this is defense in depth rather than the only barrier.

Example

In the 5G example the paper cites, the same software was attacked successfully through its P-256 option and resisted through its X25519 option, because the protocol sends one coordinate for Curve25519 and two for P-256.

What to watch for

Cofactor 1 does not solve this: it pushes protocols toward sending two coordinates, which reopens invalid-curve attacks. The paper's combined-attack costs are 2 to the power 120.3 for NIST P-256 and 2 to the power 124.3 for Curve25519, but only 2 to the power 58.4 for NIST P-224 and 2 to the power 44.5 for brainpoolP256t1.

Useful background: Ladders and complete addition formulas.

Related ideas

  • ECDH: The protocol whose public keys are the attack surface.

Papers

Why a curve stronger than 128-bit security

The paper asks why anyone needs more than a 256-bit-field curve and answers with a list of threat scenarios: brute force over decades, a quantum computer running Shor’s algorithm, a mathematical breakthrough against all elliptic curves or only against special ones, a protocol with a loose security bound, implementation bugs, and architects who simply want a margin.

Why it is useful

It is the justification for the whole design. Curve25519 is rated at a work factor of about 126 bits, and in strong attack models such curves may cost an attacker more work than AES-128, since symmetric encryption can fall to multiple-target attacks that recover the first of n keys in time about 2^128/(n+1) while elliptic-curve batch attacks only speed up later keys.

How it works

  1. List the plausible break scenarios and separate those helped by a larger curve (brute force, partial breakthroughs) from those that are not (Shor’s algorithm, implementation bugs, where the defense is simplicity).
  2. Choose the significantly larger, or overkill, level, in the 384-to-521-bit range where the NIST and Brainpool curves already sit.
  3. Trade size against speed, since any user can always pick a larger curve at the cost of worse performance.
  4. Generate the curve under the safecurves policies to avoid known mistakes and to show nothing is up the designer’s sleeve.
  5. Propose one curve, not a 384-bit and a 521-bit pair: users will pick one and ignore the other.

Example

A 448-bit field puts the cost of a generic discrete-log attack near 2^223 operations, using the same square-root scaling that rates Curve25519 at about 126 bits.

What to watch for

For a significantly larger curve the usual work-factor estimate means almost nothing, because attacking it would itself require the breakthrough that invalidates the estimate.

Useful background: Ed448-Goldilocks.

Related ideas

  • Curve25519: The curve whose 126-bit work factor sets the baseline the paper argues from.

Papers

Bilinear pairings and pairing-friendly structures

Pairing maps, embedding degrees, curve construction and pairing evaluation, including target-group arithmetic.

Barreto-Naehrig curves

Barreto-Naehrig curves are a parameterized family of pairing-friendly elliptic curves.

Papers

Bilinear pairing accumulators

Pairing accumulators encode sets for membership proofs and revocation applications.

Papers

Bilinear pairings

A bilinear pairing maps a pair of group elements into a third group. Scaling either input by a scalar scales the output by that scalar, so scaling both inputs has a multiplicative effect on the output exponent.

Why it is useful

It lets a verifier check certain relationships involving secret exponents without learning those exponents. BBS uses a pairing equation to check a signature.

How it works

  1. Choose the specified source groups and target group.
  2. Apply the pairing to one element from each source group.
  3. Use bilinearity to compare the algebraic relationships the protocol requires.
  4. Require a nondegenerate pairing so the comparison carries information.

What to watch for

A pairing does not make every problem in the groups easy or prove security on its own. In the type-3 setting used here, the two source groups differ and the proof does not assume an efficient map from the second source group into the first.

Related ideas

Papers

Building pairing-friendly curves

Ordinary curves for Types 2 and 3 are produced with the CM method, and the goal of curve construction is to make the group order l close to the field size q.

Why it is useful

When l is about q, a point of G1 is represented with nearly the minimum number of bits, and hashing into the group stays cheap. That is what makes a curve family practical rather than merely existing.

How it works

  1. Search a family of polynomials, evaluating them at integers until the values are prime.
  2. Avoid generation methods that need Pell equations (only finitely many solutions are expected) or the factorisation of l to the k minus 1, because factoring is not polynomial time.
  3. Check that the resulting l is about the size of q.

What to watch for

Getting l about q has not been achieved for every embedding degree, and for large security levels it is not always the optimal target either, so curve choice remains an open engineering problem in the paper’s snapshot.

Useful background: The curves behind each type, Embedding degree.

Papers

Computing with encoded exponents

An encoded exponent [a] denotes a group element such as g raised to a. Group operations add exponents, scalar multiplication multiplies an exponent by a known scalar, and a pairing multiplies exponents from its two source groups.

Why it is useful

This lets a verifier check certain algebraic equations without learning the encoded values.

How it works

  1. Place each value in the required source group.
  2. Build linear combinations using public coefficients.
  3. Use a pairing to obtain a product in the target group.
  4. Check the resulting target-group equation.

What to watch for

The notation does not give an algorithm for reading a discrete logarithm. Pairing outputs live in the target group and cannot simply be fed back as arbitrary source-group inputs.

Useful background: Bilinear pairings.

Papers

Embedding degree

The embedding degree k is the integer with G1 inside E(Fq), G2 inside E(Fqk) and GT inside the multiplicative group of Fqk; it is the third parameter to fix alongside the base field size q and the group order l.

Why it is useful

It is the dial that trades curve security against field security. Small k puts GT in a small field where discrete logs are easy; large k makes GT safe but makes G2 elements and field arithmetic big and slow.

How it works

  1. Pick the group order l, the base field size q, and the embedding degree k together: the paper lists these as the three main parameters.
  2. A point of G1 is stored with about log q bits, while a point of G2 needs about k times as much.
  3. For Type 3 curves with even k, twists compress G2 by a factor of roughly k/2.

What to watch for

The paper warns that the three parameters cannot be chosen independently: at 256-bit security the natural choice k = 30 is one for which nobody knows how to build suitable curves.

Useful background: What a pairing computes.

Papers

Miller algorithm

Miller's algorithm evaluates rational functions along an addition chain for pairing computation.

Papers

Pairing final exponentiation

Final exponentiation maps a pairing's intermediate field value into its target subgroup.

Papers

The curves behind each type

Each type comes from a particular family of elliptic curves: Type 1 from supersingular curves, Types 2 and 3 from ordinary curves built by the CM method, with the trace map (or its kernel) supplying the group G2.

Why it is useful

The curve family fixes the embedding degree you are stuck with, and therefore the sizes and speeds of everything downstream. Choosing a type is really choosing a curve family.

How it works

  1. Type 1 uses supersingular curves: characteristic 2 gives embedding degree 4, characteristic 3 gives 6, and large prime characteristic gives 2.
  2. Type 2 uses an ordinary curve where the homomorphism from G2 to G1 is the trace map.
  3. Type 3 uses an ordinary curve where G2 is the kernel of that same trace map.

What to watch for

Supersingular in characteristic 2 or 3 pins the embedding degree at 4 or 6, which is why small-characteristic Type 1 curves stop being attractive once the security level grows.

Useful background: Three types of pairing groups.

Papers

The q-strong Diffie-Hellman assumption

The q-strong Diffie-Hellman assumption gives an attacker group encodings of powers of a hidden scalar and asks it to compute an inverse-exponent group element for a new scalar of its choice.

Why it is useful

It matches the inverse-exponent structure of BBS signatures and lets a reduction turn a successful forgery into a stated hard problem.

How it works

  1. Provide encodings of the hidden scalar's powers up to degree q, together with the required pairing-group data.
  2. The attacker chooses a scalar c.
  3. It must output the group element whose exponent is the inverse of x+c, where x is hidden.
  4. Exclude the zero-denominator case when stating a concrete problem.

What to watch for

This is not simply ordinary discrete-logarithm hardness with a different name. Auxiliary powers and the value of q matter to attacks and concrete parameters; the paper treats q-SDH and q-DL as equivalent only under the algebraic restriction.

Papers

Three types of pairing groups

Pairings are sorted into three types by how the two input groups relate: Type 1 has G1 = G2, Type 2 has distinct groups plus an efficiently computable homomorphism from G2 to G1, and Type 3 has distinct groups and no such homomorphism.

Why it is useful

The type decides which protocol designs are possible. Some security proofs need to move elements between G2 and G1, and those proofs break if the scheme is implemented with Type 3 pairings.

How it works

  1. Type 1: G1 = G2, one group used twice.
  2. Type 2: G1 and G2 differ, and a map phi : G2 → G1 can be computed efficiently.
  3. Type 3: G1 and G2 differ and no efficient map between them is known.
  4. Homomorphisms between two cyclic groups of the same order always exist mathematically, but computing them is believed as hard as a discrete logarithm, so they do not count as efficiently computable.

What to watch for

Type 1 looks like the convenient option because one group serves both inputs, but the paper calls it one of the least flexible choices in practice. The appendix also records a variant where G2 is the whole l-torsion subgroup, which makes every property in the paper’s table hold but wastes bits and can output a trivial pairing value.

Useful background: What a pairing computes.

Papers

Weil or Tate: which pairing to compute

Every pairing used in practice is the Weil pairing or the Tate pairing evaluated on an elliptic curve; the paper restricts itself to elliptic curves and treats the choice of algorithm as secondary.

Why it is useful

The choice between Weil and Tate matters for speed, not for what the protocol proves: both give a bilinear map with the same group structure, so a designer can pick whichever is faster to implement.

How it works

  1. Take two points on the curve and evaluate the Weil or Tate pairing to land in the finite-field subgroup GT.
  2. The Tate pairing finishes with a final powering (exponentiation) in the extension field, and some protocol costs can be folded into that step.
  3. The classic short-signature and identity-based encryption papers were stated with the Weil pairing, which is why the name keeps appearing.

What to watch for

This article is about choosing groups, not about pairing algorithms, so it gives no runtime comparison of Weil against Tate. Later optimisations such as the ate pairing and its variants are outside the paper’s 2006 horizon; the final powering it mentions survives inside them.

Useful background: What a pairing computes.

Related ideas

Papers

What a pairing computes

A pairing is a map that eats two points on an elliptic curve and outputs an element of a finite field, written e : G1 × G2 → GT, where G1, G2 and GT all have the same prime order l.

Why it is useful

The map is bilinear: multiplying the inputs by integers a and b before pairing gives the same result as raising the output to the power a times b. That single property is what lets a protocol combine two public values into one field element, and it is the engine inside identity-based encryption and short signatures.

How it works

  1. Take G1 and G2 to be groups of points on an elliptic curve E over a finite field.
  2. Take GT to be a subgroup of the multiplicative group of a related finite field.
  3. All three groups have the same prime order l, so exponents and point multiples live in the same arithmetic.
  4. The paper uses the two-input form throughout and treats the one-input form (G2 = G1) as a special case.

Example

Sketch: e(aP, bQ) = e(P, Q)^(ab). Both sides are elements of GT, and the equality is what protocols exploit.

What to watch for

The paper never defines bilinearity; it assumes you have seen a pairing before and concentrates entirely on which groups to use. For the algorithm that actually computes e you need other sources.

Related ideas

Papers

Pairing-friendly curve families

Families and parameter choices for curves supporting efficient pairings.

BLS12 curves

BLS12 curves are a pairing-friendly elliptic-curve family with embedding degree twelve.

Papers

Optimal Ate pairing

Optimal Ate pairings use a shortened function-evaluation loop tailored to pairing-friendly curves.

Papers

Curve models and group arithmetic

How a curve and its group arithmetic are modelled in practice, seen through this paper: a hyperelliptic curve of genus g is handled through the Mumford representation, where each divisor class is stored as a pair of polynomials and added with Cantor’s algorithm; the weight of a divisor is the degree of its u-polynomial and never exceeds the genus.

Divisor arithmetic and the Mumford representation

Every element of the Jacobian is stored as a pair of polynomials u(x) and v(x), the Mumford representation of the unique reduced divisor in its class. The degree of u(x) is called the weight of the divisor, and the divisor is prime when u(x) cannot be factored further.

Why it is useful

This representation is what makes the Jacobian practical: it gives a unique short name for each group element, and Cantor’s algorithm adds two such pairs without leaving the representation.

How it works

  1. Store a divisor class as the pair of polynomials u(x) and v(x) coming from its unique reduced divisor.
  2. Add two classes with Cantor’s algorithm, which combines the pairs and reduces the result.
  3. Read the weight off the degree of u(x); a reduced divisor has weight at most the genus, so the storage per group element is bounded by g.
  4. Check whether a divisor splits into weight 1 pieces by factoring u(x); index calculus calls such a divisor smooth, and this factorisation is the test that the attacks depend on.
  5. Use the hyperelliptic involution, which mirrors each point across the x axis and costs almost nothing to compute, to halve the number of pieces that must be tracked.

What to watch for

Weight at most g is what keeps divisor arithmetic cheap for small fixed genus. The complexity estimates in the paper count each Jacobian operation and smoothness test as one unit of time and hide those polynomial factors.

Useful background: Hyperelliptic curves and their Jacobians.

Related ideas

Papers

Edwards coordinates

Edwards-form curve models support rational addition formulas in affine or projective coordinates.

Papers

Extended Jacobian coordinates

Extended Jacobian coordinates store extra powers of a point's projective scale alongside its other coordinates. Those cached values can save work in repeated additions.

Why it is useful

An MSM may spend much more time adding input points into buckets than doubling points. A coordinate system can be chosen for the operation that dominates that workload.

How it works

  1. Represent the affine coordinates as x = X/ZZ and y = Y/ZZZ.
  2. Maintain the relation ZZ cubed = ZZZ squared.
  3. Use formulas that preserve this representation during point operations.

What to watch for

These coordinates use more storage than ordinary Jacobian coordinates. Their advantage depends on the mix of additions, doublings, field multiplication and squaring.

Related ideas

Papers

Genus: elliptic versus hyperelliptic curves

The genus is a number measuring how complicated a curve is. Genus 1 curves are the elliptic curves, and genus 2 or more gives hyperelliptic curves. The genus fixes both how large the Jacobian is, about q to the power g elements over a field of q elements, and which attacks apply.

Why it is useful

A designer can trade field size against genus: a genus 3 curve over a small field gives a Jacobian as large as an elliptic curve over a much larger field. This paper shows the trade has a price, because the best known attacks get faster as the genus grows.

How it works

  1. Genus 1 is the elliptic case, where the points of the curve themselves form the group used in cryptography.
  2. Genus 2 or more: the points no longer form a group, so arithmetic moves into the Jacobian, which has roughly q to the power g elements.
  3. The algorithms in this paper are proved for genus at least 3, and the gain they give is largest exactly at genus 3.
  4. When the genus is large compared with the field size, the discrete logarithm problem can be solved in subexponential time, so such curves are not usable for cryptography.

What to watch for

The paper compares genus 3 Jacobians with elliptic curves only through attack running times, and genus 1 and 2 fall outside its theorems. Its elliptic-curve statement concerns curves over extension fields reached by Weil descent, not ordinary prime-field elliptic curves.

Useful background: Hyperelliptic curves and their Jacobians.

Related ideas

Papers

Hyperelliptic curves and their Jacobians

A hyperelliptic curve is a curve that can be written with one equation of the shape y squared equals f of x, where f is a polynomial with no repeated roots. The number of handles of the resulting surface is the genus g, and the paper studies genus at least 3. The group used for cryptography is not the set of points of the curve but its Jacobian, written JacC(Fq), whose elements are divisor classes.

Why it is useful

On a curve of genus two or more the points do not form a group, so there is no point addition like on an elliptic curve. The Jacobian is the replacement: a finite abelian group in which every class has one short representative, so elements can be stored and added quickly.

How it works

  1. Fix a finite field Fq with q elements and a hyperelliptic curve C of genus g over it, given by an imaginary Weierstrass equation, which is the odd-degree version of the y squared equals f of x shape.
  2. Form divisors, that is formal sums of points of the curve with integer coefficients. Two divisors belong to the same class when they differ by the zeroes and poles of a rational function on the curve.
  3. Every class contains exactly one reduced divisor, and that representative is what a computer stores.
  4. Add two classes by combining their representatives; for fixed genus this group arithmetic runs in time polynomial in log q.

Example

A genus 3 curve over a field with q elements has a Jacobian of roughly q to the power 3 elements; that group is the target of the attacks in this paper. This is an illustration of the size, not a parameter recommendation.

What to watch for

The paper assumes this background rather than developing it, and states its theorems for genus at least 3, imaginary Weierstrass form and a cyclic Jacobian group. The y squared equals f of x description is standard background added here for reading, not a quotation from the paper.

Useful background: Finite fields, Elliptic curve point addition.

Related ideas

Papers

Short Weierstrass curves over prime fields

An elliptic curve over a prime field can be written in the short Weierstrass form y^2 = x^3 + a*x + b. Its solutions, plus one extra point at infinity that serves as the neutral element, form a group, and the group operation is what lets a signer compute k*P for a secret scalar k.

Why it is useful

This is the shape of the prime-field curves Android signs with (the experiments use NIST P-256), and the shape whose doublings and additions the paper tells apart in a leakage trace. Koblitz curves are the binary-field counterpart attacked by the same paper.

How it works

  1. The curve is the set of pairs (x, y) satisfying y^2 = x^3 + a*x + b, together with the point at infinity.
  2. To add two distinct points, use the slope lambda = (y1 - y2)/(x1 - x2); to add a point to itself, use the tangent slope lambda = (3*x1^2 + a)/(2*y1). The new point is (lambda^2 - x1 - x2, lambda*(x1 - x3) - y1).
  3. Both slope formulas need a field division, which is slow, so Bouncy Castle stores points in Jacobian coordinates (X : Y : Z) with x = X/Z and y = Y/Z, where doubling and addition avoid inversion entirely.
  4. Bouncy Castle 1.50 uses modified Jacobian coordinates: a doubling costs 4 multiplications and 5 squarings, an addition 13 multiplications and 6 squarings.

Example

The slope formula is the algebraic form of the geometric rule: draw the line through the two points, find the third intersection with the curve, and reflect it.

What to watch for

The different operation counts are exactly what makes the two routines visible in a leakage trace; a formula set that spent the same operations on both routines would remove this particular signal, at a cost in speed.

Related ideas

  • Koblitz curves: the binary-field counterpart attacked in the same paper

Papers

Tau-adic expansions and the TNAF recoding

Because 2 = mu*tau - tau^2, an integer scalar can be rewritten in base tau instead of base 2. Bouncy Castle uses the non-adjacent variant (TNAF), whose digits are -1, 0 or 1 with no two adjacent digits both nonzero, and a windowed variant whose digits are signed multiples of powers of tau.

Why it is useful

It removes the expensive step of the double-and-add loop. Instead of doubling the accumulator once per bit, the loop applies the nearly-free Frobenius map once per digit and only occasionally adds a precomputed point, which is why Koblitz scalar multiplication is fast.

How it works

  1. Recoding: use 2 = mu*tau - tau^2 to replace factors of 2, obtaining digits in {0, 1}; the non-adjacent form keeps digits in {0, +1, -1} with the extra condition that the product of two consecutive digits is 0.
  2. Windowing: for a width w, precompute the points P, +/-[alpha_3]P, +/-[alpha_5]P, ... where alpha_u is congruent to an odd u modulo tau^w; among any w consecutive coefficients at most one is nonzero.
  3. Main loop (Algorithm 4): for i from n down to 0, set Q = phi_2(Q), then if the digit k_i is nonzero add the matching precomputed point to Q.
  4. Every element of Z[tau] also has a canonical form a_0 + a_1*tau with ordinary integers a_0 and a_1, which is how a tau-adic expansion collapses to two numbers.

What to watch for

The positions of the nonzero digits are secret data. A trace that reveals those positions reveals the tau-adic expansion of the nonce, and that is enough for the lattice attack; the flip side is that tau-adic digits do not directly give the binary bits of the scalar, which is why a dedicated attack was needed.

Useful background: The Frobenius endomorphism of a Koblitz curve.

Papers

The Frobenius endomorphism of a Koblitz curve

The Frobenius map tau sends a point (x, y) to (x^2, y^2) and the point at infinity to itself. On a Koblitz curve it respects the addition law, so tau(P + Q) = tau(P) + tau(Q), and it satisfies (tau^2 + 2)P = mu*tau(P) for every point P, where mu = (-1)^a.

Why it is useful

Squaring in a binary field is close to free, so tau costs far less than a point doubling while acting on points like multiplication by a fixed constant. Every speed advantage of Koblitz curves, and the unusual side-channel behaviour studied in this paper, comes from this one map.

How it works

  1. Compute tau(P) by squaring both coordinates: squaring in F_{2^m} inserts a zero between each pair of bits of the element and then reduces modulo the polynomial defining the field.
  2. Use the characteristic relation tau^2 + 2 = mu*tau to treat tau as an algebraic number; the paper writes it as tau = (mu + sqrt(-7))/2, a complex number that is a root of X^2 - mu*X + 2.
  3. Work in the ring Z[tau] of such quadratic integers, where multiplying a point by any element of the ring is well defined through repeated application of tau.

Example

If a field element has bit pattern 1011, its square has bit pattern 1000101 before reduction, because a zero is inserted between each pair of bits.

What to watch for

tau is not an integer and not a real number: it is a complex number of absolute value sqrt(2), and that size is what later bounds the unknowns in the lattice attack on Koblitz signatures. In the extracted source text the radical signs are displaced, so tau = (mu + sqrt(-7))/2 appears with the radical stuck to the following word.

Useful background: Koblitz curves.

Papers

Edwards and twisted Edwards models

Curve equations, coordinate systems and group laws in Edwards forms.

Complete twisted Edwards group law

On FourQ the fastest known addition formulas are also complete: they add any two points, including the neutral element and a point added to itself, without special cases.

Why it is useful

Completeness removes the branching that a Montgomery ladder or Weierstrass implementation needs to handle exceptional inputs, which is exactly the kind of branching that leaks secrets through timing.

How it works

  1. Represent the affine point (x, y) by a projective tuple (X : Y : Z : T) with x = X/Z, y = Y/Z and T = XY/Z; the extra coordinate T speeds up the formulas.
  2. The neutral element is (0, 1) and the inverse of (x, y) is (-x, y).
  3. Because the curve constant d is not a square in F_{p^2}, the Hisil-Wong-Carter-Dawson formulas hold for every pair of points.

What to watch for

The non-square condition on d does not come for free on this curve: the authors pass through a 4-isogeny to a curve where d is a square and back, which adds roughly ten field multiplications to each endomorphism evaluation.

Useful background: FourQ: a complete twisted Edwards curve over a Mersenne prime field.

Papers

Montgomery models

Montgomery-form curves, differential arithmetic and model conversions.

Group encodings and maps to curves

Maps between field elements, byte representatives and curve groups, including quotient-group encodings and hash-to-curve mathematics.

Decaf

Decaf represents a prime-order quotient associated with an Edwards curve using canonical point encodings.

Papers

Elligator

Elligator maps between field elements and elliptic-curve points for point encodings.

Papers

Encoding bit strings as curve points

Many protocols need to treat a fixed-length bit string (say b bits) as a curve point, and to turn points back into strings. For most curves there is no efficient bijection (a one-to-one, onto map) of this kind, because a compressed point only uses about half of all possible field elements as x-coordinates. SafeCurves asks for an efficient constant-time bijection between all b-bit strings and a large fraction of the curve's points, a criterion called indistinguishability.

Why it is useful

Ad-hoc fixes are dangerous. Trying candidate strings in lexicographic order until one is a point leaks information through timing, which is exactly how the Dragonblood attack broke implementations of the WPA3 handshake. Protocols that hash passwords into points can also suffer partition attacks, where an attacker eliminates most wrong password guesses in a single session because most strings are not valid points.

How it works

  1. Use an Elligator-style construction: for curves with an even number of points, Elligator 2 gives a constant-time bijection between strings and roughly a quarter to a half of the points, with a retry when a string is not covered.
  2. Decode strings to points on the correct curve only, which automatically blocks invalid-curve attacks at the encoding layer.
  3. For protocols that need the prime-order subgroup specifically, also specify how points outside it are rejected, since the known bijections need a cofactor larger than 1.

Example

A password-authenticated key exchange can encrypt multiples of the base point under a key derived from the password; if only some strings decode to points, each observed session eliminates many password guesses at once.

What to watch for

This criterion is the least central of the SafeCurves requirements, and the string-to-point maps do not cover the prime-order subgroup: the Monero blockchain suffered a bug where points equivalent under the cofactor were accepted as separate spend authorizations.

Useful background: Twist security against invalid-curve attacks.

Related ideas

  • Curve25519: A curve whose even order admits an Elligator 2 bijection.

Papers

Ristretto

Ristretto constructs prime-order group encodings from a cofactor-bearing Edwards curve.

Papers

Simplified SWU map

The simplified SWU map maps field elements to elliptic-curve points through algebraic formulas.

Papers

Isogenies, group actions and quaternion methods

Isogeny evaluation and search, endomorphism rings, quaternion ideals and group actions on curves or abelian varieties.

CSIDH

CSIDH is a noninteractive key-exchange construction using a commutative action on supersingular curves.

Papers

Distortion maps for torsion generators

A fixed endomorphism of the starting curve, here the map sending (x, y) to (−x, iy), used to derive the second generator of each public torsion basis from the first.

Why it is useful

It makes both generators of a torsion basis describable with base-field data: the derived point lies in the trace-zero subgroup and is represented by two base-field elements only, which shrinks the public parameters by a factor of four.

How it works

  1. Take a point P of order ℓ^e defined over the base field Fp and apply the distortion map to get a second point of the same order over Fp2.
  2. The Weil pairing of P and its image is non-trivial, and the image lies in the trace-zero subgroup: adding the image to its p-power Frobenius conjugate gives the identity.
  3. Publish the generators as PA, QA = τ(PA) and PB, QB = τ(PB), so the second generator of each pair needs no storage at all.
  4. Check once, offline, how much of the torsion a pair actually generates by reading off the order of their Weil pairing.

What to watch for

For the even side the two generators never span the full 2^e-torsion: any point of the form P + [m]Q with m odd has order below 2^e. The implementation also samples secrets from only about a third of the possible 2-power kernels (about a quarter on the 3-power side), and the paper leaves the security effect of both restrictions open.

Useful background: Elliptic curve torsion subgroups, Weil pairing, Frobenius endomorphism.

Related ideas

Papers

Optimal strategies for isogeny computation

A scheduling method that decides, step by step during a large isogeny computation, whether to do another scalar multiplication or another small isogeny evaluation, so that the total number of operations is close to minimal.

Why it is useful

The two obvious schedules are wasteful: multiplying down to a small-order point every round, or storing every intermediate multiple and pushing all of them through each isogeny. A balanced schedule cuts the work by more than an order of magnitude.

How it works

  1. Model the computation as a directed acyclic graph whose leaves are the points that must eventually be evaluated by the isogeny.
  2. Define a strategy as a way of traversing that graph, and cost it using the measured latencies of one multiplication by ℓ and one degree-ℓ isogeny evaluation.
  3. Use dynamic programming: an optimal strategy on n leaves is built from two optimal strategies on strictly smaller leaf sets, so compute optimal strategies from small ℓ-powers upwards.
  4. Store the answer as a short list of integers; each entry records how many multiplication steps to take before the next split, which is enough to replay the whole schedule.
  5. Regenerate the list whenever the prime or the cost ratio changes.

Example

Illustration: with the optimized schedule Alice’s key generation needs 638 multiplications-by-4 and 1330 four-isogeny evaluations; the naive schedule needs 17020 multiplications-by-4 for 744 evaluations.

What to watch for

The strategy only balances two measured operation costs on one machine; it changes the schedule, not the mathematics, and the paper’s cost ratios came from averaging on an Intel Haswell processor.

Useful background: Smooth-order supersingular curves for large isogenies, Dynamic programming.

Related ideas

  • SIDH: the strategy is the difference between a practical and an impractical SIDH round

Papers

Projective curve coefficients in SIDH

Represent points by unscaled pairs (X : Z) and, unusually, represent the curve itself by an unscaled pair (A : C) as well, so that no field inversion is needed until the end of a whole key exchange round.

Why it is useful

Field inversions cost much more than multiplications. In classical elliptic curve cryptography the curve is fixed, so only the points need projective form; in SIDH the curve changes at every step of the walk, so the curve coefficients have to be carried projectively too.

How it works

  1. Write the Montgomery curve as By^2 = Cx^3 + Ax^2 + Cx, so the curve is described by (A : C) rather than by the single number a = A/C.
  2. Work on the x-line: drop the y-coordinate, so points become (X : Z), a point and its inverse are treated as the same object, and doublings, differential additions and triplings are computed on that quotient (called the Kummer line).
  3. Observe that every formula needed depends only on (A : C): a curve and its quadratic twist share the same Kummer line, so the B coefficient can be dropped entirely and twists are never distinguished.
  4. Carry the denominator C through each isogeny step instead of dividing by it, then normalize once at the very end, using one simultaneous inversion when publishing a public key and one inversion inside the j-invariant computation when deriving the shared secret.

What to watch for

Strictly speaking this computes maps between Kummer varieties rather than isogenies between curves. The paper stresses that the derived shared secrets are exactly the same as those obtained with affine Vélu formulas, so this is an implementation choice that does not change the protocol or interoperability.

Useful background: Montgomery ladder, Projective coordinates on elliptic curves, Quadratic twists.

Related ideas

  • Montgomery ladder: the x-only point arithmetic that this framework reuses
  • SIDH: the setting where the curve itself moves, which is what forces projective curve coefficients

Papers

Smooth-order supersingular curves for large isogenies

A recipe for the starting curve: pick a prime of the form p = 2^eA · 3^eB · f ± 1 so that a supersingular curve of order (2^eA · 3^eB · f)^2 exists over Fp2, and so that all of its 2^eA- and 3^eB-torsion points are defined over Fp2.

Why it is useful

An isogeny of degree 2^372 cannot be written down directly, but because the degree is smooth (built from many small prime factors) it can be computed as a chain of hundreds of degree-2 and degree-3 isogenies, each of which is cheap.

How it works

  1. Fix two small primes, written ℓA and ℓB (here 2 and 3), a cofactor f, and a prime p of the required form; a supersingular curve E over Fp2 of the matching order is then easy to construct.
  2. Pick two generators P and Q for the full ℓ^e-torsion. That torsion group is two copies of the integers modulo ℓ^e, because ℓ does not divide p.
  3. Given a kernel generator R of order ℓ^e, compute the point [ℓ^(e−i−1)]R_i, take the degree-ℓ isogeny whose kernel that point generates, and push R_i through it to get R_i+1.
  4. After e such steps the composition has degree ℓ^e and sends R to the identity, so its kernel is exactly the subgroup generated by R.

What to watch for

Secret isogenies are in one-to-one correspondence with cyclic subgroups of order ℓ^e, and there are ℓ^(e−1)(ℓ+1) of them, which bounds the number of possible secrets on each side.

Useful background: Elliptic curve torsion subgroups, Vélu’s formulas, Smooth numbers.

Related ideas

  • SIDH: this parameter shape is what makes the secret isogeny walk computable at all

Papers

Square-root Velu

Square-root Velu reorganizes kernel-point computations in isogeny evaluation.

Papers

Velu formulas

Velu formulas compute an isogeny and its codomain from a specified finite kernel.

Papers

Finite algebra and polynomial computation

Computational methods over finite fields, rings and polynomial algebras used across cryptographic functions.

Finite fields, towers and representations

Prime and extension fields, tower constructions, basis changes, inversion and root extraction as algebraic operations.

Cipolla-Lehmer-Muller

Cipolla-Lehmer-Muller computes finite-field square roots through extension-field arithmetic.

Papers

Field representation in binary polynomial arithmetic

A binary field element is encoded as bits representing polynomial coefficients. A protocol must specify which bit represents which coefficient, as well as the polynomial used to reduce products.

Why it is useful

Two implementations can perform mathematically correct field arithmetic and still disagree because they interpret the same bytes differently.

How it works

  1. Choose the binary field and its irreducible reduction polynomial.
  2. Specify the mapping between bits and polynomial coefficients.
  3. Implement addition and multiplication using that mapping.
  4. Check the encoded zero, identity and known multiplication examples.

Example

In the GHASH convention used here, the identity is a byte 0x80 followed by fifteen zero bytes, not fifteen zero bytes followed by 0x01.

What to watch for

The byte string for the multiplicative identity need not look like the integer one in the machine's ordinary integer format.

Papers

Multiplicative order of a field element

The multiplicative order of a nonzero field element H is the smallest positive number n for which H raised to n equals one. Its successive powers then repeat with period n.

Why it is useful

When a construction uses successive powers as weights, the order tells us when those weights start repeating.

How it works

  1. Start with a nonzero element in the field's multiplicative group.
  2. Find the smallest positive exponent that gives the multiplicative identity.
  3. Use that exponent as the period of the element's powers.

Example

An element of order three has powers H, H squared, 1, H, H squared, 1, and so on.

What to watch for

The number of elements in a field differs from the order of its multiplicative group: a field with q elements has q-1 nonzero elements. Zero has no multiplicative order.

Papers

Order tests using a factored group size

When the size of a finite cyclic group is known and factored, exponentiation tests can determine which factors occur in an element's order. GHASH has a square-free multiplicative-group size, so each prime factor can be tested separately.

Why it is useful

It gives a way to classify the cycle of a known hash key without enumerating that potentially enormous cycle.

How it works

  1. Exclude zero, which is not in the multiplicative group.
  2. Let M be the group size and factor it into distinct primes for the square-free case.
  3. For each prime p, compute H raised to M/p.
  4. A result different from one means p occurs in the order; multiply the primes that pass this test.

What to watch for

The simple one-test-per-prime rule needs the square-free group-size condition used here. Repeated prime powers require additional tests. Knowing how to classify H does not give an attacker H or the corresponding cipher key.

Useful background: Multiplicative order of a field element.

Papers

Squaring as a binary linear map

In a binary extension field, squaring is linear over the base field of two elements: squaring a sum gives the sum of the squares. With a fixed bit basis, it can therefore be represented by a binary matrix.

Why it is useful

Repeated squaring is common in exponentiation. A fixed matrix or precomputed tables can make those steps cheaper than general field multiplication.

How it works

  1. Fix the field representation and a basis for its bit vectors.
  2. Square each basis element to obtain the columns of the squaring matrix.
  3. Apply the matrix to the bits of any element to obtain its square.
  4. Compose the map to obtain higher powers of two.
  5. To raise the current intermediate Z to 2^(2^i)+1, apply the corresponding map to Z and multiply by that same Z. Repeating power maps multiplies their exponents.

Example

Raising H to 3 and then raising that result to 5 gives H^15. Squaring the intermediate twice but multiplying by the original H instead gives H^13.

What to watch for

This is linearity over the two-element base field, not multiplication by one constant over the entire extension field. Representation choices matter. Table-based speedups need a separate leakage analysis when indices depend on secrets.

Useful background: Field representation in binary polynomial arithmetic.

Papers

Tonelli-Shanks

Tonelli-Shanks computes square roots modulo an odd prime using the factorization of the field-group order.

Papers

Tower-field arithmetic

Tower-field representations build an extension field through a sequence of smaller extensions.

Papers

Polynomial algorithms and transforms

Evaluation, interpolation, multiplication and factorization, including multiplicative and additive transform domains.

Additive FFT

Additive FFTs evaluate polynomials over domains organized as additive subspaces.

Papers

Fast Fourier transform

A fast Fourier transform efficiently converts a coefficient vector into evaluations at structured roots of unity, or back again. Polynomial multiplication becomes pointwise multiplication in that evaluation representation.

Why it is useful

It speeds up the polynomial and matrix operations used by Falcon's lattice sampler.

How it works

  1. Choose a suitable structured set of roots.
  2. Recursively split the coefficient data into smaller transforms.
  3. Combine the smaller evaluations.
  4. Use the inverse transform when coefficient values are needed again.

What to watch for

Complex-valued FFT arithmetic uses finite precision. It differs from a number-theoretic transform over a finite field, even though the algorithms share a transform structure. Correct rounding and numerical bounds matter in signing.

Related ideas

Papers

Frobenius additive FFT

Frobenius additive FFTs use Frobenius relations among evaluations over binary extension fields.

Papers

Horner evaluation of a polynomial hash

Horner's rule evaluates a polynomial by repeatedly multiplying an accumulator and adding the next coefficient. GHASH uses this idea to process message blocks without separately computing every power of its hash key.

Why it is useful

The computation fits a streaming interface: one block updates a small running state.

How it works

  1. Start with a zero field element as the accumulator.
  2. Add the next encoded block to the accumulator.
  3. Multiply the accumulator by the hash key.
  4. Repeat for all blocks in the prescribed encoding.

What to watch for

The block order, finite-field representation, padding and length encoding are part of the construction. A raw polynomial evaluation is not by itself a complete message authentication code.

Related ideas

  • GHASH: Uses a Horner-style recurrence over a binary field.

Papers

Polynomial identity tests and hidden evaluation points

A nonzero low-degree polynomial has limited probability of vanishing at independently sampled field points. Proof arguments use this fact to distinguish a true polynomial identity from an accidental equality.

Why it is useful

It is the algebraic reason that a bounded-degree false relation cannot usually pass a suitably randomized equality test.

How it works

  1. Bound the polynomial degree.
  2. Specify how its evaluation points are sampled.
  3. Keep the polynomial independent of points that must remain unpredictable in the argument.
  4. Apply the appropriate root bound, including the number of tests and any excluded values.

Example

Over a field, a nonzero degree-two polynomial has at most two distinct roots. If it is fixed before a uniform point is sampled from 101 field elements, its chance of evaluating to zero is at most 2/101.

What to watch for

The point in Groth16 is hidden in the setup; this is not a public Fiat-Shamir challenge. The proof uses formal multivariate Laurent polynomials, so inverse terms require nonzero sampled scalars and an appropriate degree bound.

Papers

Strided Frobenius additive FFT

Strided Frobenius additive FFT reorganizes Frobenius-based evaluations for polynomial processing in HQC.

Papers

Vanishing polynomials

The vanishing polynomial of a finite set of distinct field points is the product of X minus each point. It is zero at every point in that set.

Why it is useful

Divisibility by this polynomial converts many pointwise equalities into a single algebraic condition.

How it works

  1. Choose distinct points r1 through rn.
  2. Form t(X) as the product of the factors X-ri.
  3. Build a polynomial P(X) expressing a constraint difference.
  4. Check whether P(X)=h(X)t(X) for some quotient polynomial h.

Example

For points 1 and 2 over the field with 7 elements, t(X)=(X-1)(X-2). Multiplying t by any polynomial gives a polynomial that is zero at both points.

What to watch for

For distinct points over a field, this divisibility is equivalent to P being zero at every chosen point. Repeated points add multiplicity conditions, and arbitrary rings need different care.

Papers

Lattice geometry and algebraic structures

Lattice reduction turns an arbitrary basis into a shorter, more orthogonal one. LLL does it in polynomial time with a loose guarantee; HKZ is strongest but exponential; BKZ trades between them by block size. Cryptanalysis uses weak reduction directly and models strong reduction to set lattice-scheme security.

A search-to-decision reduction for power-of-two moduli

The paper proves that deciding whether Learning With Errors samples are merely noisy or actually random is as hard as recovering the secret, for a wide range of moduli, including q a power of a small prime such as a power of two, which earlier reductions did not cover.

Why it is useful

The simplest and fastest form of the gadget wants q to be a power of two, but before this paper no search-to-decision reduction was known for such moduli, so using them would have rested on an untested assumption.

How it works

  1. Given a decision oracle, shift samples so that a guess at one secret entry either changes the distribution or does not; the oracle answer reveals whether the guess is right modulo p.
  2. Enumerate the residues modulo p to recover each entry, then iterate to higher powers of p and combine primes with the Chinese remainder theorem.
  3. Once most of the secret is known, round out the rest directly, because the noise is smaller than the rounding grid.

What to watch for

The reduction trades error rate: the distinguishing version may need noticeably larger noise than the search version (roughly an extra factor of omega of root-log n squared for prime-power moduli), and it neither covers the sample-preserving reduction of Micciancio and Mol nor means much when q itself is a very small prime.

Useful background: Why lattice cryptography needed strong trapdoors.

Papers

BKZ reduction

A family of block-wise reduction algorithms between LLL’s speed and HKZ’s quality, parameterized by a block size.

Why it is useful

Security estimates for lattice cryptography are set against the best practical attacks, and those attacks are built on BKZ with increasing block sizes.

How it works

  1. Slide blocks of the basis to a chosen dimension, HKZ-reducing each block.
  2. Larger blocks give better bases at steeply higher cost.
  3. In practice the algorithm is often stopped early once the target solution appears.

Example

Block size 20 is fast and weak; block sizes past 100 approach HKZ quality at enormous cost.

What to watch for

No polynomial bound on the number of block reductions was known; termination analyses are themselves research results.

Useful background: LLL basis reduction.

Related ideas

  • Shortest vector problem: the core subproblem

Papers

Ideal lattices: the ring, the ideal and what gets encoded

The construction works in a polynomial ring whose elements are also integer vectors, so the ring is a lattice. A secret short element g of the ring generates a principal ideal, the set of all multiples of g, and that ideal is itself a lattice. What the scheme encodes is not a single element but a coset: one ring element plus the entire ideal.

Why it is useful

Treating the ideal as a lattice is what ties the scheme to lattice problems: sampling short elements and finding short vectors in this lattice are the operations the construction and its attacks both use.

How it works

  1. Work in the cyclotomic ring of integer polynomials modulo X to the n plus 1, identified with the integer lattice of coefficient vectors.
  2. Choose a short secret g and let the ideal be all multiples of g; this ideal is a lattice with a basis built from rotations of g.
  3. Take the quotient ring, whose elements are cosets e plus the ideal; these cosets are the values the scheme encodes.
  4. Choose a second secret z uniformly at random modulo q; it is deliberately not short and acts as a hidden denominator.

What to watch for

The generator g and the denominator z stay secret, yet the paper shows an attacker can compute a basis of the ideal from the public parameters, so security rests on finding the short generator being hard, not on the ideal being hidden.

Useful background: From bilinear maps to graded encodings.

Papers

LLL basis reduction

An algorithm from 1982 that makes every vector in a lattice basis shorter and more orthogonal, in polynomial time.

Why it is useful

Shorter, better-aligned bases make lattice problems tractable enough to attack knapsack and RSA variants, and LLL is the workhorse behind Coppersmith’s small-root methods. It is also the fast end of the reduction ladder that lattice cryptography security estimates stand on.

How it works

  1. Take a basis of the lattice and a parameter close to one.
  2. Repeatedly size-reduce pairs of vectors and swap them when a length condition fails.
  3. Finish in polynomial time with a basis whose first vector approximates the shortest vector within an exponential-in-dimension factor.
  4. Stronger reductions (HKZ, BKZ) trade far more time for far better bases.

Example

In dimension n, the first LLL vector is guaranteed within roughly (4/3) to the power (n-1)/2 of the true shortest length.

What to watch for

The worst-case guarantee is exponentially loose in the dimension; real behavior is much better than the bound. The original 1982 paper predates this archive, so the linked paper is a later cryptographic treatment, not the origin.

Useful background: Lattice.

Related ideas

  • BKZ reduction: the stronger practical trade-off
  • Shortest vector problem: the problem being approximated

Papers

Noise growth bounds the multilinearity degree

Every addition and every multiplication makes the numerator of an encoding larger. Once it approaches the modulus, reduction modulo q wraps around and the encoding stops meaning anything, so the scheme supports only a bounded number of multiplication levels, and the modulus and the dimension must grow with that bound.

Why it is useful

The bound is both a shield and a wall: it blocks a generic discrete-logarithm attack that needs exponentiations of exponential degree, but it also fixes how many levels an application may use and forces large parameters.

How it works

  1. Track a noise bound with each encoding, the size of its numerator.
  2. Additions add the bounds; multiplications multiply them, so a product of many encodings has a much larger numerator.
  3. Set the modulus large enough that the top-level numerator still fits under about the eighth root of the modulus.
  4. Set the ring dimension large enough that lattice attacks on the resulting modulus cost the security level, which forces the dimension to grow with the number of levels times the square of the security parameter.

What to watch for

The paper states plainly that this dependence between degree and parameter size rules out applications needing compact maps, and that it could not reach the polynomial degree that another proposed application requires.

Useful background: Encoding a coset as a short numerator over a secret denominator.

Papers

Re-randomizing encodings with published encodings of zero

The public parameters contain many level-one encodings of the zero coset. Adding a random small integer combination of them to a fresh encoding changes nothing about which coset is encoded, but it wipes out the connection between the published value and the way it was produced.

Why it is useful

Without this step, two encodings made the same way would be related by simple algebra, and averaging attacks that recover the secret generator from many related samples become a threat. The paper borrows a countermeasure from the Gentry-Peikert-Vaikuntanatan signature work: sample the randomizers from a Gaussian distribution over a lattice, so the samples reveal nothing about the particular basis used to make them.

How it works

  1. Publish m encodings of zero, each a short element of the ideal divided by the secret denominator.
  2. To re-randomize a fresh encoding, draw a vector of small integer coefficients from a wide enough discrete Gaussian.
  3. Add the corresponding combination of the published encodings to the fresh one; the coset is unchanged because every added numerator lies in the ideal.
  4. Choose the Gaussian wide enough that the added noise drowns the original numerator, making the output distribution independent of the input except for its coset.

What to watch for

The authors state that the simplistic way of choosing these randomizers is suspect and that they use a more involved sampling procedure instead, and the argument that the Gaussian sampling hides everything is given without a formal proof.

Useful background: Encoding a coset as a short numerator over a secret denominator.

Papers

Smaller dimension, better quality: why small constants matter

The new generator needs only about 2n log q columns for a statistically near-uniform public matrix (down from more than 5n log q), reaches trapdoor quality about 1.6 times the square root of n log q, and stores a trapdoor that is not a basis: at least four times smaller than a basis of corresponding quality.

Why it is useful

Concrete lattice security is very sensitive to these constants: a smaller bound on preimage length makes attacks dramatically harder, and smaller parameters also shrink keys and speed up every operation, feeding a cycle of further savings.

How it works

  1. Compare dimension: a near-uniform A now needs about 2n log q columns instead of more than 5n log q.
  2. Compare quality: the trapdoor quality drops to about 1.6 times the square root of n log q, which directly shortens sampled preimages.
  3. Store the short rectangular R instead of an m-by-m basis, so storage grows linearly rather than quadratically in the dimension.
  4. Re-estimate concrete security: the paper reports fold improvements (for example, at least 112-fold on the preimage length bound for typical q) at equal estimated security.

What to watch for

These are 2011 asymptotic and concrete estimates, not a parameter recommendation; all quality and length figures omit a statistical smoothing factor of about 4 to 5, and the comparison baselines are the pre-2012 generators.

Useful background: Micciancio-Peikert trapdoors.

Papers

The Hermite factor: a yardstick for reduced bases

A single number that summarizes how well a lattice basis was reduced: the length of the first basis vector divided by the n-th root of the lattice determinant. Its n-th root, called the root Hermite factor, is the standard scale for comparing reduction algorithms.

Why it is useful

Attack costs for lattice cryptography are usually rated by the root Hermite factor an attacker can reach, so this one number drives key-size decisions and lets different algorithms and block sizes be compared on equal footing.

How it works

  1. Compute the determinant of the lattice, which equals the product of the lengths of the Gram-Schmidt vectors of the basis.
  2. Divide the length of the first basis vector by the n-th root of the determinant; this quotient is the Hermite factor.
  3. Take the n-th root of that quotient to get the root Hermite factor. Experiments summarized in the paper show it settles to a value that depends mainly on the algorithm and its block size, not on the particular lattice.

Example

The worst-case reference point is Minkowski’s bound on the shortest vector, which involves Hermite’s constant; reduction quality is measured against exactly this yardstick.

What to watch for

The convergence to a constant was observed for lattice dimensions of about 140 and above in the authors’ experiments; smaller dimensions give biased values, and repeated runs scatter around the constant by an amount that matters for security.

Related ideas

  • Shortest Vector Problem: the problem whose approximate solution quality is being measured

Papers

Why cryptographers care about basis quality

The quality of a reduced basis decides whether cryptanalysis succeeds and how lattice schemes must set parameters.

Why it is useful

Both directions use reduction: attacks on knapsack and RSA variants via small roots need only LLL, while judging lattice scheme security requires estimating what stronger reduction achieves.

How it works

  1. Weak reduction suffices for many classical attacks.
  2. Strong reduction is the main engine of attacks on lattice schemes.
  3. Parameter selection needs a model of the strongest feasible reduction.

What to watch for

The correspondence between security levels and concrete parameters remains the acknowledged obstacle to deployment.

Useful background: LLL basis reduction, BKZ reduction.

Related ideas

  • Small-root attacks: an application class

Papers

Basis reduction and short-vector algorithms

Basis reduction, nearest-plane methods, enumeration and sieving as general geometric algorithms.

BKZ reduction

BKZ reduces a lattice basis by solving short-vector subproblems in local blocks.

Papers

Lattice basis reduction

Basis-reduction algorithms and block-reduction methods.

Analyzing tours as a dynamical system

The paper tracks the logarithms of the determinants of growing prefixes of the basis. One full tour of DBKZ maps this vector by a fixed affine transformation, so the algorithm’s long-run behavior is the repeated application of one map: it has a single fixed point, and the distance to that point shrinks geometrically.

Why it is useful

This reframing turns “what will the algorithm output and when will it stop” into linear algebra about one matrix, yielding both the worst-case output quality and a polynomial bound on the number of tours without any heuristic assumption.

How it works

  1. Bound the length of each vector a tour inserts using the worst-case constant, then amortize the losses across a whole tour, following the Hanrot-Pujol-Stehlé technique.
  2. Read the composed forward-plus-backward tour as the affine map X mapped to (RA) squared X plus (RA plus I) times Rb, and solve for its unique fixed point.
  3. Show a matrix norm of the map is strictly below 1, so errors decay geometrically; for block size proportional to the dimension the tour count is polylogarithmic, and Neumaier’s subsequent argument extends polynomial convergence to every block size.

What to watch for

This is the worst-case branch of the analysis; the heuristic branch swaps the worst-case constant for GH(k). The tour bound grows on the order of (n/2k) squared for small block sizes, which is polynomial but not small.

Useful background: Recursive reducedness and the dual twist.

Papers

BKZ and Slide reduction: practice versus proof

The two reference points of block reduction. BKZ sweeps the basis in tours, calling a shortest-vector oracle on every projected block of size k, and is fast in practice but has no polynomial bound on oracle calls. Slide reduction calls the oracle only in dimension exactly k, provably terminates, and has the best worst-case bound, yet was reported to be far weaker in experiments.

Why it is useful

This mismatch forced cryptanalysts to use the practical algorithm and predict it heuristically. If the provable algorithm is actually competitive in practice, predictions can rest on its proof-friendly structure instead.

How it works

  1. BKZ tour: scan left to right, SVP-reduce each projected block of size k, and iterate until nothing changes; practical versions stop early using heuristic criteria.
  2. Slide reduction: alternately SVP-reduce the disjoint blocks, dual-SVP-reduce the blocks shifted by one position, and run LLL in between until stable.
  3. The paper’s experiments, with block sizes up to 75 on lattices of dimension a large-enough multiple of the block size, show Slide reduction becoming competitive: its confidence intervals overlap BKZ’s at block size 75.

What to watch for

The experiments used about ten random subset-sum lattices per block size, and Slide reduction formally requires the block size to divide the lattice dimension. The historical impression that Slide reduction is useless came from experiments with much smaller block sizes.

Useful background: Why lattice reduction beats its own worst case.

Papers

Dual enumeration without the dual basis

An algorithm that finds a shortest vector of the dual lattice by enumerating the integer scalar products of that vector with the primal basis vectors. It needs neither the dual basis nor its Gram-Schmidt form, and its pseudocode is nearly identical to ordinary primal enumeration.

Why it is useful

Dual SVP reduction otherwise costs a matrix inversion per block, which would erase the speed advantage of algorithms like DBKZ and Slide reduction. Once enumeration in the dual costs the same as in the primal, dual-reduction ideas become practical, and pruning techniques carry over unchanged.

How it works

  1. Walk the enumeration tree from the first basis vector upward, choosing the scalar products one level at a time.
  2. Maintain partial dual solutions whose squared lengths can be computed from already available quantities, which allows pruning the search tree exactly as in primal enumeration.
  3. Insert the found shortest dual vector into the basis through a unimodular transformation of the primal basis, using only its coordinates.

What to watch for

The measured speed, about 3.2 times ten to the seventh tree nodes per second and essentially equal to primal enumeration, comes from the authors’ machine and their implementation in fpLLL; the insertion step needs a careful strategy to keep the coefficients polynomially bounded.

Useful background: Recursive reducedness and the dual twist.

Papers

Predictable reduction and parameter selection

“Predictable” means the output quality follows a closed formula: choose a block size and read off the expected root Hermite factor. But each run draws from a distribution, and the paper measures standard deviations of roughly 0.0002 to 0.0004, up to about 0.00054, around the mean.

Why it is useful

An attacker runs the reduction many times and keeps the best sample, so a key sized against the average can be broken by a lucky run. Parameters must resist a tail value of the distribution, not its mean.

How it works

  1. Use the closed formula for the mean root Hermite factor at a given block size.
  2. Predict or bound the spread of the distribution; the paper could only conjecture a constant upper bound such as 0.0006 on the standard deviation.
  3. Translate mean plus spread into a value unlikely to be achieved. Distribution-free bounds like Chebyshev’s inequality are so weak that they produce absurd requirements, so the shape of the distribution, possibly a truncated Gaussian, must be studied with more data.

What to watch for

With about ten data points per block size the distribution cannot be pinned down, and the authors state plainly that their results do not yet translate into security estimates. Treating the average as the whole story is the main mistake these findings warn against.

Useful background: The Gaussian Heuristic as a closed-form predictor, Simulating BKZ instead of analyzing it.

Papers

Recursive reducedness and the dual twist

Block algorithms define their goal recursively: the first block must be SVP-reduced, and the rest of the basis, projected orthogonally past the block, must satisfy the same property again. The paper’s DBKZ keeps this recursion but requires the first block to end with a shortest dual vector instead of beginning with a shortest primal one.

Why it is useful

That one change forces every oracle call into dimension exactly k. The output bound then depends on a single worst-case constant, the Gaussian Heuristic applies uniformly to all calls, and the worst-case quality matches Slide reduction while the practical behavior matches BKZ.

How it works

  1. Read LLL as the k = 2 case of the same recursion: a two-vector block is SVP-reduced and the projected remainder is again LLL-reduced.
  2. Run a forward tour that SVP-reduces each block of size k, then a backward tour that dual-SVP-reduces the blocks from the other end, and repeat while progress continues.
  3. Stop when the projected tail of the basis no longer changes; the paper proves that this condition yields the stated reducedness property.

What to watch for

Dual SVP reduction is only cheap because of the companion dual-enumeration algorithm described next; without it, each block would cost a matrix inversion. The terminating condition must be chosen to both guarantee stopping and preserve the reducedness notion.

Useful background: BKZ and Slide reduction: practice versus proof.

Papers

Simulating BKZ instead of analyzing it

The standard prediction tool for BKZ before this paper: numerically estimate what the shortest-vector oracle achieves in every dimension up to the block size, then simulate tours of the algorithm on a synthetic basis until the predicted quality stabilizes.

Why it is useful

A predictor that is itself a program with extra assumptions shifts the trust question rather than answering it. Knowing where those assumptions sit matters whenever key sizes rest on the prediction.

How it works

  1. Estimate oracle performance separately in each dimension up to k, including the shape of a typical HKZ-reduced basis in dimension 45.
  2. Run the tour-by-tour simulation to convergence and read off the predicted root Hermite factor and basis profile.
  3. Contrast with a closed formula such as the Gaussian-Heuristic estimate, which needs no synthesized inputs at all.

What to watch for

The simulator demands implementation effort and synthesized inputs, and its accuracy rests on additional heuristics whose validity had not been independently checked; simulation errors also compound as the simulated tours proceed.

Useful background: BKZ and Slide reduction: practice versus proof, The Gaussian Heuristic as a closed-form predictor.

Papers

The Gaussian Heuristic as a closed-form predictor

A rule of thumb from geometry: a well-behaved set contains about volume divided by determinant lattice points. Applied to a ball, it predicts the length of a lattice’s shortest vector, written GH. Substituting GH(k) for the worst-case constant in an analysis that only uses dimension-k oracle calls gives the closed formula: the root Hermite factor is about GH(k) to the power 1/(k-1).

Why it is useful

One formula replaces a program: an estimate a cryptanalyst can evaluate directly instead of running and validating a simulator, and it extends beyond the first vector to the whole expected profile of Gram-Schmidt lengths.

How it works

  1. Assume each k-dimensional projected block that the oracle sees behaves like a random lattice, so its shortest vector has length given by GH of that block.
  2. Propagate the estimate through the recursive reduction structure; because every call is in dimension exactly k, a single constant covers all of them.
  3. The predicted Gram-Schmidt lengths then decay geometrically across most of the basis, matching the Geometric Series Assumption that cryptanalysts had long supposed but not proven.

What to watch for

The heuristic is only accurate from dimension about 45 upward. BKZ mixes in calls of smaller dimensions, where the heuristic fails, so plugging it into BKZ’s analysis is not automatically justified; and the geometric-series statement for the new algorithms is a consequence of the assumption, not a theorem.

Useful background: BKZ and Slide reduction: practice versus proof, The Hermite factor: a yardstick for reduced bases.

Papers

Why lattice reduction beats its own worst case

Provable statements about algorithms such as LLL and BKZ are guarantees for every possible input, so they describe the worst case. Real runs on typical inputs do much better: they find noticeably shorter vectors than the bounds promise, and the gap has persisted for over thirty years of research.

Why it is useful

Lattice cryptography is rated by how hard the best real attack is, and the attack is an actual run, not a worst case. If the analysis is loose, keys sized from the analysis look stronger than they are, and the paper identifies exactly this as an obstacle to adopting lattice cryptography.

How it works

  1. Compare bound with behavior: for LLL the provable root Hermite factor bound is about 1.0746, while experiments report values far below that.
  2. Treat reduction behavior as an empirical quantity, measured on random-looking inputs rather than derived from worst-case arguments.
  3. Search for algorithms whose analysis is tight, so that prediction and observed behavior agree instead of diverging.

What to watch for

The worst-case bounds are still true statements; every run satisfies them. They are loose, not wrong. Closing the gap calls for either sharper analysis of existing algorithms or new algorithms designed from the start to be analyzable.

Useful background: The Hermite factor: a yardstick for reduced bases.

Papers

Lattice sieving and enumeration

Algorithms for finding short vectors and assessing their resource costs.

Lattice enumeration

Lattice enumeration searches a basis-coordinate tree for vectors within a norm bound.

Papers

Lattice sieving

Lattice sieving combines vectors to build collections of progressively shorter lattice vectors.

Papers

Lattice trapdoors and distribution sampling

Trapdoor generation, preimage sampling, discrete Gaussians and response-distribution shaping over lattices.

Cumulative distribution table sampling

A cumulative distribution table maps a uniform random integer into intervals whose widths encode the probabilities of discrete outputs.

Why it is useful

It makes a fixed discrete distribution practical to sample, including the half-Gaussian proposal used in this Falcon implementation.

How it works

  1. Allocate intervals according to the required probabilities at the selected precision.
  2. Draw a random integer in the table's full input range.
  3. Find its interval using the specified boundary comparisons.
  4. Return the corresponding output, using a fixed memory-access pattern when the selection is sensitive.

What to watch for

Rounding, threshold ordering and endpoint conventions change the distribution. Full-table scanning prevents a lookup-index leak but does not repair incorrect thresholds. Independent boundary tests and independently derived values serve different purposes.

Papers

Discrete Gaussian sampling

A discrete Gaussian assigns probabilities to integers according to their distance from a center. Unlike a continuous Gaussian, its possible outputs are discrete even when the center is not an integer.

Why it is useful

Lattice signing can require carefully shaped randomness that hides the secret basis rather than merely producing short outputs.

How it works

  1. Specify the center and width convention for the target distribution.
  2. Compute or sample the required integer probabilities using an analyzed method.
  3. Include finite-precision and tail-handling effects in that method.
  4. Check that the sampler follows the distribution required by the surrounding construction.

What to watch for

A small norm, a plausible histogram or a valid final signature does not establish the required distribution. Falcon's centers depend on the signing target, so a single fixed table is not the whole sampler.

Related ideas

  • Gaussian mechanism: Uses noise for differential privacy, a different security goal and parameter analysis.

Papers

Gadget decomposition

Gadget decomposition expresses ring or vector entries in a structured digit basis for lattice constructions.

Papers

GPV Gaussian sampling

GPV sampling draws lattice preimages through sequential discrete-Gaussian sampling along a basis.

Papers

Rejection sampling for lattice signatures

Rejection sampling draws from an available proposal distribution and accepts a candidate with a chosen probability so that the accepted outputs follow the desired distribution.

Why it is useful

It can turn a convenient sampler into the particular distribution a lattice-signature security argument needs.

How it works

  1. Choose a proposal distribution with adequate support.
  2. Compute the prescribed acceptance probability for the proposed value.
  3. Use fresh randomness for the acceptance test.
  4. Retry on rejection and account for what the retry pattern reveals.

What to watch for

Correctness depends on the actual acceptance formula and finite-precision implementation. In the Falcon implementation described here, substituting exp(-C*x) for C*exp(-x) produced valid but insecure signatures. Other lattice-signature families use different proposals and tests.

Useful background: Discrete Gaussian sampling.

Papers

Noisy linear problems and structured lattices

Integer, ring and module formulations of noisy or rounded linear equations, short relations and convolution-based lattices.

Module learning with errors

Module learning with errors, or Module-LWE, concerns noisy linear equations whose entries are polynomials in a specified ring. The same secret polynomial vector is used in several equations, each with fresh small noise.

Why it is useful

Without the noise, linear algebra could expose the secret. The hardness assumption is that the noisy samples are difficult to distinguish from uniform samples at the chosen parameters.

How it works

  1. Choose a secret vector of polynomials.
  2. Sample public polynomial coefficient vectors.
  3. Compute their inner products with the secret and add fresh small error polynomials.
  4. Study whether an attacker can distinguish these noisy results from random values.

What to watch for

Hardness depends on the ring, modulus, dimensions and distributions. A reduction for one parameter regime is not a guarantee for every practical choice.

Related ideas

Papers

NTRU lattices

NTRU lattices have algebraic structure described by polynomial relations. In the Falcon example, the public polynomial h specifies pairs satisfying u+v*h=0 modulo the polynomial modulus and q.

Why it is useful

A secret short basis makes certain lattice computations feasible for the key holder while the public representation does not reveal that short basis.

How it works

  1. Work with integer polynomials modulo X^n+1.
  2. Choose small secret polynomials f and g and complete them with F and G so that f*G-g*F=q in that quotient ring.
  3. Publish h satisfying f*h=g modulo q.
  4. Use the secret basis to sample near a message-dependent target.

What to watch for

The NTRU equation alone does not supply secure parameters, key distributions or a secure signing sampler. NTRU encryption and Falcon use related lattice structure but are different constructions.

Related ideas

  • NTRU encryption: Uses related polynomial-lattice structure for encryption rather than this signature procedure.

Papers

Multivariate systems and computational algebra

Polynomial-system representations, elimination, Groebner bases and structured quadratic maps as constructive or solving tools.

F4 algorithm

F4 computes Groebner bases using matrix-based polynomial reduction.

Papers

Multivariate quadratic cryptography

Multivariate quadratic constructions encode cryptographic maps as systems of quadratic polynomial equations.

Papers

Probability distributions and sampling algorithms

Generic discrete and continuous sampling, rejection methods and statistical-distance analysis; entropy production is a separate topic.

Centered binomial sampling

A centered binomial sample is the difference between the sums of two equally sized collections of independent random bits. The result is a small integer centered around zero.

Why it is useful

Small-coefficient lattice schemes need a precisely specified noise distribution. Bit counting gives an efficient way to sample this particular one.

How it works

  1. Sample two independent groups of equally many unbiased bits.
  2. Count the ones in each group.
  3. Subtract the second count from the first.
  4. Repeat for the required coefficients.

Example

For two bits per group, counts 2 and 1 produce the sample 1. Counts 0 and 2 produce -2.

What to watch for

The distribution is not uniform over its range. Replacing it with arbitrary small integers changes both correctness and security assumptions.

Papers

Discrete Gaussian sampling from a basis

A randomized algorithm that outputs lattice vectors around a target point, each vector picked with probability falling off like a bell curve in the distance.

Why it is useful

Sampling with the correct spread, rather than picking any nearby point, is what keeps later schemes from leaking the shape of the secret basis.

How it works

  1. Take a basis of the lattice and a target point.
  2. Run a randomized version of the classic nearest-plane algorithm: choose each plane with probability set by how far the target is from it.
  3. Set the width parameter above the lengths of the basis vectors after Gram-Schmidt orthogonalization.
  4. The output follows the discrete Gaussian distribution over the lattice.

What to watch for

The sampler width must exceed the basis quality measure; a worse basis forces wider, longer outputs.

Useful background: Lattice.

Related ideas

Papers

Knuth-Yao sampling

Knuth-Yao sampling traverses a probability-distribution tree using random bits.

Papers

Rejection sampling for uniform residues

To map a uniform bounded integer into residues modulo q without bias, first restrict it to a range containing an exact multiple of q values, then reduce modulo q.

Why it is useful

Direct modular reduction is biased when some residues have more source values than others.

How it works

  1. Choose a source range with uniform values.
  2. Accept only a prefix whose size is a multiple of q.
  3. Reduce accepted values modulo q.
  4. Handle retries or bounded oversampling under the intended timing and failure model.

Example

For q=12289, accepting 16-bit values from 0 through 61444 gives 61445=5*q values. Every residue has exactly five preimages before conditioning on acceptance.

What to watch for

Falcon uses this inside hash-to-point; here point means a polynomial target, not an elliptic-curve point. A fixed oversampling budget has a failure probability and needs defined handling when too few samples survive.

Papers

Ziggurat Gaussian sampling

Ziggurat sampling partitions a probability density into layers and uses rejection steps.

Papers

Learning parity with noise

Learning parity with noise asks whether a batch of noisy linear equations over bits can be distinguished from random data. This paper treats it as equivalent to decoding a random linear code, reports exponential-time best attacks when the number of equations matches the secret length, and builds a commitment scheme whose hiding follows from it.

Exact LPN

Exact LPN, written xLPN, is the version of learning parity with noise in which the error vector has exactly ⌊kτ⌋ ones instead of each bit being flipped independently with probability τ. The error is drawn uniformly from all vectors of that exact weight. The commitment and all the protocols in the main part of this paper assume the decisional version of xLPN is hard.

Why it is useful

The protocols that prove relations among commitments reveal the weight of the error vector as part of their answers. If the weight can vary, that leaked number depends on the secret error and the zero-knowledge property breaks; with a fixed weight the leak carries no information. A fixed weight also removes the small chance that an honest protocol run fails.

How it works

  1. Sample the error uniformly from the set of k-bit vectors whose number of 1 entries is exactly ⌊kτ⌋.
  2. Search xLPN and search LPN are equally hard, because an ordinary LPN error has the target weight with noticeable probability, and conditioned on that the two distributions agree.
  3. Decisional xLPN is polynomially related to ordinary LPN through a sample-preserving reduction.
  4. That reduction relies on the Goldreich-Levin theorem and is not tight, so parameters that must be provably safe under ordinary LPN grow accordingly.

What to watch for

The paper assumes decisional xLPN directly. If ordinary LPN must be the only assumption, the known reduction is loose and the appendix protocol costs more repetitions.

Useful background: Learning parity with noise.

Related ideas

Papers

Learning parity with noise

Learning parity with noise (LPN) asks whether noisy linear equations over bits, written A.s ⊕ e, can be told apart from uniformly random strings. A is a public random binary matrix with k rows, s is a hidden secret of ℓ bits, and e is a random error vector in which only a small fraction of the entries are 1. Solving it is the same problem as decoding a random linear code, which has been studied for over half a century.

Why it is useful

It is the assumption that makes the commitment in this paper hide its message. It is also attractive on its own: with k proportional to ℓ the best known attacks take exponential time, no quantum algorithm is known to break it, and the only arithmetic is adding bits, which suits weak hardware such as RFID tags.

How it works

  1. Write down k random linear equations over the bits 0 and 1: the matrix A is public, the secret s is hidden, and each result is flipped with a small probability τ.
  2. The decision version asks to distinguish the noisy results A.s ⊕ e from uniformly random strings of the same length.
  3. The search version asks to recover s from the noisy equations; both versions are known to be equivalent, but the reduction needs many more samples than the search problem itself.
  4. With k proportional to ℓ, the best known algorithms need time about 2 to the power ℓ, so ℓ works as the security parameter.

What to watch for

Hardness is an assumption, not a theorem. The attack bounds are asymptotic and the sample counts matter, so concrete security needs a separate analysis.

Useful background: Linear equations over bits, Hamming weight.

Related ideas

  • Exact LPN: the fixed-weight variant the protocols in this paper assume

Papers

Learning with errors as lattice decoding

The learning-with-errors problem is the problem of decoding a lattice point after a small random shift, on the lattice that is dual to the scheme lattice.

Why it is useful

Seeing LWE geometrically explains where its trapdoors live and why small noise creates many plausible preimages.

How it works

  1. Take the dual lattice of the scheme lattice.
  2. Public data is a lattice point shifted by a small random error.
  3. Recovering the point is bounded-distance decoding.
  4. The trapdoor basis of the primal lattice enables this decoding.

What to watch for

Uniqueness of the closest point holds with overwhelming probability given small enough noise.

Useful background: Lattice.

Related ideas

  • Learning with errors: the computational problem

Papers

Parity noise as the simplest learning problem

Learning parity with noise is the two-value special case that learning with errors generalizes.

Why it is useful

It links this branch to the oldest noisy-learning assumption, used in lightweight identification schemes.

How it works

  1. Bits replace vectors: equations are over two values.
  2. A random fraction of equations is wrong.
  3. LWE replaces bits with vectors and errors with small numbers.

What to watch for

LPN stays an assumption of its own; the reduction value runs the other way, from lattice worst case to LWE.

Useful background: Learning with errors as lattice decoding.

Papers

Standard LPN commitment variant

An appendix variant of the commitment and of its proof of knowledge whose security rests directly on ordinary LPN instead of exact LPN. Its error is drawn with independent flips but conditioned on staying below twice the expected weight, and the proof uses partial permutations instead of full ones.

Why it is useful

It removes the loose reduction between xLPN and LPN at the price of a weaker guarantee per run and a slightly larger commitment.

How it works

  1. Draw the error with independent flips of probability τ but reject any vector heavier than 2τk; by a concentration bound the two distributions are statistically close, so LPN hardness is unaffected.
  2. The commitment matrix must then have distance at least 4⌊τk⌋ rather than 2⌊τk⌋, so the parameters grow.
  3. In the proof, the prover uses a partial permutation that sends exactly w positions to 0 and permutes the remaining ones, chosen so that it maps the error to the zero vector.
  4. Two extra challenges check the partial permutation and that its two opened images agree, which bounds the error weight by w.
  5. The knowledge error is 4/5 per run instead of 2/3, so roughly twice as many repetitions reach the same guarantee.

What to watch for

Whether this variant or the xLPN version is faster depends on the concrete parameters; the paper does not settle that choice. The relation can be generalised to bounds w1 ≤ ‖e‖1 ≤ w2, but no parameters are given.

Useful background: Exact LPN, Zero-knowledge proof of a commitment opening.

Papers

Pairing assumptions and parameter selection

Pairing-based schemes do not rest on one hardness assumption but on three at once: the discrete logarithm must be hard in each of G1, G2 and GT. The first two are elliptic curve groups, the third is a finite field subgroup reached through the embedding degree, so a security level fixes both the group order l and the extension field size. Because the group order doubles the security level while the field must reach RSA-like sizes, a pairing-based system scales like RSA rather than like elliptic curves, and the embedding degree must be chosen so that suitable curves actually exist. This paper sets out those constraints and the assumptions designers silently make about hashing, element sizes and parameter generation.

A two-chain of curves instead of a cycle

A cycle of curves is a set where the base-field size of each curve equals the group order of another, so proofs can be nested to any depth by going around the loop. Zexe instead uses a two-chain: the base-field size of the inner curve equals the group order of the outer curve, in one direction only.

Why it is useful

Known cycles of pairing-friendly curves at 128-bit security are inefficient, and Zexe needs to nest proofs exactly one level deep, so it can give up the loop and pick each curve for efficiency instead.

How it works

  1. Pick the inner curve first, choosing a pairing-friendly family that also suits fast proving in both fields.
  2. Use the Cocks–Pinch method to search for an outer curve over a field Fq whose group contains a subgroup of exactly the size of the inner curve’s base field.
  3. Prove predicates on the inner curve, and prove the statement that verifies those proofs on the outer curve.
  4. Because the outer curve’s circuit field equals the inner curve’s base field, the inner verifier runs natively inside the outer statement.

What to watch for

The chain is bounded: it supports proofs of proofs, not recursion of arbitrary depth as a cycle does. Nested proofs that must themselves nest again need a different construction.

Useful background: Native and foreign field arithmetic in recursive proofs.

Related ideas

Papers

Assumptions that do not all hold at once

Protocol papers routinely assume you can hash into G2, that G1 has short elements, that a homomorphism from G2 to G1 exists, and that parameters for any security level can be generated in polynomial time; no pairing realises all four.

Why it is useful

Each assumption is individually easy to satisfy, so an author who treats the pairing as a black box will not notice the conflict until implementation. The paper’s whole purpose is to expose that conflict before a scheme is designed around it.

How it works

  1. List the properties the protocol actually needs.
  2. Look them up in the paper’s table for Types 1, 2 and 3.
  3. Keep only the types where every needed entry is marked, and redesign if none survive.

What to watch for

Marking every box is possible only by weakening the setup, for example by taking G2 to be the full l-torsion subgroup, which costs bandwidth and can make the pairing trivial with probability 1/l. Composite-order groups, which some protocols want, exist only in the Type 1 setting and are more expensive than ordinary pairing groups.

Useful background: Three types of pairing groups.

Papers

Companion Edwards curves for cheap circuits

Zexe adds two plain twisted Edwards curves: EEd/BLS defined over the field Fr, so its group order matches EBLS, and EEd/CP over the field Fp, so its group order matches ECP. They carry the commitments and hash functions used inside the proofs.

Why it is useful

Commitments and collision-resistant hashes built from group exponentiations turn into very small arithmetic circuits when the group’s field is the same field the circuit computes in. Matching each Edwards curve to a proof curve’s subgroup order achieves exactly that.

How it works

  1. Pick a twisted Edwards curve whose base field is the subgroup-order field of a proof curve.
  2. Build Pedersen commitments and Pedersen hashes over its large prime-order subgroup.
  3. Inside a proof over that proof curve, opening a commitment or evaluating such a hash is then native arithmetic.
  4. Projecting a point to one coordinate shrinks the outputs further, since that projection is injective on the large prime-order subgroup.

What to watch for

These curves do not need to be pairing-friendly, because the primitives only use their group structure, and their security rests on discrete logarithms being hard in those groups.

Useful background: EBLS: the inner BLS12 curve of Zexe, ECP: the outer Cocks-Pinch curve of Zexe.

Papers

EBLS: the inner BLS12 curve of Zexe

EBLS is the curve Zexe uses for the inner proofs, the ones about user-defined predicates. It comes from the Barreto-Lynn-Scott family with embedding degree 12, meaning its pairing takes values in a field built on top of its base field by adjoining twelve layers; that base field is a 377-bit prime p, and its large subgroup has a 253-bit prime order r.

Why it is useful

It was chosen to serve two proof systems at once. Its own circuits live over Fr, and the outer curve’s circuits live over Fp, so both fields need a large power-of-two subgroup for the fast polynomial arithmetic that proof generation relies on.

How it works

  1. Take a BLS family curve with embedding degree 12, whose sizes sit near the 128-bit security guidelines.
  2. Choose the family parameter x so that both r(x) and p(x) are divisible by a large power of 2, which the paper arranges by taking x congruent to 1 modulo 3 times that power.
  3. The seed used is x = 3 · 2^46 · (7 · 13 · 499) + 1, and the same choice keeps efficient field towers available.
  4. Both fields hold large power-of-two subgroups inside their multiplicative groups, with exponents 46 and 47, which is what fast polynomial arithmetic needs.

What to watch for

The paper calls the curve EBLS and never uses the later name BLS12-377, which refers to the same parameters in later libraries. The printed hexadecimal primes wrap across table lines, so only the first line of each is quoted here.

Useful background: A two-chain of curves instead of a cycle.

Related ideas

Papers

ECP: the outer Cocks-Pinch curve of Zexe

ECP is the curve Zexe uses for the outer proof, the one that verifies the inner proofs. It was produced with the Cocks-Pinch method over a 782-bit prime field q, and its group contains a subgroup of prime order p equal to the size of EBLS’s base field.

Why it is useful

The Cocks-Pinch method lets you fix the subgroup order you want, here p, and then search for a curve over a suitable field with that subgroup. The price is a base field about twice as wide as the order you asked for.

How it works

  1. Fix the target subgroup order: the size p of EBLS’s base field.
  2. Run the Cocks-Pinch method to obtain a prime q and a curve over Fq whose group has a subgroup of order p.
  3. Accept a base field of about twice the bit length, so embedding degree 6 is enough to reach 128-bit security under the standard guidelines.
  4. Use compressed elements of 104 bytes in the first pairing group and 312 bytes in the second.

What to watch for

Operations on ECP are at least twice as costly in time and space as on EBLS because its field is twice as wide, which is why Zexe keeps it for proof checking only. The paper gives this curve no name beyond ECP; later systems call curves of this shape CW6 or CP6.

Useful background: A two-chain of curves instead of a cycle.

Related ideas

Papers

Native and foreign field arithmetic in recursive proofs

A pairing-based proof system built on a curve over the field Fq, whose points include a subgroup of prime order r, proves statements written as arithmetic circuits over Fr, but checking one of its proofs computes with elements of Fq. Arithmetic in a field your circuit cannot do natively has to be simulated, operation by operation.

Why it is useful

This mismatch is the whole difficulty of recursive proofs: the verifier being proved about lives in one field and the verifier doing the proving lives in another. It cannot be removed by choosing q equal to r.

How it works

  1. Note which field the circuits use: the field of the subgroup order r, not the base field q.
  2. Note which field the verifier uses: the base field q, through elliptic-curve operations and the pairing.
  3. To nest one proof inside another, express the inner verifier’s q-arithmetic inside a circuit over a different field, and pay the simulation cost for every operation.
  4. Choose curves so that the two fields coincide, which is what curve cycles and chains arrange.

What to watch for

Simulation is not forbidden, only expensive, and the paper gives no constant for it here; the fix is a choice of curves, not a faster simulation.

Useful background: Elliptic curve pairings, Succinct arguments and SNARKs.

Papers

One-generator q-SDH

When the two groups coincide, the pair (g2, g2^x) in the Journal-version instance merely repeats information already present, leaving the one-generator problem: given (g1, g1^x, g1^(x^2), ..., g1^(x^q)), output (g1^(1/(x+c)), c).

Why it is useful

It is the cleanest statement of the problem and the form the single-group reduction chain works with.

How it works

  1. Set G1 = G2, so g1 and g2 are the same generator.
  2. Delete (g2, g2^x) from the Journal-version instance; no information is lost.
  3. The Journal version over a single group is equivalent to this one-generator problem.

What to watch for

The redundancy argument is specific to G1 = G2; with two genuinely different groups the pair still carries information.

Useful background: The Journal of Cryptology version of q-SDH.

Papers

Reversing the power ladder

The reversal trick: set beta = 1/alpha and h = g^(alpha^q); then the original ladder read backwards, (h, h^beta, h^(beta^2), ..., h^(beta^q)), is a fresh, valid instance whose secret is beta.

Why it is useful

It proves that q-wDH and the exponent q-SDH problem are equivalent - an inverse-exponent target and a next-power target turn out to be the same difficulty - and the construction is worth reusing elsewhere.

How it works

  1. Set beta = alpha^-1 and h = g^(alpha^q); then h^(beta^j) = g^(alpha^(q-j)) and h^(beta^q) = g.
  2. A q-wDH oracle on the reversed ladder returns h^(1/beta) = g^(alpha^(q+1)), which is the exponent q-SDH answer.
  3. An exponent q-SDH oracle on the reversed ladder returns h^(beta^(q+1)) = g^(alpha^-1), which is the q-wDH answer.

Example

With q = 2: h = g^(alpha^2), and the reversed instance (h, h^beta, h^(beta^2)) equals (g^(alpha^2), g^alpha, g).

What to watch for

The trick consumes the entire ladder, so it needs all q powers and says nothing about instances that hand over fewer. The new secret beta differs from alpha, which is legitimate because an oracle accepts any valid instance.

Useful background: The exponent q-SDH problem and discrete log, The q-weak Diffie-Hellman problem, Shifting the secret exponent.

Papers

Shifting the secret exponent

The shift reduction: how to convert a solver for q-weak Diffie-Hellman into a solver for one-generator q-SDH by moving the secret exponent alpha to alpha + c.

Why it is useful

This construction is the proof behind the ladder's middle link, and it shows exactly why the strong problem is no harder than the weak one.

How it works

  1. Pick any c and view the instance as (g, g^alpha, ..., g^(alpha^q)).
  2. Rebuild the powers of the shifted secret, g^((alpha+c)^i) for each i. By the binomial theorem, (alpha+c)^i expands into known multiples of 1, alpha, ..., alpha^i, so each rebuilt power is a product of the given powers raised to public exponents; the note writes only that we compute them and leaves this algebra implicit.
  3. Hand the rebuilt ladder to a q-wDH solver, which returns g^(1/(alpha+c)).
  4. Output the pair (g^(1/(alpha+c)), c).

Example

With q = 2 and public c: g^((alpha+c)^2) = g^(alpha^2) times (g^alpha)^(2c) times g^(c^2), and each factor is either given or computable from g.

What to watch for

The rebuilt ladder must have exactly q rungs, and rebuilding the top rung already uses every given power, so nothing is spare. The conversion is exact, not approximate.

Useful background: One-generator q-SDH, The q-weak Diffie-Hellman problem.

Papers

Splitting one statement across two curves

The single statement a transaction proves is split into two: one relation holding everything except proof checking, proved over EBLS, and one relation holding only the checks of the inner proofs, proved over ECP. A transaction carries both proofs.

Why it is useful

Every check moved onto ECP costs at least twice what it would cost on EBLS, because ECP’s field is twice as wide. Splitting lets the cheap curve carry the bulk of the work and leaves the expensive curve with the one job it exists for.

How it works

  1. Write the checks of the whole transaction as one relation, then separate the inner-proof verifications from the rest.
  2. Prove the remaining checks with a proof system over EBLS.
  3. Prove the proof verifications with a proof system over ECP.
  4. Share the secret information the two relations need, such as the predicate identities and the transaction’s local data, through commitments included in both statements.

Example

Verifying an inner proof inside the outer relation costs 14n + 52626 constraints for an n-bit input.

What to watch for

The split costs size: a transaction now holds a second proof, 192 bytes for the EBLS proof and 520 bytes for the ECP proof, and the shared commitments must be opened consistently across two different fields.

Useful background: EBLS: the inner BLS12 curve of Zexe, ECP: the outer Cocks-Pinch curve of Zexe.

Papers

The Journal of Cryptology version of q-SDH

A later restatement of q-SDH: given (g1, g1^x, g1^(x^2), ..., g1^(x^q), g2, g2^x), output (g1^(1/(x+c)), c). The powers now arrive in G1, and no efficiently computable isomorphism between the groups is assumed.

Why it is useful

Because the solver gets no translation help, this version is at least as hard to solve as the original; resting a security proof on it therefore assumes less about the groups and covers more curve choices.

How it works

  1. Start from an original-version instance, whose powers sit in G2.
  2. Apply psi to each power g2^(x^i) to obtain g1^(x^i), and keep the pair (g2, g2^x).
  3. A solver for the Journal version, run on this converted input, returns the required pair.

What to watch for

The note proves only this one direction - the original version reduces to the Journal version - and claims no equivalence between the two.

Useful background: Two groups and their isomorphism, The q-strong Diffie-Hellman problem.

Papers

The paper’s practical guidance

The authors score each pairing type at 80-bit and 256-bit security against nine questions (hashing, representation size, group-operation cost, pairing speed, parameter flexibility) using zero to three stars.

Why it is useful

The scoring turns a list of impossibilities into a decision procedure: pick the type whose weaknesses you can live with, rather than discovering them after implementation.

How it works

  1. Answer questions H1, H2, S1, S2, E1, E2, E3, P and F for the candidate type.
  2. Read the stars relative to the same type as security grows, not as an absolute comparison between types.
  3. Prefer Type 3 at high security; it is the only choice with good performance and flexibility there, and a Type 2 pairing can be rewritten as a Type 3 pairing at the cost of one extra multiplication in G1.

What to watch for

The ratings are subjective and deliberately relative, and the conclusion is a nudge to protocol designers: write proofs that do not need a homomorphism from G2 to G1, because the best-performing type cannot offer one.

Useful background: Assumptions that do not all hold at once, Three discrete logs and the key sizes they force.

Papers

The q-SDH reduction ladder

In a single group the five problems line up as: original q-SDH, then the Journal version, equivalent to one-generator q-SDH, then q-weak Diffie-Hellman, equivalent to the exponent q-SDH problem. The notation A <= B means any solver for B can be repackaged as a solver for A.

Why it is useful

The ladder orders five look-alike problems by how much a solver must be able to do, which tells you which cryptanalysis results threaten which schemes.

How it works

  1. Read A <= B as: an oracle for B answers instances of A. Read the double arrow as: solvers convert in both directions, so the two problems have the same difficulty.
  2. If any problem on the right turns out to be easy, every problem to its left is easy as well.
  3. A scheme whose forgery reduces to a left-hand problem is therefore threatened by attacks on every problem to its right.

What to watch for

Every link is a one-way construction assembled from other papers (Mitsunari et al., Zhang et al., Reardon); the note claims no separation between any two problems, and it never compares them against plain discrete logarithm.

Useful background: One-generator q-SDH, The Journal of Cryptology version of q-SDH.

Papers

The q-strong Diffie-Hellman problem

The q-strong Diffie-Hellman problem (q-SDH) hands an algorithm the tuple (g1, g2, g2^x, g2^(x^2), ..., g2^(x^q)) built from one secret exponent x, and asks it to output a value c of its own choosing together with g1 raised to the power 1/(x+c).

Why it is useful

It is the hardness assumption behind the first short pairing-based signature scheme provably secure without random oracles: a forger can be converted into a solver for this problem, so if the problem is hard then forgery is hard.

How it works

  1. The instance exposes successive powers of one unknown exponent x but never x itself.
  2. The solver picks the shift c; only the group element carrying the exponent 1/(x+c), paired with c, must be produced.
  3. The exponent arithmetic happens in the field Zp of integers modulo a prime p, where 1/(x+c) means the multiplicative inverse of x+c modulo p.

Example

With q = 1 the instance is (g1, g2, g2^x); choosing c = 0 turns the task into producing g1^(1/x).

What to watch for

The number q is a parameter of the problem, not of the group: the larger q is, the more powers the solver receives, so claiming hardness for larger q is a bolder claim. The extracted text garbles the printed fractions; read them as the exponent 1/(x+c).

Related ideas

  • Digital signatures: the schemes whose forgery reduces to this problem

Papers

The q-weak Diffie-Hellman problem

The q-weak Diffie-Hellman problem (q-wDH): given the same ladder (g1, g1^x, g1^(x^2), ..., g1^(x^q)), output exactly g1^(1/x) - there is no freedom to choose a shift.

Why it is useful

It is the oldest problem of the family, introduced for traitor tracing, and in the reduction ladder it is one of the two hardest.

How it works

  1. Compare with q-SDH: there you choose c and hand over g1^(1/(x+c)); pinning c to zero would give this target, but q-SDH lets you dodge the hardest point.
  2. The appendix reduction makes the dodge explicit by shifting the secret before invoking a q-wDH solver.
  3. Zhang et al. showed that q-wDH is equivalent to the exponent q-SDH problem.

Example

In the original traitor-tracing application, values of this inverse-exponent shape served as the secret keys handed to users.

What to watch for

Strong and weak are historical names from the original papers, not difficulty ratings: in this chain the weak problem is the harder one to solve.

Useful background: The q-SDH reduction ladder.

Papers

Three discrete logs and the key sizes they force

A pairing-based scheme is only as strong as the weakest of three discrete logarithm problems: in G1, in G2 and in GT, so q and q to the k must both be large enough.

Why it is useful

Unlike plain elliptic curve cryptography, the pairing drags a finite-field discrete log into the system, so key sizes grow the way RSA key sizes grow rather than the way elliptic curve keys grow.

How it works

  1. Read the security level kappa from a key-size table; an elliptic curve group of about twice kappa bits gives kappa bits of security.
  2. Treat the RSA column of the same table as the size the extension field Fqk must reach.
  3. At 256-bit security this means a 512-bit group order and an extension field of at least 15360 bits, and any protocol that transmits pairing values pays for arithmetic in that field.

Example

NIST row quoted in the paper: 80-bit security needs a 160-bit curve group and a 1024-bit RSA-style field; 256-bit security needs 512 and 15360.

What to watch for

The three key-size sources the paper quotes (NIST, Lenstra, ECRYPT) disagree, and all are 2005-era figures; none of them is current parameter advice.

Useful background: Embedding degree.

Papers

Two groups and their isomorphism

The setting for the original q-SDH problem: two cyclic groups G1 and G2 of the same prime order p, with generators g1 and g2, plus an isomorphism psi from G2 onto G1 that maps g2 to g1. A cyclic group is one whose elements are exactly the powers of a single generator, and an isomorphism is a one-to-one renaming of elements that preserves the group operation.

Why it is useful

Pairing-based cryptography works with two such groups, and they play different roles: elements of G1 are typically compact and cheap to store. The isomorphism is a translation dictionary between the two groups.

How it works

  1. Both groups have the same prime order p, so they carry the same multiplication table under different names.
  2. The original definition of q-SDH requires psi to be efficiently computable, so anyone may rewrite a G2 element as a G1 element.
  3. When G1 and G2 are the same group, psi is simply the identity map.

What to watch for

On the asymmetric pairing curves used today, an efficiently computable isomorphism in this direction is a real restriction on the curve choice; dropping that requirement is exactly what the later version of the problem does.

Papers

When the parameters you want do not exist

Generating pairing parameters is not automatic: the security level fixes q and q to the k, hence k, but there may be no known way to produce an elliptic curve with that embedding degree and the right group order.

Why it is useful

This is what breaks the promise of asymptotic security. A proof that assumes parameters can be generated in polynomial time gives only heuristic evidence when the actual curves cannot be found.

How it works

  1. Compute the required field sizes from the security level.
  2. Divide the extension-field size by the group order to get the embedding degree.
  3. Search for a curve family with that k; for k = 30 and l about q about 2 to the 512 there is no known construction.

What to watch for

The paper defers the whole subject of pairing-friendly curve construction to other literature and only records the symptom.

Useful background: Three discrete logs and the key sizes they force.

Papers

Implementing cryptography safely

A sound mathematical construction can still fail in software or hardware. This branch covers arithmetic, key handling, encodings and information leaked through timing, memory access or power consumption.

Externally controlled free-running Simeck datapath

The paper's hardware interface without an internal finite-state controller. An external mode signal selects loading or running, and ordinary datapath flip-flops run without chip-enable signals. The environment must collect the ciphertext at the intended end of the run.

Papers

Cryptographic APIs, encodings and key lifecycle

Safe parsing and canonical serialization, parameter validation, key and nonce lifecycle, memory protection, protocol integration and algorithm migration.

Unambiguous encoding

An encoding is unambiguous when the encoded bytes identify exactly one sequence of input values. Cryptographic operations need to distinguish the boundaries between fields, not just their combined contents.

Why it is useful

If two different messages or contexts have the same encoding, a tag or hash of that encoding cannot tell them apart.

How it works

  1. Specify the order and representation of the fields.
  2. Make their boundaries recoverable, for example by fixed sizes or encoded lengths.
  3. Authenticate the boundary information along with the fields themselves.

Example

The pairs (ab, c) and (a, bc) both become abc under plain concatenation. Including each field's length distinguishes the pairs.

What to watch for

Simply concatenating variable-length strings is not enough. Padding must also preserve which original lengths and fields were supplied.

Papers

Efficient cryptographic computation

Implementation-level scheduling, representation and memory tradeoffs for arithmetic kernels; abstract algorithms are indexed under mathematics.

Counting instructions to predict speed

A back-of-the-envelope model that multiplies out the number of multiply-and-add instructions per modular multiplication, in order to guess the speed-up before writing any code.

Why it is useful

It separates what the algorithm guarantees from what the hardware does, and it predicts where a vectorized kernel should win or lose so that measurements can be checked against reasoning.

How it works

  1. Count the multiply-accumulate operations for each implementation as a function of the number of limbs.
  2. Compare the totals: the 2-way vector version uses half the operations of a 32-bit scalar version, and roughly twice as many as a 64-bit scalar version.
  3. Add the extra work the vector version needs, such as recomputing the quotient word and moving values in and out of vector registers.
  4. Bound the outcome: at most twice as fast as 32-bit scalar code, and about half the speed of 64-bit scalar code, assuming identical instruction cost.

What to watch for

The model assumes all instructions cost the same and dispatch at the same rate, which real processors violate; it also ignores data movement, shifting and masking entirely.

Useful background: Parallel Montgomery multiplication with two accumulators.

Papers

Platform-dependent speed of modular multiplication

The measured fact that the same vectorized Montgomery code can be nearly twice as fast, indistinguishable, or nearly twice as slow depending on which chip runs it.

Why it is useful

It warns that an arithmetic kernel is not fast in the abstract; its speed depends on the cost and pipelining of that chip's vector multiply instructions relative to its scalar ones.

How it works

  1. Benchmark the same pair of implementations on several processors, such as a 32-bit x86 tablet chip and several ARM system-on-chip designs.
  2. Compare against published numbers from independent benchmark suites and a standard library to check the baseline is fair.
  3. Where the vector version loses, look up the instruction latencies: a vector multiply that costs as much as two scalar multiplies erases the advantage.
  4. At run time, identify the chip and choose the sequential or the parallel algorithm accordingly.

What to watch for

The numbers come from 2013 tablet and phone hardware, and the authors found no good way to make one implementation fast on every ARM design at once. Faster general-purpose libraries can beat both versions when constant-time behaviour is not required.

Useful background: Counting instructions to predict speed.

Papers

Secret-dependent sliding-window exponentiation

Sliding-window exponentiation groups exponent bits so that a precomputed odd power can handle several bits with one multiplication. Squarings advance through the exponent, while the windows determine when multiplications occur.

Why it is useful

This saves arithmetic work, but a window schedule selected from a secret exponent can disclose information through the operation sequence.

How it works

  1. Precompute the odd powers needed for the chosen maximum window size.
  2. Scan the exponent and select nonzero windows.
  3. Square to advance through the bits and multiply by the corresponding precomputed power.
  4. Consider both the operation schedule and table selection when assessing leakage.

What to watch for

Window direction and selection rules matter. The paper's bit-inference rules apply to its particular sliding-window implementation, not to every windowed or constant-time exponentiation method.

Related ideas

Papers

SIMD vector arithmetic for big integers

A processor feature where one instruction applies the same operation to several data elements at once, for example multiplying two pairs of 32-bit words and producing two 64-bit results.

Why it is useful

Cryptographic big-number code performs millions of identical small multiply-and-add steps, so packing two of them into one instruction can nearly halve the instruction count without changing the algorithm.

How it works

  1. Load two word-sized lanes into one vector register; SSE2 on x86 offers 128-bit registers and ARM offers the comparable NEON engine.
  2. Use the vector multiply instruction, such as PMULUDQ on x86 or vmul on NEON, that widens two 32-bit lanes into two 64-bit results.
  3. Accumulate with vector add and subtract, and handle carries with shifts, masks and comparisons.
  4. Rearrange a serial algorithm so both lanes do useful, nearly identical work every step.

What to watch for

The lanes must stay in step: any value that only one lane needs must be extracted from the vector, and those extractions are pure overhead. Wider registers do not help unless the widening multiply instruction also exists.

Useful background: Interleaved Montgomery multiplication.

Related ideas

Papers

Integer, field and polynomial kernels

Limb arithmetic, modular reduction, inversion, multiplication and FFT or NTT implementations, including batching and precision constraints.

Barrett reduction

Barrett reduction approximates a division using a precomputed reciprocal for modular reduction.

Papers

Floating-point precision and rounding contracts

A floating-point format represents a finite set of numbers. Each operation must round its mathematical result according to a specified rule; intermediate precision and fused operations can change the result.

Why it is useful

A cryptographic sampler may depend on those low-order numerical details, so matching an algebraic expression is not enough to match its implementation.

How it works

  1. Fix the numeric format and rounding mode.
  2. Bound operands and exclude unsupported exceptional values.
  3. Control intermediate precision and unintended expression contraction.
  4. Check conversions to integers and any range assumptions used by rounding tricks.

Example

With binary64 round-to-nearest-even, the exact integer 2^53+1 lies halfway between representable neighbors and rounds to 2^53. Different intermediate precision can defer that rounding.

What to watch for

Binary64 hardware support alone does not establish constant-time behavior or the intended compiler semantics. Falcon's discussion is restricted to normal values and zeros; those exclusions require justification for the actual execution path.

Papers

Good's trick

Good's trick decomposes a polynomial transform using coprime factor sizes.

Papers

Integer emulation of floating-point arithmetic

Floating-point arithmetic can be implemented with integer operations on the encoded sign, exponent and significand instead of using a hardware floating-point unit.

Why it is useful

It can support systems without suitable hardware and give tighter control over instruction selection and rounding behavior.

How it works

  1. Decode the represented components.
  2. Align and combine significands with integer operations.
  3. Normalize and round according to the required format.
  4. Encode the result while preserving the allowed-value and timing contracts.

What to watch for

Integer-only code is not automatically constant-time. This implementation assumes fixed-time 32-by-32-bit multiplication and bounded shifts, and intentionally omits NaNs, infinities and subnormals. It is not a general replacement for an IEEE-754 library.

Useful background: Floating-point precision and rounding contracts, Constant-time execution assumptions.

Papers

Karatsuba multiplication

Karatsuba multiplication recursively replaces a pair of product decompositions with fewer subproducts.

Papers

Montgomery batch inversion

Montgomery's trick computes inverses of multiple nonzero field elements using products and a shared inversion.

Papers

FFT and NTT kernels

Transforms and their execution strategies for field and polynomial arithmetic.

Number-theoretic transform

A number-theoretic transform, or NTT, evaluates polynomial data in a finite field so that a suitable polynomial product can be computed through smaller products in the transformed representation. An inverse transform returns to coefficients.

Why it is useful

Polynomial multiplication is a major cost in many lattice constructions. A suitable transform replaces quadratic schoolbook work with a faster structured computation.

How it works

  1. Choose a field and roots of unity compatible with the polynomial ring.
  2. Transform both input polynomials.
  3. Multiply corresponding transformed values using the required representation.
  4. Apply the inverse transform and its normalization.

What to watch for

The ring, roots, ordering and scaling must agree. The complete transform described for this early Kyber modulus must not be assumed to be the same transform used by later variants.

Related ideas

Papers

Inversion and batch inversion

Individual inverses, simultaneous inversion and the conditions needed for zero inputs.

Hierarchical batch inversion

Hierarchical batch inversion organizes batches into levels for polynomial inversion work in NTRU+ key generation.

Papers

Modular multiplication and reduction

Modular multiplication is the dominant cost in RSA and similar public-key schemes, because a single exponentiation performs thousands of such products. Montgomery multiplication removes the division from modular reduction by storing values scaled by a power of two and folding in a multiple of the modulus at every word, so the reduction becomes shifts and adds. This paper shows how to run that kernel on vector units by splitting it into two identical arithmetic streams whose difference is the answer.

Branch-free final correction

Replacing the final if-statement that compares the result with the modulus by straight-line code that computes both possible answers and selects one with a bitmask.

Why it is useful

A branch taken on secret data can be timed, and the branch condition in modular reduction depends on the operands. Straight-line code takes the same path regardless of the data, so the running time does not leak the comparison outcome.

How it works

  1. Compute the difference (or the difference plus the modulus) and observe whether the subtraction borrowed.
  2. Build a mask of all ones or all zeros from that borrow flag.
  3. Select either the plain difference or the corrected one with a bitwise select, executing both arithmetic paths unconditionally.
  4. Apply the same treatment to the final conditional subtraction in the sequential algorithm.

What to watch for

This protects the comparison itself, not the whole algorithm: other input-dependent behaviour elsewhere in the code still has to be removed separately.

Useful background: Parallel Montgomery multiplication with two accumulators.

Related ideas

  • Timing attacks: the threat that motivates removing the branch

Papers

Interleaved Montgomery multiplication

The word-by-word form of Montgomery multiplication: each partial product is folded in and reduced immediately, so the running value never grows much larger than the modulus.

Why it is useful

Interleaving keeps the intermediate value at one or two limbs beyond the modulus instead of holding a full double-length product, which saves registers and memory traffic. It is the form used in most cryptographic libraries.

How it works

  1. Walk over the words of one operand from least significant to most significant.
  2. Add the word times the other operand to the running value.
  3. Multiply the lowest word of the running value by the precomputed constant and reduce modulo the radix to get the quotient word.
  4. Add that quotient times the modulus, then divide the whole running value by the radix.
  5. Finish with one conditional subtraction of the modulus.

What to watch for

The quotient word depends on the running value, which depends on the previous step, so the loop is inherently sequential. It also does not combine with subquadratic multiplication methods such as Karatsuba, which need the full product before reducing.

Useful background: Montgomery representation.

Papers

Montgomery multiplication

Montgomery multiplication computes a product with a built-in scaling factor so that modular arithmetic can avoid costly division by the modulus. Values are usually kept in this scaled form across many operations.

Why it is useful

Cryptography performs many multiplications modulo large integers. Saving work in this low-level operation improves the higher-level group or field computations that use it.

How it works

  1. Choose a radix R coprime to the modulus p; for an odd modulus it can be a suitable power of two.
  2. Encode a value a as aR modulo p.
  3. Multiply encoded values with Montgomery reduction, which removes one factor of R.
  4. Convert out of Montgomery form when ordinary values are required.

Example

Multiplying aR and bR and removing one factor of R leaves abR: the product is still in Montgomery form.

What to watch for

Montgomery arithmetic changes the representation. Ordinary inversion, serialization and comparisons must account for it; internal range assumptions and final reduction still matter.

Papers

Coarsely Integrated Operand Scanning

Coarsely Integrated Operand Scanning, or CIOS, is a multi-word Montgomery multiplication method. It interleaves multiplication of the operands with reduction instead of treating them as two completely separate passes.

Why it is useful

Interleaving lets an implementation control temporary storage and carry propagation while processing large integers a machine word at a time.

How it works

  1. Store the operands and modulus as arrays of machine words.
  2. Accumulate one portion of the product.
  3. Choose a reduction word that cancels the low word modulo the machine radix.
  4. Shift the working value and continue, then perform the required final reduction.

What to watch for

The best Montgomery multiplication variant depends on word size, available instructions, memory and modulus size. All carry chains and input bounds must match the selected algorithm.

Papers

Headroom-based CIOS optimization

The EdMSM paper gives a CIOS optimization that removes some additions by proving that certain high carry words are always zero. The proof needs unused space at the top of the modulus representation.

Why it is useful

A carry that cannot occur need not be propagated, but that saving is valid only under the proved bounds.

How it works

  1. Check the modulus bound required by the optimization.
  2. Require inputs already reduced modulo the modulus.
  3. Use the smaller temporary representation and omit only the carry operations covered by the bound.
  4. Retain the final conditional reduction.

What to watch for

With 64-bit words, the multiplication bound requires the top modulus word to be at most 0x7FFFFFFFFFFFFFFE. The paper's squaring optimization has a stricter bound; neither is a general license to discard carries.

Papers

Montgomery representation

Every value is stored multiplied by a fixed power of the radix, and multiplication of two stored values returns a value in the same scaled form.

Why it is useful

The scaled form is what lets the reduction become shifts: dividing by the radix is exact in this representation, so the result stays in the representation and a long computation needs no conversion in the middle.

How it works

  1. Choose the radix as a power of two larger than the modulus, for instance r to the n for an n-word modulus.
  2. Store A as A times r to the n modulo M.
  3. Multiply two stored values by computing their ordinary product, then reducing by the shift-based method, which divides by r to the n.
  4. Add and subtract stored values with the usual modular rules, since the scaling factor is common to both.
  5. Convert back once, at the end, with one more Montgomery multiplication by the unscaled constant.

What to watch for

Entering and leaving the representation costs extra multiplications, so it is worthwhile only when many modular multiplications run in a row.

Useful background: Montgomery multiplication.

Papers

Parallel Montgomery multiplication with two accumulators

A rearrangement of interleaved Montgomery multiplication that splits the running value into two parts, one holding the sum of the operand products and one holding the sum of the added modulus multiples, and returns their difference.

Why it is useful

The two parts can be computed at the same time, so a 2-way vector unit processes both in one instruction stream. Because the final answer is a difference rather than a sum, both parts stay below the modulus and never overflow into an extra word.

How it works

  1. Flip the sign of the precomputed constant: use the inverse of the modulus modulo the radix instead of its negation.
  2. Compute the quotient word from the first limb only, using the difference of the two accumulators' lowest words.
  3. Let one computation accumulate the products of operand words, and the other accumulate the products of quotient words times the modulus; both perform identical arithmetic on different data.
  4. At the start of each outer step, extract the two lowest limbs to form the new quotient word; the inner loop needs no extraction.
  5. Subtract the second accumulator from the first, and add the modulus once if the difference is negative.

What to watch for

The two lanes are not fully independent: the lowest limbs must cross over every outer iteration, and that communication is the price of the parallelism.

Useful background: Interleaved Montgomery multiplication, SIMD vector arithmetic for big integers.

Related ideas

Papers

The Mersenne prime field under FourQ

All of FourQ's arithmetic happens in F_{p^2} = F_p(i) with i^2 = -1, built on the Mersenne prime p = 2^127 - 1, that is, the prime one less than a power of two.

Why it is useful

Reducing modulo 2^127 - 1 is almost free on a computer: the bits that overflow 127 places can be added back at the bottom, so no expensive division by a general prime is needed. Since the field sits under every multiplication in the scalar multiplication, this saving is paid millions of times over.

How it works

  1. Work in F_p, where p = 2^127 - 1.
  2. Represent elements of F_{p^2} as a + b*i with i^2 = -1, so each F_{p^2} element costs two F_p elements.
  3. Carry out modular reduction with shifts and additions instead of division.

What to watch for

The choice is forced rather than free: 2^127 - 1 is the only Mersenne prime that fits high-security curves over quadratic extension fields, and demanding it together with a four-dimensional decomposition leaves essentially one known curve, so there are no backup parameters to move to.

Useful background: FourQ: a complete twisted Edwards curve over a Mersenne prime field.

Related ideas

  • Mersenne reduction: the reason the prime is fast

Papers

Vectorized Montgomery multiplication

A way to compute the product of two numbers modulo an odd modulus without ever dividing by that modulus. Each step divides by a power of two instead, which a computer does as a cheap shift.

Why it is useful

Reducing a product modulo a large modulus normally needs a division, and division is far slower than multiplication on a processor. Modular multiplication is the inner loop of RSA and of discrete-logarithm schemes, so any saving here is felt across public-key cryptography.

How it works

  1. Split each operand into words in radix r, where r is a power of two such as 2 to the 32nd.
  2. At each word, add one operand times the next word of the other, add a multiple of the modulus chosen to zero out the lowest word, then divide by r using a shift.
  3. After the last word, subtract the modulus once if the result is still too large.
  4. No trial division and no estimate of the quotient from the leading bits is needed.

Example

With a 32-bit word and an odd modulus, one iteration adds a multiple of the modulus that makes the running value divisible by 2 to the 32nd, then shifts right by 32 bits.

What to watch for

The modulus must be odd (so that it has an inverse modulo the power-of-two radix), and the method only pays off across a chain of multiplications, not for one isolated product.

Useful background: Montgomery multiplication.

Related ideas

  • Barrett reduction: another way to avoid division, which estimates the quotient instead of changing representation

Papers

Scalar multiplication, MSM and pairing kernels

Fixed-base and variable-base scalar operations, multiscalar multiplication, endomorphism use and optimized pairing execution.

Endomorphism acceleration

Scalar decomposition using efficiently computable curve endomorphisms. These techniques can complement multiplication algorithms.

Four-dimensional scalar decomposition

The Gallant-Lambert-Vanstone (GLV) idea, pushed to four dimensions here: rewrite one scalar m as a1 + a2*lambda_phi + a3*lambda_psi + a4*lambda_phi*lambda_psi modulo N, where each ai is at most 64 bits, and compute [m]P as [a1]P + [a2]phi(P) + [a3]psi(P) + [a4]psi(phi(P)).

Why it is useful

A plain scalar multiplication needs about 256 doubling-and-adding steps for a 256-bit scalar. Four 64-bit scalars processed together need only about 64 loop iterations, each doing one doubling and one table lookup addition, so the loop shrinks by a factor of four.

How it works

  1. Form the lattice L of zero decompositions: integer vectors (z1, z2, z3, z4) with z1 + z2*lambda_phi + z3*lambda_psi + z4*lambda_phi*lambda_psi congruent to 0 mod N.
  2. Solve (m, 0, 0, 0) in terms of a short basis of L and round the coefficients to integers; the rounding error lands back inside the lattice coset, so the result is still a valid decomposition.
  3. Use a Babai-optimal basis, chosen so the widest coordinate over all rounded decompositions is as small as possible, which bounds every ai below 2^64.

What to watch for

The decomposition is worth little if the basis is bad: the authors show that the usual reduced bases (LLL, or Lovasz-Scarf under the infinity norm) are not optimal here, and that the width of the basis sets the worst-case loop length.

Useful background: The endomorphisms psi and phi.

Papers

GLS endomorphism

GLS uses endomorphisms on curves over extension fields to decompose scalar multiplications.

Papers

GLV decomposition

GLV decomposes elliptic-curve scalars using an efficiently computable curve endomorphism.

Papers

The endomorphisms psi and phi

An endomorphism is a map from a curve to itself that respects the group law. FourQ has two cheap ones: psi, coming from the Q-curve construction and the p-power Frobenius map, and phi, coming from complex multiplication by the order of discriminant -40.

Why it is useful

Each endomorphism acts on the order-N subgroup like multiplication by a fixed constant (its eigenvalue), so computing psi(P) or phi(P) is far cheaper than a general scalar multiplication, yet it moves the point just as far.

How it works

  1. Build psi by composing a 2-isogeny to the Galois conjugate curve with the p-power Frobenius map back, giving an endomorphism of degree 2p.
  2. Build phi from complex multiplication, realized as a 5-isogeny composed with Frobenius.
  3. Evaluate phi(P), psi(P) and psi(phi(P)) once per scalar multiplication, for a total of 68 multiplications, 27 squarings and 49.5 additions in F_{p^2}.

Example

Applying psi to a point P gives the same result as multiplying P by its eigenvalue lambda_psi modulo N, but at the cost of a few dozen field operations instead of a full scalar multiplication.

What to watch for

The stated operation counts are exact for this implementation and these explicit formulas; a different platform or a different formula set gives different counts.

Useful background: FourQ: a complete twisted Edwards curve over a Mersenne prime field, Complete twisted Edwards group law.

Papers

Multi-scalar multiplication (MSM)

An MSM adds many weighted group elements into one result. The useful distinctions are how many points there are, whether they are reused, how much memory is available and whether the scalars must be hidden from side channels.

EdMSM

EdMSM combines bucket-based MSM with arithmetic and point representations tailored to suitable twisted Edwards curves. It precomputes combinations of coordinates that will be reused whenever an input point is added to a bucket.

Why it is useful

Reducing the cost of the most frequent point additions can speed up the whole MSM, even without changing the high-level bucket algorithm.

How it works

  1. Use a curve and subgroup for which the chosen conversion and addition formulas are valid.
  2. Convert reusable input points and cache coordinate combinations.
  3. Run bucket accumulation with the specialized mixed additions.
  4. Use the appropriate formulas for combining buckets and windows.

What to watch for

The reported results concern particular curves, implementations and machines. An arbitrary curve does not acquire a suitable Edwards model merely by being part of a curve cycle.

Related ideas

Papers

Cached coordinates for repeated Edwards additions

For the twisted Edwards case studied in EdMSM, a reusable affine point is stored through combinations y-x, y+x and 2dxy. These are values the repeated addition formulas would otherwise recompute.

Why it is useful

A little extra preparation for each base point saves arithmetic each time that point is accumulated into a bucket.

How it works

  1. Start with an affine point on the required twisted Edwards model.
  2. Precompute y-x, y+x and 2dxy using that curve's parameter d.
  3. Use the addition formulas designed for these cached coordinates.

What to watch for

This is a specialized representation, not a generic serialized point format. Whether formulas cover all inputs depends on the curve parameters and the permitted input domain.

Papers

Multi-scalar multiplication

A multi-scalar multiplication, or MSM, adds many scalar multiples of group elements. On an elliptic curve, the inputs are points and numbers; the output is one point equal to the sum of all the requested multiples.

Why it is useful

Proof systems and other group-based protocols often need a large weighted sum of points. Sharing work across the sum can be much faster than multiplying every point separately.

How it works

  1. Pair each input point with its scalar.
  2. Choose an algorithm suited to the number of points, available memory and whether the points can be reused.
  3. Compute the weighted sum using shared additions and doublings.

Example

For points P and Q, the MSM 3P + 5Q produces one point. The integers are scalars, not coordinates.

What to watch for

MSM is an arithmetic task, not a proof system or a security assumption. The fastest algorithm depends on the input size and hardware.

Papers

Bucket-based MSM

Pippenger-style bucket accumulation and associated arithmetic optimizations.

Pippenger MSM

The bucket version of Pippenger's algorithm computes a large weighted sum by grouping points whose scalar digits match. It processes several bits of every scalar at a time.

Why it is useful

Points that share a digit can be added together before applying that digit's weight. This reduces the work in large MSMs.

How it works

  1. Split each scalar into fixed-width windows of bits.
  2. For one window, place each point into the bucket named by its digit; ignore zero digits.
  3. Add the points within each bucket.
  4. Combine the bucket sums using a descending running sum.
  5. Combine the window results with the required doublings.

What to watch for

Larger windows require more buckets and memory. Bucket accesses depend on scalar digits, so an ordinary bucket implementation should not be assumed to hide secret scalars from side channels.

Related ideas

Papers

Descending bucket accumulation

Once bucket j contains the sum of all points with digit j, the window result is the sum of j times bucket j. Two running sums compute this weighted total without a separate scalar multiplication for each bucket.

Why it is useful

The bucket indices are consecutive small integers. Their regular structure lets additions replace many multiplications.

How it works

  1. Visit the buckets from the largest index down to one.
  2. Add each bucket into a running sum.
  3. Add that running sum into the total at every step.

Example

For buckets B1, B2 and B3, add B3, then B3+B2, then B3+B2+B1. The total is B1+2B2+3B3.

What to watch for

Zero and empty buckets, the largest digit and the loop boundaries must be handled consistently with the chosen recoding.

Papers

Window-level MSM parallelism

The smaller MSMs for different scalar windows can be computed independently. A multicore implementation can assign different windows to different workers, then combine their results.

Why it is useful

The window split creates parallel tasks without changing the mathematical weighted sum.

How it works

  1. Split scalars into windows.
  2. Give each worker its own bucket array for one or more windows.
  3. Compute the window results independently.
  4. Combine the results in their correct positional order.

What to watch for

Parallel workers multiply the bucket-memory requirement. Splitting an MSM into arbitrarily many smaller MSMs also adds overhead, so more workers do not guarantee a speedup.

Papers

Parallel and hardware MSM

GPU, FPGA and other parallel implementations. A reported speedup depends on its curve, workload and baseline.

Simultaneous scalar multiplication

Interleaving and joint representations for computing several scalar-point products together.

Straus multiscalar multiplication

Straus multiplication shares doublings across scalar expansions in a multiscalar product.

Papers

Pairing computation

Miller loops, final exponentiation and implementation techniques for bilinear pairings.

Scalar multiplication

Single-scalar algorithms, precomputation and scalar recodings. Public- and secret-scalar workloads have different implementation constraints.

Comb scalar multiplication

Comb methods precompute combinations of spaced scalar bits for fixed-base multiplication.

Papers

Ladders and complete addition formulas

The ladder criterion requires that the curve support single-coordinate scalar multiplication: computing nP from just one coordinate of P, producing one coordinate of nP, in a way that is simultaneously simple, fast and constant-time, meaning the computation takes the same time for every secret. The completeness criterion goes further: the group-law formulas must work for every possible pair of inputs, with no exceptional cases. Montgomery curves give the first through the Montgomery ladder, and Edwards curves give the second through a complete addition formula.

Why it is useful

The natural fast algorithms for short Weierstrass curves branch on secret data: the standard from P1363 adds or subtracts depending on bits of the secret, and precomputed tables leak through memory access. Each leak can be closed, but every fix adds code that can be wrong, and slower secure code tempts implementors toward faster insecure code. Incomplete formulas have the same shape of problem: the obvious addition formula fails for doubling or for adding a point to its own negative, and fixes need extra branches.

How it works

  1. For key exchange, run the Montgomery ladder: for each bit of n, unconditionally swap or do not swap two points using arithmetic instead of a branch, then perform one doubling and one differential addition (an addition that also gets the difference of the two points).
  2. Keep the loop length fixed, so the number of iterations does not leak the size of the secret.
  3. For signatures, use Edwards curves where d is not a square: the single addition formula then adds every pair of points correctly, and constant-time code becomes the simplest code to write.

Example

The paper prints the whole Curve25519 ladder in a dozen lines of Python, including the branch-free conditional swap written as arithmetic on the coordinates.

What to watch for

A ladder that exists but is slow does not qualify, because implementors will not use it: the paper cites a 19M-per-bit ladder for short Weierstrass curves as too slow next to the roughly 10M-per-bit insecure alternatives, and fixed-base precomputation still tempts implementors toward incomplete formulas.

Useful background: Montgomery ladder, Safe curves: ECC security beyond ECDLP security.

Related ideas

  • Ed25519: The signature system built on Edwards-curve complete formulas.
  • Montgomery ladder: The single-coordinate algorithm the criterion is named after.

Papers

Lim-Lee comb method

A comb method discussed as a component of a fixed-base scalar-multiplication construction. Its exact relationship to the broader comb entry remains unreconciled.

Papers

Measured speed and deployment notes

On the x64 processors benchmarked in the paper, a variable-base scalar multiplication on FourQ ran about four to five times faster than NIST P-256 and two to three times faster than Curve25519 implementations of the day.

Why it is useful

The numbers show what the field choice, the complete Edwards formulas and the four-dimensional decomposition add up to in practice, and they justify using one curve routine for both Diffie-Hellman and signature-style protocols.

How it works

  1. Use fixed-base precomputation for public-key generation and variable-base multiplication for the shared secret, as in ephemeral Diffie-Hellman.
  2. Build the library without the endomorphisms if desired; it is then still about three times faster than P-256 and up to 1.6 times faster than Curve25519.
  3. Validate input points on the curve and multiply by the cofactor 392 unless the input is already known to have order N.

What to watch for

Twist security, a property Curve25519 relies on for x-coordinate-only ladders, is not the relevant defence here: the largest prime factor of the twist order is only 158 bits, so FourQ instead always validates points and uses both coordinates. Disabling cofactor multiplication is only safe for inputs known to lie in the order-N subgroup.

Useful background: FourQ: a complete twisted Edwards curve over a Mersenne prime field, Four-dimensional scalar decomposition.

Related ideas

Papers

Mixed-coordinate point addition

Mixed addition combines points stored in different coordinate forms. A common choice stores reusable input points in affine coordinates while keeping the changing accumulator in projective or extended coordinates.

Why it is useful

Affine points take less storage, while the accumulator's extra coordinates can avoid an expensive field inversion at every addition.

How it works

  1. Store the unchanged input points in the chosen compact representation.
  2. Keep running sums in the coordinate system suited to repeated arithmetic.
  3. Use an addition formula designed for that exact combination of representations.

What to watch for

Coordinate formulas have input conditions and exceptional cases. The word mixed does not imply that arbitrary point representations can be combined.

Related ideas

  • EdMSM: Tailors representations to the dominant additions inside its MSM.

Papers

Montgomery ladder

The Montgomery ladder computes scalar multiplication through a repeated differential-addition and doubling pattern.

Papers

Where the processor time goes

On the STM32F410RB at 48 MHz, the measured averages were about 284 ms to generate a key pair or compute a shared secret, 336 ms to sign and 368 ms to verify a signature, against about 2.8 ms for one AES encryption. A full routine exchange on the device, meaning decrypt, verify, encrypt and sign again, averaged about 711 ms.

Why it is useful

Almost all of the elliptic-curve cost is scalar multiplication, that is, computing k times P for a 256-bit k, and both signing and verifying need at least one such multiplication. The comparison with AES makes the shape of the budget clear: the public-key steps cost two orders of magnitude more than the symmetric ones, which is why they are used only to set up and authenticate a session and AES then carries the bulk traffic.

How it works

  1. Identify the operations that contain a scalar multiplication: key generation, shared-secret computation, signing and verification.
  2. Measure each one separately, as the paper does, instead of timing the protocol as one block.
  3. Keep the public-key operations rare, and use the fast symmetric cipher for the actual data.

What to watch for

These numbers belong to one board, one library, one clock speed and one message size. A faster core, a hand-written assembly inner loop or a different curve changes them substantially, and the paper does not report code size or energy, which on a battery-powered device can matter as much as latency.

Useful background: Timing an elliptic-curve protocol on real hardware.

Papers

Scalar recoding and addition chains

Signed digits, non-adjacent forms and joint recodings used to organize group operations.

Constant-time recoding and the main loop

Recoding turns the four 64-bit multipliers into digits in {-1, 0, 1} whose table lookups and additions take a fixed number of steps, whatever the secret scalar is.

Why it is useful

A naive multiexponentiation would loop a variable number of times and sometimes add nothing, and both behaviours depend on secret bits. Fixed-length recoding with a guaranteed non-zero leading digit removes those dependencies.

How it works

  1. Recoded digits so the first multiplier has a non-zero digit at every one of the 65 positions, fixing the loop length at 64 iterations.
  2. Align the signs of the other three multipliers with the first, so an 8-element lookup table of P, phi(P), psi(P) and psi(phi(P)) combinations suffices instead of 16 elements.
  3. Run 64 doublings and 64 additions, each selecting a table row and a sign by masked operations.

What to watch for

The recoding itself must be implemented in constant time; the paper gives an implementer-friendly version of the algorithm whose lines map onto branchless code.

Useful background: Four-dimensional scalar decomposition.

Related ideas

  • Constant-time execution: the property the recoding protects

Papers

Hybrid Binary-Ternary Joint Sparse Form

A joint recoding of two integers using powers of two and three, proposed for double-scalar multiplication. Performance claims depend on the paper's operation-count model.

Papers

Joint Sparse Form

A joint signed-digit representation used to organize double-scalar multiplication. This source discusses it as an existing method.

Papers

Signed-window scalar recoding

Signed-window recoding allows some scalar digits to be negative. In an elliptic-curve MSM, a negative digit can be handled by adding the negative of the point to the bucket for the digit's magnitude.

Why it is useful

Using positive and negative digits can roughly halve the number of bucket magnitudes compared with an unsigned window of the same width.

How it works

  1. Split the scalar into windows.
  2. Replace large positive digits by negative digits of smaller magnitude.
  3. Carry the difference into the next window.
  4. Use the digit sign to choose the point or its negative.

Example

In base 16, 31 is 1 times 16 plus 15. It can also be written as 2 times 16 minus 1.

What to watch for

The final carry needs room. This signed-window representation is not automatically the same thing as a non-adjacent form, whose nonzero digits have an additional spacing property.

Related ideas

Papers

Window non-adjacent form

Window non-adjacent form represents a scalar with sparse signed digits.

Papers

Entropy devices and physical secret engineering

Physical and quantum RNGs, source health tests, entropy-pool integration, PUFs and noisy-secret enrollment or reconstruction.

Hardware and execution platforms

CPU, accelerator, embedded and isolated execution environments for cryptographic implementations.

Accelerators and constrained-device implementation

Running cryptography on a small processor turns speed and memory into design constraints. Measuring in clock cycles at a clock speed with no memory stalls, and measuring peak stack use by overwriting a known pattern, gives numbers that can be compared across runs and machines.

Counting cycles instead of seconds

Speed is reported in processor clock cycles, counted with the chip’s small SysTick timer plus an interrupt that tallies overflows, and measured at a reduced clock speed where instruction fetches never stall.

Why it is useful

Seconds depend on the clock setting, while a cycle count is a hardware-independent unit; at full speed the processor waits on flash memory, which would tie the results to the memory controller instead of the scheme.

How it works

  1. Average 100 runs per operation, except the slowest SIKE and SPHINCS+ parameter sets, which are measured once.
  2. Count with the 24-bit SysTick timer rather than the 32-bit DWT timer, because SysTick can raise an interrupt on overflow and the handler counts wraps, so a small counter spans arbitrarily long runs.
  3. Run the benchmarks at 24 MHz, where flash fetches need zero wait states, making results independent of caches and memory speed; the chip runs at 168 MHz for everything else.

Example

The slowest SPHINCS+ signing variants need over a hundred billion cycles, far past the roughly 4.3 billion a 32-bit counter can hold.

What to watch for

The 24 MHz clock is a measurement convenience, not a deployment speed, and cycle counts are stable only for schemes without rejection sampling, whose running time varies widely from run to run.

Useful background: One board and four implementation tiers.

Papers

cuZK

A GPU-oriented zkSNARK implementation that combines parallel MSM, matrix-vector multiplication and number-theoretic transforms. The title and abstract support identification; this entry does not certify its implementation.

Papers

CycloneMSM

An FPGA MSM architecture with a pipelined curve adder and a scheduler for curve operations. Reported performance is specific to its curve, hardware and input size.

Papers

Elastic MSM

Elastic MSM is a preprocessing method for multiscalar multiplication on GPUs.

Papers

Fixslicing

Fixslicing rearranges bitsliced state layouts to simplify linear operations in cipher implementations.

Papers

Measuring memory by painting the stack

Memory use is measured by filling the whole stack with a random pattern, running the operation, and reading back which bytes changed.

Why it is useful

On a microcontroller, memory is usually scarcer than time, and for code without heap allocation or static buffers the peak stack use is the entire memory footprint of the scheme.

How it works

  1. Fill the available stack with a random canary pattern, run the operation, then check which parts of memory were overwritten.
  2. Count only the scheme’s own usage: constant tables live in flash and are excluded, and keys or messages are allocated by the caller.
  3. Keep the stack inside the 112 KiB SRAM1 bank, because reaching into SRAM2 causes wait cycles; a custom linker script can raise the budget to 128 KiB when those extra 16 KiB decide whether a scheme fits.

Example

The tuned Kyber512 implementation uses 2 952 bytes of stack for key generation against 6 480 for the clean C version; some FrodoKEM, Round5 and Dilithium parameter sets only fit with the enlarged 128 KiB layout.

What to watch for

The reported stack bytes exclude caller-side keys and messages, so a real deployment needs more memory than the tables show, and code size is reported separately.

Useful background: One board and four implementation tiers.

Papers

One hash implementation for every scheme

Every scheme in the framework calls the same optimized AES, SHA-2, SHA-3, SHAKE and cSHAKE code, and the results report what share of cycles that hashing takes.

Why it is useful

Hashing dominates the running time of many post-quantum schemes, so sharing one implementation stops a scheme from winning benchmarks by shipping faster hash code, and the reported share shows what hardware acceleration or a lighter primitive would buy.

How it works

  1. Wire all schemes, including code imported from pqclean, to the framework’s tuned AES and Keccak implementations.
  2. Measure the cycles spent inside those hash and cipher primitives for each operation.
  3. Read the share as a hint: a scheme spending almost all cycles hashing gains the most from a hash accelerator or a more lightweight alternative.

Example

SPHINCS+ with SHAKE spends 96 to 98 percent of every operation hashing, while NTRU key generation spends none at all.

What to watch for

The share is relative to one particular implementation: speeding up a scheme’s arithmetic raises the hashing share even though the scheme itself did not change.

Useful background: One board and four implementation tiers.

Papers

The Micro ECC library on a constrained board

Micro ECC (micro-ecc) is a small C library that implements elliptic curve operations and that the paper runs on the STM32 board. It is written in C, optionally uses GNU inline assembly for AVR, ARM and Thumb, works on 8-, 32- and 64-bit systems, has a small code footprint and never allocates memory at run time.

Why it is useful

On a board with 128 KB of flash and 64 KB of RAM, a library that avoids heap allocation and fits in a small code footprint is what makes public-key cryptography possible at all. The paper also records that it supports five SEC curves, which is why the curve choice reduced to picking a name.

How it works

  1. Drop the library into the firmware project and build it for the ARM target.
  2. Select one of the supported curves; here Secp256r1.
  3. Call its key-generation, shared-secret, signing and verification routines from the protocol code.

What to watch for

The claim of "robust defense against known side-channel attacks" is the library's own description, not something this paper tested. The board itself has no trusted platform module or secure element, so the paper warns that storing keys and keeping them off the bus takes extra work.

Useful background: Secp256r1, Why elliptic curves suit a small processor.

Related ideas

  • Secp256r1: One of the five curves the library supports and the one used here.

Papers

Why elliptic curves suit a small processor

Elliptic curve cryptography reaches the same security level as RSA or finite-field Diffie-Hellman with far shorter keys, so the arithmetic that has to be done involves smaller numbers and fewer field operations.

Why it is useful

A sensor or smart-home board has a slow clock, little memory and a battery. Public-key operations are the expensive part of securing its traffic, so shrinking the arithmetic shrinks the delay the user notices. The paper cites a measurement on 8-bit processors where RSA exponentiation took about ten times longer than an equally secure elliptic-curve scalar multiplication.

How it works

  1. Compare security level, not key length: an ECC key of a given bit length matches a much longer RSA key.
  2. Count field operations, since each modular multiplication on the device costs the same regardless of scheme.
  3. Prefer the scheme with fewer and smaller operations when the processor is the bottleneck.

What to watch for

The ten-times figure is quoted from an earlier 8-bit study, not measured in this paper. The real ratio depends on the library, the key sizes chosen for the comparison and the processor, so treat it as an order of magnitude rather than a constant.

Useful background: Secp256r1.

Papers

Secure hardware and attestation

TEEs, secure elements, HSMs and TPMs, including roots of trust, remote attestation and rollback-resistant protected state.

Iron FE

Iron realizes functional encryption through Intel SGX execution.

Papers

Leakage and fault countermeasures

Implementation defenses against observed execution behavior or induced faults, with explicit leakage and fault models.

Constant-time and data-oblivious execution

Constant-time code keeps protected values from controlling observable execution behavior. Check branches, memory accesses, operand-dependent instruction latency and compiler-generated helper routines. The protected values and allowed input ranges must be explicit. Rejection-based algorithms need a separate analysis of what their visible retry behavior reveals.

Bernstein-Yang inversion

Bernstein-Yang inversion uses division steps to organize modular-inversion computations.

Papers

Constant-time execution assumptions

Constant-time programming aims to keep execution behavior independent of protected values. Relevant behavior includes branches, memory addresses and instruction latency, not just the number of source-code statements.

Why it is useful

A correct cryptographic algorithm can reveal secrets through how it executes.

How it works

  1. Specify which inputs and intermediate values must remain secret.
  2. Avoid secret-dependent control flow and memory access.
  3. Check the timing properties of the actual machine instructions over the allowed operands.
  4. Inspect what the compiler emits and preserve the numerical and range assumptions that justify it.

What to watch for

This does not establish resistance to every physical side channel. The Falcon paper's hardware path allows a rare static timing leak during tree construction and calls it negligible; its observations do not prove that every static leak is harmless or mathematically negligible.

Related ideas

Papers

Data-oblivious table lookup

A data-oblivious lookup visits the same table locations regardless of which result is selected. A small table can be scanned completely while masks select the answer.

Why it is useful

It avoids revealing a sensitive selection through memory addresses or an early exit.

How it works

  1. Read each table entry in a fixed order.
  2. Evaluate the selection condition without secret-dependent control flow.
  3. Combine the chosen value using masks.
  4. Check that compiler output and machine operations preserve the intended behavior.

What to watch for

Reading the full table has a cost and only addresses this access-pattern issue. It does not prove the table is correct or eliminate all timing and physical leakage.

Related ideas

Papers

Defenses against Flush+Reload

The attack depends on four things together: secret-dependent memory access patterns, shared memory, a high-resolution clock and unrestricted use of clflush. Breaking any one of them breaks the attack, and fixes exist at every level from the instruction to the algorithm.

Why it is useful

Hardware and system changes take years and never protect installed machines, so the immediate shipped defence changed the software: make the victim touch the same lines whatever the secret is.

How it works

  1. Restrict clflush to pages the process may write to, through page-attribute controls; ARM already restricts its eviction instructions to privileged mode.
  2. Reduce sharing, or disable de-duplication, which the paper recommends for public clouds; degrading timer resolution helps less, since attackers can rebuild a clock from the network or a spinning core.
  3. The software fix released in GnuPG 1.4.14 and libgcrypt 1.5.3 is square-and-multiply-always: multiply for every bit and keep the result only when the bit is 1, so the executed sequence no longer depends on the key.
  4. Protect dummy work from the optimiser: if the compiler can prove it has no side effects it deletes it. Constant-time technique, as in the NaCl library, is the general form; the OpenSSL exponentiation of the time already had secret-independent line access without being fully constant time.

What to watch for

The fix still contains a small bit-dependent fragment, judged safe only because speculative execution tends to touch it anyway and it fits inside one cache line. The authors expect it to remain exposed to branch-prediction and Prime+Probe attacks, and constant-time code is too slow to be the answer for non-cryptographic software.

Useful background: How square-and-multiply exponentiation leaks key bits.

Papers

Floating-point emulation and timing leakage in Falcon

Falcon’s signing arithmetic needs 64-bit floating point, which the Cortex-M4 lacks, so it must be emulated with 32-bit arithmetic - and the compiler’s emulation is heavily non constant-time.

Why it is useful

Non constant-time code runs at data-dependent speeds, and for signing that timing can depend on the secret key, so a benchmark must state which variant it is timing.

How it works

  1. Ship the fast compiler-emulated build under an explicit opt-leaktime label so the leakage is visible.
  2. Ship constant-time variants that perform the emulation in plain C (opt-ct) or assembly (m4-ct).
  3. Offer tree variants that precompute part of the key during key generation to speed up signing, at the cost of a much larger private key.

Example

Constant-time falcon512 signing takes about 38.1 million cycles versus 33.7 million for the leaking variant: the timing safety costs roughly 13 percent.

What to watch for

The labels describe how the floating-point emulation is done, not a blanket side-channel guarantee, and the largest tree variant exceeds even the enlarged 128 KiB memory budget.

Useful background: Falcon.

Related ideas

Papers

Reading a constant-time claim from timings

The paper concludes that its implementation "does not vary for different sessions" and calls it a constant-time implementation, because the thousand repetitions of each operation clustered into a two- to three-millisecond window.

Why it is useful

Constant-time code is the standard defence against timing attacks, where an attacker watches how long an operation takes and uses the pattern to guess secret bits. A library whose running time depends on secret data leaks those secrets even though the mathematical result is correct.

How it works

  1. Collect many timings of the same operation with different inputs and keys.
  2. Look at the spread: here key generation landed on 283, 284 and 285 ms and never further out.
  3. Compare the spread against the resolution of the timer before drawing a conclusion.

What to watch for

A tight timing distribution is evidence of stability, not proof of constant time. A data-dependent branch can be invisible at one-millisecond resolution, so a real constant-time claim needs inspection of the code paths or dedicated leakage measurement; the paper relies on the library's own description plus the timing spread.

Useful background: The Micro ECC library on a constrained board, Timing an elliptic-curve protocol on real hardware.

Papers

Secret shift counts and compiler lowering

A wide shift written as one source-language operation can compile into different execution paths depending on the shift count, especially when the machine word is narrower than the value.

Why it is useful

Secret-dependent exponents in floating-point emulation can make an apparently simple shift leak information.

How it works

  1. Identify whether the count is public or secret.
  2. Determine how the compiler implements the wide shift on the target architecture.
  3. Use a justified decomposition into fixed-width operations and masked selection where needed.
  4. Verify the emitted instructions and their timing assumptions.

What to watch for

A conditional branch is not necessarily a leak if its outcome is fixed or public, and branchless source is not necessarily safe. The paper's workaround is analyzed for counts in its stated range, not arbitrary integers.

Useful background: Constant-time execution assumptions.

Papers

Fault detection and fault-tolerant cryptography

Redundancy, verification, infective computation and combined countermeasures intended to contain induced computational faults.

Masking, hiding and leakage-resilient gadgets

Randomized sharing, blinding, hiding and composable masked gadgets for implementation leakage. Proof-system polynomial masking is a different use of the word.

Boolean masking

Masking splits every secret-dependent value inside a computation into several shares whose combination recovers the value, and processes the shares instead of the value itself.

Why it is useful

Each share on its own is statistically independent of the secret, so leakage from any single share tells the attacker nothing about the key.

How it works

  1. Pick random masks and keep them as the shares numbered 1 to d.
  2. Compute the share numbered 0 so that the exclusive-or of all d+1 shares equals the secret value.
  3. Carry out the algorithm on the shares, never recombining them inside the protected region.
  4. Use a masking scheme for the operations that are not simple additions, so the shares stay valid and independent.

What to watch for

Linear operations extend to shares immediately; non-linear ones, such as the s-box of a block cipher, need dedicated secure algorithms.

Useful background: Higher-order side-channel attacks.

Related ideas

Papers

d-th order probing security

A masked implementation has dth-order security when any set of d or fewer internal values, taken together, is statistically independent of the secret; the number d is the masking order and works like a security parameter.

Why it is useful

It turns a physical question into a checkable statement: if every d-tuple of internals is independent of the secret, then no attacker who can observe up to d points learns anything, and the higher the order, the more measurements an attack needs.

How it works

  1. Fix the order d and split every sensitive value into d+1 shares.
  2. List every internal value the algorithm ever computes on the shares.
  3. Check that the joint distribution of any d of those values does not depend on the secret.
  4. Prove it by simulation: show any d values can be generated from fewer than d shares, which carry no information about the secret.
  5. Remember that real leakage is a noisy function of the values, not the values themselves.

What to watch for

Probing security assumes exact observations; real traces are noisy, which helps the defender, but the order d is only a soundness criterion, not a guarantee that no attack exists.

Useful background: Boolean masking.

Related ideas

  • Leakage-resilient cryptography: formal models that assume the attacker observes bounded or noisy leakage

Papers

ISW secure multiplication

The Ishai-Sahai-Wagner construction multiplies two shared values without ever bringing two shares of the same secret together, by mixing fresh randomness into every cross-term.

Why it is useful

Multiplication is the only hard step when masking a cipher: linear operations act on each share separately, while a naive product would make one internal value depend on two shares at once.

How it works

  1. For every pair of share indices i below j, draw a fresh random value.
  2. Fold that randomness into each cross-term so the term leaks on one share of each operand only.
  3. Add the masked cross-terms into the output shares so the exclusive-or of the outputs still equals the product.
  4. Evaluate the terms in the bracketed order written in the algorithm, since the order is part of the security argument.

What to watch for

The original proof gives security at order d/2 from d+1 shares, so reaching order d needs about twice as many shares and roughly four times the runtime, because the cost grows with the square of the number of shares.

Useful background: Boolean masking, d-th order probing security.

Related ideas

Papers

Mask refreshing

Mask refreshing replaces an existing sharing of a value by a new sharing of the same value using fresh randomness, leaving the value itself unchanged.

Why it is useful

During an s-box evaluation the two operands of a multiplication often come from the same original sharing, so their masks are correlated; the secure multiplication is only proved when the two input sharings are mutually independent, and refreshing restores that independence.

How it works

  1. Start from the shares of the value z.
  2. For each share index i from 1 to d, draw a fresh random value.
  3. Add the random value into share 0 and into share i, so the exclusive-or of all shares is unchanged.
  4. Feed the refreshed shares into the secure multiplication as the second operand.

What to watch for

The procedure only rerandomizes; it is not itself a security proof, and its cost in fresh randomness and time grows with the order, which matters on small devices.

Useful background: Boolean masking, ISW secure multiplication.

Related ideas

Papers

Multiplying a value by a linear function of itself

A secure way to compute a times g(a) from the shares of a alone, when g is linear, so no mask refresh is needed before the multiplication.

Why it is useful

It removes the flawed composition by never creating the half-refreshed sharing that the attack targets, and it keeps the full dth-order security claim.

How it works

  1. Note that the second operand shares satisfy b_i equals g(a_i) for every share index, because g is linear.
  2. Write each cross-term as a bilinear function f of two shares plus fresh randomness.
  3. Split the evaluation of f on two shares with an extra fresh random value, so no internal value ever depends on two shares of a at once.
  4. Prove security by simulation: any d internal values can be generated from a strict subset of the shares, which has fewer than d elements and is independent of the secret.

What to watch for

The proof is in the perfect-probing model, and the construction needs roughly twice as much fresh randomness as the original refresh-then-multiply approach.

Useful background: ISW secure multiplication, d-th order probing security, Mask refreshing leaks when composed with multiplication.

Related ideas

Papers

Table look-ups instead of field multiplications

Replace the field multiplications inside the secure cross-terms by table look-ups of the single-variable function h mapping x to x times g(x).

Why it is useful

Direct field products are slow for the field sizes used by real s-boxes, and a table of all products becomes too large beyond small fields, so the bilinear structure is used to shrink the table to one entry per field element.

How it works

  1. Store a look-up table for h, with one entry per field element.
  2. Use the identity that f of x and y equals h of the exclusive-or, plus h of x, plus h of y, to rewrite each cross-term as a sum of four table look-ups on masked arguments.
  3. Feed the masked arguments into the look-ups in the bracketed order fixed by the algorithm.
  4. Reuse the same security proof, since the internal values fall into the same categories as before.

What to watch for

The gain in speed is paid for in read-only memory for the tables, and the reported timings come from one small 8-bit processor and orders one to three, not from a range of modern platforms.

Useful background: Multiplying a value by a linear function of itself.

Related ideas

Papers

Verified implementation and empirical validation

Verified code generation, compiler preservation, memory-safety reasoning, test vectors, fuzzing and reproducible performance or leakage validation.

Device Security

Assumption that QKD devices are reasonably secure against side-channel attacks and implementation flaws; an engineering challenge for QKD deployments.

Papers

Rounding errors and the proven-correct routine

The decomposition divides by N using precomputed constants and a power-of-two shift, which can be off by one; FourQ accounts for that error explicitly and proves the whole routine correct with a fixed operation sequence.

Why it is useful

Earlier implementations made the error probability tiny by choosing a large shift and hoping. A residual error would produce a different control flow for some rare scalar, which breaks a constant-time promise in a way that is hard to test for.

How it works

  1. Allow each rounded coefficient to be one too small, and size the parallelepiped so that all sixteen error combinations still fit inside the 2^64 cube.
  2. Translate with lattice vectors so all four multipliers come out positive and the first is odd, avoiding extra conditional additions.
  3. Theorem 1 then counts every field operation: exactly one inversion, 842 multiplications, 283 squarings and 950.5 additions for any input.

What to watch for

The guarantee costs speed: the safety margin doubles the parallelepiped, and the authors state plainly that they trade performance for simplicity and provable correctness in several places.

Useful background: Four-dimensional scalar decomposition, Constant-time recoding and the main loop.

Papers

Testing the code before timing it

Before benchmarking, the framework checks that each implementation computes what it claims and stays inside the sizes it declares, using functional checks, guard values and reproducible test vectors.

Why it is useful

Timings taken from code that fails silently, writes past its buffers, or behaves differently on a 32-bit chip than on a desktop would poison every table built on top of them.

How it works

  1. For key encapsulation, check that both sides derive the same shared secret, and that substituting random bytes for the initiator private key or the ciphertext breaks the agreement.
  2. For signatures, check that a signature verifies under the right public key and fails under a random one.
  3. Place 8-byte canary values before and after each output buffer; a changed canary means the code wrote outside its declared size.
  4. Replace the randomness source with a deterministic stand-in so implementations become fully reproducible, then compare test vectors across implementations and between the 32-bit board and a 64-bit host.

Example

Producing the same test vector on the board and on a desktop catches code that silently assumes a particular machine word size.

What to watch for

The canary check only catches writes immediately next to a buffer, so an out-of-bounds write landing further away goes unnoticed, and determinism covers only the randomness input, not other hidden state.

Useful background: Key encapsulation mechanism, One board and four implementation tiers.

Papers

Timing an elliptic-curve protocol on real hardware

To measure how long a cryptographic operation takes, the paper runs it one thousand times, reads a hardware time counter embedded in the code, and reports the minimum, maximum, average and median of the thousand values. It also tabulates how many of the runs landed on each whole-millisecond value.

Why it is useful

A single measurement is dominated by noise from the processor, the flash wait states and anything else the chip happens to be doing. Repeating the operation many times and looking at the spread separates the real cost from the jitter, and the distribution shows whether the cost is stable or has rare slow outliers.

How it works

  1. Configure an on-chip timer for the clock frequency used, here 48 MHz.
  2. Run the operation in a loop one thousand times, reading the counter around each call.
  3. Report the minimum, maximum, average and median, and the histogram of observed values.

What to watch for

A software timer around a function call measures wall-clock time, so anything the scheduler does in between is included. At one-millisecond resolution, differences smaller than a millisecond cannot be seen at all, and the method says nothing about why an outlier occurred.

Useful background: The Micro ECC library on a constrained board.

Papers

Valid signatures versus secure sampling

A signature can pass verification even when the signing algorithm uses the wrong distribution and exposes information about its key. Verification tests the output relation, not the signer's internal randomness.

Why it is useful

It explains why cryptographic testing must cover the generation process as well as whether outputs are accepted.

How it works

  1. Test exact sampler boundaries against an independently obtained reference.
  2. Use deterministic vectors when the random-input interface is fully specified.
  3. Apply statistical tests across relevant parameter ranges.
  4. Treat those tests as evidence, not a proof that every harmful deviation is absent.

What to watch for

The revised Falcon paper documents two sampler errors that produced accepted signatures. Its added chi-square tests can catch some errors, but the paper explicitly warns that small exploitable deviations may escape them.

Useful background: Discrete Gaussian sampling.

Related ideas

Papers

Cache and microarchitectural attacks

Attacks that read secrets from what a processor's memory system reveals: cache timing, Flush+Reload and related techniques, higher-order differential power analysis, and the countermeasures that mask or refresh secrets.

A lattice attack for Koblitz ECDSA

Knowing the top or bottom coefficients of the tau-adic expansion of each nonce still leaks the key. Each nonce splits as k_i = u_i + v_i*tau with ordinary integers u_i and v_i of size about 2^(l/2), where l is the length of the unknown part, and the verification equation becomes x = A_i*u_i + tau*A_i*v_i + B_i mod q with known constants A_i and B_i.

Why it is useful

It was believed that side-channel leakage does not help against Koblitz curves, because the tau-adic digits do not determine the binary bits of the nonce. The paper shows the hidden number idea works directly in the ring Z[tau], turning each signature into a two-dimensional unknown instead of a one-dimensional one.

How it works

  1. Bound the unknowns: the pair (u_i, v_i) lies in a disc of radius about sqrt(c*2^l), so u_i^2 + v_i^2 <= c*2^l for some constant c; simulation gives c close to 0.30 for random bit expansions and TNAFs, while the worst-case bound of 3.85 is pessimistic.
  2. Stack all signatures into one short vector u = (u_1, ..., u_t, v_1, ..., v_t, w) that is orthogonal modulo q to the differences of the known vectors A_i, with a balancing weight w on the last coordinate; this is a higher-dimensional relative of the hidden number problem.
  3. Reduce the orthogonal lattice with BKZ-25: on NIST K-163 the attack needed between 21 and 39 signatures for 9 down to 6 bits of bias, in lattices of dimension 63 to 117, taking from seconds to about 100 seconds on one core.

What to watch for

The success condition is heuristic, based on comparing the norm of u with the Gaussian heuristic for the lattice volume, and the constant c comes from simulation rather than proof; the paper states only that the rigorous Nguyen-Shparlinski approach should extend in principle. Fewer than about 1.4 bits of bias per signature is out of reach for the TNAF case.

Useful background: Tau-adic expansions and the TNAF recoding, Leaking a few nonce bits breaks ECDSA.

Related ideas

Papers

Cache lines, sets and the last-level cache

A cache is a small, fast store of recently used data. Each processor core has private L1 and L2 caches, and all cores on the chip share the last-level cache (the L3 on this processor). Data moves in fixed-size lines that sit in cache sets; how many lines a set holds is the associativity.

Why it is useful

The last-level cache is the meeting point: it is shared by all cores, and on Intel processors of this generation it is inclusive, meaning it holds a copy of everything in the private caches. Evicting a line there evicts it everywhere.

How it works

  1. On the test processor each of the four cores has private L1 and L2 caches and all four share one 6MB L3.
  2. Each memory line can only be cached in the one set its address selects, which holds a fixed number of lines.
  3. Because the L3 is inclusive, flushing a line from it removes the line from every cache level, so the next use by any core reloads it into the shared level.

What to watch for

Sizes and associativity are properties of one 2013 processor. On AMD processors with non-inclusive caches the eviction step of the attack stops working, as the paper reports.

Papers

Countermeasures against the operation-sequence leak

The paper lists fixes that break the link between secret data and the sequence of curve operations: routines that always perform the same operations, atomic rewriting of the formulas, zero-free tau-adic expansions, randomization of the scalar, and the fixed-base comb method that later shipped in Bouncy Castle 1.51.

Why it is useful

A simple electromagnetic analysis reads the operation sequence, so any change that makes the sequence independent of the secret, or randomizes which secret-equivalent sequence is executed, removes the leak that both attacks rely on.

How it works

  1. Double-and-add-always performs an addition whatever the bit value, so the trace is a regular succession of identical patterns.
  2. Atomicity patterns rewrite the different curve operations with the same pattern of suboperations; more efficient variants followed the original 2004 proposal.
  3. On Koblitz curves, zero-free tau-adic expansions avoid runs of Frobenius steps that would otherwise reveal long stretches of zero digits, and Hasan's countermeasures are cited as well.
  4. Coron's randomization adds a random scalar of about 32 bits to the nonce in a way that leaves the resulting point unchanged, so the observed sequence no longer reveals a part of the nonce.
  5. The fixed-base comb method adopted in Bouncy Castle 1.51 avoids exposing consecutive bits at either end of the scalar and defeats these attacks.

What to watch for

The regular and atomic countermeasures apply to prime-field curves. Used on Koblitz curves they throw away the benefit of the Frobenius maps, and the paper says one would then do better with a general binary curve combined with a Montgomery ladder.

Useful background: Telling doublings from additions in a leakage trace, A lattice attack for Koblitz ECDSA.

Papers

Flush+Reload beyond GnuPG

RSA in GnuPG was the demonstration, not the limit: the technique monitors any software whose code pages the spy shares, including programs that hold no cryptographic keys.

Why it is useful

Because it records execution line by line over time, it supports profiling and surveillance attacks, not only key recovery - for example timing keystrokes through keyboard driver code or collecting traffic statistics through network handling code. It works through read-only sharing, which systems treat as harmless.

How it works

  1. Choose shared code lines whose execution answers the question at hand.
  2. Run the flush, wait and reload loop and record when each line is touched.
  3. Interpret the timeline against the program control flow.

What to watch for

The suggested non-cryptographic uses are sketched, not evaluated in the paper. The recommendation to switch de-duplication off in virtualised environments is a policy judgement about the memory-for-isolation trade-off, argued from attack strength rather than measured costs.

Useful background: The Flush+Reload monitoring round.

Papers

Higher-order side-channel attacks

Side-channel attacks read a secret from physical measurements of a running cipher, such as power use or timing. A higher-order attack goes further and combines measurements taken at several moments, one for each of several internal values.

Why it is useful

A single masked value looks random on its own, so first-order attacks fail; combining leakages from several related values is the standard way around masking, and a countermeasure is only useful if it survives that combination.

How it works

  1. Measure the leakage each time a different internal value of the computation is handled.
  2. Combine those measurements into one statistic instead of testing them one by one.
  3. Match the combined statistic against predictions computed for each guess of the secret key.
  4. Keep the guess whose predictions track the combined leakage best.

Example

With three shares, a second-order attack multiplies the centered leakage of two shares and correlates that product with key hypotheses.

What to watch for

The paper measures attacks on simulated traces with a fixed noise model, so success rates reported here are simulation results, not measurements of a particular physical device.

Useful background: Differential power analysis.

Related ideas

Papers

How square-and-multiply exponentiation leaks key bits

The tested GnuPG version computed RSA with square-and-multiply: scan the exponent bit by bit, always square and reduce, and additionally multiply and reduce when the bit is 1. A spy that records which routines ran therefore reads the exponent bits straight off the operation sequence.

Why it is useful

The secret shows up in which code executes, not in any data value. Probing one frequently executed line in each of the square, multiply and reduce routines is enough to transcribe that sequence.

How it works

  1. Divide time into slots of 2,500 cycles; in each slot probe one line from each of the three routines, then flush and wait.
  2. Square-Reduce-Multiply-Reduce in the trace means a 1 bit; Square-Reduce followed by another Square means a 0 bit.
  3. With the Chinese remainder optimisation only the per-prime exponents appear, but recovering either one is enough to factor the modulus.
  4. Debugging symbols map source lines to addresses; a stripped executable needs reverse engineering first.

Example

Trace shows Square-Reduce-Multiply-Reduce: the exponent bit is 1. Trace shows Square-Reduce and then Square again: the bit is 0.

What to watch for

Speculative execution pulls square-loop lines into the cache even for 0 bits, so the authors probe near the ends of routines, which removed the effect on one machine but not the other. The findings describe one default optimised build of that era.

Useful background: The Flush+Reload monitoring round.

Papers

Leaking a few nonce bits breaks ECDSA

ECDSA signs a message m with a pair (r, s): r is the x-coordinate of the point k*P for a fresh random nonce k, and s = (r*x + h)/k mod q, where h is the hash of the message, x is the secret key and q is a large prime. If an attacker learns a few bits of k for sufficiently many signatures, lattice reduction recovers x.

Why it is useful

The nonce is the only secret input to the signature equation, so partial knowledge about many nonces turns into many equations that together pin the key down. This is why a side channel that looks harmless, revealing two or three bits per signature, is fatal.

How it works

  1. From each signature compute the known constants: the paper's appendix D turns l known least significant bits into an inequality |x*t_i - v_i/2^(l+1)|_q <= q/2^(l+1), where |.|_q is distance to the nearest multiple of q.
  2. Those inequalities are an instance of the hidden number problem of Boneh and Venkatesan; the standard treatment, due to Howgrave-Graham and Smart and refined by Nguyen and Shparlinski, rewrites it as a closest vector problem in a lattice built from the signatures.
  3. Reduce that lattice: the paper embeds the closest vector problem into a shortest vector problem and solves it with BKZ in Sage. For the NIST P-256 curve, about 500 measured signatures, of which 115 carried at least 2 known bits, yielded the secret key in under five minutes on a desktop computer.

What to watch for

The number of signatures needed grows quickly as the number of known bits shrinks; the paper notes that with only 2 known bits on a 160-bit modulus, Liu and Nguyen had to use BKZ 2.0 because the lattice dimension becomes large.

Useful background: Short Weierstrass curves over prime fields.

Related ideas

Papers

Mask refreshing leaks when composed with multiplication

Two gadgets that are each secure at order d can be insecure when run one after the other: the mask-refreshing step followed by the secure multiplication can be attacked with about half the intended number of observations.

Why it is useful

It shows that local security of each sub-routine does not add up to security of the whole computation, which is exactly how the published schemes argued their security.

How it works

  1. Take the intermediate value produced by the refresh loop halfway through, after the d/2-th iteration; it still mixes the sensitive value with d/2 mask sums.
  2. Take the d/2 multiplication cross-terms that pair those same mask sums with the matching shares.
  3. Each cross-term depends on one of the mask sums that protects the half-refreshed value.
  4. Combining them therefore peels away the masks and leaves dependence on the sensitive input, using d/2+1 observations instead of d+1.

What to watch for

For an odd order one extra observation is needed, so the attack order is the ceiling of d/2 plus one; the affected schemes claimed dth-order security.

Useful background: Mask refreshing, ISW secure multiplication, d-th order probing security.

Related ideas

Papers

Measuring how much the composition flaw leaks

The authors quantify the flaw with an information-theoretic measure between the sensitive variable and the simulated leakages, then try standard higher-order attacks on the same simulations.

Why it is useful

A theoretical dependence on the secret is not automatically a practical key recovery, so the severity of a flaw has to be measured before deciding how urgent the fix is.

How it works

  1. Model each observation as the Hamming weight of the internal value plus independent Gaussian noise.
  2. Compute the mutual information between the sensitive variable and the leakage vector for the flaw, and compare it with classical first-order and second-order masking.
  3. Run standard distinguishers, here second-order correlation and mutual information analysis, on simulated traces.
  4. Compare success rates against the number of measurements.

What to watch for

On these simulations the flaw leaks little in absolute terms and no tested attack exceeded a 20 percent success rate with up to a million traces and no noise, but the authors state that stronger multivariate or profiled attacks might still exploit it, and with growing noise the flawed scheme degrades towards first-order security.

Useful background: Mask refreshing leaks when composed with multiplication, Differential power analysis.

Related ideas

Papers

Measuring one memory access with the time stamp counter

The reload is timed by reading the processor time stamp counter before and after the load, with fence instructions around the measurement, and each load is classified as cached or uncached by comparing it with a threshold measured on the target machine.

Why it is useful

Processors execute instructions out of order, so without serialisation neighbouring work can slide inside the measured window and corrupt it. The usual serialising instruction, cpuid, is emulated by hypervisors and takes over 1,000 cycles, which destroys the resolution a cross-VM attack needs.

How it works

  1. Place lfence instructions for partial ordering and mfence to order memory operations, including clflush itself.
  2. Read the counter, load the address, read the counter again, subtract; short intervals make the low 32 bits enough.
  3. Calibrate on the target: the authors measured cached loads at about 44 cycles and memory loads at 270 to 290 cycles, and set the threshold at 120 cycles.

What to watch for

Every number is machine- and software-specific: another test machine gave 33 to 43 cycles for cached loads and about 230 for memory, and a virtual machine guest showed rare loads over 6,000 cycles caused by hypervisor activity. A threshold must be re-measured, never copied.

Useful background: The Flush+Reload monitoring round.

Papers

Recovering the RSA key from a noisy trace

A capture is not a clean copy of the exponent: the spy misses time slots when the system runs something else, and noise misclassifies operations. The paper captured 1,000 signatures per configuration and analysed how the remaining errors affect key recovery.

Why it is useful

Reconstruction algorithms for RSA need a fraction of the exponent bits with correct positions, and missed slots destroy position information exactly there. Choosing what to do with the errors is part of the attack, not an afterthought.

How it works

  1. Detect missed slots from jumps in the cycle counter.
  2. Attack the better-captured Chinese remainder component: either one suffices to break the key.
  3. Published algorithms need between 27% and 70% of the bits; the attack recovers over 90% but not always with reliable positions.
  4. Merge captures of two signatures: error positions are independent, so comparing them locates the errors - merged results were left with at most a handful of wrong bits.

What to watch for

Error counts ranged from an average of 0.2 wrong bits in the quietest configuration to 66 in the noisiest, on idle lab machines. The headline rate of 96.7% of bits from one round is the authors’ cross-VM measurement, and they state that adapting the reconstruction algorithms to this error structure still required research.

Useful background: How square-and-multiply exponentiation leaks key bits.

Papers

Sharing memory pages between processes

Operating systems and hypervisors let several processes use one physical copy of identical memory pages: the code of a shared library, or pages that memory de-duplication found to hold the same bytes. A rule called copy-on-write keeps such pages read-only; the first write triggers a trap and the writer gets a private copy.

Why it is useful

Sharing saves memory, but it hands every sharing process the same memory lines. A cache attack needs exactly that: addresses whose cache state both the victim and the spy can influence.

How it works

  1. Map the same file pages into each process, as with shared libraries and program text.
  2. Or let a de-duplication mechanism scan memory and coalesce unrelated pages with identical contents, as hypervisors and some operating systems do.
  3. Copy-on-write preserves isolation of contents: reads are shared, writes copy first.

What to watch for

Copy-on-write protects what a shared page contains, not when it is read. Removing sharing restores isolation but costs memory, which is why systems kept sharing despite the risk.

Related ideas

Papers

Telling doublings from additions in a leakage trace

On a phone processor running at gigahertz speed, a small loop probe placed near the chip, combined with band-pass filtering, shows the scalar multiplication as a train of low-power peaks, and the doubling and addition routines of the library produce recognizably different peak patterns.

Why it is useful

The order of doublings and additions is dictated by the secret nonce, so an attacker who can label each pattern learns the digit structure of the nonce, which is the raw material for the lattice attack.

How it works

  1. Leakage can be physical (power consumption, electromagnetic emanations, execution timing) or microarchitectural (cache state, branch prediction); this paper measures the electromagnetic channel.
  2. Synchronize the capture by sending a fixed pattern on the USB channel and forcing a CPU sleep just before the computation, then band-pass filter the trace; a 50 kHz cutoff gave the best signal-to-noise ratio on the tested phone.
  3. Label the patterns using a white-box run with a known scalar: each routine is characterized by the number of peaks and the timing intervals between them, because the number of field multiplications between other operations differs between doubling and addition.
  4. With the window NAF method the attacker cannot tell which precomputed point was added, but the number of zeros between successive additions is readable, and the doublings that follow the last addition reveal the zeros in the least significant bit positions, since the last digit of a window is always odd.

What to watch for

The useful leakage sits below 50 kHz on the tested 1.2 GHz chip, because each leaking operation spans many clock ticks, so a cheap analog-to-digital converter at a few hundred kilohertz is enough; the paper's mechanistic explanation, that multiplications execute in ARM mode while other instructions use Thumb-2, is offered as a plausible hypothesis rather than a proven cause.

Useful background: Short Weierstrass curves over prime fields, Leaking a few nonce bits breaks ECDSA.

Papers

Watching the Frobenius on Koblitz curves

On the Koblitz implementation the same analysis labels Frobenius operations and point additions rather than doublings and additions. The Frobenius step is visible in the trace even though Bouncy Castle computes it from precomputed tables rather than by field arithmetic.

Why it is useful

The Frobenius plays the role that doublings play on prime-field curves, so counting the Frobenius steps between two additions reads the tau-adic digits of the nonce and feeds the Koblitz lattice attack.

How it works

  1. Display the trace with a short-time Fourier transform using a Hamming window: successions of Frobenius operations separated by a single point addition are visible, with five Frobenius operations then four in the traces shown.
  2. Bouncy Castle 1.50 implements the Frobenius with precomputed tables and affine coordinates, so the leakage differs from the prime-field arithmetic, and each Frobenius shows a twofold repeated pattern, one part per coordinate.
  3. The paper argues the attack is not tied to this representation: other coordinate systems such as Jacobian or lambda coordinates also leak if the most significant digits of the nonce leak, because their internal operations differ in timing and cost.

What to watch for

Fewer distinguishable operations are available than on prime-field curves, which the paper describes as a signal processing challenge, since the number of available points in the trace is reduced. The measurements come from particular Qualcomm chips, so counts of visible operations are device specific.

Useful background: Tau-adic expansions and the TNAF recoding, Telling doublings from additions in a leakage trace.

Papers

When Flush+Reload works and when it fails

The attack needs shared cache and shared pages: the attacker must run code on the victim machine, though without elevated privileges, or own a virtual machine co-located on the same host. Sharing arises naturally - by mapping the victim executable, or through hypervisor page de-duplication across guests.

Why it is useful

Knowing the preconditions tells a defender what to check: co-location, readable executables, de-duplication settings. It also explains which defences are useless.

How it works

  1. Between processes in one system, the spy maps the victim executable file into its own address space, so both share the code pages.
  2. Between virtual machines, the spy maps a copy and de-duplication merges it with the victim pages.
  3. The last-level cache is tagged by physical address, so probes match regardless of virtual addresses; address randomisation gives no protection.
  4. It fails when spy and victim are on different physical processors, on contemporary AMD processors whose caches are non-inclusive, when several victim instances blur together, and for short keys whose steps no longer fit in the probe slot.

What to watch for

Tests pinned processor affinity on otherwise idle machines; a real scheduler and background load add noise. The ARM architecture confines cache-eviction instructions to privileged modes, so this attack shape does not carry over to it.

Useful background: The Flush+Reload monitoring round.

Papers

Understanding attacks and security arguments

Cryptanalysis studies how a construction can fail. Security analysis also asks whether a proof, a mathematical assumption or an implementation matches the guarantees people rely on.

Conditional cube attack

Conditional cube attacks impose input or key conditions to control degree growth in cube sums.

Papers

Degree annihilation attacks

Degree-annihilation attacks construct polynomial combinations that cancel selected high-degree terms.

Papers

Differential power analysis

Differential power analysis partitions or models power traces using secret-dependent intermediate predictions.

Papers

F5 algorithm

F5 computes Groebner bases using signatures to discard redundant reductions.

Papers

Graeffe-transform hash cryptanalysis

Graeffe-transform cryptanalysis reorganizes polynomial relations in attacks on field-based hash functions.

Papers

Pohlig-Hellman

Pohlig-Hellman reduces a discrete logarithm to problems associated with prime-power factors of the group order.

Papers

Pollard kangaroo

Pollard kangaroo searches for a discrete logarithm known to lie in an interval.

Papers

Rebound attack

Rebound attacks solve constraints in an internal segment before extending differentials outward.

Papers

Rectangle attack

Rectangle attacks use sets of differential quartets as a statistical distinguisher.

Papers

Rotational cryptanalysis

Rotational cryptanalysis follows relations between words and their rotations through cipher operations.

Papers

Automated reasoning and cryptanalysis tools

Automated cryptanalysis tools restate an attack as a search a machine can grind through: the cipher is translated into Boolean clauses, the observed values are fixed, and a SAT solver returns any assignment that fits. This turns questions about keys, states and messages into reproducible experiments with a tunable time budget, at the cost of depending heavily on the encoding and on the solver.

SAT-based cryptanalysis

SAT-based cryptanalysis turns breaking a cipher into a logic puzzle. You write the cipher as a Boolean formula whose variables are the unknown bits (key, state or message), add everything already observed, and give the formula to a SAT solver, a program that searches for true/false values satisfying every clause.

Why it is useful

SAT is worst-case exponential, yet solvers handle the huge but structured formulas that come from real ciphers, so translating a hard question into SAT can be cheaper than inventing a bespoke attack. Here the encoding is automatic, so no hand analysis of the cipher's algebra is needed.

How it works

  1. Encode the cipher once: the Cryptosat tool lets you write the algorithm in C++, and operator overloading records every AND, OR and XOR as clauses; a clause is a list of literals (a variable or its negation) and the whole formula is a conjunction, a logical AND of clauses, called conjunctive normal form (CNF).
  2. One XOR of two bits costs two clauses: (x1 or x2) together with (not x1 or not x2) forces exactly the patterns where the two bits differ.
  3. Substitute the knowns: fix the observed nonce, plaintext, associated data or tag values, leaving a smaller formula over only the unknowns.
  4. Run the solver, here Cryptominisat 2.9.5, under a time budget: it answers SAT together with a full assignment (a candidate key, state or message), UNSAT if it proved that no assignment exists, or TIMEOUT if the budget ran out.

Example

Encode AEAD(K, N, P, A) once, fix N, P and A to the observed values, and ask for any key K that reproduces the known tag.

What to watch for

Worst-case behaviour is exponential, and outcomes depend on the encoding, the solver version and the timeout; a TIMEOUT proves nothing, and results on one cipher do not transfer automatically to another.

Useful background: ACORN.

Related ideas

Papers

Computational security proof development and checking

Developing and checking concrete computational-security arguments: matching experiments to interfaces, auditing hybrids and simulations, checking theorem hypotheses, and accounting for reduction loss. General reduction techniques, composition theorems, separations and impossibility results have their primary home under foundations.reductions-composition. Automated proof tools remain under analysis.automated.

Concrete security, parameter selection and research validation

Concrete-security reading weighs what an attacker is given, what the attack returns and at what cost, and whether the designers' claims are contradicted. Probabilities estimated over thousands of random instances, the hardware used, and the settings the designers disclaimed all decide whether a reported attack eats real margin.

Distinguishing weak hash keys from cipher keys

It may be easy to write down a hash-key value with an undesirable algebraic property while being very hard to find a block-cipher key that produces it. In GCM, the hash key is derived by encrypting the all-zero block under the AES key.

Why it is useful

A cryptanalytic example must explain how the required internal value arises. Choosing that value directly can give the attacker more control than the real system allows.

How it works

  1. State the internal hash-key condition needed for the attack.
  2. Identify how the real construction derives that internal value.
  3. Separate a chosen internal value from a random-key event and from an actual cipher-key search.
  4. Check whether the resulting cycle length fits a usable message.

What to watch for

The paper's smallest reported AES-derived cycles are still enormously long. Finding such a key is not the same as demonstrating an exploitable short cycle in a normal protocol message.

Related ideas

Papers

Reading cryptanalytic attack margins

Attack numbers only mean something when compared with the cost of brute force and with the number of rounds the design actually has. For Skein-512 and SHA-512 the ideal preimage cost is 2^512, and the paper's best results are 2^511.2 on 37-round Skein-512 and 2^511.5 on 50-round SHA-512.

Why it is useful

A saving of a factor of two or eight says something about how much safety margin a design retains, even though no real attacker can run the search. Comparing rounds covered and settings attacked is how cryptanalysts rank designs against each other.

How it works

  1. Compare the attack complexity against 2^n for an n-bit hash rather than against zero.
  2. Compare the rounds attacked against the function's full round count: 72 for Threefish-512, 64 for SHA-256, 80 for SHA-512.
  3. Keep the hash-function setting and the compression-function setting apart; the latter gives the attacker control of more input.
  4. Distinguish a pseudo-preimage, which is a chaining value plus one block that reaches the target, from a full preimage; pseudo-preimages are converted to preimages by restarting the search, which is where formulas such as 2^(1+(253+256)/2) come from.
  5. Check what the authors themselves claim: the 2^511.76 saving on the full 72-round Skein-512 is explicitly not called an attack.

What to watch for

Round counts are not the whole story: reaching 52 of SHA-256's 64 rounds still costs about 2^255 in the compression-function setting, which is essentially the full ideal cost for a 256-bit hash. Conversely a small complexity gain over a complete function, as reported for full Skein-512, is a warning about margin rather than a break.

Useful background: Biclique attacks on the SHA-2 family, Preimage attacks on reduced Skein-512.

Related ideas

  • SHA-2: The standard whose round-by-round margins are being measured.
  • Skein: The finalist the paper judges more resistant to this line of attack.

Papers

Reading the security estimates

The paper converts each attack into a count of field multiplications using XL and Wiedemann cost formulas, then into gate counts with the model standard in the MQ literature, where one field multiplication costs 2(log2 q)^2 + 2 log2 q gates. Comparing the cheapest attack with the NIST security target for each submitted parameter set, the new attacks cut the cost of a key recovery by factors of about 2^17, 2^53 and 2^73 for the three round-two parameter sets and about 2^20, 2^40 and 2^55 for the finalists, so all of them fall short of the NIST requirements. The attacks remain exponential, so the fix is larger parameters: for example q = 16, n = 109, m = 68, o2 = 36 would presumably reach security level I with a ten percent larger signature and a twenty-five percent larger key, or one could switch to plain UOV with q = 64, n = 118, m = 47.

Why it is useful

This is how concrete post-quantum security claims are actually justified: not by a proof, but by a table of the cheapest known attack under a stated cost model, revisited whenever a new attack appears. When the table moves, every parameter set priced against the old table has to be repriced, which is what happened to Rainbow here.

How it works

  1. Count the field multiplications the attack needs, from the size of the Macaulay matrix and the degree at which the XL system becomes solvable.
  2. Convert multiplications to gate operations with the stated cost per multiplication.
  3. Take the cheapest attack across all known attacks and compare its gate count with the target security level in bits.
  4. If the cheapest attack is below target, increase parameters until the cheapest attack is above target again, and record the new sizes.

Example

A claimed 128-bit parameter set becomes a 95-bit one if a new attack costs 2^95 instead of 2^130; the response is not a new scheme but a larger n and m until the cheapest attack again exceeds 2^128 under the same cost model.

What to watch for

The numbers are estimates built on genericity heuristics, on experiments with small instances, and on one particular gate model; they are not measurements of a full attack at full scale. The extracted source text flattens superscripts, so 217 in the quotes means a factor of 2^17. The suggested replacement parameters carry the paper’s own hedge (presumably reach), and the paper also questions whether the small performance advantage of Rainbow over UOV is worth its extra complexity.

Useful background: The intersection attack on UOV, The rectangular MinRank attack.

Related ideas

Papers

Reading the security margin of an authenticated cipher

A margin reading asks three questions of a cryptanalysis result: what the attacker is given, what the attack returns, and whether the designers' claims are actually contradicted. For this paper the answers are a tag (sometimes plus leaked state bits or the key), states and messages matching that tag, and no: each attack either assumes knowledge that Acorn's claims do not cover, or lands on a state that is not the user's real one.

Why it is useful

Headline phrases like practical attack on a competition candidate are easy to over-read. The real margin is what remains after accounting for the attacker's assumed knowledge and for how the numbers were produced.

How it works

  1. List the attacker's inputs per experiment: one tag; a tag plus leaked state bits; the key and nonce; or an internal state.
  2. Compare cost against the claimed security: brute force on a 128-bit key costs about 2^128 trials, while these solver runs take seconds to hours, but only under their own assumptions.
  3. Check what the designers disclaimed: nonce reuse, decryption misuse and insider knowledge of the state were never part of Acorn's claims.
  4. Record how the numbers were produced: probabilities estimated over 3,000 random tags or states on one desktop core, reproducible from the paper's published scripts.
  5. Keep two statements separate: the attacks do not contradict the author's claims, and they still cast doubt on Acorn's wide applicability and on what authenticated encryption should be required to provide.

Example

State recovery with an 800-second timeout succeeds for about 62 percent of tags but returns a decoy state unless state bits leak; that gap between some state and the state is the margin.

What to watch for

This reading reflects one 2016 paper's experiments with one solver and one cipher; it is not a verdict on Acorn's final competition standing or on SAT attacks in general.

Useful background: State recovery from the authentication tag, State collisions and same-tag forgeries in ACORN.

Related ideas

Papers

Reading the security margin of the JH mode

How to read the result as a margin statement: the JH mode of operation adds no weakness beyond the unavoidable birthday bound, so any attack faster than about 2^(c/2) would have to exploit the internals of the permutation rather than the way it is used.

Why it is useful

Before this paper, the best known statement about JH was indifferentiability from a random oracle up to 2^(n/6) queries, which implied collision resistance only up to 2^(n/6), far from optimal. A margin reading compares the proven bound with the generic attack cost, and closing that gap is exactly what this paper does.

How it works

  1. Compare the proven query bound against the generic birthday bound 2^(c/2).
  2. Check the model: an ideal permutation, facing an information-theoretic adversary allowed forward and backward queries.
  3. Check the parameter conditions: digest size c at most n/2, and q below 2^(n/2).
  4. Keep mode-level guarantees separate from permutation-level cryptanalysis; this paper provides only the first.

What to watch for

An ideal-permutation proof cannot certify the concrete JH permutation. Reduced-round or structural attacks on the real permutation are a different line of work and are not part of this paper.

Useful background: Optimal collision resistance of iterated JH, The JH hash function.

Related ideas

Papers

Physical and implementation cryptanalysis

Adversarial measurement, perturbation and extraction from executing or stored cryptographic state.

Fault injection and fault-assisted attacks

Secret recovery or security-check bypass using corrupted execution, including differential faults and ineffective-fault selection bias.

Differential fault analysis

Differential fault analysis compares correct and faulty computations to derive information about a secret.

Papers

Statistical ineffective fault attacks

SIFA extracts secret-dependent bias from executions in which injected faults do not alter the observed output.

Papers

Side-channel and leakage analysis

Timing, cache, power, electromagnetic, speculative-execution and remanence leakage, including profiled and higher-order attacks.

Cache-timing attacks

Cache-timing attacks infer secret-dependent computation from differences between cached and uncached accesses. The observations may concern data accesses or which instructions execute.

Why it is useful

A mathematically secure algorithm can leak through the way a processor runs its implementation.

How it works

  1. Identify a cache resource affected by the secret computation.
  2. Observe timing changes associated with that resource.
  3. Relate the measurements to possible memory accesses or execution paths.
  4. Assess how much secret information those patterns actually reveal.

What to watch for

The attacker needs the access and resource sharing required by the particular method. Detecting a pattern is not the same as recovering a complete key.

Papers

Instruction-cache trace analysis

Instruction-cache analysis looks for changes caused by the code a victim executes. In the paper's experiment, a co-running process measures cache interference to distinguish portions of an RSA exponentiation.

Why it is useful

A secret can influence the sequence of arithmetic routines even when the observer cannot read the secret or directly inspect the victim's memory.

How it works

  1. Establish the required sharing of instruction-cache resources.
  2. Collect timing observations while the victim performs the relevant computation.
  3. Look for repeated patterns associated with operations such as squaring or multiplication.
  4. Compare the inferred sequence with the implementation's exponentiation rules.

What to watch for

The paper studies an old OpenSSL sliding-window path on a specific processor setup. It does not establish that every RSA implementation, modern CPU or cross-core placement leaks in this way.

Papers

The Flush+Reload monitoring round

A spy loop that watches one shared memory line: flush the line out of every cache level with the x86 clflush instruction, wait while the victim runs, then reload the line and time that reload. A fast reload means the line was fetched back into the cache during the wait, so the victim touched it; a slow reload means nobody did.

Why it is useful

Because the spy chooses the exact line, it learns which specific code or data the victim executed, not merely which coarse cache region was active. Earlier cache attacks mostly identified larger classes of locations and suffered false positives; here the LLC being shared moves the attack off the victim core entirely.

How it works

  1. Flush the chosen line with clflush; inclusiveness guarantees it leaves all cache levels.
  2. Wait a chosen period so the victim has time to run.
  3. Reload and measure: a load below a time threshold means the line was back in the cache.
  4. Pick lines that run often, such as loop bodies, so a short wait still catches an access.

Example

After the spy flushes the line holding a victim routine, the reload takes about 40 cycles instead of about 280: the victim ran that routine during the wait.

What to watch for

The wait is a trade-off: longer waits miss fewer victim accesses but blur the timeline, and an access overlapping the reload can be missed. Prefetching and speculative execution can pull lines into the cache without a real access, so results need filtering.

Useful background: Sharing memory pages between processes, Cache lines, sets and the last-level cache.

Papers

Consistency checks for side-channel traces

An inferred operation trace can be checked against rules of the victim algorithm. A sequence that the algorithm could not produce is evidence that the timing data was misclassified.

Why it is useful

Noise can turn an apparent key-bit observation into a false constraint, damaging later key-recovery attempts.

How it works

  1. Record candidate operation classifications with their uncertainty.
  2. Test them against the implementation's permitted operation patterns.
  3. Revisit conflicting observations or retain multiple candidates.
  4. Check whether additional measurements improve the evidence.

What to watch for

Passing a consistency check does not prove a trace is correct. Averaging repeated measurements also assumes that the executions can be aligned and contain comparable secret-dependent behavior.

Papers

Correlation power analysis

Correlation power analysis compares measured traces with predicted leakage values through statistical correlation.

Papers

Template attacks

Template attacks use profiled leakage distributions to classify secret-dependent computations.

Papers

Protocol, oracle and composition attacks

Attacks exploiting observable errors, malformed messages, replay, downgrade, transcript ambiguity, concurrency, state loss or mismatched component guarantees.

Bleichenbacher padding-oracle attack

Bleichenbacher's RSA attack uses padding-validity responses to narrow possible plaintext values.

Papers

Offline password guessing

An offline password attack tests guesses using data the attacker already has, without asking the legitimate server to check each guess. A captured challenge and password-dependent response can sometimes provide such a test.

Why it is useful

This distinction matters because slowing down login attempts does not slow an attacker who can test guesses on its own computers.

How it works

  1. Obtain a transcript or stored value that depends on the password.
  2. For each candidate password, recompute what that value should be.
  3. Reject guesses that do not match the observation.

Example

If a server sends a known challenge and the reply is only that challenge encrypted under a password-derived key, an attacker may try candidate passwords against the recorded pair.

What to watch for

Whether a transcript enables this attack depends on the protocol. Replacing a password by a fast hash of the password does not remove the guessing problem.

Papers

Vaudenay padding-oracle attack

Vaudenay-style attacks use block-padding validity responses to recover CBC-encrypted plaintext.

Papers

Public-key and algebraic cryptanalysis

Attacks on computational problems and structure exposed by public-key constructions, with parameters and auxiliary information made explicit.

Decoding and code-structure attacks

Information-set decoding, rank decoding, code distinguishers and equivalence or structural recovery attacks.

Support minors attack

Support-minors attacks express rank-decoding constraints through minors of matrices describing error support.

Papers

Information-set decoding

Information-set decoding algorithms and their time-memory tradeoffs for code-based security.

BJMM decoding

BJMM decoding applies representation techniques to multi-list information-set decoding.

Papers

Dumer decoding

Dumer decoding is an information-set decoding variant that matches partial error patterns.

Papers

Information-set decoding

Information-set decoding searches coordinate subsets that make decoding an error pattern tractable.

Papers

May-Ozerov decoding

May-Ozerov decoding incorporates nearest-neighbor search into information-set decoding.

Papers

Prange decoding

Prange decoding guesses an error-free information set and solves the resulting linear equations.

Papers

Stern decoding

Stern decoding uses a split search and collision matching inside information-set decoding.

Papers

Factoring, discrete-log and isogeny attacks

Classical attacks using number-theoretic algorithms, weak parameters, special curve structure, auxiliary torsion data or partial algebraic information.

Approximate common divisors

The approximate common-divisor problem asks for a hidden integer p given many samples of the form p times a large quotient plus a small error.

Why it is useful

It supplies the computational assumption behind the base integer encryption scheme: ordinary exact-GCD computation no longer directly recovers p from noisy samples.

How it works

  1. Specify how the hidden divisor, quotients and errors are sampled.
  2. Give the attacker the permitted number of noisy samples.
  3. Ask it to recover the hidden divisor.
  4. Choose parameters against the relevant attacks, keeping those distributions part of the assumption.

What to watch for

Small errors alone do not establish hardness. Brute-force error guessing, lattice methods and other attacks constrain the parameters. Exact multiples, much larger samples or a smooth secret divisor change the problem instance and must be analyzed separately.

Papers

Castryck-Decru SIDH attack

The Castryck-Decru attack uses auxiliary torsion information and higher-dimensional isogenies to recover SIDH secrets.

Papers

Coppersmith small-root method

Coppersmith methods use lattice reduction to recover small roots of modular polynomial equations.

Papers

Partial secret-exponent exposure

A side channel may reveal some bits or structural constraints on a secret exponent without revealing the whole value. Further recovery depends on the positions and reliability of those observations as well as on algebraic information about the key.

Why it is useful

The number of reported bits alone is not enough to establish an end-to-end key-recovery attack.

How it works

  1. Specify which exponent is exposed, including whether it is an RSA CRT component.
  2. Separate known bits from uncertain inferences.
  3. Record their positions and any relationships among them.
  4. Check the exact prerequisites of a proposed completion algorithm before claiming full recovery.

What to watch for

This paper reports scattered exponent-bit inferences, then invokes a lattice result about a different structured known-bit problem without demonstrating the necessary reduction. Its claimed polynomial-time full recovery is not established by those reported bit counts alone.

Papers

Lattice and noisy-linear cryptanalysis

Primal, dual, combinatorial and hybrid attacks on lattice or noisy-linear instances, plus lattice attacks exploiting partial nonce or key information.

BKW algorithm

BKW eliminates variable blocks from noisy linear samples before statistical recovery.

Papers

Dual lattice attacks

Dual lattice attacks use short dual vectors to obtain statistical tests on noisy linear samples.

Papers

Hidden number problem attacks

Hidden-number attacks reconstruct secret scalars from partial information about modular products.

Papers

Primal lattice attacks

Primal lattice attacks embed noisy linear equations into a lattice and search for a target short vector.

Papers

Polynomial-system and multivariate attacks

Algebraic equation solving, rank methods, differential structure and trapdoor recovery against multivariate public-key constructions.

Finding the oil space: the Kipnis-Shamir attack

Each component pi of the public map defines a matrix Mi through the polar form, pi′(x, y) = x^T Mi y. Because pi vanishes on the secret subspace O, Lemma 2 of the paper shows Mi maps O into its own orthogonal complement O⊥, the set of vectors whose inner product with every vector of O is zero. When n = 2m the dimensions match, so the image of O is exactly O⊥ for every invertible Mi, which makes O a common invariant subspace of all the maps Mj^-1 Mi; an invariant subspace is one that a map sends into itself, and finding a common one for many maps is a polynomial-time computation, which is how the original balanced Oil and Vinegar was broken. When n > 2m the images no longer coincide, but they still have an unusually large intersection, so vectors of O are eigenvectors of Mj^-1 Mi with probability about q^(1+m-n); repeating with random combinations of the Mi costs about O(q^(n-2m)) overall.

Why it is useful

This one observation explains both the 1998 break of balanced parameters and the modern rule of taking many more variables than equations. The gap n − 2m is the security knob against this attack: each extra unit of gap multiplies the cost by roughly q. Recovering the key matters more than forging once, because with O in hand the attacker can sign any message as if legitimate.

How it works

  1. Write each public polynomial as a matrix Mi via its polar form.
  2. If n = 2m, compute the common invariant subspace of the maps Mj^-1 Mi in polynomial time.
  3. If n > 2m, repeatedly take random invertible linear combinations F and G of the Mi, compute eigenvectors of F^-1 G, and test each candidate x by checking P(x) = 0.
  4. After the first vector of O is found, each further vector satisfies m linear equations for free, so the whole attack is dominated by finding the first vector.

Example

With m = 44 equations, n = 103 variables and q = 256 the gap n − 2m is 15, so the eigenvector search takes about 256^15 = 2^120 tries; counting the linear algebra per try, the whole attack was priced at about 2^136 field multiplications for these parameters, above the 128-bit target.

What to watch for

The cost bound hides polynomial factors (the paper writes it with a tilde over the O) and rests on a heuristic estimate of the eigenvector probability, not on a proof. In characteristic 2 the matrices Mi are never invertible when n is odd, and the paper works around this by fixing one variable to zero, slightly weakening the attack.

Useful background: The UOV trapdoor: a map that vanishes on a secret subspace, Signing with UOV: the polar form turns inversion into linear algebra.

Related ideas

  • UOV: the scheme being attacked

Papers

Groebner-basis cryptanalysis

Groebner-basis cryptanalysis solves polynomial systems describing a cryptographic construction.

Papers

The intersection attack on Rainbow

The same intersection idea applies to Rainbow, aimed at the innermost secret subspace O2: pick invertible matrices L1 to Lk from the span of the public matrices and look for x in the intersection of the images LiO2, whose dimension is at least k times o2 minus (k − 1)(n − o2). Solving the quadratic system alone is possible, but the attack is cheaper if the attacker simultaneously solves for a vector v in W⊥, the orthogonal complement of the output subspace W, which adds kn equations that are bilinear in the pair (x, v). With k = 1 the system becomes exactly the Rainbow Band Separation attack, so the new attack is a generalization of it. When n is at least 3 times o2 the intersection is usually trivial, and the attacker repeats with fresh guesses of the pair (L1, L2), expecting success after about q^(n − 3o2 + 1) tries.

Why it is useful

It unifies two attacks that had been studied separately, and it exploits both structural properties of a Rainbow public key at once: the vanishing on O2 and the fact that the polar form maps O2 into W. For the NIST parameter sets, which all have n at least 3 times o2, the guessing repeat factor is what keeps this attack from dominating everywhere.

How it works

  1. Pick k invertible combinations L1 to Lk of the public matrices.
  2. Write the quadratic equations in x coming from the preimages Li^-1 x lying in O2.
  3. Add the kn bilinear equations that say v is orthogonal to the polar form of each Li^-1 x with every basis vector.
  4. Impose affine constraints on x and v to pin a unique solution, then solve with the bilinear XL variant of Smith-Tone and Perlner; once O2 is known, finish the key recovery as in the UOV attack.

Example

For the finalist parameter set Ia (n = 100, m = 64, o2 = 32) the ratio n/o2 is just above 3, so the attack needs about q^5 repeats of a bilinear solve; the paper estimates the total at about 2^140 gate operations against a best previously known attack cost of about 2^147.

What to watch for

The system is not generic: for each pair (i, j) there is a non-trivial syzygy, a combination of the equations that cancels out identically, at bi-degree (2, 1), so the maximal rank assumption used in the standard complexity analysis fails. The paper conjectures a corrected generating function with an extra factor per syzygy and checks that it predicts the observed Macaulay matrix ranks on small instances. An earlier literature assumption that only n − 1 of the n bilinear equations are useful is also corrected here: all n should be kept.

Useful background: The intersection attack on UOV, Rainbow: stacking UOV layers.

Papers

The intersection attack on UOV

The new attack combines the Kipnis-Shamir idea with system solving. Instead of hunting for eigenvectors of Mj^-1 Mi, the attacker directly looks for a vector x lying in the intersection MiO ∩ MjO. When x is in that intersection, both Mi^-1 x and Mj^-1 x lie in O, so x must satisfy the quadratic system P(Mi^-1 x) = 0, P(Mj^-1 x) = 0 and P′(Mi^-1 x, Mj^-1 x) = 0. Since the intersection has dimension at least 3m − n, a non-trivial solution exists whenever n < 3m, and enough affine constraints can be imposed to make the solution unique. Intersecting k subspaces at once extends the range to n < (2k − 1)/(k − 1) times m, and leaves a system of (k+1 choose 2)m − 2(k choose 2) independent equations in nk − (2k − 1)m unknowns, solved with XL.

Why it is useful

This is the first improvement in UOV cryptanalysis that uses the specific structure of the public keys since 1999, and it beats both the direct attack and the Kipnis-Shamir attack on previously recommended parameters. It shows that the safety margin of UOV was smaller than the community believed, not because solving general MQ got easier but because the hidden subspace can be reached by a different route.

How it works

  1. Choose invertible matrices Mi and Mj (or k of them) from the span of the public matrices.
  2. Write the quadratic system in the unknown intersection vector x, plus the polar-form equations between the preimages.
  3. Impose as many affine constraints as the expected dimension of the intersection, leaving a unique solution.
  4. Solve with an XL or Groebner-style solver, then recover the rest of O from the m free linear equations per new vector.

Example

For q = 256, n = 103, m = 44 (a parameter set proposed for 128-bit security, where the direct attack was estimated at 2^130 and Kipnis-Shamir at 2^136), the attack uses k = 3 subspaces, giving 258 equations in 89 variables; it solves in about 2^95 multiplications, well below the claimed level.

What to watch for

The complexity estimate assumes the resulting system behaves like a random system with that many equations and variables; the paper verifies this by comparing the ranks of the Macaulay matrices, the big matrices whose rows collect all multiples of the equations up to a given degree, on small instances, which is experiment, not proof. Note that the extracted source text flattens superscripts, so a cost written as 295 means 2^95 field multiplications.

Useful background: Finding the oil space: the Kipnis-Shamir attack.

Papers

The rectangular MinRank attack

The MinRank problem asks, given a number of matrices, for a linear combination of them with exceptionally low rank. The paper finds a second, previously unnoticed MinRank instance inside a Rainbow public key: stack the vectors P′(e1, x), ..., P′(en, x) into a matrix Lx, where e1 to en is the standard basis. If y lies in the secret subspace O2, every row of Ly lies in W, so Ly has rank at most o2. Finding such a y therefore reduces to a MinRank instance, and since the matrices Le are public, an attacker can solve it with Support Minors Modeling and XL. The new instance is rectangular: the matrices are n-by-m rather than n-by-n, there are n − o2 + 1 of them rather than o2 + 1, the target rank is o2 rather than m, and the solution vector lies in O2 rather than in W⊥.

Why it is useful

This is the attack that does the most damage to the Rainbow parameters: a second, cheaper route to the key had been hiding in the public key since the scheme was designed in 2005, and the known-instance analysis had been pricing the wrong problem. It illustrates the general lesson that each extra structural property of a trapdoor is a potential equation system for an attacker.

How it works

  1. Stack the vectors P′(e, x) for the basis vectors e into the public matrix Lx.
  2. Fix o2 − 1 entries of y to zero, which leaves n − o2 + 1 matrices Le to combine.
  3. Look for a linear combination of them with rank at most o2; the rank condition is expressed algebraically by Support Minors Modeling, which introduces one variable per r-by-r minor of a basis of the row space and produces a bilinear system.
  4. Solve that system with the XL algorithm and the Wiedemann method, a memory-frugal way of solving large sparse linear systems, then read off y, which lies in O2, and finish the key recovery from there.

Example

For the finalist parameter set Vc the paper estimates the plain MinRank route at about 2^235 gate operations and the version using the extra equations P(y) = 0 at about 2^226, versus about 2^281 for the best previously known attack.

What to watch for

In characteristic 2, which covers all the Rainbow NIST parameters, the identity P′(y, y) = 2P(y) = 0 creates extra syzygies that a random MinRank instance does not have; the paper sidesteps them by deleting one row from every matrix, which slightly reduces the information used. Adding the equations P(y) = 0 to the system helps by a modest factor between 2^2 and 2^9. All cost estimates rely on genericity assumptions checked on small instances.

Useful background: Rainbow: stacking UOV layers, The intersection attack on Rainbow.

Papers

XL algorithm

XL multiplies polynomial equations by monomials and linearizes the resulting system.

Papers

Steganalysis and attacks on covert channels

Detection, distinguishing and disruption of hidden communication and subliminal channels under passive and active warden models. Construction interfaces belong under foundations.information-hiding; sender anonymity and software watermark attribution are separate goals.

Symmetric cryptanalysis

Distinguishing, recovery and forgery methods for ciphers, hashes and authentication constructions, separated from implementation leakage.

ACORN

ACORN (spelled Acorn in the paper) is a lightweight authenticated cipher: one shared 128-bit key both encrypts a message and produces a 128-bit tag that detects tampering. It works like a stream cipher built on a single 293-bit internal state, and it was a second-round candidate in the CAESAR competition for new authenticated-encryption designs.

Why it is useful

CAESAR was launched to find authenticated-encryption designs beating AES-GCM and AES-CCM in security or performance, and it drew 57 first-round submissions, more than the AES, eSTREAM and SHA-3 competitions before it. ACORN aimed at very small hardware, and its one small state for a 128-bit key is exactly what a cryptanalyst wants to test.

How it works

  1. One internal state of 293 bits, made of six feedback shift registers (a shift register is a row of bits that slides one position per step, taking a new bit in) of lengths 61, 46, 47, 39, 37 and 59, plus a separate 4-bit register.
  2. Three Boolean functions do all the work per clocked bit: KSG128 taps the state to make one keystream bit, FBK128 computes the feedback bit that will enter the state, and StateUpdate128 slides the state and inserts the feedback bit combined with the current input bit.
  3. Four phases run in order: initialization (the running text counts 1793 state updates mixing in the key and the nonce), processing of the associated data, processing of the plaintext, and tag generation, where the last 128 keystream bits become the tag.
  4. A nonce (a value meant to be used once per key) and any associated data (data that is authenticated but not encrypted, such as a packet header) are folded into the state before the tag is produced.

Example

Encrypting a short packet: start from the all-zero state, clock the key and nonce in, then the associated data and plaintext one bit at a time while adding keystream to plaintext bits, then clock through the tag phase and read off the 128-bit tag.

What to watch for

This entry describes the two versions the paper attacks: Acorn v1 and the tweaked Acorn v2 submitted two months into the second round. The competition continued after this 2016 paper, so later rounds and the final portfolio are outside this source.

Related ideas

Papers

Earlier cryptanalysis of ACORN

Four earlier results on Acorn set the stage for the SAT work: slid pairs and guess-and-determine state recovery by Liu and Lin, a full key recovery under nonce reuse by Chaigneau, Fuhr and Gilbert, state collisions usable for forgery by Salam et al., and a keystream regularity observed by Josh and Sarkar.

Why it is useful

The SAT attacks are measured against these: they need no hand-built algebra, they do not require nonce reuse, and they turn a single collision into arbitrarily many.

How it works

  1. Slid pairs (2014): two distinct key and nonce pairs can drive Acorn to the same internal state, up to a clock difference (the two runs agree once you slide the registers into alignment), with probability 1.
  2. Guess-and-determine state recovery (2014): the reported costs are about 2^180 and 2^130 CPU cycles against 2^128 for brute force (the retained source prints these exponents flattened into the digits, 2180 and 2130).
  3. Nonce-reuse key recovery (2015): reusing one nonce across plaintexts with the same associated data, helped by a decryption that releases plaintexts even when the tag check fails, recovers the key; the designer claims no security in those settings.
  4. Keystream regularity (2015): combining the first keystream bits with XOR, for a fixed key and nonce but different associated data, gives the scalar 0.

Example

The earlier state-recovery record of about 2^130 cycles still loses to brute force at 2^128; the SAT approach instead trades guaranteed success for minutes of runtime on a full tag.

What to watch for

These complexities and settings are quoted as the paper reports them, and most of the earlier work targets version 1 only.

Useful background: ACORN.

Related ideas

Papers

State collisions and same-tag forgeries in ACORN

Because many states produce one tag, the solver can be asked for many of them: fix one different state bit to 1 for each new state and let the solver choose the remaining bits. The same trick on the input side yields several plaintexts, or several associated-data strings, that share one tag.

Why it is useful

A tag that several different meaningful messages share is no longer a reliable identifier, which breaks the promise that authentication binds one message to one tag.

How it works

  1. Multi-state collisions: in instance number i, fix bit i of the state to 1, leave the other bits free, and require the observed tag; each SAT answer is a different state with the same tag, generalizing the single-collision result of Salam et al.
  2. The paper extracted five states per tag, averaging about 1,642 seconds per state on Acorn v1 and about 571 seconds on v2.
  3. Forgeries with the key and nonce known: fix a target tag, then ask for plaintexts reaching it; the solver returns several, including ones where chosen bytes spell readable text and the remaining bytes are filler it invents.
  4. Fixed points speed this up: target the internal state itself rather than the tag, and the solver returns extra matching messages in about 1.5 seconds each.
  5. Impact: a sender holding the key can later deny what was sent, and an unreliable channel can drop or alter ciphertext and associated data without the receiver detecting it.

Example

Three 64-byte messages spelling "Bob gave 5Euro.", "Bob gave 500Euro." and "Eve gave 500Euro." carry the same tag; the solver filled the unused bytes to force the match.

What to watch for

These experiments assume the adversary already holds the key and nonce, or the internal state, so they are not forgeries in the standard outsider model; the paper says so itself, and the filler bytes are chosen by the solver rather than the attacker.

Useful background: ACORN, State recovery from the authentication tag.

Related ideas

Papers

Structural attacks versus statistical ones

The paper labels its two analyses trivial, but they are of different kinds: state recovery is exact and structural, built from guesses plus linear algebra, while the distinguisher is statistical and rides a small bias across many samples.

Why it is useful

Knowing the kind tells you what a result means: the structural attack bounds the usable key length, the statistical one only certifies non-randomness; the two also combine, since statistical filters can prune guesses inside the structural attack.

How it works

  1. Structural route: guess a third of the state and some gate outputs, solve exact linear equations, cost about c times 2 to the power 83.5 for Trivium and 2 to the power 36.1 for Bivium.
  2. Statistical route: find a biased function of the keystream and count, needing on the order of one over the bias squared samples, about 2 to the power 32 for Bivium.
  3. Hybrid: a statistical post-test on each T0 guess cuts Bivium to 2 to the power 30.2 per pass with a low success rate, so repeating about six times restores success at 2 to the power 36.1 total.

What to watch for

The pre-test variant gains little on Trivium, the post-test trades success probability for speed, and the authors state outright that designing a strong statistical test is an open problem, so the hybrid numbers are indicative rather than final.

Useful background: Solving for the remaining two thirds, A linear distinguisher from biased samples.

Papers

Generic search and hash-construction attacks

Key search, meet-in-the-middle and time-memory tradeoffs, collision or preimage search, multicollisions and construction-level hash weaknesses.

A two-backward-query collision for the JH compression function

The JH compression step can be collided with only two queries to the inverse of the permutation. The attacker picks the output it wants and works backwards through the permutation twice, once per message block, to obtain two different inputs that compress to that same output.

Why it is useful

It shows that the compression step by itself gives no collision resistance, even when the permutation is perfectly random. So the security question shifts entirely to what chaining many steps together adds.

How it works

  1. Fix any target output v and pick two different message blocks z1 and z2.
  2. Query the inverse permutation on v XOR (0||z1) and on v XOR (0||z2), receiving x1 and x2.
  3. Recover the matching chaining inputs u1 = x1 XOR (z1||0) and u2 = x2 XOR (z2||0).
  4. Each pair now satisfies F(ui, zi) = v, so the two evaluations collide.

What to watch for

The paper states the two-query fact; the steps above are an illustration worked out from the definition of F. This is a statement about the step in isolation - it does not give a collision for the full hash, where padding, chaining and truncation all constrain what a real collision must look like.

Useful background: The JH compression function, Random permutation.

Related ideas

Papers

Biclique attacks on the SHA-2 family

Applied to SHA-256 and SHA-512, bicliques push preimage attacks to 45 and 50 rounds of the full hash functions, and to 52 and 57 rounds of their compression functions, covering more rounds than any earlier method.

Why it is useful

SHA-2 expands a 16-word message block into a longer schedule with non-linear mixing, so the computation does not split into independent halves on its own. The biclique has to be placed carefully and the message words have to satisfy padding and schedule constraints at the same time.

How it works

  1. Place a 6-round biclique at rounds 17-22 for SHA-256 and 21-26 for SHA-512, and construct it with Algorithm 2.
  2. Write message compensation equations with free constants, so that words before the biclique can be computed without the neutral-bit word and vice versa.
  3. Spend message bits on the padding rules: the encoded length and the trailing one-bit pin down parts of specific words.
  4. For SHA-512, leave part of the padding free and instead use a first preimage to place the final block, or use expandable messages at a cost near the birthday bound.

What to watch for

SHA-256 runs 64 rounds and SHA-512 runs 80, so the hash-mode attacks cover 45 and 50 of them. A compression-function result does not automatically transfer to the hash function, and the paper states plainly that only some of these attacks are convertible.

Useful background: SHA-2, Building bicliques from differential trails.

Related ideas

Papers

Case analysis of the earliest collision

The second half of the proof. Assuming no right-half collision among reachable states, every remaining way to complete a collision is forced into one of three local configurations, called C1, C2 and C3, that sit around the single query which completes the collision.

Why it is useful

A collision means two evaluation paths from the initial value end on states whose kept c bits agree. Fixing the earliest such collision and the query that completes it reduces an unbounded search over message pairs to a fixed list of local shapes, each of which a random permutation answer can satisfy only by luck.

How it works

  1. Let Coll be the event of a collision of the c-bit hash, and picture it as two paths whose endpoints have the same chopped value.
  2. Assume the collision is earliest-possible and let the i*-th query be the one that completes it.
  3. Classify: C1 has one endpoint already reachable with a matching chopped value, C2 has the new query create both endpoints, and C3 lets the new query precede an older one.
  4. Bound each case by the chance that a random permutation response matches a specific reachable state or digest window, at most about iN/(N^2 - q) for the i-th query, and sum over queries.

What to watch for

The three configurations cover only the case where no right-half collision happened; combined with the birthday bound on that event they give the theorem. The constants are stated for q below N = 2^(n/2).

Useful background: Orderly reachable nodes.

Related ideas

Papers

Length extension of an iterated hash

When a digest reveals the complete final chaining state of an iterated hash, an observer can use that state to process additional blocks without knowing the original message or secret prefix.

Why it is useful

It explains why using a bare secret-prefix hash as an authentication code is different from using a construction such as HMAC.

How it works

  1. Treat the observed full digest as a new chaining state.
  2. Continue the public compression algorithm on extra blocks.
  3. For a padded hash, account for the original padding and total length.
  4. Recognize that the resulting digest authenticates an extended encoding, not an arbitrary replacement message.

What to watch for

This argument depends on the hash structure and the available output state; it does not apply unchanged to every hash. HMAC hides the inner state behind a separate outer keyed computation, so the described extension is not an HMAC forgery.

Papers

Meet-in-the-middle attack

Meet-in-the-middle attacks match intermediate values computed from opposite ends of a cryptographic computation.

Papers

Orderly reachable nodes

The bookkeeping object of the proof. Each query the adversary makes is turned into edges of a directed graph on the n-bit states; a state is called orderly reachable if the initial value reaches it along a path whose query labels strictly increase, and Ui is the set of such states after i queries.

Why it is useful

Any collision the adversary builds must be assembled from evaluations it actually made. Recording which states are reachable, and in which query order, is what lets the proof charge collision probability to specific queries instead of arguing about all messages at once.

How it works

  1. Treat every query-response pair as potential edges; one permutation query is compatible with 2^(n/2) different edges, one for each choice of message block.
  2. Call a state orderly reachable when some path from the IV reaches it with strictly increasing query labels; the IV itself counts by convention.
  3. Show that as long as no two reachable states share right halves, each query adds at most one new reachable state.
  4. Track the event that two reachable states do share right halves; that is the first place a birthday collision would show up, and the paper bounds it by a birthday-type expression in q and N = 2^(n/2).

What to watch for

The graph is an analysis tool for the proof, not a part of the hash function. The strictly increasing label condition is what keeps paths honest when the adversary mixes forward and backward queries.

Useful background: The JH compression function, Birthday attack.

Related ideas

  • The JH compression function: Each compression evaluation becomes one edge in the graph.
  • Birthday attack: The shape of the bound on right-half collisions among reachable states.

Papers

Preimage attacks on reduced Skein-512

The paper reports the first cryptanalytic attack on the Skein hash function: a second-preimage attack on Skein-512 reduced to 22 of its 72 rounds, plus a preimage attack on 37 rounds of its compression function.

Why it is useful

Before this work every published Skein result attacked the compression function alone, and rotational and differential methods did not carry over to the full hashing mode. The authors deliberately chose the simplest example in the strongest model rather than the largest round count.

How it works

  1. Reduce Skein-512 to rounds 3-24 and build a dimension-3 biclique over rounds 12-15 with Algorithm 1.
  2. Compute the forward chunk over rounds 16-19 and the backward chunk over rounds 8-11.
  3. Match on three bits of one state word, rechecking the surviving key candidates on the full state.
  4. Improve the matching phase with a statistical hypothesis test, accepting a small rate of false positives instead of insisting on a perfect match.
  5. In the compression-function setting the attacker also controls the tweak value, which adds freedom and pushes the attack to 37 rounds with a rebound-style biclique.

What to watch for

These are attacks on round-reduced variants. The reported complexities of 2^508.4 for a pseudo-preimage and 2^511.2 on the compression function sit below the 2^512 ideal but far beyond any real machine, and the full 72-round hash function is not broken.

Useful background: Skein, Biclique cryptanalysis, Splice-and-cut preimage search.

Related ideas

Papers

Splice-and-cut preimage search

Splice-and-cut is a family of meet-in-the-middle methods for finding hash preimages faster than trying every input. The attacker splits the computation into two parts that each ignore a different set of message or key bits, enumerates those neutral bits on both sides, and looks for a match in the middle.

Why it is useful

A preimage is an input that hashes to a given target digest, and brute force costs 2^n for an n-bit hash. If one part ignores b bits and the other ignores c bits, the attacker can test 2^(b+c) candidates while doing work closer to 2^b + 2^c, so the search gets cheaper.

How it works

  1. Find bits that one part of the computation never uses, so flipping them leaves that part unchanged.
  2. Find a second, independent set for the other part; each part is called a chunk and the corresponding bits are neutral for it.
  3. Compute the forward part once per value of its neutral bits and the backward part once per value of the other set.
  4. Compare a small matching variable computed from both directions; a surviving candidate is rechecked on the full state.
  5. Let the two chunks overlap where possible, so that neutral bits formally belonging to both are used by only one of them.

What to watch for

The overlap trick was long known only informally as an "initial structure", which is what bicliques replace. The saving is a constant factor in the exponent, not a break, and the number of structures to prepare grows as 2^(n-2d) for dimension d.

Useful background: Merkle-Damgard construction.

Related ideas

Papers

State recovery as the yardstick for key length

The first attack model: given a stretch of known keystream, reconstruct the internal state; because the state update runs backwards too, this also hands over the key.

Why it is useful

The cost of the cheapest state-recovery attack is an upper bound on how much secret material the design can safely carry, which is exactly the question the authors set out to answer.

How it works

  1. Take a known piece of keystream, for example from a message with known headers.
  2. Search for the internal state that reproduces it; the paper improves this to about 2 to the power 83.5 for Trivium and 2 to the power 36.1 for Bivium.
  3. Compare that cost with the previous best attacks, 2 to the power 135 and 2 to the power 164.

What to watch for

A generic time-memory trade-off based on the birthday paradox already gives an attack on the order of the square root of the state size; the paper contributes a dedicated attack far below the plain guessing cost of 2 to the power 288.

Useful background: Trivium and Bivium: the structure under attack.

Papers

Why the 1152-clock initialization matters

Exhaustive key search on Trivium does not cost 2 to the power 80 but roughly gamma times that, because every key trial must first run the 1152-clock initialization before a single keystream bit appears; the authors put gamma near 2 to the power 10.

Why it is useful

That multiplier is what makes the 2 to the power 83.5 structural attack competitive with brute force, and it is why enlarging the key to 128 bits would buy nothing: the attack would still sit far below key-search cost.

How it works

  1. Charge each key trial for its 1152 initialization clocks, giving about 2 to the power 90 for a full search.
  2. Compare that with the state-recovery attack at about c times 2 to the power 83.5, which is at least close to and possibly faster than searching.
  3. Conclude that a real security gain needs a larger state or another redesign, accepting longer initialization and bigger hardware.

What to watch for

Gamma is an implementation assumption, not a measured constant; parallel hardware and cheap early aborts change it, so the comparison with exhaustive search is a judgement, not a theorem.

Useful background: Solving for the remaining two thirds.

Papers

Statistical, algebraic and structural distinguishers

Structural cryptanalysis exploits how a cipher is built rather than statistics of its outputs: encoding its update rule as equations or logic and solving for the secret. On Acorn this means turning the tag-generation loop into clauses and solving for the 293-bit state, or for the key and nonce behind a known state.

Boomerang attack

Boomerang attacks connect two differential trails through related encryption and decryption computations.

Papers

Cube attacks: cube sums as key equations

A cube attack views one output bit of a cipher as a polynomial p over GF(2) in secret key bits and public bits (IV bits for a stream cipher). Fixing a small set of public variables called a cube and summing the output over all their 0/1 values cancels every term that misses a cube variable, leaving only the superpoly.

Why it is useful

Summing over a cube is a degree-reduction step: the superpoly has lower degree than p. If the superpoly is linear in key bits, one cube gives one linear equation about the key, and enough independent equations solve for the whole key.

How it works

  1. Write the output bit in algebraic normal form (ANF): a XOR-sum of products of variables.
  2. Pick a cube, that is a term of public variables, and sum the outputs over all assignments of the cube variables; the sum equals the superpoly of that cube.
  3. In a key-independent preprocessing phase, search for maxterms - cubes whose superpoly is linear and not constant - with linearly independent superpolys.
  4. Online, evaluate the same cubes against the real key, read off one linear equation per cube, and solve the system.

Example

For p = v1v2x1 + v1x2 + 1 with cube {v1, v2}: the terms v1x2 and 1 each miss a cube variable and cancel in the sum, while v1v2x1 sums to x1, giving the equation "x1 = measured value".

What to watch for

Linear superpolys are not guaranteed to exist, and finding them can dominate the attack cost; on scaled-down Grain-128 the authors report that cube testers succeed while cube attacks seem to fail.

Papers

Cube testers: cube sums as distinguishers

A cube tester performs the same cube summation as a cube attack but never writes equations. It only checks whether the summed value behaves like a random function would, using cheap tests such as balance, low degree, presence of linear variables, or presence of neutral variables.

Why it is useful

A strong deviation from random behavior proves the cipher is distinguishable from an ideal keystream generator even though no key bit is recovered. The preprocessing is easier than for cube attacks because any easily testable property of the superpoly is usable, not only linearity.

How it works

  1. Preprocess: find cubes whose superpolys show a testable non-random property, for example a truth table that is far from balanced.
  2. Online: sum the outputs over the cube for the real key and test the property.
  3. A failed test (property present) distinguishes the cipher from random; a passed test says nothing.

What to watch for

A distinguisher alone does not recover the key, and the usual block-cipher trick of guessing key material and partially decrypting does not exist for stream ciphers, so converting cube testers into key recovery needs a new mechanism - which is what the next lesson supplies.

Useful background: Cube attacks: cube sums as key equations.

Papers

Differential cryptanalysis

Differential cryptanalysis studies how input differences propagate to output differences.

Papers

Dynamic cube attacks: dynamic variables that zero state bits

A dynamic cube attack keeps the cube summation but stops holding the non-cube public variables fixed. Each such dynamic variable is assigned a function of cube variables and of secret expressions, chosen so that a chosen internal state bit evaluates to zero during the whole summation.

Why it is useful

When key and IV are not mixed thoroughly, the cipher's resistance to cube testers hangs on a few nonlinear operations performed at the latest stages; those operations create the high-degree terms. Forcing one input of such a multiplication to zero collapses the degree, so under the correct guess of the secret expressions the output becomes visibly non-random while wrong guesses look random.

How it works

  1. Decompose the output as P = (source polynomial) times (target polynomial) plus (remainder polynomial), so that nullifying the source kills the worst high-degree product.
  2. Choose a public variable that appears linearly in the source polynomial and assign it the expression that makes the source identically zero.
  3. Collect the secret expressions multiplying cube-variable terms; these are the unknowns to guess, one bit each.
  4. For each guess run the cube tester with the dynamic variables set accordingly: the correct guess shows a strong bias, most wrong guesses do not, so wrong guesses are eliminated and key information leaks out directly.

Example

In the paper's toy case P = P1P2 + P3, setting the static variable v4 to 0 and the dynamic variable v1 to the linear expression that cancels P1 leaves a polynomial of degree 2 in the public variables whose sums over the cube v2v3v5 and its subcubes are zero for most keys.

What to watch for

Finding which state bits to zero is manual, cipher-specific work that cannot be fully automated; the paper needs several rounds of recursive simplification before a late state bit can be zeroed, and zeroing state bits too late in the initialization was not possible at all.

Useful background: Cube testers: cube sums as distinguishers.

Papers

Guess scoring and attack complexity

The online phase guesses the bit values of the secret expressions, sums the output over a big cube and its subcubes for each guess, and scores each guess as the fraction of 1 values among the subcube sums; guesses are then read from the best score downward.

Why it is useful

The superpolys in these attacks are so sparse that they evaluate to zero for almost all keys, so a guess whose sums are nearly all zero is non-random and is either correct or assigns correct values to a fixed subset of the expressions - both outcomes leak key information.

How it works

  1. Sum over all subcubes with the Moebius transform: with cube dimension d and e guessed expressions this costs about d times 2^(d+e) bit operations.
  2. Data stays far below time: with y dynamic variables, 2^(d+y) chosen outputs suffice, one for each cube and dynamic-variable value.
  3. Exploit the guessed linear expressions: Gaussian elimination turns them into linear combinations of the still-unknown key bits, and the remaining free bits are found by exhaustive search with the cipher itself as the checker.

What to watch for

Complexity estimates for the strongest attacks depend on the position of the correct guess in the sorted list, which the authors estimate by assuming wrong guesses behave randomly - an assumption the paper itself calls an oversimplification, since some wrong guesses inherit a low score.

Useful background: Dynamic cube attacks: dynamic variables that zero state bits.

Papers

Guessing AND-gate outcomes at favourable odds

Sharpen phase one by guessing the outputs of chosen AND gates instead of individual bits: the AND of two roughly random bits is zero with probability 0.75.

Why it is useful

Each correctly guessed gate buys extra linear equations on T0 and shrinks the brute-forced part, at the price of scanning the keystream for a window in which the whole guess holds.

How it works

  1. Pick a set of specific AND gates in each register and guess their outputs; all-zero is the most likely single guess.
  2. Allow G gates to be zero and H gates to be one; that event has probability 0.75 to the G times 0.25 to the H, and the keystream must be long enough to meet it.
  3. Sums of a few gates stay biased too, so nonlinear equations can be guessed at better than even odds while w stays small.

What to watch for

The bias only helps for a small number of summed gates: as w grows the probability approaches one half, so guessing degenerates to coin flipping while the keystream demand explodes.

Useful background: Guessing one third of the state.

Papers

Guessing one third of the state

Phase one of the state-recovery attack: guess the subset of state bits called T0, roughly one third of the state, and use linear equations to fill in the rest.

Why it is useful

Because every block length is a multiple of three, moving the state from time t to time t+1 is a linear transformation of one of the three subsets plus a one-bit disturbance, so one correct guess makes a large part of the cipher predictable.

How it works

  1. Label the state bits by their position modulo three; this gives three subsets T0, T1 and T2.
  2. Guess all of T0 at some time t, brute-forcing about 2 to the power theta-over-3 candidates.
  3. The first few forward steps yield free linear equations on T0, cutting the guess work to 2 to the power 74 for Trivium and 2 to the power 37 for Bivium.

What to watch for

The exponent counts only the guessing; each guess still has to be completed by a second phase whose cost is folded into a constant c, so real runtimes are higher than the headline exponents.

Useful background: Trivium and Bivium: the structure under attack.

Papers

Integral cryptanalysis

Integral cryptanalysis tracks balanced sums over structured collections of cipher inputs.

Papers

Interpolation attack

Interpolation attacks reconstruct algebraic descriptions of a cipher or its reduced-round components.

Papers

Key recovery from a known state

Given the true 293-bit state that Acorn holds just before tag generation, the SAT solver extracts the whole 128-bit key and the 128-bit nonce within seconds and with certainty.

Why it is useful

A stream cipher should behave like a one-way chain: seeing the state should not hand over the key that produced it. The paper adopts exactly this as the quality test, and Acorn fails it once the state is known.

How it works

  1. Encode the full path from key and nonce through initialization and message processing into CNF.
  2. Fix the state bits at the tag-generation input to the known state, together with the plaintext and optionally the ciphertext.
  3. Leave the 256 key and nonce bits free and let the solver finish; the paper measures average times between roughly half a second and three and a half seconds.
  4. The run is deterministic, so it succeeds with probability 1 given the right state; decoy states that merely share the tag do not yield the key.
  5. Acorn v2 falls slightly faster than v1 because v2 runs 2,304 state updates before tag generation against v1's 2,560.

Example

Hand the solver 293 state bits plus an 8-byte plaintext, and it returns the 16-byte key and the 16-byte nonce in about a second.

What to watch for

The attack needs the genuine state as input, which an attacker normally does not have; timings were measured on one 2.3 GHz core with the 2016-era Cryptominisat 2.9.5.

Useful background: State recovery from the authentication tag, SAT-based cryptanalysis.

Related ideas

Papers

Key recovery results on Grain-128

Three key-recovery attacks: full recovery of the 128-bit key on Grain-128 reduced to 207 initialization rounds in practical time; an attack on the 250-round variant costing about 2^100 cipher evaluations for about 60% of keys; and an attack on the full 256-round cipher that works for a weak-key subset of about one key in a thousand at about 2^113 bit operations.

Why it is useful

They move the best single-key attack on Grain-128 from recovering 2 key bits at 213 rounds to full key recovery at 207 rounds, and they give the first demonstration that a cube-style attack is effective on the full version of a well known cipher that had resisted all previous attacks.

How it works

  1. Attack 1: 55 parameter sets over output bits 208-218 recover about 80 key bits on average (declaring expressions undetermined when the best score is at least 0.44), and the last 48 bits fall to exhaustive search.
  2. Attack 2: nullify state bit b230 using 24 dynamic variables over a 37-dimensional cube; for about 60% of keys the remaining search is about 2^100 cipher evaluations, with about 10% of keys resisting.
  3. Attack 3: fix 10 key bits to zero so that b236 can be nullified, sum over a 46-dimensional cube with 13 dynamic variables; the result beats exhaustive search over the 2^118 weak keys by a factor of about 2^15.

What to watch for

The full-cipher attack only touches the weak-key subset, not arbitrary keys, and the 250-round and full-cipher complexities come from a partial simulation rather than a completed attack run, so the quoted factors are estimates.

Useful background: Grain-128: NFSR plus LFSR stream cipher, Dynamic cube attacks: dynamic variables that zero state bits.

Papers

Linear cryptanalysis

Linear cryptanalysis uses biased linear relations among message, ciphertext and key bits.

Papers

Partial simulation: verifying infeasible attacks

The authors separate a full simulation, which runs the whole attack on random keys, from a partial simulation, which computes the subcube sums only for the correct guess and checks whether the expected bias actually appears.

Why it is useful

A partial simulation costs about b times 2^d bit operations for a cipher costing b per execution and does not depend on the number e of guessed expressions, so attacks whose total cost is far beyond feasible can still be experimentally checked for the property that powers them.

How it works

  1. Run steps 1-2 of the preprocessing, then evaluate the subcube sums with the dynamic variables set by the correct (known) guess on random keys.
  2. If the correct guess shows the predicted strong bias towards 0 on most keys, the nullification works and the full attack is expected to succeed.
  3. Estimate the rank of the correct guess from the observed bias, assuming wrong guesses behave like random summations, and derive the attack complexity from that estimate.

What to watch for

This is evidence, not a completed attack: the complexity figure relies on the random-wrong-guess assumption, and for a minority of keys the observed bias was too weak to beat exhaustive search significantly.

Useful background: Key recovery results on Grain-128.

Papers

Polynomial-hash cycling attacks

A polynomial hash assigns different powers of a secret field element to different message positions. If those powers repeat after a short cycle, some different positions receive the same weight and certain message changes cancel out.

Why it is useful

The example shows why the algebraic structure of a hash family affects its collision probability. A long tag alone does not describe every term in an authentication bound.

How it works

  1. Consider the powers of the secret hash key H.
  2. Choose two message positions separated by a possible cycle length.
  3. Swap their blocks, or apply matching changes to both.
  4. If the two powers of H coincide, the polynomial hash remains unchanged.

What to watch for

This is conditional on the hidden hash key lying in the relevant subgroup and on the message containing suitable positions. The paper does not demonstrate a practical general forgery against ordinary random-key AES-GCM.

Related ideas

Papers

Paired bit changes in polynomial authentication

When two message positions have the same polynomial-hash weight, adding the same difference at both positions cancels in a binary field. If those positions are ciphertext blocks under counter-mode encryption, corresponding plaintext bits change too.

Why it is useful

An authentication collision can permit controlled data changes rather than merely producing an unintelligible message.

How it works

  1. Find or hypothesize two positions with equal hash weights.
  2. XOR the same difference into both encoded blocks.
  3. The two equal weighted differences cancel if the hypothesis is correct.
  4. In counter-mode encryption, each ciphertext difference also changes the corresponding plaintext bits.

Example

A bit flipped in one chosen block must be paired with the same bit difference in the other selected block to preserve the sum.

What to watch for

Without equal weights, this cancellation does not follow. The attack still needs the weak-key condition and appropriate message positions; its existence does not make every GCM ciphertext malleable under a valid tag.

Papers

Reduced-round SAT experiments on ACORN

Cut the number of state updates that turn the state into a tag, then measure how often the solver still inverts the reduced version inside a fixed time budget. Acorn v2 uses 768 tag-generation updates and v1 uses 512; the paper's reduced runs cover roughly 130 to 180.

Why it is useful

Full ciphers are usually out of reach, so cryptanalysts test weakened copies first. The curve of success probability against added updates is the practical evidence for how much of the cipher is really needed to hide the state.

How it works

  1. Shorten the tag-generation loop that produces the tag from the state, and generate random target tags with each reduced version.
  2. At each length, count how often a matching state is found within the budget; the paper reports a linear dependence with a very small slope, so a few dozen extra updates barely slow the solver down.
  3. Read the timeout as part of the attack: the same formula can go from unsolved to solved by allowing more seconds, so every result is a pair, probability p within time t, never a plain yes or no.
  4. Reduced versions were attacked in practice with no human study of Acorn's algebra; the full-length runs are the ones reported with the tabulated timeouts.

Example

A run with 150 tag-generation updates and a 200-second timeout either returns a state, proves none exists, or hits TIMEOUT; repeating over 3,000 random tags estimates the success rate.

What to watch for

A small slope measured between 130 and 180 updates does not extrapolate to the full 768; the paper fits no growth law, and solver runtimes jump around rather than rising smoothly.

Useful background: State recovery from the authentication tag.

Related ideas

Papers

Slide attack

Slide attacks exploit repeated round structure by relating computations shifted by a round or round sequence.

Papers

Solving for the remaining two thirds

Phase two: with T0 and the guessed gate outputs fixed, clock the cipher forward and collect linear equations on the still-unknown T1 and T2 bits, then solve them.

Why it is useful

While the guessed gates behave as assumed the update is linear, so every three clocks hand over two fresh linear equations; once the guess window ends the equations turn quadratic, cubic and so on, which caps how many cheap equations exist.

How it works

  1. Collect linear and degree-two equations by clocking forward inside the guessed window.
  2. Solve the linear system by Gaussian elimination and check the candidate state against further keystream.
  3. Trade off with scenario tables: T1 reaches about c times 2 to the power 83.5 using 2 to the power 61.5 keystream bits, T2 spends more time for less keystream, and T0 and B0 are the no-guess lower bounds.

What to watch for

Backward clocking is a dead end because the design raises equation degree quickly in that direction, and the constant c, the cost of solving a sparse 192-variable system, is assumed rather than measured.

Useful background: Guessing AND-gate outcomes at favourable odds.

Papers

State recovery from the authentication tag

Run the SAT solver backwards from a 128-bit tag to find a 293-bit internal state that produces it. On the full Acorn v1 and v2, the solver returns some matching state for a majority of the tested tags within about fifteen minutes.

Why it is useful

The tag is the only public output at the end of a run, so asking which states explain it is the most direct question an attacker can pose; if that question is cheap to answer, the final state is badly hidden.

How it works

  1. Build the formula for the tag-generation phase only, leaving all 293 state bits unknown, and fix the 128 tag bits to the observed value.
  2. Let the solver run under a budget: with an 800-second timeout it found a matching state for 0.6240 of 3,000 random tags on Acorn v1 and 0.6093 on Acorn v2, and longer timeouts raise the success rate.
  3. Beware decoys: 293 state bits map onto only 128 tag bits, so many unrelated states share one tag, and the state you get need not be the user's real state.
  4. To force the real one, give the solver some true state bits, which the paper models as leaked by a side channel (accidental physical leakage such as power use): with 283 known bits the right state came out for roughly 8 to 10 percent of tags at a 1,000-second timeout, and with fewer than 263 known bits the probability fell to zero.

Example

A tag of all-FF bytes is fed in as 128 fixed bits; every remaining free variable is a state bit the solver must choose.

What to watch for

Success probabilities are estimates over 3,000 random tags with one solver and fixed timeouts, and the known-bits variant assumes a leak that the paper does not itself provide.

Useful background: ACORN, SAT-based cryptanalysis.

Related ideas

Papers

Trivium and Bivium: the structure under attack

Trivium is a hardware stream cipher with a 288-bit internal state and an 80-bit key, built from shift registers whose block sizes are all divisible by 3; Bivium is a two-register, 177-bit truncation of it.

Why it is useful

Every attack in the paper grows out of this layout: the divisible-by-3 block sizes split the state into three interleaved parts, and the only nonlinear operation in the whole cipher is one AND gate per register.

How it works

  1. Picture the state as two or three registers, each cut into three blocks whose lengths are multiples of three.
  2. Each clock, taps leave a register, pass through one AND gate, and XOR into the next register; the keystream bit is a plain XOR of tap bits.
  3. Trivium uses three registers and a 288-bit state with an 80-bit key; Bivium drops the third register and shrinks to 177 bits.

Example

Divisibility by 3 is what later lets the attacker guess one third of the state and treat a whole clock step as almost linear.

What to watch for

The paper attacks the whole class of Trivium-like designs, not only the submitted cipher; a result proven for the truncated Bivium does not automatically transfer to full Trivium.

Related ideas

  • Stream ciphers: the primitive under attack

Papers

Differential cryptanalysis

Difference propagation, differential trails and related distinguishers.

Biclique cryptanalysis

A biclique is a small block of precomputed computation: two sets of 2^d internal states each, arranged so that every state in the first set flows to every state in the second set under its own message. Biclique cryptanalysis uses such a block as the seed of a meet-in-the-middle attack.

Why it is useful

The earlier initial-structure trick was informal and hard to generalise. Naming the object and describing it in graph terms let the authors reuse the machinery of differential cryptanalysis, and the same idea later produced key-recovery attacks on the full versions of popular block ciphers.

How it works

  1. Pick a sub-cipher f of the block cipher E and a group of 2^(2d) messages M[i, j] that parameterise f.
  2. Build states Q_i and P_j so that f maps Q_i to P_j under M[i, j] for every pair (i, j).
  3. Start one chunk from each Q_i and the other from each P_j.
  4. Test all 2^(2d) message candidates for the price of about 2^d + 2^d chunk computations instead of 2^(2d).

What to watch for

A biclique breaks nothing by itself; it is a way to organise and reuse computation. The real gain depends on how cheaply the structure is built and how many times one structure can be recycled.

Useful background: Meet-in-the-middle attack, Differential cryptanalysis.

Related ideas

Papers

Building bicliques from differential trails

Bicliques are constructed from differential trails. One mapping Q_0 to P_0 is fixed as the basic computation, and every other mapping is viewed as a pair of input and output differences relative to it. A computation that satisfies all those differences at once is exactly a biclique.

Why it is useful

Differential cryptanalysis already has a large toolbox: message modification, local collisions, trail backtracking and rebound techniques. Recasting the biclique as a system of differentials makes all of those tools available for building it.

How it works

  1. Algorithm 1, for independent trails: choose message differences that decompose as one difference per side, build the P_j from Q_0 and the Q_i from P_0, and keep the cases where one set of trails leaves the other set's active non-linear elements alone.
  2. Algorithm 2, for ciphers with step-by-step message injections such as SHA-2: fix the two trail families first, then solve for a base message block by block, using message compensation to keep the families consistent.
  3. Algorithm 3, for long sub-ciphers: split f in two, fix a middle state, and use a boomerang-style quartet of states so each half carries its own difference.
  4. Estimate the chance that the two trail families do not interfere either experimentally or by counting sufficient conditions.

What to watch for

Algorithm 1 succeeds with probability 2^(-t*2^d), so it is practical only at small dimension. Where the message schedule is non-linear the trails themselves depend on the message, which is why SHA-2 needs message compensation at all.

Useful background: Biclique cryptanalysis, Differential cryptanalysis.

Related ideas

Papers

Forging tags with a differential on the nonce blocks

A useful trail here starts and ends with its difference confined to the 32 most significant state bits, which is exactly where an input block is XORed in. Inject a difference in one block, cancel it in the next, and the tag computed afterwards is also a valid tag for the unmodified input, with the probability of the trail.

Why it is useful

This attacks the 384-round parts of the mode (nonce setup, associated data, tag generation) rather than the far longer encryption permutation, so it applies to all three variants of TinyJAMBU alike.

How it works

  1. Ask for the tag of a message whose associated data (or nonce) blocks carry the chosen differences; the returned tag then authenticates the original message with probability p.
  2. If p reaches 2 to the minus 64, the claimed 64-bit authenticity is broken.
  3. For a stronger version, find two nonce prefixes whose states collide after the first two blocks, then keep renewing the third nonce block: one collision pays for forgeries on many targets while still respecting nonce uniqueness.
  4. Improve p beyond a single trail by collecting all trails that share the same input and output differences and adding their probabilities.

What to watch for

The paper reports a 338-round trail of probability 2 to the minus 64, and 24 trails sharing its masks that together give 2 to the minus 62.68; the reusability trick relies on the nonce being spread over three blocks, a consequence of the minimal state size.

Useful background: How TinyJAMBU absorbs the nonce, data and tag in 32-bit blocks, Refined differential trails with correlated AND gates.

Related ideas

Papers

Higher-order differential cryptanalysis

Higher-order differential cryptanalysis applies iterated derivatives to reduce algebraic degree.

Papers

Impossible differential cryptanalysis

Impossible-differential attacks eliminate keys using input-output difference pairs that cannot occur through selected rounds.

Papers

Refined differential trails with correlated AND gates

The refinement adds one observation to the simple model: because the state shifts by one bit per round, a value that enters an AND gate re-enters another one 15 rounds later. When the two outer bits carry a difference and the shared middle bit does not, the two AND outputs flip together or stay together, decided by that single middle bit.

Why it is useful

This is the frequent case in TinyJAMBU, so modelling it captures most of the accuracy that the exact-but-slow methods buy, at a cost the solver can still afford.

How it works

  1. Detect the chained gate pairs that share a shifted bit.
  2. Add MILP constraints: when the difference pattern is (1,0,1) on (a,b,c), force the output difference of a AND b to equal that of b AND c.
  3. Count such a correlated pair as a single active gate by subtracting the indicator variables in the objective; chains are set up so two overlapping correlations cannot both be claimed.
  4. Check the resulting trail and compute its probability outside the solver, since a minimum-gate trail need not minimize the true probability.

Example

A 338-round trail activates 76 AND gates of which 12 form correlated pairs, so the refined count is 76 - 12 = 64 and the trail is expected to hold with probability about 2 to the minus 64.

What to watch for

Only first-order correlations of this repeated shape are modelled, so some trails can still be globally inconsistent; the model is a better measuring stick, not an exact one.

Useful background: Why counting active AND gates understates the risk.

Related ideas

  • Keccak: conditional cube attacks control nonlinear gates jointly in a similar spirit

Papers

Why counting active AND gates understates the risk

Differential cryptanalysis tracks a difference (an XOR flip) through the cipher: pick an input difference, follow it round by round, and hope the output difference appears far more often than random chance. In TinyJAMBU an AND gate whose input has a difference flips its output with probability one half, so the designers used an automated Mixed Integer Linear Programming (MILP) search to minimize the number of active AND gates and read off a trail probability as 2 to the minus that count.

Why it is useful

The paper shows this counting rule can be wrong in both directions, because the AND gates are not independent events: the same register bit reaches several AND gates as the state shifts.

How it works

  1. Treat each active AND gate as an independent coin flip costing a factor of 2, which is fast to search but ignores how gates share input bits.
  2. The result can be an impossible trail that no real pair ever follows, or a real trail that is much more likely than the count says.
  3. Building the exact consistency conditions into the search, as was done for SIMON, keeps only valid trails but becomes far too slow to find the best one.
  4. The designers counted 80 active gates for a claimed 2 to the minus 80 trail over the full 384 rounds; with dependencies included, no such trail exists.

What to watch for

An under-counted probability is the dangerous case, because a cipher can look safer than it is; the paper answers with a model that is cheap enough to run and accurate enough to trust on the dominant effect.

Useful background: The TinyJAMBU keyed permutation: one NAND gate per round.

Related ideas

  • SIMON: the block cipher family whose exact MILP trail models are cited as accurate but slow

Papers

Integral and division-property methods

Integral distinguishers and division-property techniques.

Division property

The division property tracks monomial propagation to search for integral distinguishers.

Papers

Linear cryptanalysis

Linear approximations, correlations and linear hulls.

A linear distinguisher from biased samples

The second attack: replace every AND gate by zero, which turns the cipher into a linear one, and derive fixed XOR combinations of keystream bits that equal a sum of leftover noise bits; because that sum is biased, counting samples separates the cipher from randomness.

Why it is useful

A distinguisher proves the keystream is not random without recovering anything, and for Bivium it needs only about 2 to the power 32 samples, cheap enough that the authors ran it and confirmed the predicted bias.

How it works

  1. Assume all AND terms are zero; the resulting linear system on T0 has rank 93 instead of 96 for Trivium, leaving sampling equations of the form: XOR of selected state bits equals a noise variable.
  2. The noise is a sum of random AND gates, so its bias shrinks with the number of gates: about 2 to the power minus 72 for Trivium, giving 2 to the power 144 work, but only 2 to the power minus 16 for Bivium, giving 2 to the power 32.
  3. An alternative approximation writes each AND as a linear combination of its inputs plus noise with bias one half, but searches for better combinations stalled.

What to watch for

Distinguishing recovers neither key nor state, and the Trivium version at 2 to the power 144 is far beyond exhaustive search; only the Bivium case is practical, and treating several samples jointly gave no significant gain.

Useful background: Trivium and Bivium: the structure under attack.

Papers

Differential-linear cryptanalysis

Differential-linear cryptanalysis combines a differential segment with a linear approximation.

Papers

Refined linear cryptanalysis and the bias of the tag

Linear cryptanalysis looks for a linear expression, an XOR of chosen plaintext, ciphertext or tag bits, whose value is biased, meaning it equals 0 noticeably more or less often than half the time. The same chaining idea refines the search: because (a AND b) XOR (b AND c) simplifies to b AND (a XOR c), that expression can only be approximated well by a small set of linear functions.

Why it is useful

Cutting the wrong approximations out of the search finds biases the simple model misses, and the tag of TinyJAMBU is a natural target because it is squeezed in two 32-bit halves.

How it works

  1. Model each AND gate as linearly approximated by its inputs, then add constraints that forbid the approximations a chained pair cannot actually achieve.
  2. After finding a trail, evaluate the true correlation of the target expression with a quadratic Boolean function rather than trusting the gate count.
  3. Collect several trails with the same input and output masks; their signs decide whether they reinforce or cancel, and the signs depend on the key.
  4. For the tag, combine trails by summing squared correlations, which for the best 384-round trail cluster suggests an expected bias near 2 to the minus 38.9.

Example

For 256 rounds the designers reported a bias of 2 to the minus 12; the refined search gives 2 to the minus 10, and experiments confirmed roughly a quarter of the 1000 keys tested showed the larger bias while the rest stayed at the smaller one.

What to watch for

The quadrature estimate assumes independent random subkeys, which TinyJAMBU does not have, so it is an approximation; the key-dependent regime is real (about a quarter of tested keys showed the larger bias) but the existence of weak keys is left open.

Useful background: Refined differential trails with correlated AND gates, TinyJAMBU.

Related ideas

  • TinyJAMBU: the scheme whose tag bias is measured

Papers