libsecp256k1 は 1 つの曲線だけを、細心の注意を払って実装しています。署名は定数時間で行われ、網羅的なテストがあり、有限体演算の一部は形式検証されています。Bitcoin Core、多くのウォレット、coincurve などのバインディング、go-ethereum の cgo バックエンドがこのライブラリを使っています。ここに挙げる事実は、Alpine 3.24.2 のパッケージ(バージョン 0.5.0、recovery、extrakeys、schnorrsig モジュール付き)で確認したものです。当時、アップストリームは 0.8.0 に達していました。
署名は不透明な構造体に格納され、エンコーディングはシリアライズの時点で選びます。serialize_compact は 64 バイトの r‖s を、serialize_der は DER を返し、解析も同様に明示的です。parse_der は厳格で、Bitcoin の BIP-66 のルールに従い、最小限の DER は受け入れましたが、r に冗長な先頭のゼロを付けた同じ署名は拒否しました。過去の緩い形式の署名には、リポジトリの contrib ディレクトリにある緩いパーサーが必要です。
署名は 32 バイトのハッシュを受け取り(ライブラリがメッセージをハッシュすることはありません)、RFC 6979 を使い(チェックでは独立した実装と一致しました)、常に low-S を生成します。厳格なのは検証のほうです。有効な署名を鏡像にした high-S 形式は失敗し、secp256k1_ecdsa_signature_normalize はまさに汎用の署名実装が作った署名を修正するために存在します。OpenSSL、Java、クラウドの KMS による署名がおよそ半分の確率でしか検証を通らない場合、原因は high-S です。サンプルでは検証の前に正規化しています。
公開鍵は SEC1 の点で、非圧縮形式は 65 バイト、圧縮形式は 33 バイトです。64 バイトの x‖y は拒否され、SPKI、PEM、JWK には対応していません。recovery モジュールは署名から公開鍵を復元し(Ethereum のアドレスはこの仕組みに基づきます)、schnorrsig モジュールは BIP-340 を実装しています。Bitcoin のメッセージ署名は Bitcoin メッセージ検証ツールで、Nostr のイベントは Nostr イベント検証ツールで確認してください。