Les systèmes d’exploitation en fournissent un, dont la graine provient de l’entropie matérielle : getrandom(2) et /dev/urandom sous Linux, getentropy et arc4random sous macOS et les BSD, BCryptGenRandom sous Windows. Les API des langages les encapsulent : crypto.getRandomValues() dans les navigateurs (65 536 octets au maximum par appel), crypto.randomBytes dans Node.js, secrets en Python, crypto/rand en Go, SecureRandom en Java. Math.random(), le module random de Python et les générateurs généralistes du même type sont prévisibles et ne doivent jamais produire de secrets.
La NIST SP 800-90A Rev. 1 spécifie les générateurs déterministes approuvés (Hash_DRBG, HMAC_DRBG et CTR_DRBG), la SP 800-90B les sources d’entropie et la SP 800-90C la manière de les combiner ; les modules FIPS 140-3 doivent les utiliser. Dual_EC_DRBG, aujourd’hui retiré, est l’exemple classique d’un générateur soupçonné de contenir une porte dérobée.
La plupart des défaillances réelles de RNG tiennent à l’initialisation de la graine, pas aux algorithmes : des appareils embarqués qui génèrent des clés avant de disposer d’assez d’entropie, des machines virtuelles clonées qui reprennent avec le même état, des processus créés par fork qui partagent un générateur. ECDSA y est particulièrement sensible, car un nonce prévisible expose la clé ; les nonces déterministes ou hedged (déterministes avec ajout d’aléa) suppriment cette dépendance.