DEV Community: ein-monarch

How Can A Randomly Generated Number Be "Insecure"? (a beginner's guide to PRNGs)

ein-monarch — Mon, 10 Aug 2026 05:35:27 +0000

Let's play a little game...

I've generated a sequence of 16 bits using 3 different random number generators from different languages and libraries.

All you have to do is guess which one is cryptographically insecure.
Got it?

Alright, here they are:
A. 1010100000101001
B. 1100111001101101
C. 1101100010000111

Lock in your guess, and then click me!
The correct answer is... B.
A. Generated by Java's SecureRandom.nextBytes,
B. With Python's random.getrandbits (which is insecure),
C. Through JS's window.crypto.getRandomValues.

Congrats if you guessed it right!

The truth is, it's not possible to tell.
A single short stream of bits doesn't tell you anything about the cryptographic security of the source. With only 16 bits, any sequence is equally likely from a secure or insecure generator.

So, then, what makes Python's random.getrandbits different from JS's crypto.getRandomValues?
If you can't distinguish their outputs, then how can one of them be a vulnerability?

To understand, we need to break down a Random Number Generator, or RNG, down to its components.

What is an RNG in the first place?

Computers are always deterministic: the same input always results in the same output.

So, when we say RNG, we mean something that usually takes a starting value (a seed) and uses math to generate outputs that look random. The same seed leads to the same sequence of outputs, so this is technically called a Pseudo-Random Number Generator (PRNG), but I'll refer to it as RNG for simplicity.

Now, we can finally understand what an insecure RNG really means:
A weak Random Number Generator allows the seed value to be easily determined, typically by looking at enough of the RNG's outputs.
All RNGs are deterministic, so if you can figure out either its seed or its internal state, you now know every single future output.

When these predictable RNGs are used in security-critical portions of applications and websites, like session tokens, password resets, or key generation, it becomes a major vulnerability; for example, Wordpress, Docker, and, most recently, online Crypto wallets were all compromised due to flaws that made it easy to determine RNG seeds.

In truth, using an insecure RNG is a very simple mistake but can lead to disastrous consequences.

Thankfully, it's easy to prevent; if you're generating random numbers for any security-related reason, NEVER use Math.random() or your preferred language's general purpose equivalent. Most languages offer cryptographically secure alternatives, like Python's secrets module or JS's window.crypto.getRandomValues().

Okay; that's a simple change to make.
But why?

What really makes window.crypto.getRandomValues() actually secure and unguessable?

Let's take a deeper dive and actually see the difference between Math.Random() and window.crypto.getRandomValues().

The Two Parts To A Secure RNG

1. A Secure Algorithm

A secure RNG requires an algorithm that not only produces statistically random numbers, but also prevents attackers from determining its internal state from its outputs.

Math.random(), for example, typically uses xorshift128+ across modern JavaScript engines (V8, SpiderMonkey, JavaScriptCore). It was designed for speed, not security. Determining its internal state can be done from only a few outputs; just take a look at this repo.

Python's random.getrandbits(), on the other hand, uses the Mersenne Twister algorithm; while it has excellent statistical properties and a huge period, it is also not cryptographically secure. Observing 624 consecutive 32-bit outputs is enough to reconstruct its entire internal state and predict every future value.

window.crypto.getRandomValues(), though, works differently. Browsers do not implement their own cryptographic algorithm here. Instead, they delegate to the operating system's CSPRNG (Cryptographically Secure Pseudo-Random Number Generator); /dev/urandom on Linux, arc4random on macOS, or BCryptGenRandom on Windows. The OS uses a PRNG algorithm designed so that even with billions of outputs, determining its internal state requires solving problems believed to be computationally infeasible.

Even with an unbreakable RNG algorithm, if someone figures out the seed then they'll know all the future outputs; a secure algorithm alone isn't enough for a truly secure RNG.

An Unpredictable Seed

Remember: computers are deterministic.
Every input always results in an unchanging output.

So a good RNG needs to be initialised with an unpredictable seed.

The first strategy that comes to mind is to use time as a seed.
For example, we may seed the RNG with the number of nanoseconds that have elapsed since the start of the program.

However, this method is unreliable. It's not possible for an attacker to guess the exact nanosecond count, but it allows them to narrow it down to a range of values.

With just a few RNG outputs, the attacker can simply test every single seed within said range, figuring out which one perfectly matches the outputs.

Time based seeding simply isn't random enough; so, then, how do we produce unpredictable seeds?

The answer is Entropy Pools.

Essentially, your operating system converts events like mouse movements, key presses, disk I/O, network packet arrivals, and hardware interrupts into randomness.

When a system event occurs, the computer logs a high-resolution timestamp. Because raw timestamps are predictable, the system extracts entropy from the jitter (the microscopic, physically random variation) in the least significant bits of those timestamps, then blends that unpredictability into the pool via cryptographic mixing.

Cloudflare also extracts randomness from physical events: they convert chaotic lava flow to unpredictable randomness by hashing photos of a lava lamp wall.

If you're on Linux, you can check your kernel's entropy estimator with:

cat /proc/sys/kernel/random/entropy_avail

This used to tell you how many bits of entropy, or randomness, is left in your system's entropy pool. On older devices, seeding an CSPRNG would reduce the bits of entropy in the pool, requiring more events to occur to regenerate its size.

On modern kernels (version 5.17+), this will typically read 256. That number reflects that the kernel's own CSPRNG (which typically uses the ChaCha20 algorithm) has been successfully seeded with 256 bits of quality entropy. In other words, we use random events to seed a CSPRNG, which is used to generate seeds for other CSPRNGs.

On a typical desktop, this seeding happens during boot; on servers or VMs with few entropy sources, it can sometimes take longer.

To give some context to what 256 bits of security really means:

There are around 10^68 atoms in our galaxy, the Milky Way.
The probability of picking one specific atom out of all the matter in the entire Milky Way is a billion times more likely than guessing a 256 bit value correctly.

The Future of RNGs?

Standard computers are deterministic, but quantum mechanics is fundamentally probabilistic. Devices called Quantum Random Number Generators (QRNGs) exploit this by measuring quantum phenomena such as radioactive decay; these phenomena are by definition impossible to predict, no matter how many outputs you have.

You can actually view or even listen to real outputs from an actual QRNG here.

Unlike PRNGs, QRNGs do not rely on a seed or an internal algorithmic state. However, they are still physical devices: they can suffer from hardware biases, environmental noise, or manufacturing flaws, so their outputs still require post-processing and health monitoring to ensure quality.

So, for now, I suppose window.crypto.getRandomValues, backed by your system's robust CSPRNG and seeded using data generated (in part) from each keypress and mouse movement you make, will have to do.

Leave a reaction if you learned something new, and I'd love to hear tell any security disasters caused by Math.Random() you've heard of!

Til next time,
ein-monarch

What the #@(% are Monads? (a beginner's guide)

ein-monarch — Sun, 26 Jul 2026 22:07:23 +0000

A monad is just a monoid in the category of endofunctors.

Oh... you aren't fluent in the arcane language of Category Theory?

Hm...
I suppose an example will have to do.

Alright. Let's say we're programming a small class to manage an Inventory in a game. We want to add, remove, and display the items in the inventory.

Let's go ahead and write out some simple code:

class Inventory:
    def __init__(self):
        self.items = []

    def add(self, item):
        self.items.append(item)
        return self

    def remove(self, item):
        self.items.remove(item)
        return self

    def display(self):
        print("Inventory: ", self.items)

We can use the Inventory class with ease:

Inventory().add("Sword").add("Potion").add("Shield").remove("Potion").display()

Output: Inventory:  ['Sword', 'Shield']

So far, so good. One more thing though; the player can only hold a limited amount of items. We just need to change the __init__ and add functions:

class Inventory:
    def __init__(self, capacity):
        self.items = []
        self.capacity = capacity

    def add(self, item):
        if len(self.items) >= self.capacity:
            #inventory is over capacity!
            raise Exception("Out of Inventory Space")
        else:
            self.items.append(item)
            return self
   #implementation of remove() and display() omitted; same as above

Ok... we're done.

So, to recap.
We made an Inventory class, where we can add, remove, and display the state of the list.
It has a max capacity, and throws an Exception when we surpass inventory capacity; we can use try/except to catch and display them neatly instead of letting them crash the program.

Alright, let's just test it real quick.:

try:
   Inventory(capacity=10).add("Sword").add("Potion").remove("sword").display()
except Exception:
   print("Inventory out of space: Try removing some items first.")

And, just as expected, we see

Oh...
that's not right...

Inventory out of space: Try removing some items first.

We're supposed to have plenty of space.

OHHH. Wait...
Calling Inventory.remove(item) can also result in an Exception, when we pass in an item that doesn't exist in the list we're removing from.

I mean... I guess we could surround every single use of Inventory with try/catch and use an if-statement to check the Exception but...
it's not really elegant anymore. The first version was so simple to use; data simply flowed through the operations and there wasn't any complexity.

Maybe there's a better way to do all this. It's time to call upon one of the dark arts of functional programming.

Alright.
The problem is that our functions don't fully behave predictably.
They might throw an error, or they might return normally.
So, to make them behave predictably, what if we made them always return, even if an error happened?

We could technically return an Exception object in Python, but that doesn't really solve our problem. What we want is a clear way to represent success or failure as part of the function's normal output.

We could do so with something like this:

class Result:
     def __init__(self, value, is_error):
         self.is_error = is_error
         if is_error:
            self.error = value
         else:
            self.ok = value
#helper functions for easily constructing Ok/Error
def Ok(value):
    return Result(value, False)
def Error(value):
    return Result(value, True)

Now, when something returns a Result, we can check is_error to determine whether it succeeded or failed.

Alright. Let's modify our Inventory code to return Results instead of throwing errors.

class Inventory:
    def __init__(self, capacity):
        self.items = []
        self.capacity = capacity

    def add(self, item):
        if len(self.items) >= self.capacity:
            return Error("OutOfSpace")
        else:
            self.items.append(item)
            return Ok(self)
    def remove(self, item):
        if item not in self.items:
            return Error("ItemNotFound")
        else:
            self.items.remove(item)
            return Ok(self)
    def display(self):
        print("Inventory: ", self.items)
        return Ok(self)

Alright, but how does this even solve anything?
I mean you still need to unwrap the Result every single time:

inventory = Inventory(3).add("Sword")
if inventory.is_error:
   print(inventory.error)
else:
   inventory = inventory.ok.remove("Potion")
   if inventory.is_error:
       print(inventory.error)
   else:
       #and so on

What progress have we even made?
Now it's worse off than before...

No. Stay steadfast. We're right at the boundary and we cannot turn back.
We must make the final, daring leap.

The problem isn't the Result, it's that we have to keep unwrapping it.
Programmers are lazy; how can we be expected to do such a boring chore again and again? It's madness!

So, we delegate the work to a new method, called and_then:

class Result:
     def __init__(self, value, is_error):
         self.is_error = is_error
         if is_error:
            self.error = value
         else:
            self.ok = value
     def and_then(self, f):
         if self.is_error:
              return self
         else:
              return f(self.ok)

So, and_then takes a function. If the result is an error, it propagates that error down the chain. Otherwise, it applies the function to the value inside.

Interestingly enough, nothing in and_then specifically knows about errors. It only knows how to inspect the Result and decide what to do based on which variant it contains.

To use it, all we need to do is convert Inventory's methods to functions:

class Inventory:
    def __init__(self, capacity):
        self.items = []
        self.capacity = capacity

def add(inventory, item):
    if len(inventory.items) >= inventory.capacity:
        return Error("OutOfSpace")
    else:
        inventory.items.append(item)
        return Ok(inventory)
def remove(inventory, item):
    if item not in inventory.items:
        return Error("ItemNotFound")
    else:
        inventory.items.remove(item)
        return Ok(inventory)
def display(inventory):
    print("Inventory: ", inventory.items)
    return Ok(inventory)

And done!
Alright. Now everything is put into place.
Using Inventory now may look a bit strange at first, but it's quite elegant:

inventory = Ok(Inventory(capacity=3)).and_then(lambda x: add(x, "Sword")).and_then(lambda x: add(x, "Potion")).and_then(display)

if inventory.is_error:
    #handle error gracefully

Why the lambdas? Well, add takes two arguments: an Inventory and an item. But and_then only provides one argument: the value inside the Result.

So we create a small temporary function that remembers the item we want to add:

lambda x: add(x, "Sword")

Now, and_then just needs to fill in the inventory, as the item is already filled in.

And, after all that work, we've kinda re-invented the monad.
I guess you don't need a degree in category theory or experience in Arcane magic to understand a monad after all (though, speaking from personal experience, the latter helps).

Well, technically we didn't make a proper monad. A real monad needs three pieces: a wrapper type (our Result), a way to wrap the starting value (like we did with Ok), and a chaining operation (and_then; usually called bind). Real monads also avoid mutating state and side effects like printing, which we cheated on here to keep things readable.

The category theory definition and the programming definition are really just describing the same concept from different perspectives. Category theory gives the general mathematical structure; Result.and_then is one example of what that structure looks like when we write code. And, thankfully, you don't really need to know category theory at all to benefit from the ideas behind monads.

This is really just the beginning. Remember how and_then only knew how to inspect the box and decide what to do next? That same structure works even if we swap out the context. Replace Error with None and Ok with Some, and now you can handle optional values without repeating if x is not None. The same pattern reappears for async computations, state management, and plenty more. The beauty of monads is that the shape stays the same even when the payload changes.

Do let me know your thoughts and what you'd be interested in reading next. Until then, don't be too afraid of venturing into the arcane.

Sincerely,
ein-monarch