BoringSSL es el fork de OpenSSL de Google, usado en Chrome y Android; AWS-LC, la biblioteca que hay debajo de aws-lc-rs, es a su vez un fork de BoringSSL, y ring reutiliza su código ensamblador. No publica versiones ni promete estabilidad de la API: quienes lo usan fijan un commit. Los datos de esta página se comprobaron compilando desde el código fuente el commit b50cad27ee80 (19 de octubre de 2026).
ECDSA mantiene las convenciones de OpenSSL: firmas DER, nonces aleatorios, sin normalización low-S y una verificación que acepta high-S; ECDSA_sign firma un resumen que calculas tú. A diferencia de OpenSSL, una entrada mal formada es simplemente una verificación fallida: EVP_DigestVerify devolvió 0 con una firma r‖s en bruto y con un blob de 3 bytes, así que la cola de errores es el único lugar donde aparece un problema de formato. Comprueba las codificaciones con el conversor DER ⇄ en bruto.
Las curvas se limitan deliberadamente a P-224, P-256, P-384 y P-521 —EC_GROUP_new_by_curve_name(NID_secp256k1) devolvió NULL— y Ed25519 es la única variante de EdDSA que funciona: EVP_PKEY_ED448 está definido por compatibilidad, pero generar una clave Ed448 a través de EVP falló. El código que pasa de OpenSSL a BoringSSL pierde secp256k1, Brainpool y Ed448 sin ningún error de compilación hasta que se solicita el algoritmo.
La compatibilidad poscuántica es amplia y llega como API separadas y tipadas en lugar de a través de EVP: MLKEM768_* y MLKEM1024_*, MLDSA65_* y los tamaños relacionados, y SLHDSA_SHA2_128S_*, que superaron todos la prueba de ida y vuelta en la comprobación; ssl.h también define el grupo TLS híbrido X25519MLKEM768 (0x11EC). El ejemplo usa ML-KEM-768 y ML-DSA-65 directamente. Mira qué negocia tu navegador con la comprobación de TLS poscuántico del navegador.