CSEC3616Cybersecurity Engineering

    Random numbers and CSPRNGs

    Where cryptography actually depends on random numbers, what makes a pseudo-random generator cryptographically secure, and why ChaCha20 replaced RC4 as the standard it builds on.

    • List the four places the lecture names random numbers as required in cryptography.
    • State the two conditions that make a PRNG a CSPRNG.
    • Explain why a CSPRNG's seed, not its algorithm, is what an attacker actually has to attack.
    • State ChaCha20 and Salsa20's current status against RC4's, and cite the source for each.

    12 min read

    Intuition

    Every mode of operation on the previous page rests on one assumption: that its IV or nonce is something an attacker cannot predict or reproduce. A key is the same kind of assumption, one level up. None of that holds if the “randomness” behind it is actually predictable. A cipher that is otherwise unbreakable is worth nothing if the value feeding it can be guessed instead of attacked.

    Mechanism

    The lecture names four places cryptography specifically depends on random numbers: key distribution and reciprocal authentication schemes, session key generation, generating keys for RSA (next week’s topic), and generating the keystream for a symmetric stream cipher. In every one of these, an attacker who can predict the “random” value gets a shortcut around whatever cryptographic strength the surrounding scheme was supposed to provide.

    Mechanism

    A Pseudorandom Number Generator (PRNG) outputs a deterministic sequence of numbers built from an initial seed value. Nothing about that sequence is actually random: the same seed, run through the same generator, always produces the same output. What a PRNG buys is a large, hard-to-guess-looking sequence generated from a small, easy-to-store starting point.

    Mechanism

    A Cryptographically Secure PRNG (CSPRNG) is a PRNG that additionally satisfies two conditions:

    • it is computationally infeasible to brute-force the seed value and correctly predict the output from it, and
    • it is computationally infeasible to distinguish the output sequence from true randomness.

    Put together, the lecture’s own phrasing is exact: the only option left for the attacker is to know the seed. Everything a CSPRNG produces, every key, IV or nonce built from it, is exactly as strong as that one seed, which is why generating the seed itself, from a source with enough entropy that guessing it is infeasible, is the part the whole guarantee actually rests on.

    Pitfall

    “Pseudorandom” and “cryptographically secure” are not the same claim. Every CSPRNG is a PRNG, but a PRNG only earns the CSPRNG label once both conditions above hold. A generator that merely looks random under casual inspection, or one where an attacker with enough compute could still narrow down the seed, is a PRNG that should not be used for keys, IVs or nonces.

    Threat

    If an attacker can guess, narrow down, or otherwise reproduce the seed a CSPRNG started from, every value it has produced or will produce from that seed is exactly as predictable as the seed itself, no matter how strong the algorithm mixing that seed is. A weak seed collapses the entire guarantee at once, not just the first output.

    Control

    Draw the seed from a source with enough entropy that brute-forcing it is computationally infeasible: an operating system’s own entropy pool, not a predictable value like a system clock or a process ID. That is the property the lecture’s own definition names directly: once the seed itself cannot feasibly be found, the attacker has nothing left to attack.

    Recall

    A generator's output passes every statistical randomness test a human could run on it by eye. Is that enough to call it cryptographically secure?

    No. Indistinguishability from true randomness has to hold against a computationally bounded adversary actively trying to tell the two apart, not just casual inspection. And even a generator that clears that bar is not a CSPRNG unless brute-forcing its seed is also infeasible: the two conditions are both required, not either one on its own.

    Mechanism

    Stream ciphers are themselves an application of this: their keystream is generated by a pseudo-random function seeded from the secret key, and every practical reason to prefer one stream cipher over another comes down to how well its generator meets the two CSPRNG conditions above.

    Compare

    A family of related stream ciphers designed by Daniel J. Bernstein. The current de-facto standard for stream ciphers on the internet, and the basis of the CSPRNG in both OpenBSD and Linux.

    Formerly the de-facto standard for TLS/SSL. A feasible attack was demonstrated in 2013. Avoid it today.

    Exam detail

    docs/FACTS.md verifies both halves of that comparison independently of the lecture. RC4’s break is AlFardan et al., “On the Security of RC4 in TLS and WPA” (USENIX Security 2013), and RFC 7465 (February 2015) formally prohibits RC4 in TLS, confirming the lecture’s “feasible breakage in 2013” and “avoid today” exactly. ChaCha20’s status is likewise confirmed outside the lecture: OpenBSD’s arc4random moved to ChaCha20 in OpenBSD 5.5 (2014), and Linux’s kernel CSPRNG, exposed through getrandom(), has been ChaCha20-based since kernel 4.8 (2016).

    Source

    Week 4 slides PDF