[...]
Au commencement était ECB.
Ce mode souffre du coup d’un énorme problème. Si plusieurs blocs contiennent les mêmes données, alors les blocs de sortie contiendront aussi les mêmes données ! Vous ne devez aussi jamais réutiliser la même clef pour chiffrer 2 messages différents. [...] Vous obtenez donc les données en clair XORées entre elles. Avec un peu d’analyse, on peut retrouver A et B.
Dans les commentaires :
Oui effectivement, j’aurais du préciser que l’ECB ou CBC présenté utilisait comme chiffrement de bloc un XOR, alors qu’en réalité, tu y mets ce que tu veux (AES et companie). Le XOR a l’avantage de bien exposer les problèmes d’ECB.
Reprenons :
Puis CBC apparu
On voit que le soucis de ECB vient du fait qu’on réutilise la même clef pour tous les blocs, ce qui fait qu’à entrée (et donc clef) identique, la sortie sera identique. Vu qu’on ne maîtrise pas les données d’entrée, on ne peut jouer que sur la clef de chiffrement. Il faut trouver un moyen de la faire varier pour chaque bloc, pour qu’enfin à données identiques, on obtienne bien une sortie différente. La solution retenue est simplement d’utiliser la sortie du bloc précédent, de la mixer avec la clef et d’utiliser le résultat comme nouvelle clef de bloc [...] Les petits malins en mathématiques vont s’apercevoir d’un problème pour i=0. En effet, on n’a pas encore de bloc précédent pour mixer avec la clef… Du coup, on va résoudre cette étape avec une donnée aléatoire, appeler vecteur d’initialisation (IV)
Bien que cela soit beaucoup moins critique que pour ECB, il ne faut à nouveau jamais réutiliser la même clef ou le même IV pour chiffrer 2 données. Un attaquant possédant 2 textes chiffrés par la même clef ou IV peut à nouveau en déduire des choses sur les données d’entrées.
Il reste aussi un autre problème à résoudre. Les données chiffrées restent malléables par un attaquant potentiel, le fonctionnement des chiffrements ne pouvant en effet pas détecter une modification et toute entrée chiffrée conduit obligatoirement à une donnée en clair valide. [...] Sans rien connaître du texte en clair, l’attaquant est capable de le modifier sans que cette modification ne soit décelable.
AEAD à la rescousse
Afin d’authentifier plus fortement les données chiffrées, les cryptologues ont conçu un dernier mode de chiffrement : AEAD (Authenticated Encryption with Associated Data). Dans le cadre du chiffrement, le mode AEAD le plus connu est sans conteste GCM (Galois/Counter Mode).
Je vous passe les détails techniques qui sont autrement plus complexes que les modes précédents, mais en l’utilisant, toute modification du contenu chiffré sera détecté, comblant cette lacune de CBC.
[...]
Implémentation concrète
Implémenter du chiffrement correct n’est pas si simple. La difficulté vient du fait qu’on ne doit jamais réutiliser la même clef de chiffrement ni le même IV. La clef de chiffrement ne doit en plus jamais être communiquée au public (alors que l’IV peut l’être). Et en pratique, on souhaite pouvoir déchiffrer les données en s’échangeant uniquement un mot de passe.
On peut régler tous les problèmes à partir d’une dérivation de clef PBKDF2. Partant du mot de passe, d’un sel généré aléatoirement et d’un nombre d’itérations, on peut calculer 2X bits aléatoire en calculant random = PBKDF2(password, salt, iterations, 2X) (en pratique, X = 128 ou 256). Ces 2X bits sont ensuite découpés en X bits de clef de chiffrement et X bits d’IV key, iv = random[0..X], random[X..2X]. Cette procédure garantie au passage que la clef et l’IV ne seront jamais réutilisés puisque à mots de passe identique, le sel sera différent donc la clef et l’IV aussi. On peut ensuite chiffrer proprement avec AES-X-GCM