Back to Tools 100% Client-Side (0 Data Sent)

Provably Fair & Configurable Random Number Studio

Zero Egress

Zero-egress client-side randomness studio. SHA-256 / HMAC-SHA256 provably fair commit-reveal scheme, uniform & Box-Muller Gaussian normal distributions, tabletop polyhedral dice roller, Fisher-Yates list shuffler, EFF Diceware passphrases, UUID v4/v7 tokens, and real-time Chi-Square & Shannon entropy statistical audit.

Presets:

How Provably Fair Verification Works (Cryptographic Guarantee)

1. Pre-Commitment: Privatools generates a 256-bit secret and publishes its SHA-256 hash before you roll. This commits the seed without revealing it.

2. Client Input: You provide your own client seed and an incrementing nonce. Privatools cannot predict or alter your roll because the outcome is derived from HMAC-SHA256(ServerSeed, ClientSeed:Nonce).

3. Post-Roll Audit: Reveal the secret seed at any time to verify that the pre-commitment hash was never changed and that every roll was mathematically deterministic.

Server Seed & Pre-Commitment

SHA-256 Pre-Commitment Hash:Public & Locked

Generating hash...

Secret Server Seed (256-bit):

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Roll Parameters

Client Seed:

Nonce (Counter):

Min Value:

Max Value:

Generate Floating Point

Roll History & Audit Ledger (0)

No rolls recorded yet. Press "Roll Provably Fair Number" above to start your ledger.

Independent 3rd-Party Verifier

Input any revealed server seed, client seed, nonce, and commitment hash to independently recompute the cryptographic HMAC and derived outcome.

Revealed Server Seed:

Expected Commitment Hash:

Client Seed:

Nonce:

Min:

Max:

Architectural Privacy Guarantee

Provably Fair & Cryptographic Random Number Studio

Generate cryptographically secure random numbers, Diceware passphrases, UUIDs (v4 & v7), and Gaussian distributions. Audit randomness with NIST-style statistical tests, and roll verifiably provably fair numbers using SHA-256 HMAC commitments.

In-Browser Technology:Web Crypto API (crypto.getRandomValues)SHA-256 HMAC Provably Fair ProtocolDiceware Wordlist EngineChi-Square Statistical Tests

How Client-Side Processing Works

Every step executes within your browser runtime without network calls or cloud storage.

1Hardware randomness is gathered from the OS kernel via window.crypto.getRandomValues.
2The provably fair protocol hashes a 256-bit server seed into a commitment, combines it with a client seed and nonce, and produces verifiable rolls via HMAC-SHA256.
3Gaussian random values are generated via the Box-Muller transformation using cryptographic uniform floats.
4Statistical test suites evaluate Shannon entropy, chi-square distribution uniformity, and run frequency in real time.

Common Workflows & Use Cases

Provably Fair Audits for Gaming & Contests

Run verifiably fair giveaways, contests, and game mechanics where participants can verify their roll was not manipulated after the fact.

High-Entropy Password & Diceware Generation

Generate memorable, cryptographically secure multi-word passphrases with exact entropy calculation for password managers and master keys.

Database UUID v7 Generation

Generate time-ordered UUID v7 tokens for high-performance database primary keys without index fragmentation.

Scientific Simulation & Monte Carlo Modeling

Sample Gaussian distributions and uniform random batches for statistical modeling and engineering simulations.

Questions & Answers

Frequently Asked Questions

What makes a roll 'Provably Fair'?

A secret seed is generated and its SHA-256 hash is published before the roll (commitment). The outcome is determined mathematically by HMAC-SHA256(ServerSeed, ClientSeed:Nonce). When the roll finishes, the secret seed is revealed so anyone can verify the outcome was not changed.

Is this cryptographically secure?

Yes. All random values are harvested from window.crypto.getRandomValues, which connects to your operating system's cryptographic CSPRNG (/dev/urandom or Windows CryptoAPI). It does not use pseudo-random Math.random().

What is UUID v7 and why should I use it over UUID v4?

UUID v4 is completely random, which causes severe B-tree page splits when used as a database primary key. UUID v7 embeds a Unix millisecond timestamp at the front, creating natural time-ordered indexing while retaining 74 bits of cryptographic uniqueness.