¿Cómo puede Bitcoin resistir a las computadoras cuánticas? Comparación de las ventajas y desventajas de tres esquemas de firma basados en rejillas

Escrito por: Blockstream Team

Compilado por: Saoirse, Foresight News

*El Instituto de Investigación de Blockstream ha publicado un informe completo sobre las firmas basadas en rejillas para Bitcoin. Este artículo resume el contenido de la investigación, los hallazgos clave y las recomendaciones relacionadas, * el informe completo se puede consultar aquí .

Las firmas digitales son el mecanismo central para autorizar transacciones en Bitcoin, y hoy en día, los costos de las firmas Schnorr y ECDSA que cumplen esta función son extremadamente bajos. En 1994, Shor demostró que una computadora cuántica lo suficientemente potente podría romper ambos tipos de firmas. Aunque hay un amplio debate sobre cuándo podrían aparecer tales máquinas, necesitamos establecer un plan de implementación de firmas post-cuánticas viable antes de que el problema se presente realmente.

Los esquemas de firma basados en rejillas son candidatos populares para reemplazar las firmas existentes. La criptografía de rejillas ha sido objeto de investigación durante más de un siglo, y sus aplicaciones criptográficas han evolucionado durante casi tres décadas. En el contexto de la criptografía post-cuántica, las firmas basadas en rejillas tienen muchas ventajas: el tamaño total de la clave pública y la firma puede ser inferior a 1.6 kilobytes, y su estructura algebraica tiene el potencial de soportar firmas múltiples, firmas umbral y pruebas concisas en el futuro.

Este informe estudia tres esquemas: Dilithium, Falcon y Hawk. Para los lectores que no están familiarizados con la criptografía de rejillas, explicamos las ideas de diseño de cada esquema, presentamos el flujo del algoritmo y analizamos desde dimensiones como seguridad, rendimiento y despliegue práctico (por ejemplo, la derivación de claves de billetera). ¿Cuáles de estos esquemas pueden realmente implementarse en la cadena de Bitcoin?

Dimensiones de evaluación

Bitcoin tiene sus propias restricciones en la selección de esquemas de firma, y esta evaluación se centra en cuatro criterios clave:

• Costo en cadena: Uno de los indicadores más importantes es el tamaño total de la clave pública y la firma. Cuando se gasta una salida, tanto la clave pública como la firma se registran en la cadena, y todos los nodos completos deben descargar y almacenar cada byte. El costo de verificación también es crucial: cada firma debe ser verificada por todos los nodos de la red, y una velocidad de verificación lenta puede sobrecargar toda la red.
• Complejidad de implementación: La capacidad de implementar el esquema de manera segura es fundamental. Si el diseño requiere operaciones de punto flotante o muestreo gaussiano fino, cualquier error en la implementación o ataques de canal lateral como el análisis de tiempo pueden filtrar la clave. La complejidad de implementación es un factor que no se puede ignorar para lograr una transición suave.
• Riesgo de despliegue: La integración real de Bitcoin también enfrentará varios obstáculos prácticos: la selección de funciones hash a nivel de consenso (la mayoría de los esquemas candidatos utilizan SHAKE, mientras que Bitcoin utiliza SHA-256), la reproducibilidad de los resultados de firma entre plataformas y si el programa de firma se adapta a las limitaciones de memoria de las billeteras de hardware.
• Potencial de desarrollo: La gran mayoría de las billeteras de Bitcoin utilizan el mecanismo determinista jerárquico BIP-32: a través de una única clave pública maestra, se pueden derivar infinitas claves públicas secundarias sin acceder a la clave privada. Actualmente, los esquemas de firma post-cuántica estandarizados no admiten esta característica de forma nativa, por lo que investigamos el costo de agregar esta capacidad; también examinamos varias variantes no estándar que podrían ofrecer más beneficios.

¿Qué nivel de seguridad se debe elegir?

Antes de comparar tamaños, primero se debe determinar el nivel de seguridad objetivo, y esta elección no es tan simple como parece. NIST clasifica los niveles de seguridad en 1-5; cuanto mayor es el nivel, mayor es la seguridad, pero también lo son el tamaño de la clave y la firma.

Creemos que Bitcoin debería adoptar al menos un nivel de seguridad de 3. Las salidas de Bitcoin pueden no ser gastadas durante décadas, y si los avances en técnicas de análisis criptográfico llevan a una disminución del nivel de seguridad real del esquema, los activos quedarían bloqueados con claves debilitadas, expuestos a riesgos a largo plazo. La criptografía de rejillas ha sido sometida a casi tres décadas de análisis criptográfico público, y la investigación acumulada sobre la adopción de curvas elípticas por parte de Bitcoin es aún más antigua. Sin embargo, la compleja estructura algebraica de la criptografía de rejillas aún presenta muchos puntos vulnerables que podrían ser explotados en ataques futuros, por lo que no deberíamos apostar toda nuestra seguridad futura en ella.

Los principales productos también han llegado a la misma conclusión. El protocolo PQ3 de iMessage de Apple descarta directamente los parámetros de criptografía de rejillas de nivel 1, utilizando solo parámetros de nivel 3 y 5; Cloudflare utiliza ML-KEM-768 (nivel 3) en su implementación de TLS post-cuántico, indicando que aunque el nivel 1 parece seguro en este momento, es necesario reservar un margen de seguridad para el análisis criptográfico de las próximas décadas. La duración de la seguridad de Bitcoin es incluso más larga que la de estos dos ejemplos.

Aumentar el nivel de seguridad tiene un costo. Por ejemplo, Dilithium aumenta de nivel 2 a nivel 3, y el tamaño total aumenta aproximadamente 1.5 kilobytes. El informe compara todos los conjuntos de parámetros en todos los niveles de seguridad, y los lectores pueden sopesar sus opciones. La experiencia de Hawk demuestra que las consideraciones de seguridad conservadoras no son solo teoría.

Análisis detallado de los esquemas candidatos

Dilithium: un esquema de diseño simple

Dilithium ha sido estandarizado por NIST como ML-DSA en el estándar FIPS 204, trasladando el paradigma de compromiso-reto-respuesta de las firmas Schnorr a la aritmética de rejillas modulares.

Su mayor característica es su simplicidad. Todas las operaciones de Dilithium son operaciones enteras: operaciones en anillos, multiplicación de matrices y vectores, hash, redondeo, sin operaciones de punto flotante ni necesidad de muestreo gaussiano discreto. Esto facilita la escritura de implementaciones seguras y de tiempo constante. También es el esquema candidato más ampliamente implementado, ya que se ha integrado en OpenSSL, BoringSSL, AWS-LC y Apple CryptoKit.

El costo es un tamaño relativamente grande. Para el ML-DSA-65 de seguridad de nivel 3, la clave pública tiene 1952 bytes y la firma 3309 bytes, sumando un total de 5261 bytes, aproximadamente 55 veces el tamaño total de la clave pública y privada nativa de Bitcoin más la firma, siendo el más grande entre los tres esquemas en el mismo nivel de seguridad.

Para Bitcoin, lo más valioso de Dilithium es que es el único de los tres que se acerca a implementar la derivación de claves al estilo BIP-32. La construcción de claves re-randomizadas DilithiumRK puede generar claves secundarias a partir de la clave padre utilizando solo información pública. El informe analiza tres variantes, incluyendo nuestra propuesta DilithiumRKS, cuya lógica de derivación se mantiene completamente dentro del software de billetera, y en la cadena solo se necesita un verificador estándar para procesar firmas ML-DSA ordinarias. Sin embargo, ninguna de las tres ha alcanzado los estándares de implementación: dos variantes requieren modificaciones en el verificador, y DilithiumRKS carece de una prueba completa de no falsificabilidad; todos los esquemas dependen de una matriz compartida por toda la red, que aunque es formalmente segura bajo la suposición de Module-LWE, vincula la seguridad de todas las claves a la misma instancia. Creemos que en esta etapa, la derivación de claves públicas basada en Dilithium es solo una prueba de concepto y no puede ser implementada en la práctica.

Falcon: un esquema compacto

Falcon ha sido seleccionado por NIST, y su nombre estandarizado es FN-DSA, siendo el más compacto de los tres. La clave pública y la firma de Falcon-512 de seguridad de nivel 1 suman un total de 1563 bytes; la de Falcon-1024 de seguridad de nivel 5 suma 3073 bytes. Falcon-1024, que tiene un mayor margen de seguridad, es incluso más pequeño que Dilithium de nivel 3.

Falcon adopta un enfoque diferente al de Dilithium: se basa en un modelo de hash-firma de rejillas NTRU. La clave privada del firmante es un conjunto de bases cortas de la rejilla; el mensaje se mapea a un punto en el espacio mediante hash, y el firmante utiliza la base corta para encontrar un vector que esté muy cerca de ese punto en la rejilla. El punto y ese vector cercano constituyen la firma; la verificación solo comprueba que el vector pertenece a la rejilla y que está lo suficientemente cerca. La dificultad de implementación radica en encontrar el vector sin filtrar información sobre la base. Los esquemas tempranos GGH y NTRUSign simplemente tomaban puntos cercanos de la rejilla, y cada firma filtraba parte de la información geométrica. Falcon utiliza el marco GPV, muestreando vectores cercanos de una distribución gaussiana, lo que permite demostrar que la salida del muestreo es independiente de la base, eliminando el riesgo de filtración, aunque la dificultad de implementación del muestreador aumenta considerablemente.

El muestreador es el punto débil en la ingeniería de Falcon. Opera en el dominio de Fourier complejo y requiere cálculos de punto flotante. Diferentes procesadores, compiladores y opciones de optimización de compilación pueden causar resultados inconsistentes en la salida de punto flotante. Esto no es solo un problema de compatibilidad, sino también un riesgo de seguridad: la prueba de seguridad de GPV requiere que el firmante nunca produzca dos conjuntos diferentes de vectores cortos para el mismo resumen; una vez que la firma se convierte en una firma determinista, las diferencias de redondeo de punto flotante provocadas por la plataforma pueden romper esta condición. Existe una solución viable: Falcon determinista puede utilizar simulaciones enteras en lugar de hardware de punto flotante, produciendo firmas completamente consistentes en todas las plataformas. El costo es que la velocidad de firma disminuye aproximadamente 15 veces y la velocidad de generación de claves disminuye aproximadamente 2 veces.

Lo importante es que la verificación no se ve afectada: la verificación de Falcon se realiza completamente con operaciones enteras, y los resultados son deterministas, además de ser el esquema candidato con la velocidad de verificación más rápida. Esta característica asimétrica es muy favorable para Bitcoin: la firma es ejecutada por la billetera una vez al gastar la transacción, mientras que cada firma debe ser verificada por todos los nodos de la red. Que la firma sea 15 veces más lenta es un costo de baja frecuencia, que a cambio proporciona reproducibilidad entre plataformas y operaciones enteras, lo que consideramos un compromiso razonable. Por lo tanto, el problema de punto flotante es un obstáculo que se puede resolver mediante ingeniería, no un defecto fatal.

Dos puntos a tener en cuenta: debido a las restricciones estructurales, Falcon no tiene parámetros de nivel 3, solo se puede elegir entre nivel 1 o nivel 5. Basado en consideraciones de margen de seguridad, recomendamos Falcon-1024. En segundo lugar, la firma consume una gran cantidad de memoria: el muestreador del conjunto de parámetros 1024 depende de un árbol de pre-cálculo, ocupando aproximadamente 90 kilobytes de memoria. Las billeteras de hardware pueden reconstruir dinámicamente este árbol por rama, reduciendo el uso de memoria a 16 kilobytes, pero el tiempo de firma se duplicará. La desaceleración de la firma en dispositivos de hardware es un costo real, pero aún es aceptable.

Hawk: un esquema fallido

El objetivo de Hawk es fusionar las ventajas de los otros dos esquemas: la firma Hawk-512 tiene solo 555 bytes, más pequeña que Falcon; todas las operaciones en el lado de la firma son enteras, con un uso mínimo de memoria de solo 6 kilobytes. También es el único candidato basado en rejillas que ha sobrevivido a la tercera ronda del concurso de firmas adicionales de NIST, y el informe dedica una gran cantidad de espacio a este esquema.

El costo está en las suposiciones de seguridad. No ha utilizado problemas NTRU o SIS, que han sido verificados por décadas de análisis criptográfico, sino que se basa en el problema de isomorfismo de rejillas y la suposición one-more-SVP, que tienen una historia de investigación relativamente corta.

Justo antes de la finalización del informe, Straznickas y Weis de Anthropic descubrieron un defecto estructural en la construcción de la rejilla de Hawk: la dimensión del problema SVP que realmente necesita resolverse para la recuperación de claves es solo la mitad de lo que los diseñadores habían imaginado. La seguridad de recuperación de claves del conjunto de parámetros candidatos se ha debilitado significativamente. Los investigadores completaron un ataque de recuperación de claves de extremo a extremo contra el parámetro de desafío HAWK-256 utilizado para el análisis criptográfico; incluso bajo ataque, las propuestas formales HAWK-512 y HAWK-1024 aún no pueden ser comprometidas en la práctica. El equipo de Hawk confirmó la efectividad del ataque y retiró el esquema del proceso de NIST; el equipo indicó que si se corrigen las vulnerabilidades duplicando los parámetros, la ventaja de tamaño que Hawk había presumido se perdería por completo.

El informe aún conserva el capítulo relacionado con Hawk, ya que el ataque se dirige a las características algebraicas de un dominio numérico específico y no niega por completo este paradigma de diseño. No hay conclusión sobre si un rediseño podría evitar las vulnerabilidades. El incidente de Hawk también ilustra de manera intuitiva nuestra razón para mantener un margen de seguridad conservador: un esquema, aunque tenga un tamaño excelente y una velocidad notable, y haya pasado por múltiples rondas de estandarización, un solo artículo puede hacer que su nivel de seguridad estimado disminuya drásticamente.

Tabla comparativa de los esquemas

La tabla anterior incluye todos los esquemas (incluido SPHINCS+) que son firmas sin estado: el firmante no necesita recordar firmas anteriores. Firmas hash con estado como XMSS pueden lograr tamaños de firma más pequeños, pero requieren mantener el estado de la firma; se puede consultar el * informe temático sobre firmas basadas en hash * para más comparaciones.

Aún existen muchos obstáculos para la implementación

Falcon carece de un esquema de derivación de claves utilizable. Actualmente, el único esquema de derivación de estilo BIP-32 de Falcon disponible públicamente re-randomiza la base de la clave privada, lo que aumenta drásticamente el límite superior de la norma de firma, haciendo que la firma en cadena se expanda a aproximadamente 23.7 kilobytes. Además, los parámetros de este esquema no cumplen con sus propias condiciones de seguridad, y si se corrige este problema, el tamaño aumentará aún más. Actualmente no hay una implementación viable de derivación de claves públicas de Falcon, que es el problema más valioso que el informe plantea para resolver.

El estándar de Falcon aún no está finalizado. Aunque NIST ha seleccionado Falcon, el borrador de FN-DSA aún no se ha publicado oficialmente. Solo después de que se complete la estandarización se proporcionarán implementaciones auditadas, vectores de prueba y soporte a nivel de hardware. La implementación general puede reducir los riesgos y la dificultad de integración en la capa de consenso de Bitcoin. Sugerimos esperar la publicación oficial de FN-DSA; hasta entonces, Falcon sigue en un estado de cambio.

Variante Falcon-WS: Esta variante relaja los parámetros internos, compensando con muestreo rechazado, reduciendo el tamaño total de nivel 1 a 1114 bytes y a 2387 bytes para nivel 5, lo que representa una disminución adicional en comparación con el Falcon original. Esta dirección tiene valor de investigación, pero no se incluirá en el estándar oficial y requiere más validación de análisis criptográfico. Investigaciones anteriores han encontrado vulnerabilidades en la prueba de fuerte no falsificabilidad de su esquema derivado (la no falsificabilidad ordinaria no se ve afectada).

¿Aparecerán mejores esquemas en el futuro? Aparte de los esquemas mencionados, la serie Fiat-Shamir, que se originó en 2013 con BLISS, y los últimos resultados presentados por Gärtner en la conferencia CRYPTO 2025, basados en suposiciones maduras, pueden igualar el tamaño de Falcon en papel. La dificultad de implementar estas series radica en problemas de seguridad en la implementación: BLISS fue comprometido por un ataque de canal lateral debido a muestreo gaussiano no constante en el tiempo; los esquemas posteriores no han resuelto completamente esta vulnerabilidad, y los últimos resultados también indican que la protección durante el muestreo es más difícil. Hasta que se resuelvan estos problemas, estos esquemas solo tienen atractivo teórico y no son adecuados para su implementación.

Las firmas basadas en rejillas y las firmas hash pueden complementarse. Las firmas basadas en rejillas pueden ser componentes de un esquema híbrido. Por ejemplo, en SHRINCS, la ruta de recuperación sin estado actualmente utiliza firmas SPHINCS+ de tamaño de varios KB; al reemplazarlas por firmas Falcon (o Falcon-WS), el tamaño es menor y la verificación es más rápida, reduciendo significativamente el costo de la ruta de recuperación de baja frecuencia, sin afectar la ruta de uso diario.

Conclusiones de la investigación

El orden de las ventajas y desventajas de los esquemas candidatos basados en rejillas es muy claro: Hawk se retiró de la competencia tras el ataque del equipo de Anthropic; Dilithium tiene la menor dificultad de implementación y es el único esquema con una base de investigación relacionada con la derivación de claves, pero su tamaño no es amigable para los costos en la cadena de Bitcoin; Falcon equilibra un tamaño compacto, verificación rápida y suposiciones de seguridad maduras; su principal desventaja, las operaciones de punto flotante en el lado de la firma, ya tiene soluciones de ingeniería viables. Si ahora tuviéramos que elegir un esquema de firma basado en rejillas para Bitcoin, elegiríamos Falcon-1024.

En este momento, nuestra opinión coincide con el informe sobre firmas basadas en hash: la ruta conservadora a corto plazo sigue siendo las firmas basadas en hash, con las suposiciones de seguridad más maduras y el menor riesgo, adecuadas como solución de transición. Una vez que FN-DSA esté formalmente finalizado, con especificaciones estables, una base de código auditada y soporte para billeteras de hardware, Falcon ofrecerá mejoras significativas en comparación con las firmas hash puras; también se puede implementar un despliegue híbrido, permitiendo que ambos sistemas de firma se complementen.

Este contenido se ofrece únicamente con fines informativos generales y no constituye un asesoramiento financiero, de inversión, legal ni fiscal. Cualquier evento, recompensa, promoción en línea o información relacionada que se mencione en el presente documento no debe considerarse como una recomendación, solicitud o invitación a comprar, vender, operar o de negociar de otra manera con cualquier criptoactivo. Los criptoactivos son sumamente volátiles y pueden provocar pérdidas. La disponibilidad de los servicios, productos y eventos relacionados de WEEX puede variar según la región. Tienes la responsabilidad de asegurarte de que tu participación esté de acuerdo con las leyes y regulaciones locales vigentes.