Chiffrement / déchiffrement DES / 3DES / RC4 / Blowfish

Ce que c’est. Le Data Encryption Standard (FIPS 46, 1977) est un chiffrement de Feistel à 16 tours sur des blocs de 64 bits, avec une clé de 56 bits (stockée sur 8 octets, car un bit de chaque octet sert de contrôle de parité). Conçu par IBM avec la participation de la NSA, il est devenu la norme américaine pendant deux décennies, puis a été cassé en pratique en 1998 lorsque la machine Deep Crack de l’EFF a trouvé une clé par force brute en 56 heures pour 250 000 $ de matériel. Le NIST l’a retiré pour le chiffrement en 2005.

Pourquoi le bit de parité brouille les longueurs de clé. Chaque huitième bit d’une clé DES est calculé à partir des sept autres, si bien qu’une clé de 8 octets ne contient que 56 bits indépendants — c’est pourquoi l’on rencontre à la fois « clé de 64 bits » et « clé de 56 bits » pour le même chiffrement. Le 3DES en hérite : 24 octets bruts = 168 bits bruts = 112 bits effectifs (l’attaque « meet-in-the-middle » retire le reste).

Où on le rencontre encore. Les blocs PIN bancaires (ISO 9564), certains domaines Kerberos v4, d’anciennes archives de sauvegarde et les cartes à puce. Si un système exige DES aujourd’hui, il dialogue soit avec du matériel des années 1990, soit il est tout simplement non sécurisé.

L’astuce. Le Triple-DES exécute DES trois fois sur chaque bloc : EDE3 utilise trois clés différentes (C = E_k3(D_k2(E_k1(P)))) ; l’étape de déchiffrement au milieu existe pour qu’une implémentation 3DES puisse émuler le DES simple en posant k1=k2. EDE2 n’utilise que deux clés (k1=k3), ce qui donne 112 bits effectifs. La construction était un correctif rapide qui a triplé la sécurité d’un chiffrement déjà attaqué, sans en inventer un nouveau.

Pourquoi il a tout de même été abandonné. Deux problèmes : il est lent (trois passages DES complets par bloc, environ 1/20 de la vitesse de l’AES) et il conserve le bloc de 64 bits. Avec 32 Gio de données sous une même clé (la borne d’anniversaire de 2³² blocs), les collisions de blocs deviennent assez probables pour révéler la structure du texte clair — l’attaque Sweet32 (2016) l’a démontré contre des sessions TLS 3DES. Le NIST a interdit le chiffrement 3DES après 2023 (SP 800-131A r2) ; la norme PCI DSS exige son retrait dans les systèmes de paiement.

Fonctionnement. RC4 (Ron’s Code 4, conçu en 1987, divulgué en 1994) est un chiffrement en flux : la clé produit une permutation de 256 octets (KSA), puis cette permutation émet un flux d’octets pseudo-aléatoire (PRGA) qui est combiné par XOR avec le message. Ni bourrage, ni taille de bloc, longueur de message quelconque, et très rapide en logiciel — c’est pourquoi il a dominé SSL/TLS et le WEP dans les années 1990. « ARCFOUR » est le nom libre de marque que la plupart des projets open source utilisent.

Comment il a été cassé. Fluhrer, Mantin et Shamir (2001) ont montré que les premiers octets du flux de clés sont biaisés — fatal pour le WEP, dont la construction de clé par paquet transmettait ces octets aux attaquants. Des attaques ultérieures sur les biais (2013, AlFardan et al.) ont permis de retrouver le texte clair de sessions TLS protégées par RC4 sur des millions de connexions. La RFC 7465 (2015) interdit purement et simplement RC4 dans TLS.

Le vecteur classique. La clé « Key » (3 octets) et le message « Plaintext » donnent le chiffré bbf316e8d940af0ad3 — essayez l’exemple RC4 et comparez. L’autotest de cette page vérifie aussi le flux de clés de la RFC 6229 pour la clé de 40 bits 01 02 03 04 05 : b2396305f03dc027ccc3524a0a1118a8.

Ce que c’est. Le chiffrement de Feistel de Bruce Schneier, de 1993 : blocs de 64 bits, clés de 32 à 448 bits (4 à 56 octets), 16 tours, et un célèbre calendrier de clés qui exécute Blowfish lui-même 521 fois pour construire ses sous-clés — ce qui rend la mise en place de la clé lente, mais les tentatives de force brute coûteuses aussi. Aucune cryptanalyse pratique ne casse Blowfish à tous ses tours.

Pourquoi il figure tout de même sur cette page. C’est la taille de bloc de 64 bits qui pose problème, pas l’algorithme : au-delà d’environ 32 Gio sous une même clé, les collisions d’anniversaire divulguent des données (même borne que pour 3DES, type Sweet32). Schneier recommande lui-même son successeur Twofish (finaliste de l’AES) ou l’AES pour tout nouveau projet. Blowfish survit dans bcrypt — le calendrier de clés du hachage de mot de passe est Blowfish — ce qui n’est pas gênant, car le hachage traite de très petites entrées, non des gigaoctets.

Les vecteurs classiques. Une clé entièrement nulle et un texte clair entièrement nul donnent 4ef997456198dd78 (premier bloc de la sortie de l’exemple) ; la clé « abcdefghijklmnopqrstuvwxyz » sur « BLOWFISH » donne 324ed0fef413a203. Les deux proviennent du fichier de vecteurs publié par Schneier et sont vérifiés par l’autotest.

• Les utiliser pour de nouvelles données. Tous les chiffrements de cette page sont dépréciés, sauf Blowfish (limité par la taille du bloc). Le bon choix moderne est l’AES-GCM — voir Chiffrement / déchiffrement AES.
• Une clé DES tirée d’un mot de passe. Un mot de passe de 8 caractères ne représente pas 56 bits aléatoires ; c’est quelques bits d’entropie par caractère. Les anciens systèmes faisaient exactement cela, et c’est la raison la plus courante pour laquelle les archives « chiffrées en DES » tombent en quelques minutes face à une attaque par dictionnaire.
• Réutiliser un IV en CBC. Le premier bloc révèle alors l’égalité de texte clair entre messages sous la même clé. Le bouton IV aléatoire existe pour cette raison.
• Réutiliser un flux de clés RC4. RC4 applique un XOR avec le même flux de clés pour la même clé : chiffrer deux messages avec une seule clé revient à un masque jetable utilisé deux fois — en faisant un XOR des chiffrés, on retrouve les deux textes clairs. La faille fatale du WEP était précisément une construction qui réutilisait le flux de clés.
• Supposer que « ça se déchiffre, donc c’est juste ». L’ECB/CBC ici ne valide que le bourrage au déchiffrement — une mauvaise clé donne en général un résultat illisible qui peut tout de même se débourrer. Aucun mode hérité ne possède de contrôle d’intégrité ; si vous en avez besoin, il vous faut l’AES-GCM, pas ces modes.
• Compter le 3DES comme « 168 bits ». La clé brute fait 168 bits, mais la force effective est de 112 bits — l’attaque « meet-in-the-middle » réduit le triple chiffrement à un double chiffrement plus un peu, exactement comme pour les constructions ancestrales du 3DES.

Pourquoi conserver un outil de chiffrement cassé ? Pour la compatibilité. Les sauvegardes chiffrées, les fichiers exportés dans d’anciens formats, les traces de protocoles capturées, les défis CTF et le matériel impossible à mettre à niveau parlent encore ces chiffrements. Lire d’anciennes données est légitime ; écrire de nouvelles données avec ces chiffrements ne l’est pas.

Ma clé DES a une parité impaire / des octets non ASCII. DES ignore le bit de parité de chaque octet de clé, la clé effective est donc de toute façon constituée des 56 autres bits. Cette page accepte n’importe quels 8 octets et n’impose pas de parité paire.

Pourquoi le texte déchiffré ressemble-t-il parfois à du charabia ? Mauvaise clé, mauvais mode, mauvais IV, ou les données n’ont pas été chiffrées comme vous le supposez. Sans étiquette d’authentification, il n’existe pas d’erreur « mauvaise clé » nette — la vérification du bourrage est le seul indice, et elle peut réussir par hasard (1 fois sur 256).

Blowfish est-il sûr pour mes fichiers ? Pour de petits fichiers, cryptographiquement oui (aucune cassure pratique). Pour tout ce qui atteint la taille du gigaoctet sous une seule clé, non — la borne d’anniversaire du bloc de 64 bits dépend du volume de données, non de la force de la clé. Twofish ou l’AES évitent le problème.

Et les clés Blowfish de 72 octets que j’ai vues quelque part ? Certaines implémentations acceptent jusqu’à 72 octets, mais la référence de Schneier utilise 56, et les octets au-delà n’apportent aucune diffusion supplémentaire dans le calendrier standard. Cette page suit la référence : 4 à 56 octets.