Betriebssysteme stellen einen bereit, dessen Seed aus Hardware-Entropie stammt: getrandom(2) und /dev/urandom unter Linux, getentropy und arc4random unter macOS und den BSDs, BCryptGenRandom unter Windows. Die APIs der Programmiersprachen kapseln sie: crypto.getRandomValues() in Browsern (höchstens 65.536 Byte pro Aufruf), crypto.randomBytes in Node.js, secrets in Python, crypto/rand in Go, SecureRandom in Java. Math.random(), random in Python und ähnliche Allzweckgeneratoren sind vorhersagbar und dürfen niemals Secrets erzeugen.
NIST SP 800-90A Rev. 1 spezifiziert die zugelassenen deterministischen Generatoren (Hash_DRBG, HMAC_DRBG und CTR_DRBG), SP 800-90B die Entropiequellen und SP 800-90C, wie sie kombiniert werden; Module nach FIPS 140-3 müssen sie verwenden. Der zurückgezogene Dual_EC_DRBG ist das Lehrbuchbeispiel für einen Generator mit mutmaßlicher Hintertür.
Die meisten RNG-Fehler in der Praxis betreffen das Seeding, nicht die Algorithmen: eingebettete Geräte, die Schlüssel erzeugen, bevor genug Entropie verfügbar ist, geklonte virtuelle Maschinen, die mit demselben Zustand weiterlaufen, und per fork abgespaltene Prozesse, die sich einen Generator teilen. ECDSA ist besonders empfindlich, weil eine vorhersagbare Nonce den Schlüssel preisgibt; deterministische Nonces oder Hedged Nonces beseitigen diese Abhängigkeit.