Random: OS-entropy tokens

akurai-rand is the framework's only source of unpredictable values. It reads the kernel CSPRNG at /dev/urandom with std::fs — no external crate, no userspace generator, no seed to leak. On Linux, macOS, and the BSDs this device never blocks once the system has booted.

There is no fallback. If the device cannot be opened or read, every function returns io::Error. A session id, share link, or device token minted from clock bits and a pid is a security bug, not a degraded mode, so the framework refuses to produce one.

API

use akurai_rand::{secure_bytes, token_hex, token_url, uniform_u32};

let key   = secure_bytes(32)?;      // Vec<u8>, 32 bytes
let id    = token_hex(16)?;         // "3f9a…" — 32 lowercase hex chars (128 bits)
let link  = token_url(32)?;         // "Qm3x…" — 43 base64url chars, no padding (256 bits)
let digit = uniform_u32(10)?;       // 0..10, rejection-sampled (no modulo bias)

| Function | Use it for | | --- | --- | | secure_bytes(n) / fill(&mut buf) | HMAC keys, nonces, salts as raw bytes | | token_hex(n) | opaque ids stored in the B+tree, log-safe | | token_url(n) | anything that travels in a URL, cookie, or filename | | uniform_u32(bound) | OTP digits, random choice among bound items |

Sizing tokens

• 16 bytes (128 bits) — session ids, record ids. Collisions and guessing

are both infeasible.

• 32 bytes (256 bits) — bearer tokens and public share links that must stay

unguessable for years.

Where the framework uses it

Auth session ids, password salts, and email-OTP codes (Auth & sessions) all come from akurai-rand. Applications should mint device tokens, API keys, CSRF tokens, and share-link secrets the same way.