- La crítica central es que, en el proceso de impulsar a Kyber-512 como estándar de criptografía poscuántica, NIST calculó mal el costo de los ataques e infló su nivel de seguridad.
- El punto en disputa es que el costo computacional y el costo de acceso a memoria de cada iteración deben sumarse, pero NIST los trató como si se multiplicaran, añadiendo “40 bits extra de seguridad” a la estimación de 2^137 de Matzov.
- Kyber-512 fue presentado con un nivel de alrededor de 2^118 según Core-SVP, y NIST intentó alinearlo con unas 2^143 bit operations de AES-128, pero se le critica que las unidades y el significado de las cifras combinadas no coinciden.
- Se compara que Kyber solo ofrece opciones limitadas de parámetros como Kyber-512, Kyber-768 y Kyber-1024, mientras que NTRU y NTRU Prime ofrecen opciones más finas de tamaño y nivel de seguridad.
- La estandarización de Kyber-512 carga con incertidumbre en el análisis de ataques, falta de cuantificación del modelo de costos de memoria y escasa revisión pública; el autor pide retirar Kyber-512 y que NIST haga público su error de cálculo.
El núcleo del error de cálculo
- El punto de partida es un ejemplo simple: “2^40 + 2^40 no es 2^80 sino 2^41”.
- Si se confunden los números que deben multiplicarse con los que deben sumarse, el nivel de seguridad puede inflarse enormemente.
- La estructura problemática en la discusión sobre la seguridad de Kyber-512 es la siguiente:
- El ataque está compuesto por muchas iteraciones.
- Cada iteración tiene un costo computacional y un costo de acceso a memoria.
- El costo total debe calcularse como
número de iteraciones × costo por iteración. - Dentro del costo por iteración, el costo computacional y el costo de acceso a memoria deben sumarse.
- La crítica clave es que NIST produjo el efecto de multiplicar el costo computacional y el costo de acceso a memoria en lugar de sumarlos.
- Por ejemplo, 2^25 bit operations/iteration y 2^35 bit operations/iteration deben sumarse.
- Si se multiplican, la unidad pasa a ser
bitops^2/iter^2, que no es una unidad de costo de ataque. - Esa multiplicación puede inflar el costo del ataque por millones de veces o más.
Contexto de NISTPQC y Kyber-512
- NIST anunció en 2022 su plan de estandarizar Kyber-512 y en 2023 publicó un borrador de estándar para Kyber-512.
- El foco de la crítica es que NIST cometió un grave error de cálculo al justificar el nivel de seguridad de Kyber-512.
- En marzo de 2022 se presentó una solicitud FOIA relacionada con NSA, NIST, and post-quantum cryptography, y luego parte de documentos internos de NIST se revelaron mediante litigio.
- A partir de la comparación entre documentos públicos y no públicos, se sostiene que la participación de la NSA en el proceso NISTPQC fue mayor de lo que NIST explicó públicamente.
- Se indica que en 2016 la lista del equipo
pqc@nist.govincluía más personal de la NSA que de NIST. - NIST había señalado en materiales públicos de 2020 que la retroalimentación de la NSA no influía en las decisiones y que solo NIST tomaba decisiones con base en información pública.
- En enero de 2023 se presentó una nueva solicitud FOIA relacionada con las afirmaciones sobre el nivel de seguridad de Kyber-512, y se afirma que NIST volvió a retrasar su respuesta, lo que llevó a una nueva demanda.
La selección limitada de parámetros de Kyber
- Se señala que Kyber, a diferencia de RSA, ECC, McEliece o NTRU, no permite aumentar gradualmente el nivel de seguridad al tamaño deseado.
- No existe Kyber-576, y la siguiente opción más fuerte después de Kyber-512 es Kyber-768, lo que exige un aumento de dimensión del 50%.
- La siguiente opción más fuerte después de Kyber-768 es Kyber-1024.
- No se ofrece una opción más fuerte que Kyber-1024.
- La documentación oficial de Kyber destacaba como ventaja que todos los conjuntos de parámetros podían procesarse con “dimension-256 NTT”, pero en esa estructura una dimensión que no sea múltiplo de 256 exige cambios de diseño fundamentales.
- En aplicaciones con límite de 1KB, es difícil usar Kyber-768 y Kyber-512 se convierte en la opción Kyber de mayor seguridad.
- Kyber-768 usa una public key de 1184 bytes y un ciphertext de 1088 bytes.
- Kyber-512 usa una key de 800 bytes y un ciphertext de 768 bytes.
- Se compara que, con el mismo límite de 1KB, la familia NTRU ofrece estimaciones Core-SVP más altas.
sntrup653: key de 994 bytes, ciphertext de 897 bytes, Core-SVP 2^129- NTRU-677 (
ntruhps2048677): key de 931 bytes, ciphertext de 931 bytes, Core-SVP 2^145 - La versión round-3 de Kyber-512 se presentó con Core-SVP 2^118
- Core-SVP es el mecanismo que el equipo de Kyber usó para estimar niveles de seguridad en sus entregas round-1 y round-2, y el informe round-2 de NIST de 2020 también utilizó Core-SVP para comparaciones.
Criterios de evaluación de NIST y comparación con NTRU
- La convocatoria oficial de NIST de 2016 incluía la flexibilidad como criterio de evaluación.
- Bajo el supuesto de “buena seguridad general y rendimiento”, se consideraba que los esquemas con mayor flexibilidad podían satisfacer mejor más necesidades de los usuarios.
- Se especificaba que incluso dentro de una misma categoría podían presentarse varios conjuntos de parámetros para ajustar rendimiento o margen de seguridad.
- En 2020, al descartar NewHope, NIST mencionó como una de las razones que Kyber soportaba de forma natural un conjunto de parámetros de categoría 3.
- Si Kyber-512 no alcanza el nivel mínimo de seguridad, en Kyber solo quedarían Kyber-768 y Kyber-1024, agravando el problema de menor flexibilidad frente a NTRU.
- El selection report de NIST de 2022 dijo tener confianza en la seguridad tanto de Kyber como de NTRU, y evaluó que el rendimiento general de los KEM era aceptable para aplicaciones de propósito general.
- Bajo esas condiciones, la lógica es que si Kyber-512 se elimina, NTRU queda mejor posicionado que Kyber al ofrecer una opción más pequeña, una opción de mayor seguridad y compromisos tamaño/seguridad más finos.
Cuatro críticas a que NIST inclinó la competencia
-
1. Ignorar la flexibilidad adicional de NTRU
- Se afirma que la literatura de NTRU venía mostrando desde hace tiempo que podía ofrecer varias opciones de nivel de seguridad y tamaño.
- En 2020, NIST publicó que “too many parameter sets” dificultan la evaluación y el análisis.
- Se señala que en los criterios oficiales la flexibilidad se presentaba como algo positivo, pero a mitad del proceso apareció la crítica de “too many”, y NIST no respondió con claridad dónde estaba ese límite.
-
2. Exagerar el costo de generación de claves
- En benchmarks sobre Golden Cove, Kyber-512 tiene 25829 cycles para encapsulation y 20847 cycles para decapsulation.
- NTRU-509 tiene 15759 cycles para encapsulation y 25134 cycles para decapsulation, por lo que se presenta que el total de procesamiento del ciphertext es 13% menor que en Kyber-512.
- En cambio, la key generation de NTRU-509 es de 112866 cycles, mayor que los 17777 cycles de Kyber-512.
- Sin embargo, se argumenta que en un KEM una clave puede reutilizarse para muchos ciphertexts, que el costo de enviar y recibir bytes es mucho más importante que los cycles, y que con el Montgomery trick la key generation de NTRU puede acelerarse.
-
3. Ocultar el mayor nivel de seguridad de NTRU
- En su informe round-2 de 2020, NIST empezó a recomendar con fuerza los conjuntos de parámetros de categoría 5.
- Se afirma que NTRU presentó NTRU-1229 y NTRU-HRSS-1373, con Core-SVP 2^301 y 2^310 respectivamente, superiores al 2^254 de Kyber-1024.
- NTRU Prime también presentó opciones como
sntrup1277yntrulpr1277con Core-SVP 2^270 y 2^271. - Se critica que los gráficos de NIST no mostraban adecuadamente estas opciones NTRU de seguridad más alta.
-
4. Excluir NTRU-509, la opción de mejor rendimiento
- Se señala que NIST excluyó NTRU-509 de un gráfico grande y luego de figuras y tablas del selection report.
- NTRU-509 ofrece key y ciphertext más pequeños que Kyber-512, lo que, según esta crítica, no encaja con la descripción de NIST de que “NTRU” tiene public key y ciphertext “somewhat larger” que Kyber.
- Para excluir NTRU-509 habría que sostener que no alcanza el nivel mínimo de seguridad de AES-128, pero mantener a Kyber-512 bajo el mismo criterio se critica como una distinción muy débil.
Incertidumbre después de Core-SVP
- El Core-SVP de Kyber-512 es 2^118, y el costo de un ataque a AES-128 se estima como algo superior a 2^140 bit operations.
- Los documentos de entrega de Kyber de 2017 y 2019 afirmaban que era al menos 30 bits más seguro que Core-SVP, pero se critica que parte de esa base era errónea o insuficiente.
- Se dice que el rounding noise no aplica a ataques sobre la key, por lo que no sirve como fundamento de aumento de seguridad.
- Se considera que la afirmación de un aumento subexponencial del costo en sieving no tiene base, e incluso que la asintótica real podría ser más rápida que Core-SVP.
- El número de llamadas al oráculo SVP y el gate count pueden ser razonablemente válidos hasta cierto punto, pero parecen insuficientes para salvar a Kyber-512.
- El costo de acceso a memoria puede ser importante como costo real de ataque, pero se señala que los criterios oficiales de NIST exigían 2^143 “classical gates”, por lo que es difícil usarlo directamente para rescatar a Kyber-512.
- La entrega round-3 de Kyber cambió Kyber-512 y también redefinió Core-SVP para obtener 2^118 en lugar de 2^112.
- Esa entrega presentó la seguridad de Kyber-512 como 151 bits ±16, y sostuvo que aunque bajara a 135 no sería “catastrophic” por los requisitos de memoria.
- Después aparecieron varios análisis de ataques de retículas, entre ellos el de Matzov, y la estimación de seguridad de Kyber-512 se volvió más compleja e inestable.
La lógica de NIST para rescatar a Kyber-512
- La convocatoria oficial de NIST especifica que cada categoría de seguridad usa primitivas de referencia como AES-128 como piso en varias métricas “potentially relevant”.
- Es decir, cualquier ataque debe requerir recursos por encima de la referencia en todas las métricas que NIST considere potencialmente relevantes para la seguridad práctica.
- NIST evitó durante mucho tiempo las peticiones de definir con claridad “classical gates”, y en el selection report de 2022 explicó que permitía contar una lectura/escritura de memoria de un bit como una gate de costo 1.
- Se critica que, al excluir NTRU-509, NIST usó un “non-local cost model”, es decir, un criterio que en la práctica trata el costo de acceso a memoria como gratuito.
- En cambio, al mantener a Kyber-512 en la categoría 1, consideró que con “realistic memory access costs” sí cumple la categoría 1.
- En consecuencia, la crítica es que aplicó a NTRU-509 una métrica de memoria gratis y a Kyber-512 una métrica donde la memoria es cara.
NISTBS: refutación de la explicación del 7 de diciembre de 2022
- El 7 de diciembre de 2022, NIST explicó por qué consideraba que Kyber-512 cumplía la categoría I de NIST, y este texto llama a esa explicación “NISTBS”.
- NISTBS parte de que el informe de Matzov estimó el costo de un ataque a Kyber-512 en 2^137 bit operations.
- El costo de un ataque clásico a AES-128 se fija en aproximadamente 2^143 bit operations.
- Por tanto, faltarían 6 bits.
- NISTBS explica que los ataques de lattice sieving requieren acceso no estructurado a grandes memorias, y que el modelo RAM ignora ese costo.
- Luego cita evaluaciones de los documentos de NTRU y NTRU Prime para calcular que, considerando el costo de acceso a memoria en ataques de sieving de categoría 1, el costo podría ser “20~40 bits” mayor que en el modelo RAM.
- El problema es que parece que NIST interpretó eso como sumar los 40 bits de NTRU Prime al 2^137 de Matzov para obtener algo del orden de 2^177.
- Esos 40 bits de NTRU Prime parecen inferirse de la diferencia entre el 2^169 “real” y el 2^129 “free” de
sntrup653. - Se objeta que 2^129 es Core-SVP, es decir, aproximadamente el número de iteraciones, no el gate count del modelo RAM al que se refiere NIST.
- El costo de acceso a memoria debe sumarse al costo por iteración y no puede multiplicarse por el costo computacional total ya contado en bit operations ni añadirse como exponente.
- Esos 40 bits de NTRU Prime parecen inferirse de la diferencia entre el 2^169 “real” y el 2^129 “free” de
El significado de las cifras reales
- El documento de NTRU Prime reporta Core-SVP 2^129 para
sntrup653.- Eso es aproximadamente una estimación del número de iteraciones.
- El mismo documento estima el costo total de acceso a memoria como equivalente a 2^169 bit operations.
- Kyber-512 se presenta con Core-SVP 2^118.
- Aplicando el mismo método, se estima de forma aproximada que el costo de acceso a memoria sería equivalente a 2^154 bit operations.
- La estimación de 2^151 “gates” del documento de Kyber no es una estimación del costo de acceso a memoria.
- Es una estimación del número de bit operations dentro del cómputo del ataque.
- Considerando “known unknowns”, se presenta un rango de 2^135~2^167.
- Por tanto, la estimación de costo computacional de 2^151 y la estimación de costo de acceso a memoria no son términos que deban multiplicarse entre sí, sino términos que deben sumarse con dimensiones coherentes dentro del costo por iteración.
Por qué se considera que el error era fácil de detectar
- Una verificación básica de plausibilidad sería la siguiente:
- El documento de Kyber estima el costo computacional del ataque a Kyber-512 en 2^135~2^167 bit operations.
- NTRU Prime estima el costo de acceso a memoria de
sntrup653, que parece más difícil que Kyber-512, como equivalente a 2^169 bit operations. - Se critica que, si el ataque mejoró en 2^14, resulta extraño que NIST calcule el costo del ataque a Kyber-512 como 2^177.
- NISTBS escribió que el documento de NTRU Prime estimaba “40 bits extra de seguridad” frente al modelo RAM, pero se afirma que en la Sección 6.11 de ese documento no aparecen de forma directa ni “40” ni “RAM model”.
- La crítica es que, para una revisión clara, NIST debería haber explicado exactamente de dónde salía ese 40, y a qué valor de qué métrica correspondía.
- Después de diciembre de 2022 se planteó una pregunta de confirmación sobre el escenario concreto X: “¿Es correcto que se calculó como 137+40=177?”, pero se afirma que NIST no respondió.
- Más tarde, NIST contestó que ese correo “speaks for itself”, y se le critica no haber confirmado una interpretación específica del cálculo ni ofrecido una interpretación alternativa.
Investigación necesaria para el cálculo correcto
- Un cálculo correcto debe distinguir dos efectos:
- Parte del aumento en la estimación de seguridad respecto a Core-SVP proviene del costo en bit operations del cómputo dentro de cada iteración.
- Otra parte proviene de un aumento en el número de iteraciones del bucle externo respecto a Core-SVP.
- El efecto de aumento en el número de iteraciones sí puede multiplicarse con el costo de acceso a memoria.
- En cambio, el costo computacional interno por iteración y el costo de memoria interno por iteración deben sumarse, y multiplicarlos entre sí es el error central.
- Un cálculo preciso requeriría revisar cientos de páginas de artículos sobre ataques de retículas de última generación y reoptimizar toda la pila del ataque incorporando el costo de acceso a memoria.
- Por ejemplo, incluso dentro de BKZ habría que recalcular qué conviene más entre low-memory enumeration y high-memory sieving cuando se incorpora el costo de acceso a memoria.
El borrador del estándar y la cuestión de la responsabilidad
- En agosto de 2023, NIST publicó el borrador del estándar Kyber como ML-KEM.
- ML-KEM-512 es categoría de seguridad 1.
- ML-KEM-768 es categoría 3.
- De ML-KEM-1024 se dice que “claimed” corresponde a categoría 5.
- El problema, según la crítica, es que no está claro quién es el sujeto de “claimed”.
- Se cuestiona si lo afirma NIST, los diseñadores o alguien más.
- El Appendix A del borrador vuelve a presentar el criterio de que la categoría debe superar AES-128, AES-192 y AES-256 en todas las métricas potentially relevant.
- El análisis más reciente en los documentos de Kyber sugiere que el costo de un ataque a Kyber-512 podría bajar hasta 2^135 “classical gates”, lo que queda por debajo de la estimación de NIST de 2^143 gates para AES-128.
- Por ello, se reclama un análisis público de cómo justifica NIST la afirmación de que Kyber-512 está al nivel de AES-128 o por encima en todas las métricas relevantes.
Conclusión y propuesta
- La conclusión es que, como la superficie de ataque de lattice sigue siendo inestable y no se entiende lo suficiente, estandarizar Kyber-512 es temerario.
- Se sostiene que Kyber-512 podría ser mucho más fácil de romper que AES-128 incluso considerando ataques ya publicados y costos de acceso a memoria, aunque también se admite la posibilidad contraria, por lo que haría falta investigación difícil para aclarar el estado real.
- También se señala que el propio AES-128, en ataques multiobjetivo, puede bajar al nivel de unas 2^88 computations para romper una de entre un billón de claves, de modo que una pérdida de 10~30 bits no es despreciable.
- Si Kyber-512 permanece como opción estándar, se considera probable que incluso aplicaciones capaces de soportar Kyber-1024 o NTRU-1229 elijan la opción más rápida.
- La recomendación final es eliminar Kyber-512 y que NIST reconozca públicamente tanto el error en el cálculo del nivel de seguridad de Kyber-512 como la selección opaca de datos en la comparación con NTRU.
1 comentarios
Opiniones en Hacker News
Algo que hay que tener muy en cuenta antes de leer este texto es que NIST y NSA no crearon este algoritmo, sino que evaluaron la competencia.
La mayor parte del análisis la realizaron competidores y la academia, y el equipo de Kyber incluye a Roberto Avanzi, Joppe Bos, Léo Ducas, Eike Kiltz, Tancrède Lepoint, Vadim Lyubashevsky, John M. Schanck, Gregor Seiler, Damien Stehlé, y también Peter Schwabe, colaborador de Bernstein.
Históricamente, muchas veces solo se adopta al ganador. Basta con ver la competencia de AES y pensar en qué tan seguido se menciona Serpent, aunque se considera que tiene un margen de seguridad mayor que Rijndael.
No parece que NIST emita recomendaciones con base en algún análisis secreto.
La realidad lamentable es que Bernstein podría tener razón, pero es difícil distinguir si la respuesta —o la falta de respuesta— de NIST debe verse como engaño, o si simplemente no querían involucrarse con alguien que llegaba con una actitud muy agresiva.
En NIST también trabaja gente común, y es muy probable que hayan recibido esas exigencias filosas de explicación de forma similar a como la mayoría de nosotros recibe reportes de bugs agresivos.
Acusaciones exageradas como “hicieron que se usara Kyber desde que las licencias de patentes se activaran en 2024, exponiendo 3 años de datos de usuarios a atacantes, y no recomendaron usar NTRU desde 2021” no ayudan. Probablemente nadie despliegue de inmediato criptografía poscuántica independiente durante un tiempo, y en 2021 NIST también tenía varias alternativas que podría haber propuesto. SIKE se veía bastante bien hasta que fue roto el año pasado.
NIST no tiene una reputación impecable en este campo, pero si se van a criticar el algoritmo y el proceso, sería bueno contar con un resumen conciso de por qué y una o dos pruebas decisivas. Montones de análisis de correos, comparaciones solo con una propuesta, y acusaciones de que todos están demorando las cosas para absorber datos hacen que sea difícil tomárselo en serio. Si Kyber-512 realmente es así de peligroso, debería comunicarse con más claridad.
También pesa mucho que la página tenga 17.000 palabras. Incluso usando Harry Potter como referencia, a un lector promedio le tomaría 70 minutos leerla, y esto no es una novela: está lleno de números, consideraciones y frases como citas de NIST donde hay que analizar cuidadosamente la elección de palabras. Aunque uno tenga los conocimientos necesarios para entender criptografía poscuántica, desde el inicio es difícil leerlo tan rápido como un libro normal.
Al principio hice clic en “That lawsuit has been gradually secret NIST documents, shedding some light on what was actually going on behind the scenes” y terminé absorbido por otro texto; esa página enlazada tenía otras 54.000 palabras. En móvil no había barra de desplazamiento, así que no sabía qué tan largo era y lo fui revisando de forma lineal, hasta que en algún momento sentí que me había inscrito en un proyecto de investigación de doctorado, cerré la pestaña y volví al texto original.
Los lectores de HN suelen ser inteligentes y técnicos, pero vienen de áreas diversas, así que es difícil evaluar razonablemente pruebas llenas de jerga especializada que supuestamente respaldan “NIST=malo”. Estoy en un área cercana y creo entender más que el lector promedio, pero no siento que tenga derecho a juzgar sin leerlo bien. El texto sí explica el contexto y las siglas, pero es tan extenso que no sé si alguien que no lo conociera ya querría leerlo. No todas las presentaciones tienen que ser entendibles para todo el mundo, pero como esta incluye acusaciones, me pregunto si es un texto adecuado para HN.
Así que quizá retire un poco lo que dije abajo, o al menos creo que, considerando la historia de djb con las recomendaciones de NIST, se entiende mejor el tono agresivo. Hay información relacionada en https://en.wikipedia.org/wiki/Daniel_J._Bernstein#Cryptograp....
No me gusta dar demasiada importancia a la forma por encima del contenido, pero en este caso el formato del post era tan malo que resultaba difícil evaluar si el contenido valía la pena. Como no soy del área de criptografía, no puedo valorar el fondo, pero el sarcasmo y el menosprecio innecesarios hacían que el mensaje sonara muy sospechoso. Aunque parecía señalar puntos buenos, el tono general se parecía a un video de YouTube tipo “¡¡Lo QuE La ÉLiTe No QuIeRe QuE SePaS!!”, y aun si tiene razón, el autor suena bastante desagradable.
También me pregunto si alguien realmente lo leyó completo. Puede ser cierto que internet haya destruido nuestra capacidad de concentración, pero también es verdad que hoy hay tanta información que uno se vuelve muy estricto al elegir en qué gastar el tiempo. Si es un post de blog, los detalles relevantes y un resumen deberían ir en los primeros párrafos, y el diario largo y errante debería quedar después. Si las piezas importantes están escondidas como en Where's Waldo dentro de un diario interminable, es difícil esperar que alguien lo lea hasta el final.
Lo central que pregunta una y otra vez es por qué cambiaron los criterios de evaluación a posteriori, por qué presentaron los resultados de una forma que inducía a error y por qué cometieron errores básicos de cálculo. Estas personas son expertas, y todas esas cosas terminaron favoreciendo a un algoritmo.
A mis ojos, eso parece una señal de que querían convertir ese algoritmo en estándar. Si a eso se suma que la participación de la NSA fue mucho mayor de lo conocido y que intentaron ocultarlo, este estándar me resulta extremadamente sospechoso.
El problema es que estos algoritmos pronto se van a integrar en hardware.
Una vez definida la implementación que se estandarizará, es probable que los fabricantes de hardware empiecen a diseñar bloques que calculen el estándar FIPS 203 de forma más eficiente. Quizá ya hayan diseñado algunos.
Considerando que se espera la publicación del estándar en 2024 y que la evaluación de NIST CMVP para módulos FIPS toma entre 1 y 2 años, no sería sorprendente ver hacia mediados de 2026 módulos de hardware FIPS 140-3 con ML-KEM (Kyber, etc.).
El punto clave parece ser la frase de [1]: “Sin embargo, NIST no hizo una afirmación clara de extremo a extremo de que Kyber-512 tenga un margen de seguridad de N bits en el escenario X para algún (N,X) especificado con claridad”.
En [2], djb resumió de forma concisa lo que llama “escenario X” y dijo que solo se necesita una respuesta de sí o no. Está preguntando a personas que realmente necesitan conocer este problema y que tienen el trasfondo técnico para discutirlo. Como no recibió respuesta, publicó [1].
La respuesta del NIST en [3] descarta [1] sin debatir la seguridad en sí. En particular, el segundo párrafo me pareció frustrante. “El correo citado (https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/4MBu...) habla por sí solo. Al NIST le sigue interesando la opinión de la gente sobre si el plan actual de estandarizar Kyber512 es una buena idea. Los revisores son libres de intentar refutar, por diversión, lo que parece ser la postura del NIST sobre el margen de seguridad, pero el resultado no será especialmente útil para el proceso de estandarización. Las afirmaciones previas del NIST y su interpretación no son relevantes para determinar si la gente cree que estandarizar Kyber512 es una buena idea”
Si el NIST considera que los argumentos de seguridad de los revisores “no son especialmente útiles para el proceso de estandarización”, ¿por qué debería el público confiar en ese estándar, considerando que esos revisores son criptógrafos?
Es inevitable que no haya una prueba concluyente. Justamente porque el problema actual es la falta de una explicación clara. Si pudieran explicar cómo calcularon la fortaleza de seguridad de Kyber-512, sería otro asunto
Según las estimaciones actuales de terceros, el valor algo ambiguo de la fortaleza de seguridad de Kyber-512 queda por debajo de los requisitos originales, así que parece necesaria una aclaración o justificación
[1]: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/4MBu...
[2]: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/4MBu...
[3]: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/4MBu...
Si este texto hubiera sido de alguien desconocido, quizá habría estado de acuerdo, pero los autores son DJB o Tanja Lange, y ninguno de los dos es desconocido
Este tipo de cosas inevitablemente tiene que ser algo adversarial. En parte porque el criptoanálisis requiere esa actitud, y en parte porque en el pasado han ocurrido varias cosas sospechosas. Es parte del campo y de su política, así que es difícil evitarlo
Esto, más que un artículo, parece un diario. Tiene mucha terminología técnica, está poco ordenado, da vueltas sobre lo mismo y es muy difícil de seguir
Aun así, la información en sí podría ser importante. Hay una fuerte insinuación de que NIST, con ayuda de la NSA, estandarizó a propósito un algoritmo débil
Todos sabemos que algo así es posible
Pero si alguien sigue este campo más de cerca, me gustaría que explicara qué significan los números de aquí. Siempre pensé que debilitar la criptografía pública de esta forma era una apuesta peligrosa, porque no se puede garantizar que un atacante no descubra el mismo hecho de manera independiente. Una clave secreta de backdoor se puede ocultar. Esa fue la sospecha cuando apareció Dual_EC_DRBG. Pero los resultados matemáticos son realmente difíciles de ocultar
¿Por qué habrían querido asumir ese riesgo aquí?
A estas alturas ni siquiera sé por qué hace falta esta discusión. Ya no los necesitamos. Los controles de exportación también desaparecieron
Lo que hace falta es un consorcio que capte la atención de los fabricantes de hardware y limite a NIST y la NSA al rol de simples participantes. Entonces, aunque el gobierno adopte un estándar con backdoor, solo lo usarán ellos
¿Por qué le importaría eso?
La conjetura actual sobre lo que pudo haber ocurrido con las curvas elípticas de NIST va por ese lado
Si es así, durante muchísimo tiempo podría ser, en la práctica, un backdoor exclusivo de Estados Unidos
La idea era que ellos podrían mantenerse por delante en los ataques, y que para cuando las claves de 56 bits se volvieran demasiado débiles en general, DES ya habría sido reemplazado por otra cosa. ¿Fue riesgoso? Sí. Pero en cierto sentido “funcionó”. Por eso no asumiría que algo parecido nunca volverá a ocurrir
La teoría de fondo se llama kleptografía (kleptography). También implica que la NSA es lo bastante delirante como para creer que puede robar información de forma “segura”
El año pasado hubo un hilo relacionado con 443 comentarios
https://news.ycombinator.com/item?id=32360533 ("NSA, NIST, and post-quantum crypto: my second lawsuit against the US government (cr.yp.to)")
“Averiguar cómo funciona NISTPQC en secreto. En marzo de 2022 presenté una solicitud FOIA llamada ‘NSA, NIST, and post-quantum cryptography’. NIST violó la ley y dilató el proceso. El bufete de derechos civiles Loevy & Loevy presentó una demanda en mi nombre”
En lo personal, por lo general no me cae bien djb, pero profesionalmente lo apoyo siempre, porque ha seguido presionando al gobierno federal en los tribunales. Me alegra mucho ver que todavía lo sigue haciendo
Dejando de lado que DJB es una figura importante en criptografía, y que desconozco bastantes de los detalles aquí, hubo un punto en el que su credibilidad me cayó mucho
En particular, en la parte de los gráficos dice que “NIST decidió usar barras rojas más delgadas en el gráfico de ancho de banda para darles menos énfasis”, pero eso no queda probado en absoluto por la evidencia. Hay una explicación mucho más plausible. El gráfico con barras más delgadas es un gráfico de barras con más puntos de datos que los demás. Abre cualquier herramienta de gráficos y compara un gráfico con 12 puntos de datos con otro de 9; es natural que las barras del de 12 se vean más delgadas. En ese punto me dio una fuerte impresión de que estaba interpretando cada acción de la forma más maliciosa posible
En el siguiente punto se queja de que no usaron escala logarítmica, aunque los valores están dentro del mismo orden de magnitud. No suena como un buen caso para usar escala logarítmica, y no veo bien por qué estaría justificado en este caso
Sabiendo que DJB estuvo involucrado en NTRU, es difícil sacarse de encima la sensación de que buena parte de esto es una reacción resentida por haber perdido la competencia
Asumir otra cosa me parece, al menos a mí, bastante ingenuo
Hay razones de sobra para sospechar
Es natural que los competidores de este campo terminen revisando el trabajo de los demás
Lo que aprendí observando profesionalmente las peleas encendidas entre criptógrafos: no apuestes contra Bernstein y no confíes en NIST
NIST respondió: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/W2VO...
No estoy seguro de que le quede credibilidad a N(IST)SA
Es alentador que curve25519 se use más que sus curvas P, y espero que la comunidad siga en esa dirección y, en adelante, los ignore en gran medida
El gobierno no debería liderar ni decidir. Para FIPS, regulaciones, etc., sería mejor estructurarlo en torno al rol de recopilar y seguir el consenso actual