Zum Inhalt springen
ecdsa.com
C · Befehlszeile

LibreSSL

LibreSSL von OpenBSD, der 2014 entstandene Fork von OpenSSL, den OpenBSD und die Systemtools von macOS nutzen: ECDSA in DER und Schlüsselformate wie bei OpenSSL, Ed25519, aber kein Ed448, ML-KEM über eine eigene API, kein ML-DSA und kein RFC 6979.
Lizenz
OpenSSL AND ISC
Geprüfte Version
4.3.1 ·
Quellcode
github.com/libressl/portable
Dokumentation
man.openbsd.org/

Kompatibilität auf einen Blick

ECDSAEdDSAPost-Quanten-Verfahren

ECDSA-Kurven
P-224P-256P-384P-521secp256k1brainpoolP256r1brainpoolP384r1brainpoolP512r1
EdDSA
Ed25519
Formate privater Schlüssel
pkcs8-pempkcs8-derencrypted-pkcs8sec1-pemsec1-der

LibreSSL behält die vertraute API (libcrypto/libssl) und die Befehlszeile von OpenSSL bei, entfernt aber Legacy-Code und ergänzt eine eigene libtls. macOS liefert ein älteres LibreSSL als System-Kryptografie aus: Unter macOS 27.0.1 gab /usr/bin/openssl version den Wert LibreSSL 3.3.6 aus, und ssh -V nannte dieselbe Bibliothek. Die Fakten auf dieser Seite wurden mit dem Paket aus Alpine 3.24.2 geprüft, LibreSSL 4.3.1 (upstream war bereits 4.3.3 erschienen); dort ist der Befehl als libressl installiert – Skripte, die openssl aufrufen, scheitern, solange das Kompatibilitätspaket nicht installiert ist.

ECDSA verhält sich wie OpenSSL mit Standardeinstellungen: DER-Signaturen, zufällige Nonces, keine Low-S-Normalisierung und eine Prüfung, die High-S akzeptiert. Anders als bei OpenSSL ab 3.2 gibt es keine Option für deterministisches ECDSA nach RFC 6979. EVP_DigestVerify gab für eine rohe r‖s-Signatur -1 zurück, und die Befehlszeile meldete dafür Error Verifying Data, für eine gültige Signatur über andere Daten dagegen Verification Failure – die Groß- und Kleinschreibung weicht von den Meldungen von OpenSSL ab, woran Skripte scheitern, die per grep nach dem exakten Text suchen.

Die Kurven reichen von P-224 bis P-521, dazu kommen secp256k1 und die Brainpool-r1-Kurven; Ed25519 funktioniert über EVP_PKEY_ED25519, Ed448 gibt es überhaupt nicht. Schlüsseldateien sind mit OpenSSL austauschbar: SPKI und Zertifikate für öffentliche Schlüssel, PKCS#8 (unverschlüsselt und verschlüsselt) und SEC1 für private Schlüssel; ecparam -genkey schreibt SEC1 im Format EC PRIVATE KEY, konvertiere also mit pkcs8 -topk8, wenn ein anderes Tool PKCS#8 erwartet, wie es das Beispiel tut.

Die Post-Quanten-Unterstützung ist unvollständig: ML-KEM-768 und ML-KEM-1024 stehen über die eigenen Funktionen MLKEM_* von LibreSSL in <openssl/mlkem.h> bereit, nicht über EVP oder die Befehlszeile, und ML-DSA gibt es nicht (Algorithm ML-DSA-65 not found). Vergleiche die Algorithmen im Post-Quanten-KEM-Playground; für Signaturen mit ML-DSA nimm OpenSSL 3.5 oder neuer.

Fakten und die Prüfungen dahinter

Nichts im Folgenden ist aus einer Dokumentation abgeschrieben. Das Prüfskript content/libraries/verify/libressl/run.sh hat LibreSSL 4.3.1 am 20. Oktober 2026 im Container-Image alpine:3.24.2 ausgeführt; die Seite muss mit seiner Ausgabe übereinstimmen, und jeder Fakt führt die zugehörigen Zeilen auf.

  • Kodierung von ECDSA-Signaturen

    der

    EVP_DigestSign und libressl dgst -sign erzeugen ASN.1-DER.

    Von der Prüfung aufgezeichnet
    fact ecdsa-signature-encoding = der
  • ECDSA-Nonce

    random

    Zufällige Nonce: Zwei Signaturen derselben Nachricht unterscheiden sich; eine deterministische Option gibt es nicht.

    Von der Prüfung aufgezeichnet
    fact ecdsa-nonce = random
  • Low-S beim Signieren

    either

    s wird nicht normalisiert: Unter 64 Signaturen traten High-S-Werte auf.

    Von der Prüfung aufgezeichnet
    fact ecdsa-low-s-sign = either
  • High-S bei der Prüfung

    accepts-high-s

    Eine DER-Signatur, in der s durch n − s ersetzt war, bestand die Prüfung.

    Von der Prüfung aufgezeichnet
    fact ecdsa-low-s-verify = accepts-high-s
  • Was der Signaturaufruf hasht

    hashes-message-or-digest

    EVP_DigestSign hasht; ECDSA_sign signiert einen Digest, und diese Signatur bestand die Prüfung gegen die Nachricht.

    Von der Prüfung aufgezeichnet
    fact ecdsa-prehash = hashes-message-or-digest
  • Fehlerhafte ECDSA-Signatur

    returns-error

    EVP_DigestVerify gab für eine rohe r‖s-Signatur und für einen 3-Byte-Blob -1 zurück.

    Von der Prüfung aufgezeichnet
    fact ecdsa-malformed-signature = returns-error
    evidence ecdsa-malformed-signature: EVP_DigestVerify returned -1 for raw r||s and -1 for 3 bytes
  • Ausgabe bei fehlgeschlagener Prüfung

    distinguishable

    dgst -verify gab für eine Signatur, die kein DER ist, Error Verifying Data aus und für eine gültige Signatur über andere Daten Verification Failure.

    Von der Prüfung aufgezeichnet
    fact cli-verify-output = distinguishable
    evidence cli-verify-output: valid: Verified OK; 64 zero bytes: Error Verifying Data; valid signature over other data: Verification Failure
  • ECDSA-Kurven

    P-224P-256P-384P-521secp256k1brainpoolP256r1brainpoolP384r1brainpoolP512r1

    Signieren und Prüfen funktionierten mit P-224, P-256, P-384, P-521, secp256k1 und brainpoolP256r1/P384r1/P512r1.

    Von der Prüfung aufgezeichnet
    fact ecdsa-curves = P-224, P-256, P-384, P-521, secp256k1, brainpoolP256r1, brainpoolP384r1, brainpoolP512r1
  • EdDSA

    Ed25519

    Ed25519 über EVP_PKEY_ED25519; EVP_PKEY_ED448 ist nicht definiert.

    Von der Prüfung aufgezeichnet
    fact eddsa = Ed25519
    evidence eddsa: EVP_PKEY_ED448 is not defined in the headers
  • Post-Quanten-Algorithmen

    ML-KEM

    ML-KEM-768 und ML-KEM-1024 bestanden den Roundtrip über die API MLKEM_*; genpkey -algorithm ML-DSA-65 scheiterte mit Algorithm ML-DSA-65 not found.

    Von der Prüfung aufgezeichnet
    fact pqc = ML-KEM
    evidence pqc: ML-KEM rank 3: public key 1184 bytes, ciphertext 1088 bytes, round trip ok
    evidence pqc: ML-KEM rank 4: public key 1568 bytes, ciphertext 1568 bytes, round trip ok
    evidence pqc: genpkey -algorithm ML-DSA-65: Algorithm ML-DSA-65 not found
    evidence pqc: ML-KEM names in s_client help: none
  • Formate öffentlicher Schlüssel

    spki-pemspki-derx509

    Mit öffentlichen Schlüsseln als SPKI in PEM und DER sowie aus Zertifikaten bestand dieselbe Signatur die Prüfung.

    Von der Prüfung aufgezeichnet
    fact public-key-formats = spki-pem, spki-der, x509
  • Formate privater Schlüssel

    pkcs8-pempkcs8-derencrypted-pkcs8sec1-pemsec1-der

    Signieren funktionierte mit PKCS#8 in PEM und DER, mit verschlüsseltem PKCS#8 und mit SEC1 in PEM und DER; ecparam -genkey schreibt SEC1.

    Von der Prüfung aufgezeichnet
    fact private-key-formats = pkcs8-pem, pkcs8-der, encrypted-pkcs8, sec1-pem, sec1-der
    evidence private-key-formats: genpkey -algorithm EC: works
    evidence private-key-formats: ecparam -genkey writes -----BEGIN EC PRIVATE KEY-----

Verwendung

Erzeuge mit dem Befehl libressl einen P-256-Schlüssel, konvertiere ihn in PKCS#8, signiere und prüfe und zeige, dass Ed25519 funktioniert, ML-DSA dagegen nicht.
# Alpine and some distributions install LibreSSL's tool as "libressl", not "openssl".
L=libressl
$L ecparam -name prime256v1 -genkey -noout -out key.pem   # SEC1 "EC PRIVATE KEY"
$L pkcs8 -topk8 -nocrypt -in key.pem -out key.p8.pem       # PKCS#8 for other tools
$L pkey -in key.pem -pubout -out pub.pem

printf 'order #1042 approved' > msg.txt
$L dgst -sha256 -sign key.p8.pem -out sig.der msg.txt
$L dgst -sha256 -verify pub.pem -signature sig.der msg.txt

# Ed25519 works; ML-DSA does not exist in LibreSSL.
$L genpkey -algorithm ED25519 -out ed.pem && echo "Ed25519 key: $(head -1 ed.pem)"
$L genpkey -algorithm ML-DSA-65 2>&1 | grep -i "not found"

Die Snippet-Testumgebung führt jedes Beispiel unverändert im Container-Image alpine:3.24.2 aus, und der Lauf schlägt fehl, wenn die Ausgabe nicht übereinstimmt.

Einrichtung
apk add --no-cache -q libressl=4.3.1-r0 >/dev/null
Befehl
OPENSSL_CONF=/dev/null sh usage.sh
Ausgabe muss passen (regulärer Ausdruck)
Verified OK\nEd25519 key: -----BEGIN PRIVATE KEY-----\nAlgorithm ML-DSA-65 not found

Bibliotheken