PKCS1 : Public-Key Cryptography Standards #1
Cryptographie
PKCS1 : Public-Key Cryptography Standards #1. « Norme de cryptographie à clé publique numéro un », par analogie avec le mode d'emploi d'un coffre-fort : le coffre existait avant lui, mais c'est lui qui explique comment ne pas s'y coincer les doigts.
Contenu : Le document définit l'usage pratique de RSA : format des clés, primitives mathématiques et schémas de remplissage pour chiffrer et pour signer.
Deux générations : Le remplissage v1.5, historique, côtoie OAEP pour le chiffrement et PSS pour la signature. L'ancien n'a jamais été vraiment chassé ; il a été contourné, ce qui dans ce métier tient lieu d'enterrement.
Le piège du chiffrement v1.5 : Un serveur qui laisse deviner si un remplissage v1.5 déchiffré est valide offre un oracle : l'attaque de Bleichenbacher en tire le contenu, requête après requête.
Sous le nom : Les identifiants d'algorithmes comme RS256 désignent une signature RSA avec remplissage v1.5 et SHA-256, ce qui reste acceptable pour la signature.
Ce qui arrive si on s'en passe
Utiliser RSA sans les remplissages décrits par cette norme revient à manipuler la formule mathématique nue : le même message chiffré donne toujours le même résultat, ce qui permet de reconnaître des messages déjà vus, et le produit de deux chiffrés ou de deux signatures se combine de façon exploitable. Un attaquant peut alors fabriquer des signatures valides sur des messages jamais signés ou deviner des contenus courts par essais. Avec le remplissage v1.5 appliqué au chiffrement, le danger se déplace : chaque message d'erreur qui distingue un remplissage valide d'un invalide devient une source d'information que l'attaquant interroge jusqu'à obtenir le clair. OAEP pour chiffrer et PSS pour signer ferment ces portes.
Explication de la marmotte
Il existe une célèbre méthode mathématique pour chiffrer et signer des messages avec deux clés, une publique et une secrète. Mais la méthode brute a des faiblesses : utilisée telle quelle, un même message donne toujours le même résultat, et on peut parfois le bricoler. Ce document officiel explique comment s'en servir correctement : comment écrire les clés, et surtout comment « emballer » le message avec du remplissage avant de le chiffrer ou de le signer, un peu comme on cale un objet fragile dans un carton avant de l'expédier.
Où ce terme est utilisé
- L'attaque de Bleichenbacher : un oracle de padding contre RSA PKCS#1 v1.5 (8 occurrences)
- Dimensionner un cluster HSM à forte charge transactionnelle (3 occurrences)
- Auditer un HSM pour la conformité PCI DSS dans les paiements (2 occurrences)
- Choisir ECDSA, EdDSA ou RSA pour un certificat TLS (2 occurrences)
- Héritage, politique et limites de la cryptographie (2 occurrences)
- Comprendre la cryptanalyse sans perdre le fil pratique (1 occurrence)
- Créer, vérifier et utiliser les clés dès le départ (1 occurrence)
- Extensions X.509 v3 Key Usage EKU et Basic Constraints (1 occurrence)
- Formats, bibliothèques et API : rendre la crypto utilisable (1 occurrence)
- Lire une garantie sans la surinterpréter (1 occurrence)