Bugs happen: la forma más fácil de comparar PQ solo frente a ECC+PQ
Bugs happen: The easy way to compare solo PQ to ECC+PQ
Daniel J. Bernstein argumenta que pasar de protocolos basados en ECC a solo PQ (post-quantum) sería un desastre de seguridad inexcusable. Señala que el software PQ tendrá fallos, algunos explotables, y que mantener ECC en esquemas híbridos ECC+PQ reduce el daño. Los costos de ECC son asumibles comparados con los de PQ, por lo que no hay excusa para descartarlo. Ejemplos recientes de bugs en ML-KEM y ML-DSA respaldan su postura.
El software PQ a menudo tendrá fallos; algunos de esos fallos serán explotables; mantener ECC como parte de ECC+PQ, en lugar de usar solo PQ, reduce el daño causado por esas vulnerabilidades.
- Retr0id
Solía estar a favor del híbrido, pero hoy en día estoy mucho más indeciso al respecto.
El software de ECC también puede tener fallos, pero no creo que nadie haya sugerido seriamente hibridar dos implementaciones diferentes de ECC, por ejemplo.
- rot256
No me compro el argumento; esto es lo bastante simple como para que podamos verificarlo formalmente y auditarlo con mucho cuidado.
Además, NIST tuvo la previsión de desaleatorizar todos los algoritmos, así que ahora podemos comprobar, por ejemplo, qué producirá una implementación correcta con semillas concretas. Esto es importante porque muchos errores de, p. ej., ECDSA, como nonces sesgados o reutilizados, se detectan trivialmente con estas pruebas/desaleatorización.
TLDR: los errores van a estar en otra parte.
- libeclipse
¿Por qué no usamos entonces RSA y ECC híbridos? ¿O AES y ChaCha20 híbridos?
Los errores de software son un argumento débil para un nuevo estándar híbrido, y no justifican la complejidad adicional.