Ciphers par bloc | Modes de fonctionnement | Alison
Loading
Notes d'étude
Study Reminders
Support
Text Version

Modes d'exploitation du chiffrement par bloc

Set your study reminders

We will email you at these times to remind you to study.
  • Monday

    -

    7am

    +

    Tuesday

    -

    7am

    +

    Wednesday

    -

    7am

    +

    Thursday

    -

    7am

    +

    Friday

    -

    7am

    +

    Saturday

    -

    7am

    +

    Sunday

    -

    7am

    +

Fondations de CryptographyProf. Dr. Ashish Choudhury (Former) Infosys Foundation Career Development Chair ProfessorIndian Institute of Technology-BangaloreLecture-16Modes of Operations of Block Ciphers Part IHello, everyone, welcome to lecture 15. Il s'agit de la première partie des modes de fonctionnement des algorithmes de chiffrement par bloc (voir la diapositive: 00 :34). La feuille de route pour cette conférence est la suivante. Nous verrons comment assurer l'efficacité des algorithmes de chiffrement CPA via 2 modes d'opérations, à savoir le mode de la BCE et le mode CBC ; les autres modes d'opérations que nous allons voir dans le module suivant. (Référez-vous à la diapositive: 00 :49) Donc, juste pour rappeler, lors de la dernière conférence, nous avions vu un processus de cryptage sécurisé du candidat CPA pour le chiffrement?-des messages-bit et les deux inconvénients que nous avons identifiés dans ce processus de chiffrement sont que la taille du texte de chiffrement est grande par rapport au texte en clair. Plus précisément si? Et l sont identiques, alors le texte chiffré est le double de la taille du texte en clair. Et le deuxième inconvénient est que chaque instance du processus de chiffrement nécessite un caractère aléatoire frais de petits bits (voir la diapositive: 01 :21). Cela nous conduit à ce que nous appelons les modes d'opérations de chiffrement par bloc. Et en gros, l'objectif ici est le suivant. Imaginez que vous avez une fonction à clé qui pourrait être soit une fonction pseudo-aléatoire, soit une permutation pseudo-aléatoire ou une forte permutation pseudo-aléatoire. Et la construction avec laquelle vous êtes donné est une fonction de préservation de longueur. Namely le bloc sizeand la taille de sortie sont les mêmes, disons?. Et pour simplifier, on suppose ça? =?, mais il peut s'agir de n'importe quelle fonction polynomiale de votre paramètre de sécurité. Vous avez donc une description d'une telle fonction?. Et l'objectif ici est le suivant. Nous avons maintenant un grand message composé de plusieurs blocs de bits. À savoir, imaginez que vous avez le nombre de blocs. Et notre objectif est de trouver un processus de cryptage où je peux chiffrer de tels messages de grande taille, de sorte que le processus de cryptage devrait être sécurisé par CPA. De plus, le processus de chiffrement de résultat devrait avoir un taux d'utilisation aléatoire aussi minimal que possible. L'expansion du texte devrait être aussi minimale que possible et il devrait y avoir un soutien pour le parallélisme. Cela signifie que s'il y a une portée où je peux chiffrer plusieurs blocs en parallèle, étant donné que j'ai plusieurs processus informatiques disponibles avec moi, alors le processus de chiffrement devrait fournir ce soutien. Et surtout, la sécurité globale de mon processus de chiffrement devrait dépendre de l'hypothèse de sécurité minimale de la fonction?. Cela signifie qu'il devrait suffire si ma fonction? n'est qu'une fonction pseudo-aléatoire. C'est notre objectif global. (Référez-vous à la diapositive: 03 :09) Alors, voyons l'une des façons de le faire. Et puis nous analyserons les propriétés suivantes que j'ai énumérées ici sont réalisées et qui ne sont pas atteintes. Ce mode est donc appelé le livre de code électronique, ou la BCE en bref. Et pour le démontrer, imaginez que j'ai un message composé de 3 blocs d'? -bits. Donc, la façon dont je vais chiffrer en mode ECB est la suivante: depuis que j'ai 3 blocs d'? bits, chacun d'entre eux va être crypté à l'aide de la même clé?. Alors je nourris la même? à 3 appels de ma fonction sous-jacente?, donc c'est la clé. Et bloc d'entrée pour les appels sous-jacents de la fonction? Sont en fait les blocs du message, cela signifie? 1 va comme il est, comme le bloc pour le premier appel. De même, pour le second appel,? 2 goesas it is, as the block input. Et dans le troisième appel,? 3sert comme l'entrée de bloc et la sortie résultante? 1,? 2,? 3est essentiellement ce qui est mon code de chiffrement. Cela signifie que le texte de chiffrement sera la concaténation de? 1,? 2,? 3. Donc, en général, le processus de cryptage ici est l'évaluation de la fonction clé?? Sur l'entrée bloc??. Et le processus de décryptage ici est fondamentalement l'inverse de la fonction clé?? Sous la même clé?, sur le bloc? ?hciphertext??, pour récupérer le bloc? ?h en texte clair. Cela veut dire, vous pouvez voir que dans ce cas ma fonction?? Doit être une permutation pseudo-aléatoire à clé, elle ne devrait pas être une fonction de plusieurs à une autre, sinon le déchiffrement deviendra ambigu. Une autre propriété intéressante ici est que ma taille de texte de chiffrement est exactement la même que la taille du message. Donc, si j'ai 3 blocs d'? -bits chacun, alors j'ai un texte chiffré composé de 3 blocs d'? -bits each.De plus, ce processus de chiffrement ou le mode de chiffrement supporte le parallélisme. Cela signifie, si j'ai 3 processeurs de calcul disponibles avec moi, alors? 1 peut être calculé indépendamment de? 2, qui peut être calculé indépendamment de? 3. Cela signifie, en même temps, en parallèle, je peux calculer? 1,? 2,? 3, les mêmes retenues pour le cryptage et pour la description.Maintenant, répondons à la partie la plus importante, que ce mode de la BCE soit CPA-sécurisé ou pas? Et la réponse est absolument non, parce que comme vous pouvez le voir ici, que ce mode de la BCE est un système de cryptage déterministe. Cela signifie que partout où les blocs de messages se répand, et si je crypte ces blocs de messages répétés sous la même clé?, je vais voir le même bloc de texte, ce qui est fondamentalement contraire au principe selon lequel pour atteindre la sécurité de l'ACP, mon processus de cryptage devrait être randomisé. Étant donné que ce processus de cryptage est déterministe, je ne peux pas prétendre que ce processus de cryptage est sécurisé par l'ACP. (Référez-vous à la diapositive: 05 :59) Pour vous donner une idée de l'insécurité que peut avoir ce mode de fonctionnement de la BCE, voyons un exemple pratique. Par conséquent, supposons que je veuille chiffrer une image en utilisant le mode ECB. Et comme une image est fondamentalement une collection de pixels, ce que je peux faire c'est que je peux imaginer un groupe de pixels dans mon image comme un bloc et le nourrir en tant que bloc de messages lors de l'appel du mode ECB. Alors, considérez l'image en noir et blanc (la première image ci-dessus), que je veux chiffrer. Et si je le chiffre à l'aide du mode ECB, l'image chiffrée ressemblera à la deuxième image ci-dessus. Et comme vous pouvez le voir à partir de l'image cryptée, vous avez un motif absolument clair qui est disponible dans l'image cryptée. Et la raison en est que, quel que soit l'endroit où vous avez un groupe de pixels noirs, il produira toujours le même type de texte chiffré et où vous avez un groupe de pixels blancs qui produira toujours le même type de texte. Et ce motif sera clairement visible dans l'image cryptée. Et si j'envoie ce genre d'image chiffrée sur le canal non sécurisé intercepté par un adversaire, l'adversaire peut facilement découvrir ce qui est exactement l'image sous-jacente. Idéalement, si je veux chiffrer l'image en noir et blanc, en utilisant un certain mode sécurisé, il devrait produire une image chiffrée, similaire à la troisième image ci-dessus, où il n'y a absolument aucun motif disponible dans l'image chiffrée, qu'il s'agisse d'un pixel blanc que je crypte ou si c'est un pixel noir, je crypte. Nous verrons plus loin comment exactement ces modes de sécurité ressemblent. Mais pour l'instant, si je me concentre sur le mode de la BCE, c'est complètement inutile. La leçon que nous tirons de cet exemple est qu'un algorithme de chiffrement par bloc, à savoir la fonction??, ne doit pas être utilisé directement pour chiffrer un message. Et si vous voyez la syntaxe du mode ECB, ce que nous faions réellement, nous faions cette erreur, nous chiffrons directement le message à l'aide des appels de??, où la même clé a été utilisée dans tous les appels, donc nous ne devrions pas faire ça. Et si vous vous souvenez du système sécurisé de notre candidat CPA, nous n'avons jamais chiffré le message directement en l'alimentant à la fonction??. En fait, nous avons donné une entrée aléatoire à la fonction??, générer l'extrusion, qui a été XORed avec le message, pour produire le texte chiffré réel. C'est donc le mode de la BCE, et il est clair qu'il n'est pas sécurisé par l'ACP. (Référez-vous à la diapositive: 08 :10) Passons maintenant au deuxième mode, que nous appelons aussi le chaînage de bloc de texte, ou le mode CBC. Et ce mode a été utilisé dans certaines versions plus anciennes du vrai protocole TLS. Encore une fois, pour la démonstration, supposons que vous avez 3 blocs, chacun comprenant? -bytes. Donc la façon dont nous chiffrons ici est la suivante. Nous choisissons d'abord un hasard??, que nous dénoterons comme? 0 et qui fera partie du texte. Et la longueur de? 0sera la même que celle de la taille de bloc de ma fonction sous-jacente??, c'est-à-dire? -octets. Et maintenant je vais chiffrer 3 blocs individuels en invoquant 3 appels de ma fonction??, avec la même clé?. Le premier appel de la fonction?? Est essentiellement sur la XOR du message? 1 avec le??, servant de bloc. J'ai obtenu la sortie? 1 et la raison pour laquelle ce mode est appelé comme le chaînage de texte de chiffrement est que nous allons maintenant faire une sorte de processus chaînage. Le bloc de chiffrement? 1 que j'ai obtenu maintenant, il va être enchaîné et XORed avec le deuxième bloc de mon message. Et le XOR qui en résulte, sert d'entrée de bloc pour mon deuxième appel de ma fonction?? Et me donne la sortie? 2. Et maintenant cela sert de chaîne pour le prochain bloc du message, XORed avec le troisième bloc, alimenté comme un bloc pour le troisième appel de ma fonction? ?.Et j'arrête avec le bloc de chiffrement 3, et mon chiffrement global sera? 0 concaténé avec? 1,? 2,? 3. Donc en général, si je veux faire le chiffrement du bloc? ?h, alors c'est essentiellement l'évaluation de la fonction clé de??, où l'entrée de bloc est XOR du bloc de messages courant et du bloc de chiffrement précédent. C'est pourquoi le nom du texte du code de chiffrement est chaînon. Et le hasard?? Que nous choisissons ici au début du chiffrement doit faire partie du texte de chiffrement. Si je veux déchiffrer? ?hciphertext block, la façon dont je fais c'est que je calcule l'inverse de la fonction saisie?? Par rapport à la même clé. Et si par exemple, si je veux décrypter? 3, je calcule l'inverse de? 3 par rapport à la fonction??, et si je perverti, j'obtiens essentiellement la XOR de? 3 et? 2. Et pour annuler l'effet de? 2, je dois juste prendre la XOR de? 2 avec la sortie récupére. C'est donc ce qui est le décryptage générique du bloc? ?h. Ça veut dire ma fonction?? Devrait être une permutation clé si je veux sans ambiguïté faire le décryptage part.Maintenant, quelle est la taille globale du chiffrage ici, bien le nombre de blocs dans le texte chiffré est exactement le même que le nombre de blocs dans le message plus un bloc supplémentaire pour le?? Partie. Cela signifie en termes d'expansion des messages, c'est un minimum que vous pouvez imaginer. Cette situation est nettement meilleure par rapport au système de sécurité CPA candidat, basé sur le PRF, que nous avions vu lors de la dernière conférence. Cependant, l'un des inconvénients de ce mode est qu'il ne prend pas en charge le parallélisme. Cela signifie que le chiffrement du deuxième bloc ne peut se produire que lorsque le chiffrement du premier bloc s'est produit. Plus important encore, ce processus de cryptage est un processus de cryptage aléatoire, parce que chaque fois que j'ai un nouveau message, le?? Sera choisi au hasard, ce qui déclenche le hasard dans tout le processus de chaînage. En fait, nous pouvons prouver formellement que si la fonction sous-jacente?? Est un PRP sécurisé selon la définition de la distinction, alors ce mode de fonctionnement est en effet protégé par CPA. Et vous pouvez voir n'importe laquelle des références, à savoir le livre de Katz-Lindell ou Boneh et al, pour la preuve réelle. Je ne vais pas vous donner la preuve réelle ici. (Référez-vous à la diapositive: 12 :16) Maintenant, voyons un aspect intéressant du mode CBC. Ainsi, la façon dont j'ai discuté du mode CBC jusqu'à présent est que j'ai supposé que le nombre de blocs dans le message est essentiellement un multiple de la longueur de bloc de votre sous-jacent??. Alors imaginez que la longueur de bloc de la fonction sous-jacente?? Est? -octets. Il peut donc y avoir 2 cas par rapport au message sous-jacent, que je veux chiffrer. Si le nombre d'octets dans mon message sous-jacent que je veux chiffrer est déjà un multiple de? -octets, alors je peux diviser mon message en plusieurs blocs de? -octets et faire le mode de chiffrement CBC comme je l'ai discuté. (Voir Heure de la diapositive: 13 :01) Mais si mon message sous-jacent n'est pas un multiple de? -octets. La longueur du message n'est pas un multiple de grand nombre d'octets. Cela signifie que je dois maintenant faire une sorte de remplissage avant de chiffrer mon message. Parce que si je ne fais pas le rembourrage, je ne peux pas appliquer le mode de cryptage CBC. Parce que même si je divise mon message en blocs de? -octets, le dernier bloc ne sera pas de longueur? -bytes. Et donc, je ne peux pas appliquer une instance de ma fonction sous-jacente??. Donc ce que je vais faire ici, c'est que je vais discuter du type de rembourrage que nous devons utiliser et appliquer au message myjacent avant de faire le mode de cryptage CBC. Mon mécanisme de remplissage doit donc être inversé. Et il doit être sans ambiguïté. Alors permettez-moi de parler de l'un des plus importants mécanismes de padding que nous appelons PKCS version 5 padding, et l'idée ici est laissée? Indiquer le nombre d'octets que j'ai besoin d'ajouter dans le dernier bloc de mon message?. Donc, le message de remplissage global, sa longueur devient un multiple de? -bytes. Donc, une fois que j'ai identifié la valeur de la petite?, ce que je fais, c'est que j'ajoute? Nombre d'octets dans le dernier bloc, et chacun d'eux représente la valeur entière?. Une fois que je le fais, la longueur de mon message de remplissage sera un multiple de? -octets, que je peux diviser en plusieurs blocs de? -octets. Et maintenant je peux faire mon mode habituel de cryptage CBC. Comment je vais faire le décryptage. Eh bien, à la fin du déchiffrement, le récepteur essaiera de déchiffrer le dernier bloc de chiffrement selon le mode habituel de CBC. Et puis ce qu'il va faire, c'est qu'une fois qu'il aura récupéré le dernier bloc, c'est-à-dire? 2 ′ dans cet exemple, il va lire la dernière valeur d'octet. Et à partir de cette dernière valeur d'octet, ça va apprendre la valeur de?. Et il verra si le dernier a récupéré? Octets représente la valeur d'octet?. Si tel est le cas, défaites simplement ces derniers? octets et le reste sera le message réel qui a été chiffré et communiqué par l'expéditeur. D'autre part, si le dernier? Octets pour ne pas représenter la valeur entière?, c'est-à-dire qu'une erreur s'est produite lors de l'envoi du message chiffré et que, par conséquent, le récepteur va générer une erreur de sortie. Maintenant, sur la base du processus de chiffrement et du processus de déchiffrement, vous vous demandez peut-être ce qui doit être la plage?? Cela signifie combien d'octets doivent être ajoutés, de sorte que mon message de remplissage, sa longueur devient un multiple de gros? -octets. Et l'intuition dit que la gamme de? Doit de 0 à? − 1. 0 parce que je pourrais avoir un message dont la longueur est déjà un multiple de? -octets, et? − 1 parce que je pourrais avoir un message, où en fait j'ai besoin d'ajouter? − 1 octets. Mais il s'avère que la gamme de? Ne peut pas être de 0 à? − 1, car cela ne va pas conduire à un remplissage inversé. Etant donné que cela peut entraîner une ambiguïté, que le remplissage s'est produit ou que le remplissage n'a pas eu lieu. Le cas problématique est? = 0, un récepteur ne peut pas distinguer si un remplissage a eu lieu ou non lorsqu'il est déchiffré. C'est pourquoi quand? = 0, en fait nous faisons? =?. Cela signifie que si à l'expéditeur ’ se termine, aucun remplissage n'est requis, alors pour indiquer sans ambiguïté le récepteur, l'expéditeur va ajouter un bloc complet de? -octets, chacun d'eux représentant la valeur entière?. C'est une indication pour le récepteur qu'il n'y a pas eu de remplissage, et que tout le dernier bloc doit être retiré. Donc, la gamme de? N'est pas 0 à? − 1, mais en fait 1 à?. C'est ainsi que nous pouvons faire un cryptage de messages longs arbitraires en utilisant le mode CBC de cryptage en faisant ce padding. (Référez-vous à la diapositive: 17 :09) Maintenant, permettez-moi de parler aussi d'un aspect très intéressant du mode CBC, ce que nous appelons une variante avec état du mode CBC. Si vous voyez le mode de définition de la CBC, si nous avons 2 messages différents, par exemple? Et? ′ en séquence, l'une après l'autre, bien sûr de différentes longueurs, par exemple, message? Composé de 3 blocs, suivi d'un autre message? ′ composé de 2 blocs, alors c'est la façon idéale que l'expéditeur ait chiffré? Et? ′. Pour le cryptage?, l'expéditeur aurait dû choisir un peu indépendant??, désigné comme? ?1. Et aurait dû faire le chaînage. Et puis s'il y a un autre message, disons un message de suivi? ′, l'expéditeur devrait idéalement choisir un autre message indépendant??, par exemple? ?2 et aurait dû faire le mode de cryptage CBC. Mais un implémenteur intelligent peut imaginer que si l'expéditeur et le récepteur sont synchronisés, et si le même émetteur et le même récepteur vont faire une séquence de plusieurs communications chiffrées, alors pourquoi ne pas maintenir l'état?Et ce que je veux dire par le maintien de l'état ici est que, pourquoi ne pouvons-nous pas conserver le dernier bloc de texte chiffré du dernier message entre l'expéditeur et le récepteur et l'utiliser comme le?? Pour le message suivant que l'expéditeur va chiffrer et communiquer au destinataire. C'est ce que je veux dire par le maintien de l'état ici. Et en fait, si nous le faisons, il y a un avantage que nous obtenons ici. Tout d'abord, pour le prochain message, à savoir? ′, que l'expéditeur veut communiquer,?? N'ont pas besoin d'être choisis ; l'expéditeur et le destinataire sauront que puisqu'ils utilisent une variante avec état,? 3 va servir comme??. Cela permet d'économiser le caractère aléatoire. Et elle fournit aussi des avantages en termes de bande passante, parce que maintenant? 3 n'a pas besoin d'être à nouveau communiqué quand? ′ est chiffré. Il sera connu de toute façon pour le récepteur que le déchiffrement doit se produire à l'égard de? 3, donc?-les octets n'ont pas besoin d'être communiqués parce que la taille de? 3 aurait été? -octets. Donc de cette façon, nous économisons en fait la bande passante. Et maintenant vous vous demandez peut-être si la variante avec état est en effet CPA-sécurisée ou pas et intuitivement, vous pourriez penser que la variante avec état devrait être CPA-secure. Parce que si en fait l'expéditeur aurait un message plus grand?, qui est une concaténation de? Et? ′, alors c'est la façon dont l'expéditeur et le destinataire auraient réellement effectué le mode CBC de chiffrement et de déchiffrement:? 3 aurait servi comme??? Et il aurait été utilisé pour chiffrer le bloc de messages? 4 et ainsi de plus, c'est l'intuition. Mais sur la base de l'intuition, nous ne pouvons pas dire formellement si un système modifié est sûr ou non. (Référez-vous à la diapositive: 19 :51) Ce que nous allons maintenant démontrer, c'est que la variante avec état n'est absolument pas CPA-sécurisée car il y a une attaque ici. L'attaque provient essentiellement du fait que dans la variante avec état, l'adversaire est déjà au courant du?? Qui va être utilisé pour le futur message, ce qui n'est pas le cas, si l'expéditeur aurait chiffré un long message, un seul message composé des deux? Et? ′. Dans ce cas, l'adversaire ne serait pas au courant du fait qu'il sera utilisé? 4. Mais dans le cas où? Et? ′ sont traités comme 2 messages différents, à savoir une séquence de messages, l'adversaire est déjà au courant de l'??, qui va être utilisé pour effectuer la partie chaînage pour le chiffrement du message? ′. Cela signifie, dans un certain sens, qu'il a le contrôle sur le hasard, que l'adversaire peut exploiter. Et en demandant des requêtes d'oracle de chiffrement, il peut identifier complètement le bloc de messages qu'il veut identifier. Alors, voyons le scénario d'attaque ici. Imaginez que nous ayons un expéditeur. Et dire que le premier message qu'il veut chiffrer est une concaténation de 3 blocs, chacun de? -bytes. Il utilise une variante avec état du mode CBC. Donc, depuis le message? Est le premier message qu'il envoyait au récepteur, le?? Seront choisis au hasard. Et? 1,? 2,? 3 sera essentiellement le cryptage de? 1,? 2,? 3 et dire qu'il y a un attaquant CPA, qui intercepte ces paquets cryptés. Et maintenant l'adversaire connaît la relation ou le chemin? 1,? 2,? 3 ont été calculés. L'adversaire ne connaît pas la clé?, il est inconnu pour l'attaquant, mais l'adversaire connaît les mathématiques sous-jacentes qui sont utilisées pour calculer? 1,? 2,? 3.Maintenant, imaginez que l'agresseur CPA est sous l'état suivant: il sait d'une manière ou d'une autre que le message? 1 ou le premier bloc du message? Est en fait? 10 ou? 11. Il s'agit d'une information préalable d'une manière ou d'une autre disponible avec l'adversaire. Maintenant, si la variante avec état du mode CBC est en effet en sécurité CPA, alors même si l'adversaire a cette connaissance préalable et que l'adversaire voit cette communication chiffrée, en regardant simplement le bloc de chiffrement? 1, l'adversaire ne devrait pas être en mesure de déterminer s'il s'agit d'un chiffrement de fait? 10 ou? 11, sauf avec la probabilité 12, même si l'adversaire a accès au service d'oracle de chiffrement. Mais maintenant, ce que nous allons démontrer ici, c'est que si l'expéditeur et le récepteur utilisent une variante avec état du mode de cryptage CBC, comment un attaquant de CPA intelligent peut obtenir le service d'oracle de chiffrement et déterminer s'il est? 10 qui est crypté dans? 1 ou si c'est? 11 qui est crypté. C'est donc ce que nous allons démontrer. Supposons que le CPA-agresseur demande un service de chiffrement-oracle pour un nouveau message? ′, qui se compose de 2 blocs, par exemple? 4 et? 5 et? 4 est sélectionné de manière à ce que? 4 =? ?? ?10? 3. La raison pour laquelle? 4est choisi comme ceci, vous sera très bientôt clair. ? 5 peut être n'importe quel bloc arbitraire de? -octets, je ne me souciais pas de? 5, mais? 4est sélectionné comme ceci. Et comme nous sommes dans le régime CPA, nous ne pouvons pas empêcher un attaquant de CPA de demander une requête d'oracle de chiffrement pour ce genre de message. Maintenant, en réponse, supposons que l'expéditeur n'est pas au courant du fait qu'il interagit avec un adversaire et qu'il est influencé pour chiffrer le message? ′, composé de ces 2 blocs? 4 et? 5 avec la même clé?, mais en utilisant une variante avec état de cryption.Donc, le chiffrement ne sera plus composé d'un??, parce que?? Pour le chiffrement du message? ′ sera le bloc de chiffrement? 3. Donc l'adversaire saura que le bloc de chiffrement? 4est la valeur de la fonction clé?? Sur la XOR de? 4 et? 3. C'est,? 4 =?? (?4? 3). Et si je remplace la valeur de? 4, la voie? 4 a été choisie par l'adversaire, l'effet de? 3 annule. Et en gros? 4 s'avère être la valeur de la fonction clé sur la XOR de?? Et? 10.Maintenant, l'adversaire a également vu la valeur de? 1. Parce que c'était la communication cryptée, que l'adversaire a interceptée. Et depuis mon??? Est une permutation, il s'agit d'un mappage un à un sur un mappage. Alors l'adversaire sait que? 4 va être égal à? 1, si et seulement si le bloc de message? 1 est le même que? 10, donc il a toutes les informations disponibles avec elle pour savoir si le bloc de chiffrement? 1 était un chiffrement de? 10, ou s'il s'agit d'un chiffrement de? 11. Et avec une probabilité, notre adversaire va identifier ce qui est exactement le cas. C'est pourquoi nous ne pouvons plus affirmer que la variante avec état du mode de cryptage CBC est sécurisée par l'ACP. Et cette attaque a en effet été lancée dans l'une des versions précédentes du protocole TLS où les implémenteurs pensaient que la variante avec état du mode CBC sera sécurisée par CPA, et ils ont fini par le déployer. Et cette faiblesse a été exploitée par les attaquants pour lancer ce que nous appelons une attaque de bête. Et ce n'est que plus tard que cette attaque a été formellement identifiée et les gens se rendent compte que c'est exactement l'importance de la preuve formelle. Donc la leçon que nous tirons de cet exemple, c'est que vous ne devriez pas apporter absolument aucune modification à un schéma cryptographique qui a été formellement prouvé pour être sécurisé, même si les modifications vous semblent bénignes jusqu'à ce que vous ne disposez pas d'une preuve formelle pour la sécurité du schéma modifié. Cela nous amène à la fin de cette conférence. Pour résumer, nous avons vu 2 modes d'opérations des permutations pseudo-aléatoires, à savoir le mode ECB et le mode CBC. Le mode de la BCE n'est absolument pas CPA-sécurisé et il n'est pas recommandé d'utiliser dans la pratique et le mode CBC est sécurisé par l'ACP. Nous n'avons pas encore vu la preuve, mais vous devez me croire en la sécurité de l'ACP. L'inconvénient du mode CBC est qu'il n'est pas un état, cela signifie que nous ne pouvons pas maintenir l'état sur plusieurs messages, et qu'il ne prend pas en charge le parallélisme. Lors de la prochaine conférence, nous allons voir 2 autres modes de fonction pseudo-aléatoire et les permutations pseudo-aléatoires qui sont sécurisées par CPA, et qui se débarrinde réellement des restrictions qui sont là ou des inconvénients qui y sont liés par rapport au mode CBC.

Notification
You have received a new notification
Click here to view them all