EMSA-PKCS1-v1_5 (RFC 8017 §9.2) bildet 0x00 ‖ 0x01 ‖ 0xFF…0xFF ‖ 0x00 ‖ DigestInfo mit mindestens acht 0xFF-Bytes, wobei DigestInfo die DER-Kodierung von Hashalgorithmus und Hash ist. Für SHA-256 lautet das DigestInfo-Präfix 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20. Das Verfahren nutzt keinen Zufall: Derselbe Schlüssel und dieselbe Nachricht ergeben immer dieselbe Signatur.
Einsatzgebiete: JOSE RS256, RS384 und RS512 (RFC 7518 §3.3); X.509 sha256WithRSAEncryption (1.2.840.113549.1.1.11); Signaturen in TLS 1.2; DKIM rsa-sha256; SSH rsa-sha2-256 und rsa-sha2-512. TLS 1.3 erlaubt es nur für Signaturen in Zertifikaten (rsa_pkcs1_sha256, 0x0401); Signaturen im Handshake müssen PSS verwenden.
Der bekannte Fallstrick liegt bei den Verifizierern, nicht im Verfahren: Parser, die nicht prüften, ob die DigestInfo den Rest des Blocks ausfüllt, ermöglichten 2006 Bleichenbachers Fälschung für den öffentlichen Exponenten 3. RFC 8017 §8.2.2 empfiehlt, den erwarteten Block neu zu kodieren und zu vergleichen, und FIPS 186-5 §5.4(h) legt die erforderlichen Prüfungen fest. Verwechsle dieses Signaturpadding nicht mit dem Verschlüsselungspadding von PKCS #1 v1.5 (dem Padding-Oracle-Problem) oder mit dem Dateiformat für private Schlüssel nach PKCS #1.