Chapter 22 of Trappe & Washington: bilinear pairings on a supersingular curve and what one extra operation makes possible. Covers the five facts and Assumption (A), why a pairing must be computable from coordinates rather than defined by bilinearity, the MOV attack reducing curve discrete logs to a field, Joux's one-round tripartite Diffie-Hellman, Boneh-Franklin identity-based encryption with its inherent key escrow, BLS signatures and the Zhang-Safavi-Naini-Susilo variation, Hess identity-based signatures, and Boneh-Di Crescenzo-Ostrovsky-Persiano encrypted keyword search — all derived from the single identity that moves a secret across the pairing.
Subject: Cryptography · 66 slides · diagram-first lesson
Open the interactive version of this deck
Title
Cryptography · Chapter 22
One extra operation on an elliptic curve, and problems that were impossible become routine
Objectives
Chapter 21 used curves as a drop-in replacement for the integers mod p. This chapter uses something curves have that ordinary groups do not: a bilinear pairing — and it buys constructions with no counterpart anywhere else.
Figure (svg): The pairing as a machine taking two curve points and returning a root of unity, with the bilinearity rule beneath.
Warm-up
Every public-key system so far has used a group with one operation. Diffie-Hellman gives two parties a shared secret; getting three parties to agree takes two rounds of messages.
Discussion prompt
Suppose the group had a second operation that multiplied exponents. What would become possible?
Hint: Write down what a map ẽ with ẽ(aP, bQ) = ẽ(P, Q)^ab would let you compute.
Answer:
Two secrets could be combined by someone who knows neither. Given aP and bP, anyone can form ẽ(aP, bP) = ẽ(P, P)^ab — a value that in an ordinary group requires knowing a or b.
So three-party agreement collapses to one round. Each person publishes their point; each pairs the other two and raises to their own secret; all three land on ẽ(P, P)^abc.
And a secret could be moved from one side to the other. ẽ(sX, Y) = ẽ(X, sY), so a key masked with s on one input is interchangeable with the same mask on the other — without anyone knowing s. That single identity is the engine of identity-based encryption.
The catch, and it is severe: the map must be computable from the points alone. Defining it by picking a value and extending bilinearly is useless, because evaluating it would require solving a discrete logarithm.
Such a map exists on certain curves — a modified Weil pairing — and finding a use for it rather than an attack took from 1993 to 2000.
Section
Section 22.1 · pp. 425-427
Concept
The chapter could be done for any cyclic group of prime order, but the examples that matter come from curves, so one setting is fixed throughout.
Let p be a prime of the form 6q − 1 with q also prime, and let E be y² ≡ x³ + 1 (mod p).
Then E has exactly p + 1 = 6q points, and there is a point P₀ ≠ ∞ with qP₀ = ∞ — a subgroup of prime order q. Taking a random point P, with very high probability 6P ≠ ∞ and 6P is a multiple of P₀, so finding a suitable generator is easy.
The pairing ẽ maps pairs of multiples of P₀ to qth roots of unity, and satisfies
\[ \tilde e(aP_0, bP_0) = \tilde e(P_0, P_0)^{ab} \]
which implies ẽ(aP, bQ) = ẽ(P, Q)^{ab} for all P, Q that are multiples of P₀. The roots of unity live in the finite field with p² elements.
Figure (svg): The pairing as a machine taking two curve points and returning a root of unity, with the bilinearity rule beneath.
Concept
Everything in the chapter rests on this list, and it is worth knowing which parts are elementary and which are deep.
Facts (3), (4) and (5) together are deep. ẽ is a modification of the Weil pairing from the theory of elliptic curves. The ordinary Weil pairing has e(P₀, P₀) = 1, which would make it useless here; this version is modified using special properties of E to get (5).
Assumption (A) — Given a random point P ≠ ∞ and a random qth root of unity ω ≠ 1, it is computationally infeasible to find Q with ẽ(Q, P) = ω, or Q′ with ẽ(P, Q′) = ω. Believed true for large enough p, and not known.
Figure (svg): The five facts about the supersingular curve underlying every construction in the chapter.
Socratic
It seems easy to build a bilinear map: choose a random qth root of unity ω, declare ẽ(P₀, P₀) = ω, and define ẽ(aP₀, bP₀) = ω^{ab}.
Discussion prompt
Why does this not work?
Hint: Ask what you need to know in order to evaluate it.
Answer:
Because evaluating it requires a and b. Given two points P and Q, they are certainly multiples of P₀ — but finding which multiples is exactly the elliptic curve discrete logarithm problem.
So the definition is well posed and uncomputable. The map exists as a mathematical object and no algorithm can evaluate it in reasonable time, which makes it useless for cryptography.
Fact (4) is therefore the whole content. The real ẽ is computed directly from the coordinates of P and Q, by an algorithm — Miller's — that never learns the exponents. That is what makes bilinearity usable rather than merely true.
And it explains the historical timing. Bilinear pairings were known to number theorists for decades; what turned them into cryptography was efficient evaluation plus somebody asking what they were good for besides breaking things.
A transferable lesson: in cryptography a property is only as useful as the algorithm that realises it, and 'there exists a function such that…' is not a construction until the function can be evaluated.
Figure (svg): Why the pairing cannot be defined by choosing a value and extending by bilinearity.
Worked example
The identities used repeatedly through the chapter, all immediate from the definition.
ẽ(aP, Q) = ẽ(P, Q)ᵃ — a scalar on either input comes out as an exponent
Why: Set b = 1 in the bilinearity rule.
ẽ(aP, Q) = ẽ(P, aQ) — a scalar can be moved from one input to the other
Why: Both equal ẽ(P, Q)ᵃ. This is the identity that makes identity-based encryption work.
ẽ(aP, bQ) = ẽ(P, Q)^{ab} — two scalars multiply
Why: Which is what lets one person combine two other people's secrets, and is why Joux's protocol needs only one round.
ẽ(P + Q, R) = ẽ(P, R)·ẽ(Q, R) — additive in each argument
Why: Point addition on the left becomes multiplication on the right, which is what makes the Hess signature's cancellation work.
Verify: so the pairing translates between the additive group on E and the multiplicative group of roots of unity
Why: It is a homomorphism in each variable separately. Every construction in the chapter is that translation applied once, and the trick is always to move a secret from a place where you cannot use it to a place where you can.
Figure (svg): The pairing as a machine taking two curve points and returning a root of unity, with the bilinearity rule beneath.
Concept
E is an example of a supersingular elliptic curve — one where the number of points is congruent to 1 mod p.
They were once attractive, because arithmetic on them is fast.
Then the MOV attack showed their discrete logarithm problem is only slightly harder than the classical one mod p — so they offered no security advantage while being computationally slower than plain modular multiplication. They fell out of favour entirely.
And then pairings became constructive, and supersingular curves were the ones where ẽ could be computed quickly. They returned, with one new requirement: p must now be large enough that discrete logs in GF(p²) are also infeasible.
A useful reminder about how this subject moves. The very property that made these curves worthless — a pairing into a small field — is the property that made them essential. Structure is not good or bad on its own; what matters is whether anyone has found a use for it yet.
Figure (svg): The changing status of supersingular curves: fast, then broken by MOV, then essential once pairings became constructive.
Prediction
Predict first
In which field do those roots of unity live?
Correct: GF(p²), the field with p² elements
The exponent 2 is called the embedding degree, and it is the single most important parameter of a pairing-friendly curve.
Low embedding degree makes pairings fast and the MOV attack effective. High embedding degree makes MOV useless and the pairing too slow to compute. Pairing-based cryptography lives in the narrow band where both are manageable — typically degree 6 to 12 for modern curves.
Which is why supersingular curves mod p, with degree 2, need such large p. The field GF(p²) must itself resist index calculus, so p ends up substantially larger than a non-pairing curve would need.
Why: The qth roots of unity for this curve lie in the field with p² elements. That fact is what makes the MOV attack effective here — the target field is small, only twice the bit length of p, so index calculus in it is feasible.
Section
Section 22.2 · p. 427
Concept
Menezes, Okamoto and Vanstone found the destructive use first, and it is three lines long.
Suppose Q = kP₀ and we want k — the elliptic curve discrete logarithm problem. Apply the pairing:
\[ \tilde e(Q, P_0) = \tilde e(kP_0, P_0) = \tilde e(P_0, P_0)^k \]
So k can be found by solving a discrete logarithm in the field with p² elements rather than on the curve. And field discrete logarithms have index calculus, which is subexponential — usually much easier.
Both sides are computable. ẽ(Q, P₀) is evaluated from coordinates by fact (4), and ẽ(P₀, P₀) likewise. So the reduction is effective, not merely theoretical.
Figure (svg): The MOV attack moving an elliptic curve discrete log into a finite field where index calculus applies.
Worked example
The reduction works in theory for any curve. Whether it is useful depends on one number.
The pairing takes values in some extension field GF(p^k)
Why: k is the embedding degree — the smallest k with q dividing pᵏ − 1.
For supersingular curves mod p, k = 2
Why: So the target field has p² elements, about twice the bit length of p.
For a randomly chosen curve, k is typically enormous
Why: Often comparable to q itself, so the target field has astronomically many elements.
Index calculus in GF(p^k) costs subexponential time in the size of that field
Why: Which is a saving when k = 2 and hopeless when k is huge.
Verify: so MOV is fatal for supersingular curves and irrelevant for random ones
Why: This is why the standard curves of Chapter 21 are unaffected, and it is also why every pairing-friendly curve must be checked: a low embedding degree is required for the pairing to be computable and is exactly what MOV needs.
Figure (svg): The MOV attack moving an elliptic curve discrete log into a finite field where index calculus applies.
Anomaly
The reduction is valid for any curve, so it can be run against a standardised curve like P-256.
Predict first
What happens?
Correct: The target field is astronomically large, so the reduction is valid and useless
A valid reduction is not automatically an attack. It has to move the problem somewhere easier, and here it moves it somewhere very much harder.
The check is part of curve standardisation. Any proposed curve is tested for a small embedding degree, and one is rejected if k is small — precisely the check that eliminates supersingular curves from general use.
And note the tension pairing-based cryptography lives with. It needs a small embedding degree so the pairing can be computed, which means it always operates in the regime where MOV bites. The response is to enlarge p until the target field is safe too — paying in performance for a structure it cannot do without.
Why: The pairing exists and the reduction is mathematically correct, but P-256's embedding degree is enormous — the target field has around 2^(256·k) elements for very large k. Index calculus in a field that size is far harder than attacking the curve directly, so the reduction converts an easy problem into an impossible one.
Definition probe
The same map appears as an attack and as a construction.
Sort into buckets
Sort each consequence of ẽ existing on a curve.
Section
Section 22.3 · pp. 428-429
Concept
Diffie-Hellman extends to three people, but it costs an extra round.
Six messages in two rounds, and the same protocol works with the curve substitution from Chapter 21, giving abcP₀.
The second round is the cost. Nobody can combine two secrets without holding one of them, so the partial results have to travel a second time — which matters when the parties are not simultaneously online.
Figure (svg): Two-round tripartite Diffie-Hellman compared with Joux's single round using a pairing.
Concept
In 2000, Joux showed the pairing removes the second round entirely.
The pairing absorbs two secrets at once. ẽ(bP₀, cP₀) = ẽ(P₀, P₀)^{bc} is computable by anyone, and Alice supplies the third exponent herself.
This was the first constructive use of a pairing, and the paper that created the field — before it, pairings in cryptography meant the MOV attack and nothing else.
Figure (svg): Two-round tripartite Diffie-Hellman compared with Joux's single round using a pairing.
Worked example
One line each, and the symmetry is the whole argument.
Alice holds a and sees B = bP₀ and C = cP₀
Why: She computes ẽ(B, C)ᵃ = ẽ(bP₀, cP₀)ᵃ.
By bilinearity, ẽ(bP₀, cP₀) = ẽ(P₀, P₀)^{bc}
Why: So her result is ẽ(P₀, P₀)^{bca}.
Bob computes ẽ(A, C)ᵇ = ẽ(P₀, P₀)^{acb}
Why: And Carlos computes ẽ(A, B)ᶜ = ẽ(P₀, P₀)^{abc}.
\[ \tilde e(P_0, P_0)^{abc} \text{ — the same for all three, since the exponents commute} \]
Verify: one broadcast each, and no second round
Why: Compare the classical version, where Alice could not produce α^{bc} because combining two secrets required holding one. The pairing lets a fourth party — anyone at all — combine two published points, and each participant only needs to add their own exponent.
Figure (svg): Two-round tripartite Diffie-Hellman compared with Joux's single round using a pairing.
Concept
Eve sees E and the points P₀, aP₀, bP₀, cP₀, and must compute ẽ(P₀, P₀)^{abc}.
Bilinear Diffie-Hellman Problem — Given P₀, aP₀, bP₀ and cP₀, compute ẽ(P₀, P₀)^{abc}. Its difficulty is not known.
One relation is known, and it is the wrong direction. If Eve can solve the Computational Diffie-Hellman problem from Section 10.4, she uses P₀, aP₀ and bP₀ to get abP₀, then computes ẽ(abP₀, cP₀) = ẽ(P₀, P₀)^{abc}.
So the Bilinear problem is no harder than Computational Diffie-Hellman. It could be strictly easier, and nobody has shown otherwise.
Which is the honest status of the whole chapter. Its constructions rest on assumptions that are newer and less studied than factoring or plain discrete logs — a real consideration when choosing whether to deploy one.
Figure (svg): Two-round tripartite Diffie-Hellman compared with Joux's single round using a pairing.
Prediction
Predict first
What would be needed for four parties in one round?
Correct: A trilinear map, taking three inputs — which is not known to exist efficiently
This is one of the more striking limits in the subject. The jump from two to three parties needed a deep object from number theory; the jump from three to four has resisted twenty-five years of effort.
Multilinear maps would give far more than group key agreement — indistinguishability obfuscation among other things — which is why so much effort has gone into them, and why the repeated breaks are so notable.
In practice four parties use two rounds of Joux, or a tree of pairwise exchanges. The one-round property simply does not extend.
Why: The pairing combines exactly two published secrets, and each party adds one of their own — three in total. Four would require a map combining three inputs at once, and constructing secure efficient multilinear maps is a famous open problem: every proposed candidate has been attacked.
Section
Section 22.4 · pp. 429-432
Concept
In an ordinary public-key system, Alice looks up Bob's key in a directory before encrypting. That step needs authentication: perhaps Eve modified the directory and the key listed for Bob is hers.
Shamir suggested in 1984 that it would be better if Bob's public identification information — his email address, say — were his public key. Then there is nothing to look up and nothing to substitute.
The system was finally designed in 2001 by Boneh and Franklin, seventeen years later, and it needed pairings.
Authentication does not disappear, it moves. Each user must be authenticated once, when the trusted authority issues their private key — and that is a single enrolment rather than a check on every message.
And there is a genuinely new capability hidden here: Alice can encrypt to Bob before Bob has any key at all. His address is enough, and he collects the private key later. No conventional system can do that.
Figure (svg): Boneh-Franklin identity-based encryption: the trusted authority issues a private point derived from an identity string.
Concept
Two public hash functions are needed.
Arthur, the trusted authority, does three things. He chooses a secret integer s once and for all and publishes P₁ = sP₀. For each user he computes
\[ D_{\text{User}} = s \, H_1(\text{ID}) \]
and sends it over a secure channel. He does not need to store it, so he discards it.
Public: E, p, P₀, P₁, H₁, H₂. Secret: s, known only to Arthur, and each D_User, known only to that user.
Figure (svg): Boneh-Franklin identity-based encryption: the trusted authority issues a private point derived from an identity string.
Concept
Alice wants to send an n-bit message m to bob@computer.com. She needs no directory and no prior contact.
Bob receives (U, v) and computes h = ẽ(D_Bob, U), then recovers m = v ⊕ H₂(h).
Notice what Alice used: only public values and Bob's address. Notice what Bob used: only his own private point. Neither knows s.
Figure (svg): Boneh-Franklin identity-based encryption: the trusted authority issues a private point derived from an identity string.
Worked example
One application of bilinearity, and the book calls it the main step.
Bob computes h = ẽ(D_Bob, rP₀), where D_Bob = s·H₁
Why: Writing H₁ for H₁(bob@computer.com).
The scalar s comes out as an exponent: ẽ(sH₁, rP₀) = ẽ(H₁, P₀)^{sr}
Why: By bilinearity in the first argument.
And it can be put back on the other input: ẽ(H₁, P₀)^{sr} = ẽ(H₁, sP₀)ʳ
Why: Which is ẽ(H₁, P₁)ʳ = gʳ — exactly what Alice used.
\[ t \oplus H_2(h) = m \oplus H_2(g^r) \oplus H_2(g^r) = m \]
Verify: the secret s moved from Bob's private point onto Alice's public P₁ without anyone knowing s
Why: That is the trick, and the book says so explicitly: almost all cryptographic uses of pairings move from one masking of the secret to another. Once you see this step, the signature and keyword-search schemes read as variations on it.
Figure (svg): The single algebraic step that makes identity-based encryption decrypt: bilinearity moves the secret across the pairing.
Concept
The convenience has a price, and it is structural rather than a flaw to be patched.
Arthur knows s, so he can compute D_User for every user and read every message. The book states it plainly: if Eve obtains s she can read every email.
This is key escrow by construction. It is not an implementation weakness — the ability to derive a private key from an identity string is precisely the ability to derive everyone's private key.
Two further requirements follow. Since P₁ = sP₀, the security of s depends on curve discrete logs being infeasible. And since the ciphertext contains rP₀, an Eve who can find r computes gʳ and recovers m directly. So p must be large enough for both.
Which shapes where IBE is used. It fits closed organisations that already have a central IT authority and may actively want message recovery. It does not fit settings where users must be protected from the operator — which is most of the open internet, and is why IBE never displaced certificates.
Figure (svg): The cost of identity-based encryption: the trusted authority can derive every user's private key.
Socratic
In IBE the trusted authority can decrypt everything.
Discussion prompt
When is that a feature, and what would it take to reduce it?
Hint: Consider who deploys the system and why.
Answer:
A corporation often wants it. Messages must survive an employee leaving, regulators may require retained access, and the organisation already controls the mail server. Escrow is the recovery mechanism, not the threat.
It is fatal where the operator is the adversary — journalists, dissidents, or any system whose promise is that the provider cannot read the traffic. Signal cannot be built on IBE.
The standard mitigation is to split s across several authorities, using Chapter 17's secret sharing: each holds a share, each issues a partial private key, and the user combines them. Now t authorities must collude, which is a real improvement and not the same as nobody being able to.
Certificateless cryptography goes further, combining the authority-derived key with a user-chosen secret so the authority alone cannot decrypt — at the cost of reintroducing something the user must publish, which was the thing IBE set out to remove.
The honest summary is that this is a trade, not a defect. Removing the directory and removing the escrow are in tension, and every scheme in this space picks a point on that line.
Figure (svg): The cost of identity-based encryption: the trusted authority can derive every user's private key.
Anomaly
After sending each user their private point, Arthur deletes it and keeps only s.
Predict first
Does deleting the private keys protect the users?
Correct: Barely — s is still there, and s regenerates every private key on demand
Compare Chapter 19's Feige-Fiat-Shamir setup, where Arthur discards p, q and the secrets, and a breach genuinely yields nothing — because there the secrets are not recoverable from what remains.
The difference is which direction the derivation runs. In FFS the authority destroys the trapdoor; in IBE the trapdoor is the master key and must be kept to serve new users.
So the deletion is still worth doing — it reduces what a partial compromise exposes — but the real defence is hardware protection of s, or splitting it across authorities. Discarding the derived keys is hygiene, not security.
Why: D_User = s·H₁(ID) is derived, not stored. Anyone with s and a public identity string recomputes it instantly, so discarding the derived keys removes almost nothing. The one secret worth protecting is s.
Faded example
Four blanks.
Fill in the blanks
Arthur publishes P₁ = sP₀ and gives Bob the point D_Bob = s·H₁(ID). Alice computes g = ẽ(H₁(ID), P₁), picks a random r, and sends (rP₀, m ⊕ H₂(gʳ)). Bob computes ẽ(D_Bob, rP₀), which equals gʳ because the scalar s can be moved to the other argument.
Why: The last blank is the whole scheme. ẽ(sX, Y) = ẽ(X, sY) means a secret applied to one input is interchangeable with the same secret applied to the other — and neither party has to know it.
Section
Section 22.5 · pp. 432-436
Concept
Boneh, Lynn and Schacham's scheme is the shortest signature in wide use, and the whole thing fits on a slide.
Setup: a supersingular curve E and point P₀, plus a public hash H mapping binary strings to multiples of P₀ — with the same care as before, so that nobody can find k with H(b) = kP₀.
Alice chooses a secret integer a once and publishes K_Alice = aP₀.
Her signature on m is a single point:
\[ S = a \, H(m) \]
Bob verifies by checking ẽ(S, P₀) =? ẽ(H(m), K_Alice). No randomness, no nonce, and nothing to reuse — which removes at a stroke the failure mode that has appeared in Chapters 13, 19 and 21.
Figure (svg): The BLS signature: one point as the signature, verified by comparing two pairings.
Worked example
Both directions in a few lines.
Correctness: ẽ(S, P₀) = ẽ(aH(m), P₀)
Why: Substituting the signature.
Bilinearity pulls the a out: = ẽ(H(m), P₀)ᵃ
Why: And then puts it on the other input: = ẽ(H(m), aP₀).
Which is ẽ(H(m), K_Alice) — the right-hand side
Why: So an honest signature always verifies. The same move-the-scalar step as in IBE.
Forgery: Eve wants S with ẽ(S, P₀) equal to a known quantity
Why: H(m), K_Alice and P₀ are all fixed once m is chosen, so the right-hand side is determined.
Verify: that is exactly Assumption (A), which says finding such an S is infeasible
Why: Note what the security rests on: not a reduction to discrete logs, but the newer pairing assumption. That is the standing caveat on everything in this chapter.
Figure (svg): The BLS signature: one point as the signature, verified by comparing two pairings.
Concept
BLS needs a hash whose values are points, which is less natural than an ordinary hash. This variation removes that requirement.
Let H be a standard hash such as SHA-3 or SHA-256, with its output read as an integer. Alice's key is unchanged: K_Alice = aP₀. But the signature becomes
\[ S = \bigl(H(m) + a\bigr)^{-1} P_0 \]
where the inverse is taken modulo q, the order of P₀.
Verification: ẽ(H(m)P₀ + K_Alice, S) =? ẽ(P₀, P₀).
Why it works: H(m)P₀ + K_Alice = (H(m) + a)P₀, and pairing that with (H(m) + a)⁻¹P₀ multiplies the exponents to 1, giving ẽ(P₀, P₀) exactly. Forgery again reduces to Assumption (A).
Figure (svg): The BLS signature: one point as the signature, verified by comparing two pairings.
Worked example
Worth doing carefully, because the inverse is modulo q and the points live on E.
The left argument is H(m)P₀ + K_Alice = H(m)P₀ + aP₀
Why: Point addition, which corresponds to adding the multipliers: = (H(m) + a)P₀.
The right argument is S = (H(m) + a)⁻¹P₀
Why: A multiple of P₀ by the inverse of that same quantity mod q.
Pairing them: ẽ((H(m)+a)P₀, (H(m)+a)⁻¹P₀) = ẽ(P₀, P₀)^{(H(m)+a)(H(m)+a)⁻¹}
Why: Both scalars come out as exponents and multiply.
The product is 1 modulo q, and ẽ(P₀, P₀) is a qth root of unity
Why: So raising it to anything ≡ 1 (mod q) leaves it unchanged.
Verify: the left side equals ẽ(P₀, P₀), which is the verification condition
Why: Note the step that needed care: the exponent is only 1 modulo q, and it works because ẽ(P₀, P₀)ᑫ = 1. The same subtlety as Chapter 21's k⁻¹k = 1 + tN with NA = ∞.
Figure (svg): The BLS signature: one point as the signature, verified by comparing two pairings.
Concept
Verifying a BLS signature means looking up K_Alice on a web page and trusting it — the directory problem again, on the signing side. Hess's scheme removes it.
Setup is exactly IBE's. H₁ maps strings to multiples of P₀; H₂ is a standard hash. Arthur picks s, publishes P₁ = sP₀, and gives each user D_User = s·H₁(ID).
To sign m, Alice:
Bob verifies by computing v₁ = ẽ(H₁(ID_Alice), P₁)⁻ʰ, then v₂ = v₁ · ẽ(U, P₀), and accepting if h = H₂(m ‖ v₂). He needs only Alice's identity string.
Figure (svg): Hess identity-based signatures: the verifier needs only the signer's identity string.
Worked example
The cancellation is the interesting part.
v₁ = ẽ(H₁, P₁)⁻ʰ = ẽ(H₁, P₀)^{−hs}
Why: Since P₁ = sP₀ and the scalar comes out as an exponent.
Move the s onto the first argument: = ẽ(sH₁, P₀)⁻ʰ = ẽ(D_Alice, P₀)⁻ʰ
Why: The same move-the-secret step, now used by the verifier, who does not know s.
So v₁ = ẽ(−h·D_Alice, P₀)
Why: Pulling the −h inside the first argument.
Then v₂ = v₁ · ẽ(U, P₀) = ẽ(−h·D_Alice + U, P₀)
Why: Using additivity in the first argument — the product of pairings is the pairing of the sum.
And U = h·D_Alice + P, so −h·D_Alice + U = P
Why: The private point cancels exactly.
Verify: v₂ = ẽ(P, P₀) = r, so H₂(m ‖ v₂) = H₂(m ‖ r) = h
Why: Bob has reconstructed r without ever learning P, D_Alice or s. Eve's problem is to find U with ẽ(U, P₀) equal to a determined quantity — Assumption (A) once more.
Figure (svg): Hess identity-based signatures: the verifier needs only the signer's identity string.
Notation
Three lines, and each uses a different property of the pairing.
Annotate
On: \( v_1 = \tilde e(H_1, P_1)^{-h}, \quad v_2 = v_1 \cdot \tilde e(U, P_0), \quad h \overset{?}{=} H_2(m \, \| \, v_2) \)
Every line is the same identity ẽ(aX, Y) = ẽ(X, aY) applied in a different direction. Learn that one move and the chapter's schemes stop needing to be memorised.
Definition probe
Four schemes from the course.
Sort into buckets
Sort each by what the verifier must obtain and trust.
Section
Section 22.6 · pp. 436-438
Concept
Alice runs a corporation. Employees send in reports with sensitive information, and the reports must be routed to departments by subject.
Keywords could do the routing, but the keywords are sensitive too. So they must be encrypted — and if the person sorting the reports can decrypt them, that person sees everything.
What is wanted: an authorised searcher can test whether a particular keyword is present, learning only yes or no, and nothing about any other keyword or about the document.
Boneh, Di Crescenzo, Ostrovsky and Persiano solved it with pairings. Alice picks a secret a and publishes P₁ = aP₀. For each keyword w a department may search, she computes the trapdoor
\[ T_w = a \, H_1(w) \]
and sends it over a secure channel to that department alone.
Figure (svg): Searchable encryption: a department holds a trapdoor for one keyword and can test for it without decrypting anything.
Concept
Daphne writes a report and attaches encrypted keywords.
A searcher holding T_w looks at an attached pair [A, b] and checks
\[ H_2\bigl(\tilde e(T_w, A)\bigr) \overset{?}{=} b \]
Yes means w is a keyword for that document; no means it is not. The searcher never decrypts anything, and can only test the keywords for which they hold a trapdoor.
Figure (svg): Searchable encryption: a department holds a trapdoor for one keyword and can test for it without decrypting anything.
Worked example
Correctness first, then uniqueness.
If [A, b] encrypts w, then A = rP₀ and b = H₂(t) with t = ẽ(H₁(w), rP₁)
Why: By construction.
The searcher computes ẽ(T_w, A) = ẽ(a·H₁(w), rP₀)
Why: Substituting the trapdoor.
Bilinearity: = ẽ(H₁(w), rP₀)ᵃ = ẽ(H₁(w), a·rP₀) = ẽ(H₁(w), rP₁)
Why: The a moves from the first argument to the second and becomes part of P₁ — the same step as everywhere else in the chapter.
So ẽ(T_w, A) = t, and H₂ of it is b. The test passes
Why: Correctness done.
Verify: and a pair passes for at most one keyword
Why: If w′ is a different keyword, collision resistance of H₁ gives T_w′ ≠ T_w, hence ẽ(T_w′, A) ≠ ẽ(T_w, A), and collision resistance of H₂ makes their hashes differ. So even if the same r were used for two keywords, only one of them matches b.
Figure (svg): Searchable encryption: a department holds a trapdoor for one keyword and can test for it without decrypting anything.
Concept
A different r is required for every encryption of a keyword. Otherwise the encryption of that keyword is always the same string, and the scheme leaks by frequency.
Which is Chapter 2's attack in a modern setting. Someone notices that a particular encrypted keyword appears on a third of all reports, and guesses what it must be. Deterministic encryption of a low-entropy value is never safe, whatever the primitive.
A second application the book gives: a medical researcher wants to know how many patients at a hospital were treated for disease X. The administration gives out only T_X. The researcher searches encrypted records for X and learns nothing about gender, age, race or any other diagnosis.
The access-control granularity is what makes it valuable. Authorisation is per keyword, not per document and not per user — the administration decides exactly which questions can be asked, and the answer to any other question is unavailable rather than merely forbidden.
This is the ancestor of a large modern field. Searchable symmetric encryption and encrypted databases descend from it — and so does a long line of work showing that access patterns and result counts leak more than the designers expected.
Figure (svg): Searchable encryption: a department holds a trapdoor for one keyword and can test for it without decrypting anything.
Real world
For a long time pairings were a research topic. Then they were deployed at scale.
Discussion prompt
Name three places pairing-based cryptography is running in production.
Hint: Blockchains, aggregate signatures, and privacy-preserving protocols.
Answer:
Ethereum's consensus layer uses BLS signatures. Hundreds of thousands of validators sign each block, and BLS signatures aggregate: many signatures on the same message combine into one, verified against the combined public keys in a single pairing check. No other scheme in this course can do that, and it is what makes the validator set possible.
zk-SNARKs. Groth16 and its relatives — used by Zcash and by many rollups — are pairing-based. The verification of a proof is a handful of pairing evaluations, which is what makes proofs constant-size and cheap to check on-chain.
Threshold and distributed signing. BLS's linearity makes threshold signatures unusually clean: shares combine by addition, so Chapter 17's Shamir scheme drops straight in. Randomness beacons such as drand are built on exactly this.
Identity-based encryption itself found a narrower niche, mostly in closed enterprise messaging, for the escrow reasons discussed. The chapter's most influential idea turned out to be the signature scheme rather than the encryption one.
And the curves changed. Nobody uses supersingular curves mod p any more — BN and BLS12-381 curves have higher embedding degrees, giving the same pairing with much better security margins. The mathematics of the chapter is exactly right; the parameters are all different.
Error analysis
From a design document for an encrypted document store.
Annotate
The last is the one specific to this chapter: a curve that would be adequate without a pairing is inadequate with one, because the pairing hands the attacker a route into a small field.
Trade off
Two answers to 'how does Alice get Bob's public key'. Fill the blanks.
Comparison matrix
| Certificates (PKI) | Identity-based encryption | |
|---|---|---|
| What Alice needs | Bob's certificate and a trust chain | Bob's identity string and the public parameters |
| Can encrypt before enrolment | no | yes |
| Who can read messages | only Bob | Bob and the trusted authority |
| Revocation | revocation lists, OCSP | awkward — identities cannot be revoked, so keys carry expiry dates in the ID |
| Trust concentrated in | certificate authorities, many of them | one authority holding s |
Revocation is the underrated row. An IBE identity is permanent, so the usual fix is to bake a date into it — bob@x.com‖2026-09 — and re-issue keys each period, which quietly reintroduces a per-period enrolment.
Matching
All four reduce to Assumption (A), but in different shapes.
Match the pairs
Why: The first and third are Assumption (A) directly — invert the pairing at a known target. The second and fourth are bilinear Diffie-Hellman: combine two published multiples of P₀ into a pairing value involving both secrets. Four schemes, two underlying problems, and neither is known to be as hard as anything older.
Discrimination
Five constructions from the course.
Sort into buckets
Sort each by whether a bilinear map is required.
Edge cases
Assumption (A) and the Bilinear Diffie-Hellman Problem underpin everything here.
Discussion prompt
How do they compare with factoring and ordinary discrete logs?
Hint: Consider age, scrutiny, and known relationships.
Answer:
They are much younger. Factoring has been studied since antiquity and seriously for fifty years; the bilinear assumptions date from 2000 and 2001.
And they are known to be no harder than what they sit above. The Bilinear Diffie-Hellman Problem reduces to Computational Diffie-Hellman, so it could be strictly easier. Nobody has shown it is not.
The curves have an unavoidable extra weakness. A pairing means MOV applies, so security is bounded by discrete logs in the extension field as well as on the curve — two problems instead of one, and the parameters must defeat both.
Progress in field discrete logs has bitten. Improvements to the number field sieve in small-characteristic and composite-degree fields forced the recommended parameters upward, and BN curves once thought to give 128-bit security were re-estimated at around 100. That is a real, recent adjustment.
So the honest summary: pairing-based schemes deliver capabilities nothing else does, on assumptions that are newer, less studied, and have already been revised once. For aggregation and zero-knowledge proofs the capability is worth it because there is no alternative. For plain encryption or signatures, where alternatives exist, the case is much weaker.
Ranking
Five things that can go wrong in a pairing deployment.
Put in order
Why: A leaked trapdoor lets someone test one keyword — the narrowest loss. One stolen D_User exposes that user's mail. Repeated r leaks keyword frequencies across the corpus, which is broader but statistical. A small prime breaks the curve for everyone, and s is worse still: it regenerates every private key past and future, so it compromises the entire system retroactively and cannot be repaired without re-issuing everything.
Constraint
A hospital wants encrypted internal messaging. Staff turn over frequently, records must remain accessible after someone leaves, and there is a central IT department.
Discussion prompt
Which system fits, and what would you specify?
Hint: Look at who the adversary is and who needs recovery.
Answer:
IBE fits this case unusually well. Addresses are stable and known, new staff can be sent encrypted mail before they have collected a key, and the escrow that disqualifies IBE elsewhere is here a requirement — the hospital must retain access to records when a doctor leaves.
Specify identity strings with a validity period baked in — 'dr.smith@hospital.org‖2026-Q3' — so keys expire naturally and departure is handled by not re-issuing. This is the standard answer to IBE's revocation problem.
Split s across several authorities using Shamir's scheme from Chapter 17, so that reading a mailbox requires a quorum rather than one administrator. That converts unilateral access into an auditable process without giving up recovery.
Use a modern pairing-friendly curve, not the chapter's supersingular one — BLS12-381 or similar, with an embedding degree high enough that MOV is irrelevant at reasonable parameter sizes.
And be explicit with users about what the system does not promise. Their messages are readable by a quorum of administrators. That is the design, and a system whose users misunderstand its guarantees is dangerous regardless of its cryptography.
Cost model
One equation generates every construction in the chapter.
Annotate
On: \( \tilde e(aP, bQ) = \tilde e(P, Q)^{ab} \)
Every scheme here is one of the first three readings. Recognising which one a new pairing-based paper is using is usually enough to follow its main construction.
Missing information
A paper presents a new pairing-based protocol with a security proof.
Discussion prompt
What should you check before believing it is deployable?
Hint: Proofs are relative to assumptions and models.
Answer:
Which assumption it reduces to. There is a large family — bilinear Diffie-Hellman, decisional variants, q-type assumptions that grow with the number of queries — and they are not equally believed. A q-type assumption is much weaker evidence than a standard one.
Whether the proof is in the random oracle model. Most of these schemes are, and the hash functions here are strong ones — H₁ must map onto curve points in a way nobody can invert or control.
Which curve and which parameters. Security estimates for pairing curves have been revised downward before, and a scheme quoting 128-bit security on a BN curve may be delivering closer to 100.
Whether the pairing is symmetric. The chapter uses ẽ(P, Q) with both inputs from one group, which is only available on supersingular curves. Efficient modern curves have asymmetric pairings with two different source groups, and a scheme written for a symmetric pairing may not transfer without modification.
And what it leaks outside the proof. Keyword search is proved secure and still leaks access patterns; the proof covers the ciphertexts, not the behaviour of the system around them.
Two truths and a lie
Two of these overstate it.
Eliminate the wrong options
Which statement is correct?
Survives elimination: a
Why: Both clauses are essential and they come from the same fact. Deriving a key from an identity is what removes the directory and what gives the authority universal access — you cannot have one without the other, which is why IBE is a good fit for organisations and a bad one for the open internet.
Commit first
A team deploys BLS signatures on BLS12-381 using a well-regarded library.
Predict first
What is the realistic failure?
Correct: A missing subgroup check on an untrusted input point, or a rogue-key attack on aggregation
Rogue-key attacks are the aggregation-specific hazard, and they are why every production BLS deployment requires a proof of possession at key registration — Ethereum's deposit contract includes exactly that.
Subgroup checks are the other. Pairing-friendly curves have structure that ordinary curves do not, and an input point that passes the curve equation may still be in a small or wrong subgroup.
The mathematics is not the risk here either. As in Chapter 21, the group is a solved problem and the danger has moved into validation and protocol composition.
Why: Pairing curves have large cofactors and a second source group, so a received point can lie in the wrong subgroup entirely — and subgroup checks are expensive, which tempts implementers to skip them. Aggregation adds a second class of bug: without proof-of-possession, an attacker registers a public key derived from others' keys and forges an aggregate signature they never signed.
Explain it
A colleague understands that gᵃ and gᵇ give a shared gᵃᵇ, and asks what is new.
Discussion prompt
Explain the added capability in terms they already have.
Hint: Ask what an outsider can compute in each case.
Answer:
In ordinary Diffie-Hellman, an outsider who sees gᵃ and gᵇ cannot compute gᵃᵇ. That is the whole security of the scheme, and it is also a limitation.
A pairing changes exactly that. Given aP and bP, anyone can compute ẽ(P, P)^{ab} — the combination is public.
Which sounds like a disaster and is not, because the pairing lands in a different place: a field element, not a group element. So it cannot be fed back in to continue the attack, and the original curve secrets stay hidden.
The gain is one free multiplication of exponents, once. Three people can each supply one exponent and reach the same value, and a secret can be moved from one side of an equation to the other by someone who does not know it.
The cost is that this also helps attackers — the same move turns a curve discrete log into a field discrete log — so pairing curves need larger parameters than ordinary ones. It is a genuine trade, not a free capability.
Figure (svg): The pairing as a machine taking two curve points and returning a root of unity, with the bilinearity rule beneath.
Explain it to yourself
In an ordinary system a public key is generated with its private key, together. In IBE the public key is an email address that existed first.
Discussion prompt
Explain how a private key can be produced for a public key nobody chose.
Hint: Something must be able to derive keys from arbitrary strings.
Answer:
Because the private key is derived, not generated. D_User = s·H₁(ID) exists for every possible string, whether or not anyone has asked for it, and the authority can compute it on demand.
So the key pair is created in the wrong order: the public part is fixed by the identity, and the private part is manufactured afterwards by someone holding a master secret.
That immediately implies escrow. Whatever can derive one user's private key from a public string can derive everyone's. There is no way to have the first property without the second.
And the pairing is what makes the derived key usable. Alice masks with ẽ(H₁(ID), P₁)ʳ and Bob unmasks with ẽ(D_User, rP₀); bilinearity makes these equal without either of them knowing s.
So the answer has two halves. A master secret makes the derivation possible, and the pairing makes the derived key work in an encryption scheme. Take away either and IBE does not exist — which is why Shamir could pose the problem in 1984 and nobody could solve it until 2001.
Figure (svg): The single algebraic step that makes identity-based encryption decrypt: bilinearity moves the secret across the pairing.
Pattern
Every construction in this chapter is one identity used once.
\[ \tilde e(aX, Y) = \tilde e(X, Y)^a = \tilde e(X, aY) \]
Joux's protocol is the one variation: rather than moving a secret, it combines two, and each party contributes the third. That is the other thing bilinearity permits, and between them the two readings account for the entire chapter.
And the recurring theme returns. The property that makes these constructions possible is the property that makes MOV work. Designers and attackers are using the same equation, and the parameters are chosen so that one wins.
Figure (svg): The pairing as a machine taking two curve points and returning a root of unity, with the bilinearity rule beneath.
Trap
The trap. Pairings enable things no other group can do — identity-based encryption, one-round three-party agreement, aggregate signatures. A group with more structure supports more constructions, so a pairing-friendly curve is a strictly better curve than an ordinary one.
More is possible. Less is secure, and the two follow from the same fact.
A pairing is a weakness before it is a feature. Bilinearity gives the MOV attack, which moves the curve's discrete logarithm into GF(pᵏ) where index calculus applies. The map cannot be had without the reduction.
So pairing curves need larger parameters than ordinary curves at the same security level, because the extension field must resist attack as well as the curve. Supersingular curves mod p, with k = 2, need a much larger p than P-256 does.
And the assumptions are younger and weaker. Bilinear Diffie-Hellman is provably no harder than Computational Diffie-Hellman, and may be easier. Security estimates for pairing-friendly curves have already been revised downward once, when field discrete log algorithms improved.
The right way to read it: a pairing is a capability purchased with security margin. When the capability is unavailable elsewhere — signature aggregation across a hundred thousand validators, or constant-size zero-knowledge proofs — the purchase is obviously worth making.
When an ordinary curve would do the job, use the ordinary curve. Plain signatures and plain key exchange gain nothing from a pairing and give up parameter efficiency and assumption maturity to get it. Structure is a cost you should only pay for a capability you actually need.
Check
Work it out before clicking.
Check your understanding
How does the MOV attack use the pairing to attack Q = kP₀?
Answer: B
Why: Bilinearity pulls the scalar out as an exponent, so both ẽ(Q, P₀) and ẽ(P₀, P₀) are computable and k is the discrete log of one to the base of the other — in a field, where index calculus is subexponential. The curve problem has become a field problem.
Check
Consider what makes IBE decrypt.
Check your understanding
Bob computes ẽ(D_Bob, rP₀) with D_Bob = s·H₁. Why does this equal Alice's gʳ?
Answer: B
Why: The scalar s comes out of the first argument as an exponent and goes back into the second, turning P₀ into P₁ = sP₀ — which is exactly what Alice paired with. Neither party knows s, and the book identifies this as the main step of the whole scheme.
Check
Consider the parameter choice.
Check your understanding
Why must a pairing-friendly curve use a larger prime than an ordinary curve at the same security level?
Answer: B
Why: A computable pairing requires a small embedding degree, and a small embedding degree is exactly what makes MOV effective. So the parameters must defeat two problems — the curve discrete log and the field discrete log — and the field one drives the prime upward.
Connect it up
The chapter is one equation and five applications.
Draw it
Write ẽ(aX, Y) = ẽ(X, aY) at the top. Then derive, in order: the MOV reduction, Joux's tripartite protocol, IBE encryption and decryption, BLS signing and verification, and the keyword search test. For each, mark which scalar is being moved and who does not know it. Finish with three lines: what a pairing costs in parameter size, which assumption each scheme rests on, and one deployment where the capability justifies the cost.
Deriving them rather than memorising them is the point. A new pairing-based paper is then read by asking which scalar is moving and who is ignorant of it.
Exit ticket
One question, on the chapter's central tension.
Predict first
Why did supersingular curves go out of favour and then come back?
Correct: The pairing that made them insecure via MOV turned out to be the thing that makes new constructions possible
Why: A computable pairing into a small field is exactly what MOV needs and exactly what identity-based encryption, one-round tripartite agreement and aggregate signatures need. The curves became worthless when only the attack was known and valuable once a use was found — with the requirement that p be large enough for the extension field to be safe too.
Recap
One extra operation, and a chapter's worth of consequences.
Chapter 23 next. Lattice methods: the shortest vector problem, LLL reduction, and attacks that break knapsack cryptosystems and low-exponent RSA — plus the lattice problems that post-quantum cryptography is now built on.
Figure (svg): The five facts about the supersingular curve underlying every construction in the chapter.
Want this taught 1-on-1? Alexander tutors Cryptography — $55/session, free consultation.