Escrito por: Blockstream Team
Compilado por: Saoirse, Foresight News
Blockstream Research ha publicado un informe completo sobre las firmas basadas en retículos para Bitcoin. Este artículo resume los hallazgos clave y las recomendaciones del estudio. Elinforme completo está disponible aquí.
Las firmas digitales son el mecanismo central que autoriza las transacciones en Bitcoin. Actualmente, las firmas Schnorr y ECDSA cumplen esta función con un costo extremadamente bajo. En 1994, Shor demostró que una computadora cuántica lo suficientemente poderosa podría romper ambos tipos de firmas. Aunque aún existe un amplio debate sobre cuándo podría materializarse dicha máquina, es necesario desarrollar un plan viable para desplegar firmas post-cuánticas antes de que el problema se presente realmente.
Los esquemas de firma basados en retículos son candidatos destacados para reemplazar las firmas actuales. La criptografía de retículos tiene más de un siglo de estudio, y sus aplicaciones en criptografía se han desarrollado durante casi tres décadas. Dentro de la criptografía post-cuántica, las firmas basadas en retículos ofrecen varias ventajas: el tamaño total de la clave pública y la firma puede ser inferior a 1.6 kilobytes, y su estructura algebraica ofrece potencial futuro para soportar firmas múltiples, firmas de umbral y pruebas sucintas (succinct proofs).
Este informe estudia tres esquemas: Dilithium, Falcon y Hawk. Para lectores no familiarizados con la criptografía de retículos, explicamos el diseño de cada esquema, describimos completamente los algoritmos y analizamos dimensiones como seguridad, rendimiento y despliegue práctico (por ejemplo, derivación de claves en carteras). Entre los tres, ¿cuáles se podrían desplegar realmente en la cadena de bloques de Bitcoin?
Dimensiones de evaluación
La selección de un esquema de firma para Bitcoin tiene sus propias restricciones. Esta evaluación se centra en cuatro criterios principales:
- Costo en cadena: Uno de los indicadores más importantes es el tamaño total de la clave pública y la firma. Al gastar una salida, tanto la clave pública como la firma se registran en la cadena, y 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; una verificación lenta supondría una carga para toda la red.
- Complejidad de implementación: Es vital que el esquema pueda implementarse de forma segura. Si el diseño requiere operaciones de punto flotante o un muestreo gaussiano preciso, un error de implementación o un ataque de canal lateral como el análisis de tiempo podría filtrar la clave privada. La complejidad de implementación es un factor que no se puede ignorar para una migración fluida.
- Riesgos de despliegue: La integración real en Bitcoin enfrenta varios obstáculos prácticos: la elección de la función hash a nivel de consenso (la mayoría de los esquemas candidatos usan SHAKE, Bitcoin usa SHA-256), la reproducibilidad de los resultados de la firma entre plataformas, y si el procedimiento de firma se adapta a las limitaciones de memoria de las carteras de hardware.
- Potencial de desarrollo: La gran mayoría de las carteras de Bitcoin utilizan el mecanismo BIP-32 de determinismo jerárquico: a partir de una sola clave maestra pública, se pueden derivar infinitas claves hijas sin tocar la clave privada. Ninguno de los esquemas de firma post-cuánticos estandarizados actualmente soporta esta característica de forma nativa, por lo que estudiamos el costo de añadir esta capacidad; también examinamos variantes no estándar que podrían ofrecer beneficios adicionales.
¿Qué nivel de seguridad deberíamos elegir?
Antes de comparar tamaños, debemos definir el nivel de seguridad objetivo. Esta elección no es tan simple como parece. El NIST divide los niveles de seguridad en 1-5; a mayor nivel, mayor seguridad, pero también mayor tamaño de claves y firmas.
Creemos que Bitcoin debería adoptar al menos el nivel de seguridad 3. Una salida de Bitcoin puede permanecer sin gastarse durante décadas. Si los avances en criptoanálisis reducen el nivel de seguridad real del esquema, los fondos quedarán bloqueados con claves debilitadas, expuestas a largo plazo. Los supuestos de los retículos han resistido casi tres décadas de criptoanálisis público, un periodo más largo que el de las curvas elípticas cuando Bitcoin las adoptó. Sin embargo, la compleja estructura algebraica de los retículos aún ofrece posibles vectores de ataque futuros, y no debemos apostar toda la seguridad a largo plazo en ellos.
Productos importantes han tomado la misma decisión. El protocolo PQ3 de iMessage de Apple descarta directamente los parámetros de retículos de nivel 1, utilizando solo parámetros de nivel 3 y 5; Cloudflare, en su despliegue de TLS post-cuántico, usa ML-KEM-768 (nivel 3), argumentando que, aunque el nivel 1 parece seguro ahora, se necesita un margen de seguridad para décadas de criptoanálisis futuro. Y el horizonte temporal de seguridad de Bitcoin es aún más largo.
Subir el nivel de seguridad tiene un costo. Por ejemplo, al pasar Dilithium del nivel 2 al 3, el tamaño total aumenta unos 1.5 kilobytes. El informe compara los conjuntos de parámetros para todos los niveles de seguridad, permitiendo al lector sopesar las opciones. La experiencia de Hawk demuestra que las consideraciones de seguridad conservadoras no son meramente teóricas.
Detalle de los esquemas candidatos
Dilithium: El esquema de diseño simple
Dilithium ha sido estandarizado por el NIST como ML-DSA en el estándar FIPS 204. Traslada el paradigma compromiso-desafío-respuesta de las firmas Schnorr a la aritmética de retículos modulares.
Su mayor característica es la simplicidad. Todas las operaciones de Dilithium son de enteros: operaciones de anillo, multiplicación matriz-vector, hash, redondeo; no requiere operaciones de punto flotante ni muestreo gaussiano discreto. Esto facilita escribir implementaciones seguras y de tiempo constante. También es el candidato con mayor adopción, integrado en OpenSSL, BoringSSL, AWS-LC y Apple CryptoKit.
El costo es un tamaño relativamente grande. ML-DSA-65 de nivel 3 tiene una clave pública de 1952 bytes, una firma de 3309 bytes, totalizando 5261 bytes, aproximadamente 55 veces el tamaño total de las claves públicas/privadas nativas de Bitcoin más la firma. Es el de mayor volumen entre los tres esquemas del mismo nivel de seguridad.
Para Bitcoin, el punto más valioso de Dilithium es que es el único de los tres que se acerca a implementar una derivación de claves al estilo BIP-32. La construcción DilithiumRK con clave realeatorizable permite generar claves hijas a partir de una clave padre usando solo información pública. El informe analiza tres variantes, incluyendo nuestra propuesta DilithiumRKS, donde la lógica de derivación reside completamente en el software de la cartera, y la cadena solo necesita un verificador estándar para procesar firmas ML-DSA ordinarias. Sin embargo, ninguna está lista para producción: dos variantes requieren modificar el verificador, DilithiumRKS carece de una prueba completa de no falsificabilidad (unforgeability); todos los esquemas dependen de una matriz compartida por toda la red, lo que, aunque seguro formalmente bajo el supuesto Module-LWE, ata la seguridad de todas las claves a una misma instancia. Consideramos que la derivación de claves basada en Dilithium es actualmente solo una prueba de concepto, no apta para despliegue real.
Falcon: El esquema compacto
Falcon fue seleccionado por el NIST, con el nombre estándar FN-DSA. Entre los tres, es el más compacto. Falcon-512 de nivel 1 suma 1563 bytes (clave pública + firma); Falcon-1024 de nivel 5 suma 3073 bytes. Falcon-1024, con mayor margen de seguridad, es incluso más pequeño que Dilithium de nivel 3.
Falcon adopta un enfoque diferente al de Dilithium: un esquema de hash-y-firma basado en el retículo NTRU. La clave privada del firmante es una base corta del retículo; el mensaje se hashea a un punto en el espacio, y el firmante usa la base corta para encontrar un vector del retículo cercano a ese punto. El punto y este vector cercano constituyen la firma; la verificación solo comprueba que el vector pertenece al retículo y está suficientemente cerca. La dificultad de implementación radica en encontrar el vector sin filtrar información sobre la base. Esquemas antiguos como GGH y NTRUSign tomaban simplemente el punto del retículo más cercano, filtrando información geométrica con cada firma. Falcon utiliza el marco GPV, muestreando el vector cercano desde una distribución gaussiana, lo cual prueba que la salida del muestreo es independiente de la base, eliminando el riesgo de fuga, pero aumentando enormemente la dificultad de implementar el muestreador.
El muestreador es el talón de Aquiles de Falcon a nivel de ingeniería. Opera en el dominio de Fourier complejo, requiriendo cálculo de punto flotante. Diferentes procesadores, compiladores y opciones de optimización producen resultados de punto flotante inconsistentes. Esto no es solo un problema de compatibilidad, sino de seguridad: la prueba de seguridad GPV requiere que, para un mismo resumen (digest), el firmante nunca produzca dos vectores cortos diferentes; una vez que la firma es determinista, las diferencias de redondeo de punto flotante entre plataformas rompen esta condición. Existen soluciones viables: un Falcon determinista puede simular punto flotante con enteros, produciendo firmas idénticas en todas las plataformas. El costo es una velocidad de firma unas 15 veces menor y una generación de claves unas 2 veces más lenta.
Lo importante es que la verificación no se ve afectada: la verificación de Falcon utiliza solo operaciones de enteros, es determinista y es la más rápida entre los candidatos. Esta asimetría es muy favorable para Bitcoin: la firma la ejecuta la cartera una vez al gastar la transacción, mientras que cada firma debe ser verificada por todos los nodos completos de la red. Una firma 15 veces más lenta es un costo de baja frecuencia, y a cambio obtenemos reproducibilidad multiplataforma y operaciones con enteros, lo que nos parece un intercambio razonable. Por lo tanto, el problema del punto flotante es un obstáculo solucionable con ingeniería, no un defecto fatal.
Dos advertencias: Por restricciones estructurales, Falcon no tiene parámetros de nivel 3, solo de nivel 1 o 5. Basándonos en el margen de seguridad, recomendamos Falcon-1024. En segundo lugar, la firma consume mucha memoria: el muestreador para el conjunto de parámetros 1024 depende de un árbol precalculado que ocupa unos 90 kilobytes. Las carteras de hardware pueden reconstruir este árbol dinámicamente por ramas, reduciendo el uso de memoria a unos 16 kilobytes, pero duplicando el tiempo de firma. Un hardware más lento es un costo real, pero aceptable.
Hawk: El esquema fallido
El objetivo de Hawk era combinar las ventajas de los otros dos esquemas: la firma Hawk-512 tiene solo 555 bytes, más pequeña que Falcon; el lado del firmante usa solo operaciones de enteros, con un uso mínimo de memoria de solo 6 kilobytes. También era el único candidato basado en retículos que permanecía en la tercera ronda del concurso de firmas adicionales del NIST. El informe dedica una sección extensa a este esquema.
El costo está en los supuestos de seguridad. No utiliza problemas ampliamente estudiados como NTRU o SIS, sino que se basa en el problema del isomorfismo de retículos y el supuesto "one-more-SVP", que tienen una historia de investigación relativamente más corta.
Poco antes de finalizar el informe, Straznickas y Weis de Anthropic descubrieron un defecto estructural en la construcción del retículo de Hawk: la dimensión real del problema SVP necesario para recuperar la clave era la mitad de lo que los diseñadores suponían. Esto redujo drásticamente los bits de seguridad de recuperación de clave para los parámetros candidatos. Los investigadores completaron un ataque de recuperación de clave de extremo a extremo contra los parámetros de desafío HAWK-256, utilizados para criptoanálisis; incluso tras el ataque, las propuestas formales HAWK-512 y HAWK-1024 no podían ser rotas en la práctica. El equipo de Hawk confirmó la validez del ataque y retiró el esquema del proceso del NIST; el equipo indicó que si se corrigiera el fallo duplicando los parámetros, la ventaja de tamaño de Hawk desaparecería por completo.
El informe mantiene la sección sobre Hawk porque el ataque se dirige a propiedades algebraicas específicas de un campo numérico, no invalida completamente el paradigma de diseño. No está claro si un rediseño podría evitar la vulnerabilidad. El caso de Hawk también ilustra vívidamente la razón de nuestro enfoque conservador en el margen de seguridad: un esquema, incluso con buen tamaño, velocidad y tras pasar 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 en la tabla anterior (incluyendo SPHINCS+) son firmas sin estado (stateless): el firmante no necesita registrar firmas anteriores. Firmas hash con estado como XMSS pueden lograr tamaños de firma más pequeños, pero requieren mantener un estado de firma; consulta elinforme especial sobre firmas basadas en hashpara más comparaciones.
Persisten múltiples obstáculos para el despliegue
Falcon carece de un esquema de derivación de claves usable. El único esquema público de derivación al estilo BIP-32 para Falcon realeaatoriza la base de la clave privada, lo que aumenta enormemente el límite de la norma de la firma, inflando la firma en cadena a unos 23.7 kilobytes. Además, los parámetros de este esquema no cumplen sus propias condiciones de seguridad, y si se corrigiera, el tamaño aumentaría aún más. Actualmente no existe una implementación viable de derivación de claves públicas para Falcon, lo que constituye uno de los problemas pendientes más valiosos identificados en el informe.
El estándar de Falcon aún no está finalizado. Aunque el NIST seleccionó Falcon, el borrador de FN-DSA aún no se ha publicado oficialmente. Una vez finalizada la estandarización, llegarán implementaciones auditadas, vectores de prueba y soporte a nivel de hardware. Una adopción amplia reduciría el riesgo y la dificultad de integración en la capa de consenso de Bitcoin. Recomendamos esperar a la publicación oficial de FN-DSA; hasta entonces, Falcon sigue en estado de cambio.
Variante Falcon-WS: Esta variante relaja parámetros internos, compensando con muestreo por rechazo (rejection sampling). El tamaño total para nivel 1 se reduce a 1114 bytes, y para nivel 5 a 2387 bytes, una reducción adicional respecto a Falcon original. Esta dirección tiene valor de investigación, pero no será parte del estándar oficial y necesita más verificación criptoanalítica. Ya se ha encontrado un fallo en la prueba de fuerte no falsificabilidad (strong unforgeability) de un esquema derivado (la no falsificabilidad ordinaria no se ve afectada).
¿Aparecerán esquemas mejores en el futuro? Además de los esquemas anteriores, la serie Fiat-Shamir se originó con BLISS en 2013; el trabajo más reciente de Gärtner en CRYPTO 2025, basado en supuestos maduros, promete tamaños en papel comparables a Falcon. La raíz de la dificultad de implementación de esta serie radica en problemas de seguridad: BLISS fue vulnerado por canal lateral debido a que su muestreo gaussiano no era de tiempo constante; esquemas posteriores no han resuelto completamente este problema, y el trabajo más reciente señala una mayor dificultad para proteger la fase de muestreo. Hasta que se resuelva, estos esquemas solo tienen atractivo teórico y no son aptos para despliegue.
Las firmas basadas en retículos y en hash pueden complementarse. Las firmas basadas en retículos pueden ser un componente en esquemas híbridos. Por ejemplo, en SHRINCS, la ruta de recuperación sin estado (stateless recovery path) actualmente usa firmas SPHINCS+ de varios KB; reemplazarlas con firmas Falcon (o Falcon-WS) reduciría el tamaño, aceleraría la verificación y disminuiría significativamente el costo de baja frecuencia de la ruta de recuperación, sin afectar la ruta de uso diario.
Conclusión del estudio
El orden de preferencia entre los candidatos basados en retículos es claro: Hawk quedó fuera tras el ataque del equipo de Anthropic; Dilithium tiene la menor dificultad de implementación y es el único con investigación base relacionada con derivación de claves, pero su tamaño no es amigable para los costos en cadena de Bitcoin; Falcon combina tamaño compacto, verificación rápida y supuestos de seguridad maduros; su principal desventaja —las operaciones de punto flotante en el lado de la firma— ya tiene soluciones de ingeniería viables. Si tuviéramos que elegir un esquema de firma basado en retículos para Bitcoin ahora mismo, elegiríamos Falcon-1024.
En el presente, nuestra postura coincide con la del informe sobre firmas basadas en hash: la ruta conservadora a corto plazo siguen siendo las firmas basadas en hash, con los supuestos de seguridad más maduros y el menor riesgo, adecuadas como solución de transición. Una vez que FN-DSA esté finalizado oficialmente, con especificaciones estables, código auditado y soporte en carteras de hardware, Falcon ofrecerá mejoras significativas respecto a las firmas hash puras; también se podría adoptar un despliegue híbrido, permitiendo que ambos sistemas de firma se complementen.
