Cryptographically secure PRNG, in full
Two properties define the class. Next-bit unpredictability means an observer who has seen the first k outputs cannot predict output k+1 with probability meaningfully better than guessing. State compromise resistance means recovering the internal state from observed output must be computationally infeasible, and stronger designs add backward secrecy so that even a leaked state does not expose earlier output. An ordinary generator like mulberry32 fails both, and no amount of statistical flatness repairs that.
A CSPRNG is still an algorithm, so it still needs a seed, but that seed comes from physical entropy the operating system collects: interrupt timings, device noise, on-chip instructions such as RDRAND. The kernel pool is reseeded continuously. In a browser the pool is exposed as crypto.getRandomValues, part of the Web Crypto API, which fills a typed array with bytes drawn from it. Math.random is a different thing entirely and offers no security guarantee.
Every draw made by the random tools on Vibe Numbers goes through crypto.getRandomValues. rollInt in components/random/random.ts fills a Uint32Array of length one from it, then applies rejection sampling to map that 32-bit value onto the face count without bias. There is no seed the site controls, no reproducibility, and no way for the page to know a result before the reader does. That is the whole point of the split between these tools and the seeded daily numbers.
- Probability
- CSPRNG, Cryptographically secure random number generator
A worked example
Roll the d20 tool twice and the two results are unrelated, because each roll pulls four fresh bytes from the browser's Web Crypto pool and keeps nothing that would link them. Compare that with the daily numbers page, where the entire output is a function of one short seed string and can be reproduced by hand from the date. Different job, different generator, and the difference is deliberate.
Sources
NIST specifies the deterministic random bit generator mechanisms used for cryptographic random number generation in SP 800-90A Rev. 1, published in June 2015.
NIST SP 800-90A Rev. 1 — Recommendation for Random Number Generation Using Deterministic Random Bit GeneratorsThe Web Cryptography API tells implementations to generate cryptographically strong values from a well-established cryptographic pseudo-random number generator seeded with high-quality operating-system entropy.
W3C — Web Cryptography API
See also
Where it comes up on this site
Cryptographically secure PRNG: frequently asked
Unpredictability under attack. Any amount of previous output must leave an adversary no better off than guessing at the next value, and the internal state must stay unrecoverable from what has been observed. Passing statistical randomness tests is necessary and nowhere near sufficient.
Yes. It is the Web Crypto interface to the platform's cryptographic generator, seeded from operating-system entropy, and the specification asks implementations to make it cryptographically strong. Math.random carries no such requirement.
Every roll, through rollInt. Nothing is seeded, and no result exists before you press the button.