Exercise 1: Why Key Generation Needs a CSPRNG, Not a Game-Style PRNG — Possible Solution ==================================================================== A cryptographic key's entire security depends on being UNPREDICTABLE to an attacker -- if an attacker can guess or narrow down the key's possible values significantly faster than brute-forcing the full keyspace (Chapter 5's AES-128 keyspace discussion), the cipher's own mathematical strength becomes irrelevant, because the attacker never needed to break the cipher at all. A PRNG built for a video game (for example, a simple linear congruential generator used to shuffle a deck of cards) only needs to produce output that LOOKS statistically random enough that a player doesn't notice a pattern during normal play. It does NOT need to resist someone deliberately trying to predict its output -- that was never part of its design goal. Many such generators are fully deterministic: given the generator's internal state (or even just a handful of its outputs), the ENTIRE future sequence of outputs can often be calculated exactly, with no guessing involved at all. What could go wrong using one to generate an AES key: If an attacker can determine or narrow down the PRNG's seed or internal state -- which is often far easier than it sounds, since game-style PRNGs are frequently seeded from predictable values like the system clock at startup -- they could compute the exact AES key that PRNG would produce, without ever attacking AES's actual mathematics (Chapter 5) at all. The key's real strength would collapse from "requires searching ~3.4 x 10^38 possibilities" (Chapter 5's own AES-128 figure) down to "requires guessing a PRNG seed," which could plausibly be a search space many, many orders of magnitude smaller -- this is structurally the exact same category of failure as the 2008 Debian OpenSSL disaster this chapter describes, just triggered by choosing the wrong tool from the start rather than an accidental code change. A CSPRNG avoids this specifically because it's seeded from genuine OS-level entropy sources (hardware noise, timing jitter) that are not predictable or reproducible by an outside observer, and is specifically designed so that even seeing many of its past outputs doesn't help predict future ones. WHY THIS WORKS AS AN ANSWER ------------------------------ This directly applies the chapter's own distinction ("true unpredictability, not merely output that looks random") to a concrete scenario, and explicitly connects the failure mode back to Chapter 5's own AES keyspace figure -- showing that a weak entropy source doesn't weaken AES's math at all, it simply bypasses the need to attack it, exactly the same underlying lesson the Debian OpenSSL case study teaches later in the chapter.