Comment choisir un mode de

cryptage AES
(CBC ECB CTR OCB CFB)?
Lesquels d’entre eux sont préférés dans quelles circonstances?

J'aimerais voir la liste des critères d'évaluation pour les différents modes, et peut-
être une discussion sur l'applicabilité de chaque critère.
Par exemple, je pense que l’un des critères est la "taille du code" pour le
chiffrement et le déchiffrement, ce qui est important pour les systèmes embarqués
à microcode, tels que les cartes réseau 802.11. SI le code requis pour implémenter
CBC est beaucoup plus petit que celui requis pour le CTR (je ne sais pas si c'est vrai,
ce n'est qu'un exemple), alors je pourrais comprendre pourquoi le mode avec le
code plus petit serait préféré. Mais si j'écris une application qui s'exécute sur un
serveur et que la bibliothèque AES que j'utilise implémente de toute façon CBC et
CTR, alors ce critère n'est pas pertinent.
Voyez ce que je veux dire par "liste de critères d'évaluation et applicabilité de
chaque critère" ??
Ce n'est pas vraiment lié à la programmation mais à l'algorithme.
• ECB ne doit pas être utilisé lors du cryptage de plusieurs blocs de données
avec la même clé.
• CBC, OFB et CFB sont similaires, mais OFB/CFB est préférable, car vous avez
uniquement besoin d’un chiffrement et non d’un déchiffrement, ce qui peut
économiser de l’espace.
• Le CTR est utilisé si vous voulez une bonne parallélisation (vitesse) au lieu de
CBC/OFB/CFB.
• Le mode XTS est le plus courant si vous codez des données accessibles de
manière aléatoire (comme un disque dur ou une RAM).
• OCB est de loin le meilleur mode, car il permet le cryptage et
l’authentification en un seul passage. Cependant, il existe des brevets aux
États-Unis.
La seule chose que vous devez vraiment savoir, c'est que la BCE ne doit pas
être utilisée à moins que vous ne chiffriez qu'un seul bloc. XTS doit être
utilisé si vous chiffrez des données consultées de manière aléatoire et non
un flux.
• Vous devez TOUJOURS utiliser des valeurs uniques IV à chaque fois que
vous chiffrez, et elles devraient être aléatoires . Si vous ne pouvez pas
garantir qu'ils sont aléatoires , utilisez OCB car il ne nécessite qu'un 
nonce , pas un IV , et il existe une différence nette. . Un nonce ne
supprime pas la sécurité si les gens peuvent deviner le prochain, un IV
 peut causer ce problème.
Permettez-moi d'illustrer mon propos: imaginez que vous construisez une
application Web et que vous deviez stocker des données de session. Vous pouvez
attribuer à chaque utilisateur un ID de session et stocker les données de session sur
le serveur dans un ID de session de mappage de table de hachage avec les données
de session. Mais alors vous devez faire face à cet état embêtant sur le serveur et si
à un moment donné vous avez besoin de plus d’un serveur, les choses vont devenir
compliquées. Vous avez donc l’idée de stocker les données de session dans un
cookie côté client. Vous le chiffrerez bien sûr afin que l'utilisateur ne puisse pas lire
et manipuler les données. Alors, quel mode devriez-vous utiliser? En venant ici,
vous lisez la réponse en haut (désolé de vous avoir choisi myforwik). Le premier
sujet couvert - la BCE - n’est pas fait pour vous, vous voulez chiffrer plus d’un bloc,
le suivant - le CBC - semble bien et vous n’avez pas besoin du parallélisme du CTR,
vous n’avez pas besoin d’un accès aléatoire; XTS et les brevets sont un PITA, donc
pas d'OCB. En utilisant votre bibliothèque de chiffrement, vous vous rendez compte
que vous avez besoin d'un certain rembourrage, car vous ne pouvez chiffrer que
des multiples de la taille du bloc. Vous choisissez PKCS7 car il a été défini dans
certaines normes de cryptographie sérieuses. Après avoir lu quelque part que CBC
est prouvé que c'est sûr s'il est utilisé avec un IV aléatoire et un chiffrement de bloc
sécurisé, vous vous sentez à l'aise même si vous stockez vos données sensibles côté
client.
Que faire si vous avez besoin de chiffrer des données
Pour les connexions actives, utilisez TLS (assurez-vous de vérifier le nom d'hôte du
certificat et la chaîne de l'émetteur). Si vous ne pouvez pas utiliser TLS,
recherchez l'API de plus haut niveau que votre système peut offrir pour votre
tâche et assurez-vous de bien comprendre les garanties qu'il offre et surtout ce
qu'il ne garantit pas. Pour l'exemple ci-dessus, un cadre tel que Play offre 
installations de stockage côté client , les données stockées ne seront pas
invalidées après un certain temps, cependant, et si vous modifiez l’état côté
client, un attaquant peut restaurer un état antérieur sans que vous ne le
remarquiez.
S'il n'y a pas d'abstraction de haut niveau disponible, utilisez une bibliothèque de
chiffrement de haut niveau. NaCl est un exemple frappant et une implémentation
portable comportant de nombreuses liaisons de langage est Sodium . En utilisant
une telle bibliothèque, vous n'avez pas à vous soucier des modes de cryptage,
etc., mais vous devez faire encore plus attention aux détails d'utilisation qu'avec
une abstraction de niveau supérieur, comme si vous n'utilisiez jamais deux fois un
nonce.
Si, pour une raison quelconque, vous ne pouvez pas utiliser une bibliothèque de
chiffrement de haut niveau, par exemple parce que vous devez interagir avec le
système existant de manière spécifique, vous ne pouvez absolument pas vous
renseigner de manière approfondie. Je recommande la lecture 
Ingénierie de cryptographie par Ferguson, Kohno et Schneier . S'il vous plaît ne
vous trompez pas en croyant que vous pouvez construire un système sécurisé
sans les antécédents nécessaires. La cryptographie est extrêmement subtile et il
est presque impossible de tester la sécurité d'un système.
Comparaison des modes
Cryptage uniquement:
Modes nécessitant un remplissage: comme dans l'exemple, le remplissage
peut généralement être dangereux car il ouvre la possibilité d'attaquer les
attaques Oracle. La défense la plus simple consiste à authentifier chaque
message avant le déchiffrement. Voir ci-dessous.
• ECB chiffre chaque bloc de données indépendamment et le même
bloc de texte en clair donnera le même bloc de texte chiffré. Jetez un
coup d’œil à l’image Tux chiffrée de la BCE sur page ECB Wikipedia
 pour comprendre pourquoi il s’agit d’un problème grave. Je ne
connais pas de cas d'utilisation où la BCE serait acceptable.
• CBC a un IV et a donc besoin d’être aléatoire à chaque fois qu’un
message est chiffré, modifier une partie du message nécessite de
tout rechiffrer après le changement, les erreurs de transmission dans
un bloc de texte crypté détruisent complètement le texte en clair et
change le déchiffrement du bloc suivant, le déchiffrement peut être
parallélisé/le chiffrement ne peut pas, le texte en clair est malléable
dans une certaine mesure - cela peut être un problème .
Modes de chiffrement par flux: Ces modes génèrent un flux de données
pseudo-aléatoire qui peut ou non dépendre du texte en clair. De manière
similaire aux flux de chiffrement généralement, le flux pseudo-aléatoire généré
est traité par XOR avec le texte en clair pour générer le texte chiffré. Comme
vous pouvez utiliser autant de bits du flux aléatoire que vous le souhaitez, vous
n'avez pas besoin de bourrage du tout. L’inconvénient de cette simplicité est
que le chiffrement est complètement malléable , ce qui signifie que le
déchiffrement peut être modifié par un attaquant à sa guise, comme pour un
texte en clair p1, un texte chiffré c1 et un flux pseudo aléatoire r et l'attaquant
peut choisir une différence d telle que le déchiffrement d'un texte chiffré c2 =
c1⊕d soit p2 = p1⊕d, comme p2 = c2⊕r = (c1 d) r = d ⊕ (c1 r). De même, le
même flux pseudo-aléatoire ne doit jamais être utilisé deux fois, car pour deux
caractères chiffrés c1 = p1⊕r et c2 = p2⊕r, un attaquant peut calculer le xor
des deux textes en clair comme suit: c1⊕c2 = p1⊕rp2⊕r = p1⊕p2. Cela
signifie également que la modification du message nécessite un nouveau
cryptage complet, si le message d'origine a pu être obtenu par un attaquant.
Tous les modes de chiffrement Steam suivants ne nécessitent que l'opération
de chiffrement du chiffrement par bloc. Par conséquent, cela peut économiser
de l'espace (code machine ou code machine) dans des environnements
extrêmement restreints.
• CTR est simple, il crée un flux pseudo aléatoire indépendant du texte en clair.
Différents flux pseudo aléatoires sont obtenus en comptant à partir de
différents nonces/IV qui sont multipliés par une longueur de message
maximale de sorte que le chevauchement est évité, l'utilisation du
chiffrement des messages nonces est possible sans l'aléa par message, le
déchiffrement et le chiffrement sont terminés, les erreurs de transmission ne
concernent que les bits erronés et rien de plus
• OFB crée également un flux pseudo aléatoire indépendant du texte en clair.
Différents flux pseudo aléatoires sont obtenus en commençant par un nonce
ou un IV aléatoire différent pour chaque message. Aucun chiffrement ni
déchiffrement n'est parallélisable, comme avec CTR. utiliser le cryptage des
messages nonces est possible sans caractère aléatoire par message, car avec
le CTR, les erreurs de transmission affectent uniquement les bits erronés et
rien de plus
• Le flux pseudo-aléatoire de CFB == dépend du texte en clair, un nonce ou un
IV aléatoire différent est nécessaire pour chaque message, comme avec CTR
et OFB utilisant le cryptage de message nonces possible sans qu'il soit
nécessaire de décoder, ne peut pas être parallélisé/chiffré, les erreurs de
transmission détruisent complètement le bloc suivant, mais n'affectent que
les bits erronés du bloc actuel
Modes de cryptage de disque: Ces modes sont spécialisés dans le cryptage
des données sous l'abstraction du système de fichiers. Pour des raisons
d'efficacité, la modification de certaines données sur le disque ne nécessite
que la réécriture d'au plus un bloc de disque (512 octets ou 4 kib). Ils sont
hors du champ de cette réponse car ils ont des scénarios d'utilisation très
différents des autres. 
Ne les utilisez pas pour autre chose que le chiffrement de disque au niveau
du bloc
 . Quelques membres: XEX, XTS, LRW.
Cryptage authentifié:
Pour empêcher les attaques Oracle et les modifications apportées au texte
chiffré, il est possible de calculer un code d'authentification de message
 (MAC) sur le texte chiffré et de le déchiffrer uniquement s'il n'a pas été
falsifié. Ceci s'appelle encrypt-then-mac and 
devrait être préféré à tout autre ordre . À l'exception de très peu de cas
d'utilisation, l'authenticité est aussi importante que la confidentialité (cette
dernière étant le but du cryptage). Les schémas de chiffrement authentifié
(avec données associées (AEAD)) combinent le processus en deux parties du
chiffrement et de l'authentification en un mode de chiffrement par bloc qui
produit également une étiquette d'authentification au cours du processus.
Dans la plupart des cas, cela se traduit par une amélioration de la vitesse.
• CCM est une combinaison simple des modes CTR et CBC-MAC.
L'utilisation de deux chiffrements de bloc par bloc est très lente.
• OCB est plus rapide mais encombré de brevets. Pour les logiciels libres
(comme dans les libertés) ou non militaires, le titulaire du brevet 
a accordé une licence libre , cependant.
• GCM est une combinaison très rapide mais sans doute complexe du
mode CTR et de GHASH, un MAC sur le champ de Galois comportant 2
^ 128 éléments. Son utilisation étendue dans des normes de réseau
importantes telles que TLS 1.2 est reflétée par une instruction spéciale
 que Intel a introduite pour accélérer le calcul de GHASH.
Recommandation:
Compte tenu de l'importance de l'authentification, je recommanderais
les deux modes de chiffrement par blocs suivants dans la plupart des cas
d'utilisation (à l'exception du chiffrement de disque): Si les données sont
authentifiées par une signature asymétrique, utilisez CBC, sinon utilisez
GCM.
Une analyse formelle a été réalisée par Phil Rogaway en 2011, ici . La section
1.6 donne un résumé que je transcris ici, en ajoutant ma propre accentuation
en gras (si vous êtes impatient, sa recommandation est d'utiliser le mode CTR,
mais je vous suggère de lire mes paragraphes sur l'intégrité du message par
rapport au cryptage ci-dessous).
Notez que la plupart d'entre eux exigent que le vecteur d'initialisation soit
aléatoire, ce qui signifie non prévisible et doit donc être généré avec une
sécurité cryptographique. Cependant, certains nécessitent uniquement un
"nonce", qui n'exige pas cette propriété mais exige seulement qu'elle ne soit
pas réutilisée. Par conséquent, les conceptions qui reposent sur un nonce sont
moins sujettes aux erreurs que celles qui ne le font pas (et croyez-moi, j'ai vu
de nombreux cas où CBC n'est pas implémentée avec une sélection IV
appropriée). Ainsi, vous verrez que j'ai ajouté des mots en gras lorsque
Rogaway dit quelque chose comme "La confidentialité n'est pas atteinte
lorsque l'IV est un nonce", cela signifie que si vous choisissez votre IV de
manière cryptographique sécurisée (imprévisible), aucun problème. Mais si
vous ne le faites pas, vous perdez les bonnes propriétés de sécurité. Ne
réutilisez jamais un IV pour aucun de ces modes.
En outre, il est important de comprendre la différence entre l’intégrité du
message et le cryptage. Le chiffrement masque les données, mais un attaquant
peut peut-être modifier les données chiffrées. Les résultats peuvent
éventuellement être acceptés par votre logiciel si vous ne vérifiez pas l'intégrité
du message. Alors que le développeur dira "mais les données modifiées
reviendront comme des ordures après le déchiffrement", un bon ingénieur en
sécurité trouvera la probabilité que ces ordures causent un comportement
indésirable dans le logiciel, puis il transformera cette analyse en une véritable
attaque. J'ai vu de nombreux cas d'utilisation du cryptage, mais l'intégrité du
message était vraiment plus nécessaire que le cryptage. Comprenez ce dont vous
avez besoin.
Je devrais dire que bien que GCM ait à la fois un cryptage et une intégrité de
message, sa conception est très fragile: si vous réutilisez un IV, vous êtes foutu -
l’attaquant peut récupérer votre clé. Les autres conceptions étant moins fragiles,
j'ai personnellement peur de recommander GCM en fonction de la quantité de
code de cryptage médiocre que j'ai constaté dans la pratique.
Si vous avez besoin des deux, intégrité des messages et cryptage, vous pouvez
combiner deux algorithmes: généralement nous voyons CBC avec HMAC, mais
aucune raison de vous lier à CBC. La chose importante à savoir est 
chiffrez d'abord, puis MAC le contenu chiffré , et non l'inverse. De plus, l'IV doit
faire partie du calcul du MAC.
Passons maintenant aux bonnes choses du professeur Rogaway:
Bloquer les modes de chiffrement, le cryptage mais pas l'intégrité du message
ECB: un chiffrement par bloc, le mode chiffre les messages qui sont un multiple
de n bits en chiffrant séparément chaque élément de n bits. Les propriétés de
sécurité sont faibles , la méthode fuyant l’égalité des blocs entre les positions et
l’heure du bloc. Valeur patrimoniale considérable et valeur essentielle pour
d’autres systèmes, mais ce mode n’atteint pas en soi un objectif de sécurité
généralement souhaitable et doit être utilisé avec beaucoup de prudence; La
BCE ne doit pas être considérée comme un mode de confidentialité
"polyvalent" .
CBC: schéma de cryptage basé sur IV, le mode est sécurisé en tant que schéma
de cryptage probabiliste, permettant d'obtenir une distinction entre les bits
aléatoires, en supposant un IV aléatoire. La confidentialité n'est pas atteinte si
le vecteur d'initialisation est simplement un nonce , ni s'il s'agit d'un nonce
chiffré sous la même clé que celle utilisée par le schéma, comme le suggère la
norme à tort. Les textes chiffrés sont très malléables. Aucune sécurité d'attaque
de cryptogramme choisi (CCA). La confidentialité est perdue en présence d'un
Oracle de remplissage correct pour de nombreuses méthodes de remplissage.
Cryptage inefficace d'être intrinsèquement série. Largement utilisées, les
propriétés de sécurité du mode exclusivement liées à la confidentialité du mode
résultent en de fréquents abus Peut être utilisé comme bloc de construction
pour les algorithmes CBC-MAC. Je ne peux identifier aucun avantage important
par rapport au mode CTR.
CFB: schéma de chiffrement basé sur IV, le mode est sécurisé en tant que schéma
de chiffrement probabiliste, permettant d'obtenir une distinction entre les bits
aléatoires, en supposant un IV aléatoire. La confidentialité n'est pas atteinte si l'IV
est prévisible , ni par un nonce chiffré sous la même clé utilisée par le schéma,
comme le suggère la norme à tort. Les textes chiffrés sont malléables. Pas de CCA-
sécurité. Cryptage inefficace d'être intrinsèquement série. Le schéma dépend d’un
paramètre s, 1 ≤ s ≤ n, typiquement s = 1 ou s = 8. Inutile d’avoir besoin d’un seul
appel de type chiffré-bloc pour traiter uniquement s bits. Le mode atteint une
propriété intéressante d’auto-synchronisation; l'insertion ou la suppression d'un
nombre quelconque de caractères sur le cryptogramme ne perturbe que
temporairement le déchiffrement correct.
OFB: schéma de cryptage basé sur IV, le mode est sécurisé comme schéma de
cryptage probabiliste, permettant d'obtenir une distinction entre les bits
aléatoires, en supposant un IV aléatoire. La confidentialité n'est pas atteinte si le
IV est un nonce, bien qu'une séquence fixe de IV (par exemple, un compteur)
fonctionne correctement. Les textes chiffrés sont très malléables. Aucune sécurité
de la CCA. Le chiffrement et le déchiffrement ne sont pas efficaces, car ils sont
intrinsèquement série. Crypte en mode natif des chaînes de n'importe quelle
longueur en bits (aucun remplissage requis). Je ne peux identifier aucun avantage
important par rapport au mode CTR.
CTR: schéma de chiffrement basé sur IV, le mode est indiscernable des bits
aléatoires en supposant une nonce IV. En tant que schéma sécurisé basé sur
nonce, le mode peut également être utilisé en tant que schéma de chiffrement
probabiliste, avec un IV aléatoire. Échec total de la confidentialité si un nonce
est réutilisé pour le chiffrement ou le déchiffrement. La parallélisabilité du
mode le rend souvent plus rapide, dans certains paramètres, beaucoup plus
rapide que d'autres modes de confidentialité. Un bloc de construction
important pour les schémas de chiffrement authentifié. Dans l’ensemble, c’est
généralement le moyen le plus moderne et le plus performant d’atteindre le
cryptage avec confidentialité uniquement.
XTS: schéma de chiffrement basé sur IV, le mode fonctionne en appliquant un
blockcipher ajustable (sécurisé en tant que PRP fort) à chaque bloc de n bits.
Pour les messages dont la longueur n'est pas divisible par n, les deux derniers
blocs font l'objet d'un traitement particulier. Ce mode est uniquement autorisé
à chiffrer des données sur un périphérique de stockage structuré en blocs. La
faible largeur du PRP sous-jacent et le traitement médiocre des blocs finaux
fractionnaires posent problème. Plus efficace, mais moins souhaitable que ne le
serait un blockcipher sécurisé par PRP (à bloc large).
MACs (intégrité du message mais pas
cryptage)
ALG1–6 : ensemble de codes MAC, tous basés sur le code CBC-MAC. Trop de
régimes. Certains sont sécurisés de manière fiable en tant que PRF VIL, d'autres en
tant que PRF FIL, et d'autres n'ont aucune sécurité prouvable. Certains des
régimes admettent des attaques dommageables. Certains modes sont datés. La
séparation des clés est mal traitée pour les modes qui en sont dotés. Ne devrait
pas être adopté en masse, mais il est possible de choisir sélectivement les
"meilleurs" régimes. Il serait également bon de n’adopter aucun de ces modes en
faveur de CMAC. Certaines des MAC ISO 9797-1 sont largement normalisées et
utilisées, en particulier dans le secteur bancaire. Une version révisée de la norme
(ISO/IEC FDIS 9797-1: 2010) sera bientôt publiée [93].
CMAC: MAC basé sur le CBC-MAC, le mode est manifestement sécurisé (jusqu'à la
date de naissance) en tant que PRF (VIL) (en supposant que le blockcipher sous-
jacent est un bon PRP). Frais généraux essentiellement minimaux pour un système
basé sur CBCMAC. La nature série inhérente pose un problème dans certains
domaines d’application et son utilisation avec un bloc de chiffrement par blocs de
64 bits nécessiterait une nouvelle saisie occasionnelle. Plus propre que la
collection de codes MAC ISO 9797-1.
HMAC: un MAC basé sur une fonction de hachage cryptographique plutôt que
sur un blockcipher (bien que la plupart des fonctions de hachage
cryptographiques soient elles-mêmes basées sur des chiffreurs de blocs). Le
mécanisme bénéficie de fortes limites de sécurité prouvables, bien que non
fondées sur des hypothèses préférées. Plusieurs variantes étroitement
apparentées dans la littérature compliquent l'acquisition d'une compréhension
de ce que l'on sait. Aucune attaque dommageable n'a jamais été suggérée.
Largement normalisé et utilisé.
GMAC: adresse MAC nonce constituant un cas particulier de GCM. Hérite de
nombreuses bonnes et mauvaises caractéristiques de GCM. Mais la non-
exigence n'est pas nécessaire pour un MAC, et ici, cela n'apporte que peu
d'avantages. Attaques pratiques si les étiquettes sont tronquées à ≤ 64 bits et
que l'étendue du déchiffrement n'est pas surveillée ni réduite. Échec complet de
non-réutilisation. L'utilisation est de toute façon implicite si GCM est adopté.
Non recommandé pour la normalisation séparée.
cryptage authentifié (cryptage et intégrité du message)
CCM: schéma AEAD basé sur nonce qui combine le cryptage en mode CTR et le
CBC-MAC brut. En série, limite la vitesse dans certains contextes. Sûrement
sécurisé, avec de bonnes limites, en supposant que le blockcipher sous-jacent
est un bon PRP. Inconvénient de la construction qui fait manifestement le
travail. Plus simple à mettre en œuvre que GCM. Peut être utilisé en tant que
MAC basé sur nonce. Largement normalisé et utilisé.
GCM: schéma AEAD basé sur nonce qui combine le cryptage en mode CTR et
une fonction de hachage universelle basée sur GF (2128). Bonnes
caractéristiques d'efficacité pour certains environnements de mise en œuvre.
De bons résultats sécurisés en supposant une troncature minimale des balises.
Attaques et limites de sécurité prouvables médiocres en présence d'une
troncature importante des étiquettes. Peut être utilisé en tant que MAC nonce,
appelé ensuite GMAC. Choix discutable d'autoriser des ressources autres que
96 bits. Il est recommandé de limiter les informations à 96 bits et les étiquettes
à au moins 96 bits. Largement normalisé et utilisé.
Tout sauf la BCE.
Si vous utilisez le CTR, vous devez impérativement utiliser un vecteur
d’information différent pour chaque message. Sinon, l’attaquant sera en mesure
de prendre deux textes cryptés et d’en déduire un texte en clair non chiffré. La
raison en est que le mode CTR transforme essentiellement un chiffrement par
bloc en un chiffrement de flux, et la première règle des chiffrements de flux est
de ne jamais utiliser deux fois la même clé + IV.
Il n’ya vraiment pas beaucoup de différence dans la difficulté de mise en œuvre
des modes. Certains modes ne nécessitent que le chiffrement de bloc pour
fonctionner dans le sens du chiffrement. Cependant, la plupart des chiffreurs de
blocs, y compris AES, ne nécessitent pas beaucoup plus de code pour
implémenter le déchiffrement.
Pour tous les modes de chiffrement, il est important d'utiliser des IVs différents
pour chaque message si vos messages peuvent être identiques dans les premiers
octets et que vous ne voulez pas que l'attaquant sache le savoir.