Входные данные — открытый ключ, сообщение (или его дайджест), подпись и алгоритм с параметрами; результат — подпись верна или неверна. Строгая реализация проверки также отклоняет некорректные входные данные: неминимальное кодирование DER, r или s вне диапазона 1…n−1, значение S в EdDSA, которое не меньше порядка группы, подписи в формате raw неправильной длины, точки, не лежащие на кривой, и ключи неподходящего типа.
Большинство ошибок «invalid signature» в рабочих системах не связаны с криптографией: подписаны были другие байты (JSON сериализовали заново, изменились пробелы или окончания строк, пропал завершающий перевод строки), использовался другой хеш, подпись DER попала в код проверки, ожидающий raw (или наоборот), отличается кривая или длина соли PSS либо выбран не тот ключ. Проверяйте входные данные по отдельности; инструмент проверки подписей показывает, какие кривую, хеш и кодировку он использовал.
Правила безопасности, которые предотвращают реальные взломы: фиксируйте алгоритм на стороне проверки, а не читайте его из сообщения (alg в JWT, RFC 8725, § 3.1); проверяйте подпись до того, как разбирать полезную нагрузку или действовать на её основе; проверяйте привязку ключа к удостоверению (проверка цепочки сертификатов, kid в JWKS, known_hosts); а в системах консенсуса закрепите один набор правил проверки, потому что библиотеки расходятся в граничных случаях, например в проверках EdDSA с учётом кофактора.