🦥 Random isn’t “Random”

Hello friends!

Welcome to this week’s Sloth Bytes. I hope you had a great week.

Dex is a conversational AI and career matchmaker that works on behalf of each person. You spend 15-20 minutes on the phone with him, talking about your experience, your ambitions and your non-negotiables.

Dex then scans thousands of roles and companies to identify the most interesting and compatible opportunities.

Once we’ve found a match, Dex connects you to hiring managers and even helps you prep for interviews.

Thousands of exceptional engineers have already signed up and we’re partnered with many of the UK’s leading Start-ups, Scale-ups, hedge funds and tech companies.

Don’t waste another day at a job you hate. Speak with Dex today.

Get Started

AI will eliminate 300 million jobs in the next 5 years.

Yours doesn't have to be one of them.

Here's how to future-proof your career:

Start learning AI now

A few years ago, I was in a final-round technical interview.

Fun little zoom call. Multiple interviewers. My hands were sweating like crazy.

After finishing all the normal interview problems we had some extra time.

So they asked me a fun bonus question:

Easy enough, right? I asked if I can use the random package and they said sure.

Now in my head I thought “Wow this is way easier than the other questions.”

The solution basically looks like this with the random package.

Boom. Done.

At this point I felt pretty confident, but then one interviewer hit me with this question:

And that’s where I froze. Because I had no idea.

Is random actually random?

Ordinary software is deterministic: given the same internal state and inputs, it follows the same rules. So most general-purpose “random” APIs generate pseudorandom values with algorithms rather than inventing entropy from nothing.

But computers can also collect nondeterministic physical/environmental signals through hardware and operating-system entropy sources. Modern secure randomness usually combines that entropy with a cryptographically secure pseudorandom generator.

So the useful distinction isn’t “computers can never do true random.” It’s: normal PRNGs are deterministic and reproducible; security-sensitive generators are designed to be unpredictable and are seeded/reseeded from high-quality entropy.

For simulations, games, tests, and shuffling where adversaries are not involved, a normal PRNG is often exactly what you want.

For passwords, tokens, keys, and cryptography, use the operating system’s secure randomness APIs or a library built on top of them.

When you ask your computer for randomness, it doesn’t pull chaos out of thin air. Instead, it uses a pseudorandom number generator (PRNG).

A PRNG is an algorithm that produces a sequence that looks random. If you know enough about its algorithm and internal state—including its seed/state—you may be able to reproduce or predict the sequence. That reproducibility is a feature for simulations and testing, but a disaster for secrets.

PRNGs usually consist of two parts:

The seed is the starting point and the math algorithm uses that seed to generate a sequence of numbers.

If you’re curious here’s a list of PRNGs

To reproduce the “random” result. Weird, I know.

The output you should get is [2, 1, 5, 4, 4].

With the same Python version/compatible random implementation and seed, you should reproduce the same sequence. Don’t treat a seeded stream as a cross-language or forever-across-versions serialization format unless the library explicitly guarantees that behavior.

Because reproducibility matters:

So “random” in this case isn’t true randomness. It’s just math following rules.

Okay, so if PRNGs need seeds, where do those come from?

How a generator gets initialized depends on the language/library. Non-cryptographic PRNGs may use an explicit seed for reproducibility or automatically initialize themselves. Secure randomness APIs typically draw seed material from the operating system’s entropy facilities, which aggregate unpredictable system and hardware events.

Once a deterministic PRNG has a particular internal state, its future sequence is determined. The security question is whether an attacker can feasibly learn or predict that state.

Now we only covered how the “random” part works, but how does the shuffle work?

A common way to implement an unbiased in-place shuffle is the Fisher–Yates shuffle. Python’s random.shuffle() uses a well-designed shuffle routine, but the important idea is broader than one language: each step must choose uniformly from the remaining valid positions.

Here’s the implementation in Python (thanks wikipedia):

You see that random.randint(0, i)?

That is what’s making this implementation possible.

The shuffle is only unbiased if those index choices are uniform. A correct Fisher–Yates algorithm paired with a biased range-mapping method can still produce a biased deck. Good standard-library integer APIs avoid common mistakes such as naive modulo reduction when the source range is not evenly divisible by the target range.

And if an attacker needs to be unable to predict the shuffle—think online gambling, lotteries, secret assignments, or security protocols—the randomness source must also be cryptographically secure. Python’s normal random module is explicitly for simulation/general-purpose randomness, not secrets.

And that means it’s not that “random.”

WAIT A MINUTE… If patterns can exist, doesn’t that mean encryptions and random password generators are not that secure?

Couldn’t attackers could guess the seed and reproduce the sequence.

Yes—if you use a predictable non-cryptographic generator for secrets, an attacker who recovers or infers its state may be able to predict future values.

But don’t worry, modern systems provide cryptographically secure PRNGs (CSPRNGs).

CSPRNGs are designed so that, assuming their secret internal state remains unknown and the implementation is sound, observing previous outputs does not make future outputs feasibly predictable. Operating systems seed and reseed these generators from entropy sources.

For a security-sensitive shuffle in Python, use a secure generator such as random.SystemRandom(), which draws from the operating system rather than the deterministic Mersenne Twister used by the normal random module:

These are what you’d use for things like password-reset tokens, API keys, session identifiers, cryptographic keys, and other security-sensitive values.

Knowing the algorithm is not supposed to be enough to predict the sequence; security comes from the generator’s unknown internal state and high-quality entropy, not from hiding how the algorithm works.

Fun fact: Cloudflare uses a wall of lava lamps as one additional physical entropy source.

Cameras capture unpredictable visual patterns, and that data contributes entropy to Cloudflare’s randomness systems. The lamps do not directly encrypt TLS traffic; they are one additional entropy source feeding systems that need unpredictable random values.

That interviewer asked a really good question. I don’t know if this was the answer they were looking for, but still a good question.

If I could go back to that interview, I’d probably say something like this:

If I said that, I probably would’ve gotten the job…

But hey, maybe it’ll help you with one.

Thanks to everyone who submitted!

grcc492, Melvis-07, Yeshua235 , AspenTheRoyal, gcavelier (used a crate/package to handle it. Practical. I respect it), jsjasee, NeoScripter, and Suji-droid!

A lot of you solved it with dfs and bfs great job!

A Keyword Cipher replaces each letter of a message with a letter from a shifted alphabet built using a keyword.

Write a function that takes a key and a message, and returns the encrypted message.

Reply with

That’s all from me!

Have a great week, be safe, make good choices, and have fun coding.

If I made a mistake or you have any questions, feel free to comment below or reply to the email!

See you all next week.

If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.