Avant qu’AES ne devienne le standard mondial en 2001, l’histoire des chiffrements par blocs s’est jouée sur quarante ans, entre IBM, la NSA, des chercheurs académiques et un concours public. Comprendre cette histoire ne relève pas de la curiosité : on rencontre encore aujourd’hui du DES en mainframe bancaire, du 3DES en lecteur de carte à puce, du Blowfish dans des produits embarqués anciens, du Lucifer dans des manuels universitaires. Savoir lire un dump qui parle de ces algorithmes, savoir migrer un système qui les utilise, savoir refuser le bon argument quand un fournisseur prétend qu’un 3DES « c’est encore bon » — voilà l’utilité concrète. Ce tutoriel propose un parcours pratique en huit étapes : Lucifer côté Python pour comprendre la mécanique, DES et 3DES en OpenSSL pour reproduire ce que fait le legacy, Blowfish et Twofish en bibliothèque tierce, AES en bibliothèque standard, et migration de bout en bout d’un fichier 3DES vers AES-GCM.

Pour la vue d’ensemble, voir le guide principal : Cryptographie pratique pour développeurs et sysadmins.

Prérequis

OpenSSL 3.0+ (qui marque DES et 3DES comme legacy mais les supporte encore)
Python 3.10+ avec cryptography et pycryptodome
Lecture préalable des tutoriels AES et RSA appliqués recommandée
45 minutes

Étape 1 — Lucifer, l’ancêtre méconnu

Lucifer a été conçu chez IBM par Horst Feistel à la fin des années 1960 — le premier chiffrement par blocs civil qui présentait une structure mathématique propre. Sa version finale (1973) utilisait des blocs de 128 bits et une clé de 128 bits, déjà des paramètres modernes. Lucifer n’a jamais été déployé tel quel mais a servi de base directe au développement de DES — sa structure dite réseau de Feistel est encore utilisée dans des chiffrements récents.

Pour comprendre ce qu’est un réseau de Feistel, le coder en Python sur deux rounds suffit. C’est un exercice purement pédagogique — ne jamais utiliser cette implémentation pour de vraies données — mais qui éclaire la mécanique de DES et de tous ses descendants :

def feistel_round(left: int, right: int, sous_cle: int, taille: int) -> tuple[int, int]:
    # Fonction F simplifiée : XOR avec sous-clé puis rotation
    masque = (1 << taille) - 1
    f = ((right ^ sous_cle) << 3 | (right ^ sous_cle) >> (taille - 3)) & masque
    nouveau_droit = left ^ f
    return right, nouveau_droit

def feistel_chiffrer(bloc: int, sous_cles: list, taille: int = 16) -> int:
    half = taille // 2
    masque = (1 << half) - 1
    left, right = bloc >> half, bloc & masque
    for sk in sous_cles:
        left, right = feistel_round(left, right, sk, half)
    return (right << half) | left  # swap final caractéristique

# Test pédagogique sur 16 bits
bloc_clair = 0xABCD
sous_cles = [0x1234, 0x5678, 0x9ABC, 0xDEF0]
chiffre = feistel_chiffrer(bloc_clair, sous_cles)
print(f"Clair  : {bloc_clair:04X}")
print(f"Chiffre: {chiffre:04X}")

Cette implémentation jouet montre les ingrédients : un bloc divisé en deux moitiés, plusieurs rounds où une fonction F transforme une moitié en utilisant une sous-clé, le résultat XORé avec l’autre moitié, et un échange à chaque round. La beauté du Feistel : le déchiffrement utilise exactement la même fonction avec les sous-clés en ordre inverse.

Étape 2 — DES, le standard de 1977 cassé en 1998

DES (Data Encryption Standard) est dérivé de Lucifer après modifications par la NSA. Adopté par le NIST en 1977 comme standard fédéral américain, il a régné pendant vingt ans avant d’être officiellement cassé. Ses caractéristiques : blocs de 64 bits, clé effective de 56 bits (les 8 derniers bits sont des parités). En 1998, l’EFF (Electronic Frontier Foundation) construit la Deep Crack machine à 250 000 USD qui casse une clé DES en 56 heures par force brute. La fin officielle du standard.

OpenSSL supporte encore DES en mode legacy. Pour reproduire un chiffrement DES (uniquement pour comprendre le format ou interopérer avec un système ancien) :

echo "Donnees historiques" > clair.txt
openssl enc -des-cbc -in clair.txt -out chiffre.des -pbkdf2 -iter 100000 -provider legacy -provider default

L’option -provider legacy -provider default est devenue obligatoire à partir d’OpenSSL 3.0 — DES n’est plus dans le provider par défaut, c’est explicitement refusé sans le geste opt-in. Le message clair : ne pas l’utiliser pour de nouveaux systèmes.

Cas d’usage légitime aujourd’hui : déchiffrer un fichier ancien, lire un dump issu d’un mainframe, comprendre un protocole legacy bancaire. Hors de ces cas, basculer.

Étape 3 — 3DES, la rallonge de DES

Quand DES est devenu suspect dans les années 1990, l’industrie a inventé 3DES (Triple DES) : appliquer DES trois fois de suite avec deux ou trois clés différentes, ce qui porte la clé effective à 112 ou 168 bits. Mathématiquement plus robuste, mais lent (trois fois DES qui n’est déjà pas rapide) et toujours bridé par le bloc de 64 bits — vulnérable à l’attaque Sweet32 publiée en 2016 — qui exploite la collision de blocs de 64 bits dès qu’on chiffre quelques dizaines de gigaoctets avec la même clé (NIST limite 3DES à 2²⁰ blocs, soit environ 8 Go maximum par clé).

Le NIST a annoncé la dépréciation de 3DES en 2017 (publication NIST SP 800-67 Rev.2), formalisée en 2019 dans SP 800-131A Rev.2, et a interdit son usage en chiffrement après le 31 décembre 2023 (le déchiffrement legacy reste autorisé). Il subsiste néanmoins dans des terminaux de paiement, des modules HSM bancaires anciens, et certains protocoles industriels (SCADA, contrôleurs de machines). Pour interopérer :

openssl enc -des-ede3-cbc -in clair.txt -out chiffre.3des -pbkdf2 -iter 100000 -provider legacy -provider default

Là encore, le mode legacy doit être activé explicitement. Pour un sysadmin qui découvre un système chiffré en 3DES, la procédure recommandée : déchiffrer une bonne fois, rechiffrer immédiatement en AES-GCM, retirer le 3DES de la chaîne.

Étape 4 — Blowfish et Twofish, les outsiders

Blowfish a été conçu par Bruce Schneier en 1993 — gratuit, sans brevet, plus rapide que DES, devenu populaire dans les bibliothèques cryptographiques des années 90. Bloc de 64 bits comme DES, clé jusqu’à 448 bits. La version qui survit aujourd’hui : bcrypt, l’algorithme de hachage de mots de passe que tout le monde utilise — son schéma de dérivation est basé sur Blowfish.

Twofish est le successeur de Blowfish, finaliste du concours AES en 2000 où il a perdu face à Rijndael (renommé AES). Twofish reste sécurisé — il est utilisé en option par VeraCrypt et OpenPGP — mais le marché s’est uni autour d’AES.

Exemple Python avec pycryptodome qui couvre Blowfish (la bibliothèque cryptography ne le propose pas) :

from Crypto.Cipher import Blowfish
from Crypto.Random import get_random_bytes
from Crypto.Util.Padding import pad, unpad

cle = get_random_bytes(16)  # 128 bits, dans la plage Blowfish
iv = get_random_bytes(8)
chiffreur = Blowfish.new(cle, Blowfish.MODE_CBC, iv)
chiffre = chiffreur.encrypt(pad(b"Donnees test Blowfish", Blowfish.block_size))
print(iv.hex(), chiffre.hex())

Ce code illustre la même mécanique CBC qu’on a vue avec DES — bloc de 64 bits, IV, padding nécessaire. Pour de la production, ne pas utiliser Blowfish — basculer sur AES ou ChaCha20 — sauf pour interagir avec un format legacy spécifique.

Étape 5 — AES, le standard depuis 2001

Le concours AES lancé par le NIST en 1997 a sélectionné l’algorithme Rijndael de Joan Daemen et Vincent Rijmen, qui devient AES en 2001. Caractéristiques : blocs de 128 bits, clé de 128/192/256 bits, structure non-Feistel (substitution-permutation network) plus moderne, conception qui anticipe l’accélération matérielle (AES-NI sur Intel à partir de 2010).

Vingt-cinq ans après son adoption, AES reste résistant à toutes les attaques cryptographiques connues. Les attaques publiées (XSL, biclique) abaissent la complexité théorique mais restent astronomiquement loin du praticable — AES-256 reste le standard à long terme. Pour son utilisation appliquée concrète, voir le tuto dédié : Chiffrer en AES-256-GCM avec OpenSSL et Python.

Étape 6 — Détecter un algorithme legacy dans un système

Pour un sysadmin qui découvre un parc, identifier les usages d’algorithmes obsolètes est la première étape de la migration. Quatre indicateurs trahissent un système qui dort sur du DES, 3DES ou Blowfish.

Le premier : l’inspection des configurations TLS. Sur un serveur web ou mail, lancer nmap –script ssl-enum-ciphers -p 443 serveur.exemple.com liste les suites acceptées. Toute mention de 3DES, DES, RC4, ou EXPORT signale une configuration à durcir d’urgence. Sur un Nginx, retirer ces suites de ssl_ciphers. Sur un Apache, idem dans SSLCipherSuite.

Le deuxième : l’inspection des bases de données. Les hash de mots de passe en MD5 (32 caractères hex) ou SHA-1 (40 caractères hex) sont les marqueurs d’un système sous-protégé. Une requête SELECT password FROM users LIMIT 1 révèle souvent immédiatement le format. Si on voit autre chose que $2b$ (bcrypt), $argon2id$ (Argon2) ou un hash similaire moderne, le chantier de migration commence.

Le troisième : les fichiers chiffrés en archive. Un fichier .gpg peut être inspecté sans déchiffrement avec gpg –list-packets — la sortie indique l’algorithme symétrique utilisé. Si on voit S2K cipher: 3DES ou CAST5, l’archive ancienne attend une migration. Pour un conteneur VeraCrypt, l’algorithme est affiché dans les propriétés du volume monté.

Le quatrième : les configurations applicatives. grep -ri « des\|3des\|md5\|sha1\|blowfish » /etc/ et dans le code applicatif fait remonter les références. Beaucoup de chaînes de connexion JDBC, de fichiers de configuration historiques, de scripts de déploiement portent encore ces algorithmes.

Étape 7 — Migrer un fichier 3DES vers AES-GCM

Cas concret de migration. Un fichier archive.3des chiffré en 3DES-CBC avec une phrase secrète. La procédure standard : déchiffrer en 3DES, rechiffrer immédiatement en AES-256-GCM, supprimer le fichier 3DES original, renouveler la phrase secrète. Le script Python :

import os, getpass, subprocess
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC
from cryptography.hazmat.primitives import hashes

# Étape 1 : déchiffrer le 3DES via OpenSSL legacy
ancienne_phrase = getpass.getpass("Ancienne phrase 3DES: ")
subprocess.run([
    'openssl', 'enc', '-d', '-des-ede3-cbc', '-pbkdf2', '-iter', '100000',
    '-provider', 'legacy', '-provider', 'default',
    '-in', 'archive.3des', '-out', 'archive.tmp',
    '-pass', f'pass:{ancienne_phrase}'
], check=True)

# Étape 2 : lire le contenu déchiffré
with open('archive.tmp', 'rb') as f:
    contenu = f.read()

# Étape 3 : rechiffrer en AES-256-GCM avec une nouvelle phrase
nouvelle_phrase = getpass.getpass("Nouvelle phrase AES (forte): ").encode()
sel = os.urandom(16)
nonce = os.urandom(12)
cle = PBKDF2HMAC(hashes.SHA256(), 32, sel, 600_000).derive(nouvelle_phrase)
chiffre = AESGCM(cle).encrypt(nonce, contenu, None)

with open('archive.aes', 'wb') as f:
    f.write(sel + nonce + chiffre)

# Étape 4 : effacer les fichiers temporaires
os.remove('archive.tmp')
print("Migration terminee. Verifier archive.aes puis supprimer archive.3des manuellement.")

Quatre précautions à respecter dans ce type de migration. Premièrement, ne jamais supprimer le fichier source avant d’avoir vérifié que le déchiffrement de la version migrée fonctionne. Deuxièmement, renouveler la phrase secrète à la migration — l’ancienne a peut-être circulé pendant des années. Troisièmement, écraser proprement le fichier intermédiaire archive.tmp avec shred -u sur Linux ou cipher /w sur Windows — un rm ne suffit pas pour un secret. Quatrièmement, tester la restauration immédiatement après en déchiffrant la nouvelle archive et en comparant au contenu attendu.

Les mathématiques en clair

Comprendre pourquoi DES est tombé et pourquoi 3DES a vacillé n’est pas qu’un exercice d’histoire — c’est une leçon directement applicable au choix d’un algorithme moderne. Trois mathématiques se croisent : la structure de Feistel qui permet à un même circuit de chiffrer et déchiffrer, la longueur de clé qui détermine la résistance à la force brute, et le paradoxe des anniversaires qui décide la durée de vie d’une clé dans un mode CBC.

Le réseau de Feistel : une bijection presque pour rien

Horst Feistel a publié en 1973 une construction qui permet de transformer n’importe quelle fonction F (même non-inversible) en un chiffrement par blocs inversible. L’idée tient en deux gestes. Découper le bloc clair en deux moitiés L_0 et R_0. À chaque round i, calculer L_i = R_{i-1} et R_i = L_{i-1} ⊕ F(R_{i-1}, K_i), où K_i est une sous-clé dérivée de la clé principale. Après n rounds, on obtient le chiffré (L_n, R_n).

Le miracle vient du déchiffrement. En reprenant (L_n, R_n) et en appliquant les sous-clés en ordre inverse avec exactement la même fonction F, on retrouve (L_0, R_0). La preuve mathématique : L_{i-1} = R_i ⊕ F(L_i, K_i), qui se déduit immédiatement des équations de chiffrement. Autrement dit, un Feistel est auto-inversif — un seul circuit matériel suffit pour chiffrer et déchiffrer. C’est la raison pour laquelle DES, 3DES, Blowfish et Twofish ont tous adopté cette structure : elle économisait des transistors à une époque où chaque porte logique comptait.

DES : pourquoi 56 bits, et pourquoi c’est tombé

DES utilise une clé de 56 bits effectifs (les 8 bits de parité dans la clé déclarée à 64 bits ne contribuent pas à la sécurité). L’espace des clés à explorer en force brute compte donc 2⁵⁶ ≈ 7,2 × 10¹⁶ valeurs. En 1977 à l’adoption du standard, tester toutes ces clés demandait des décennies sur les ordinateurs disponibles. La loi de Moore appliquée naïvement (doublement de la puissance tous les deux ans) prédisait que cette barrière tomberait vers 2000 — l’EFF l’a précipitée à 1998 avec sa machine spécialisée Deep Crack, qui testait 9 × 10¹⁰ clés par seconde et trouvait n’importe quelle clé DES en 56 heures.

Aujourd’hui, un seul GPU consumer haut de gamme casse une clé DES en quelques heures. Ce qui était une borne pratique en 1977 est devenu un exercice de fin de semaine en 2026. La leçon mathématique : doubler le nombre de bits effectifs de la clé multiplie le coût d’attaque par 2 à chaque bit. AES-128 demande 2¹²⁸ ≈ 3,4 × 10³⁸ tentatives — 2⁷² fois plus que DES. Aucune machine concevable ne testera jamais ce nombre de clés.

3DES : la rallonge mathématiquement bancale

Pour prolonger DES sans tout réécrire, l’industrie a imaginé 3DES : appliquer DES trois fois de suite avec des clés différentes K_1, K_2, K_3 dans la séquence chiffre-déchiffre-chiffre. Mathématiquement C = E_{K_3}(D_{K_2}(E_{K_1}(P))). Cette construction utilise 168 bits de clé en mode trois clés ou 112 bits en mode deux clés (K_1 = K_3). On pourrait s’attendre à 2¹⁶⁸ de sécurité — mais une attaque ancienne dite meet-in-the-middle réduit la sécurité effective à environ 2¹¹² (deux clés indépendantes vues par un adversaire qui dispose de mémoire).

Le vrai défaut de 3DES n’est pas la clé mais le bloc. Hérité de DES, il fait toujours 64 bits, soit 8 octets seulement. Et là intervient la deuxième mathématique fondamentale : le paradoxe des anniversaires.

Le paradoxe des anniversaires et l’attaque Sweet32

Dans une salle de 23 personnes, la probabilité que deux d’entre elles partagent un anniversaire dépasse 50 %. Le résultat surprend l’intuition mais découle d’un calcul simple : on a 23 × 22 / 2 = 253 paires possibles, et chacune a 1/365 chance de coïncider — soit environ 50 % en cumulé. Plus généralement, dans un espace de N valeurs distinctes, deux tirages aléatoires entrent en collision après environ √N tirages.

Appliqué à un chiffrement par blocs en mode CBC, ce paradoxe est dévastateur. Avec un bloc de 64 bits, l’espace des blocs chiffrés possibles est de 2⁶⁴. Une collision (deux blocs chiffrés identiques) survient après environ √(2⁶⁴) = 2³² ≈ 4 milliards de blocs, soit 2³² × 8 = 2³⁵ octets ≈ 32 Go chiffrés. Quand cette collision se produit, l’attaquant peut, par XOR successifs, récupérer la différence entre deux clairs — ce qui révèle souvent des secrets (cookies HTTP, jetons d’authentification). C’est l’attaque Sweet32 publiée par Bhargavan et Leurent en 2016, et c’est ce qui a mis fin à 3DES en TLS et OpenVPN.

AES, avec un bloc de 128 bits, repousse cette borne à √(2¹²⁸) = 2⁶⁴ blocs avant collision, soit 2⁶⁴ × 16 = 2⁶⁸ octets ≈ 295 milliards de gigaoctets. Un volume que personne ne chiffre jamais avec une seule clé. La leçon mathématique : doubler la taille du bloc met l’attaque par anniversaire hors de portée pour toutes les durées de clé pratiques.

Pourquoi AES n’est pas un Feistel

Daemen et Rijmen ont pris l’inverse du choix Feistel : leur algorithme Rijndael (devenu AES) est un Substitution-Permutation Network (SPN). À chaque round, l’ensemble du state passe par les quatre étapes SubBytes-ShiftRows-MixColumns-AddRoundKey vues précédemment, sans découper le bloc en deux moitiés. Avantage : la diffusion est plus rapide, deux rounds suffisent pour qu’un bit clair influence tous les bits du chiffré, contre quatre à six rounds pour un Feistel. Inconvénient : le déchiffrement demande des opérations distinctes (InvSubBytes, InvShiftRows, InvMixColumns) et donc un peu plus de matériel — un compromis acceptable à l’ère des transistors bon marché.

Le passage du Feistel au SPN à la transition DES → AES illustre l’évolution du raisonnement cryptographique : on optimise la sécurité par cycle d’horloge, pas la sécurité par transistor. C’est cette même logique qui a guidé le choix d’ARX dans ChaCha20 — où les opérations sont encore plus simples que les S-box d’AES, et où la rapidité vient de l’absence de toute table.

Étape 8 — Communiquer la migration à l’organisation

Une migration cryptographique n’est complète qu’avec sa documentation. Un message court à l’équipe ou à la direction : quels systèmes ont été migrés, depuis quel algorithme, vers AES-256-GCM ou ChaCha20-Poly1305, à quelle date, qui détient la nouvelle phrase ou clé, où elle est sauvegardée, qui a accès à la procédure de récupération. Une page wiki ou un fichier SECURITY.md à jour évite que la migration soit perdue dans six mois quand un autre administrateur reprend le dossier.

Pour les entreprises soumises à audit (banques, assurances, structures publiques), la documentation devient une obligation. Les normes ISO 27001 et PCI-DSS exigent explicitement le retrait des algorithmes obsolètes et la trace des opérations de migration.

Vérification du livrable

La structure d’un réseau de Feistel est comprise (Lucifer, DES)
Un fichier DES ou 3DES legacy peut être déchiffré avec OpenSSL en mode legacy
Un audit de configuration TLS a été lancé et les suites obsolètes retirées
Un script de migration 3DES → AES-GCM tourne sur un fichier de test
La documentation de migration est rédigée et stockée

Erreurs fréquentes

Erreur	Conséquence	Solution
« 3DES c’est encore bon »	Vulnérabilité Sweet32 + clé bridée	Migration AES-256-GCM ou ChaCha20-Poly1305
Garder du DES en TLS	Note F sur SSL Labs, attaques publiées	Retirer DES, 3DES, RC4 de ssl_ciphers
Suppression simple du fichier intermédiaire	Récupération possible sur disque	shred -u (Linux) ou cipher /w (Windows)
Phrase secrète recyclée à la migration	Compromission antérieure transmise	Renouveler la phrase à chaque migration
Migration sans test de restauration	Perte irréversible si bug	Test immédiat après chiffrement nouveau format

Mainframes bancaires UEMOA et terminaux de paiement

Trois cas locaux fréquents où ce parcours sert directement. Les systèmes bancaires hérités au Sénégal, en Côte d’Ivoire et au Mali, basés sur des solutions des années 2000-2010, contiennent encore du 3DES dans les couches d’échange interbancaire UEMOA — comprendre la structure et préparer la migration vers AES-GCM est un sujet d’audit standard pour les équipes IT bancaires en zone CEDEAO. Les terminaux de paiement (TPE) en agence reposent sur des clés DES ou 3DES de session — leur renouvellement régulier suit la norme PCI-DSS et impose des opérations de chargement de clé sécurisées, en présence physique du technicien certifié. Et les logiciels métier sur mesure développés en PHP 5 ou Java 7 il y a dix ans pour des PME locales ont souvent du md5(password) en base : la migration vers bcrypt ou argon2id se fait progressivement à la connexion suivante de chaque utilisateur.

Tutoriels frères

Pour aller plus loin

🔝 Retour au guide principal : Cryptographie pratique pour développeurs et sysadmins

Sources et références

NIST SP 800-67 Rev.2 — recommandations 3DES
NIST SP 800-131A Rev.2 — transition algorithmes
Sweet32 — attaque sur 3DES et Blowfish
Page Blowfish de Bruce Schneier
NIST AES Development — historique du concours AES

De Lucifer à AES : comprendre, lire et migrer les chiffrements par blocs historiques