Codes d'authentification de message | Messages longs | Alison
Loading
Notes d'étude
Study Reminders
Support
Text Version

Codes d'authentification de message pour les messages longs

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 la cryptographie Prof. Dr. Ashish Choudhury (Ancienne) Infosys Foundation Professeur de développement de carrière Professeur International Institute of Information Technology-Bengaluru Lecture-23 Message Authentication for Long Messages Partie I Bonjour à tous, bienvenue à la conférence 22, juste pour récapitulation, lors de la dernière conférence, nous avons commencé à discuter des problèmes de l'authentification des messages et de l'intégrité des messages, où l'objectif du récepteur est de vérifier si le message qu'il reçoit vient du bon expéditeur ou non. Et pour détecter si le message reçu par le récepteur est effectivement le message correct ou non. Et nous avons introduit une primitive cryptographique appelée code d'authentification de message et nous avons vu les définitions de sécurité du code d'authentification des messages. Nous avons aussi discuté de la façon de construire le code d'authentification des messages pour les messages de longueur fixe en utilisant des fonctions pseudo-aléatoires. Ainsi, lors de cette conférence, nous poursuivrons la discussion sur les codes d'authentification des messages. (Reportez-vous à la section Heure de la diapositive: 01:12) Nous allons discuter de la façon de construire des codes d'authentification des messages pour les chaînes de bits arbitraires. Nous allons donc commencer par discuter de la façon de construire un code d'authentification de message pour la chaîne de blocs, ce qui sera fait en 2 étapes. Nous allons d'abord voir comment construire un préfixe exempt de fonctions pseudo aléatoires sécurisées pour la chaîne de blocs. Ensuite, nous verrons comment convertir n'importe quelle fonction pseudo-aléatoire sécurisée sans préfixe pour une chaîne de blocs pour sécuriser complètement PRF pour une chaîne de blocs. Et une fois que nous aurons entièrement sécurisé PRF pour la chaîne de blocs, nous verrons comment construire des fonctions pseudo aléatoires pour des entrées de longueur arbitraire, à savoir arbitraires, mais des chaînes qui finiront par donner un code authentique de message pour des chaînes de bits arbitraires. C'est donc le plan de cette conférence. (Reportez-vous à la page Heure de la diapositive: 02:04) Pour vous rappeler, lors de la dernière conférence, nous avons vu comment construire un code d'authentification de message pour des messages de longueur fixe utilisant des fonctions pseudo-aléatoires. Par conséquent, supposons que vous avez une fonction pseudo-aléatoire sécurisée avec une longueur de bloc de bit de n bit et une taille de sortie L bit. Ensuite, à l'aide de la fonction pseudo-aléatoire, nous avons vu comment construire une MAC sécurisée où l'espace de clé est l'ensemble d'espace de message de chaînes de bits de toutes les chaînes de bits et l'espace de balise est un ensemble de chaînes de bits de L. Et la construction est comme suit la clé de sortie de l'algorithme de génération de clé pour la fonction pseudo-aléatoire qui est utilisée pour authentifier le message en calculant la valeur de la fonction pseudo-aléatoire sous la clé k avec le message étant le bloc d'entrée. Et c'est la balise et pour vérifier la balise pour le message m. La balise est recalculée en recalculant la valeur de la fonction keyed Fk sur l'entrée m. Et en comparant si la balise recalculée correspond ou non à la balise reçue. Si la correspondance se produit, la sortie est 1, sinon la sortie est 0. Maintenant, notre objectif est de construire des MACs sécurisés pour les messages longs arbitraires, car dans la pratique il n'y a aucune restriction que la taille du message devrait être de L bit, elle pourrait être inférieure à L bit, elle pourrait être plus grande que L bits et ainsi de suite. (Référez-vous à la diapositive: 03:29) Et il s'avère que, contrairement aux systèmes de cryptage sécurisés de l'ACP, si nous avons un système de cryptage sécurisé CPA pour le chiffrement des messages de L bit. Et si nous voulons atteindre la sécurité CPA pour chiffrer des messages longs arbitraires, alors nous avons vu qu'il suffit de diviser le message plus grand en plusieurs blocs de bits de L, et de chiffrer chaque bloc de bits de L à l'aide d'une instance du processus de chiffrement à longueur fixe. Mais ce processus de division du message et d'authentification de chaque bloc utilisant cette MAC de taille fixe ne va pas vous donner une construction MAC sécurisée. Concrètement, supposons que vous avez un message m à droite constitué de 2 blocs de bits de L. Et vous divisez le message m en blocs m1 et m2 et vous dites que vous vous authentifiez m1 à l'aide de cette procédure MAC de longueur fixe et que vous vous authentifiez indépendamment en m2 à l'aide de la même clé k à l'aide de cette procédure MAC de longueur fixe. Ensuite, un adversaire qui a vu la balise t1,t2 pour un message m peut facilement produire une MAC pour un nouveau message m ’ consistant en blocs m2 suivi de m1 à droite. Et ce sera une contrefaçon du point de vue de l'adversaire. Il n'est donc pas simple de prendre cette construction MAC pour des messages de longueur fixe et de l'utiliser pour construire une MAC pour l'authentification de messages longs arbitraires. (Référez-vous à la diapositive: 04:49) La construction sera vraiment une tâche difficile. Donc l'idée derrière la construction de codes d'authentification de messages pour les messages longs arbitraires est à rechercher, elle devrait concevoir des fonctions pseudo aléatoires sécurisées avec des chaînes de bits longs arbitraires, mais une sortie de taille fixe. Parce que si nous pouvons construire des fonctions pseudo aléatoires, qui peuvent prendre en charge n'importe quelle chaîne de bits arbitraire comme une entrée et donner une sortie de taille fixe, puis utiliser une telle fonction pseudo-aléatoire, nous pouvons facilement construire une MAC pour les messages longs arbitraires, ce que vous avez essentiellement à faire c'est que vous devez juste appeler cette fonction pseudo-aléatoire sur le message, qui pourrait être de n'importe quelle longueur pour produire la balise. Et selon l'idée que nous avions utilisée pour construire la pseudo MAC pour un message de longueur fixe, la construction correspondante sera une construction sécurisée. Donc tout le problème de la conception d'une MAC sécurisée pour les messages longs arbitraires revient au problème de la façon de construire des fonctions pseudo aléatoires pour des chaînes de bits arbitraires. Et c'est ce qui sera au centre de cette discussion. Ainsi, le document de référence pour la discussion d'aujourd'hui sera le chapitre de l'ébauche du livre par Boneh et Shoup et la plupart des preuves pour les constructions que nous allons discuter lors de la conférence d'aujourd'hui seront ignorées parce que les preuves sont vraiment avancées, nous allons juste donner, nous discuterons juste de la vue d'ensemble des idées de haut niveau derrière les preuves de sécurité des constructions que nous allons discuter dans cette conférence. Mais si vous êtes intéressés de voir ces preuves exactes, alors vous pouvez vous référer à la conférence donnée dans le projet de livre par Boneh et Shoup right. (Reportez-vous à la section Heure de la diapositive: 06:36) Commet donc la construction d'un PRF pour les entrées de taille arbitraire à partir d'un PRF avec entrée de taille fixe. Donc ce que vous êtes donné est de supposer que vous êtes donné comme PRF, dont la longueur de bloc est n bits et la sortie est aussi de n bits. Et en utilisant ceci, votre but est de construire en gros un autre PRF à clé que je dénote comme F*. Et qui peut supporter l'entrée de n'importe quelle longueur jusqu'à (l * n) bits. Et il vous donnera une sortie fixe de taille n bits. Donc, comme vous pouvez voir que la sortie de la clé PRF F* que nous sommes intéressés à construire est indépendante de la valeur de droite. Donc, peu importe si votre l est 1, l est 2 et ainsi de la taille de la sortie est toujours fixe, à savoir n bits. Donc notre objectif est de construire ce F* compte tenu de cette fonction pseudo-aléatoire clé F. Et nous concevrons F* à partir de F en utilisant une approche en 3 étapes. Dans la phase 1 ce que nous allons faire est, nous allons d'abord construire un PRF qui ne fonctionnerait pas sur une entrée de longueur arbitraire, mais il fonctionnerait sur une séquence arbitraire de blocs. Il peut calculer la sortie pour n'importe quel nombre de blocs jusqu'au nombre de blocs, où chaque bloc sera composé de n bit d'entrée. Et il vous donne toujours une sortie de n bit et nous appelons ce PRF en tant que préfixe sage préfixe libre PRF. Il sera clair très bientôt ce que nous entendons exactement par le terme préfixe libre PRF sécurisé. Mais ce qui est important, c'est qu'il ne supporte pas les entrées de longueur arbitraire, mais qu'il supporte les entrées qui sont en fait analysées comme séquence de plusieurs blocs. Et il peut prendre en charge des entrées composées d'un maximum de blocs, où chaque bloc est constitué de n bits de ficelle. Ainsi, il est indiqué par cette notation { { 0, 1 } n } < = l. Cela signifie que chaque bloc est de taille n bits et qu'il peut y avoir de tels blocs. Ainsi, l'étape 1 sera comment passer de cette taille fixe PRF F à ce préfixe libres PRF PF. Ensuite, une fois que nous aurons le PF de la construction, ce qui est un préfixe prudent de préfixe libre PRF sécurisé. Au cours de l'étape 2, nous prenons ce préfixe libre PF et nous construisons un FPR entièrement sécurisé, mais qui est encore bloqué. Cela signifie qu'il peut prendre des entrées composées de blocs d'upto l, où chaque bloc est de taille n bits et la sortie est de taille n bits. Et enfin à l'étape 3, une fois que nous aurons la construction F ’, nous construisons le PRF F* réel que nous sommes intéressés à construire, qui peut prendre n'importe quelle chaîne de bit arbitraire comme entrée de longueur allant jusqu'à l n bits. Rappelez-vous donc qu'il y a une différence entre la notation où cette notation et la notation où la chaîne binaire est jusqu'à longueur l n bits, donc quand je dis entrée de la forme { 0, 1 } < = ln qui signifie que l'entrée est une chaîne de bits arbitraire dont la longueur est l n. Mais quand je dis que j'ai une entrée de ce formulaire { { 0, 1 } n } < = l, cela signifie que mon entrée se compose de plusieurs blocs, à savoir, jusqu'à des blocs, où chaque bloc est exactement de taille n bits. Il y a donc une différence entre cette notation et cette notation. C'est donc l'approche à trois étapes que nous allons suivre pour construire notre PRF F* requis à partir du PRF F de longueur fixe. Et chacune des étapes est vraiment intéressante et subtile et nous sauverons les preuves comme je l'ai dit plus tôt, si vous voulez voir la preuve, vous pouvez voir le chapitre dans le brouillon du livre par Boneh et Shoup. (Reportez-vous à la page Heure de la diapositive: 10 :37) Donc commençons par la construction de préfixe libre PRF et pour cela, permettez-moi d'abord de définir ce que nous entendons exactement par ensemble sans préfixe. Donc un ensemble Q qui est un sous-ensemble de l'ensemble de tous les blocs, jusqu'à qui est un sous-ensemble de la séquence de blocs jusqu'à des blocs de taille, où chaque bloc est constitué de n bits est appelé ensemble sans préfixe. Si les conditions suivantes sont réunies, la première de toutes les conditions Q doit être non vide. Et la deuxième propriété est qu'aucun élément de l'ensemble Q ne devrait être un préfixe approprié de tout autre élément de l'ensemble Q, ce que cela signifie est que si nous avons un membre d'entrée dans l'ensemble Q dit la séquence (a1, a2) où a1 est 1 bloc et a2 est un autre bloc de la taille de n bits. Ensuite, nous ne pouvons pas avoir l'entrée a1 présente dans l'ensemble Q, car l'entrée de bloc a1 est un sous-ensemble approprié de la séquence des entrées de bloc a1, a2. Cependant, nous pouvons avoir l'entrée a2 présente dans le bloc Q car a2 n'est pas un préfixe de la séquence de bloc (a1, a2). Donc c'est la définition d'un préfixe libre jeu, pas vrai. Donc maintenant, ce que nous entendons exactement par un préfixe de "block sage" libre-sécurisé PRF. Ainsi, à un niveau très élevé, il s'agit d'un droit de PRF qui prend des entrées en tant que séquence de blocage et il pourrait y avoir un certain nombre de blocs de ce type. Et ce PRF sera sécurisé contre un adversaire plus faible que nous appelons le préfixe de l'adversaire libre. À savoir, il sera sécurisé contre un adversaire ou un distinguant dont les requêtes sont limitées à un préfixe libre. Donc, ce que nous voulons dire exactement par là, si syntactiquement bloquer le préfixe libre PRF sera une fonction à clé et il prendra une clé de taille par exemple n bits. Et il faut une séquence de blocs comme entrées, de sorte qu'il peut prendre jusqu'à l blocs ici, où chaque bloc est une taille fixe, à savoir n bits. Et il vous donne une sortie de taille fixe disons n bits et une propriété de sécurité que nous voulons à partir de ce bloc sage de préfixe-free sécurisée PRF est que, si vous considérez une fonction vraiment aléatoire qui prend également en entrée une séquence de blocs disons jusqu'à 1 blocs, où chaque bloc est de taille exactement n bits. Et vous donne une sortie de taille n bits telle que la fonction f est une fonction vraiment aléatoire à droite, c'est une fonction non indexée. Alors ce que nous entendons par un préfixe libre PRF sécurisé est que le comportement de ce PRF à clé ne doit pas être distingué du comportement de cette fonction vraiment aléatoire f contre un distinguisher, qui est limité à faire des requêtes uniquement à partir d'un préfixe libre. Cela signifie que ce distinguant ne peut pas demander la valeur de la fonction sur l'entrée de séquence de bloc (a1, a2) et a1 qui signifie toutes les requêtes que ce distinguisher va demander. Dans le jeu d'indistinction PRF, si nous le dénote par Q, alors l'ensemble Q des requêtes pour le distinguisher doit constituer un ensemble sans préfixe. C'est pourquoi cette distinction est une distinction plus faible ou un adversaire plus faible. Parce que dans la définition de sécurité du PRF, il n'y a absolument aucune restriction quant à la nature des requêtes que le distinguisher peut poser pendant le jeu. Il peut s'agir d'un ensemble sans préfixe, il peut ne pas être un ensemble sans préfixe. Mais quand je dis que nous sommes en train de concevoir un FPR sécurisé sans préfixe, alors il sera sécurisé uniquement contre un adversaire, dont les requêtes constituent un préfixe libre d'ensemble. (Reportez-vous à la section Heure de la diapositive: 14 :23) Donc, c'est la définition de la PRF par bloc qui est sécurisée sans préfixe et nous allons maintenant voir une construction candidate que nous appelons un préfixe CBC sans préfixe PRF sécurisé. Et la construction est la suivante. Nous avons donc un PRF à clé de taille fixe et une sortie de taille fixe. Et en utilisant notre objectif est de construire un PRF qui est un droit de PRF sécurisé sans préfixe qui peut prendre une séquence de blocs comme l'entrée disons jusqu'à l blocs de chaque taille de n bits et vous donne une sortie de taille fixe. Et nous utilisons ce mode de cryptage de CBC que nous avions vu plus tôt avec quelques différences. Laissez-moi vous montrer comment fonctionne exactement ce RPRF sécurisé sans préfixe de CBC. Pour des raisons de démonstration, supposons que vous disposez d'un message comprenant jusqu'à 3 blocs. Maintenant, pour calculer la sortie du PRF sécurisé sans préfixe de CBC pour cette entrée, ce que nous faisons est le suivant. Puisque nous avons 3 blocs, nous avons besoin d'appeler la taille fixe PRF 3 fois avec la même clé k. Et le premier appel du PRF sera m1 comme entrée et tout ce qui est la sortie qui sert d'entrée pour l'appel suivant, où il est XORed avec l'entrée de bloc suivante, à savoir le m2 et un XOR de la m2 et la sortie précédente du PRF est alimentée comme l'entrée de bloc pour le second appel, et ensuite nous poursuivons le processus de chaînage. Enfin, le résultat du dernier appel de la longueur fixe PRF F est traité comme la sortie de la PRF sécurisée de la CBC sans préfixe pour le message m. C'est un moyen, ce RDP sécurisé sans préfixe de CBC fonctionne bien. (Voir le temps de la diapositive: 16:14) Il y a donc certaines différences entre le FPR de la SRC que nous avons conçu tout à l'heure et le mode de cryptage CBC que nous avons discuté lors de l'une de nos conférences précédentes. Par conséquent, sur votre gauche, vous avez le mode PRF de la CBC et, sur votre droite, vous avez le mode de cryptage CBC. À des fins de comparaison, je considère qu'il s'agit d'un bloc de messages composé de 3 blocs et de la façon dont la sortie du fichier PRF de CBC sans préfixe sera calculée sur ce message. Et sur la partie droite, j'ai le même message et je montre comment exactement le mode de cryptage de la CBC sera exploité sur le même message. Les différences entre ces deux primitives sont donc les suivantes. Tout d'abord, lorsque nous voyons le PRF de la SRC, alors les valeurs intermédiaires qu'elles ne sont pas en sortie de droite, ce n'est que le résultat de l'appel final de F, qui est la production globale du PRF de la SRC. Alors que dans le mode de cryptage CBC, chacun des résultats intermédiaires du F fait également partie de la production globale. En effet, dans le mode de cryptage CBC, l'objectif est de chiffrer chacun des blocs individuels. C'est pourquoi nous devons absolument produire les résultats intermédiaires du PRF. Mais lorsque nous considérons le PRF de la CBC, notre objectif est de calculer une sortie de taille fixe pour le message global. C'est pourquoi il n'est pas nécessaire de générer les appels intermédiaires du PRF, donc c'est la première différence. La deuxième différence est que si nous considérons le PRF de la SRC, alors il utilise un IV fixe, c'est-à-dire sur la photo, il n'y a pas de IV du tout. Mais vous pouvez toujours imaginer que le IV est fixé à toutes les années 2000 qui sont connues du public. Mais lorsqu'il s'agit d'un mode de cryptage CBC, il y a un IV et il est choisi au hasard pour chaque instance du mode de cryptage CBC. Vous pouvez donc imaginer que CBC PRF utilise un déterministe IV, qui est toujours corrigé pour chaque message. Mais lorsqu'il s'agit du mode de cryptage CBC, IV est sélectionné indépendamment pour chaque appel. (Référez-vous à la diapositive: 18:28) Il s'agit donc des 2 différences et il s'avère que si vous avez réellement modifié un FRR de la SRC en faisant également passer les résultats intermédiaires du FPR, le PRF global n'est pas un FPR sécurisé. En outre, au lieu d'utiliser un IV fixe, si vous commencez à utiliser un IV aléatoire, il n'y a aucune garantie que le PRF de la CBC soit un préfixe PRF sécurisé sans préfixe. C'est ainsi que fonctionne le PRF de la SRC et je ne vais pas entrer dans la preuve de sécurité que ce PRF de CBC est en effet un PRF sans préfixe, mais laissez-moi vous donner une intuition qui explique pourquoi il risque d'être incertain si nous ne limitons pas notre adversaire à faire des requêtes qui constituent un droit fixe sans préfixe. Donc ce que je vais faire, c'est que je vais démontrer l'insécurité du préfixe de CBC sans préfixe contre un adversaire qui peut faire des requêtes qui ne constituent pas un ensemble sans préfixe. Alors imaginez que l'adversaire, il ya un adversaire qui demande une entrée de bloc a1 et obtient la sortie y sous une clé inconnue k qui n'est pas connu de l'attaquant à droite. Ainsi, la façon dont la production y aurait été calculée est la suivante. Puisque nous n'avons qu'un seul bloc, en gros nous aurions évalué la longueur fixe PRF F sur l'entrée a1 avec la clé k et c'est ainsi que la sortie y serait calculée. Maintenant imaginez l'adversaire a un nouveau bloc d'entrée nouveau composé de 2 blocs, disons bloc a1 suivi d'un bloc a2, où a2 est un bloc spécial ici, a2 est lié au bloc a1 et la sortie y qui est la valeur du préfixe-free PRF sur l'entrée de bloc a1. Et maintenant, demandez-nous ce qui sera exactement la valeur de ce préfixe CBC PRF sur l'entrée (a1, a2) de droite. C'est ainsi que la sortie du PRF de CBC sur l'entrée (a1, a2) sera calculée à droite. Nous aurons 2 invocations de la PRF de longueur fixe, nous ferons le chaînage et la sortie finale sera ceci: PFCBC (k, a1 | |a2). Maintenant ce qui est exactement le résultat de la première invocation du PRF F ici c'est y, parce que c'est ce qui est la structure juste. Donc vous pouvez voir que si je me concentre sur cette partie ici, cette partie n'est rien d'autre que le calcul du PRF de la CBC sur une entrée différente constituée d'un bloc a1. Et nous savons que n'est rien d'autre que y et maintenant, cette y est alimentée comme l'entrée pour le second appel, où cette y est XORed avec le bloc suivant ici. Et le bloc suivant est a1 XOR y, donc l'effet de cette y et y annule. Et ce que nous faisons ici, c'est que nous invo­tons effectivement le PRF de longueur fixe sur l'entrée1.Et l'adversaire sait déjà que la valeur de ce PRF sous la clé inconnue k mais avec l'entrée connue a1 va vous donner la sortie y. (Voir Diapositive Heure: 21 :48) Donc l'adversaire sait déjà que la sortie du PRF de CBC sur la séquence d'entrée (a1, a2) vous donnera y si donc le bloc a2 satisfait cette relation. Et cela lui donne un avantage ou une stratégie pour distinguer ce PRF de la CBC d'une fonction vraiment aléatoire. Donc ce que l'adversaire peut fondamentalement faire est, il peut d'abord demander la sortie de fonction sur l'entrée de bloc a1. Et puis il peut demander la sortie de fonction sur la séquence de blocs d'entrées de bloc (a1, a2). Et il peut le comparer avec y, s'il voit la sortie de l'entrée de fonction sur la séquence (a1, a2) à être y. Ensuite, il sait qu'il interagit avec un PRF sans préfixe CBC et si la sortie n'est pas y, cela signifie qu'elle interagit avec une fonction vraiment aléatoire. Et il peut être prouvé formellement que l'avantage distinctif du distinguant est significatif. Cela signifie que si nous autorisons l'adversaire à interroger, si l'ensemble des requêtes que l'adversaire peut demander ne constitue pas un ensemble sans préfixe. (Référez-vous à la diapositive: 22 :48) Ensuite, la construction que nous avons vue aujourd'hui n'est absolument pas sécuritaire. Parce que dans cet exemple particulier il est demandé à interroger a1 et ensuite il est invité à interroger pour aussi l'entrée (a1, a2). Et clairement a1 est un préfixe de l'ensemble (a1, a2), mais la définition de PRF sécurisé sans préfixe est qu'elle est sécurisée uniquement contre un adversaire qui ne peut pas interroger à la fois a1 ainsi que la séquence d'entrée (a1, a2). C'est donc l'intuition de base qui explique pourquoi cet enchaînement de PRF est protégé contre un adversaire sans préfixe. Si nous ne mettons pas cette restriction alors définitivement, elle se distingue d'une fonction véritablement aléatoire. (Référez-vous à la diapositive: 23 :34) Donc maintenant, nous avons un candidat par bloc de candidat sans préfixe-libre PRF sécurisé. Et ce que nous faisons maintenant c'est que nous allons à l'étape 2, où nous allons convertir ce préfixe de bloc-préfixe libre PRF pour obtenir un PRF entièrement sécurisé, où il n'y a aucune restriction sur les requêtes que le distinguisher peut faire dans le jeu d'indistinction du PRF. Vous avez donc déjà vu un candidat à ce sujet, c'est-à-dire le bloc PRF de la CBC. Et notre objectif est de construire un bloc PRF entièrement sécurisé, qui peut prendre la séquence de blocs comme des entrées, disons jusqu'à l blocs où chaque bloc est de taille fixe, disons n bits. Et la sortie est une sortie de taille fixe de taille n bits. Et il y a plusieurs approches pour ce faire, il y a plusieurs approches allant de l'aller à ce PRF sécurisé sans préfixe vers un PRF entièrement sécurisé et chaque approche a un échange différent. Donc la première approche est un PRF crypté de la CBC et les deux autres approches sont déterministes de codage sans préfixe et de codage de préfixe aléatoire. Donc les deux dernières méthodes ce qu'elle fait est en fait qu'elle code l'entrée de votre bloc de préfixe libre et sécurisé sans préfixe, de telle sorte que les entrées codées qui en résultent constituent un ensemble sans préfixe, alors que la CBC cryptée utilise 2 keys., où l'utilisation de la première clé nous utilisons le préfixe PRF sans préfixe. Et puis la sortie est à nouveau chiffrée à l'aide de la deuxième clé qui garantit que l'adversaire est confus. (Voir le temps de la diapositive: 25 :12) Nous allons donc plus loin dans les différentes approches, donc voyons d'abord comment nous construisons le préfixe par bloc-free secure CBC à une CBC entièrement sécurisée à l'aide du chiffrement. Et l'idée ici est d'utiliser 2 clés indépendantes, où l'utilisation de la première clé, nous exploitons le bloc sans préfixe CBC et en utilisant la deuxième clé, nous chiffrons la sortie du bloc sagesse CBC. Plus précisément ce que nous allons faire, c'est que nous allons construire un nouveau PRF que je dénote comme FCBC qui est entièrement sécurisé. Il n'y a pas de restriction sur le distinguisher, il peut faire des requêtes qui peuvent être sans préfixe, ou qui ne constituent pas un ensemble sans préfixe, etc. Donc la construction va prendre 2 clés et le PRF peut supporter une séquence de blocs, disons jusqu'à l blocs. Chaque bloc composé de n bits fixes et j'insiste sur le fait qu'ici tout au long de cette discussion, ce l est une fonction polynomiale de votre paramètre de sécurité. Et la sortie de ce bloc de PRF par bloc va être de n bits juste. Donc, comment exactement l'opération va se passer ici, puisque la clé est de taille 2 n bits, on l'analyse comme une séquence de 2 blocs de n bits chacun et on appelle la première partie de la clé pour être k1. Et avec k1, nous avons d'abord dirigé le droit CBC sans préfixe, qui fonctionne par bloc, et ce sera la sortie du préfixe CBC PRF sans préfixe par rapport à la clé k1. Et une fois que nous obtenons la sortie, nous utilisons la partie restante de la clé qui est aussi de n bits et indépendante de k1. Et nous utilisons cette clé pour chiffrer à nouveau la sortie que nous avons obtenue à partir du PRF sans préfixe de la CBC et qui sera le résultat global de ce PRF entièrement sécurisé de la SRC à l'égard de la clé k1,k2 de droite. (Référez-vous à l'heure de la diapositive: 27 :14) Il y a donc plusieurs avantages ainsi que des inconvénients pour ce CPR PRF chiffré par bloc. L'avantage ici est que ce PRF constitue ce que nous appelons un FPR de streaming et qui nous donne encore ce que nous appelons un MAC streaming. N'oubliez pas, notre but est de construire fondamentalement PRF supportant des entrées arbitraires de taille de bloc ; notre objectif est de construire PRF, qui peut prendre des entrées de taille arbitraire. En ce moment, ce que nous visons est de construire PRF qui peut prendre la séquence de blocs comme entrée et vous donne une sortie de taille fixe. Et une fois que nous aurons ce PRF, nous pouvons toujours utiliser ces PRF pour obtenir les CMA sécurisées correspondantes. A savoir une MAC qui peut prendre des entrées ; qui peut prendre une séquence de blocs comme entrée et vous donner une balise de taille fixe. Ainsi, l'avantage de ce PRF crypté de la SRC est qu'il constitue ce que nous appelons un MAC en continu. À savoir dans cette construction, la longueur du message n'a pas besoin d'être connue à l'avance. Cela signifie qu'il faut imaginer un scénario où un expéditeur envoie continuellement des paquets de messages au destinataire. Et il ne sait pas exactement ce qui va être la longueur du message m qui signifie qu'il ne sait pas bien à l'avance combien de blocs de bits seront là dans le message m, ce qu'il sait, c'est que le nombre maximum de blocs qui peuvent être là dans le message m est l, où l est connu publiquement, mais à part qu'il n'a aucune connaissance du nombre exact de blocs. Donc, si vous voyez la façon dont fonctionne le FPR de CBC crypté, la longueur du message n'est pas du tout utile ici. Donc, comme et quand de nouveaux blocs arrivent à droite ; ce que l'expéditeur peut faire est essentiellement qu'il peut calculer la sortie correspondante du préfixe CBC PRF sans préfixe. Et une fois le message terminé, cela signifie qu'une fois le dernier bloc du message envoyé à l'expéditeur, il peut calculer un appel final du PRF par rapport à la clé k2. C'est pourquoi il s'agit de ce que nous appelons un MAC en continu parce que la longueur du message n'a pas besoin d'être connue à l'avance ici. L'inconvénient de cette construction est que nous devons maintenant opérer avec 2 clés. Cela signifie que la clé globale pour le bloc CBC de la PRF est en fait constituée de 2 blocs indépendants de n bits. Et nous avons également besoin d'un appel de PRF supplémentaire, à savoir l'appel du PRF final, à l'exception du nombre d'appels de PRF que nous invoons en interne dans le cadre du PRF CBC sans préfixe. Ce sont donc les 2 inconvénients, et nous avons aussi un avantage ici. Donc vous avez le commerce ici. Si vous voulez un MAC streaming, alors c'est vraiment une très bonne construction. Mais vous devez payer quelque chose pour cela, c'est-à-dire que vous devez opérer avec 2 clés et que vous devriez être prêt à avoir un appel PRF supplémentaire ici à droite. J'espère que vous avez apprécié cette conférence, merci.

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