Aller au contenu
ecdsa.com
C · Ligne de commande

LibreSSL

LibreSSL d’OpenBSD, le fork d’OpenSSL créé en 2014 et utilisé par OpenBSD et les outils système de macOS : le même ECDSA en DER et les mêmes formats de clés qu’OpenSSL, Ed25519 mais pas Ed448, ML-KEM via sa propre API, pas de ML-DSA et pas de RFC 6979.
Licence
OpenSSL AND ISC
Version vérifiée
4.3.1 ·
Code source
github.com/libressl/portable
Documentation
man.openbsd.org/

Compatibilité en un coup d’œil

ECDSAEdDSAPost-quantique

Courbes ECDSA
P-224P-256P-384P-521secp256k1brainpoolP256r1brainpoolP384r1brainpoolP512r1
EdDSA
Ed25519
Formats de clé publique
spki-pemspki-derx509
Formats de clé privée
pkcs8-pempkcs8-derencrypted-pkcs8sec1-pemsec1-der

LibreSSL conserve l’API libcrypto/libssl et la ligne de commande familières d’OpenSSL tout en supprimant le code hérité, et ajoute sa propre bibliothèque libtls. macOS livre une version plus ancienne de LibreSSL comme bibliothèque cryptographique système : sous macOS 27.0.1, /usr/bin/openssl version a affiché LibreSSL 3.3.6 et ssh -V a indiqué la même bibliothèque. Les faits présentés ici ont été vérifiés sur le paquet Alpine 3.24.2, LibreSSL 4.3.1 (le projet amont en était à la 4.3.3), où la commande est installée sous le nom libressl : les scripts qui appellent openssl y échouent, sauf si l’on ajoute le paquet de compatibilité.

ECDSA se comporte comme OpenSSL avec ses valeurs par défaut : signatures DER, nonces aléatoires, aucune normalisation low-S et une vérification qui accepte high-S. Contrairement à OpenSSL 3.2 et versions ultérieures, il n’existe pas d’option déterministe RFC 6979. EVP_DigestVerify a renvoyé -1 pour une signature r‖s brute, et la ligne de commande a affiché Error Verifying Data pour celle-ci, contre Verification Failure pour une signature valide portant sur d’autres données. Notez que la casse diffère de celle des messages d’OpenSSL, ce qui casse les scripts qui recherchent le texte exact avec grep.

Les courbes vont de P-224 à P-521, avec secp256k1 et les courbes Brainpool r1 ; Ed25519 fonctionne via EVP_PKEY_ED25519, et Ed448 est totalement absent. Les fichiers de clés sont interopérables avec OpenSSL : SPKI et certificats pour les clés publiques, PKCS#8 (en clair ou chiffré) et SEC1 pour les clés privées ; ecparam -genkey écrit une EC PRIVATE KEY SEC1, convertissez-la donc avec pkcs8 -topk8 quand un autre outil attend du PKCS#8, comme le fait l’exemple.

La prise en charge post-quantique est partielle : ML-KEM-768 et ML-KEM-1024 sont disponibles via les fonctions MLKEM_* propres à LibreSSL, déclarées dans <openssl/mlkem.h>, et non via EVP ni la ligne de commande, et ML-DSA n’existe pas (Algorithm ML-DSA-65 not found). Comparez les algorithmes dans le bac à sable des KEM post-quantiques ; pour les signatures ML-DSA, utilisez OpenSSL 3.5 ou une version ultérieure.

Les faits et les vérifications qui les fondent

Rien de ce qui suit n’est copié d’une documentation. La vérification content/libraries/verify/libressl/run.sh a exécuté LibreSSL 4.3.1 dans l’image de conteneur alpine:3.24.2 le 20 octobre 2026 ; la page doit correspondre à ce que la vérification a affiché, et chaque fait cite les lignes en question.

  • Encodage des signatures ECDSA

    der

    EVP_DigestSign et libressl dgst -sign produisent de l’ASN.1 DER.

    Relevé par la vérification
    fact ecdsa-signature-encoding = der
  • Nonce ECDSA

    random

    Nonce aléatoire : deux signatures du même message diffèrent ; il n’existe pas d’option déterministe.

    Relevé par la vérification
    fact ecdsa-nonce = random
  • Low-S à la signature

    either

    s n’est pas normalisé : des valeurs high-S sont apparues parmi 64 signatures.

    Relevé par la vérification
    fact ecdsa-low-s-sign = either
  • High-S à la vérification

    accepts-high-s

    Une signature DER dont s a été remplacé par n − s a passé la vérification.

    Relevé par la vérification
    fact ecdsa-low-s-verify = accepts-high-s
  • Ce que l’appel de signature hache

    hashes-message-or-digest

    EVP_DigestSign hache les données ; ECDSA_sign signe un condensat, et cette signature a passé la vérification sur le message.

    Relevé par la vérification
    fact ecdsa-prehash = hashes-message-or-digest
  • Signature ECDSA mal formée

    returns-error

    EVP_DigestVerify a renvoyé -1 pour une signature r‖s brute et pour un bloc de 3 octets.

    Relevé par la vérification
    fact ecdsa-malformed-signature = returns-error
    evidence ecdsa-malformed-signature: EVP_DigestVerify returned -1 for raw r||s and -1 for 3 bytes
  • Sortie de la vérification en cas d’échec

    distinguishable

    dgst -verify a affiché Error Verifying Data pour une signature non DER et Verification Failure pour une signature valide portant sur d’autres données.

    Relevé par la vérification
    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
  • Courbes ECDSA

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

    Signature et vérification réussies avec P-224, P-256, P-384, P-521, secp256k1 et brainpoolP256r1/P384r1/P512r1.

    Relevé par la vérification
    fact ecdsa-curves = P-224, P-256, P-384, P-521, secp256k1, brainpoolP256r1, brainpoolP384r1, brainpoolP512r1
  • EdDSA

    Ed25519

    Ed25519 via EVP_PKEY_ED25519 ; EVP_PKEY_ED448 n’est pas défini.

    Relevé par la vérification
    fact eddsa = Ed25519
    evidence eddsa: EVP_PKEY_ED448 is not defined in the headers
  • Algorithmes post-quantiques

    ML-KEM

    ML-KEM-768 et ML-KEM-1024 ont fonctionné en aller-retour via l’API MLKEM_* ; genpkey -algorithm ML-DSA-65 a échoué avec Algorithm ML-DSA-65 not found.

    Relevé par la vérification
    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
  • Formats de clé publique

    spki-pemspki-derx509

    Les clés publiques SPKI en PEM et en DER ainsi que celle du certificat ont vérifié la même signature.

    Relevé par la vérification
    fact public-key-formats = spki-pem, spki-der, x509
  • Formats de clé privée

    pkcs8-pempkcs8-derencrypted-pkcs8sec1-pemsec1-der

    PKCS#8 en PEM et en DER, PKCS#8 chiffré et SEC1 en PEM et en DER ont tous permis de signer ; ecparam -genkey écrit du SEC1.

    Relevé par la vérification
    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-----

Utilisation

Créer une clé P-256 avec la commande libressl, la convertir en PKCS#8, signer et vérifier, puis montrer qu’Ed25519 fonctionne alors que ML-DSA ne fonctionne pas.
# 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"

Le banc de test des extraits de code exécute chaque exemple tel quel dans l’image de conteneur alpine:3.24.2, et l’exécution échoue si la sortie ne correspond pas.

Mise en place
apk add --no-cache -q libressl=4.3.1-r0 >/dev/null
Commande
OPENSSL_CONF=/dev/null sh usage.sh
La sortie doit correspondre à cette expression régulière
Verified OK\nEd25519 key: -----BEGIN PRIVATE KEY-----\nAlgorithm ML-DSA-65 not found

Bibliothèques