Comment choisir un mode de cryptage AES (CBC ECB CTR OCB CFB) ?

Question

Lesquelles sont préférables 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 cryptage et le décryptage, ce qui est important pour les systèmes intégrés à micro-code, comme les adaptateurs réseau 802.11. SI le code requis pour implémenter CBC est beaucoup plus petit que celui requis pour CTR (je ne sais pas si c'est vrai, c'est juste un exemple), alors je pourrais comprendre pourquoi le mode avec le plus petit code serait préféré. Mais si j'écris une application qui tourne sur un serveur, et que la bibliothèque AES que j'utilise implémente de toute façon à la fois CBC et CTR, alors ce critère n'est pas pertinent.

Vous voyez ce que je veux dire par "liste des critères d'évaluation et applicabilité de chaque critère" ?

Ce n'est pas vraiment lié à la programmation mais à l'algorithme.

Answer 1

Réfléchissez longuement si vous ne pouvez pas implémenter votre propre cryptographie.

L'horrible vérité est que si vous vous posez cette question, vous ne serez probablement pas en mesure de concevoir et de mettre en œuvre un système sécurisé.

Permettez-moi d'illustrer mon propos : imaginez que vous construisiez une application web et que vous ayez besoin de stocker des données de session. Vous pourriez attribuer à chaque utilisateur un identifiant de session et stocker les données de session sur le serveur dans une carte de hachage reliant l'identifiant de session aux données de session. Mais vous devez alors gérer cet état sur le serveur et si, à un moment donné, vous avez besoin de plus d'un serveur, les choses vont se compliquer. L'idée est donc de stocker les données de session dans un cookie côté client. Vous le chiffrerez bien sûr pour que l'utilisateur ne puisse pas lire et manipuler les données. Alors, quel mode devez-vous utiliser ? En venant ici, vous avez lu la meilleure réponse (désolé de vous avoir distingué myforwik). Le premier mode couvert - ECB - n'est pas pour vous, vous voulez chiffrer plus d'un bloc, le suivant - CBC - semble bon et vous n'avez pas besoin du parallélisme de CTR, vous n'avez pas besoin d'accès aléatoire, donc pas de XTS et les brevets sont un PITA, donc pas d'OCB. En utilisant votre bibliothèque de cryptographie, vous vous rendez compte que vous avez besoin de rembourrage car vous ne pouvez chiffrer que des multiples de la taille du bloc. Vous choisissez PKCS7 parce qu'il a été défini dans des normes de cryptographie sérieuses. Après avoir lu quelque part que le CBC est Sûr et certain S'il est utilisé avec un IV aléatoire et un chiffrement par bloc sécurisé, vous êtes tranquille, même si vous stockez vos données sensibles du côté client.

Des années plus tard, alors que votre service a effectivement atteint une taille significative, une spécialiste de la sécurité informatique vous contacte dans le cadre d'une divulgation responsable. Elle vous dit qu'elle peut décrypter tous vos cookies à l'aide d'une attaque par oracle de rembourrage parce que votre code produit une page d'erreur si le rembourrage est en quelque sorte cassé.

Il ne s'agit pas d'un scénario hypothétique : Microsoft avait exactement cette faille dans ASP.NET jusqu'à il y a quelques années.

Le problème est qu'il existe de nombreux pièges en matière de cryptographie et qu'il est extrêmement facile de construire un système qui semble sûr pour le profane mais qui est facile à casser pour un attaquant averti.

Que faire si vous devez crypter des données ?

Pour les connexions en direct, utilisez TLS (veillez à 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 comprendre les garanties qu'elle offre et, surtout, ce qu'elle ne garantit pas. Dans l'exemple ci-dessus, un framework comme Jouer offre installations de stockage côté client Cependant, il n'invalide pas les données stockées après un certain temps et, si vous avez modifié l'état du côté client, un attaquant peut rétablir un état antérieur sans que vous vous en rendiez compte.

Si aucune abstraction de haut niveau n'est disponible, utilisez une bibliothèque cryptographique de haut niveau. Un exemple important est NaCl et une implémentation portable avec de nombreuses liaisons de langage est Sodium . En utilisant une telle bibliothèque, vous ne devez pas vous soucier des modes de cryptage, etc., mais vous devez être encore plus attentif aux détails d'utilisation qu'avec une abstraction de plus haut niveau, comme ne jamais utiliser un nonce deux fois. Pour la construction de protocoles personnalisés (disons que vous voulez quelque chose comme TLS, mais pas sur TCP ou UDP), il existe des frameworks comme Bruit et les implémentations associées qui font le gros du travail pour vous, mais leur flexibilité signifie également qu'il y a beaucoup de place pour l'erreur, si vous ne comprenez pas en profondeur ce que font tous les composants.

Si, pour une raison quelconque, vous ne pouvez pas utiliser une bibliothèque cryptographique de haut niveau, par exemple parce que vous devez interagir avec le système existant d'une manière spécifique, il n'y a pas d'autre moyen que de vous éduquer de manière approfondie. Je vous recommande de lire Ingénierie de la cryptographie par Ferguson, Kohno et Schneier . Ne vous faites pas d'illusions en croyant que vous pouvez construire un système sécurisé sans avoir les connaissances nécessaires. La cryptographie est extrêmement subtile et il est pratiquement impossible de tester la sécurité d'un système.

Comparaison des modes

Chiffrement uniquement :

• Modes qui nécessitent un rembourrage : Comme dans l'exemple, le padding peut généralement être dangereux car il ouvre la possibilité d'attaques par oracle de padding. La défense la plus simple consiste à authentifier chaque message avant de le décrypter. Voir ci-dessous.
  • BCE crypte chaque bloc de données indépendamment et le même bloc de texte en clair donnera lieu au même bloc de texte chiffré. Jetez un coup d'œil à l'image Tux chiffrée par ECB sur la page Page Wikipedia de la BCE pour voir pourquoi c'est un sérieux problème. Je ne connais aucun cas d'utilisation où la BCE serait acceptable.
  • CBC a un IV et a donc besoin d'un caractère aléatoire à chaque fois qu'un message est crypté, le changement d'une partie du message nécessite de tout re-crypter après le changement, les erreurs de transmission dans un bloc de texte crypté détruisent complètement le texte en clair et changent le décryptage du bloc suivant, le décryptage peut être parallélisé / le cryptage ne peut pas, le texte en clair est malléable jusqu'à un certain degré - 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 dépendre ou non du texte en clair. De la même manière que pour les chiffrages de flux, le flux pseudo-aléatoire généré est soumis à une opération 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 remplissage. L'inconvénient de cette simplicité est que le chiffrement est entièrement malléable En effet, pour un texte en clair p1, un texte chiffré c1 et un flux pseudo-aléatoire r, l'attaquant peut choisir une différence d telle que le déchiffrement d'un texte chiffré c2=c1⊕d soit p2 = p1⊕d, car p2 = c2⊕r = (c1 ⊕ d) ⊕ r = d ⊕ (c1 ⊕ r). De plus, le même flux pseudo-aléatoire ne doit jamais être utilisé deux fois car pour deux cryptogrammes c1=p1⊕r et c2=p2⊕r, un attaquant peut calculer le xor des deux cryptogrammes comme c1⊕c2=p1⊕r⊕p2⊕r=p1⊕p2. Cela signifie également que la modification du message nécessite un réencryptage complet, si le message original a pu être obtenu par un attaquant. Tous les modes de chiffrement à la vapeur suivants n'ont besoin que de l'opération de chiffrement du chiffrement par blocs, donc selon le chiffrement, cela peut permettre de gagner de l'espace (silicium 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 maximale de message afin d'éviter tout chevauchement, en utilisant les nonces, le cryptage des messages est possible sans caractère aléatoire par message, le décryptage et le cryptage sont entièrement parallélisables, les erreurs de transmission n'affectent que les mauvais bits 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, ni le cryptage ni le décryptage ne sont parallélisables, comme avec le CTR en utilisant des nonces le cryptage des messages est possible sans aléa par message, comme avec le CTR les erreurs de transmission n'affectent que les mauvais bits et rien de plus
  • BFC Le flux pseudo-aléatoire de CTR 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 en utilisant des nonces. Le cryptage des messages est possible sans aléa par message, le décryptage est parallélisable / le cryptage ne l'est pas, les erreurs de transmission détruisent complètement le bloc suivant, mais n'affectent que les mauvais bits dans le bloc actuel.
• Modes de cryptage des disques : Ces modes sont spécialisés pour chiffrer les données en dessous de l'abstraction du système de fichiers. Pour des raisons d'efficacité, la modification de certaines données sur le disque ne doit nécessiter que la réécriture d'un bloc de disque au maximum (512 octets ou 4kib). Ils sont hors de portée 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 cryptage de disque au niveau du bloc. . Certains membres : XEX, XTS, LRW.

Cryptage authentifié :

Pour éviter les attaques par oracle de remplissage et les modifications du texte chiffré, on peut calculer un code d'authentification du message (MAC) sur le texte chiffré et ne le déchiffre que s'il n'a pas été altéré. C'est ce qu'on appelle le cryptage puis le MAC. doit être préféré à tout autre ordre . À l'exception de très rares cas d'utilisation, l'authenticité est aussi importante que la confidentialité (cette dernière étant l'objectif du cryptage). Les schémas de chiffrement authentifié (avec données associées (AEAD)) combinent les deux processus de chiffrement et d'authentification en un seul mode de chiffrement par blocs 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 simple combinaison du mode CTR et d'un CBC-MAC. En utilisant deux cryptages par bloc, il est très lent.
• POE est plus rapide mais encombré de brevets. Pour les logiciels libres (comme dans liberté) ou non militaires, le détenteur du brevet a accordé une licence gratuite mais
• GCM est une combinaison très rapide mais sans doute complexe du mode CTR et de GHASH, un MAC sur le champ de Galois avec 2^128 éléments. Sa large utilisation dans d'importantes normes de réseau telles que TLS 1.2 est reflétée par l'existence d'un certificat de sécurité. instruction spéciale Intel a introduit pour accélérer le calcul du GHASH.

Recommandation :

Compte tenu de l'importance de l'authentification, je recommande les deux modes de chiffrement par blocs suivants pour la plupart des cas d'utilisation (sauf pour le chiffrement des disques) : Si les données sont authentifiées par une signature asymétrique, utilisez CBC, sinon utilisez GCM.

Answer 2

• ECB ne doit pas être utilisé si l'on crypte plus d'un bloc de données avec la même clé.

• CBC, OFB et CFB sont similaires, mais OFB/CFB est meilleur parce que vous n'avez besoin que du cryptage et non du décryptage, ce qui peut économiser de l'espace de code.

• CTR est utilisé si vous voulez une bonne parallélisation (c'est-à-dire la vitesse), au lieu de CBC/OFB/CFB.

• Le mode XTS est le plus courant si vous encodez des données accessibles de façon aléatoire (comme un disque dur ou une mémoire vive).

• L'OCB est de loin le meilleur mode, car il permet le cryptage et l'authentification en un seul passage. Cependant, il fait l'objet de brevets aux Etats-Unis.

La seule chose que vous devez vraiment savoir est que ECB ne doit pas être utilisé à moins que vous ne chiffriez qu'un seul bloc. XTS doit être utilisé si vous cryptez des données accessibles de manière aléatoire et non un flux.

• Vous devez TOUJOURS utiliser une IV à chaque fois que vous cryptez, et ils devraient être au hasard . Si vous ne pouvez pas garantir qu'ils sont au hasard utiliser la POE, car elle ne nécessite qu'une nonce et non un IV et il y a une nette différence. A nonce ne perd pas la sécurité si les gens peuvent deviner le prochain, un IV peut causer ce problème.

Answer 3

Une analyse formelle a été réalisée par Phil Rogaway en 2011, aquí . La section 1.6 donne un résumé que je retranscris ici, en ajoutant mon propre accent 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é des messages par rapport au cryptage ci-dessous).

Notez que la plupart d'entre elles exigent que le IV soit aléatoire, ce qui signifie non prévisible et doit donc être généré avec une sécurité cryptographique. Cependant, certaines requièrent uniquement un "nonce", qui n'exige pas cette propriété mais uniquement qu'il ne soit pas réutilisé. Par conséquent, les conceptions qui s'appuient 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ù le CBC n'est pas mis en œuvre avec une sélection correcte des IV). Vous verrez donc que j'ai ajouté du gras lorsque Rogaway dit quelque chose comme "la confidentialité n'est pas atteinte lorsque le IV est un nonce", cela signifie que si vous choisissez votre IV cryptographiquement sûr (imprévisible), alors pas de problème. Mais si vous ne le faites pas, alors vous perdez les bonnes propriétés de sécurité. Ne jamais réutiliser une perfusion pour l'un ou l'autre de ces modes.

Il est également important de comprendre la différence entre l'intégrité des messages et le cryptage. Le cryptage cache les données, mais un attaquant peut être en mesure de modifier les données cryptées, et les résultats peuvent potentiellement ê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 sous forme de déchets après le décryptage", un bon ingénieur en sécurité trouvera la probabilité que les déchets provoquent un comportement indésirable dans le logiciel, puis il transformera cette analyse en une véritable attaque. J'ai vu de nombreux cas où le chiffrement était utilisé mais où l'intégrité du message était vraiment plus nécessaire que le chiffrement. Comprenez ce dont vous avez besoin.

Je dois préciser que, bien que la GCM assure à la fois le cryptage et l'intégrité des messages, sa conception est très fragile : si vous réutilisez un IV, vous êtes fichu - l'attaquant peut récupérer votre clé. D'autres conceptions sont moins fragiles. Personnellement, j'ai peur de recommander la GCM en raison de la quantité de codes de chiffrement médiocres que j'ai vus dans la pratique.

Si vous avez besoin des deux, intégrité du message et chiffrement, vous pouvez combiner deux algorithmes : on voit généralement CBC avec HMAC, mais il n'y a aucune raison de s'attacher à CBC. Ce qu'il faut savoir, c'est que chiffrer d'abord, puis MAC le contenu chiffré et non l'inverse. De plus, l'IV doit faire partie du calcul du MAC.

Je ne suis pas au courant des problèmes de propriété intellectuelle.

Maintenant, passons aux bonnes choses du Professeur Rogaway :

Modes de chiffrement par blocs, chiffrement mais pas intégrité du message

BCE : Un chiffrage par blocs, ce mode permet de chiffrer les messages qui sont un multiple de n bits en chiffrant séparément chaque morceau de n bits. Les propriétés de sécurité sont faibles la méthode laisse subsister l'égalité des blocs à la fois dans la position des blocs et dans le temps. D'une valeur considérable pour l'héritage, et d'une valeur en tant que bloc de construction pour d'autres schémas, mais le mode n'atteint aucun objectif de sécurité généralement souhaitable en soi et doit être utilisé avec beaucoup de prudence ; La BCE ne doit pas être considérée comme un mode de confidentialité "généraliste". .

CBC : Un schéma de cryptage basé sur l'IV, le mode est sûr comme un schéma de cryptage probabiliste, réalisant l'indiscernabilité des bits aléatoires, en supposant un IV aléatoire. La confidentialité n'est pas atteinte si le IV 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 la norme suggère incorrectement de le faire. Les ciphertexts sont très malléables. Aucune sécurité d'attaque par texte chiffré choisi (CCA). La confidentialité est perdue en présence d'un oracle de remplissage correct pour de nombreuses méthodes de remplissage. Le chiffrement est inefficace car il est intrinsèquement sériel. Largement utilisé, les propriétés de sécurité du mode de confidentialité uniquement entraînent une mauvaise utilisation fréquente. Peut être utilisé comme un bloc de construction pour les algorithmes CBC-MAC. Je ne peux identifier aucun avantage important par rapport au mode CTR.

BFC : Un schéma de cryptage basé sur l'IV, le mode est sûr comme un schéma de cryptage probabiliste, réalisant l'indiscernabilité des bits aléatoires, en supposant un IV aléatoire. La confidentialité n'est pas atteinte si l'IV est prévisible. ni si elle est faite par un nonce chiffré sous la même clé utilisée par le schéma, comme la norme suggère incorrectement de le faire. Les Ciphertexts sont malléables. Pas de sécurité CCA. Le chiffrement est inefficace car il est intrinsèquement sériel. Le schéma dépend d'un paramètre s, 1 ≤ s ≤ n, typiquement s = 1 ou s = 8. Inefficace car nécessitant un appel au blockcipher pour traiter seulement 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 de s bits dans le texte chiffré ne perturbe que temporairement le décryptage correct.

OFB : Un schéma de cryptage basé sur IV, le mode est sûr comme un schéma de cryptage probabiliste, réalisant l'indiscernabilité des 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 bien. Les cryptogrammes sont très malléables. Pas de sécurité CCA. Le cryptage et le décryptage sont inefficaces car ils sont intrinsèquement sériels. Crypte nativement des chaînes de n'importe quelle longueur de bit (pas de remplissage nécessaire). Je ne peux identifier aucun avantage important par rapport au mode CTR.

CTR : Un schéma de cryptage basé sur IV, le mode atteint l'indiscernabilité des bits aléatoires en supposant un nonce IV. En tant que schéma sécurisé basé sur un nonce, le mode peut également être utilisé comme schéma de cryptage probabiliste, avec un IV aléatoire. Échec complet de la confidentialité si un nonce est réutilisé lors du cryptage ou du décryptage. La parallélisation du mode le rend souvent plus rapide, voire beaucoup plus rapide dans certains cas, que d'autres modes de confidentialité. Un bloc de construction important pour les schémas de cryptage authentifié. Dans l'ensemble, il s'agit généralement du meilleur moyen, et le plus moderne, de réaliser un cryptage exclusivement privé.

XTS : Un schéma de cryptage basé sur l'IV, le mode fonctionne en appliquant un chiffrement par blocs modifiable (sécurisé comme un strong-PRP) à chaque bloc de n bits. Pour les messages dont la longueur n'est pas divisible par n, les deux derniers blocs sont traités spécialement. La seule utilisation autorisée de ce mode est le chiffrement de données sur un dispositif de stockage structuré en blocs. La faible largeur du PRP sous-jacent et le mauvais traitement des blocs finaux fractionnaires posent problème. Il serait plus efficace, mais moins souhaitable, d'utiliser un chiffrement par blocs (large) sécurisé par le PRP.

MACs (intégrité des messages mais pas de cryptage)

ALG1-6 : Une collection de MAC, tous basés sur le CBC-MAC. Trop de schémas. Certains sont prouvés sûrs en tant que VIL PRFs, d'autres en tant que FIL PRFs, et certains n'ont pas de sécurité prouvable. Certains des schémas admettent des attaques dommageables. Certains des modes sont datés. La séparation des clés n'est pas suffisamment prise en compte pour les modes qui en disposent. Ne devrait pas être adopté en masse, mais une sélection des "meilleurs" schémas est possible. Il serait également possible de n'adopter aucun de ces modes, en faveur de CMAC. Certains des MAC de la norme ISO 9797-1 sont largement normalisés et utilisés, notamment dans le secteur bancaire. Une version révisée de la norme (ISO/IEC FDIS 9797-1:2010) sera bientôt publiée [93].

CACM : Un MAC basé sur le CBC-MAC, le mode est provablement sûr (jusqu'à la limite d'anniversaire) comme un (VIL) PRF (en supposant que le blockcipher sous-jacent est un bon PRP). Frais généraux essentiellement minimes pour un schéma basé sur CBCMAC. La nature intrinsèquement sérielle est un problème dans certains domaines d'application, et l'utilisation avec un chiffrement par blocs de 64 bits nécessiterait une nouvelle clé occasionnelle. Plus propre que la collection de MACs de l'ISO 9797-1.

HMAC : Un MAC basé sur une fonction de hachage cryptographique plutôt que sur un blockchain (bien que la plupart des fonctions de hachage cryptographique soient elles-mêmes basées sur des blockchips). Le mécanisme bénéficie de fortes limites de sécurité prouvables, bien que ce ne soit pas à partir des hypothèses préférées. De multiples variantes étroitement liées dans la littérature compliquent la compréhension de ce qui est connu. Aucune attaque dommageable n'a jamais été suggérée. Largement normalisé et utilisé.

GMAC : Un MAC basé sur un nonce qui est un cas particulier de GCM. Il hérite de nombreuses caractéristiques, bonnes et mauvaises, du GCM. Mais l'exigence de nonce n'est pas nécessaire pour un MAC, et ici elle apporte peu d'avantages. Attaques pratiques si les tags sont tronqués à ≤ 64 bits et si l'étendue du décryptage n'est pas surveillée et limitée. Échec complet sur la réutilisation du nonce. L'utilisation est implicite de toute façon si le GCM est adopté. Non recommandé pour une normalisation séparée.

le cryptage authentifié (à la fois le cryptage et l'intégrité du message)

CCM : Un schéma AEAD basé sur un nonce qui combine le chiffrement en mode CTR et le système brut CBC-MAC. Intrinsèquement sériel, limitant la vitesse dans certains contextes. Provablement sûr, avec de bonnes limites, en supposant que le chiffrement par blocs sous-jacent est un bon PRP. Construction simple qui fait manifestement l'affaire. Plus simple à mettre en œuvre que le GCM. Peut être utilisé comme un MAC basé sur un nonce. Largement normalisé et utilisé.

GCM : Un schéma AEAD basé sur un 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. Bons résultats de sécurité prouvable en supposant une troncature minimale des étiquettes. Attaques et limites de sécurité prouvables médiocres en présence d'une troncature substantielle des étiquettes. Peut être utilisé comme un MAC basé sur les nonces, qui est alors appelé GMAC. Choix discutable d'autoriser des nonces autres que 96 bits. Il est recommandé de limiter les nonces à 96 bits et les tags à au moins 96 bits. Largement normalisé et utilisé.

Answer 4

1. Tout sauf la BCE.
2. Si vous utilisez le mode CTR, il est impératif d'utiliser un IV différent pour chaque message, sinon l'attaquant pourra prendre deux cryptogrammes et en déduire un texte en clair combiné non chiffré. La raison en est que le mode CTR transforme essentiellement un chiffrement par blocs en un chiffrement par flux, et la première règle des chiffrement par flux est de ne jamais utiliser deux fois la même clé + IV.
3. Il n'y a pas vraiment de différence dans la difficulté de mise en œuvre de ces modes. Certains modes ne nécessitent que le fonctionnement du chiffrement par blocs dans le sens du chiffrement. Cependant, la plupart des algorithmes de chiffrement par blocs, y compris AES, ne nécessitent pas beaucoup plus de code pour mettre en œuvre le déchiffrement.
4. Pour tous les modes de chiffrement, il est important d'utiliser des IV différents pour chaque message si vos messages peuvent être identiques dans les premiers octets et que vous ne voulez pas qu'un attaquant le sache.

Answer 5

Avez-vous commencé par lire les informations à ce sujet sur Wikipédia ? Modes de fonctionnement du chiffrement par blocs ? Suivez alors le lien de référence sur Wikipedia vers NIST : Recommandation pour les modes d'opération de chiffrement par blocs .