OASA Logo

The Technology Behind Random Number Generators: Ensuring Fairness in Digital Games

A slot stops on three cherries. A card lands on the river. It looks like luck. Under the hood, it is careful math, strict rules, and many tests. Games feel light, but the systems that make them fair are not simple. They run on code, hardware, and review work done by people who check again and again.

Here is a clear walk through how random number generators (RNGs) work, how labs test them, how rules shape them, and what you can check on your own. The aim is simple: help you see how “fair” is built, not wished for.

What “random” means when money is on the line

In games, “random” is not chaos. It is a stream of numbers with no pattern that you can use to pick reel stops, deal cards, or trigger a jackpot. There are two main kinds: true random (from nature, like noise) and pseudo‑random (from math). For money games, we often use a crypto‑strong pseudo‑random stream, because it is fast, stable, and safe when it is done right.

A secure RNG has a “seed,” which is a secret start value. If the seed has enough surprise (entropy), and the algorithm is strong, no one can guess the next number. Good practice for such secure generators is set out in the US standard known as NIST SP 800‑90A. It explains how to build and run well known secure designs like AES‑CTR DRBG and Hash‑based DRBGs.

Bad RNGs are not just “a bit off.” They can be guessed. If an attacker can guess the next card or the next spin, a game fails. That is why fair play is not a feeling. It is a design choice plus proof.

Where does randomness come from in real systems?

Most game servers do not pull random bits straight from the wind. They mix sources. The operating system collects noise from devices and timing. Hardware can add more, like low‑level noise from chips. Then a secure pseudo‑random generator stretches that seed into many safe numbers.

For a fun, real world look at entropy, see how a major network company uses a wall of lava lamps to seed randomness. Yes, lava lamps. Their post on Cloudflare’s LavaRand entropy wall shows how real‑world noise can help build strong seeds.

On the server, many teams also use CPU features to seed and reseed. Intel chips, for example, expose RDSEED and RDRAND. Used with care, they add fresh bits to the pool. Intel has a good, deep write‑up here: Intel DRNG (RDRAND/RDSEED) guide.

How a game turns RNG bits into game results

Numbers alone are not the game. The code must map random bits to outcomes with no bias. For slots, the RNG picks a large number. The game maps that to “stops” on each reel by using ranges. Every spin is a new, independent sample. The long‑term return to player (RTP) is set by the pay table and reel math, not by the RNG. The RNG just picks which stop you hit next.

For card games, a correct shuffle will take a deck and permute it using a strong method, like Fisher–Yates, with a crypto RNG as the source. If a team uses a fast but weak PRNG, a smart foe may spot a pattern. That would break the game. Many rules for remote gambling name the shuffle and RNG parts in plain words. See the UK Gambling Commission Remote Technical Standards for how a major regulator frames these needs.

Test labs check that mapping logic does not leak bias. They also check that limits, like bet caps and jackpots, do not change the random pick itself. A core doc many labs use is GLI‑11, which is part of a long list of public standards for devices and systems. You can find it on the GLI‑11 standards for gaming devices page.

What labs actually test (and why those tests matter)

First, they hit the RNG stream with math tests. These are not one test, but a pack of tests for bits, bytes, blocks, and serial traits. A very common set is the NIST SP 800‑22 statistical test suite. It looks for signs of bias: runs too long, too many ones, repeats at odd levels, and more.

For deep stress on pseudo‑random streams, many labs and devs also use TestU01 battery. It has small, medium, and huge packs. Some tests take hours or days, and they can catch fine flaws in old or home‑grown PRNGs.

Another open pack you may see is Dieharder tests, which extend the old Diehard set. It is not as formal as TestU01, but it is a good extra lens and used in many audit flows.

Then there is the lab role itself. An audit group needs to be free from the maker and the casino. eCOGRA is a well known, independent test house. They test RNGs, payout logic, change control, and more. Their seals show up on many legal sites in Europe and beyond.

Another big lab is iTech Labs. They publish RNG testing notes and public reports. If you see their mark on a game, you can click through and read the scope: which game, which version, what date, which tests, and if the test was on the server side or in the client.

When randomness goes wrong: short case files

RNG mistakes are not only a casino thing. One famous bug hit the Linux world. A change in OpenSSL on Debian made keys and random numbers easy to guess for years. It was a seeding issue. Many tools broke. Read the original note: Debian OpenSSL PRNG vulnerability. The lesson for games: never trim the seed. Never comment out “weird” code you do not get. Ask the crypto team first.

Another common trap is to build your own “fast” PRNG, then use it to shuffle cards. It may pass small tests and still leak. Once state is known or guessed, the stream is done. At that point, it is not random. Attack notes from the app sec world explain why this happens. See OWASP on PRNG weaknesses for a clear view.

Good teams do not wait for drama. They set a reseed policy, log RNG health, lock down builds, and run a full test after each key change. When they change a compiler flag or upgrade a chip, they test again.

Rules, audits, and life in the real world

Regulators want proof that the RNG is strong, that the mapping has no bias, and that change control is strict. They can ask for source code, build logs, and test packs. They also want to see a plan for faults: what if the system RNG blocks, or a health check fails?

In the US, New Jersey is a key market for online play. Their tech rules are public and very clear. They show what a lab will ask for and what a casino must keep on file. See the New Jersey DGE Technical Standards for details on remote games, RNGs, and reporting.

A quick detour: “provably fair” and public randomness

Some crypto games use “commit‑reveal” and public beacons. The idea: the server commits to a secret seed now, the player adds a client seed, and later both are used to make the outcome. Anyone can check the math. A known tool in this space is a verifiable random function (VRF). For example, Chainlink VRF gives a proof that a number came from a set seed and key.

There are also public sources of random bits for research. One is the NIST Randomness Beacon, which signs time‑stamped values. It is not a drop‑in for games, but it is a good tool to test ideas or to add an extra layer in a commit‑reveal scheme.

Note, though: blockchains do not make poor RNG safe by magic. You still need sound seeds, good code, audits, and tests.

Player checklist: fast ways to spot real fairness

Use this short list when you check a site or a game:

You can also cross‑check audit seals on trusted review hubs. One neutral option is this curated list of recommended online casinos. It keeps track of audit marks and license data across many brands. Disclosure: many review hubs, including Spilloversikt, may receive affiliate revenue from some operators they list. Always read how they rate sites and what tests they require before they give a badge.

A table that makes RNG choices easier to compare

Teams often ask: which RNG should we use for shuffles, spins, or seeds? The global guideline on random number generation is ISO/IEC 18031. The table below sums up common picks in games and what they are good for.

Mersenne Twister (MT19937) PRNG Not crypto‑safe Huge period; 624‑word state Sim tools, visual effects; not for money shuffles TestU01, Dieharder Fast, but leaks if state is known. Avoid for cards/slots results.
PCG family PRNG Not crypto‑safe Long period; small state Mini‑games with no cash risk TestU01 Nice stats and speed; still not safe vs. attack.
Xoroshiro / Xorshift PRNG Not crypto‑safe Long period; tiny state UI effects, non‑cash logic TestU01 Very fast; breaks under known‑state or backtracking.
AES‑CTR DRBG (per NIST) CSPRNG Crypto‑safe N/A (stream from block cipher) Core server RNG, shuffles, jackpots NIST SP 800‑22 Needs robust seeding and reseed rules; great on AES‑fast CPUs.
ChaCha20‑based DRBG CSPRNG Crypto‑safe N/A (stream from ARX cipher) Core RNG on mobile and cross‑platform NIST SP 800‑22 Good speed on low‑power chips; simple code path.
Hardware TRNG (OS pool + RDSEED) TRNG feed Crypto‑safe source N/A Seeding and periodic reseed NIST SP 800‑22 (on whitened output) Use as seed material; do not expose raw bits to the game.

Field notes: how devs wire it all together

On a new build, a team will often do this:

They also plan for faults. If the OS RNG blocks, they wait. If seeding fails a health check, they stop the game, show an error, and page an engineer. No silent fallbacks to weak PRNGs.

Myth‑busting Q&A

Does a strong RNG force a game to hit the RTP each week?

No. RTP is the long‑term average set by pay tables and odds. A fair RNG just picks outcomes with no bias. Over a short time, results can swing high or low. That is normal and not a sign of a bug.

Is Mersenne Twister safe for card shuffles?

No. MT19937 is fast and great for sims, but not safe for money games. If someone can observe some outputs, they can often predict the rest. Use a CSPRNG.

What if my OS RNG blocks and the game hangs?

Do not swap to a weak PRNG. Design the app to wait and show a clear message. Modern APIs like Windows BCryptGenRandom and Apple SecRandomCopyBytes give secure bytes; use them right and handle errors with care.

Does “provably fair” mean labs are not needed?

No. It is a useful idea and can add trust, but you still need audits, safe code, and clear rules. Many laws also still require lab tests.

Red flags you can spot in minutes

Developer corner: practical do’s

Reality check: fairness is engineered

A fair game is not luck behind the scenes. It is design, code, tests, rules, and people who check the work. Good teams mix strong entropy, secure RNGs, clean mapping, and outside audits. Good players check seals, read reports, and know the signs of trouble. That is how trust is kept.

Methodology & Sources

Responsible play

Gambling is for adults only. If you feel stress or loss of control, pause and seek help. You can find support at BeGambleAware: begambleaware.org.