A CSPRNG is a cryptographically secure pseudorandom number generator. It calculates new values from a secret internal state by following a precise procedure. “Pseudorandom” does not mean poor quality: the calculation is repeatable, but its results should be practically unpredictable without the secret state. This requires sufficient entropy—uncertainty in the input that an attacker does not know—and correct integration into the application.
Imagine a program creating secret values for a wallet. An attacker discovers some of its earlier outputs. A secure generator must not let that knowledge make the remaining values easier to guess. This demands more than an attractive distribution of numbers on a chart. RFC 4086 therefore distinguishes cryptographically strong sequences from ordinary simulation generators. Even a good statistical test result is insufficient if the seed, the starting value used to initialize generation, can be guessed. [1]
Technical documentation also uses DRBG, meaning deterministic random bit generator. “Deterministic” means that the same state and inputs produce the same result, so the state must remain secret. NIST SP 800-90A Rev. 1 describes specific mechanisms: Hash_DRBG, HMAC_DRBG and CTR_DRBG. These are technical procedures, not a seal of quality for every program that names them. A review must also examine configuration, the origin of entropy and the actual code implementation. [2]
A state leak raises two different questions. Can an attacker reconstruct earlier secret outputs? Can they predict the next ones? Protection of past outputs is called Backtracking resistance; protection of future outputs is Prediction resistance. For the latter, NIST SP 800-90A requires effective incorporation of fresh entropy to separate new results from the exposed state. Simply running the calculation again may not restore security. Having one protection does not automatically establish the other. [2]
A library is a ready-made software component that a wallet can use, but calling it can fail. In OpenSSL 3.5, RAND_bytes() and RAND_priv_bytes() return 1 on success, 0 on other failure and -1 when the current method is unsupported. Generation may be refused if the entropy source fails. The program must check that result before using the reserved memory area, known as a buffer. Otherwise, it could use data that was never securely generated. [3]
Repeatability helps testing: a developer wants the same result again to compare it with an expected value. The libsodium function randombytes_buf_deterministic() therefore produces the same sequence from the same seed. In normal operation, unintended repetition is a problem. A virtual-machine snapshot saves a computer’s state, including its memory; restoring it may also repeat the generator’s state and output. Copies of an environment therefore need not produce independent secrets. [4]
A generator can supply good random data that an application then handles incorrectly. Converting it into a smaller permitted range using a simple division remainder can make some outcomes more frequent than others. The libsodium function randombytes_uniform() addresses this through uniform selection below a specified upper bound. Keys must also satisfy their particular algorithm’s rules. Security does not end with obtaining random bytes: what happens to them next matters too. [4]
A nonce is a value intended for an individual use in a cryptographic procedure, but the protocol determines its rules. RFC 8439 requires that a nonce never repeat with the same key; a random appearance alone does not guarantee uniqueness. RFC 6979 instead describes deterministic calculation of the value k needed for a digital signature from the secret key and the message being signed. These are different designs, not a contradiction. “Add randomness everywhere” is no substitute for following the correct procedure. [5] [6]
The CSPRNG label alone does not tell you whether a wallet uses the whole system correctly. A technical review examines the specific library version, generator startup, error handling and behavior after state restoration or copying. OpenSSL and libsodium documentation establishes properties of their functions, not the security of every application calling them. What happens afterwards matters to users too: a perfectly generated secret stops protecting funds if a backup that restores access later leaks. [3] [4]
For the clearest picture, read this entry together with Cryptographic Entropy, Random Number Generator, Deterministic RNG, Seed Generation. The reverse links also lead from Dice Roll Entropy, Cryptographic Entropy, Random Number Generator, Deterministic RNG.