Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Comment choisir un mode de cryptage AES (CBC ECB CTR OCB CFB)? Lesquels d’entre

Comment choisir un mode de cryptage AES (CBC ECB CTR OCB CFB)? Lesquels d’entre eux sont préférés dans quelles circonstances? J'aimerais voir la liste des critères d'évaluation pour les différents modes, et peut- être une discussion sur l'applicabilité de chaque critère. Par exemple, je pense que l’un des critères est la "taille du code" pour le chiffrement et le déchiffrement, ce qui est important pour les systèmes embarqués à microcode, tels que les cartes réseau 802.11. SI le code requis pour implémenter CBC est beaucoup plus petit que celui requis pour le CTR (je ne sais pas si c'est vrai, ce n'est qu'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 de toute façon CBC et CTR, alors ce critère n'est pas pertinent. Voyez ce que je veux dire par "liste de critères d'évaluation et applicabilité de chaque critère" ?? Ce n'est pas vraiment lié à la programmation mais à l'algorithme. • ECB ne doit pas être utilisé lors du cryptage de plusieurs blocs de données avec la même clé. • CBC, OFB et CFB sont similaires, mais OFB/CFB est préférable, car vous avez uniquement besoin d’un chiffrement et non d’un déchiffrement, ce qui peut économiser de l’espace. • Le CTR est utilisé si vous voulez une bonne parallélisation (vitesse) au lieu de CBC/OFB/CFB. • Le mode XTS est le plus courant si vous codez des données accessibles de manière aléatoire (comme un disque dur ou une RAM). • OCB est de loin le meilleur mode, car il permet le cryptage et l’authentification en un seul passage. Cependant, il existe des brevets aux États-Unis. La seule chose que vous devez vraiment savoir, c'est que la BCE ne doit pas être utilisée à moins que vous ne chiffriez qu'un seul bloc. XTS doit être utilisé si vous chiffrez des données consultées de manière aléatoire et non un flux. • Vous devez TOUJOURS utiliser des valeurs uniques IV à chaque fois que vous chiffrez, et elles devraient être aléatoires . Si vous ne pouvez pas garantir qu'ils sont aléatoires , utilisez OCB car il ne nécessite qu'un nonce , pas un IV , et il existe une différence nette. . Un nonce ne supprime pas la sécurité si les gens peuvent deviner le prochain, un IV peut causer ce problème. Permettez-moi d'illustrer mon propos: imaginez que vous construisez une application Web et que vous deviez 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 table de hachage avec les données de session. Mais alors vous devez faire face à cet état embêtant sur le serveur et si à un moment donné vous avez besoin de plus d’un serveur, les choses vont devenir compliquées. Vous avez donc l’idée de stocker les données de session dans un cookie côté client. Vous le chiffrerez bien sûr afin que l'utilisateur ne puisse pas lire et manipuler les données. Alors, quel mode devriez-vous utiliser? En venant ici, vous lisez la réponse en haut (désolé de vous avoir choisi myforwik). Le premier sujet couvert - la BCE - n’est pas fait pour vous, vous voulez chiffrer plus d’un bloc, le suivant - le CBC - semble bien et vous n’avez pas besoin du parallélisme du CTR, vous n’avez pas besoin d’un accès aléatoire; XTS et les brevets sont un PITA, donc pas d'OCB. En utilisant votre bibliothèque de chiffrement, vous vous rendez compte que vous avez besoin d'un certain rembourrage, car vous ne pouvez chiffrer que des multiples de la taille du bloc. Vous choisissez PKCS7 car il a été défini dans certaines normes de cryptographie sérieuses. Après avoir lu quelque part que CBC est prouvé que c'est sûr 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. Que faire si vous avez besoin de chiffrer 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 de l'émetteur). Si vous ne pouvez pas utiliser TLS, recherchez l'API de plus haut niveau que votre système peut offrir pour votre tâche et assurez-vous de bien comprendre les garanties qu'il offre et surtout ce qu'il ne garantit pas. Pour l'exemple ci-dessus, un cadre tel que Play offre installations de stockage côté client , les données stockées ne seront pas invalidées après un certain temps, cependant, et si vous modifiez l’état côté client, un attaquant peut restaurer un état antérieur sans que vous ne le remarquiez. S'il n'y a pas d'abstraction de haut niveau disponible, utilisez une bibliothèque de chiffrement de haut niveau. NaCl est un exemple frappant et une implémentation portable comportant 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 si vous n'utilisiez jamais 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 de manière spécifique, vous ne pouvez absolument pas vous renseigner de manière approfondie. Je recommande la lecture Ingénierie de cryptographie par Ferguson, Kohno et Schneier . S'il vous plaît ne vous trompez pas en croyant que vous pouvez construire un système sécurisé sans les antécédents nécessaires. 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é d'attaquer les attaques Oracle. La défense la plus simple consiste à authentifier chaque message avant le déchiffrement. Voir ci-dessous. • ECB chiffre chaque bloc de données indépendamment et le même bloc de texte en clair donnera le même bloc de texte chiffré. Jetez un coup d’œil à l’image Tux chiffrée de la BCE sur page ECB Wikipedia pour comprendre pourquoi il s’agit d’un problème grave. Je ne connais pas de cas d'utilisation où la BCE serait acceptable. • CBC a un IV et a donc besoin d’être aléatoire à chaque fois qu’un message est chiffré, modifier une partie du message nécessite de tout rechiffrer après le changement, les erreurs de transmission dans un bloc de texte crypté détruisent complètement le texte en clair et change le déchiffrement du bloc suivant, le déchiffrement peut être parallélisé/le chiffrement ne peut pas, le texte en clair est malléable dans une certaine mesure - cela peut être un problème . Modes de chiffrement par flux: Ces modes génèrent un flux de données pseudo-aléatoire qui peut ou non dépendre du texte en clair. De manière similaire aux flux de chiffrement généralement, le flux pseudo-aléatoire généré est traité par 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 de bourrage 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 à sa guise, 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 soit p2 = p1 d, comme p2 = c2 r = (c1 d) r = d (c1 r). De même, le ⊕ ⊕ ⊕ ⊕ même flux pseudo-aléatoire ne doit jamais être utilisé deux fois, car pour deux caractères chiffrés c1 = p1 r et c2 = p2 r, un attaquant peut calculer le xor ⊕ ⊕ des deux textes en clair comme suit: c1 c2 = p1 rp2 r = p1 p2. Cela ⊕ ⊕ ⊕ ⊕ signifie également que la modification du message nécessite un nouveau cryptage complet, si le message d'origine a pu être obtenu par un attaquant. Tous les modes de chiffrement Steam suivants ne nécessitent que l'opération de chiffrement du chiffrement par bloc. Par conséquent, cela peut économiser de l'espace (code machine ou code machine) dans des environnements extrêmement restreints. • CTR est simple, il crée un flux pseudo aléatoire 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 de sorte que le chevauchement est évité, l'utilisation du chiffrement des messages nonces est possible sans l'aléa par message, le déchiffrement et le chiffrement sont terminés, les erreurs de transmission ne concernent que les bits erronés 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 uploads/S4/comment-choisir-un-mode-aes 1 .pdf