auditing-randomness-and-nonce-qualitylisted

# Auditing randomness and nonce quality: when the secret is guessable by construction A whole class of secrets is broken not by a flaw in the algorithm around them but by where their bytes came from. A password-reset token from a statistical generator can be reconstructed from a few prior outputs. A generator seeded from the clock produces the same token twice. A nonce reused across two messages under one key can collapse a mode's confidentiality or leak its authentication key. A token that is unpredictable but only thirty-two bits long is brute-forceable anyway. In every case the cipher, mode, and hash can be perfectly chosen; the value is guessable because of the randomness, the seed, the nonce lifecycle, or the length. You find these by tracing each security-sensitive value back to the generator that produced it and asking whether an attacker can predict or repeat it. ## When to use - A generated value is the only thing standing between an attacker and an account, a message, or a request. - Tokens, links, codes, session identifiers, nonces, or initialization vectors are produced somewhere in the code. - You want to separate a value that is unpredictable by construction from one that only looks random. ## Scope check Assess randomness only in code you own or are authorized to review, and reproduce predictability only against test data. Demonstrating that a real token is guessable can expose live accounts, so treat a confirmed finding as sensitive and coordinate. If you