La criptografía estuvo presente en Ámsterdam del 13 al 15 de abril con otro Simposio Real World Crypto, celebrado en persona y en línea. Lea este blog de David Hook, de Keyfactor, para saber más sobre sus tres conclusiones clave del evento.
En resumen, ¡están pasando muchas cosas! Para aquellos que busquen detalles más detallados sobre las cosas que nos afectan a corto plazo, he pensado examinar tres temas de interés: el concurso PQC del NIST continúa, las listas de revocación de certificados (CRL) siguen existiendo y la idea de la criptoagilidad como principio está resultando mucho más complicada de lo que pensábamos.
Continúa el concurso PQC del NIST
A finales del año pasado se anunció que el conjunto final de algoritmos del concurso PQC del NIST se elegiría a finales de marzo de este año. Como dijo elocuentemente uno de los ponentes, ahora estamos a finales de marzo. El NIST no ha hecho más anuncios y los equipos de presentación tampoco parecen tener más información.
Una posible razón de esta pausa es que se han producido nuevos avances en el análisis de los candidatos. Un ataque a Rainbow ha significado que todos sus conjuntos de parámetros han sido efectivamente degradados un nivel en seguridad, más recientemente se ha publicado un ataque de celosía dual mejorado que también degrada la seguridad de algoritmos como SABER, Crystals-Dilithium, y Crystals-Kyber.
Esto no significa que ninguno de estos algoritmos esté intrínsecamente roto, pero puede significar que los tamaños de los parámetros deben ser revisados y esto tiene efectos en cadena en cuanto a la utilidad de los algoritmos, lo que probablemente a su vez afecta a la idoneidad de un algoritmo para la selección. Así que tal vez -sólo tal vez- el NIST esté reflexionando un poco más.
Una cosa parece clara: la "forma", por así decirlo, de los algoritmos a los que migraremos en el futuro no parece que vaya a cambiar. Más adelante hablaremos de ello.
Los CRL siguen existiendo
En cuanto a la CRL, Mike Hamburg habló sobre el redescubrimiento de la CRL. Para aquellos que acaban de unirse a nosotros, he aquí un poco de historia. Cuando las CRL empezaron a ser bastante grandes, al menos para algunas CA y sus usuarios, surgió la idea de consultar el estado en línea (en lugar de distribuir las CRL completas) con OCSP (Online Certificate Status Protocol). Como la mayoría de las buenas ideas, esto llevó a otros problemas, dando lugar al grapado OCSP.
El elefante en la habitación con OCSP siempre ha sido qué hacer cuando el servidor OCSP está caído. Ha habido un par de incidentes en los que nos hemos enterado, siendo probablemente el más famoso el que dio lugar a blogs con títulos notablemente sucintos como "¿Qué le ha pasado a mi Mac? El apocalipsis OCSP de Apple".
La charla de Mike fue una nueva mirada a CRLite, que es una propuesta ya activa para volver a un equivalente descargado localmente para una CRL. Se propuso originalmente en 2017 y proporciona una representación mucho más pequeña. Aunque CRLite no proporciona tanta información como una CRL real, te dice si un certificado está revocado, que en la mayoría de los casos es todo lo que se necesita. Resulta que sólo un pequeño porcentaje de los certificados se revocan alguna vez, lo que hace que el uso de mapas de filtrado como los filtros de Bloom sea una forma eficaz de representar una CRL con una reducción sustancial del tamaño. Y parece que los filtros de cinta deshilachada producen una huella aún menor. El tamaño de las estructuras resultantes parece hacerlas fáciles de descargar. CRLite, tal y como se describe, es mucho más amplio que una única CRL para una única CA, pero las lecciones y técnicas aprendidas son igualmente aplicables a una única CA. Si la gestión y emisión de CRL es de interés, vale la pena seguir este trabajo.
La criptoagilidad no es tan fácil como parece
Por último, hubo una serie de charlas sobre todo lo relacionado con la poscuántica (PQ) que terminó con una charla sobre la transición criptográfica y la agilidad. Voy a parafrasear un poco para ser breve, así que si no he captado bien lo que David Ott y sus coautores intentaban transmitir, espero que acepten mis disculpas.
Hablamos mucho de la criptoagilidad, pero aunque algunos han tratado de señalar que no es tan fácil como parece, muchos de nosotros seguimos asumiendo que es como el efecto 2000: basta con auditar las bases de datos y ajustar las lecturas y comparaciones de dos columnas, y todo va bien. Ahora está claro que no es así. Como señaló el moderador de una sesión, no basta con añadir PQ al principio del protocolo y esperar que funcione. No todos los nuevos algoritmos se adaptan directamente a los métodos que utilizamos en la actualidad y, como industria, aún estamos trabajando para saber en qué lado de la línea se encuentran los distintos protocolos. Para otros, por citar una famosa frase de Star Trek, se trata realmente de "es la vida Jim, pero no como la conocemos".
Dicho esto, parece que tenemos una buena idea de las características de los "nuevos" algoritmos, así que en lo que respecta a la experimentación, no hace falta esperar a que se publiquen las normas definitivas. Podemos empezar ya. Esto es especialmente relevante para los que se plantean el cifrado híbrido (como combinar un algoritmo clásico como ECCDH con uno PQC como FrodoKEM), ya que supone un cambio en la forma de hacer las cosas.
En esta nota final, me gustaría mencionar que la recién publicada Bouncy Castle 1.71 incorpora cuatro de los finalistas y candidatos alternativos del NIST: FrodoKEM, Classic McEliece, SABER, y SPHINCS+, así como el soporte de una clase HybridValueParameterSpec para permitir que la salida de los algoritmos KEM se utilice para el cifrado híbrido. Los mismos algoritmos estarán pronto disponibles en Bouncy Castle para C#. Con algo de ayuda externa, esperamos tener las implementaciones de los otros completadas en los próximos meses, así que si quieres empezar a investigar estos algoritmos, algunos recursos ya están disponibles, y los recursos que faltan están por llegar.
Si quieres empezar a probar Bouncy Castle por ti mismo, consulta estos enlaces:
