Autor: Blockstream Team
Compilación: Saoirse, Foresight News
Blockstream Research ha publicado un informe de investigación completo sobre firmas basadas en retículos para Bitcoin. Este artículo resume el contenido del estudio, los hallazgos principales y las recomendaciones relacionadas. El informe completo se puede consultar en el enlace proporcionado.
Las firmas digitales son el mecanismo central para autorizar transacciones en Bitcoin. Actualmente, las firmas Schnorr y ECDSA realizan esta función con un coste extremadamente bajo. En 1994, Shor demostró que un ordenador cuántico lo suficientemente potente podría romper ambos tipos de firmas. Aunque existe un amplio debate sobre cuándo podría existir dicha máquina, es necesario desarrollar un plan de implementación viable para firmas post-cuánticas antes de que el problema se materialice.
Los esquemas de firma basados en retículos (lattices) son candidatos populares para reemplazar las firmas actuales. La criptografía de retículos tiene más de un siglo de historia de investigación, y sus aplicaciones en criptografía se han desarrollado durante casi treinta años. 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 podría permitir en el futuro firmas múltiples, firmas umbrales 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 el flujo algorítmico y analizamos dimensiones como seguridad, rendimiento y despliegue práctico (por ejemplo, derivación de claves en monederos). Entre los tres, ¿qué esquemas podrían implementarse 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:
- Coste en cadena (on-chain): Una de las métricas más importantes es el tamaño total de la clave pública y la firma. Cuando se gasta un output (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 coste de verificación también es crucial: cada firma debe ser verificada por todos los nodos de la red; una verificación lenta impondría una carga a toda la red.
- Complejidad de implementación: Es crucial que el esquema pueda implementarse de forma segura. Si el diseño requiere operaciones de coma flotante o un muestreo Gaussiano preciso, un error en la implementación o un ataque de canal lateral como el análisis de tiempos (timing analysis) podría filtrar la clave privada. La complejidad de implementación es un factor que no puede pasarse por alto para una migración suave.
- Riesgo de despliegue: La integración real en Bitcoin encuentra 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, mientras que Bitcoin usa SHA-256), la reproducibilidad de los resultados de la firma entre plataformas y si la rutina de firma se adapta 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 de determinismo jerárquico BIP-32: a partir de una única clave maestra pública, se pueden derivar infinitas claves hijas sin tocar la clave privada. Ningún esquema de firma post-cuántico estandarizado actualmente admite esta funcionalidad de forma nativa, por lo que investigamos el coste de añadir dicha capacidad. También examinamos variantes no estándar de los esquemas que podrían ofrecer beneficios adicionales.
¿Qué nivel de seguridad elegir?
Antes de comparar tamaños, debemos determinar el nivel de seguridad objetivo, y esta elección no es tan sencilla como parece. El NIST clasifica los niveles de seguridad en 1 a 5; a mayor nivel, mayor seguridad, pero también mayor tamaño de clave y firma.
Creemos que Bitcoin debería adoptar al menos el nivel de seguridad 3. Los outputs de Bitcoin pueden no gastarse durante décadas. Si el avance del criptoanálisis reduce el nivel de seguridad real del esquema, los activos quedarían bloqueados por claves debilitadas, expuestos al riesgo a largo plazo. Los supuestos de la criptografía de retículos han resistido casi tres décadas de criptoanálisis público, más tiempo que la investigación sobre curvas elípticas cuando Bitcoin las adoptó. Sin embargo, la compleja estructura algebraica de los retículos aún tiene posibles puntos de entrada para futuros ataques; no debemos apostar toda la seguridad a largo plazo 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 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), afirmando 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 que el de los anteriores.
Elevar el nivel de seguridad tiene un coste. Por ejemplo, al pasar de Dilithium nivel 2 a nivel 3, el tamaño total aumenta aproximadamente 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 estas consideraciones de seguridad conservadoras no son meramente teóricas.
Análisis detallado 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. Migra 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 con enteros: operaciones de anillo, multiplicación de matrices-vectores, hash, redondeo. No requiere operaciones de coma flotante ni muestreo Gaussiano discreto. Es más fácil escribir una implementación segura y de tiempo constante. También es el candidato más ampliamente desplegado, integrado en OpenSSL, BoringSSL, AWS-LC y Apple CryptoKit.
El coste es un tamaño mayor. ML-DSA-65 de nivel 3 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 las claves públicas/privadas nativas de Bitcoin más la firma. Es el más grande de los tres esquemas en el mismo nivel de seguridad.
El punto más valioso de Dilithium para Bitcoin 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 re-randomizable permite derivar claves hijas a partir de la clave padre utilizando solo información pública. El informe analiza tres variantes, incluyendo nuestra propuesta DilithiumRKS, que mantiene la lógica de derivación dentro del software del monedero, requiriendo en cadena solo 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 falsificación (unforgeability); y todos los esquemas dependen de una matriz compartida por toda la red, lo que, aunque seguro formalmente bajo el supuesto Module-LWE, vincula la seguridad de todas las claves a una misma instancia. Consideramos que la derivación de claves públicas basada en Dilithium es actualmente solo una prueba de concepto, no apta para despliegue real.
Falcon: El esquema compacto
Falcon ha sido seleccionado por el NIST, con el nombre estándar FN-DSA. Es el más compacto de los tres. Falcon-512 de nivel 1 suma 1563 bytes entre clave pública y 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 a Dilithium: un esquema hash-and-sign 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 tempranos como GGH y NTRUSign tomaban directamente el punto del retículo más cercano, filtrando información geométrica con cada firma. Falcon utiliza el marco GPV, muestreando vectores cercanos desde una distribución Gaussiana, lo que 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 (sampler).
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 coma flotante. Diferentes procesadores, compiladores y opciones de optimización producen resultados de coma flotante inconsistentes. Esto no es solo un problema de compatibilidad, sino de seguridad: la prueba de seguridad GPV requiere que, para un mismo digest, el firmante nunca genere dos vectores cortos diferentes; una vez que la firma se vuelve determinista, las diferencias de redondeo de coma flotante entre plataformas romperían esta condición. Existe una solución viable: Falcon determinista puede simular enteros en lugar de usar coma flotante del hardware, produciendo firmas idénticas en todas las plataformas. El coste es una velocidad de firma unas 15 veces menor y una generación de claves unas 2 veces más lenta.
Es importante que la verificación no se vea afectada: la verificación de Falcon usa 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 se ejecuta una vez por el monedero al gastar una transacción, mientras que cada firma debe ser verificada por todos los nodos completos de la red. Un retardo de 15x en la firma es un coste de baja frecuencia; a cambio, se obtiene reproducibilidad multiplataforma y operaciones con enteros, lo que consideramos un intercambio razonable. Por tanto, el problema de la coma flotante es un obstáculo superable con ingeniería, no un defecto fatal.
Dos notas importantes: debido a restricciones estructurales, Falcon no tiene parámetros de nivel 3, solo 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. Un monedero de hardware puede reconstruir este árbol dinámicamente rama por rama, reduciendo la memoria a unos 16 kilobytes, pero duplicando el tiempo de firma. El enlentecimiento de la firma en dispositivos de hardware es un coste real, pero asumible.
Hawk: El esquema fallido
El objetivo de Hawk era combinar las ventajas de los otros dos esquemas: Hawk-512 tiene una firma de 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 6 kilobytes. También fue el único candidato basado en retículos que permaneció en la tercera ronda de la competición de firmas adicionales del NIST. El informe dedica un espacio considerable a describir este esquema.
El coste estaba en sus supuestos de seguridad. No se basaba en problemas bien estudiados durante décadas como NTRU o SIS, sino en el problema del isomorfismo de retículos (lattice isomorphism) y el supuesto one-more-SVP, que tienen una historia de investigación relativamente más corta.
Justo 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 que debe resolverse para recuperar la clave es la mitad de lo que los diseñadores asumían. La seguridad de bits para la recuperación de claves de los parámetros candidatos se redujo drásticamente. Los investigadores realizaron un ataque completo de extremo a extremo para recuperar la clave contra los parámetros de desafío criptoanalítico HAWK-256; incluso bajo ataque, las propuestas formales HAWK-512 y HAWK-1024 seguían siendo irrompibles en la práctica. El equipo de Hawk confirmó que el ataque era válido y retiró el esquema del proceso del NIST; el equipo indicó que, si se corrigiera la vulnerabilidad duplicando los parámetros, la ventaja de tamaño de Hawk desaparecería por completo.
El informe conserva la sección sobre Hawk porque este ataque se dirige a propiedades algebraicas de campos numéricos específicos, y no invalida por completo este 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 énfasis en un margen de seguridad conservador: un esquema, incluso siendo compacto, rápido y habiendo pasado múltiples rondas de estandarización, puede ver su nivel de seguridad estimado reducido drásticamente por un solo artículo.
Tabla comparativa de los esquemas
Todos los esquemas en la tabla anterior (incluyendo SPHINCS+) son firmas sin estado (stateless): el firmante no necesita registrar firmas pasadas. Firmas hash con estado (stateful) como XMSS pueden lograr tamaños de firma aún más pequeños, pero requieren mantener un estado de firma; consulte el informe especial sobre firmas basadas en hash para una comparación.
Persisten múltiples obstáculos para la implementación
Falcon carece de un esquema de derivación de claves utilizable. El único esquema público de derivación al estilo BIP-32 para Falcon re-randomiza la base de la clave privada, lo que amplía 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, siendo este uno de los problemas abiertos más valiosos identificados 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. Tras completar la estandarización, llegarán implementaciones auditadas, vectores de prueba y soporte a nivel de hardware. Una adopción amplia reduce 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 sujeto a cambios.
Variante Falcon-WS: Esta variante relaja parámetros internos y compensa 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 análisis criptográfico. Investigaciones ya han encontrado un defecto en la prueba de fuerte no falsificación (strong unforgeability) de un esquema derivado (la no falsificación ordinaria no se ve afectada).
¿Aparecerán esquemas mejores en el futuro? Además de los anteriores, la serie Fiat-Shamir más temprana data de BLISS (2013); el trabajo más reciente de Gärtner en CRYPTO 2025, basado en supuestos maduros, tiene un tamaño teórico comparable a Falcon. La raíz de la dificultad de implementación de esta serie son problemas de seguridad en la implementación: BLISS fue vulnerado por canal lateral debido a un muestreo Gaussiano no de tiempo constante; esquemas posteriores no han resuelto completamente este problema, y el último trabajo advierte de una mayor dificultad para proteger la etapa 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) actualmente usa firmas SPHINCS+ de varios KB; reemplazarlas con una firma Falcon (o Falcon-WS) reduciría el tamaño, aceleraría la verificación y disminuiría significativamente el coste de la ruta de recuperación de baja frecuencia, sin afectar la ruta de uso diario.
Conclusión de la investigación
El orden de mérito entre los candidatos basados en retículos es bastante claro: Hawk se retiró tras el ataque del equipo de Anthropic; Dilithium es el más fácil de implementar y el único con investigación base relacionada con derivación de claves, pero su tamaño es poco favorable para el coste en cadena de Bitcoin; Falcon equilibra tamaño compacto, verificación rápida y supuestos de seguridad maduros. Su principal debilidad —las operaciones de coma flotante en el lado de la firma— ya tiene una solución de ingeniería viable. Si tuviéramos que elegir ahora un esquema de firma basado en retículos para Bitcoin, elegiríamos Falcon-1024.
A día de hoy, nuestra opinión coincide con la del informe sobre firmas basadas en hash: la ruta conservadora a corto plazo sigue 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, con especificaciones estables, código auditado y soporte en monederos de hardware, Falcon ofrecerá una mejora significativa respecto a las firmas puramente basadas en hash; también se podría adoptar un despliegue híbrido, complementando ambos tipos de esquemas de firma.
