Pseudorandom Generators
One-time pad is not a particularly useful encryption scheme. Among other problems, the key must be as long as the plaintext, which presents a kind of chicken-and-egg situation: I can't privately send you bits of information unless we already privately share bits of information. This chapter is about overcoming this limitation of OTP:
How can we use a short key to securely encrypt a (single) long plaintext?
5.1. Defining pseudorandomness
OTP encrypts its plaintexts using the xor operation, which requires its two arguments to have the same length. So if we want an encryption method similar to OTP, but with a key that is shorter than the plaintext, we need some way to expand the key into a longer string:
What would need to be true about this mysterious “key expansion” method?
-
It would need to be deterministic, so that both the sender and receiver can expand their key in the same way.
-
Its output distribution would need to be uniform, since that is a crucial property for the security of OTP.
Unfortunately, it's not possible to achieve both of these properties simultaneously. Suppose the expansion method is a deterministic function , so its outputs are bits longer than its inputs. Then there are strings of length , but only (at most) possible outputs of . So the outputs of can never induce a uniform distribution.
But let's not give up hope just because our goal is impossible!
When the thing we really want is impractical or even impossible, we can usually settle for something that is indistinguishable from the thing we really want.
We want a deterministic function, with outputs that are longer than its inputs, and whose outputs can induce a uniform distribution. This is impossible, but perhaps it is possible to have a function with an output distribution that is merely indistinguishable from uniform.
In cryptography, something is pseudorandom if it is indistinguishable from the uniform distribution. (The Oxford English Dictionary defines the prefix pseudo- as “apparently but not really.”)
A pseudorandom generator is the missing piece that enables us to encrypt long plaintexts with a short key.
Let be a deterministic function with , meaning that its outputs are bits longer than its inputs. is a secure pseudorandom generator (PRG) if the following two libraries are indistinguishable:
The value is called the PRG's stretch. The input to the PRG is called the seed.
Let's first understand the attack scenario that this definition formalizes.
-
A victim (or the library) samples a seed uniformly from and uses it as input to .
-
Since the only input to the PRG is its seed, which is chosen and managed by the victim, there are no inputs left for the adversary to control. Thus, the subroutines in the libraries take no arguments.
-
The adversary sees the output of , which is supposed to be indistinguishable from the uniform distribution.
-
The victim uses a seed only once. If the adversary calls more than once, a fresh seed is chosen each time.
A PRG's outputs are indistinguishable from the uniform distribution, to an adversary who sees only the output, when the seed is chosen uniformly and used for only one evaluation of the PRG.
The library generates outputs according to the distribution illustrated below on the left, the library according to the distribution illustrated on the right.
This picture presents a global view of a PRG, which can lead to some confusion. Suppose the PRG has input length and stretch , and therefore output length 256. Then only fraction of strings are possible outputs of the PRG—these correspond to the dots in the left picture. You might wonder how the two distributions could possibly be indistinguishable if one includes only a fraction of the possible outcomes.
But an adversary doesn't have a global view of this PRG picture—it has only a tiny glimpse. In our concrete example, an ambitious adversary might observe PRG outputs, which is still only a fraction of the pseudorandom distribution! More generally, an adversary can observe only polynomially many samples from these exponentially large distributions: a negligible fraction of both the pseudorandom and uniform distributions. A more accurate depiction of the adversary's perspective looks like this:
The adversary observes only a small number of samples from the two distributions, illustrated here as the darkly shaded dots.
Things to remember about the PRG security definition: First, the libraries in definition 5.1.2 give the PRG output directly to the adversary. Remember, when an attack scenario allows the adversary to see a value, we are saying that we want security to hold no matter how that value is used elsewhere. So the PRG security definition says (when the seed value is managed appropriately), “PRG output is a safe substitute for truly uniform randomness, in any situation.”
Second, a PRG is only as good as the quality of its seed. Security rests on the fact that the seed is sampled uniformly from ; how to do this effectively on a real computer is an important question, out of scope from the perspective of the PRG security definition. Security also rests on the seed remaining secret and not being reused.
5.2. Do PRGs exist?
I can't give any example of a PRG whose security can be proven in the same way that we can prove the security of OTP. If such a PRG existed, it would resolve the most famous unsolved question in computer science (see exercise 5.3). The P vs NP question is about what problems a polynomial-time algorithm can/can't solve, and the PRG security definition is about what a polynomial-time adversary can/can't do. So we cannot prove security from “first principles”; we can only conjecture about the security of any particular PRG.
Although we deal in conjectures, these conjectures don't have to be frivolous; they can be informed by strong circumstantial evidence. For example, we can sometimes prove that a PRG resists certain special types of attacks. We can expose a PRG to intense public scrutiny; if no attacks are found despite serious attempts, we gain more confidence about its security.
PRGs are only the first of many primitives and security goals that we'll study. Each of these primitives suffers from the same P vs NP barrier: We can't prove from “first principles” that any particular algorithm achieves any of these security goals. For each primitive, we can identify promising candidate algorithms and conjecture that they are secure.
But cryptography is not a large collection of unconnected, ad hoc conjectures about security. One of the pillars of provable security is that we can use mathematical proofs to reduce the number of conjectures.
In most cases, we cannot prove security properties from first principles. What we can do is prove conditional statements like the following:
If A is secure, then B, which uses A as a component, is also secure.
In this way, B doesn't require a completely new conjecture about security. Its security reduces to a previously established conjecture about A's security.
Using provably secure constructions of this kind, we can minimize the number of assumptions. Ideally, we would conjecture about just one kind of primitive, then use it to build all the others we care about. We study many different primitives, so there are many choices for which one to choose as the “axiom” of provable security.
Valuing mathematical elegance and order of presentation: PRGs are the simplest primitive with security that can't be proven from first principles. We can use PRGs to provably build everything else in the symmetric-key part of this book. For example, we show how to use a PRG to build a PRF (don't worry what that means right now) and prove that the resulting PRF is secure if the underlying PRG is secure. Then we show how to use a PRF to build symmetric-key encryption and prove that the encryption is secure if the underlying PRF is secure, and so on.
Thus, the security of PRFs and symmetric-key encryption (and other primitives) ultimately reduces to the security of the simpler underlying PRG. In other words, if secure PRGs exist, then surely secure PRFs and secure symmetric-key encryption (and other primitives) exist as well. The conjecture that secure PRFs exist is therefore not an extra conjecture; we get PRFs for free, assuming that secure PRGs exist.
In this book, we start with the simplest primitives (PRGs) and build “upward” in conceptual complexity. Most of the constructions you will see are oriented in this direction: building something more complex from something simpler.
Valuing practical efficiency: It is instructive to understand how, for example, secure symmetric-key encryption can be built from PRGs alone. However, real-world encryption schemes are not built in this way; the result would be far too inefficient because PRGs are too low-level. In practice, symmetric-key encryption is built from objects of intermediate complexity—typically PRPs, which are introduced later in chapter 7. These PRPs serve as the “ground truth” for cryptographic constructions in practice; we standardize highly optimized PRPs and use them to construct other things of both higher and lower complexity, with security proofs that reduce security to that of the underlying PRP.
5.3. Application: Pseudo-OTP
We originally motivated PRGs as a way to encrypt long plaintexts using a short key. Let's return to that motivation and formalize the details.
Let be a PRG with stretch , so . Then pseudo-OTP is the following encryption scheme:
The key in pseudo-OTP is only bits, but it can be used to encrypt a plaintext of length . Pseudo-OTP achieves a similar security property to plain OTP, but involving indistinguishability:
An encryption scheme has computational one-time secrecy (OTS) if the following two libraries are indistinguishable:
If the two libraries are interchangeable, then we say that the scheme has perfect one-time secrecy (precisely the same as definition 2.5.3).
If is a secure PRG, then pseudo-OTP (construction 5.3.1) has computational one-time secrecy. In other words,
Proof idea: You might expect a security proof for something called pseudo-OTP to closely follow the security proof for plain OTP. We proved claim 2.2.2 by explicitly calculating probabilities. Unfortunately, that same strategy won't work against pseudo-OTP, because the PRG is completely unspecified; we simply don't seem to have enough information to reason about exact probabilities.
Instead, we must remember this chapter's motivation: We want to use a value as a OTP key to mask the plaintext. Plain OTP requires its key to be uniform, but the theme of this chapter is that being pseudorandom is the next best option.
This idea is formalized in a proof by introducing an intermediate hybrid library. , which generates pseudo-OTP ciphertexts using as a kind of OTP key, is indistinguishable from a library that uses a truly uniform OTP key. This new library generates true OTP ciphertexts, so it is of course indistinguishable from , as desired. So instead of adapting the technique used to prove security of OTP, we simply use the security of OTP, as-is, in a single step of our proof.
The final library is identical to from the statement of the claim. This completes the proof.
5.4. How to extend a PRG's stretch
A PRG's stretch measures how much longer the plaintext can be than the key in pseudo-OTP. A larger stretch means you can encrypt longer plaintexts with a conveniently short key.
In this section, we show how to use a PRG with small stretch to build a PRG with longer stretch. We illustrate only the case of using a PRG with stretch to build a PRG with stretch . Exercise 5.9 explores the more general case.
A PRG is length-doubling if it has stretch . In other words, . When is length-doubling, we write to assign the first half of its output to and the second half to .
Similarly, is length-tripling if it has stretch , and we write to assign each third of the output to separate variables.
We can extend a PRG's stretch by invoking it twice in sequence:
Let be a length-doubling PRG. Then the following function is length-tripling:
If is a secure PRG, then construction 5.4.2 is too. In other words,
Both pairs of libraries are from the family, so I have added subscripts on the subroutine names to disambiguate.
Proof idea: We want to show that is a secure PRG. In other words, when inputs to are chosen uniformly, its outputs are indistinguishable from uniform. Working backwards from our desired goal, what can we say about the outputs of ?
Its output consists of three blocks, each of which is the output of some call to , a secure PRG. Outputs of a PRG are pseudorandom, so proof complete... right? Don't fall into this tempting trap; things are not so simple! A secure PRG is not a magical device that always produces pseudorandom output in every situation; its outputs are pseudorandom only when its input is chosen uniformly.
Here's another way to think about it: The only way to use the fact that is a secure PRG in a proof is to factor out some lines of a library into a separate instance of , so they can be replaced with . In , the input to is sampled uniformly.
computes its final two output blocks as . In order to take advantage of 's property as a secure PRG, its input must be chosen uniformly. Unfortunately, this is not the case here; fortunately, though, is pseudorandom, and that's the next best option. It means we can consider an indistinguishable intermediate hybrid in which actually is uniform.
Thus, the proof has two main steps:
-
Starting with , apply the PRG security of to the first call to , which is possible because it involves a uniform input to . The result is a new intermediate hybrid in which and are uniformly sampled.
-
Now that the intermediate hybrid samples uniformly, we can apply the PRG security of to the remaining call to , on input .
5.5. How to attack pseudorandomness
Security is a knife's edge. One small change can make a secure construction catastrophically insecure. In this book we will encounter many examples of this phenomenon, starting with the following small modification to construction 5.4.2:
The following function is not a secure PRG, even if is.
In other words, the following two libraries are not indistinguishable:
Pay special attention to how this claim is worded. We should be able to attack , even when is the most secure PRG in the world. It would be futile in that case to try to distinguish outputs of from uniform.
Instead, we must attack the erroneous way that uses . Even the best PRG in the world can guarantee security only when its seed is chosen uniformly and not used for anything else. This is the “proper” way to use a PRG, spelled out explicitly in .
Our function violates this “contract” by using as the input to while also including in the output. An adversary who knows can also compute , and will notice that the result is exactly equal to the second half of the output from . On the other hand, if and are all chosen uniformly, it is unlikely that will have anything to do with the value . Thus, we have identified a way to distinguish outputs of from the uniform distribution.
If you are attacking a construction that uses some secure building block , don't try to attack directly. Instead, attack that erroneous way that uses . Look for a mismatch between 's security definition and how uses .
We now formalize this attack idea, proving claim 5.5.1:
To show that is not a secure PRG, we must write a program that can distinguish between the following two libraries:
Consider the following adversary:
When is linked to , then is indeed computed as . Hence, always outputs .
On the other hand, when is linked to , the values , , and are independently and uniformly distributed. Since they are independent, we can imagine being sampled first. When is fixed, is uniquely determined, since is deterministic. Then will output only if is chosen to equal . This event happens with probability since is uniformly chosen and bits long.
In summary, , whereas . The difference in probabilities is nonnegligible, so the attack is successful. is not a secure PRG.
Is it “legal” for the adversary/calling program to run the algorithm?
Kerckhoffs's principle says that the adversary is allowed to know which algorithms it is attacking.
In technical terms, the source code of the adversary is allowed to depend on the source code of the two libraries that it might be linked to, including the description of .
The only thing the adversary doesn't know is the value of that is chosen in , but knowing is not necessary to perform our attack.
If I tried to write a security proof for this insecure construction, where would it break down?
The first few steps in the proof of construction 5.4.2 would also apply to this insecure construction.
But we'd be stuck when we get to this step:
We try to express the call to in “” in terms of the library. We rename the variable to the variable inside . The line “” becomes the line “” in . The value becomes the return value from the subroutine.
But what about the remaining reference to in “return ?” There is no way to rewrite this reference in terms of the variable, which is privately scoped in . The library, as written above, results in a “compiler error.” We get stuck because doesn't obey the “contract” of how to use its PRG : It requires internal secrets that is unwilling to provide.
Later in the book we will not always write the three-hop maneuver explicitly. Still, this example shows that it's important to mentally confirm that the three-hop maneuver “compiles” correctly, because improper use of cryptographic primitives often shows up as an error of scope in an attempted proof.
Exercises
-
Describe an exponential-time adversary that can successfully distinguish the two libraries from definition 5.1.2, and calculate its distinguishing advantage.
-
Suppose and are both secure PRGs with identical input/output lengths. Is it possible to tell whether a victim is generating outputs according to or just by looking at its outputs? Assume that the victim indeed samples seeds uniformly and uses each seed only once.
-
Let be a deterministic function, and define the following set:
Show that if there is a polynomial-time (in ) algorithm for determining membership in , then is not a secure PRG.
is unconditionally in the complexity class NP, for any polynomial-time function . If P = NP, then there is a polynomial-time algorithm for membership in . In other words, if P = NP, no function can be a secure PRG.
-
What can an adversary learn by observing two pseudo-OTP ciphertexts encrypted using the same key?
-
Pseudo-OTP (construction 5.3.1) is defined in terms of a function . We proved that if is a secure PRG, then pseudo-OTP has computational one-time secrecy. Prove that the converse is also true: If pseudo-OTP (using some function ) has computational one-time secrecy, then is a secure PRG.
-
Let be a length-doubling PRG. Show that the following encryption scheme does not have computational one-time secrecy, even if is a secure PRG:
-
Prove that if an encryption scheme has computational one-time secrecy, then the following two libraries are indistinguishable:
:return:return -
Suppose and are encryption schemes, where (i.e., can encrypt keys for ). Prove that if both and have computational one-time secrecy, then so does the following scheme (from construction 2.6.1):
-
In construction 5.4.2 we showed how to transform a PRG with stretch into one with stretch . Show how to extend a PRG with stretch 1 into a PRG with stretch , for any . Prove that your construction is secure.
-
Prove that if is a secure length-doubling PRG, then the following algorithm is also a secure PRG:
-
We've been so focused on extending a PRG's stretch, but what about reducing a PRG's stretch? Prove that if is a secure length-tripling PRG (i.e., its output is bits), then the following algorithm is also a secure PRG:
-
h Prove that if is a secure PRG, then the function is also a secure PRG. means to take the bitwise complement of (i.e., flip every bit in the string ).
.
-
h Prove that if is a secure PRG, then the function is also a secure PRG. means to take the bitwise complement of (i.e., flip every bit in the string ).
.
-
In this exercise, let's allow a PRG to have input length other than exactly bits. The only restriction should be that the PRG's output is longer than its input.
Let and be length-tripling functions, and define the algorithm
So has inputs of length and outputs of length . Show that is a secure PRG if either or is secure.
Your proof should involve two cases: In the first case, assume that is secure, but assume nothing about , except that its outputs have the correct length. Then repeat, swapping the roles of and .
-
Continuing the previous exercise, what is wrong with the simpler construction ?
-
In this exercise, let's allow a PRG to have input length other than exactly bits. The only restriction should be that the PRG's output is longer than its input.
-
Let be a conventional length-tripling PRG. Prove that the following function is a secure PRG if is:
Thus, it is possible for a PRG to be secure despite ignoring half of its seed.
-
Let be a conventional length-doubling PRG. Prove that the following function is a secure PRG if is:
Thus, it is possible for a PRG to be secure despite including half of its seed directly in the output.
-
-
h Suppose is a secure PRG with stretch . Prove that the following function is also a secure PRG:
Thus, it is possible for a PRG to be secure despite having a “weak” input.
Use a bad event.
-
Show that the following algorithm is not a secure PRG, even if is:
-
Let be a length-doubling function. Show that the following algorithm is not a secure PRG, even if is:
-
Show that the following algorithm is not a secure PRG, even if is:
(Contrast with exercise 5.23.)
-
Let be a secure length-doubling PRG. Is the following algorithm a secure PRG? Give either a security proof or a formal attack.
-
Let be a secure length-doubling PRG. Is the following algorithm a secure PRG? Give either a security proof or a formal attack.
-
Let be a secure length-doubling PRG. Is the following algorithm a secure PRG? Give either a security proof or a formal attack.
(Contrast with exercise 5.20.)
-
Let be a secure length-doubling PRG. Is the following algorithm a secure PRG? Give either a security proof or a formal attack.
-
Let be a secure length-doubling PRG. Is the following algorithm a secure PRG? Give either a security proof or a formal attack.
-
Suppose and are both secure PRGs. Is the function necessarily a secure PRG too? Either give a security proof or a counterexample (a way to choose secure PRGs and that cause to be insecure).
Chapter Notes
The first candidate PRG, provably secure from number-theoretic conjectures, was proposed by Blum and Micali [49]. Concurrently, Yao [220] developed the modern security definition for PRGs based on indistinguishability.
The P vs NP question is the most important unsolved question in computer science. It asks whether two classes of computational problems are equal. P refers to the set of problems that can be solved in (deterministic) polynomial time. NP refers to the set of problems whose solutions can be verified (but perhaps not discovered) in polynomial time. An accessible introduction to P, NP, and computational complexity in general can be found in the textbook of Sipser [208] or Arora and Barak [7].