EMSA-PKCS1-v1_5 (RFC 8017, § 9.2) строит 0x00 ‖ 0x01 ‖ 0xFF…0xFF ‖ 0x00 ‖ DigestInfo не менее чем с 8 байтами 0xFF, где DigestInfo — DER-кодирование алгоритма хеширования и самого хеша. Для SHA-256 префикс DigestInfo равен 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20. Случайности в схеме нет, поэтому один и тот же ключ с одним и тем же сообщением всегда даёт одинаковую подпись.
Где используется: RS256, RS384 и RS512 в JOSE (RFC 7518, § 3.3); sha256WithRSAEncryption (1.2.840.113549.1.1.11) в X.509; подписи в TLS 1.2; rsa-sha256 в DKIM; rsa-sha2-256 и rsa-sha2-512 в SSH. TLS 1.3 допускает эту схему только для подписей внутри сертификатов (rsa_pkcs1_sha256, 0x0401); подписи рукопожатия должны использовать PSS.
Известная ловушка кроется в коде проверки, а не в самой схеме: парсеры, которые не проверяли, что DigestInfo занимает весь остаток блока, допускали подделку подписи Блейхенбахера 2006 года для открытой экспоненты 3. RFC 8017, § 8.2.2, рекомендует повторить кодирование ожидаемого блока и сравнить результат с полученным, а FIPS 186-5, § 5.4(h), подробно перечисляет обязательные проверки. Не путайте это дополнение подписи с дополнением шифрования PKCS #1 v1.5 (проблема padding oracle) и с файловым форматом закрытых ключей PKCS #1.