EMSA-PKCS1-v1_5 (RFC 8017 §9.2) construit 0x00 ‖ 0x01 ‖ 0xFF…0xFF ‖ 0x00 ‖ DigestInfo, avec au moins huit octets 0xFF, où DigestInfo est l’encodage DER de l’algorithme de hachage et du condensat. Pour SHA-256, le préfixe DigestInfo est 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20. Il n’y a aucun aléa : la même clé et le même message donnent toujours la même signature.
Où on le trouve : JOSE RS256, RS384 et RS512 (RFC 7518 §3.3) ; X.509 sha256WithRSAEncryption (1.2.840.113549.1.1.11) ; les signatures TLS 1.2 ; DKIM rsa-sha256 ; SSH rsa-sha2-256 et rsa-sha2-512. TLS 1.3 ne l’autorise que pour les signatures contenues dans les certificats (rsa_pkcs1_sha256, 0x0401) ; les signatures du handshake doivent utiliser PSS.
Le piège connu se situe dans les vérificateurs, pas dans le schéma : les parseurs qui ne vérifiaient pas que le DigestInfo remplit le reste du bloc ont permis la falsification de Bleichenbacher de 2006 pour l’exposant public 3. La RFC 8017 §8.2.2 recommande de reconstruire l’encodage du bloc attendu et de comparer les deux, et la FIPS 186-5 §5.4(h) détaille les contrôles requis. Ne confondez pas ce remplissage de signature avec le remplissage de chiffrement PKCS #1 v1.5 (le problème de l’oracle de remplissage) ni avec le format de fichier de clé privée PKCS #1.