secrets vs urandom vs getrandbits: Localhost Lab

Intro — what this post promises

How fast can you mint random bytes — secrets.token_bytes, os.urandom, or random.getrandbits → bytes? This lab reports MB/s (and ops/s for small sizes) on Linux localhost.

It is not a remake of the uuid4 vs secrets token localhost lab (UUID/token formatting ops/s). Here the focus is bulk byte generation and the crypto vs non-crypto fork: use secrets / os.urandom for security-sensitive material; use random only for simulations / fuzz / non-secret noise.

Related links:

• 01shoppercove.comuuid4 vs secrets token localhost lab
• 02shoppercove.comhashlib md5 vs blake2b localhost lab
• 03shoppercove.combytesio vs spooled tempfile localhost lab
• 04shoppercove.comweakref vs dict cache localhost lab
• 05shoppercove.compickle vs json roundtrip localhost lab
• 06shoppercove.comdecimal vs float sum localhost lab
• 07shoppercove.combytes vs bytearray localhost lab
• 08shoppercove.comcsv reader vs split localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. Affiliates: 0. No Docker. Not a cryptographic proof — throughput + clear API guidance only.

Verdict up front (1 MiB): secrets.token_bytes ~552.7 MB/s ≈ os.urandom ~551.9 MB/s; chunked getrandbits ~48.5 MB/s (~11.39× slower). At 16 B tokens, urandom ~3.32 Mops/s beat secrets ~1.46 Mops/s — still use secrets for API clarity on security paths.

Arms

Lab topology

sizes: 16 B / 32 B / 1 KiB / 64 KiB / 1 MiB · 7 rounds · p50
metric: MB/s = nbytes / p50_s ; ops/s for small tokens

Script: lab-evidence/88-secrets-vs-urandom/results/run_lab.py.

Lead table — bulk (p50 MB/s)

Oneshot getrandbits(n*8).to_bytes(...) at 64 KiB hit ~492.3 MB/s — closer to CSPRNG speed, still not suitable for secrets.

Small tokens (ops/s)

Reading it

• secrets ≈ os.urandom for bulk on this host (~550 MB/s  MiB) — secrets is the right default API for passwords/tokens/keys.
• random.getrandbits is for games/sim, and naive 8-byte chunked packing was ~11.39× slower than CSPRNG here — oneshot closes the gap but does not become cryptographically safe.
• Do not pick random because a microbench looked hot at 16 B.

Security framing (short)

Differentiation from lab 41

Lab 41 compared uuid4 vs secrets.token_hex / token_urlsafe mint rates. This lab streams raw bytes across sizes and includes random.getrandbits, with an explicit non-crypto warning.

Bulk vs token minting

At 16–32 B the metric that matters is ops/s (auth cookies, CSRF). At ≥1 KiB, MB/s matters (key material, padding, test payloads). On this box both CSPRNG APIs converge near ~550 MB/s once buffers are large; the interesting fork is whether random is allowed at all — for secrets, no.

Pitfalls

• Using random for tokens because it is “fast enough”.
• Building bytes with many tiny getrandbits calls (chunked tax).
• Assuming MB/s equality means API indifference — prefer secrets in security code for intent and reviewability.
• Seeding random and thinking that makes it secure.

Reproduce

python3 lab-evidence/88-secrets-vs-urandom/results/run_lab.py

Evidence: summary.json, summary.txt.

Limits

One Linux box (/dev/urandom backed). Not a NIST CSPRNG audit. Free-threaded / alternate RNG builds may differ.

Takeaway

For bulk CSPRNG bytes, secrets.token_bytes ~552.7 MB/s ≈ os.urandom. For non-crypto noise, getrandbits is fine — but never for secrets. Prefer secrets in security paths even when urandom wins a few ops/s at 16 B.