When the PRNG is not CSPRNG
Description
A classic rage comic meme expressing horror at a fundamental security mistake. The image features a crudely drawn, black-and-white stick figure character with bulging, bloodshot eyes, screaming with hands on its face in a gesture of pure shock and disbelief. Above the character, white text with a black outline reads, 'OH MY GOOOOD!'. Below, the text continues, 'THAT'S NOT HOW YOU RANDOM!'. The original post caption provides the context: 'When someone suggests using a PRNG to generate a public/private keypair'. For senior developers, this is a relatable moment of witnessing a junior or uninformed colleague propose a catastrophic security flaw. Using a standard Pseudorandom Number Generator (PRNG), which can be predictable, for cryptographic key generation is a cardinal sin. Cryptography requires a Cryptographically Secure PRNG (CSPRNG) that provides sufficient entropy and unpredictability to ensure keys cannot be guessed or reverse-engineered
Comments
19Comment deleted
Suggesting a standard PRNG for key generation is the fastest way to get your pull request comments to look like a CVE report
Sure, seed rand() with time(NULL) and loop until you’ve built a 2048-bit RSA key - because 86 400 possible outcomes per day totally counts as entropy, right?
After 15 years in the industry, you've seen developers seed Math.random() with the current timestamp, use it for cryptographic keys, and my personal favorite - calling it in a loop expecting different results without understanding the underlying PRNG state. The real horror is when they defend it in the PR comments with 'but it works on my machine!'
Every senior engineer has witnessed the horror: a junior dev using `new Random(DateTime.Now.Ticks)` inside a loop, or seeding with `time(NULL)` in a tight iteration, generating the same 'random' number thousands of times per second. Even worse is seeing `Math.random()` used for security tokens or session IDs. The real nightmare? Finding out your production system's 'shuffle' algorithm has been deterministically returning the same sequence for three years because someone thought `Random(42)` made for 'reproducible randomness' in prod. Cryptographically secure randomness isn't just pedantry - it's the difference between a secure system and a $4.2M breach settlement
srand(time(NULL)) in prod: 86,400 'unique' seeds a day, zero surprises
If your “random” is sort(() => Math.random() - 0.5), the distribution is just “who gets paged”; use Fisher - Yates with a CSPRNG
rand()%N + time-based reseeding: the only algorithm that guarantees both non-uniform distribution and reproducible breaches
int rand() { return 4; // chosen by a fair dice roll } Comment deleted
i see ps3 security right here Comment deleted
That was my tought too but is this really from the PS3? Or is that just a meme? Comment deleted
took from xkcd Comment deleted
I see thanks Comment deleted
on some talk explaining how someone broke into ps3, there was a slide with exactly this code Comment deleted
Just a meme Comment deleted
What I tought 😂 Comment deleted
But this have almost nothing to do with ps3! Except the fact the signature scheme were hacked thanks to breaking underlaying alghotithm which were providing random numbers for signatures Comment deleted
well, yeah Comment deleted
That's why we have Ed25519 scheme now and we are not using EdDSA anymore Comment deleted
I think you've meant DSA/ECDSA as Ed25519 is an implementation of EdDSA Comment deleted