BoringSSL ist Googles Fork von OpenSSL und wird in Chrome und Android verwendet; AWS-LC, die Bibliothek unter aws-lc-rs, ist wiederum ein Fork von BoringSSL, und ring übernimmt Assembler-Code aus BoringSSL. BoringSSL hat keine Releases und gibt kein Versprechen zur Stabilität der API – wer es einsetzt, pinnt einen Commit. Die Fakten auf dieser Seite wurden geprüft, indem Commit b50cad27ee80 (19. Oktober 2026) aus dem Quellcode gebaut wurde.
ECDSA folgt den OpenSSL-Konventionen: DER-Signaturen, zufällige Nonces, keine Low-S-Normalisierung und eine Prüfung, die High-S akzeptiert; ECDSA_sign signiert einen Digest, den du selbst berechnet hast. Anders als bei OpenSSL führt fehlerhafte Eingabe hier einfach zu einer fehlgeschlagenen Prüfung – EVP_DigestVerify gab für eine rohe r‖s-Signatur und für einen 3-Byte-Blob 0 zurück, sodass ein Formatproblem nur in der Fehlerwarteschlange auftaucht. Prüfe Kodierungen mit dem Konverter DER ⇄ Raw.
Die Kurven sind bewusst auf P-224, P-256, P-384 und P-521 beschränkt – EC_GROUP_new_by_curve_name(NID_secp256k1) gab NULL zurück –, und Ed25519 ist die einzige funktionierende EdDSA-Variante: EVP_PKEY_ED448 ist aus Kompatibilitätsgründen definiert, aber das Erzeugen eines Ed448-Schlüssels über EVP schlug fehl. Code, der von OpenSSL zu BoringSSL wechselt, verliert secp256k1, Brainpool und Ed448 ohne Kompilierfehler; das fällt erst auf, wenn der Algorithmus angefordert wird.
Die Post-Quanten-Unterstützung ist umfangreich und kommt in Form eigener, typisierter APIs statt über EVP: MLKEM768_* und MLKEM1024_*, MLDSA65_* samt zugehörigen Größen sowie SLHDSA_SHA2_128S_* – alle bestanden in der Prüfung den Roundtrip; ssl.h definiert außerdem die hybride TLS-Gruppe X25519MLKEM768 (0x11EC). Das Beispiel verwendet ML-KEM-768 und ML-DSA-65 direkt. Was dein Browser aushandelt, zeigt der Post-Quanten-Browser-Check.