GnuTLS übernimmt TLS, X.509 und PKCS für viele GNU- und Linux-Komponenten und liefert certtool und gnutls-cli mit. Seine abstrakten Schnittstellen gnutls_privkey_* und gnutls_pubkey_* funktionieren für Software-Schlüssel, PKCS#11-Tokens und TPMs gleich. Die Fakten auf dieser Seite wurden mit dem Paket aus Alpine 3.24.2 geprüft: GnuTLS 3.8.13, das für die Arithmetik Nettle verwendet. Seit GnuTLS 3.8.10 kommen Post-Quanten-Algorithmen nur aus der optionalen Bibliothek leancrypto, und dieses Paket bindet sie nicht ein.
gnutls_privkey_sign_data liefert ECDSA-Signaturen als DER mit zufälliger Nonce; das Flag GNUTLS_PRIVKEY_FLAG_REPRODUCIBLE schaltet auf RFC 6979 um, und damit wurde der P-256-Testvektor des RFC exakt reproduziert. s wird nicht normalisiert, und High-S-Signaturen bestehen die Prüfung. gnutls_privkey_sign_hash2 signiert einen Digest, den du selbst berechnet hast.
Die Prüfung liefert bei einem Fehlschlag einen negativen Fehlercode, und jede Art von Fehlschlag sah gleich aus: Eine rohe r‖s-Signatur, ein 3-Byte-Blob und eine gültige Signatur über andere Daten ergaben alle GNUTLS_E_PK_SIG_VERIFY_FAILED (-89). Schließe mit dem Konverter DER ⇄ Raw ein Kodierungsproblem aus.
ECDSA ist auf die NIST-Kurven P-224 bis P-521 beschränkt – gnutls_ecc_curve_get_id("SECP256K1") gab 0 zurück, also unbekannt –, während Signieren und Prüfen mit Ed25519 und Ed448 funktionierten. Die Header deklarieren GNUTLS_PK_MLKEM768 und GNUTLS_PK_MLDSA65, doch dieser Build implementiert keines von beiden: Beide fehlen in gnutls_pk_list(), das Erzeugen eines ML-DSA-65-Schlüssels scheitert mit GNUTLS_E_UNSUPPORTED_SIGNATURE_ALGORITHM, und die TLS-Gruppen, die gnutls-cli --list auflistet, enthalten X25519 und X448, aber keine hybride Gruppe mit ML-KEM. Code, der gegen diese Konstanten kompiliert, kann zur Laufzeit trotzdem scheitern; prüfe daher die Liste, die die Bibliothek zur Laufzeit liefert. Untersuche Zertifikate, die certtool erzeugt, mit dem Zertifikats-Decoder.