Why are CSPRNGs central to cryptography? What goes wrong with bad randomness?

Almost every cryptographic primitive depends on truly random inputs — keys, IVs, nonces, salts, signing nonces. If the RNG is predictable, the cipher's mathematical strength is irrelevant: the attacker bypasses it entirely.

Real-world disasters caused by bad RNGs:

• Debian OpenSSL bug (2006–2008): a "helpful" patch removed the entropy source. For two years, OpenSSL on Debian generated keys from only 32,767 possible seeds. Every SSH key, TLS key, and PGP key generated on Debian was guessable in seconds.
• Sony PS3 ECDSA (2010): Sony reused the same per-signature random k value. ECDSA with reused k directly reveals the signing key — fail0verflow recovered Sony's private key.
• Android Bitcoin wallets (2013): weak Java SecureRandom on early Android caused ECDSA k reuse, draining Bitcoin wallets.
• Dual_EC_DRBG (2007/2013): a NIST-standardised CSPRNG was backdoored. Snowden documents in 2013 confirmed NSA paid RSA Security $10M to make it the default.

The lesson: crypto is a chain — keys, RNGs, primitives, protocols, implementations. The attacker breaks the weakest link, and RNGs are surprisingly often the weakest.

Tip: Don't write your own RNG, don't seed one yourself, and never use the language's default Random for cryptographic purposes. Use the OS-provided CSPRNG; it's the only thing that's been audited enough to trust.