Digital Signatures and Public-Key Infrastructure
Public-key authentication, from definitions to deployed infrastructure. Signatures versus MACs (one signature for many verifiers, public verifiability, transferability, non-repudiation; MACs are about 100–1000× faster and deniable), and why signing is not 'decrypting'. Syntax and existential unforgeability under adaptive chosen-message attack. Textbook RSA signatures and their forgeries (no-message, multiplicative 2^q − q), hashed RSA. Hash-and-sign: secure signature + collision-resistant hash ⇒ secure signature for arbitrary-length messages. Lamport one-time signatures from any one-way function (reduction loses 2ℓ), and why two signatures break them. Stateful ℓ-time, chain-based and tree-based (Merkle/Goldwasser–Micali–Rivest) signatures from one-time signatures; the tree proof (loss 2nℓ* + 1); statelessness by deriving node keys from a PRF (Goldreich); CRHFs ⇒ secure signatures (OWFs suffice: Naor–Yung, Rompel). Certificates and PKI: single CA, multiple CAs (weakest link), delegation and certificate chains, web of trust (PGP), expiry and signed revocation lists. The random oracle model: methodology, on-the-fly sampling, programmability and query observation, objections (Canetti–Goldreich–Halevi, Merkle–Damgård), and why proofs there still count; RSA-FDH with a tight-enough 1/q reduction. Exercises worked.
Corresponds to Katz & Lindell, Introduction to Modern Cryptography, Chapters 12–13 (Chapter 13’s encryption half lives in the encryption note).
Motivation: authentication that anyone can check
IntuitionSigning software patches
A vendor generates and ships with the original software (a one-time authenticated distribution). For each patch it computes one signature and broadcasts . Every client checks . A forger must fail on any never signed, even one differing from a real patch in a single bit.
Authenticated distribution of is still needed, but once; afterwards an unlimited number of messages are authenticated. (Exactly as a shared key is set up once and then encrypts many messages.)
Signatures versus MACs
| MAC (Chapter 4) | Digital signature | |
|---|---|---|
| Keys | shared secret per receiver | one ; public |
| Many receivers | separate key and tag per receiver | one signature for everyone |
| Public verifiability | no: a cheating sender can give A a good tag and B a bad one | yes: if one verifier accepts, all do |
| Transferability | no | yes: show to a third party, who can show it on |
| Non-repudiation | impossible: a judge can’t check the tag, can’t trust a revealed key, and S and R are symmetric | yes: only ‘s holder can sign |
| Speed | about 2–3 orders of magnitude faster | slower |
| Deniability | built in | absent: use MACs (or more) if the signer wants only the recipient convinced |
Transferability and public verifiability are what make certificates possible.
WarningSigning is not “decrypting”
The folklore “sign = decrypt with , verify = encrypt with ” comes from textbook RSA, where the operations happen to coincide. It is unfounded in general, and neither textbook RSA encryption nor textbook RSA signatures are secure anyway.
Definitions
DefinitionSignature scheme (Def. 12.1)
Ppt :
- ;
- ;
- , deterministic.
Correctness: . The message space should be bit strings of arbitrary (or super-polynomial) length. Any encoding into a structured space must be one-to-one, or at least collision-resistant. Like MACs, signatures say nothing about when was sent: replays remain possible.
DefinitionExistential unforgeability under adaptive chosen-message attack (Def. 12.2)
: gets and a oracle, and outputs . It wins if (the queried set) and . Secure if . The direct analogue of Definition 4.2, and the standard notion.
RSA signatures
AlgorithmTextbook RSA signatures (Construction 12.3)
, from GenRSA. ; accept iff . Correct since .
WarningTwo forgeries
- No-message forgery: pick any , set . Valid, with zero signing queries. “But the attacker doesn’t control ” is irrelevant to the definition, and false anyway: retrying random fixes any few bits of . Never assume semantics about which messages matter.
- Arbitrary-message forgery from two queries: for target , pick random , set , query both, output : . More generally, signatures on messages give forgeries on products of every subset of size at least 2: new messages (the book’s counts the empty product too).
AlgorithmHashed RSA
Put in ; ; accept iff . Signs arbitrary-length messages.
- must be collision-resistant: means a signature on also signs .
- Intuitively blocks both attacks: the no-message attack now needs with (inverting ); the multiplicative one needs .
- No standard-model proof for any concrete . With a random oracle onto it is RSA-FDH, provably secure (below).
The hash-and-sign paradigm
AlgorithmHash-and-sign (Construction 12.4)
Given a signature scheme for -bit messages and a hash family with -bit outputs: , ; ; . (The message space must be super-polynomially large, because collision-resistant hashes need super-logarithmic output.)
TheoremTheorem 12.5 — Secure signature + CRHF ⇒ secure signature for
ProofSplit on whether the forgery collides with a queried hash
Let be the event that the forged satisfies for some queried . Then .
- Collision finder : generate itself, answer signing queries honestly, and output if they collide. Its success is , which is negligible.
- Forger for : generate itself, answer query by asking its own oracle for , and output . Under , was never queried, so this is a -forgery.
Both terms are negligible. The same proof works for one-time signatures and gives variable-length MACs too (though Chapter 4 got those without CRHFs).
∎
Lamport one-time signatures
DefinitionOne-time signatures (Def. 12.6)
: may ask for one signature on , then must forge on some . Weaker, but enough as a building block.
AlgorithmLamport (Construction 12.7)
For -bit messages and a one-way function : choose random preimages
Sign by revealing (one preimage per column, chosen by the bit). Verify for all . Example: reveals .
TheoremTheorem 12.8 — One-way function ⇒ Lamport is one-time secure
Corollary 12.9: one-way functions imply one-time signatures.
ProofPlant the challenge in a random cell
A forgery on must reveal a preimage at some cell with , one the signature on never revealed. The inverter :
- pick random and set ; generate all other cells honestly;
- answer the query honestly, aborting if (that cell is unknown);
- if the forgery is “at” , output its -th component.
Mental experiment: give the preimage too, so it never aborts. ’s view is then identical to the real game and independent of , so a forgery lands at the planted cell with probability at least . The real experiment differs only when , and then a forgery at is impossible anyway. So , and is negligible.
∎
WarningTwo signatures destroy Lamport (Exercise 12.2)
Query and : together they reveal every . Now sign anything. (Even two random messages reveal both preimages in about half the columns.)
ExampleVariants (Exercises 12.1, 12.3, 12.4)
- 12.1, one-time signatures for 1-bit messages ⇒ OWF: let where . An inverter returns with ; by correctness for all of Gen’s outputs, signs validly under . Forge on bit 0 with no queries.
- 12.3, subset Lamport: secrets, a message maps injectively to an -subset , sign by revealing . Distinct equal-size subsets satisfy , so a forgery reveals some unrevealed : plant at a random index, loss . Message length up to , almost double Lamport’s.
- 12.4, strong one-time signatures (also forbid a new on the same ). (b) Lamport with (ignore a last bit) is one-way, yet flipping in any revealed preimage gives a new valid signature on . (c) Use a CRHF as Lamport’s : a second valid signature on reveals with , a collision; a forgery on new inverts (one-way by 12.5). Hash long messages first.
- 12.5, CRHF ⇒ OWF: for , at most inputs have a unique preimage, i.e. a fraction. Otherwise the inverter’s output is independent of which preimage was sampled, so it differs from with probability at least : collision probability .
(Worked here.)
From one-time to many-time: hash-based signatures
Stateful schemes and chains
DefinitionStateful signatures (Def. 12.10)
also outputs an initial state ; . Verification needs no state. The security game is the same, with the oracle updating state invisibly. Schemes without state are stateless.
NoteThree stateful designs, increasingly good
| Scheme | Idea | Drawback |
|---|---|---|
| -time | ; message uses key | bound fixed at key generation; keys linear in |
| Chain | sign with , generating the next key on the fly | signature, state and verification grow linearly; every signature reveals all previous messages; no easy way to remove state |
| Tree | binary tree of keys, leaf = message | signature and verification , independent of how many were signed; stateless via PRF |
Chains and trees sign public keys (longer than themselves), so the one-time scheme must sign long messages: Lemma 12.11, CRHFs give arbitrary-length one-time signatures (Lamport plus hash-and-sign; CRHFs give the needed OWF by Exercise 12.5).
Tree-based signatures
AlgorithmTree-based signatures (Construction 12.12; Merkle, Goldwasser–Micali–Rivest)
A depth- binary tree, nodes labelled by prefixes (root , children ), each with a one-time key pair . The root key is the public key. To sign , generating keys lazily:
- for each proper prefix : (“certify the children”);
- at the leaf, .
Output ; verify every link from root to leaf. Each internal key signs exactly one thing (its children pair), each leaf key signs exactly one message, and stored values are reused, so no one-time key is ever used twice.
graph TD R["pk_ε (public key)"] -->|"signs pk_0 ‖ pk_1"| A["pk_0"] R --> B["pk_1"] A -->|"signs pk_00 ‖ pk_01"| C["pk_00"] A --> D["pk_01"] D -->|"signs m = 01"| M["σ_m"]
TheoremTheorem 12.13 — One-time signatures for long messages ⇒ tree scheme is CMA-secure
ProofGuess which one-time key gets forged
With signing queries, at most one-time keys are ever used (each query creates at most ; plus the root). The one-time forger plants its challenge at a random position in the order keys are created, generates the rest itself, and answers queries using its own secret keys, plus its single one-time query for the planted key. Given a forgery from :
- Case 1: the forged path departs from the real tree. At the first where the claimed children differ from the real ones, is a one-time forgery under (which signed only the true children).
- Case 2: the path matches all the way, so forges a fresh message under leaf key , which signed nothing.
Either way the forged key is the planted one with probability exactly (independent of ‘s view), so the one-time advantage is , and is negligible.
∎
AlgorithmMaking it stateless (Goldreich)
Precomputing the whole tree is exponential, and so is storing randomness per node. Instead keep two PRF keys and derive everything: and . The same node always yields the same keys and the same signature, so no one-time key ever signs two different things.
TheoremTheorem 12.14 — CRHFs ⇒ stateless CMA-secure signatures
CRHF ⇒ OWF ⇒ PRF (GGM) plus tree signatures. (Exercise 12.7: replace by a random function, a hybrid to the stateful scheme with fresh randomness, which is Theorem 12.13.) In fact one-way functions suffice (Naor–Yung via one-way permutations; Rompel for any OWF), so, as for private-key cryptography, signatures are equivalent to OWFs. Today this design lives on as SPHINCS+/SLH-DSA, the stateless hash-based post-quantum standard (my addition).
ExampleWhy the chain can’t be made stateless this way (Exercise 12.6)
In a chain, what message signs (and which key signs it) depends on how many and which messages came before: the position in the chain is history, not a function of . Deriving keys from still needs the counter , and two parties signing different -th messages would reuse a one-time key. Trees work because the message itself addresses its leaf.
Certificates and public-key infrastructure
DefinitionCertificate
If Charlie holds signing keys and knows is Bob’s:
(with an unambiguous identity such as an email address). Bob sends to Alice over any channel: tampering can’t produce a certificate for a different key unless Charlie signed one. If Alice holds and trusts Charlie, she accepts . One authentic key bootstraps arbitrarily many, so secure key distribution must be solved only once. It assumes Charlie is honest and uncompromised. Open questions (how Alice gets , how Charlie checks Bob, when Alice accepts) define a PKI.
| PKI model | How it works | Weakness |
|---|---|---|
| Single CA | everyone trusts one CA; distributed physically or bundled (browser, OS); in-person, ID-checked issuance | universal trust unrealistic; single point of compromise, failure, load |
| Multiple CAs | users choose which CAs to trust | as strong as the weakest trusted CA: browsers ship many CAs as equally trusted, almost anyone can pay to be one |
| Delegation / chains | root CA certifies second-level CAs, with the stronger meaning “and may issue certificates” | eases load; more points of attack, harder management |
| Web of trust (PGP) | anyone certifies anyone; each user weighs signers; key-signing parties; public key servers | grassroots, but unsuitable for high-stakes or organisational keys (would you trust strangers to certify your bank?) |
sequenceDiagram
participant Ch as Charlie (root, trusted by Dave)
participant B as Bob (intermediate)
participant A as Alice
participant D as Dave
Ch->>B: cert C→B ("Bob's key, may certify")
B->>A: cert B→A ("Alice's key")
A->>D: pk_A, cert B→A, pk_B, cert C→B
Note over D: verify cert C→B with pk_C, then cert B→A with pk_B
NoteInvalidating certificates
Keys get stolen and employees leave, so certificates must die.
- Expiry: sign (“Bob’s key is ”, date). Coarse: a departing employee keeps a valid certificate until expiry.
- Revocation: each certificate has a unique serial number. The CA records it, verifies revocation requests, and periodically (say daily) signs the list of revoked serials together with the date. Verifiers check the signature, absence from the latest list, and the list’s own signature. The lag is at most a day.
(Modern practice adds OCSP and Certificate Transparency logs: my addition.)
ExampleRevocation exercises (12.8, 12.9)
- 12.8, self-signed revocation: Bob signs “my key is compromised” under , and the CA revokes without checking identity. Safe because the only key such a message can revoke is itself, and anyone holding (Bob or thief) has shown the key is compromised. Revoking it is exactly right.
- 12.9, posting individually signed serials immediately: each entry is signed but the list is not, and there’s no date. With no authenticated channel, a thief holding shows victims an old copy of the page (or strips the entry): every remaining entry still verifies, and nothing proves the copy is stale. The daily list signed with the date defeats this: a verifier demands today’s list.
(Worked here.)
The random oracle model
IntuitionWhy an idealised model at all
Efficient, standard-model-secure public-key schemes are scarce: no RSA-based encryption as efficient as textbook RSA, no practical RSA-based CCA encryption, and only the impractical tree signatures above. This stays true even granting AES as a PRF and SHA as a CRHF. Practitioners won’t use inefficient schemes, and ad-hoc ones are unacceptable. The random oracle model (Bellare–Rogaway) is the middle ground:
- design and prove the scheme assuming a public random function (possibly plus standard assumptions);
- deploy it with replaced by a (suitably adapted) cryptographic hash.
DefinitionThe model
A public, consistent, inscrutable box: anyone (honest or adversarial) queries and gets ; queries are private. Security probabilities are over the parties’ coins and the uniform choice of among all functions. Equivalently, sample lazily: keep a table, answer repeats consistently, answer new with fresh random . Security holds only on average over , never for a particular . The model without an oracle is the standard model.
ExampleA random oracle behaves like…
- a one-way function: with queries, hitting has probability at most and hitting an output equal to at most : total at most ;
- a collision-resistant hash: lazy samples collide with probability (birthday);
- a PRF: (Exercise 13.1: unless queries on , which happens with probability at most , the values are fresh random strings, exactly like a random function).
These hold even for unbounded adversaries limited to polynomially many queries: something with no real-world meaning.
ImportantWhat the model buys in proofs
- Unqueried points are truly random, even if is known or merely hard to guess. A PRG’s output is pseudorandom only for uniform, secret seeds.
- Programmability: the reduction simulates and may choose answers on the fly, as long as they are correctly distributed. (RSA-FDH below; CCA simulation in the encryption note.)
- Observability: the reduction sees every query makes, which is how it extracts an RSA solution.
WarningObjections
- No justification: a ROM proof implies nothing formally about any instantiation. Once ‘s code is public, ” random unless explicitly evaluated” is meaningless: an adversary can evaluate in any way, and the reduction can no longer observe or program queries.
- Provable counterexamples (Canetti–Goldreich–Halevi): schemes secure in the ROM but insecure under every instantiation. Toy version, Exercise 13.2: signs normally unless , in which case it outputs . In the ROM, , so it’s secure; with it leaks the key on the first query.
- “Behaves like a random oracle” is not a definable assumption, unlike “SHA is collision-resistant” or “AES is a PRF”. A random oracle is unkeyed and public yet random-looking, while a PRF looks random only under a secret key.
- Practical gaps: Merkle–Damgård hashes are easily distinguished from random oracles on variable-length inputs (length extension); outputs may need to land in , not just bit strings. (Oracle derivation: , gives independent oracles.)
ImportantWhy use it anyway
A ROM proof is much better than no proof. It shows the design has no inherent flaw: any break must exploit the hash function, which can then be replaced. No natural ROM-proven scheme has been broken in practice, standards expect such proofs, and almost every deployed public-key scheme (OAEP, FDH/PSS, Fiat–Shamir signatures) relies on one. Still, proofs in the standard model are preferred, and what ROM proofs really guarantee is open.
RSA-FDH: full-domain hash signatures
AlgorithmRSA-FDH (Construction 13.10)
Hashed RSA with a random oracle onto (the book writes , but the proof needs uniform elements of ): ; accept iff .
- No-message attack now needs with : inverting a random oracle.
- Multiplicative attack needs : negligible for a random .
Difference from hash-and-sign: Theorem 12.5 extends a secure scheme’s message length using any CRHF. Here a hash turns a completely insecure scheme into a secure one, and only because is modelled as a random oracle; collision resistance alone proves nothing.
TheoremTheorem 13.11 — RSA ⇒ RSA-FDH is CMA-secure in the ROM
ProofProgram every hash so you know its signature, except one
Warm-up (no signing queries): answer one random hash query out of with the RSA challenge and the rest with random values. A forgery on that query gives : success .
With signing queries (WLOG: no repeated hash queries; every signed or forged was hashed first): guesses .
- Hash query : pick , answer , store . Since is a permutation, is uniform: a perfect simulation.
- Hash query : answer .
- Signing query on : return the stored , which is valid () without knowing . If , abort.
- Output if the forgery is on .
When the guess is right, ‘s view is exactly the real game, and is independent of that view until asks to sign , which already means the guess is wrong (it can’t then forge on ). So . (Coron improved the loss to about the number of signing queries; PSS gives a tight reduction and is in PKCS #1 v2.1.)
∎
Quick reference
| Object | Statement | Note |
|---|---|---|
| Signature vs MAC | public verifiability, transferability, non-repudiation | MACs faster and deniable |
| Security | existential unforgeability under adaptive CMA | replays still possible |
| Textbook RSA | no-message and product forgeries | |
| Hashed RSA | needs CRHF; no standard proof | |
| Hash-and-sign | secure sig + CRHF ⇒ secure sig on | split on collision |
| Lamport | reveal | OWF ⇒ one-time; loss ; two sigs break it |
| Chain | sign | linear growth; stateful |
| Tree | certify children, leaf signs | loss |
| Stateless tree | keys and coins from | CRHF (even OWF) ⇒ signatures |
| Certificate | bootstraps trust once | |
| PKI models | single CA, multiple CAs, chains, web of trust | weakest trusted CA |
| Invalidation | expiry; dated signed revocation lists | unsigned/undated lists fail |
| Random oracle | public random , lazy sampling | programmable, observable |
| ROM caveats | uninstantiable counterexamples; MD length extension | better than no proof |
| RSA-FDH | , a random oracle | RSA ⇒ CMA-secure, loss |
Facts to keep to hand
- Signatures are publicly verifiable MACs, and that changes what they can do. One signature serves every verifier, can be passed along, and binds the signer (non-repudiation), at a 2–3 order-of-magnitude cost. Textbook RSA “signing by decrypting” is forgeable outright.
- Hashing does two jobs. With a CRHF it extends a secure scheme to long messages (hash-and-sign); modelled as a random oracle it turns textbook RSA into a provably secure scheme (FDH). The second needs the idealisation.
- Signatures need only one-way functions. Lamport gives one-time signatures from any OWF; trees of one-time keys certifying their children give unlimited signatures, and a PRF removes the state.
- PKI is signatures applied to keys. Certificates bootstrap trust from one authentic key; the hard parts are whom to trust (single, multiple and chained CAs, or a web of trust) and how to kill certificates (expiry plus dated, signed revocation lists).
- The random oracle model trades rigour for efficiency. Proofs observe and program oracle queries, which no real hash allows, and uninstantiable counterexamples exist. Yet no natural ROM-proven scheme has fallen, and most deployed public-key schemes rest on such proofs.
References
- Katz & Lindell, Introduction to Modern Cryptography — Chapters 12–13
- Lamport, “Constructing Digital Signatures from a One-Way Function” (1979)
- Goldwasser, Micali & Rivest, “A Digital Signature Scheme Secure Against Adaptive Chosen-Message Attacks” (1988)
- Bellare & Rogaway, “Random Oracles are Practical” (1993)
- Canetti, Goldreich & Halevi, “The Random Oracle Methodology, Revisited” (1998)
- Kohnfelder, Towards a Practical Public-Key Cryptosystem (1978) — certificates
Mentioned in
- Blockchain and Cryptocurrency Security
- Hash Function Constructions, Merkle Trees, and Key Derivation
- Hash-Based Signature Schemes
- Information Hiding — Watermarking and Steganography
- Public-Key Cryptography — Motivation and Key Exchange
- Public-Key Encryption Schemes
- Schnorr Identification and Signatures
- Signcryption and Advanced Signature Topics
- Transport-Layer Security and TLS
- Zero-Knowledge Proofs