Auditing RNG: Ensuring Fairness with Cryptography

Last updated: 20 June 2026 • Information only, not legal or certification advice.

03:17 in the logs

The room was quiet. The alert was not. At 03:17, the RNG log showed a sharp line of wins, then a flat calm. That kind of step is not normal. I pulled the seed notes, checked reseed times, and ran a quick health test. One flag turned into five. It was not a big breach, but it was a real lesson: in games with money, “random” must be more than a word.

In most places, you cannot ship a game without strict rules for remote RNG. For a sense of how tough it can be, look at the UK Gambling Commission technical standards. The bar is high for a reason.

Why “fair RNG” is not a slogan

People think random is like rolling a die. In code, it is not so simple. A weak RNG can leak patterns. A low-entropy seed can repeat. A bad design can be guessed. If a stream is even a bit easy to predict, a smart actor can tilt odds. That breaks trust at once.

Cryptography helps. A cryptographically secure RNG (CSPRNG) is built to resist guesswork, even if an attacker knows a lot. The seed must come from true, high-entropy events. The update must mix bits in a way that hides past and future state. The output must pass strong tests. See the guidance in IETF RFC 4086 on randomness requirements for why sources and mixing matter so much.

What an RNG audit really covers

An audit is not just a stats run. A good audit checks how you collect entropy, how you seed, when you reseed, and how you test for health while live. It looks at the exact DRBG you chose, the build flags, the version, and the supply chain. It reviews logs. It checks who can touch config and keys. It asks where alerts go and who acts.

We also try to break the setup. We pull big samples from the live path, not a lab stub. We verify that the sample did not pass through caches or filters. We look for gaps and bursts. We compare pre-release tests with post-release runs. If they drift, we ask why.

Field note: I always ask three fast questions: Where does entropy come from? When do you reseed? What happens when a health test fails at 02:00? If the room goes quiet, we have work to do.

Cryptography under the hood: CSPRNGs you actually see

In real systems you see DRBGs from NIST 800‑90A: CTR‑DRBG (based on AES), HMAC‑DRBG, and Hash‑DRBG. The spec is clear: use known, reviewed blocks and hashes, not homebrew. Read the details in NIST SP 800‑90A Rev.1.

You also check the entropy path per NIST SP 800‑90B (entropy sources). This is about min‑entropy and health tests at the source. How many bits of surprise per sample do we get, even in bad hours?

Then you look at how the parts join, as in NIST SP 800‑90C (RNG constructions). This sets rules to combine sources and DRBGs so the whole stays secure. In many games, teams also use stream ciphers (like ChaCha20) for speed and safety. That can be fine if the seed is strong and the design is open to review. But fast non‑crypto PRNGs (like Mersenne Twister) are not OK for money games. They are fast, but guessable.

The audit checklist (print this, then use it)

You can use the table below as a short map. It lists what to check, what proof to ask for, and what tools catch common issues. Mark each line green or red. No maybes.

How to use it: Operators can run this list each release and after any big code change. Independent labs can attach it as an appendix to final reports. Both sides should agree on sample size, live path taps, and alert playbooks before tests start.

A short, opinionated toolkit

Start with the NIST Statistical Test Suite (STS). It is a base line. It catches runs, bias, and some local patterns. Then run TestU01 documentation Crush or BigCrush. It is slow, but it sees deeper flaws. Add the Dieharder test suite for variety and cross‑checks.

Prep your data well. Pull from the same API path that games call. Turn off caching. Log raw bytes, not decoded numbers. Skip the first 1–2 MB to avoid warm‑up bias. Keep time stamps. Aim for at least 1–5 GB for BigCrush. Note the seed and version in the header of each file.

Field note: If your stats are “too perfect,” be careful. Real random has noise. A smooth bell is a bad smell.

Case file: when crypto went sideways

Years back, a DRBG called Dual_EC made news. It was in a standard. It looked slow but fine. Then two researchers showed a trap: with a secret point, one could predict the stream. Read their talk: Dual_EC_DRBG backdoor (Shumow & Ferguson). The lesson is simple: use open, reviewed designs, and watch for odd constants and hidden params.

We no longer use Dual_EC in fair play systems. But the story stands. If a design is hard to audit or has magic numbers no one can explain, do not ship it.

Hardware entropy and “verifiable” randomness

Good RNGs start with good entropy. OS pools mix clicks, clock drift, net jitter, and more. Hardware can add true noise from circuits or diodes. Some teams go further. One nice example is Cloudflare’s LavaRand in production. They point a camera at lava lamps and feed that into a mix. It is a vivid way to add surprise.

There are also public beacons. You can sample from the NIST Randomness Beacon. You can add that to your own mix to add a public, time‑stamped value. Do not rely on one beacon alone. Treat it as a spice, not the meal.

Compliance reality: seals, labs, and what they mean

Many teams ask about crypto module certs. Look up the NIST CMVP (FIPS 140‑3) registry. It shows if a module is validated. Note the scope: it says what was tested, on which platform, in which mode.

There is also an RNG standard: ISO/IEC 18031 overview. Some labs use it to assess RNG designs and tests. It is not a law in itself, but it helps align terms and methods.

In gaming, third‑party labs do a lot of the heavy lift. See GLI standards for broad rules used by many markets. Look at eCOGRA testing and iTech Labs RNG certification pages for how they scope and report checks. Read the fine print: Which games? Which versions? What dates? What sample sizes? Does it list runtime health tests or only pre‑release stats?

Seals do not replace your own duty. They show a snapshot. You still need live alerts, fast fixes, and clear logs.

For players and B2C brands: quick checks you can do today

If you are a player, scroll to the site footer. Look for an RNG test seal, the lab name, the date, and a link to a full PDF. Open it. Check the game list, the version, the date, and how large the sample was. If it is three years old and for other games, that seal is weak.

If you do not want to parse lab PDFs each time, use an independent registry that tracks audit seals, expiry dates, and test scope in plain words. A good place to start is the Casinaportal officiell sida, which keeps reviews and explains key terms in simple language. It helps you see who is up to date and who is not.

Brands can help users by linking to live audit pages, not just logos. Add a short note on your RNG design, your entropy sources, your reseed plan, and your last test date. Keep a log of fixes for RNG‑related issues.

Play safe. If you need help, visit BeGambleAware.

Short answers to hard questions

What makes a CSPRNG fit for games with money?

It must be based on a public, reviewed design. It must use strong seeds with enough min‑entropy. It must have sound reseed rules. It must resist state reveal. It must pass heavy stats before and after launch.

How is audit different from a one‑off lab test?

An audit checks design, code, ops, logs, and alerts. A one‑off test may only check samples. Both are useful. The first cuts the real risk.

Red flags and myth‑busting

• Myth: “It passed one test, so it is fair.” Fact: One test is not enough. Use many tests and live health checks.
• Myth: “Open code means fair.” Fact: You must still check seeds, builds, and ops. Supply chain counts.
• Myth: “A seal lasts for life.” Fact: Check the date, scope, and version. RNGs change with new code.
• Red flag: Time‑based seeds without extra entropy.
• Red flag: Homebrew math or secret constants with no review.
• Red flag: No logs for reseeds or health test trips.
• Red flag: Reports with tiny samples or no live path data.
• Want a handy list? See the OWASP Random Number Generation Cheat Sheet.

Field note: failure at 02:00 and what fixed it

Once, a health test began to flap at 02:00 daily. The team had an ops job at 01:55 that paused one entropy feed. Reseeds fell back to a weak mix. We changed the job time, added a second feed, and raised alert levels. The flap stopped. The point: watch your system as a whole. Crypto is strong, but ops can still break it.

Practical steps for teams that ship games

• Pick a known DRBG (AES‑CTR‑DRBG, HMAC‑DRBG, or Hash‑DRBG) with clear version and config.
• Measure min‑entropy with 800‑90B methods. Keep the report handy.
• Define a reseed interval by output size or time, not just “on start.”
• Run STS, Crush, and at least one other suite on GB‑scale data from the live path.
• Enable health tests at source and DRBG. Send alerts to a real on‑call group.
• Make builds reproducible. Store hashes. Verify at release time.
• Log seed events, test trips, and code changes. Keep 90+ days of logs.
• Have a rollback plan for RNG issues that you can run in minutes, not hours.

A note on “provably fair”

Some sites use “provably fair” for games where users can verify a seed or a move with a hash. That can help trust if done well. Still, you must review the crypto, the seed path, and the code that joins it all. Proof you can check is a promise. Make sure you do check.

Closing field note: verify the promise

Fairness is not a banner; it is a habit. It lives in the seed, the reseed, the alerts, the logs, and the people who care at 03:17 when the graph looks wrong. Keep a short list, read the reports, and ask direct questions. If something is unclear, pause and dig.

One last tip: keep a simple cheat sheet of audit claims, what each seal means, and how to read a test PDF. If you need a clean start, the Casinaportal officiell sida keeps plain notes and links to source docs.

Sources and standards mentioned

• UK Gambling Commission technical standards
• IETF RFC 4086 on randomness requirements
• NIST SP 800‑90A Rev.1
• NIST SP 800‑90B (entropy sources)
• NIST SP 800‑90C (RNG constructions)
• NIST Statistical Test Suite (STS)
• TestU01 documentation
• Dieharder test suite
• Dual_EC_DRBG backdoor (Shumow & Ferguson)
• Cloudflare’s LavaRand in production
• NIST Randomness Beacon
• NIST CMVP (FIPS 140‑3)
• ISO/IEC 18031 overview
• GLI standards
• eCOGRA testing
• iTech Labs RNG certification
• OWASP Random Number Generation Cheat Sheet
• BeGambleAware