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