Choisir, combiner et migrer les algorithmes symétriques

Choisir, combiner et migrer les algorithmes symétriques

Choisir un algorithme symétrique en 2026 est presque ennuyeux, et c’est une excellente nouvelle : deux constructions couvrent l’immense majorité des besoins, une troisième occupe le terrain des objets contraints. Les ennuis commencent ailleurs, quand on veut « renforcer » en empilant des algorithmes, quand on déploie sur un matériel inattendu, ou quand il faut changer d’algorithme sur des données qui existent déjà. Ce chapitre rassemble ces décisions : choisir sans bricoler, comprendre pourquoi les combinaisons historiques déçoivent, tenir compte du matériel, et migrer sans perdre ni la sécurité ni les données.

Explication de la marmotte

Choisir une façon de chiffrer ressemble au choix d’une serrure pour une porte d’entrée : mieux vaut un modèle reconnu et éprouvé qu’un assemblage de trois cadenas bricolés, qui rassure sans mieux protéger. Et quand une serrure vieillit, il faut savoir la changer sans laisser la maison ouverte pendant les travaux.

→ Lire l’explication complète de la marmotte

Décider sans bricoler

Préférer une recette standard

Pour chiffrer des données avec une clé partagée, la recommandation actuelle tient en deux noms, tous deux des constructions AEAD (Authenticated Encryption with Associated Data) : AES-GCM, c’est-à-dire l’AES (Advanced Encryption Standard) en mode GCM (Galois/Counter Mode), et ChaCha20-Poly1305, normalisé par le RFC 8439. Toutes deux chiffrent, authentifient, acceptent des données associées et refusent tout chiffré altéré. Le choix entre elles dépend de la plateforme, pas de la sécurité, qui est du même ordre pour un usage correct. Pour une clé de 256 bits, AES-256-GCM ; pour les cas où la gestion des nonces est difficile, une variante résistante à leur réutilisation comme AES-GCM-SIV (RFC 8452) ou un nonce long comme XChaCha20-Poly1305.

Une recette standard ne se limite pas à l’algorithme : elle inclut la longueur de clé, la taille du nonce, la façon de le produire, la limite de volume par clé, et le format de sortie. C’est ce que fournissent les bibliothèques de haut niveau, présentées dans Formats, bibliothèques et API, et ce qu’on perd en assemblant soi-même des primitives.

Éviter les options exotiques et vérifier l’usage recommandé

Une bibliothèque qui expose quarante algorithmes ne les recommande pas tous ; elle les conserve pour l’interopérabilité. Camellia, ARIA ou SM4 sont des chiffrements par blocs sérieux, normalisés dans leur pays d’origine, mais les choisir sans contrainte réglementaire précise réduit l’interopérabilité et la qualité des implémentations disponibles, sans gain de sécurité. Les référentiels nationaux, comme le guide de sélection des mécanismes cryptographiques de l’ANSSI (Agence nationale de la sécurité des systèmes d’information) ou les publications du NIST (National Institute of Standards and Technology), indiquent l’usage recommandé : une contrainte de conformité, une homologation ou une certification de module selon FIPS 140-3 peut imposer une liste fermée. Il faut alors vérifier cette liste auprès du référentiel applicable, et non d’après une mémoire collective souvent périmée. Pour un système de l’administration espagnole, ce référentiel s’appelle CCN-STIC 807, et le CCN-CERT en tient la liste avec une rigueur que l’on aimerait voir à la mémoire collective.

Ne pas confondre performance et sécurité

Un algorithme plus rapide n’est pas moins sûr, un plus lent n’est pas plus sûr. ChaCha20 n’est pas « plus léger donc plus faible » qu’AES ; AES-256 n’est pas « deux fois plus sûr » qu’AES-128 pour un usage courant, les deux étant hors de portée de toute recherche exhaustive classique. La marge de sécurité se mesure en rondes non attaquées et en hypothèses de cryptanalyse, comme l’explique Évaluer la force d’une protection ; la performance se mesure sur la machine cible.

Combinaisons historiques

Double et triple chiffrement, meet-in-the-middle

Quand la clé de 56 bits du DES (Data Encryption Standard) est devenue insuffisante, l’idée naturelle a été de chiffrer deux fois avec deux clés indépendantes. L’attaque par rencontre au milieu (meet-in-the-middle), décrite par Diffie et Hellman en 1977, ruine ce calcul. Avec une paire clair-chiffré connue, l’attaquant chiffre le clair sous les 2⁵⁶ clés possibles et stocke les résultats, puis déchiffre le chiffré sous les 2⁵⁶ clés et cherche une correspondance dans la table. Coût : environ 2⁵⁷ opérations et 2⁵⁶ blocs de mémoire, au lieu des 2¹¹² espérés. Le double DES ne gagne qu’un bit.

Le 3DES contourne l’attaque en chaînant trois opérations. Avec trois clés indépendantes, la clé nominale de 168 bits offre environ 112 bits de sécurité, la rencontre au milieu s’appliquant à deux étages sur trois. Avec deux clés (K1, K2, K1), le NIST ne lui accorde plus qu’environ 80 bits face aux attaques à clairs connus. À cela s’ajoute le bloc de 64 bits, exposé aux collisions décrites dans Chiffrer par blocs. Le triple chiffrement a été une rustine honorable ; ce n’est pas un modèle.

Cascades

Une cascade enchaîne deux algorithmes différents avec des clés indépendantes, par exemple AES puis Serpent, comme le proposent certains logiciels de chiffrement de volumes. L’intuition dit qu’il faudrait casser les deux. Le résultat établi est plus modeste : Maurer et Massey ont montré en 1993 qu’une cascade est au moins aussi sûre que son premier étage, sans garantie générale au-delà. La cascade double le coût, complique l’implémentation, multiplie les surfaces de canaux auxiliaires, et protège surtout contre un scénario, l’effondrement soudain d’AES, que trente ans de cryptanalyse rendent improbable. Si la crainte porte sur l’implémentation ou la gestion des clés, ce qui est statistiquement bien plus raisonnable, la cascade ne change rien, puisque les deux clés vivent généralement au même endroit.

Whitening, doublement de bloc, troncature héritée

Le blanchiment de clé (key whitening) XORe une clé supplémentaire avant et après le chiffrement. DESX, proposé par Ron Rivest, l’applique à DES et augmente nettement le coût de la recherche exhaustive, sans rien changer à la taille de bloc ni aux attaques structurelles. AES intègre ce principe nativement, puisque sa première et sa dernière opération ajoutent une sous-clé.

Le doublement de bloc cherche à fabriquer un chiffrement de 128 bits à partir d’un chiffrement de 64 bits, en combinant deux appels par une structure de type Feistel. La démarche avait un sens avant AES ; elle n’en a plus depuis qu’un bloc de 128 bits natif est disponible partout.

La troncature de clé a eu des motifs politiques plutôt que techniques. Le CDMF (Commercial Data Masking Facility) d’IBM réduisait DES à une clé effective de 40 bits pour se conformer aux restrictions d’exportation des années 1990. Ces variantes survivent parfois dans de vieux formats d’archives ou d’équipements ; elles se rangent dans l’inventaire avec la mention « à retirer », jamais dans une liste de choix.

Matériel, logiciel et environnement

Accélération CPU et implémentations en temps constant

Sur x86 et sur les processeurs ARM récents, les instructions dédiées à AES et à la multiplication sans retenue (utilisée par GCM) rendent AES-GCM très rapide et naturellement résistant aux attaques temporelles. Sans ces instructions, AES logiciel est lent s’il est écrit en temps constant, et vulnérable aux attaques par cache s’il utilise des tables. ChaCha20, composé uniquement d’additions, de rotations et de XOR, est rapide et constant en temps sur n’importe quel processeur. C’est la raison principale pour laquelle les navigateurs et les serveurs TLS (Transport Layer Security) négocient ChaCha20-Poly1305 avec les clients mobiles dépourvus d’accélération AES. Le détail des fuites par le temps et le cache figure dans Quand l’implémentation parle.

Embarqué, empreinte mémoire et environnements contraints

Un microcontrôleur de quelques kilooctets de mémoire vive, alimenté par pile, n’a ni AES-NI ni marge pour une bibliothèque complète. La cryptographie légère vise ce terrain : primitives compactes, faible consommation, petite surface de code. Le NIST a sélectionné en 2023 la famille Ascon à l’issue de son concours sur la cryptographie légère, puis l’a normalisée en 2025 dans la publication SP 800-232. Ascon fournit un AEAD et une fonction de hachage autour d’une même permutation de 320 bits. Sur ces cibles, il peut constituer un meilleur compromis qu’AES, sauf si le composant intègre un coprocesseur AES, ce qui est fréquent sur les microcontrôleurs récents.

Cloud et portabilité

Dans le cloud, l’algorithme est souvent imposé par le service de gestion de clés du fournisseur, en pratique AES-256-GCM. La portabilité devient alors une question de format : un chiffré produit par un service doit pouvoir être relu ailleurs, ce qui suppose un format documenté et une clé exportable ou un chiffrement d’enveloppe maîtrisé, sujets traités dans Exploiter les clés.

Compression, codage et chiffrement

L’ordre des traitements compte. On compresse avant de chiffrer, puisqu’un chiffré correct est incompressible ; on code (Base64, hexadécimal) après, pour le transport. Mais compresser des données qui mêlent un secret et un contenu contrôlé par l’attaquant fait fuir le secret par la longueur du chiffré : les attaques CRIME (2012) et BREACH (2013) ont exploité ce mécanisme contre la compression dans TLS et dans HTTP. Le chiffrement cache le contenu, pas la taille.

Migration symétrique

Inventaire et versionnement

Une migration commence par savoir ce qui existe : quels algorithmes, dans quels protocoles, quels formats, quelles bases, quelles sauvegardes. L’inventaire recense ; l’audit, lui, juge la conformité de ce qui a été recensé. Ensuite, chaque donnée chiffrée doit porter un identifiant de version ou d’algorithme dans un en-tête authentifié. Sans cette étiquette, un déchiffreur ne sait pas quoi appliquer, et la migration se transforme en archéologie.

Double lecture, rechiffrement, suppression des fallback

La phase de transition lit les deux formats et n’écrit que le nouveau. Le rechiffrement des données existantes se fait par lots, avec vérification de chaque lot et mesure de la proportion restante. Le chiffrement d’enveloppe allège beaucoup ce travail : si les données sont chiffrées par des clés de données elles-mêmes protégées par une clé maîtresse, changer l’algorithme de la clé maîtresse ne demande de rechiffrer que les petites clés emballées ; changer l’algorithme des données exige en revanche de tout rechiffrer. La dernière étape, souvent oubliée, supprime le chemin de lecture ancien. Tant qu’un fallback existe, c’est-à-dire un repli automatique sur l’ancien algorithme quand le nouveau échoue, un attaquant capable de provoquer l’échec choisit l’algorithme à la place du défenseur.

Exemples et ateliers

Une règle de choix selon la plateforme

La règle tient en quatre questions parce qu’elle est volontairement fermée. Toute exception passe par une revue documentée.

Évaluer une cascade proposée

Une équipe propose « AES-256-CBC puis Blowfish-CBC, pour plus de sécurité ». L’évaluation relève quatre problèmes : aucune authentification, donc altération indétectable ; un étage à bloc de 64 bits qui introduit des limites de volume ; des clés probablement stockées ensemble, donc compromises ensemble ; et un coût de calcul doublé. La réponse remplace l’ensemble par AES-256-GCM avec une clé gérée par le service de clés, ce qui améliore simultanément l’intégrité, la simplicité et le débit.

Un format versionné pour la migration

Placer l’en-tête dans les données associées empêche un attaquant de réétiqueter un chiffré de version 2 en version 1 pour forcer l’ancien traitement.

Matrice AES, ChaCha20, Ascon

Critère	AES-GCM	ChaCha20-Poly1305	Ascon-AEAD128
CPU avec AES matériel	très rapide	rapide	correct
CPU sans AES matériel	lent ou fuite temporelle	rapide, temps constant	rapide
Mémoire et taille de code	moyennes	moyennes	faibles
Conformité FIPS	largement validé	non approuvé par le NIST	récent (SP 800-232)
Réutilisation de nonce	catastrophique	catastrophique	catastrophique

La dernière ligne est là pour rappeler qu’aucun choix d’algorithme ne dispense de la discipline sur les nonces.

Pièges classiques

Composer deux algorithmes pour se rassurer, sans preuve de sécurité de l’ensemble, ajoute du code et des clés sans ajouter de garantie. Maintenir un repli vers un algorithme faible annule la migration, puisque l’attaquant peut provoquer le repli. Ignorer l’accélération matérielle conduit soit à des performances désastreuses, soit à des implémentations logicielles qui fuient par le temps. Une migration en une seule fois, sans double lecture ni test, transforme le changement d’algorithme en perte de données, ce qui est une forme de confidentialité, mais pas celle que l’on cherchait.

À ne pas confondre

Le surchiffrement empile des couches de confidentialité ; un AEAD fournit confidentialité et intégrité en une construction prouvée, et la première approche ne remplace pas la seconde. La performance dit combien de données passent par seconde, la marge de sécurité dit combien d’effort sépare l’attaquant du succès. La compatibilité accepte de parler plusieurs langues ; la rétrocompatibilité dangereuse accepte de les parler sur demande de n’importe qui, y compris de l’attaquant. L’inventaire, enfin, constate ce qui existe ; l’audit dit si c’est acceptable, et l’un sans l’autre laisse une décision à moitié prise.

🐝 Ce qui arrive si on s’en passe

Sans décision explicite ni format versionné, chaque équipe chiffre à sa manière et personne ne sait plus quelle donnée a été protégée avec quelle méthode. Le jour où une méthode est dépréciée, il devient impossible de dresser la liste de ce qu’il faut rechiffrer : les données anciennes restent sous la protection affaiblie, sans limite de durée, dans des sauvegardes et des archives que plus personne ne relit. La cascade ajoutée « pour se rassurer » coûte du calcul sans apporter de preuve, et la migration improvisée transforme un changement d’algorithme en perte de données, ce qui règle certes la question de la confidentialité, mais pas dans le sens espéré.

🦫 Explication de la marmotte 🍫

Le chiffrement symétrique utilise une seule clé secrète, qui sert à la fois à verrouiller et à déverrouiller les données. La première décision consiste à choisir la méthode : on part d’une recette standard, recommandée pour l’usage visé, plutôt que d’une option exotique. Une méthode rapide n’est pas forcément plus sûre ; la vitesse dépend du matériel. Certains processeurs possèdent des circuits dédiés qui accélèrent une méthode précise, alors qu’un petit appareil embarqué, avec peu de mémoire, tirera parti d’une méthode dite légère. Le calcul doit aussi prendre toujours le même temps, quelle que soit la clé, sinon la mesure de ce temps renseigne un observateur sur le secret.

Enchaîner deux chiffrements semble doubler la protection, mais une attaque dite « de la rencontre au milieu » traite les deux étapes séparément et rend le gain bien plus faible que prévu. Les combinaisons historiques, comme le triple chiffrement ou la troncature de clé, relèvent donc de l’étude, pas de la recommandation.

Changer de méthode suit un ordre précis. On recense d’abord où chaque méthode est utilisée. Chaque donnée chiffrée porte une étiquette de version. Pendant la transition, le système sait lire l’ancien et le nouveau format, rechiffre progressivement les données, puis supprime l’option ancienne. Si cette option reste disponible, un attaquant peut forcer son emploi ; si l’on bascule tout d’un coup sans test, des données deviennent illisibles.

À lire aussi

• Chiffrer et authentifier en une seule constructionFaire de l’AEAD le modèle par défaut, choisir une primitive adaptée et maîtriser nonces, données associées, tags, rotation et limites de volume.
• Chiffrement par flot : état, compteurs et réutilisation interditePrésenter les chiffrements par flot et les générateurs de suites comme une famille utile mais très sensible à la réutilisation de flux, d’état et de nonce.
• Transformer un bloc en chiffrement de messageExpliquer les modes opératoires, leurs fuites et leurs exigences de paramètres, puis orienter vers les modes authentifiés pour les usages modernes.
• Tester, auditer, répondre et migrerDonner une méthode de contrôle continu: tests, vecteurs, fuzzing, audit de conception, inventaire, incident, rotation et migration sans rupture.

Pages voisines

La citent

• Chiffrement par flot : état, compteurs et réutilisation interdite
• Préparer la migration post-quantique
• Tester, auditer, répondre et migrer

Choisir, combiner et migrer les algorithmes symétriques

Elle cite

• ⇄Lien dans les deux sens :Chiffrer par blocs : de l’héritage DES à AES
• ⇄Lien dans les deux sens :Comprendre la cryptanalyse sans perdre le fil pratique
• Évaluer la force d’une protection
• Exploiter les clés : rotation, KMS et secrets
• Frontières : cacher, coder, compresser et détruire
• Quand l’implémentation parle : temps, cache, fautes et oracles
• CCN-CERT Espagne : rôle, guides CCN-STIC et ENS
• Formats, bibliothèques et API : rendre la crypto utilisable

⇄ : les deux pages se citent l’une l’autre.