libsecp256k1 unterstützt eine einzige Kurve und tut das sorgfältig: zeitkonstantes Signieren, erschöpfende Tests und formale Verifikation von Teilen der Körperarithmetik. Bitcoin Core, viele Wallets und Bindings wie coincurve und das cgo-Backend von go-ethereum setzen die Bibliothek ein. Die Fakten auf dieser Seite wurden mit dem Paket aus Alpine 3.24.2 geprüft, Version 0.5.0 mit den Modulen recovery, extrakeys und schnorrsig; upstream war zu diesem Zeitpunkt bereits 0.8.0 erschienen.
Signaturen liegen in einer opaken Struktur; die Kodierung wird erst beim Serialisieren gewählt – serialize_compact liefert 64 Byte r‖s, serialize_der liefert DER –, und das Parsen ist ebenso explizit. parse_der ist strikt: Die Funktion akzeptierte minimales DER und lehnte dieselbe Signatur mit einer überflüssigen führenden Null in r ab, gemäß den BIP-66-Regeln von Bitcoin. Für laxe historische Signaturen braucht es den laxen Parser, der im Verzeichnis contrib des Repositorys liegt.
Das Signieren erwartet einen 32-Byte-Hash – die Bibliothek hasht deine Nachricht nie selbst –, verwendet RFC 6979 (der Abgleich ergab Übereinstimmung mit einer unabhängigen Implementierung) und erzeugt immer Low-S. Streng ist die Prüfung: Die gespiegelte High-S-Form einer gültigen Signatur scheiterte, und secp256k1_ecdsa_signature_normalize gibt es genau dafür, Signaturen von Allzweck-Signierern zu korrigieren. Besteht eine Signatur aus OpenSSL, Java oder einem Cloud-KMS die Prüfung nur in etwa der Hälfte der Fälle, liegt das an High-S; das Beispiel normalisiert vor der Prüfung.
Öffentliche Schlüssel sind SEC1-Punkte, unkomprimiert 65 Byte oder komprimiert 33 Byte lang; ein 64 Byte langes x‖y wird abgelehnt, und SPKI, PEM oder JWK werden nicht unterstützt. Das Modul recovery stellt den öffentlichen Schlüssel aus einer Signatur wieder her – die Grundlage von Ethereum-Adressen –, und das Modul schnorrsig implementiert BIP-340. Prüfe Signaturen von Bitcoin-Nachrichten mit dem Bitcoin-Nachrichten-Verifizierer und Nostr-Events mit dem Nostr-Event-Verifizierer.