Tu HSM ya tiene un TRNG. Sigue sin poder demostrar nada.

1. "Tenemos aleatoriedad real" no es un argumento de seguridad

Linux ya incluye /dev/random, getrandom() e instrucciones de CPU como RDRAND. La mayoría de HSM, TPM y proveedores de KMS en la nube integran sus propios TRNG por hardware. Decirle a un ingeniero de seguridad "nuestra entropía es real" junto a eso no diferencia nada: la suya, casi siempre, también lo es.

La pregunta que realmente importa es otra: ¿qué pasa si esa única fuente resulta defectuosa, tiene una puerta trasera o simplemente falla, y cómo lo sabría alguien? Dual_EC_DRBG se distribuyó como PRNG avalado por el NIST con una presunta puerta trasera durante años antes de demostrarse. El kernel de Linux todavía se niega a confiar solo en RDRAND, y lo mezcla en el pool en lugar de usarlo directamente.

2. No sustituyas tu RNG. Mézclale uno independiente.

Galactropy no es un sustituto directo de tu HSM o TPM. Es una segunda fuente de entropía, físicamente independiente: ruido de radio muestreado por hardware SDR y acondicionado con SHA-512, que incorporas al pool que ya alimenta la generación de tus claves. Es la práctica estándar para combinar fuentes de entropía: mientras una de las fuentes mezcladas sea genuinamente impredecible, la salida combinada también lo es, pase lo que pase con las demás.

3. Ser independiente no basta. También debe ser verificable.

El RNG de un HSM o un KMS en la nube es una caja cerrada: confías en el certificado del proveedor y en nada más. Cada lote que producen los nodos de Galactropy se comprueba con Dieharder, ENT y rngtest, se encadena con firmas Ed25519 y se ancla en la blockchain de Bitcoin mediante OpenTimestamps, así el registro no se puede alterar en silencio después, ni por nosotros ni por nadie más.

4. Mezclarla lleva una sola línea

Obtén bytes en bruto de la API pública e incorpóralos a tu pool de entropía existente antes de derivar claves:

curl -s "https://galactropy.com/raw?bytes=512" >> /dev/urandom