- La promoción de Cloudflare sobre números aleatorios basados en lámparas de lava se parece más a marketing y teatro de seguridad que a una gran contribución práctica al cifrado de Internet
- En criptografía, lo importante no es la aleatoriedad intrínseca de un valor, sino cuánto sabe un atacante sobre ese valor; esa diferencia de conocimiento es la que determina la seguridad
- Un one-time pad oculta la información del texto original si usa una clave suficientemente aleatoria una sola vez, pero si la misma clave se reutiliza, se rompe al combinarse con la información observada
- Los sistemas modernos usan CSPRNG y cifrados de flujo en lugar de one-time pads, y ChaCha20 o AES-256-CTR ofrecen seguridad práctica con una clave de 256 bits
- Los true RNG físicos son difíciles de depurar de sesgos y aumentan poco la seguridad, por lo que un diseño simple donde el propio servidor genera la semilla y usa fast key erasure es más seguro
La aleatoriedad depende del conocimiento del observador, no del objeto
- Cloudflare promociona que las lámparas de lava ayudan al cifrado de Internet, pero este enfoque se parece más a marketing y teatro de seguridad que a un aporte importante a la seguridad
- Además de las lámparas de lava, Cloudflare usa dispositivos físicos de imprevisibilidad como dobles péndulos, movimiento de olas y móviles
- Una función al estilo XKCD que solo hace
return 4siempre devuelve 4, así que el objeto en sí no es aleatorio; pero si quien la llama solo sabe que es una “constante elegida con un dado justo” y la invoca una vez, entonces desde la distribución de probabilidad del observador puede tratarse como aleatoria - En criptografía, la pregunta importante no es si el resultado es intrínsecamente aleatorio, sino cuánto sabe el atacante sobre ese resultado
- Incluso para el mismo valor, el significado de la aleatoriedad cambia según quién tenga qué información, y en los sistemas criptográficos esa diferencia de conocimiento es la que determina la seguridad
Cómo funciona y cómo se rompe el one-time pad
- En la analogía de la ruleta rusa, un cómplice conoce la posición de la bala y solo anuncia hacia afuera el resultado de sumar a esa posición un valor de dado compartido previamente con el jugador
- El jugador puede reconstruir la posición de la bala restando el valor del dado al valor anunciado, pero un tercero no puede conocer la posición de la bala solo con el valor anunciado porque no conoce el valor del dado
- Si el dado es justo, la probabilidad previa
P(Ci)que tiene el tercero y la probabilidad posteriorP(Ci|S3)después de oír un número específicoS3resultan iguales - Con la fórmula de Bayes,
P(Ci|S3) = P(Ci) × 1/6 ÷ 1/6 = P(Ci); es decir, el tercero no aprende absolutamente nada al oír el valor anunciado - Esa estructura es el núcleo del one-time pad: si una clave suficientemente aleatoria se combina con el mensaje una sola vez, el texto cifrado no revela información sobre el texto original
- Si la misma clave se reutiliza en un segundo juego, la información revelada en el primero permite al tercero reducir el rango posible del valor del dado
- Si en el primer juego se confirma que las primeras cuatro cámaras del revólver están vacías, el tercero sabe que solo quedan como posibles los valores 3 o 4 del dado; y si luego el cómplice grita “Four”, además obtiene la información de que la bala está en la primera o en la última cámara
- El one-time pad es seguro, tal como indica su nombre, solo una vez; si se reutiliza la misma clave, los textos cifrados observados se combinan con la información previa y la seguridad colapsa
Longitud de clave y la seguridad práctica del cifrado moderno
- En Internet se envían bits y bytes en lugar de posiciones de bala, y un mensaje de un bit de tipo “sí/no” puede ocultarse con un solo lanzamiento de moneda
- Si sale cara se deja el mensaje tal cual, y si sale cruz se invierten “sí” y “no”; para un observador que no conoce el resultado de la moneda, el mensaje original queda oculto
- Pero si se cifran dos bits con el mismo resultado de moneda, el texto cifrado reduce las cuatro posibilidades de texto original a dos
- “Sí sí” significa que el original fue “sí sí” o “no no”
- “No no” significa que el original fue “no no” o “sí sí”
- “Sí no” significa que el original fue “sí no” o “no sí”
- “No sí” significa que el original fue “no sí” o “sí no”
- En general, al cifrar n bits con un solo lanzamiento de moneda, el espacio posible de textos originales se reduce de
2^na 2 - En un sentido completamente de teoría de la información, para cifrar correctamente n bits se necesita una clave de n bits; si el mensaje es más largo, una parte puede quedar descifrada, y si el observador ya conoce n bits o más de información, por lo general podría llegar a descifrar el mensaje completo
- Aplicar un one-time pad a todo el tráfico que procesa Cloudflare parecería requerir una cantidad astronómica de números aleatorios, pero los sistemas modernos no usan one-time pads
- Si se usan correctamente el cifrado autenticado y los cifrados de flujo, una clave de 256 bits permite cifrar grandes volúmenes de datos de manera prácticamente segura
- Con un cifrado de flujo adecuado como ChaCha20 o AES-256-CTR, un observador pasivo tendría que probar alrededor de
2^255combinaciones para encontrar el texto original - Para quien conoce la clave, el flujo es totalmente predecible, pero para un observador del nivel de una civilización terrestre que no conoce la clave, actúa como una “entropía” completamente impredecible
- El nombre formal de este enfoque es Cryptographically Secure Pseudo-Random Number Generator, abreviado CSPRNG
Generación real de números aleatorios y fast key erasure
- Para derivar la cantidad necesaria de números aleatorios a partir de una sola clave maestra de 256 bits, se puede guardar la clave maestra en un servidor maestro o en un módulo de seguridad de hardware, generar flujos locales de claves y distribuirlos de forma segura por toda la empresa
- Cada servidor o núcleo de CPU puede generar tantos bytes aleatorios como necesite usando una clave local de 256 bits y un contador
- El problema central es que la distribución segura es muy difícil
- Si una clave local se filtra, quedan en riesgo todos los mensajes que esa máquina cifró en el pasado y todos los que cifrará en el futuro; si se filtra la clave maestra, el daño es mucho mayor
- fast key erasure es un procedimiento para reducir la posibilidad de filtración de claves y el daño en caso de que ocurra
- Se coloca una semilla aleatoria de 32 bytes al inicio de un búfer de 512 bytes
- Con esa semilla se generan 512 bytes y se sobrescribe el búfer
- Se emite, según lo solicitado, todo salvo los primeros 32 bytes, y luego se borra
- Cuando se agota el búfer, se vuelve a la etapa de generación
- “erasure” viene de que la etapa de generación borra la clave anterior
- Si el búfer se filtra, los mensajes futuros podrían quedar en riesgo, pero los valores pasados que ya fueron emitidos y borrados siguen protegidos
- Una precaución aún más importante es no clonar el búfer
- No se deben crear dos flujos con la misma semilla
- Al hacer fork de un proceso, el flujo debe dividirse adecuadamente en dos
- Si aparecen dos o más flujos iguales, los mismos bytes aleatorios se repetirán y eso puede ser fatal
- Por eso no se recomiendan los RNG en espacio de usuario; el RNG del kernel no es fácil de auditar, pero al menos reduce la cantidad de componentes que hay que revisar
Elección del cifrado de flujo y margen de seguridad
- El tamaño interno de bloque del cifrado de flujo subyacente también importa
- El bloque de 512 bits de ChaCha20 es lo bastante grande como para no preocuparse, y el bloque de 128 bits de AES también es suficientemente grande
- Existen ataques prácticos contra AES con una probabilidad de éxito mucho mejor que una simple búsqueda exhaustiva; se considera que AES-128 podría romperse, pero AES-256 sigue siendo seguro
- Un tamaño de bloque más pequeño debe considerarse roto para este uso
- Las opciones recomendadas son ChaCha20 o AES-256, con preferencia por ChaCha20
- Los cifrados de flujo modernos son muy seguros y, considerando la literatura académica y los casos de uso de varios gobiernos, especialmente el de Estados Unidos, se considera muy improbable que se rompan en un futuro cercano
- Tanto el CSPRNG como el cifrado dependen del mismo tipo de primitivas criptográficas, así que si una de ellas se rompe, el sistema completo también cae
- Si se asume que existe una probabilidad significativa de que AES-256 o ChaCha20 se rompan en un futuro cercano, hay formas de aumentar el margen de seguridad
- Si se usa el mismo cifrado tanto para el CSPRNG como para el cifrado, se evita darle al atacante la opción de romper AES o ChaCha; en cambio, tendrá que romper uno específico
- Aumentar la cantidad de rondas ayuda no solo a elevar el costo de la fuerza bruta, sino también a bloquear ataques mejores que la búsqueda exhaustiva
- AES-256 usa 14 rondas y ChaCha20 usa 20 rondas
- Existen ataques contra ChaCha7 mejores que la búsqueda exhaustiva, pero actualmente no los hay contra ChaCha8
- ChaCha20 usa 20 rondas para dejar margen y evitar problemas incluso si de pronto se descubre un ataque de 12 rondas
- Usar varios sistemas en paralelo incrementa mucho la complejidad total, y esa complejidad tiene más probabilidades de crear vulnerabilidades fatales que un ataque matemático contra alguno de sus componentes
True RNG físicos y semilla inicial
- Hay que ser cauteloso con la idea de que un true RNG físico sea más seguro que un CSPRNG solo porque este último podría romperse en teoría
- Para fines de seguridad, muchas veces la salida aleatoria debe no tener sesgos detectables; esto significa una distribución tan uniforme que ni siquiera analizando
2^64muestras se pueda detectar un sesgo - Ajustar un proceso físico a ese nivel es difícil, así que en la práctica la salida de la fuente de ruido tiene que pasarse por un hash criptográfico
- Comparado con un cifrado de flujo que use fast key erasure, el aumento de seguridad es pequeño y, según el caso, el costo en rendimiento puede ser alto
- Para producir una cantidad arbitraria de números aleatorios, de todos modos se necesitan como punto de partida los primeros bytes de una semilla
- Si se registra digitalmente durante suficiente tiempo una fuente impredecible para obtener más de 256 bits de entropía, y luego ese registro se hashea con un hash de 256 bits como SHA-256 o BLAKE2s, se puede crear una semilla maestra
- Entre las posibles fuentes de aleatoriedad están un hardware random number generator, CPU jitter, una foto arbitraria de un árbol, un beam splitter, pulsaciones de teclado o eventos del mouse, dados, etc.
- Distribuir números aleatorios entre distintos sitios no es práctico, y además de complejo puede convertirse en una causa de intrusión
- Los números aleatorios no se necesitan una sola vez, sino cada vez que se sospecha una intrusión o se hace una actualización de seguridad importante
- Para reducir molestias y riesgos, por lo general es mejor que la propia computadora genere la semilla aleatoria que va a usar, en lugar de traerla desde afuera
- Un servidor común dispone de CPU jitter, interacción con periféricos y eventos de red, lo que normalmente basta para usos generales
- Si se quiere seguridad adicional, se pueden añadir algunos dongles de hardware RNG por rack de servidores, pero un enfoque más complejo es complejidad innecesaria
Por qué el muro de lámparas de lava es innecesario
- El muro de lámparas de lava de Cloudflare no es necesario y, si se conecta a los servidores a través de la red local, solo aumenta la complejidad y la superficie de ataque
- Si se implementa correctamente, el riesgo puede ser muy bajo, pero aun así es mayor que el beneficio obtenido
- Si Cloudflare se toma en serio la seguridad, debería dejar de usar lámparas de lava y conservarlas solo como decoración y marketing
- Es más simple y más seguro que cada servidor genere por sí mismo sus propios números aleatorios
- También es posible que Cloudflare ya esté haciendo eso
1 comentarios
Comentarios en Lobste.rs
Este artículo parece estar escrito con ideas equivocadas y además se siente un poco aguafiestas. La generación moderna de números aleatorios usa múltiples fuentes de entropía independientes, y mientras la computadora está funcionando las sigue mezclando en el pool de entropía mediante hashes
No es que la computadora tenga una sola “semilla aleatoria”, sino que durante la ejecución se vuelve a sembrar continuamente usando la entropía de varias fuentes, con algo como
seed = hash(seed, new_data). Agregar datos de una cámara que filme lámparas de lava no reduce en absoluto la seguridad del sistema. Los datos que entran al pool de entropía se hashean junto con otros datos que ya estaban ahí. Está diseñado para seguir siendo seguro aunque el atacante desconozca solo una pequeña parte de la información, así que mezclar muchos datos con distintos niveles de aleatoriedad no daña la seguridadLas lámparas de lava no perjudican la seguridad del sistema y, personalmente, me parecen una obra de arte alegre y funcional que forma parte del sistema. También mejoran, aunque sea de forma ínfima, la calidad de los números aleatorios y muestran visualmente los conceptos de aleatoriedad y entropía
Sí, pero los generadores aleatorios del kernel ya vienen usando desde hace más de 30 años diversas fuentes de aleatoriedad de hardware, y conviene no exagerar cuánto se resembran “constantemente” o “sin parar”
La aleatoriedad del hardware se recolecta de forma continua, pero el generador aleatorio de Linux se resembra periódicamente. Durante el primer minuto después del arranque, cada pocos segundos; después, se vuelve más lento, aproximadamente una vez por minuto
https://zx2c4.com/projects/linux-rng-5.17-5.18/…
No sé de dónde salió la impresión de que se estaba diciendo o insinuando que los sistemas existentes no fueran así. Aquí, aparte de la parte de las lámparas de lava, no se intentaba describir los sistemas actuales, sino enfatizar lo poco que realmente necesitamos, es decir, que 256 bits bastan
Cuando se dice que agregar datos de una cámara que filme lámparas de lava no reduce la seguridad, lo que a mí me viene a la mente es la superficie de ataque. Básicamente estás agregando una computadora embebida y la comunicación de red entre esa computadora y el servidor. Para mí, ese riesgo adicional, aunque sea pequeño, parece mucho mayor que el riesgo absurdamente bajo en el que de verdad harían falta las lámparas de lava
Una forma distinta de expresar la distinción filosófica sería esta: cuántos resultados posibles hay, y qué tan predecible es el resultado
Para fines criptográficos, la predictibilidad se ha fijado en torno a 2^-256, pero curiosamente hay procesos comunes con una cantidad de resultados posibles mucho mayor, y a veces uno quiere poder producir cualquiera de los resultados posibles, por improbable que sea. En esas situaciones, la aleatoriedad criptográfica podría no ser suficiente
Una baraja estándar tiene 52! mezclas posibles, lo que equivale a aproximadamente 2^226, así que una semilla criptográficamente aleatoria puede generar todas las mezclas. Pero si juegas Uno o mezclas varias barajas juntas, un generador aleatorio de 256 bits no tiene suficiente estado para producir todas las mezclas posibles. Si toda la aleatoriedad en espacio de usuario del sistema viene del kernel, y el kernel canaliza toda la aleatoriedad de hardware a través de un CSPRNG de 256 bits, quizá no alcance para mezclar cartas en Las Vegas :-)
Lo que falta en el artículo es el resembrado, que es interesante por cómo interactúa con el borrado rápido de claves y porque muestra la dificultad de obtener la semilla inicial. El artículo da a entender que Linux usa solo jitter de CPU, pero eso es una simplificación excesiva. Linux usa muchas fuentes de aleatoriedad, y el baile del jitter se usa solo como último recurso
En el mundo real, ni siquiera puedes obtener 2^128 muestras. De hecho, muchísimo menos, y por eso AES-128 sigue siendo suficientemente seguro para muchos usos. Cuando la cantidad de resultados posibles supera 2^256, “ejecutar todos los resultados posibles” es completamente imposible. Conviene olvidarse de eso. No existe
Incluso en blackjack, cuando se usan 6 barajas en vez de una, en realidad no quieres un proceso de mezclado que distribuya la probabilidad de manera uniforme sobre todas las mezclas posibles. Basta con una distribución lo bastante buena como para que no se pueda distinguir la diferencia aunque muestrees tanto como sea posible. Aunque el número de mezclas esté limitado a 2^256, o incluso a 2^128, no notarías la diferencia
Omitir el resembrado en el artículo fue intencional. Solo se necesita en momentos específicos, como una posible intrusión o ciertas actualizaciones de seguridad. También podría aplicar al reiniciar, si resulta más simple o más seguro que mantener el estado del generador aleatorio en memoria no volátil. Por eso prefiero verlo no tanto como “resembrar”, sino como volver a empezar con una nueva semilla inicial
Durante el funcionamiento normal no hace falta resembrar en absoluto. Implementarlo solo agrega complejidad
Sí debí haber verificado la insinuación de que Linux usa solo jitter de CPU. Según entendía, en el momento del arranque eso era lo único disponible. Sobre todo antes de que exista entrada del usuario o tráfico de red. ¿Conoces otras fuentes? Supongo que ya habrá soporte para generadores aleatorios de hardware
No se puede. Pero dejando eso de lado, así es como se puede hacer de forma segura…
Supongo que las tarjetas de hardware para generación aleatoria existían para obtener fuentes paralelas de aleatoriedad medidas no solo por densidad de bits, sino también por cantidad de bits por unidad de tiempo
No hay muchas afirmaciones individuales con las que discrepe mucho, pero el argumento general me pareció difuso. El artículo se construye alrededor de “la criptografía moderna necesita mucha menos aleatoriedad real de la que la gente cree”, y luego aterriza en “por lo tanto, las lámparas de lava son peores porque amplían la superficie de ataque”
Ambas afirmaciones pueden ser ciertas, pero la transición hacia la conclusión se siente brusca
LavaRand ya estaba haciendo esto hace más de 20 años. En ese momento era adorable, pero en aquella época los sensores de cámara eran mucho más pequeños y, por características predecibles del lente y demás, no eran buenas fuentes de entropía
Aunque me gustan las lámparas de lava, el consumo eléctrico de un muro con cientos de ellas me parece bastante alto para un dispositivo más bien de juguete
Esto roza la autopromoción. Casi no comparte enlaces, y cuando lo hace, publica enlaces propios. Sus 5 publicaciones más recientes apuntan las 5 a su propio material
“Está bien que el autor participe en la comunidad, pero no debería abusar de ella como si fuera una herramienta de solo escritura para lanzar productos o desviar tráfico hacia su propio trabajo. Como regla general, la autopromoción debería ser menos de una cuarta parte de sus propias stories y comments.”
Si tiene 15 publicaciones y 1399 comentarios, claramente sí participa en la comunidad. A menos, claro, que esté dejando más de 90 comentarios propios en cada una de sus publicaciones
Cloudflare aportó entropía obtenida de lámparas de lava, la University of Chile aportó datos sísmicos, si mal no recuerdo EPFL aportó mediciones de desintegración radiactiva, y muchos otros participantes aportaron distintos materiales a la ceremonia inicial de generación de claves de la red drand
¿Podrían haber usado un CSPRNG? Claro. Pero entonces, ¿dónde quedaría la diversión?