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

lesquels 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 de 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 de micro-code, comme les adaptateurs de réseau 802.11. Si le code requis pour mettre en œuvre la SRC est beaucoup plus petit que cela requis pour le 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 la bibliothèque AES que j'utilise met en œuvre à la fois CBC et CTR de toute façon, 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 il est algorithme liés.

381
demandé sur Cheeso 2009-08-03 09:12:40

7 réponses

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

  • CBC, OFB et CFB sont similaires, cependant OFB/CFB est mieux parce que vous avez seulement besoin de chiffrement et non de déchiffrement, ce qui peut sauver de l'espace de code.

  • CTR est utilisé si vous voulez une bonne parallélisation (ie. speed), 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 mémoire vive).

  • POE est de loin le meilleur de la mode, comme il permet le chiffrement et l'authentification en un seul passage. Cependant, il existe des brevets aux etats-unis.

la seule chose que vous devez vraiment savoir est que BCE ne doit pas être utilisé à moins que vous êtes seulement encrypting 1 bloc. XTS doit être utilisé si vous cryptez au hasard accès aux données et non à un flux.

  • vous devez toujours utiliser unique IV 's chaque fois que vous cryptez, et ils devraient être aléatoire . Si vous ne pouvez pas garantir qu'ils sont aléatoire , utilisez OCB car il exige seulement un nonce , pas un IV , et il ya une différence nette. Un nonce ne chute pas en sécurité si les gens peuvent Devinez la prochaine, un IV peut causer ce problème.
270
répondu myforwik 2018-03-27 09:40:46

un mot d'introduction: Cette réponse était en partie une réponse à un grand nombre de questions que j'ai vu sous la balise [encryption] qui montrait des gens déployant un code totalement incertain. En m'adressant à ces programmeurs j'ai écrit la phrase d'ouverture suivante avec l'intention de les secouer assez pour repenser leur approche de la cryptographie, avant leur application est attaquée. Si vous êtes ici, dans le processus d'apprentissage, c'est génial! Nous avons besoin de plus de programmeurs avec des connaissances de base en cryptographie. Continuez à demander et Ajouter un muet " 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 sévère, alors laissez-moi illustrer mon point: Imaginez que vous construisez une application web et vous avez besoin de stocker des données de session. Vous pouvez assigner à chaque utilisateur un ID de session et stocker les données de session sur le serveur de hachage carte cartographie de l'ID de session à la session de données. 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 confuses. Vous avez donc l'idée de stocker les données de session dans un cookie côté client. Vous le crypterez bien sûr pour que l'utilisateur ne puisse pas lire et manipuler les données. Alors, quel mode doit-on utiliser? En venant ici vous lisez la réponse du haut (désolé de vous singulariser myforwik). Le premier concernait les - BCE - n'est pas pour vous, vous voulez crypter plus d'un bloc, le prochain - CBC - sonne bien et vous n'avez pas besoin du parallélisme du CTR, vous n'avez pas besoin d'accès aléatoire, donc pas de XTS et de brevets sont un PITA, donc pas de OCB. En utilisant votre bibliothèque crypto, vous réalisez que vous avez besoin de rembourrage parce que vous ne pouvez chiffrer des multiples de la taille du bloc. Vous choisissez PKCS7 parce qu'il a été défini dans certaines normes de cryptographie graves. Après avoir lu quelque part que CBC est provably secure s'il est utilisé avec une IV aléatoire et un cryptage de bloc sécurisé, vous reposez à l'aise même si vous stockez vos données sensibles du côté du client.

des années plus tard, après que votre service a atteint une taille importante, un spécialiste de la sécurité des TI vous contacte pour une divulgation responsable. Elle vous dit qu'elle peut décrypter tous vos cookies à l'aide d'un padding Oracle attack , parce que votre code produit une page d'erreur si le padding est en quelque sorte cassé.

ce n'est pas un scénario hypothétique: Microsoft avait ce défaut exact dans ASP.NET jusqu'à il y a quelques années.

le problème est qu'il ya beaucoup d'écueils en ce qui concerne la cryptographie et il est extrêmement facile de construire un système qui semble sûr pour le profane, mais est trivial à briser pour un attaquant averti.

Que faire si vous devez chiffrer des données

pour les connexions en direct 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 a à offrir pour votre tâche et assurez-vous que vous comprenez les garanties qu'il offre et plus important ce qu'il ne garantit pas. Pour l'exemple ci-dessus un cadre tel que Play offers client side storage facilities , il n'invalide pas les données stockées après un certain temps, cependant, et si vous avez changé 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 cryptographique de haut niveau. Un exemple important est NaCl et une implémentation portable avec de nombreuses Fixations de langage est Sodium . En utilisant une telle bibliothèque, vous n'avez pas à vous soucier des modes de cryptage, etc. mais il faut être encore plus prudent sur la détails d'utilisation qu'avec une abstraction de niveau supérieur, comme Ne jamais utiliser une nonce deux fois.

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 aucun moyen de vous éduquer complètement. Je recommande la lecture cryptographie Ingénierie par Ferguson, Kohno et Schneier . S'il vous plaît ne vous faites pas croire que vous pouvez construire un système sécurisé contexte nécessaire. La cryptographie est extrêmement subtile et il est presque impossible de tester la sécurité d'un système.

à des fins pédagogiques une comparaison des modes

que le Chiffrement:

  • Modes d'exiger remplissage : Comme dans l'exemple, le capitonnage peut généralement être dangereux parce qu'il ouvre la possibilité de capitonner des attaques oracle. La défense la plus facile est d'authentifier chaque message avant décryptage. Voir ci-dessous.
    • ECB crypte chaque bloc de données indépendamment et le même bloc en clair résultera dans le même bloc de chiffrement. Jetez un oeil à L'image de Smoking crypté de la BCE sur la ECB Wikipedia page 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 une IV et a donc besoin aléatoire chaque fois qu'un message est crypté, changer une partie du message nécessite de tout re-crypter après le changement, les erreurs de transmission dans un bloc de chiffrement détruisent complètement le plaintext et de changer le déchiffrement du bloc suivant, le déchiffrement peut être parallélisé / le cryptage ne peut pas, le plaintext est malléable à un certain degré - cela peut être un problème .
  • modes de chiffrement de Flux : ces modes génèrent un flux pseudo-aléatoire de données qui peut ou non dépendre du plaintext. De la même manière que les chiffreurs de flux en général, le flux pseudo-aléatoire généré est Xoré avec le plaintext pour générer le cryptogramme. Comme vous pouvez utiliser autant de morceaux du flux aléatoire que vous voulez vous n'avez pas besoin de rembourrage 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 de toute façon, il aime que pour un texte en clair p1, un texte chiffré en c1 et un pseudo-aléatoire flux r et l'attaquant peut choisir une différence d tels que le déchiffrement d'un cryptogramme c2=c1⊕d est p2 = p1⊕d, p2 = c2⊕r = (c1 ⊕ d) ⊕ r = d ⊕ (c1 ⊕ r). Aussi le même pseudo aléatoire de flux ne doit jamais être utilisé deux fois pour deux chiffrés c1=p1⊕r et c2=p2⊕r, un attaquant peut calculer le xor de deux plaintexts en c1⊕c2=p1⊕r⊕p2⊕r=p1⊕p2. Cela signifie également que la modification du message nécessite un réencryptage complet, si le le message original 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 en fonction du chiffrement, cela peut sauver de l'espace (code machine ou silicium) dans des environnements extrêmement restreints.
    • CTR est simple, il crée un flux pseudo-aléatoire qui est indépendant du plaintext, différents flux pseudo-aléatoires sont obtenus en comptant à partir de différents nonces / IVs qui sont multipliés par une longueur maximale de message de sorte que le chevauchement est empêché, en utilisant le cryptage de message nonces est possible sans aléatoire par message, le déchiffrement et le cryptage sont complétés parallélisable, les erreurs de transmission ne produisent que les mauvais bits et rien de plus
    • OFB crée aussi un flux pseudo-aléatoire indépendant du texte, différents flux pseudo-aléatoires sont obtenus en commençant par un nonce ou un nonce différent. random IV pour chaque message, ni le chiffrement ni le déchiffrement ne peuvent être mis en parallèle, comme avec CTR en utilisant le chiffrement de message nonces est possible sans aléatoire de message par message, comme avec les erreurs de transmission DE CTR seulement effet les mauvais bits et rien de plus
    • CFB ' s pseudo-random stream dépend du texte, un nonce différent ou aléatoire IV est nécessaire pour chaque message, comme avec CTR et OFB en utilisant nonces message cryptage est possible sans per le caractère aléatoire des messages, le déchiffrement est parallélisable / le chiffrement 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
  • Disk encryption modes " ces modes sont spécialisés pour chiffrer les données sous l'abstraction du système de fichiers. Pour des raisons d'efficacité de la modification de certaines données sur le disque ne doit exiger la réécriture d'un bloc de disque (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 de l'autre. Ne les utilisez pas pour rien, sauf au niveau du bloc de chiffrement de disque . Quelques membres: XEX, XTS, LRW.

cryptage authentifié:

pour prévenir les attaques oracle de remplissage et les changements au cryptogramme, on peut calculer un message authentication code (MAC) sur le texte chiffré et décrypter si elle n'a pas été falsifié. Ceci s'appelle encrypt-then-mac et devrait être préféré à tout autre ordre . Sauf dans de très rares cas d'utilisation, l'authenticité est aussi importante que la confidentialité (cette dernière étant le but du cryptage). Les schémas de cryptage authentifiés (avec les données associées (AEAD)) combinent les deux processus de cryptage et d'authentification en un mode de cryptage par bloc qui produit également une étiquette d'authentification en processus. Dans la plupart des cas, il en résulte une amélioration de la vitesse.

  • CCM est une combinaison simple de mode CTR et un CBC-MAC. En utilisant deux chiffrement de bloc par bloc il est très lent.
  • OCB est plus rapide mais grevé par des brevets. Pour les logiciels libres (comme dans la liberté) ou non-militaires le titulaire du brevet a accordé une licence libre , cependant.
  • GCM est une combinaison très rapide mais probablement complexe de mode CTR et GHASH, un MAC sur le champ de Galois avec 2^128 éléments. Son large usage dans les normes de réseau importantes comme TLS 1.2 se reflète dans une instruction spéciale Intel a introduit pour accélérer le calcul de GHASH.

recommandation:

compte tenu de l'importance de l'authentification, je recommande les deux modes de chiffrement par bloc suivants pour la plupart des cas d'utilisation (sauf à des fins de chiffrement sur disque): si les données sont authentifiées par une signature asymétrique, utiliser CBC, sinon utiliser GCM.

327
répondu Perseids 2018-09-28 06:22:57
  1. tout sauf BCE.
  2. si vous utilisez CTR, il est impératif que vous utilisiez un IV différent pour chaque message, sinon vous finissez avec l'attaquant capable de prendre deux textes chiffrés et de dériver un texte simple non chiffré combiné. La raison en est que le mode CTR transforme essentiellement un chiffrement de bloc en un chiffrement de flux, et la première règle des chiffrements de flux est de ne jamais utiliser la même clé+IV deux fois.
  3. il n'y a vraiment pas beaucoup de différence dans la façon les modes sont difficiles à mettre en œuvre. Certains modes n'exigent que le chiffrement par bloc pour fonctionner dans le sens du chiffrement. Cependant, la plupart des blocs de chiffrement, y compris AES, ne prennent 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 IVs 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.
27
répondu Theran 2009-08-04 03:40:46

Une analyse formelle qui a été fait par Phil Rogaway en 2011, ici . La Section 1.6 donne un résumé que je transcris ici, en ajoutant mon propre accent en gras (si vous êtes impatient, alors sa recommandation est d'utiliser le mode CTR, mais je suggère que vous lisez mes paragraphes sur l'intégrité des messages par rapport au cryptage ci-dessous).

notez que la plupart de ceux-ci exigent que L'IV soit aléatoire, ce qui signifie non prévisible et devrait donc être généré avec sécurité cryptographique. Toutefois, certains n'exigent qu'un" nonce", qui n'exige pas ce bien, mais seulement qu'il ne soit pas réutilisé. Par conséquent, les conceptions qui reposent sur une nonce sont moins sujettes aux erreurs que les conceptions qui ne le sont pas (et croyez-moi, j'ai vu de nombreux cas où la SRC n'est pas mise en œuvre avec une sélection IV appropriée). Donc, vous verrez que J'ai ajouté gras lorsque Rogaway dit quelque chose comme "la confidentialité n'est pas atteinte lorsque L'IV est une nonce", cela signifie que si vous choisissez votre IV cryptographique sécurisé (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 un IV pour l'un de ces modes.

de plus, il est important de comprendre la différence entre l'intégrité du message et le chiffrement. Le cryptage cache des données, mais un attaquant pourrait ê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 le message intégrité. Alors que le développeur dira "mais les données modifiées reviendront comme des déchets après déchiffrement", un bon ingénieur de sécurité découvrira la probabilité que les déchets causent un comportement défavorable dans le logiciel, et 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. Comprendre ce que vous avez besoin.

je dois dire que bien que GCM a à la fois et l'intégrité du message, c'est un design très fragile: Si vous réutilisez une IV, vous êtes fichu -- l'attaquant peut récupérer votre clé. D'autres designs sont moins fragiles, donc personnellement, je crains de recommander GCM basé sur la quantité de code de cryptage pauvre que j'ai vu dans la pratique.

si vous avez besoin des deux, intégrité du message 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, c'est chiffrez d'abord , puis MAC le contenu crypté , pas l'inverse. De plus, L'IV doit faire partie du calcul de la CMA.

Je ne suis pas au courant des questions de propriété intellectuelle.

maintenant à la bonne chose du Professeur Rogaway:

les chiffrements par blocs modes de chiffrement, mais pas de l'intégrité des messages

ECB : un blockcipher, le mode émet des messages qui sont un multiple de n bits par enciphering séparément chaque N-bit pièce. les propriétés de sécurité sont faibles , la méthode fuyant l'égalité des blocs à travers les deux positions de bloc et le temps. 151950920 "ECB should not be regarded as a" general-purpose "confidentiality mode .

CBC : un schéma de cryptage basé sur IV, le mode est sécurisé comme un schéma de cryptage probabiliste, d'atteindre l'indistinguabilité à partir de bits aléatoires, en supposant une IV aléatoire. la confidentialité n'est pas assurée si L'IV est simplement un nonce , ni s'il s'agit d'un nonce acquis sous la même clé utilisée par le schéma, comme la norme suggère à tort de le faire. Chiffrés sont très malléable. Pas de sécurité d'attaque chiffrée (CCA) choisie. La confidentialité est perdue en présence d'un oracle correct-padding pour de nombreuses méthodes de padding. Cryptage inefficace de série par nature. Largement utilisées, les propriétés de sécurité du mode, qui ne concernent que la protection de la vie privée, donnent lieu à des abus fréquents. 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.

CFB : un système de cryptage basé sur IV, le mode est sécurisé comme un probabiliste schéma de cryptage, atteinte de l'indistinguabilité à partir de bits aléatoires, en supposant une IV aléatoire. la confidentialité n'est pas assurée si L'IV est prévisible , ni si elle est faite par un non-initié sous la même clé utilisée par le schéma, comme la norme suggère à tort de le faire. Chiffrés sont malléables. Pas D'ACC-security. Cryptage inefficace de série par nature. Régime dépend d'un paramètre s, 1 ≤ s ≤ n, généralement s = 1 ou s = 8. Inefficace pour en avoir besoin appel de blockcipher pour traiter seulement les bits s. Le mode réalise une propriété intéressante d ' "auto-synchronisation"; l'insertion ou la suppression de n'importe quel nombre de caractères S-bit dans le cryptogramme ne perturbe que temporairement le décryptage correct.

OFB : un schéma de cryptage basé sur IV, le mode est sécurisé comme un schéma de cryptage probabiliste, en obtenant l'indistinguabilité à partir de bits aléatoires, en supposant un IV aléatoire. La confidentialité n'est pas assurée si L'IV est un nonce, bien qu'une séquence fixe de IVs (par exemple, un compteur) fonctionne très bien. Chiffrés sont très malléable. Aucune déduction de sécurité. Cryptage et décryptage inefficaces d'être en série. Nativement crypte des chaînes de bits de longueur (sans rembourrage). Je ne peux identifier aucun avantage important par rapport au mode CTR.

CTR : un schéma de cryptage basé sur IV, le mode permet d'atteindre l'indistinguabilité à partir de bits aléatoires en supposant une nonce IV. Comme un nonce-based scheme, le mode peut également être utilisé comme un schéma de cryptage probabiliste, avec un IV aléatoire. Échec complet de la vie privée si un nonce est réutilisé sur le cryptage ou le déchiffrement. La parallélisation du mode le rend souvent plus rapide, dans certains cas, que dans d'autres modes de confidentialité. Un bloc de construction important pour les systèmes de cryptage authentifiés. dans l'ensemble, habituellement la meilleure et la plus moderne façon d'obtenir le chiffrement de la vie privée seulement.

XTS : un schéma de cryptage basé sur IV, le mode fonctionne en appliquant un blockcipher tweakable (secure as a strong-PRP) à chaque morceau de N-bit. 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 de crypter les données sur un périphérique de stockage structuré en blocs. L'étroite largeur de la PRP sous-jacente et le mauvais traitement des blocs finaux fractionnels sont des problèmes. Plus efficace mais moins désirable qu'un (grand-bloc) PRP-secure blockcipher serait.

MACs (de l'intégrité des messages, mais pas de chiffrement)

ALG1–6 : UNE collection de Mac, toutes basées sur le CBC-MAC. De trop nombreux régimes. Certains sont protégés de façon prouvable en tant que PRFs VIL, d'autres en tant que PRFs FIL, et certains n'ont aucune sécurité prouvable. Certains de ces stratagèmes admettent des attaques dommageables. Certains des modes sont datés. Clé de séparation n'est pas suffisamment fréquenté pour les modes qui ont. Devrait ne pas être adopté en masse, mais le choix sélectif des "meilleurs" régimes est possible. Il serait également bien de n'adopter aucun de ces modes, en faveur de la CMAC. Certains des MACs 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].

CCMC : UN MAC basé sur le CBC-MAC, la mode est à l'abri (jusqu'à l'anniversaire lié) comme un (VIL) PRF (en supposant que le blockcipher sous-jacent est une bonne PRP). Essentiellement minimal overhead for a CBCCMAC-based scheme. Nature de série inhérente un problème dans certains domaines d'application,et l'utilisation avec un blockcipher 64 bits nécessiterait un réimpression occasionnel. Plus propre que la collection de MACs 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 cryptographique soient elles-mêmes basées sur des blockciphers). Mécanisme jouit de solides limites de sécurité prouvables, mais pas à partir 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 standardisé et utilisé.

GMAC : un MAC nonce-basé qui est un cas spécial de GCM. Hérite de bon nombre des bonnes et mauvaises caractéristiques des mcg. Mais nonce-exigence est inutile pour un MAC, et ici, il achète peu d'avantages. Attaques pratiques si les étiquettes sont tronquées à ≤ 64 bits et l'étendue du déchiffrement n'est pas surveillée et restreinte. Échec complet sur nonce de réutilisation. L'utilisation est de toute façon implicite si la MCG est adoptée. Il n'est pas recommandé de procéder à une normalisation distincte.

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

CCM : un schéma AEAD basé sur la nonce qui combine le cryptage en mode CTR et le cryptage brut CBC-MAC. Intrinsèquement série, limitation de la vitesse dans certains contextes. Sécurité prouvable, avec de bonnes limites, en supposant que le blockcipher sous-jacent est un bon PRP. Construction impie qui fait le travail de façon évidente. Plus simple à mettre en œuvre que GCM. Peut être utilisé comme un MAC à base de nonce. Largement standardisé et utilisé.

GCM : un schéma AEAD basé sur la nonce qui combine le cryptage en mode CTR et une fonction de hachage universel basée sur la GF(2128). Bonnes caractéristiques d'efficacité pour une mise en œuvre environnement. Bons résultats sûrs et prouvables en supposant une troncature minimale des étiquettes. Attaques et de mauvaises limites de sécurité prouvables en présence d'une troncature importante de l'étiquette. Peut être utilisé comme un MAC à base de nonce, 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 standardisé et utilisé.

24
répondu TheGreatContini 2017-04-25 05:47:05

avez - vous commencé par lire les informations à ce sujet sur Wikipedia - Block cipher modes de fonctionnement ? Ensuite, suivez le lien de référence sur Wikipedia à NIST: recommandation pour les modes de fonctionnement de chiffrement de bloc .

12
répondu KTC 2016-10-03 13:41:35

vous pourriez vouloir 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.

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

Open source limitations

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

11
répondu Mark Lakata 2018-03-21 17:39:09

je sais un aspect: bien que CBC donne une meilleure sécurité en changeant le IV pour chaque bloc, il n'est pas applicable au contenu crypté à accès aléatoire (comme un disque dur crypté).

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

-3
répondu chris166 2009-08-03 05:34:01