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, 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 c'est vrai, c'est juste 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 à la fois CBC et CTR, ce critère n'est pas pertinent.

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.

• La BCE ne doit pas être utilisée si vous cryptez plus d'un bloc de données avec la même clé.

• CBC, OFB et CFB sont similaires, mais OFB / CFB est meilleur car vous n'avez besoin que du chiffrement et non du déchiffrement, 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 au hasard (comme un disque dur ou une RAM).

• OCB est de loin le meilleur mode, car il permet le chiffrement 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 bloc. XTS doit être utilisé si vous chiffrez des données accédées de manière aléatoire et non un flux.

• Vous devez TOUJOURS utiliser des IV uniques à chaque fois que vous cryptez, et ils doivent être aléatoires . Si vous ne pouvez pas garantir qu'ils sont aléatoires , utilisez l'OCB car il ne nécessite qu'un nonce , pas un IV , et il y a une différence distincte. Un nonce ne baisse pas la sécurité si les gens peuvent deviner le suivant, un IV peut causer ce problème.

Veuillez considérer long et difficile si vous ne pouvez pas contourner l'implémentation de votre propre cryptographie

La triste vérité est que si vous posez cette question, vous ne pourrez probablement pas concevoir et mettre en œuvre un système sécurisé.

Permettez-moi d'illustrer mon propos: imaginez que vous créez une application Web et que vous devez 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 mappage de hachage aux 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 deviendront désordonnées. Donc, à la place, vous avez l'idée de stocker les données de session dans un cookie côté client. Vous allez bien sûr le crypter afin 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 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 accès aléatoire, donc pas de XTS et de brevets sont un PITA, donc pas d'OCB. En utilisant votre bibliothèque de chiffrement, vous réalisez que vous avez besoin d'un rembourrage car vous ne pouvez chiffrer que des multiples de la taille du bloc. Tu choisisPKCS7 car il a été défini dans certaines normes de cryptographie sérieuses. Après avoir lu quelque part que CBC est prouvablement sécurisé 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.

Des années plus tard, après que votre service ait atteint une taille importante, 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 à l'aide d'une attaque oracle de remplissage , car votre code génère 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 existe de nombreux pièges en ce qui concerne la cryptographie et il est extrêmement facile de créer un système qui semble sécurisé pour le profane, mais qu'il est trivial de casser pour un attaquant averti.

Que faire si vous devez crypter 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 d'émetteur). Si vous ne pouvez pas utiliser TLS, recherchez l'API de plus haut niveau que votre système doit offrir pour votre tâche et assurez-vous de comprendre les garanties qu'il offre et, plus important encore, ce qu'il ne garantit pas. Pour l'exemple ci-dessus, un framework comme Play offre des fonctionnalités de stockage côté client , mais il n'invalide pas les données stockées après un certain temps, et si vous avez modifié 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 disponible, utilisez une bibliothèque de chiffrement 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 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 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 le système existant d'une manière spécifique, il n'y a aucun moyen de vous renseigner complètement. Je recommande la lecture de Cryptography Engineering par Ferguson, Kohno et Schneier . Veuillez ne pas vous leurrer en croyant que vous pouvez construire un système sécurisé sans le fond nécessaire. 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é de bourrer les attaques d'oracle. La défense la plus simple consiste à authentifier chaque message avant le décryptage. Voir ci-dessous.
  • ECB crypte 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 œil à l'image Tux chiffrée par la BCE sur la page Wikipedia de la BCE pour voir pourquoi c'est 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 crypté, changer une partie du message nécessite de rechiffrer tout après la modification, les erreurs de transmission dans un bloc de texte chiffré détruisent complètement le texte en clair et modifient le déchiffrement du bloc suivant, déchiffrement peut être parallélisé / le 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 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 manière similaire aux chiffrements de flux en général, le flux 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 flux aléatoire que vous le souhaitez, vous n'avez pas besoin du tout de remplissage. L'inconvénient de cette simplicité est que le chiffrement est complètement malléable, ce qui signifie que le décryptage peut être modifié par un attaquant comme il le souhaite 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 est 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 comme pour deux chiffrements 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 d'origine aurait pu être obtenu par un attaquant. Tous les modes de chiffrement à vapeur suivants n'ont besoin que de l'opération de chiffrement du chiffrement par bloc, donc selon le chiffrement, cela pourrait économiser de l'espace (silicium ou code machine) dans des environnements extrêmement restreints.
  • Le CTR est simple, il crée un flux pseudo-aléatoire qui est 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 afin d'éviter tout chevauchement, en utilisant le chiffrement des messages nonces. possible sans aléatoire par message, le déchiffrement et le chiffrement sont complétés 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 différent ou un IV aléatoire pour chaque message, ni le chiffrement ni le déchiffrement ne sont parallélisables, comme avec le CTR utilisant le chiffrement des messages nonces est possible sans par message aléatoire, comme avec les erreurs de transmission CTR n'affectent que les mauvais bits et rien de plus
  • Le flux pseudo-aléatoire de CFB dépend du texte en clair, un nonce différent ou un IV aléatoire est nécessaire pour chaque message, comme avec CTR et OFB, l'utilisation du chiffrement des messages nonces est possible sans aléatoire par message, le déchiffrement est parallélisable / le chiffrement ne l'est pas, les erreurs de transmission sont complètement détruisez le bloc suivant, mais n'effectuez que les mauvais bits dans le bloc actuel
• Modes de chiffrement du 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 kib). Ils sont hors de portée 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 chiffrement de disque au niveau bloc . Quelques membres: XEX, XTS, LRW.

Cryptage authentifié:

Pour empêcher les attaques oracle de remplissage et les modifications du texte chiffré, on peut calculer un code d'authentification de message (MAC) sur le texte chiffré et le déchiffrer uniquement s'il n'a pas été falsifié. Cela s'appelle encrypt-then-mac et doit ê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 dernier objectif étant le chiffrement). Les schémas de chiffrement authentifiés (avec données associées (AEAD)) combinent le processus en deux parties de chiffrement et d'authentification en un mode de chiffrement par bloc qui produit également une étiquette d'authentification dans le processus. Dans la plupart des cas, cela entraîne une amélioration de la vitesse.

• CCM est une combinaison simple du mode CTR et d'un CBC-MAC. L'utilisation de deux chiffrements de blocs par bloc est très lente.
• OCB est plus rapide mais grevé de brevets. Pour les logiciels libres (comme en liberté) ou non militaires, 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 de GHASH, un MAC sur le champ de Galois avec 2 ^ 128 éléments. Sa large utilisation dans des normes de réseau importantes comme TLS 1.2 se reflète dans une instruction spéciale qu'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 pour la plupart des cas d'utilisation (sauf à des fins de 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é effectuée par Phil Rogaway en 2011, ici . La section 1.6 donne un résumé que je transcris ici, en ajoutant ma propre emphase 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 eux nécessitent que l'IV soit aléatoire, ce qui signifie non prévisible et doit donc être généré avec une sécurité cryptographique. Cependant, certains ne nécessitent qu'un "nonce", ce qui n'exige pas cette propriété, mais exige uniquement qu'elle ne soit pas réutilisée. 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ù la CBC n'est pas implémentée avec une sélection IV appropriée). 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 sécurisée cryptographiquement (imprévisible), alors pas de 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é des messages et le chiffrement. Le chiffrement cache les données, mais un attaquant pourrait être en mesure de modifier les données chiffrées, et les résultats peuvent potentiellement ê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 ordures après le décryptage", un bon ingénieur en sécurité trouvera la probabilité que les ordures provoquent un comportement défavorable dans le logiciel, puis il transformera cette analyse en une véritable attaque. J'ai vu de nombreux cas où le cryptage a été utilisé mais l'intégrité du message était vraiment plus nécessaire que le cryptage. Comprenez ce dont vous avez besoin.

Je dois dire que bien que GCM possède à la fois le chiffrement et l'intégrité des messages, c'est une conception très fragile: si vous réutilisez un IV, vous êtes foutu - l'attaquant peut récupérer votre clé. D'autres conceptions sont moins fragiles, j'ai donc 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 des deux, de l'intégrité du message et du 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 de chiffrer d'abord, puis MAC le contenu chiffré , et non l'inverse. De plus, l'IV doit faire partie du calcul MAC.

Je ne suis pas au courant des problèmes IP.

Passons maintenant aux bonnes choses du professeur Rogaway:

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

ECB : Un blockcipher, le mode chiffre des 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 faisant fuir l'égalité des blocs à la fois sur la position des blocs et sur le temps. D'une valeur héritée considérable et d'une valeur en tant que bloc de construction pour d'autres systèmes, 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é «à usage général» .

CBC : Un schéma de cryptage basé sur IV, le mode est sécurisé en tant que schéma de cryptage probabiliste, réalisant une distinction entre les bits aléatoires, en supposant une IV aléatoire. La confidentialité n'est pas atteinte si l'IV est simplement un nonce , ni s'il s'agit d'un nonce chiffré sous la même clé utilisée par le schéma, comme la norme suggère à tort de le faire. Les chiffrements sont très malléables. Aucune sécurité d'attaque de texte chiffré (CCA) choisie. La confidentialité est perdue en présence d'un oracle à rembourrage correct pour de nombreuses méthodes de rembourrage. Le chiffrement est inefficace car il est intrinsèquement série. Largement utilisées, les propriétés de sécurité du mode uniquement pour la confidentialité entraînent une mauvaise utilisation fréquente. 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 cryptage basé sur IV, le mode est sécurisé en tant que schéma de cryptage probabiliste, réalisant 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 si elle est faite par un nonce chiffré sous la même clé utilisée par le schéma, comme la norme suggère à tort de le faire. Les textes chiffrés sont malléables. Pas de sécurité CCA. Le chiffrement est inefficace car il est intrinsèquement série. Le schéma dépend d'un paramètre s, 1 ≤ s ≤ n, généralement s = 1 ou s = 8. Inefficace pour avoir besoin d'un appel de chiffrement par blocs pour traiter uniquement 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 cryptage basé sur IV, le mode est sécurisé en tant que schéma de cryptage probabiliste, réalisant une distinction entre les 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 bien. Les chiffrements sont très malléables. Pas de sécurité CCA. Le chiffrement et le déchiffrement sont inefficaces car ils sont intrinsèquement série. Crypte en mode natif des chaînes de n'importe quelle longueur de bit (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 permet de ne pas distinguer les bits aléatoires en supposant un IV nonce. En tant que schéma sécurisé non basé sur lece, 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 chiffrement ou du 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, il s'agit généralement de la méthode la meilleure et la plus moderne pour réaliser un chiffrement uniquement confidentiel.

XTS : schéma de chiffrement basé sur IV, le mode fonctionne en appliquant un chiffrement à bloc ajustable (sécurisé comme un PRP fort) à 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 du mode est le cryptage des données sur un périphérique de stockage structuré en blocs. La largeur étroite du PRP sous-jacent et le mauvais traitement des blocs finaux fractionnaires sont des problèmes. Plus efficace mais moins souhaitable qu'un chiffrement à blocs sécurisé par un PRP (bloc large).

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

ALG1–6 : une collection de MAC, tous basés sur le CBC-MAC. Trop de schémas. Certains sont prouvablement sécurisés en tant que PRF VIL, certains en tant que PRF FIL, et certains n'ont aucune sécurité prouvable. Certains régimes admettent des attaques dommageables. Certains modes sont datés. La séparation des clés n'est pas suffisamment prise en compte pour les modes qui en sont dotés. Ne devrait pas être adopté en masse, mais le choix sélectif des «meilleurs» régimes est possible. Il serait également judicieux de ne retenir aucun de ces modes en faveur du CMAC. Certains des MAC ISO 9797-1 sont largement standardisé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 : MAC basé sur le CBC-MAC, le mode est prouvé de manière sécurisée (jusqu'à la date d'anniversaire) en tant que PRF (VIL) (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érie est un problème dans certains domaines d'application et son utilisation avec un chiffrement à blocs 64 bits nécessiterait une recomposition occasionnelle. 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 blocs de chiffrement). Le mécanisme bénéficie de solides limites de sécurité prouvables, mais pas à partir d'hypothèses privilégiées. De multiples variantes étroitement liées dans la littérature compliquent la compréhension de ce qui est connu. Aucune attaque nuisible n'a jamais été suggérée. Largement standardisé et utilisé.

GMAC : un MAC non basé sur 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 elle n'achète que peu d'avantages. Attaques pratiques si les balises sont tronquées à ≤ 64 bits et que l'étendue du déchiffrement n'est pas surveillée et restreinte. Échec complet en cas de non réutilisation. L'utilisation est implicite de toute façon si GCM est adopté. Non recommandé pour une standardisation séparée.

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

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

GCM : un schéma AEAD non basé sur le système 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 d'implémentation. Bons résultats de sécurité prouvée en supposant une troncature minimale des balises. Attaques et limites de sécurité prouvables médiocres en présence d'une troncature importante des balises. Peut être utilisé comme un MAC non basé sur ce qui est alors appelé GMAC. Choix discutable pour autoriser des nonces autres que 96 bits. Recommander de restreindre les nonces à 96 bits et les balises à au moins 96 bits. Largement standardisé et utilisé.

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 retrouvez avec l'attaquant capable de prendre deux textes chiffrés et de dériver un texte en clair non chiffré combiné. La raison en est que le mode CTR transforme essentiellement un chiffrement de bloc en 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.
3. Il n'y a vraiment pas beaucoup de différence dans la difficulté de mise en œuvre des modes. Certains modes nécessitent uniquement le chiffrement par bloc pour fonctionner dans le sens du chiffrement. Cependant, la plupart des chiffrements de blocs, y compris AES, ne prennent 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 que vous ne voulez pas qu'un attaquant le sache.

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

Vous pouvez choisir en fonction de ce qui est largement disponible. J'avais la même question et voici les résultats de mes recherches limitées.

Limitations 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 de l'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 CBC offre une meilleure sécurité en changeant l'IV pour chaque bloc, il n'est pas applicable au contenu crypté accédé de manière aléatoire (comme un disque dur crypté).

Donc, utilisez CBC (et les autres modes séquentiels) pour les flux séquentiels et ECB pour l'accès aléatoire.