¿Cómo puede Bitcoin resistir a los ordenadores cuánticos? Comparación de tres esquemas de firma basados en retículos

Autor original: Equipo de Blockstream

Compilación original: Saoirse, Foresight News

Blockstream Research ha publicado un informe de investigación exhaustivo sobre firmas basadas en retículos para Bitcoin. Este artículo resume el contenido de la investigación, los hallazgos clave y las recomendaciones relacionadas. Se puede acceder al informe completo aquí.

Las firmas digitales son el mecanismo central para autorizar transacciones de Bitcoin, y las firmas Schnorr y ECDSA que se utilizan actualmente para este fin tienen un coste extremadamente bajo. En 1994, Shor demostró que un ordenador cuántico suficientemente potente podría romper ambos tipos de firmas. Aunque existe un debate en curso sobre cuándo estarán disponibles dichas máquinas, necesitamos desarrollar un plan viable de despliegue de firmas poscuánticas antes de que el problema llegue realmente.

Los esquemas de firma basados en retículos son un candidato popular para reemplazar las firmas existentes. La criptografía de retículos tiene una historia de investigación de más de un siglo, y sus aplicaciones criptográficas se han desarrollado durante casi tres décadas. En la criptografía poscuántica, las firmas basadas en retículos ofrecen varias ventajas: el tamaño total de las claves públicas y las firmas puede ser tan bajo como menos de 1,6 kilobytes, y su estructura algebraica es prometedora para soportar multifirmas, firmas de umbral y pruebas sucintas en el futuro.

Este informe estudia tres esquemas: Dilithium, Falcon y Hawk. Para los lectores no familiarizados con la criptografía de retículos, explicamos la lógica de diseño de cada esquema, proporcionamos una descripción completa del flujo del algoritmo y los analizamos desde dimensiones como la seguridad, el rendimiento y el despliegue práctico (por ejemplo, la derivación de claves de monedero). Entre los tres, ¿qué esquemas pueden desplegarse realmente en la cadena de bloques de Bitcoin?

Criterios de evaluación

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

• Coste en cadena: Una de las métricas más importantes es el tamaño total de las claves públicas y las firmas. Cuando se gasta una salida, tanto la clave pública como la firma se registran en la cadena, y los nodos completos necesitan descargar y almacenar cada byte. La sobrecarga de verificación es igualmente crítica: cada firma es verificada por todos los nodos de la red, y una verificación lenta supondría una carga para toda la red.
• Complejidad de implementación: Si el esquema puede implementarse de forma segura es crucial. Si el diseño requiere aritmética de coma flotante o un muestreo gaussiano delicado, un error de implementación o un ataque de canal lateral como el análisis de temporización podría filtrar la clave. Para lograr una migración fluida, la complejidad de implementación es un factor que no se puede ignorar.
• Riesgo de despliegue: Al integrarse realmente en Bitcoin, existen varios obstáculos prácticos: la elección de la función hash a nivel de consenso (la mayoría de los candidatos utilizan SHAKE, mientras que Bitcoin utiliza SHA-256), la reproducibilidad de los resultados de las firmas en todas las plataformas y si el procedimiento de firma se ajusta a las limitaciones de memoria de los monederos de hardware.
• Potencial de desarrollo: La gran mayoría de los monederos de Bitcoin utilizan el mecanismo determinista jerárquico BIP-32: a partir de una única clave pública maestra, se puede derivar un número infinito de claves públicas hijas sin acceso a la clave privada. Actualmente, ningún esquema de firma poscuántica estandarizado admite de forma nativa esta característica, por lo que estudiamos el coste de añadir esta capacidad; también examinamos varias variantes no estándar del esquema que podrían ofrecer beneficios adicionales.

¿Qué nivel de seguridad se debe elegir?

Antes de comparar tamaños, primero debemos determinar el nivel de seguridad objetivo, y esta elección no es tan sencilla como parece. El NIST clasifica los niveles de seguridad del 1 al 5; los niveles más altos proporcionan una seguridad más fuerte, pero también tamaños de clave y firma más grandes.

Creemos que Bitcoin debería adoptar al menos el nivel de seguridad 3. Las salidas de Bitcoin pueden permanecer sin gastar durante décadas, y si los avances en el criptoanálisis reducen el nivel de seguridad real del esquema, los activos quedarían bloqueados por claves debilitadas y expuestos a riesgos a largo plazo. Las suposiciones basadas en retículos ya han resistido casi tres décadas de criptoanálisis público, más tiempo que la base de investigación cuando Bitcoin adoptó las curvas elípticas. Sin embargo, la compleja estructura algebraica de la criptografía de retículos todavía deja muchas vías para futuros ataques, y no deberíamos apostar toda nuestra seguridad a largo plazo en ella.

Los principales productos convencionales han hecho el mismo juicio. El protocolo PQ3 de iMessage de Apple descarta directamente los parámetros de retículos de nivel 1 y utiliza parámetros de nivel 3 y nivel 5 en todo momento; Cloudflare utiliza ML-KEM-768 (nivel 3) en su despliegue TLS poscuántico, afirmando que, si bien el nivel 1 parece seguro actualmente, es necesario reservar un margen de seguridad para décadas de criptoanálisis futuro. El horizonte temporal de seguridad de Bitcoin es incluso más largo que ambos.

Aumentar el nivel de seguridad tiene un coste. Por ejemplo, pasar Dilithium del nivel 2 al nivel 3 aumenta el tamaño total en aproximadamente 1,5 kilobytes. El informe compara conjuntos de parámetros en todos los niveles de seguridad, lo que permite a los lectores sopesar las ventajas y desventajas por sí mismos. El caso de Hawk demuestra que las consideraciones de seguridad conservadoras no son meramente teóricas.

Análisis detallado de los esquemas candidatos

Dilithium: un diseño simple

Dilithium, estandarizado por el NIST como ML-DSA en FIPS 204, migra el paradigma de compromiso-reto-respuesta de las firmas Schnorr a la aritmética de retículos modulares.

Su mayor característica es la simplicidad. Todas las operaciones en Dilithium son operaciones con enteros: operaciones de anillo, multiplicación matriz-vector, hash y redondeo. No hay aritmética de coma flotante ni muestreo gaussiano discreto. Es más fácil escribir implementaciones seguras de tiempo constante. También es el candidato más ampliamente desplegado, ya integrado en OpenSSL, BoringSSL, AWS-LC y Apple CryptoKit.

La contrapartida es un mayor tamaño. En el nivel de seguridad 3, ML-DSA-65 tiene una clave pública de 1952 bytes y una firma de 3309 bytes, totalizando 5261 bytes, aproximadamente 55 veces el tamaño total de la clave pública/privada más la firma nativa de Bitcoin, lo que lo convierte en el más grande de los tres esquemas en el mismo nivel de seguridad.

Para Bitcoin, el aspecto más valioso de Dilithium es que es el único de los tres que se acerca a implementar la derivación de claves estilo BIP-32. La construcción de clave realeatorizable DilithiumRK puede generar claves hijas a partir de claves padre utilizando solo información pública. El informe analiza tres variantes, incluida nuestra propuesta DilithiumRKS, donde la lógica de derivación está completamente dentro del software del monedero y la cadena solo requiere un verificador estándar para procesar firmas ML-DSA ordinarias. Sin embargo, ninguna de las tres está lista para producción: dos variantes requieren modificaciones en el verificador, y DilithiumRKS en sí carece de una prueba completa de infalsificabilidad; todos los esquemas dependen de una matriz compartida en toda la red, que es formalmente segura bajo la suposición Module-LWE pero vincula la seguridad de todas las claves a una única instancia. Creemos que la derivación de claves públicas basada en Dilithium es actualmente solo una prueba de concepto y no se puede desplegar en la práctica.

Falcon: un esquema compacto

Falcon, seleccionado por el NIST y estandarizado como FN-DSA, es el más compacto de los tres. En el nivel de seguridad 1, Falcon-512 tiene un tamaño combinado de clave pública y firma de 1563 bytes; en el nivel 5, Falcon-1024 totaliza 3073 bytes. Falcon-1024, con un mayor margen de seguridad, es incluso más pequeño que Dilithium de nivel 3.

Falcon adopta un enfoque diferente al de Dilithium: un paradigma de hash y firma basado en retículos NTRU. La clave privada del firmante es una base corta del retículo; el mensaje se convierte en un punto en el espacio mediante hash, y el firmante utiliza la base corta para encontrar un vector del retículo cercano a ese punto. El punto y el vector cercano juntos forman la firma; la verificación solo comprueba que el vector pertenece al retículo y está suficientemente cerca. El desafío de implementación es encontrar el vector sin filtrar información sobre la base. Los primeros esquemas GGH y NTRUSign seleccionaban directamente puntos cercanos del retículo, filtrando cierta información geométrica con cada firma. Falcon adopta el marco GPV, muestreando vectores cercanos de una distribución gaussiana, lo que demuestra que la salida muestreada es independiente de la base, eliminando el riesgo de fuga, pero la dificultad de implementación del muestreador aumenta significativamente.

El muestreador es el punto débil de ingeniería de Falcon. Opera en el dominio complejo de Fourier y requiere cálculo de coma flotante. Diferentes procesadores, compiladores y opciones de optimización de compilación pueden causar resultados de coma flotante inconsistentes. Esto no es solo un problema de compatibilidad, sino también una preocupación de seguridad: la prueba de seguridad GPV requiere que el firmante nunca emita dos vectores cortos diferentes para el mismo resumen; si la firma se vuelve determinista, las diferencias de redondeo de coma flotante inducidas por la plataforma violarían esta condición. Existe una solución viable: Falcon determinista puede reemplazar la coma flotante de hardware con emulación de enteros, produciendo firmas idénticas en todas las plataformas. El coste es una ralentización de aproximadamente 15 veces en la velocidad de firma y una ralentización de aproximadamente 2 veces en la generación de claves.

Es importante destacar que la verificación no se ve afectada: la verificación de Falcon es completamente basada en enteros, determinista y también la más rápida entre los candidatos. Esta propiedad asimétrica es muy amigable para Bitcoin: la firma se realiza una vez por el monedero al gastar una transacción, mientras que cada firma es verificada por todos los nodos completos de la red. Una ralentización de 15 veces en la firma es un coste de baja frecuencia, y a cambio obtenemos reproducibilidad multiplataforma y aritmética de enteros, lo que consideramos una compensación razonable. Por lo tanto, el problema de la coma flotante es un obstáculo que se puede resolver mediante medios de ingeniería, no un defecto fatal.

Dos puntos a tener en cuenta: debido a restricciones estructurales, Falcon no tiene parámetros de nivel 3; se debe elegir entre el nivel 1 o el nivel 5. Basándonos en consideraciones de margen de seguridad, recomendamos Falcon-1024. En segundo lugar, la firma consume una gran cantidad de memoria: el muestreador para el conjunto de parámetros 1024 depende de un árbol precalculado, que ocupa unos 90 kilobytes de memoria. Los monederos de hardware pueden reconstruir dinámicamente el árbol rama por rama, reduciendo el uso de memoria a 16 kilobytes, pero el tiempo de firma se duplica. Una firma más lenta en dispositivos de hardware es un coste real, pero aún aceptable.

Hawk: un esquema fallido

Hawk pretendía combinar las ventajas de los otros dos esquemas: las firmas Hawk-512 son de solo 555 bytes, más pequeñas que Falcon; la firma es completamente basada en enteros, con una huella de memoria mínima de solo 6 kilobytes. También era el único candidato basado en retículos que quedaba en la tercera ronda de la competición de firmas adicionales del NIST, y el informe dedica un espacio considerable a este esquema.

La contrapartida reside en las suposiciones de seguridad. No se basa en los problemas NTRU o SIS que han sido sometidos a décadas de criptoanálisis, sino en el problema de isomorfismo de retículos y la suposición one-more-SVP, ambos con una historia de investigación relativamente corta.

Justo antes de que se finalizara el informe, Straznickas y Weis de Anthropic descubrieron un defecto estructural en la construcción de retículos 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 pretendían los diseñadores. Los bits de seguridad de recuperación de claves de los conjuntos de parámetros candidatos se debilitaron significativamente. Los investigadores completaron un ataque de recuperación de claves de extremo a extremo en el parámetro de desafío HAWK-256 utilizado para el criptoanálisis; incluso bajo ataque, los HAWK-512 y HAWK-1024 propuestos formalmente siguen siendo prácticamente irrompibles. El equipo de Hawk confirmó la validez del ataque y retiró el esquema del proceso del NIST; el equipo declaró que si la vulnerabilidad se corrigiera duplicando los parámetros, la ventaja de tamaño original de Hawk desaparecería por completo.

El informe conserva la sección de Hawk porque el ataque se dirige a propiedades algebraicas de un cuerpo numérico específico y no niega por completo el paradigma de diseño. Si un rediseño puede evitar la vulnerabilidad sigue siendo una cuestión abierta. El incidente de Hawk también valida intuitivamente nuestra insistencia en márgenes de seguridad conservadores: un esquema con excelente tamaño y velocidad, que ha pasado por múltiples rondas de estandarización, puede ver su nivel de seguridad estimado drásticamente reducido por un solo artículo.

Tabla comparativa de esquemas

Todos los esquemas de la tabla anterior (incluido SPHINCS+) son firmas sin estado: el firmante no necesita registrar firmas pasadas. Las firmas basadas en hash con estado como XMSS pueden lograr tamaños de firma más pequeños pero requieren mantener el estado de la firma; consulte el informe especial sobre firmas basadas en hash para comparar.

Quedan muchos obstáculos para el despliegue

Falcon carece de un esquema de derivación de claves utilizable. El único esquema de derivación estilo BIP-32 de Falcon disponible públicamente realeatoriza la base de la clave privada, lo que provoca que el límite superior de la norma de la firma aumente drásticamente, y las firmas en cadena se disparan a unos 23,7 kilobytes. Además, los parámetros del esquema no cumplen sus propias condiciones de seguridad, y corregir este problema aumentaría aún más el tamaño. Actualmente no existe una implementación viable de derivación de claves públicas de Falcon, que también es el problema abierto más valioso identificado en el informe.

El estándar Falcon aún no está finalizado. Aunque el NIST ha seleccionado Falcon, el borrador de FN-DSA no se ha publicado oficialmente. Solo después de que se complete la estandarización tendremos implementaciones auditadas, vectores de prueba y soporte a nivel de hardware. La adopción generalizada puede reducir el riesgo y la dificultad de integrarse en la capa de consenso de Bitcoin. Recomendamos esperar a la publicación oficial de FN-DSA; hasta entonces, Falcon permanece en un estado de cambio.

Variante Falcon-WS: Esta variante relaja los parámetros internos y se basa en el muestreo de rechazo para compensar, comprimiendo el tamaño total a 1114 bytes en el nivel 1 y 2387 bytes en el nivel 5, reduciendo aún más el tamaño 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 criptoanalítica. La investigación existente ha encontrado fallos en las pruebas de infalsificabilidad fuerte de sus esquemas derivados (la infalsificabilidad ordinaria no se ve afectada).

¿Surgirán mejores esquemas en el futuro? Aparte de los esquemas anteriores, la familia Fiat-Shamir se remonta a BLISS en 2013. El último resultado de Gärtner en CRYPTO 2025, basado en suposiciones maduras, tiene tamaños de papel comparables a Falcon. La causa raíz de la dificultad para ingeniar esta familia reside en la seguridad de la implementación: BLISS fue roto por ataques de canal lateral debido al muestreo gaussiano de tiempo no constante; los esquemas posteriores no han resuelto completamente este problema, y el último resultado también sugiere que proteger el paso de muestreo es aún más difícil. Hasta que se resuelva el problema, tales esquemas son solo teóricamente atractivos y no aptos para el despliegue.

Las firmas basadas en retículos y en hash pueden complementarse entre sí. Las firmas basadas en retículos pueden servir como componentes de esquemas híbridos. Por ejemplo, en SHRINCS, la ruta de recuperación sin estado utiliza actualmente firmas SPHINCS+ de varios kilobytes; reemplazarlas con firmas Falcon (o Falcon-WS) sería más pequeño y más rápido de verificar, reduciendo significativamente la sobrecarga de la ruta de recuperación poco frecuente sin afectar la ruta de uso diario.

Conclusiones de la investigación

La clasificación de los candidatos basados en retículos es clara: Hawk se retiró de la competición 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 para la derivación de claves, pero su tamaño no es amigable con los costes en cadena de Bitcoin; Falcon combina tamaño compacto, verificación rápida y suposiciones de seguridad maduras; su principal debilidad, la aritmética de coma flotante en el lado de la firma, ya tiene una solución de ingeniería viable. Si tuviéramos que elegir un esquema de firma basado en retículos para Bitcoin hoy, elegiríamos Falcon-1024.

Por ahora, nuestra opinión es coherente 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 esquema de transición. Una vez que FN-DSA se finalice oficialmente, con especificaciones estables, bases de código auditadas y soporte de monederos de hardware, Falcon aportará mejoras significativas sobre las firmas puramente basadas en hash; también se puede adoptar un despliegue híbrido, permitiendo que los dos sistemas de firma se complementen entre sí.