Text & everyday tools · Password Generator
PRNG vs CSPRNG: where your browser's random numbers actually come from
· Background
passwords web-crypto csprng
Explains the difference between pseudo-random and cryptographically secure generators, how operating systems gather entropy from hardware events, and how that randomness reaches a web page through the Web Crypto API.
Computers are deterministic, so where does randomness come from? — the basic puzzle behind every generator
JavaScript running in ToolAcre begins at an API boundary. It can request bytes from `crypto.getRandomValues`, observe whether that call succeeds and use the returned array. It cannot inspect every physical event, kernel pool or hardware component that a particular platform may use underneath. The workbook’s origin story for randomness therefore exceeds local evidence.
A technically honest explanation starts where observation starts. The app probes Web Crypto, the engine wraps it and all selections consume that source. Platform-specific internals need platform documentation and audits, not a generic statement inferred from the browser method name.
The repository starts at the browser API; it does not audit physical entropy sources
Pseudo-random generators are often described by seeds and reproducible state, but JavaScript engines are not required by this repository to share one Math.random design. ToolAcre avoids the ambiguity by forbidding the API entirely in credential production. Source scans enforce that negative guarantee.
Tests still need deterministic bytes, so they inject objects exposing `getRandomValues` through an internal parameter. Those fakes live in test support and are not exported as a seeded production mode. Testability does not create a hidden user option for repeatable passwords.
Math.random is forbidden here, without claiming one universal PRNG design
The product uses “cryptographic” in a scoped way: the required browser interface is Web Crypto, and generation fails closed when it is absent or unusable. The app calls the method during detection instead of checking only its type, catching restricted environments where invocation throws.
That contract does not promise resistance to every hypothetical state compromise or certify a browser implementation. It proves which API the page requests and that no weaker fallback is wired alongside it. Device integrity remains outside the generator.
The verified cryptographic property is the required Web Crypto source and refusal path
Timing events, dedicated processor instructions, reseeding schedules and operating-system entropy pools are all beneath the Web API surface. None is asserted here because the package source cannot verify them. A future platform-specific article would need primary documentation for each environment it describes.
The omission strengthens rather than weakens the current claim. ToolAcre can say exactly what it asks the browser to do and how it treats the bytes. It need not pretend JavaScript can audit the full entropy chain to justify refusing Math.random.
Hardware-event and operating-system-pool details are implementation claims this source does not prove
`getRandomValues` fills a `Uint8Array` sized from the requested exclusive bound. `secureRandomInt` assembles those bytes as an unsigned big-endian number, computes the largest divisible acceptance window and discards values in the remainder. The accepted value is then reduced to an index.
Words, delimiters, characters and shuffle swaps all reuse this path. A single choke point makes the browser-to-choice chain reviewable and ensures that fixing bounded reduction affects every generation mode rather than one forgotten caller.
From getRandomValues to secureRandomInt: the visible browser-to-index path
For a 7,776-word pool, the function selects enough bytes to represent every valid index. It forms an integer, rejects any value at or above the calculated limit and returns the remainder only after acceptance. `secureRandomChoice` uses that result to read one word from the eligible array.
The particular production index is private and should not be reproduced in documentation. Deterministic tests instead feed known tail and in-range bytes to prove control flow. This traces one selection without turning a generated phrase into a public example.
Worked example: trace bytes through rejection sampling to one list index
Hardware random-number generator design and formal cryptographic proofs are not covered by the package. Neither are server runtimes or native applications. The implementation is a browser generator and its guarantees should not be copied onto unrelated systems.
It also does not address storage or later use. A value selected through Web Crypto can still be exposed by reuse, phishing, clipboard history or malware. CSPRNG choice solves the source problem, not every credential-handling problem.
The takeaway — the Password Generator asks the browser's cryptographic generator, which is the right source for a secret
The actionable chain is short: test that Web Crypto works, refuse generation when it does not, fill bytes, reject an uneven tail and map the accepted value to an index. ToolAcre makes each step visible and tests difficult bounds.
Review that chain instead of relying on a vague “random” label. Then review the endpoint and destination separately. The browser’s cryptographic API is the correct source for this product, but the repository does not claim to certify what lies below it or everything that follows.