Cryptographie : quatre méthodes, de César à Alice et Bob

La cryptographie transforme un message lisible en un texte dont la lecture exige une clé. Les trois premières méthodes se découvrent avec papier et crayon ou dans un tableur ; la quatrième introduit deux clés différentes. Testez chaque étape dans le laboratoire interactif. La couverture évoque le passage des transformations de lettres aux clés publique et privée : c’est une illustration conceptuelle, pas un schéma technique.

1. Substitution : décaler les lettres

Choisissons k=2 et les lettres A–Z. Chaque lettre est remplacée par celle située deux positions plus loin, avec retour à A après Z : S→U, A→C, L→N. Ainsi SALVATORE devient UCNXCVQTG. Pour déchiffrer, décalons chaque lettre de deux positions en arrière : U→S, C→A, jusqu’à retrouver SALVATORE. C’est le principe du chiffre de César, mais la fréquence des lettres reste reconnaissable : il ne protège pas des données réelles.

2. Transposition : changer l’ordre, pas les lettres

Avec la clé MOSAI et le texte SALVATORE, écrivons les lettres de gauche à droite sous cinq colonnes :

M O S A I
S A L V A
T O R E

Les colonnes initiales sont ST | AO | LR | VE | A. En les lisant dans l’ordre alphabétique des lettres de la clé, A,I,M,O,S, on obtient VE | A | ST | AO | LR, soit VEASTAOLR. Bob connaît la même clé : il détermine la longueur de chaque colonne, les remplit dans l’ordre alphabétique et lit de nouveau les lignes pour retrouver SALVATORE. Cette version supprime espaces, accents et ponctuation avant le chiffrement ; ils ne peuvent pas être restaurés automatiquement.

3. XOR : la même clé numérique chiffre et déchiffre

Prenons l’octet ASCII de la première lettre, S=83, et une clé d’un octet 113. L’opération bit à bit donne 83 XOR 113 = 34, soit 22 en hexadécimal. Une nouvelle application de la clé donne 34 XOR 113 = 83 : S réapparaît. Pour SALVATORE, la séquence hexadécimale complète est 22303D2730253E2334. Le laboratoire applique XOR aux octets UTF-8 et traite donc aussi les messages non ASCII. Répéter un seul octet de clé est peu sûr : cela illustre uniquement (m XOR k) XOR k = m.

4. Clé asymétrique : Alice écrit à Bob

Dans notre exemple RSA, Bob choisit deux nombres premiers, p=61 et q=53. Il calcule n=pq=3233 et φ(n)=(p−1)(q−1)=3120. Il choisit e=17, premier avec 3120, et trouve d=2753, car 17×2753=46801=15×3120+1. Il publie (n,e)=(3233,17) et garde d=2753 secret.

Alice veut envoyer CIAO. Ses octets UTF-8 sont 67,73,65,79. Pour chaque octet m, elle utilise la clé publique de Bob et calcule c=m^17 mod 3233 :

C: 67^17 mod 3233 = 641
I: 73^17 mod 3233 = 1486
A: 65^17 mod 3233 = 2790
O: 79^17 mod 3233 = 1307

Elle envoie 641 1486 2790 1307. Bob applique sa clé privée à chaque bloc : m=c^2753 mod 3233. Il retrouve dans l’ordre 67,73,65,79 ; le décodage UTF-8 redonne CIAO. Mathématiquement, e×d≡1 (mod φ(n)). Alice n’a jamais eu besoin de la clé privée de Bob.

À l’intérieur du calcul pour une lettre

Au lieu de construire l’immense puissance 65^17, Alice élève au carré en réduisant chaque fois modulo 3233 : 65²≡992, 65⁴≡1232, 65⁸≡1547 et 65¹⁶≡789. Comme 17=16+1, 65¹⁷≡789×65≡2790 (mod 3233). Bob applique la même méthode avec 2753=2048+512+128+64+1 et retrouve 65. Voici le chiffrement et le déchiffrement concrets de la lettre A.

Ce que cet exemple montre, et ses limites

Il distingue la clé partagée de la paire publique/privée, mais ne protège aucune donnée réelle. Les petits nombres premiers se factorisent à la main, chaque octet est chiffré séparément et aucun bourrage n’est utilisé. Pour une application réelle, la norme RFC 8017 décrit RSAES-OAEP : ne reprenez pas ce RSA élémentaire dans un système de sécurité. En outre, connaître une clé publique ne prouve pas qu’elle appartient vraiment à Bob : son identité doit être vérifiée. Ouvrir le laboratoire et essayer un autre message →