¿El generador de números aleatorios de AMD no puede generar un 0?

Artículo original ↗ Discusión en Hacker News ↗

Las CPU de AMD parecen tener un error en el que la instrucción de número aleatorio de hardware de ciertas generaciones (en particular `rdrand16` de Zen 2) casi nunca produce un 0 real, o etiqueta las salidas cero como fallos, lo que plantea dudas sobre sesgos en valores que se supone que deben ser uniformemente aleatorios. Los comentaristas señalan que la mayoría de los sistemas no usan estos números de hardware directamente, sino como semillas para RNG de software más robustos, y que los kernels modernos mezclan múltiples fuentes de entropía, por lo que una sola fuente defectuosa no debería ser catastrófica; aun así, la historia muestra que incluso pequeños sesgos en RNG pueden convertirse en vulnerabilidades reales. El hilo se amplía hacia si se debe confiar en RNG opacos implementados por el fabricante, cómo protegen los kernels frente a fuentes de entropía malas o maliciosas, y los riesgos de implementar RNG criptográficos personalizados en espacio de usuario.

Naturaleza del error del RNG de AMD

  • Los informes se centran en CPUs de la era Zen 1/2, donde RDRAND16 parece no devolver nunca 0, mientras que RDRAND32/64 sí lo hacen.
  • Pruebas más detalladas muestran que RDRAND16 sí puede generar internamente 0, pero cuando lo hace, el indicador de acarreo (CF) se establece en 0, señalando “fallo / reintentar.”
    • Los envoltorios típicos descartan entonces estos resultados y repiten el bucle, de modo que el código de usuario, en la práctica, nunca ve un cero de 16 bits.
  • La tasa de “fallos” con CF=0 coincide con 1/65536 y todos esos fallos devuelven 0, lo que sugiere un comportamiento sistemático en lugar de una simple ausencia de 0.
  • Las generaciones más nuevas (Zen 3/4) no muestran el problema en las pruebas; Zen 5 tiene un erratum relacionado con RDSEED en el que un resultado todo ceros con CF=1 puede llevar a soluciones similares que reintroducen el comportamiento de “nunca cero”.

Relación con problemas anteriores del RNG de hardware

  • Errores anteriores de microcódigo en Zen 2 hacían que RDRAND devolviera siempre todo 1 hasta que se actualizaba.
  • Existe la preocupación de que las “correcciones” de microcódigo puedan haber cambiado un patrón de error (todo 1) por otro (sin 0s).
  • Algunos operadores de sistemas dejaron de confiar en el RNG de la CPU en el kernel de Linux debido a este tipo de fallos de AMD.

Impacto en seguridad y calidad de la aleatoriedad

  • Una postura: el impacto práctico es mínimo porque:
    • El RNG de hardware normalmente solo se usa para sembrar un CSPRNG, como el pool del kernel.
    • Perder 1 valor de 2^16 (o 2^32/2^64) apenas reduce el espacio de claves.
  • La otra postura: cualquier sesgo sistemático es una señal de alerta:
    • La historia criptográfica muestra que pequeños sesgos pueden volverse explotables en algunos protocolos.
    • Incluso si este sesgo concreto probablemente es inofensivo, desestimar estos fallos se considera arriesgado.
  • El hilo repasa conceptos básicos:
    • La salida deseada es una distribución uniforme discreta; “nunca 0” es un sesgo.
    • La predictibilidad no es solo “no ser siempre el mismo valor”, sino “no favorecer ningún valor ni predicado”.

Mezcla de entropía y confianza en hardware

  • Amplio consenso: no depender de un único RNG de hardware opaco; mezclar varias fuentes mediante una construcción robusta (CSPRNG, sponge o XOF).
  • Debate sobre:
    • Si añadir una fuente “mala” pero no maliciosa puede empeorar alguna vez un buen pool (la mayoría dice que no; otros citan ataques en los que una fuente maliciosa que ve otras entradas puede sesgar la salida).
    • Si es mejor usar siempre interfaces del kernel (/dev/urandom, getentropy/getrandom) en lugar de implementar RNGs en userland.
  • Algunos argumentan con firmeza contra los RNGs personalizados (historial de fallos reales); otros defienden diseños personalizados maduros y probados durante mucho tiempo basados en XOF, especialmente para uso multiplataforma o embebido.

Validación, pruebas y cómo pasó desapercibido

  • Varios comentaristas se sorprenden de que un error de distribución tan simple superara la validación de hardware; las hipótesis incluyen:
    • Planes de verificación incompletos (sin un bin de cobertura específico para 0).
    • Errores de uno en uno.
  • Nota práctica: construir histogramas de las 65.536 salidas de 16 bits es una prueba de caja negra sencilla que debería detectar este tipo de error.