elliptic implementa ECDSA sobre las curvas NIST y secp256k1, además de Ed25519, en JavaScript puro sobre bn.js. Se extendió a través de crypto-browserify, de bibliotecas antiguas de Ethereum y Bitcoin y de los polyfills de Node.js que Webpack 4 inyectaba en los bundles del navegador, y por eso sigue apareciendo en los archivos de bloqueo (lockfiles). ethers v6 y viem se basan en cambio en @noble/curves, que cubre las mismas curvas con valores predeterminados más estrictos.
La API se aparta de la mayoría de las bibliotecas en tres puntos que causan errores de interoperabilidad. sign() recibe el resumen, no el mensaje, y trata como resumen cualquier secuencia de bytes que reciba: en la comprobación, firmar un mensaje en bruto dio una firma distinta de la obtenida al firmar su SHA-256. Devuelve un objeto Signature con r, s y recoveryParam, así que el formato de transmisión es el que tú serialices: toDER() para implementaciones al estilo de OpenSSL, o ambos valores rellenados a 32 bytes para r‖s en bruto. Además, s no se normaliza salvo que pases canonical: true, mientras que la verificación acepta ambas mitades.
Los nonces siguen el RFC 6979 —el vector de prueba de P-256 se reprodujo exactamente—, pero el aviso de seguridad GHSA-848j-6mx2-7j84 (CVE-2025-14505), todavía abierto para la 6.6.1, informa de que un valor intermedio se trunca cuando tiene bytes cero iniciales. La comprobación lo reprodujo: en P-521 con SHA-512, 9 de 2048 entradas fijas produjeron un nonce distinto del de RFC 6979, mientras que secp256k1 con SHA-256 y P-256 con SHA-512 no mostraron ninguna diferencia en 4096 entradas cada una. Esas firmas siguen verificándose, pero firmar el mismo mensaje con la misma clave en otra implementación de RFC 6979 produce nonces relacionados, lo que, según el aviso, puede exponer la clave. Evita elliptic para P-521 y consulta el comprobador de reutilización de nonces para entender por qué importan los nonces relacionados.
Los avisos de seguridad anteriores se corrigieron en las versiones 6.5.7 a 6.6.1; entre ellos, la aceptación de firmas codificadas en BER y un fallo que permitía extraer la clave cuando se firmaba una cadena en lugar de un hash. En la comprobación, la 6.6.1 rechazó una firma DER con un cero inicial redundante. Las claves son cadenas hexadecimales o arrays de bytes —puntos SEC1, comprimidos o sin comprimir, y escalares en bruto—, sin compatibilidad con PEM, SPKI ni JWK.
El ejemplo calcula primero el hash, pide una firma canónica low-S y muestra ambas serializaciones. Cuando una firma de elliptic falla en otra parte, compara sus dos codificaciones en el conversor DER ⇄ en bruto.