El Núcleo del Asunto: Libsecp256k1, el Corazón Criptográfico de Bitcoin

Frases comunes entre los entusiastas de Bitcoin incluyen “no confíes, verifica” o “no son tus llaves, no son tus monedas”, llegando al extremo de afirmar que está “respaldado por matemáticas”. Pero, ¿qué significan realmente estos proverbios y cómo se aplica esta matemática en la práctica? La mayoría de los lectores seguramente saben que un ingrediente fundamental en el diseño de Bitcoin es la criptografía de clave pública y, más específicamente, las firmas digitales, que son esenciales para probar la propiedad sin necesidad de una entidad central. Probablemente menos conocido es el software subyacente que hace que esa matemática de curvas elípticas funcione y qué esfuerzos se realizan para asegurar que esto se lleve a cabo de la manera más segura y eficiente, con mejoras continuas. Sumergámonos en la emocionante historia y evolución de “libsecp256k1”, una biblioteca que comenzó como un pequeño proyecto personal y se transformó con el tiempo en una parte esencial de las reglas de consenso que protegen un activo multimillonario.

El Génesis

Por razones que aún desconocemos con certeza, Satoshi eligió una curva elíptica llamada “secp256k1” para crear y verificar firmas digitales en Bitcoin. La versión inicial del cliente de Bitcoin utilizaba la ampliamente conocida biblioteca OpenSSL para firmar y verificar transacciones. Dependiendo de una biblioteca de terceros puede parecer una elección razonable desde una perspectiva de ingeniería de software (aún más en algo tan específico y complejo como la criptografía de curvas elípticas), pero esta decisión resultó problemática más tarde debido a inconsistencias en el código de análisis de firmas. En el peor de los casos, esto podría incluso conducir a divisiones no intencionadas de la cadena. Una de las lecciones aprendidas en ese período fue que OpenSSL no es una biblioteca adecuada para un sistema crítico de consenso como Bitcoin. El problema se solucionó más tarde con BIP66, que aseguró una codificación estricta de las firmas ECDSA. Después de eso, la dependencia de OpenSSL fue reemplazada por libsecp256k1 en Bitcoin Core v0.12, lanzado a comienzos de 2016.¹

Sin embargo, retrocediendo un poco, la motivación inicial detrás del inicio del proyecto libsecp256k1 fue principalmente la curiosidad sobre un posible aumento de velocidad. En algún momento de 2012, el desarrollador de Bitcoin Core Pieter Wuille, también conocido como “sipa”, encontró un hilo en bitcointalk iniciado por Hal Finney (conocido por ser el receptor de la primera transacción de Bitcoin en 2009 de Satoshi).

Bajo el tema “Acelerando la verificación de firmas”, el post discutió una optimización que haría uso de un llamado “endomorfismo” (más específicamente utilizando el método GLV, Gallant-Lambert-Vanstone), algo que solo permiten ciertas curvas elípticas, siendo la secp256k1 una de ellas. Hal Finney mismo lo implementó utilizando los primitivas de OpenSSL, y más tarde se presentó incluso como una PR a Bitcoin Core.² Aunque mostró un incremento sólido de ~20% en velocidad, nunca fue fusionado debido a preocupaciones sobre el aumento de la complejidad del código y la falta de certeza de que la criptografía involucrada fuera segura.

Pieter Wuille decidió entonces crear una nueva biblioteca desde cero, siendo el primer commit del repositorio “secp256k1” del 5 de marzo de 2013. Después de solo una semana, la biblioteca logró verificar la cadena de bloques completa (con una altura de bloque ~225000 en ese momento), y otra semana después se implementó la funcionalidad de firma. Pasó un tiempo más y se realizaron pruebas hasta que la biblioteca estuvo lista para ser utilizada en Bitcoin Core como reemplazo de OpenSSL, primero para firmar en la cartera (lanzamiento v0.10, 2015), y finalmente para la verificación de firmas ECDSA en consenso (lanzamiento v0.12, 2016). Los esfuerzos valieron la pena: según la descripción de la PR en Core, utilizar libsecp256k1 para la verificación de firmas era “entre 2.5 y 5.5 veces más rápido”. Irónicamente, esto aún no incluía la optimización de endomorfismo mencionada anteriormente, ya que no se activó por defecto debido a preocupaciones sobre la violación de patentes. Solo se activó en 2020, una vez que la patente expiró (habilitada en el lanzamiento v0.20), lo que llevó a otro aumento de velocidad sólido del 16% aproximadamente.

Con el tiempo, el proyecto atrajo a varios otros colaboradores. Esto naturalmente involucró a personas que trabajaban estrechamente con Pieter desde el principio en Blockstream, entre ellos el entonces CTO Gregory Maxwell y el investigador Andrew Poelstra. En 2015, Jonas Nick y algunos años después Tim Ruffing se unieron, ambos empleados de Blockstream como investigadores y ahora manteniendo el rol de responsables de libsecp256k1 durante varios años. Dado que son responsables de especificar nuevos protocolos criptográficos (incluyendo pruebas de seguridad detalladas) y llevarlos a la práctica implementándolos y revisándolos, es muy apropiado llamarlos “criptógrafos de pila completa”, como le gusta describirse a Tim Ruffing.

Ocasionalmente, incluso criptógrafos fuera del ámbito de Bitcoin han contribuido a libsecp256k1. Un ejemplo notable es Peter Dettman, conocido por ser uno de los responsables de la biblioteca de criptografía C#/Java BouncyCastle, quien hasta la fecha sigue ofreciendo sugerencias de mejora de rendimiento. Una de sus principales contribuciones fue implementar la inversión modular usando el algoritmo “safegcd” en 2021 para mejorar la seguridad, siguiendo un artículo de Daniel J. Bernstein y Bo-Yin Yang.

¿Por Qué Reinventar la Rueda?

El objetivo de libsecp256k1 es proporcionar la biblioteca de mayor calidad para operaciones criptográficas en la curva secp256k1, con la intención principal de ser útil en el ecosistema más amplio de Bitcoin. Bitcoin Core es simplemente el cliente principal que la utiliza. La API de libsecp256k1 está diseñada para ser robusta y difícil de mal usar, para prevenir que los usuarios realicen operaciones inseguras (por ejemplo, creando sus propios esquemas criptográficos) que podrían llevar a la pérdida de fondos en el peor de los casos. Al concentrarse exclusivamente en una curva elíptica y limitar su funcionalidad a operaciones relevantes para Bitcoin (es decir, principalmente firmar y verificar transacciones), el código puede ser tanto más rápido como más fácil de revisar, lo que conduce a una menor carga de mantenimiento y una mayor calidad en comparación con otras implementaciones. libsecp256k1 está escrita en C y no tiene dependencia de otras bibliotecas, así que solo utiliza código interno creado específicamente para el proyecto. Por lo tanto, está diseñada para funcionar también en dispositivos restringidos como microcontroladores, que se utilizan comúnmente en billeteras hardware.

Medir Dos Veces, Cortar Una

Desde muy temprano, libsecp256k1 tuvo un fuerte enfoque en la garantía de calidad, que ha sido continuamente mejorada a lo largo de los años. Ahora tiene una cobertura de pruebas cercana al 100%, y nuevos módulos solo tienen la oportunidad de ser fusionados si se mantiene ese estándar. Además, existe una forma especial de garantía llamada “pruebas exhaustivas”. La idea básica es ejercitar la funcionalidad de la biblioteca para todo el espacio de valores posibles en la curva. Dado que esto sería inviable en la curva secp256k1 real, que consiste en ~2^256 puntos, se utiliza una curva especial, mucho más pequeña pero muy similar, que tiene un orden que está solo en el rango de dos o tres dígitos, por lo que se puede ejecutar fácilmente dentro de un tiempo razonable. Otra parte importante de las pruebas es asegurar el comportamiento en tiempo constante, que es particularmente relevante para la firma, como veremos más adelante.

Schnorr: Un Mundo Totalmente Nuevo

Al cambiar nuestro enfoque de la calidad a nuevas funcionalidades, uno de los hitos importantes en la última década en libsecp256k1, y en el protocolo de Bitcoin en general, fue la introducción de las firmas Schnorr. Siendo una parte esencial de la bifurcación suave Schnorr/Taproot activada a finales de 2021, ofrecen muchas ventajas sobre las firmas ECDSA, incluyendo ser provablemente seguras bajo suposiciones estándar, más compactas, y habilitan una gran cantidad de otras construcciones como la agregación de claves y firmas para esquemas de multisig más eficientes. Tanto la especificación en BIP340 como la implementación fueron creadas por los actuales tres mantenedores de libsecp256k1, Pieter Wuille, Jonas Nick y Tim Ruffing.

libsecp256k1 es Bueno para tu Nodo y la Red

No hace falta decir que la verificación de firmas digitales es uno de los (si no el) caminos de código más importantes y críticos de seguridad en el motor de consenso de Bitcoin. Sin importar qué complejos caminos de script y condiciones de gasto adicionales puedan incluirse en algún script de bloqueo, al final hay, probablemente, al menos una verificación de firma involucrada en la transacción para asegurar que realmente fue creada por el propietario de los fondos que se están gastando. Para una operación tan esencial, queremos que el código sea lo más robusto, bien probado y eficiente posible. La verificación rápida de firmas también es crítica tanto para la rápida propagación de transacciones y bloques, como para acelerar la descarga inicial de bloques (IBD) para los nuevos participantes en la red. Ya hemos mencionado anteriormente el aumento de ~5x en velocidad cuando libsecp256k1 reemplazó a OpenSSL por primera vez hace aproximadamente diez años. Con el tiempo se implementaron más mejoras de rendimiento, y una investigación reciente muestra que libsecp256k1 ahora es aproximadamente ~8x más rápido que OpenSSL para la verificación de firmas ECDSA utilizando las versiones más actuales de ambas.³

Firmar Puede Ser Peligroso, Así Que Háganlo Correctamente

Hasta ahora nos hemos centrado en la funcionalidad de verificación de libsecp256k1, siendo la más crucial para el rendimiento de los nodos y mineros. La otra cara de la moneda (sin juego de palabras) es la firma, es decir, el proceso de crear una firma digital para una transacción con el fin de gastar fondos. Lo que hace que este proceso sea delicado es que el material de la clave secreta está involucrado. Si este material se filtra de alguna manera, podría en el peor de los casos llevar a una pérdida catastrófica de fondos, por lo que se debe tener especial cuidado a nivel de implementación. libsecp256k1 intenta combatir los llamados “ataques de canal lateral” evitando ramas dependientes de datos, es decir, instancias donde se ejecutan diferentes partes de código dependiendo de los datos que se le proporcionan. Esta es una tarea no trivial y requiere un esfuerzo extra con respecto a los compiladores modernos, que a veces son “demasiado inteligentes” en el sentido de que intentan optimizar el código mientras se compila, evitando donde explícitamente no se desea. Esto no solo es una preocupación teórica, sino que ha ocurrido más de una vez, lo que ha requerido parches (por ejemplo, lanzamientos 0.3.1 y 0.3.2). La propiedad importante de tiempo constante también se prueba usando una herramienta llamada “valgrind”, que originalmente se construyó para depurar problemas de memoria. Mediante su uso para encontrar cualquier ramificación en el código que opera con datos secretos, podemos detectar si existe un riesgo potencial de canal lateral.

Otra forma en que podría filtrarse material secreto es dejándolo en la memoria de manera involuntaria. Sobreescribir una región de memoria para asegurarse de que se borre suena trivial, pero esto debe hacerse de tal manera que evita que el compilador interfiera debido a la optimización del código durante la compilación. Se toma un gran cuidado para asegurarse de que esto no ocurra.

Algunos Accidentes Agradables

Más de una vez durante el desarrollo de la biblioteca surgieron cosas interesantes por sorpresa. En 2014, Pieter Wuille y Gregory Maxwell ya estaban trabajando en una extensa suite de pruebas para la biblioteca. Una de las estrategias para lograr un mayor grado de garantía fue verificar el comportamiento de las funciones internas en la biblioteca contra otras implementaciones con entradas aleatorias especiales. Esto reveló un caso donde OpenSSL dio un resultado incorrecto al elevar un número al cuadrado, un error relevante de seguridad registrado como CVE-2014-3570 (“La elevación de bignum al cuadrado puede producir resultados incorrectos”).

En otro caso, unos años más tarde, Pieter Wuille propuso un nuevo método para calcular un límite sobre el número de iteraciones necesarias para el mencionado algoritmo “safegcd” para calcular inversos modulares. Esto permitió reducir ese límite, llevando a un cálculo más rápido. Pero no se detuvo allí. Principalmente por accidente, Gregory Maxwell descubrió una variante diferente del algoritmo de Bernstein y Yang con límites aún más bajos, conduciendo a un aumento significativo en la velocidad tanto para la firma como para la verificación.

Es destacable mencionar que la corrección (es decir, la seguridad) de la implementación de “safegcd” ha sido formalmente verificada utilizando un software especial de demostración de teoremas llamado “Rocq” (anteriormente denominado “Coq”) y la lógica de programa “Verifiable C”.⁴ Este impresionante trabajo fue realizado por Russell O’Connor y Andrew Poelstra, quienes afirman que la totalidad de libsecp256k1 podría ser verificada de la misma manera.

La Criptografía Sigue Evolucionando

Hemos demostrado que libsecp256k1 se utiliza principalmente para crear y verificar firmas digitales en las transacciones de Bitcoin, cuidando de hacerlo de la manera más segura y eficiente posible, pero no se detiene allí. Siempre que se presenten otras propuestas que impliquen operaciones criptográficas en la curva secp256k1 (idealmente formalizadas en un BIP) y se consideren beneficiosas para el ecosistema de Bitcoin, hay buenas probabilidades de que el código necesario sea considerado para su inclusión en la biblioteca. En tal caso, dado el tiempo suficiente para la implementación y revisión por parte de los desarrolladores, tiene altas probabilidades de aparecer en un lanzamiento de libsecp256k1. Esto ha sucedido notablemente antes con el módulo ElligatorSwift, una pieza esencial para habilitar la encriptación de la comunicación P2P de los nodos [ver BIP324; discutido en profundidad aquí], y más recientemente para MuSig2, un esquema de agregación de claves basado en firmas Schnorr que permite crear multisig n sobre n de manera eficiente en espacio y preservando la privacidad. También hay un esfuerzo en curso para agregar un nuevo módulo para Pagos Silenciosos, una propuesta para una dirección reutilizable estática que preserve la privacidad y no requiere interacción previa entre el remitente y el destinatario. Y hay mucho más por venir: Validación por Lotes para Firmas Schnorr, pruebas DLEQ, FROST, entre otras. ¡Veamos qué traerán los próximos 10 años de desarrollo en libsecp256k1!

Se anima a los lectores interesados en libsecp256k1 a echar un vistazo y experimentar con secp256k1lab, una implementación de Python de la curva secp256k1 destinada a la creación de prototipos y experimentación.⁵

No pierdas la oportunidad de tener The Core Issue — que presenta artículos escritos por muchos desarrolladores principales que explican los proyectos en los que trabajan.

Este artículo es la Carta del Editor publicado en la última edición impresa de Bitcoin Magazine, The Core Issue. Lo compartimos aquí como un vistazo anticipado a las ideas exploradas en todo el número.

[1] https://gnusha.org/pi/bitcoindev/55B79146.70309@gmail.com/

[2] (#2061, https://github.com/bitcoin/bitcoin/pull/2061)

[3] https://delvingbitcoin.org/t/comparing-the-performance-of-ecdsa-signature-validation-in-openssl-vs-libsecp256k1-over-the-last-decade/2087?u=thestack

[4] [https://www.arxiv.org/abs/2507.17956]

[5] https://github.com/secp256k1lab/secp256k1lab/