Home / Guides / What Is a CSPRNG?

What Is a CSPRNG?

Q: How do I know if my own code is using a CSPRNG?

In the browser or Node.js, look for crypto.getRandomValues() or crypto.randomBytes(), not Math.random(). In Python, look for the secrets module, not random. In most other languages, the standard library has an equivalent, often named something like SecureRandom or a dedicated crypto/rand package, distinct from the general-purpose random module.

Cryptographically secure random number generation, explained, and why the gap between "random-looking" and "actually unpredictable" cost Bitcoin wallet holders well over $100 million this year.

The short version

A CSPRNG (cryptographically secure pseudo-random number generator) is a random number generator built to a higher standard than the "randomness" most programming languages give you by default. The requirement isn't just that the output looks scattered. It's that no one, not even with unlimited computing power short of breaking the underlying cryptography, can predict the next value or reconstruct past ones. Ordinary random number generators, including JavaScript's Math.random(), were never built to that standard, because most of the time nobody needs it. The problem is that "most of the time" quietly excludes anything security-sensitive: passwords, encryption keys, session tokens, and, as a very recent and very expensive incident showed, cryptocurrency wallet seeds.

See the difference

Both buttons below generate 5 numbers. They look equally random to the eye, and that's exactly the problem. One is safe to use for a password or key. The other isn't, no matter how random it looks.

Math.random()

Not cryptographically secure. Don't use it for anything security-sensitive.

—

crypto.getRandomValues()

The Web Crypto API's CSPRNG, and what this site's generators actually use.

—

You can't tell which is which just by looking, and that's exactly why this matters. The difference is in the algorithm generating them, not the appearance of the output.

A real, recent example: the Coldcard incident

In late July 2026, Coldcard hardware wallet maker Coinkite disclosed a firmware flaw dating back to March 2021. A code change meant to integrate a new cryptographic library had accidentally routed wallet seed generation through a software pseudo-random number generator instead of the device's dedicated hardware CSPRNG. Nobody caught it for roughly five years, because the correct hardware generator was still being used elsewhere in the firmware. It just wasn't the one actually producing wallet seeds.

Here's what that meant in practice: affected seeds carried far less randomness than intended. Coinkite's own advisory put worst-case entropy as low as 40 bits on the most-affected devices, compared to the 128 bits a proper Bitcoin seed should have. Multiple security research teams tracked rapid, coordinated sweeps of affected wallets following disclosure, and tracked losses grew quickly as more were identified. Estimates as of early August 2026 range from roughly $90 million to over $130 million.

Nothing about Bitcoin's cryptography itself was broken. The failure was entirely in the randomness feeding it, which is the exact distinction this guide is about. It's a useful, concrete example of why "cryptographically secure" isn't a marketing phrase: a wallet that used a merely random-looking generator instead of a genuinely unpredictable one turned a mathematically sound signature scheme into a guessable one.

The technical standard

The reference standard here, in the US, is NIST Special Publication 800-90A. It defines several approved mechanisms (deterministic random bit generators, or DRBGs) for producing cryptographically secure random output, based on hash functions, HMAC, or block ciphers like AES. NIST keeps developing this area too: SP 800-90C, which covers how those DRBG mechanisms combine with entropy sources into complete random bit generator constructions, came out in September 2025.

In your browser, that's what crypto.getRandomValues() implements. The demo above already shows the practical difference it makes. For the full picture of how that method fits alongside the rest of the Web Crypto API, including the other methods this site relies on for hashing and signing, see How the Web Crypto API Works.

Sources:

NIST SP 800-90A Rev. 1, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, csrc.nist.gov
NIST SP 800-90C, Recommendation for Random Bit Generator (RBG) Constructions (September 2025), nvlpubs.nist.gov
MDN Web Docs, Crypto: getRandomValues() method, developer.mozilla.org

How to check your own tools

Look for the actual function name in the code, not the marketing copy around it:

JavaScript (browser or Node.js): crypto.getRandomValues() or crypto.randomBytes(), not Math.random()
Python: the secrets module, not random
Most other languages: look for a name like SecureRandom or a dedicated crypto/rand package, distinct from the general-purpose random module

If you're generating a password, key, token, or anything else this site's generator covers, that's already handled for you. Every mode uses the Web Crypto API's CSPRNG. See the About page for the full methodology.

Frequently asked questions

Is Math.random() ever okay to use?

Yes, for anything where predictability doesn't matter: shuffling a display order, a random UI animation delay, a non-security game mechanic. The line is simple. If guessing the output would let someone bypass security or predict a secret, use a CSPRNG instead.

How do I know if my own code is using a CSPRNG?

See the checklist above. Look for the specific function name, not general claims of "randomness" or "security" in a library's description.