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 intégrés à microcode, tels que les cartes réseau 802.11. Si le code requirejs pour implémenter CBC est beaucoup plus petit que celui requirejs pour CTR (je ne sais pas si c’est vrai, c’est juste un exemple), alors je pourrais comprendre pourquoi le mode avec le code le 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 utilise à la fois CBC et CTR, alors ce critère est sans importance.

Voir 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 c’est lié à l’algorithme.

  • ECB ne doit pas être utilisé pour chiffrer 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 n’avez besoin que du chiffrement et non du déchiffrement, ce qui permet de gagner de la place dans le code.

  • CTR est utilisé si vous souhaitez une bonne parallélisation (c.-à-d. Vitesse), au lieu de CBC / OFB / CFB.

  • Le mode XTS est le plus courant si vous encodez des données accessibles au hasard (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 cryptiez que 1 bloc. XTS doit être utilisé si vous chiffrez des données à access aléatoire et non un stream.

  • Vous devriez TOUJOURS utiliser des IV uniques à chaque fois que vous cryptez, 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 y a une différence distincte. Un nonce ne laisse pas tomber la sécurité si les gens peuvent deviner le prochain, une IV peut causer ce problème.

Un mot d’introduction: Cette réponse était en partie une réponse à beaucoup de questions que j’ai vues sous l’étiquette [encryption] qui montrait des personnes déployant du code complètement non sécurisé. S’adressant à ces programmeurs, j’ai écrit la phrase d’ouverture suivante avec l’intention de les secouer suffisamment pour repenser leur approche de la cryptographie avant que leur application ne soit attaquée. Si vous êtes en train d’apprendre, c’est génial! Nous avons besoin de plus de programmeurs ayant des connaissances de base en cryptographie. Continuez à demander et ajoutez un silence “encore!” à mon ouverture:

Si vous avez besoin de poser cette question, vous ne connaissez probablement pas assez la cryptographie pour implémenter un système sécurisé.

Je sais que cela semble dur, alors laissez-moi illustrer mon propos: Imaginez que vous construisez une application Web et que vous ayez besoin de stocker des données de session. Vous pouvez atsortingbuer à chaque utilisateur un ID de session et stocker les données de session sur le serveur dans l’ID de session de mappage de carte 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 se gâteront. Au lieu de cela, vous avez l’idée de stocker les données de session dans un cookie du côté client. Vous allez bien sûr le chiffrer pour que l’utilisateur ne puisse pas lire et manipuler les données. Alors, quel mode devriez-vous utiliser? En venant ici, vous lisez la première réponse (désolé de vous avoir choisi myforwik). Le premier couvert – ECB – n’est pas pour vous, vous voulez crypter plus d’un bloc, le suivant – CBC – sonne bien et vous n’avez pas besoin du parallélisme du CTR, vous n’avez pas besoin d’un access aléatoire, donc non XTS et les brevets sont un PITA, donc pas d’OCB. En utilisant votre bibliothèque de chiffrement, vous réalisez que vous avez besoin de 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 la sécurité de la SRC est prouvée si elle est utilisée avec un code aléatoire aléatoire et un chiffrement par bloc sécurisé, vous êtes à l’aise même si vous stockez vos données sensibles du côté client.

Des années après que votre service a effectivement atteint une taille significative, un spécialiste de la sécurité informatique vous contacte pour une divulgation responsable. Elle vous dit qu’elle peut décrypter tous vos cookies en utilisant une attaque par oracle de remplissage , car votre code produit une page d’erreur si le remplissage est en quelque sorte cassé.

Ce n’est pas un scénario hypothétique: Microsoft avait cette faille exacte dans ASP.NET jusqu’à il y a quelques années.

Le problème est qu’il y a beaucoup de pièges en ce qui concerne la cryptographie et qu’il est extrêmement facile de construire un système qui semble sécurisé pour le profane mais qui est facile à casser pour un attaquant averti.

Que faire si vous avez besoin de chiffrer des données

Pour les connexions en direct, utilisez TLS (veillez à vérifier le nom d’hôte du certificate 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 a à offrir pour votre tâche et assurez-vous de bien comprendre les garanties qu’il offre et plus important ce qu’il ne garantit pas. Pour l’exemple ci-dessus, un framework comme Play offre des possibilités de stockage côté client , il n’invalide pas les données stockées après un certain temps, et si vous modifiez l’état côté client, un attaquant peut restaurer un état précédent sans que vous le remarquiez.

S’il n’y a pas d’abstraction de haut niveau, utilisez une bibliothèque cryptographique de haut niveau. Un exemple frappant est NaCl et une implémentation portable avec de nombreuses liaisons de langage est Sodium . En utilisant une telle bibliothèque, vous n’avez pas à vous soucier des modes de cryptage, mais vous devez être encore plus attentif aux détails d’utilisation qu’avec une abstraction de plus haut niveau, comme ne jamais utiliser 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 un système existant d’une manière spécifique, vous ne pouvez pas vous renseigner à fond. Je recommande de lire Cryptography Engineering de 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 l’arrière-plan nécessaire. La cryptographie est extrêmement subtile et il est presque impossible de tester la sécurité d’un système.

A des fins éducatives, une 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é de remplir les attaques d’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 produira le même bloc de texte chiffré. Jetez un coup d’oeil à l’image Tux cryptée de la BCE sur la page Wikipedia de la BCE pour voir pourquoi il s’agit d’un problème grave. Je ne connais aucun 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é, changer une partie du message nécessite de tout rechiffrer après le changement, les erreurs de transmission dans un bloc de texte chiffré détruisent complètement le texte brut et changent le déchiffrement du prochain bloc, déchiffrement peut être parallélisé / cryptage ne peut pas, le texte en clair est malléable dans une certaine mesure – cela peut être un problème .
  • Modes de chiffrement de stream : Ces modes génèrent un stream de données pseudo-aléatoire pouvant dépendre ou non du texte en clair. De manière similaire au stream de chiffrement en général, le stream pseudo-aléatoire généré est XOR avec le texte en clair pour générer le texte chiffré. Comme vous pouvez utiliser autant de bits du stream aléatoire que vous le souhaitez, vous n’avez pas besoin de remplissage. Le désavantage de cette simplicité est que le cryptage est complètement malléable , ce qui signifie que le piratage peut être modifié par un attaquant comme il le souhaite pour un texte en clair p1, un cryptogramme c1 et un stream pseudo-aléatoire r. que le déchiffrement d’un texte chiffré c2 = c1⊕d est p2 = p1⊕d, car p2 = c2⊕r = (c1 ⊕ d) ⊕ r = d ⊕ (c1 ⊕ r). De même, le même stream pseudo-aléatoire ne doit jamais être utilisé deux fois comme pour deux chiffresxte c1 = p1⊕r et c2 = p2⊕r, un attaquant peut calculer le xor des deux textes en clair comme c1⊕c2 = p1⊕r⊕p2⊕r = p1⊕p2. Cela signifie également que la modification du message nécessite un rechiffrement complet, si le message original a pu être obtenu par un attaquant. Tous les modes de chiffrement à la vapeur suivants ne nécessitent que l’opération de chiffrement du chiffrement par blocs, ce qui, en fonction du chiffrement, pourrait permettre d’économiser de l’espace (silicium ou code machine) dans des environnements extrêmement restreints.
    • CTR est simple, il crée un stream pseudo-aléatoire indépendant du texte en clair, différents stream pseudo-aléatoires sont obtenus en comptant à partir de différentes nonces / IV qui sont multipliées par une longueur de message maximale afin d’éviter le chevauchement. possible sans aléatoire par message, le décryptage et le cryptage sont parallélisés, les erreurs de transmission n’affectent que les mauvais bits et rien de plus
    • OFB crée également un stream pseudo-aléatoire indépendant du texte en clair, différents stream pseudo-aléatoires sont obtenus en commençant par un nonce différent ou aléatoire IV pour chaque message, aucun chiffrement ni déchiffrement n’est parallélisable, car le CTR utilisant des nonces caractère aléatoire, comme avec les erreurs de transmission CTR n’affectent que les mauvais bits et rien de plus
    • Le stream pseudo-aléatoire de CFB dépend du texte en clair, un nonce ou un IV différent est nécessaire pour chaque message, comme avec CTR et OFB utilisant des nonces, le chiffrement des messages est possible sans aléatoire, le déchiffrement est parallélisable / non détruit le bloc suivant, mais n’effectue que les mauvais bits dans le bloc en cours
  • Modes de chiffrement de disque : Ces modes sont spécialisés pour chiffrer les 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 doit nécessiter que la réécriture d’au plus un bloc de disque (512 octets ou 4 ko). Ils sont hors de scope de cette réponse car ils ont des scénarios d’utilisation très différents les uns des autres. Ne les utilisez pas pour autre chose que le cryptage de disque au niveau bloc . Quelques membres: XEX, XTS, LRW.

Cryptage authentifié:

Pour empêcher le remplissage des attaques Oracle et les modifications du 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é. Cela s’appelle encrypt-then-mac et 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é (ce qui est le but du cryptage). Les schémas de cryptage authentifiés (avec données associées (AEAD)) combinent le processus de cryptage et d’authentification en deux parties en un mode de chiffrement par bloc qui produit également une étiquette d’authentification dans le processus. Dans la plupart des cas, cela se traduit par une amélioration de la vitesse.

  • CCM est une combinaison simple du mode CTR et d’un CBC-MAC. En utilisant deux chiffrements par bloc, il est très lent.
  • OCB est plus rapide mais encombré de brevets. Pour le logiciel libre (comme en liberté) ou non militaire, le titulaire du brevet a cependant accordé une licence gratuite .
  • GCM est une combinaison très rapide mais sans doute complexe du mode CTR et du GHASH, un MAC sur le champ Galois avec 2 ^ 128 éléments. Son utilisation généralisée dans des normes réseau importantes comme TLS 1.2 se traduit par une instruction spéciale introduite par Intel pour accélérer le calcul du GHASH.

Recommandation:

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

  1. Tout sauf la BCE.
  2. Si vous utilisez CTR, il est impératif que vous utilisiez un IV différent pour chaque message, sinon vous vous retrouverez avec l’attaquant capable de prendre deux textes chiffrés et de déduire un texte en clair non chiffré. La raison en est que le mode CTR transforme essentiellement un chiffrement de bloc en un chiffrement de stream, et la première règle des chiffrements de stream 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é à mettre en œuvre les modes. Certains modes nécessitent uniquement le chiffrement par bloc pour fonctionner dans le sens du chiffrement. Cependant, la plupart des algorithmes de chiffrement, y compris AES, ne nécessitent pas beaucoup plus de code pour implémenter 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 vous ne voulez pas qu’un attaquant le sache.

Une parsing formelle a été faite par Phil Rogaway en 2011, ici . La section 1.6 donne un résumé que je transcris ici, en mettant l’accent sur les caractères 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 requièrent que le IV soit aléatoire, ce qui signifie qu’il est imprévisible et qu’il devrait donc être généré avec une sécurité cryptographique. Cependant, certains ne requièrent qu’un “nonce”, qui n’exige pas cette propriété mais exige seulement qu’il ne soit pas réutilisé. Par conséquent, les conceptions qui reposent sur un nonce sont moins sujettes aux erreurs que les conceptions qui ne le font pas (et croyez-moi, j’ai vu de nombreux cas où le CBC n’est pas implémenté avec une sélection IV appropriée). Donc, vous verrez que j’ai ajouté gras lorsque Rogaway dit que quelque chose comme “la confidentialité n’est pas atteinte lorsque l’IV est un nonce”, cela signifie que si vous choisissez votre IV sécurisé cryptographiquement (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 réutilisez jamais une IV pour aucun de ces modes.

En outre, il est important de comprendre la différence entre l’intégrité des messages et le chiffrement. Le cryptage masque les données, mais un attaquant peut être en mesure de modifier les données cryptées, et les résultats peuvent être acceptés par votre logiciel si vous ne vérifiez pas l’intégrité des messages. Alors que le développeur dira “mais les données modifiées reviendront comme des déchets après le décryptage”, un bon ingénieur de sécurité trouvera la probabilité que les déchets provoquent un comportement indésirable dans le logiciel, puis il transformera cette parsing en une véritable attaque. J’ai vu de nombreux cas où le cryptage était utilisé mais l’intégrité des messages était vraiment plus nécessaire que le cryptage. Comprenez ce dont vous avez besoin.

Je dois dire que, bien que GCM ait à la fois le cryptage et l’intégrité des messages, c’est une conception très fragile: si vous réutilisez une IV, vous êtes foutu: l’attaquant peut récupérer votre clé. D’autres conceptions sont moins fragiles, aussi j’ai personnellement peur de recommander GCM en fonction de la quantité de code de chiffrement médiocre que j’ai vu dans la pratique.

Si vous avez besoin à la fois de l’intégrité des messages et du cryptage, vous pouvez combiner deux algorithmes: nous voyons généralement CBC avec HMAC, mais aucune raison de vous lier à CBC. La chose importante à savoir est de crypter en premier, puis MAC le contenu crypté , et non l’inverse. En outre, le IV doit faire partie du calcul du MAC.

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

Passons maintenant aux bonnes choses du professeur Rogaway:

Bloquer les modes de chiffrement, le chiffrement mais pas l’intégrité des messages

ECB : Un bloc de chiffrement, le mode chiffre 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 perdant l’égalité des blocs à la fois entre les positions de bloc et l’heure. Valeur pasortingmoniale considérable et valeur en tant que composante de base pour d’autres systèmes, mais le mode n’atteint aucun objective de sécurité généralement souhaitable et doit être utilisé avec beaucoup de prudence; La BCE ne devrait pas être considérée comme un mode de confidentialité «généraliste» .

CBC : Schéma de chiffrement basé sur IV, le mode est sécurisé en tant que schéma de chiffrement probabiliste, réalisant une distinction impossible avec des bits aléatoires, en supposant un IV aléatoire. La confidentialité n’est pas atteinte si l’IV est simplement un nonce , ou si c’est un nonce chiffré sous la même clé que celle utilisée par le schéma, ce que la norme suggère à tort de faire. Les chiffres sont très malléables. Pas de sécurité choisie pour l’attaque de texte crypté (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 en tant que série insortingnsèque. Largement utilisé, les propriétés de sécurité de la confidentialité uniquement du mode entraînent des abus fréquents. 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 : Un schéma de chiffrement basé sur IV, le mode est sécurisé comme un schéma de chiffrement probabiliste, réalisant une distinction impossible avec 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é que celle utilisée par le système, ce que la norme suggère à tort de faire. Les chiffres sont malléables. Pas de sécurité CCA. Le chiffrement est inefficace en tant que série insortingnsèque. Scheme dépend d’un paramètre s, 1 ≤ s ≤ n, typiquement s = 1 ou s = 8. Inefficace pour nécessiter un appel de bloc pour traiter seulement s bits. Le mode réalise une propriété intéressante «d’auto-synchronisation»; l’insertion ou la suppression d’un nombre quelconque de caractères s-bit dans le texte chiffré ne perturbe que temporairement le décryptage correct.

OFB : Un schéma de chiffrement basé sur IV, le mode est sécurisé en tant que schéma de chiffrement probabiliste, réalisant une indiscernabilité des bits aléatoires, en supposant un IV aléatoire. La confidentialité n’est pas atteinte si l’IV est un nonce, bien qu’une séquence fixe d’IV (par exemple, un compteur) fonctionne correctement. Les chiffres sont très malléables. Pas de sécurité CCA. Le chiffrement et le déchiffrement ne sont pas efficaces par nature. Encrypte nativement les 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 chiffrement basé sur IV, le mode atteint une indiscernabilité des bits aléatoires en supposant un nonce IV. En tant que schéma sécurisé non-basé, le mode peut également être utilisé comme schéma de chiffrement 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, dans certains parameters beaucoup plus rapide, que d’autres modes de confidentialité. Un bloc de construction important pour les schémas de cryptage authentifiés. Dans l’ensemble, il s’agit généralement du moyen le plus efficace et le plus moderne de parvenir à un chiffrement de confidentialité uniquement.

XTS : Un schéma de chiffrement basé sur IV, le mode fonctionne en appliquant un bloc de chiffrement ajustable (sécurisé en tant que PRP fort) à chaque bloc n bits. Pour les messages dont la longueur n’est pas divisible par n, les deux derniers blocs sont traités spécialement. Le seul usage autorisé du mode est le cryptage 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 fractionnés posent problème. Plus efficace mais moins souhaitable qu’un bloc de chiffrement sécurisé PRP (à blocs larges) serait.

MAC (intégrité du message mais pas de cryptage)

ALG1–6 : Une collection de MAC, tous basés sur le CBC-MAC. Trop de schémas. Certains sont sûrement sécurisés en tant que PRF VIL, certains en tant que PRF FIL et d’autres n’ont aucune sécurité prouvable. Certains des systèmes admettent des attaques dommageables. Certains modes sont datés. La séparation des clés est insuffisamment prise en compte pour les modes qui l’ont. Ne devrait pas être adopté en masse, mais choisir sélectivement les «meilleurs» schémas est possible. Il serait également bon d’adopter aucun de ces modes, en faveur de la CMAC. Certains des MAC ISO 9797-1 sont largement normalisés et utilisés, 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 : Un MAC basé sur le CBC-MAC, le mode est sûrement sécurisé (jusqu’à la limite d’anniversaire) en tant que PRF (VIL) (en supposant que le blockcipher sous-jacent est un bon PRP). Des frais généraux essentiellement minimes pour un système basé sur CBCMAC. La nature insortingnsèquement série, un problème dans certains domaines d’application, et une utilisation avec un chiffrement à 64 bits nécessiteraient parfois une nouvelle saisie. Plus propre que la collection ISO 9797-1 de MAC.

HMAC : MAC basé sur une fonction de hachage cryptographique plutôt que sur un bloc de chiffrement (bien que la plupart des fonctions de hachage cryptographiques soient elles-mêmes basées sur des codeurs de blocs). Le mécanisme jouit de solides limites de sécurité prouvables, mais pas d’hypothèses privilégiées. Plusieurs variantes étroitement liées dans la littérature compliquent l’acquisition d’une compréhension de ce qui est connu. Aucune attaque dommageable n’a jamais été suggérée. Largement normalisé et utilisé.

GMAC : un MAC nonce basé sur un cas particulier de GCM. Hérite beaucoup des bonnes et mauvaises caractéristiques de GCM. Mais le besoin de nonce n’est pas nécessaire pour un MAC, et ici, il n’apporte que peu d’avantages. Les attaques pratiques si les balises sont tronquées à ≤ 64 bits et l’étendue du déchiffrement ne sont pas surveillées et réduites. Échec complet sur non-réutilisation. L’utilisation est implicite de toute façon si GCM est adopté. Non recommandé pour la normalisation séparée.

cryptage authentifié (cryptage et intégrité des messages)

CCM : schéma AEAD non-basé qui combine le chiffrement en mode CTR et le CBC-MAC brut. Série insortingnsèquement, limitant la vitesse dans certains contextes. Provisoirement sécurisé, avec de bonnes limites, en supposant que le blockcipher sous-jacent est un bon PRP. Dommage construction qui fait manifestement le travail. Plus simple à mettre en œuvre que GCM. Peut être utilisé comme MAC nonce basé. Largement normalisé et utilisé.

GCM : schéma AEAD non-basé qui combine le chiffrement en mode CTR et une fonction de hachage universelle basée sur GF (2128). Bonnes caractéristiques d’efficacité pour certains environnements d’implémentation. Bons résultats sécurisés en supposant une troncature minimale des balises. Attaques et mauvaises limites de sécurité prouvable en présence d’une troncature importante des balises. Peut être utilisé comme un MAC nonce basé alors appelé GMAC. Choix discutable pour autoriser des nonces autres que 96 bits. Recommande de limiter les nonces à 96 bits et les étiquettes à au moins 96 bits. Largement normalisé et utilisé.

Avez-vous commencé par lire les informations à ce sujet sur Wikipedia – Bloquer les modes de fonctionnement ? Suivez ensuite le lien de référence sur Wikipedia vers NIST: Recommandation pour les modes de fonctionnement en mode bloc .

Vous voudrez peut-être choisir en fonction de ce qui est largement disponible. J’ai eu la même question et voici les résultats de mes recherches limitées.

Limites matérielles

 STM32L (low energy ARM cores) from ST Micro support ECB, CBC,CTR GCM CC2541 (Bluetooth Low Energy) from TI supports ECB, CBC, CFB, OFB, CTR, and CBC-MAC 

Limitations Open Source

 Original rijndael-api source - ECB, CBC, CFB1 OpenSSL - command line CBC, CFB, CFB1, CFB8, ECB, OFB OpenSSL - C/C++ API CBC, CFB, CFB1, CFB8, ECB, OFB and CTR EFAES lib [1] - ECB, CBC, PCBC, OFB, CFB, CRT ([sic] CTR mispelled) OpenAES [2] - ECB, CBC 

[1] http://www.codeproject.com/Articles/57478/A-Fast-and-Easy-to-Use-AES-Library

[2] https://openaes.googlecode.com/files/OpenAES-0.8.0.zip

Je connais un aspect: bien que la sécurité de la CBC soit améliorée en modifiant la valeur IV pour chaque bloc, elle ne s’applique pas au contenu chiffré à access aléatoire (comme un disque dur chiffré).

Donc, utilisez CBC (et les autres modes séquentiels) pour les stream séquentiels et ECB pour un access aléatoire.