入力は、公開鍵、メッセージ（またはそのダイジェスト）、署名、アルゴリズムとそのパラメーターで、出力は有効か無効かです。厳格な検証者は、不正な形式の入力も拒否します。最小長でない DER、1…n−1 の範囲外の r や s、群の位数以上の EdDSA の S、長さが誤った raw 形式の署名、曲線上にない点、種類の誤った鍵などです。
本番環境で起きる「invalid signature」エラーの多くは、暗号の問題ではありません。署名されたバイト列が違う（JSON の再シリアライズ、空白や改行コードの変更、末尾の改行の欠落）、別のハッシュが使われた、DER 署名が raw 形式を想定する検証処理に渡された（またはその逆）、曲線や PSS のソルト長が異なる、あるいは誤った鍵が選ばれた、といった原因です。入力を 1 つずつ確認してください。署名検証ツールは、使用した曲線、ハッシュ、エンコーディングを表示します。
実際の破綻を防ぐセキュリティ上のルールは次のとおりです。アルゴリズムはメッセージから読み取らずに検証者側で固定すること（JWT の alg、RFC 8725 §3.1）、ペイロードを解析したり処理に使ったりする前に検証すること、鍵と ID の結び付きを検証すること（証明書パス検証、JWKS の kid、known_hosts）、そしてコンセンサスシステムでは検証ルールのセットを 1 つに固定することです。EdDSA のコファクター付き検証などのエッジケースでは、ライブラリによって判定が異なるからです。