BoringSSL est le fork d’OpenSSL maintenu par Google, utilisé dans Chrome et Android ; AWS-LC, la bibliothèque sous-jacente à aws-lc-rs, en est à son tour un fork, et ring réutilise son code assembleur. Le projet ne publie pas de versions et ne promet aucune stabilité d’API : ses utilisateurs épinglent un commit. Les faits présentés ici ont été vérifiés en compilant depuis les sources le commit b50cad27ee80 (19 octobre 2026).
ECDSA reprend les conventions d’OpenSSL : signatures DER, nonces aléatoires, aucune normalisation low-S et une vérification qui accepte high-S ; ECDSA_sign signe un condensat que vous avez calculé. Contrairement à OpenSSL, une entrée mal formée n’est qu’un simple échec de vérification : EVP_DigestVerify a renvoyé 0 pour une signature r‖s brute et pour un bloc de 3 octets, si bien que la file d’erreurs est le seul endroit où un problème de format apparaît. Vérifiez les encodages avec le convertisseur DER ⇄ brut.
Les courbes sont volontairement limitées à P-224, P-256, P-384 et P-521 (EC_GROUP_new_by_curve_name(NID_secp256k1) a renvoyé NULL), et Ed25519 est la seule variante d’EdDSA qui fonctionne : EVP_PKEY_ED448 est défini pour compatibilité, mais la génération d’une clé Ed448 via EVP a échoué. Le code qui passe d’OpenSSL à BoringSSL perd secp256k1, Brainpool et Ed448 sans erreur de compilation, jusqu’au moment où l’algorithme est demandé.
La prise en charge post-quantique est étendue et se présente sous forme d’API distinctes et typées plutôt que via EVP : MLKEM768_* et MLKEM1024_*, MLDSA65_* et les tailles apparentées, ainsi que SLHDSA_SHA2_128S_*, qui ont tous fonctionné en aller-retour lors des essais ; ssl.h définit aussi le groupe TLS hybride X25519MLKEM768 (0x11EC). L’exemple utilise directement ML-KEM-768 et ML-DSA-65. Voyez ce que négocie votre navigateur avec le test TLS post-quantique du navigateur.