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


480

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.


22
"Ce n'est pas vraiment lié à la programmation mais c'est lié à l'algorithme." ∵ les algorithmes peuvent être représentés par des mathématiques. Programming la programmation informatique peut être présentée par les mathématiques. ∴ votre question concerne la programmation informatique.
Tyler Gillies

41
"Ce n'est pas vraiment lié à la programmation mais c'est lié à l'algorithme." ∵ les algorithmes peuvent être représentés par les mathématiques, et les marchés boursiers peuvent être représentés par les mathématiques, votre question concerne les marchés boursiers. / désolé pour le sarcasme, mais alors que la conclusion était très évidemment correcte, l'argument était manifestement faux
Shien

Cela dépend de la compréhension des relations auxquelles vous êtes abonné. Quelque chose ne doit pas nécessairement être uniquement lié à un concept ou à un autre.
Bryan Grace

Réponses:


326
  • 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.

65
CBC, OFB et CFB sont loin d'être identiques.
Jonathan Leffler

22
Le CTR se prête à la parallélisation, car vous pouvez diviser le message en blocs, chaque bloc ayant une plage de valeurs de compteur qui lui est associé, et crypter (ou décrypter) chaque bloc indépendamment. En revanche, CFB s'appuie sur la sortie du bloc précédent comme l'une des entrées sur le suivant, il est donc rigoureusement séquentiel et intrinsèquement non parallélisable. Similaire pour les autres modes mentionnés.
Jonathan Leffler

9
Même si vous chiffrez un seul bloc, ECB ne doit pas être utilisé si vous chiffrez ce bloc plusieurs fois (voire plusieurs fois) avec la même clé.
yfeldblum

23
... comment une réponse qui dit "CBC, OFB et CFB sont identiques" n'a-t-elle pas un seul downvote?
Michael Mrozek

30
GCM est très similaire à OCB (performances et autres propriétés), mais il n'est grevé d'aucun brevet, c'est donc le meilleur choix. Le seul inconvénient est le fait que l'implémentation est très complexe - mais vous n'avez pas à vous en soucier si vous utilisez une bibliothèque.
ntoskrnl

409

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.


214
"Si vous devez poser cette question, vous ne savez probablement pas assez sur la cryptographie pour implémenter un système sécurisé." - Vous avez raison, mais vous vous rendez compte que poser des questions, c'est comment les gens apprennent? Alors détendez-vous un peu.
Robert MacLean

70
@RobertMacLean Vrai, mais contrairement à beaucoup d'autres domaines de l'informatique, vous n'obtiendrez pas la bonne sécurité en essayant et en faisant une erreur. Alors qu'avec la conception web, l'évolutivité des applications, etc., vous pouvez activement vérifier vos besoins, les tests des aspects de sécurité vont de difficiles à impossibles. Malheureusement, c'est une leçon qui est rarement enseignée. La plupart des ressources vous expliquent comment fonctionne la cryptographie et non les multiples façons dont elle échoue dans la pratique sans que vous en soyez conscient. La seule issue est d'en savoir beaucoup sur le sujet. Et c'est le moral du post:
Perseids

8
Soit investir suffisamment de temps pour connaître à fond la cryptographie, soit l'éviter autant que possible et utiliser des abstractions fortes. Et dans le thème de l'apprentissage de la façon dont la cryptographie casse le premier paragraphe est beaucoup plus sur le sujet que la description des modes.
Perseids

33
Moins un: le titre de départ est faux; il devrait dire "Si vous posez cette question, vous allez dans la bonne direction, continuez et vous excellerez!"
Henrik

11
@FerminSilva: Vrai, mais un autre aspect de l'argument est qu'il est souvent plus facile d'utiliser des solutions vraies et testées que de copier-coller du code cryptographique. Par exemple, lorsque tout ce que vous voulez faire est de parler avec votre serveur à partir d'une application pour smartphone, il est beaucoup plus simple de configurer un proxy inverse Apache avec un certificat TLS Let's Encrypt et d'écrire https://your.serverpartout dans votre application, que d'inventer un protocole d'échange de clés et obtenir les bibliothèques de cryptographie des deux côtés pour fonctionner ensemble en douceur.
Perseids

36

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
Mode GCM: Étant donné que la plupart des SO ont peu ou pas de connaissance du chiffrement, n'utiliseront aucun mode correctement, n'utilisant généralement pas d'authentification et souvent en mode ECB, le mode GCM est probablement leur meilleur choix ici . Malheureusement, le manque d'implémentations de plate-forme, dans certains cas (iOS), pas de support fournisseur, mauvaise vérification dans de nombreux cas, manque de support matériel, il est actuellement problématique. Sinon, c'est bon pour les non-initiés en cryptage car il a une authentification intégrée et semble être l'avenir.
zaph

3
Mode CTR: je ne suis pas d'accord avec le mode CTR comme meilleur choix en raison de tant d'échecs dans la pratique, principalement la réutilisation IV. Même Microsoft a foiré cela au moins une ou deux fois.
zaph

1
Mode CBC: Probablement le mode le plus courant et le plus utilisé sur SO, ECB (qui ne devrait pas être utilisé) à l'exception. Les principaux défauts d'utilisation sont un IV non aléatoire, mais nous constatons des utilisations plus correctes avec un CSPRNG. Le remplissage des oracles, bien qu'il s'agisse d'un problème, est facilement résolu en ignorant simplement et en ne renvoyant pas les erreurs de remplissage. Certaines implémentations (par exemple Common Crypto) ne signalent pas les erreurs de remplissage d'une manière essentiellement efficace pour les éviter au niveau de l'API.
zaph

1
IMO CTR est pire parce que c'est un simple xor où CBC a une propagation d'un bloc à l'autre comme le font plusieurs autres modes. Cela peut sembler facile, mais il y a eu des défaillances majeures dans le code du marché de masse.
zaph

1
De la lecture du papier lié, il semble que seule la clé d'authentification est obtenue, pas la clé de chiffrement de la réutilisation nonce. Cela ne semble pas être l'affirmation dans les commentaires ici que la clé de cryptage est obtenue. Bien que l'obtention de la clé d'authentification permette de falsifier le message, elle ne permet pas de récupérer le message. Veuillez indiquer où je peux me tromper.
zaph

30
  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.

Pour prendre en charge votre point 1 (+1 pour ce btw): codinghorror.com/blog/archives/001267.html
Michael Stum

1
Vous ne devez pas démarrer le CTR avec un nombre aléatoire, car cela a une chance faible mais croissante de heurter une partie d'un message précédent. Au lieu de cela, incrémentez-le de façon monotone (cela peut signifier de vous rappeler où vous en êtes dans le stockage persistant), et ressaisissez si (quand) vous manquez de compteur.
caf

@Theran - point 2 - un nombre aléatoire différent pour chaque message? Non, je pense que ce n'est pas correct. J'ai l'impression que démarrer le compteur toujours à zéro est très bien. @caf, je pense que lorsque Theran dit "message", il ne signifie pas "bloquer". Bien sûr, le compteur est incrémenté pour chaque bloc d'un message particulier qui traverse le chiffrement. Ce que Theran semble dire, c'est que chaque message doit commencer par une valeur initiale différente pour le compteur. Et je pense que ce n'est pas correct.
Cheeso

1
re: point 3 - J'ai lu des articles qui disent, par exemple, que le mode CTR est plus petit à implémenter car le déchiffrement est la même transformation que le chiffrement. Donc la moitié du code. Mais comme je l'ai dit, pas pertinent sur une machine de classe serveur.
Cheeso

Oui, j'ai mal parlé. C'est l'IV / nonce qui devrait changer pour le mode CTR, mais qui est combiné avec le compteur avant le cryptage, j'ai donc tendance à le considérer comme un point de départ aléatoire pour le compteur. En ce qui concerne uniquement l'utilisation du chiffrement dans l'espace d'économie de direction de chiffrement, pour de nombreux chiffrements, vous n'avez qu'à inverser les sous-clés pour déchiffrer. AES est un peu volumineux pour le décryptage, mais ce n'est pas comme si vous pouviez l'implémenter sur un uC avec 128 octets de RAM de toute façon. Les sous-clés prennent plus de RAM que ça!
Theran

13

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 .


6
Cette réponse ne répond pas aux normes de qualité de Stackoverflow: supposez, dans votre réponse, que tous les liens externes seront morts, et résumez - sinon une copie pure et simple - les informations pertinentes, idéalement d'une manière conçue pour répondre au mieux à la question d'origine.
mirabilos

5
@mirabilos Venant près de 5 ans plus tard en référence à des normes et standards qui n'existaient pas à l'époque, vraiment? J'aime particulièrement parler des liens morts quand les deux ici sont en fait encore très vivants, et étant donné que le site en question le restera probablement encore 5 ans. Tant pis.
KTC

3
@mirabilos Vous pouvez venir corriger sans doute , mais votre plainte contre une réponse qui semblait avoir été fait il y a 5 ans où les normes étaient différentes ne sont pas applicables. Vous auriez dû juste admettre votre erreur. Même si ce n'est pas le cas et que vous indiquez plutôt qu'il doit être mis à jour ou modifié, ce n'est toujours pas obligatoire. La réponse suffisait de la façon dont c'était.
konsolebox

@KTC Sauf lorsque le gouvernement ferme ses portes et que le site est hors ligne. Votre réponse aurait pu être une information utile, mais pour le moment, elle manque complètement. Ainsi, le lecteur de cette question et de ses réponses se demande toujours ce qui a été mis à jour en 2014 (en raison d'une réponse incomplète) et l'état actuel (en raison de la fermeture par le gouvernement du site Web du NIST). Je serais ravi d'ajouter les informations manquantes, cependant ...
G DeMasters

11

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


1
ST Micro: EBC devrait être la BCE; FYI: par exemple, STM32L4A6 prend en charge AES 128 bits et 256 bits, avec ECB, CBC, CTR, GCM, ainsi que le code d'authentification de message Galois (GMAC) ou le mode de code d'authentification de message de chiffrement Les algorithmes de chaînage CMAC en mode code sont également pris en charge par le matériel.
Tom Kuschel

-3

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.


Ah, bien sûr. Le CBC XORs le bloc de texte chiffré précédent avec le bloc de texte en clair avant le chiffrement. Le premier bloc utilise l'IV. Donc, pour décrypter n'importe quel bloc, vous devez avoir décrypté avec succès tous les blocs précédents. ok, c'est une bonne idée.
Cheeso

6
Non, il vous suffit d'avoir accès au texte chiffré précédent , ce qui ne nécessite pas de décrypter les blocs précédents.
caf

Ah, ça veut dire que la CBC est très bien avec un accès aléatoire, n'est-ce pas?
Cheeso

4
@Cheeso: CBC est bien pour l'accès en lecture aléatoire, mais pas pour l'accès en écriture aléatoire. Utilisez CTR là-bas.
Paŭlo Ebermann,

3
@ PaŭloEbermann Pour un accès aléatoire, le CTR n'est pas une bonne idée, car il autorise des attaques sévères si un attaquant observe deux versions du texte chiffré. Utilisez plutôt XTS ou un blockcipher modifiable.
CodesInChaos
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.