Code d'authentification des messages | Société Radio-Canada entièrement sécurisée | Alison
Loading
Notes d'étude
Study Reminders
Support
Text Version

Société Radio-Canada entièrement sécurisée par blocs

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 (ancien) Infosys Foundation Career Development Chair ProfessorIndian Institute of Technology-BengaluruLecture-24Message Authentication for Long Messages Part IIHello everyone, this is a continuation of the previous lecture and in this lecture we will see how to Obtenir block-wise fully secure Mac from block-wise prefix-free secure MAC. Ensuite, nous verrons comment obtenir des CMA entièrement sécurisées pour des chaînes de bits de longue durée arbitraires. (Référez-vous à la diapositive: 00 :49) Nous allons donc maintenant discuter des autres approches, de la façon de convertir un PRF sans préfixe en blocs sans préfixe à un PRF entièrement sécurisé par blocs. (Voir Diapositive Heure: 00 :59) Et cela sera par le biais d'un encodage. Et l'idée de base ici est que, nous appliquons une fonction de codage publiquement connue à l'espace de message du préfixe CBC PRF sans préfixe, de sorte que l'espace de message codé constitue un espace de message sans préfixe. Et ce qui signifie fondamentalement que c'est la suivante: imaginez que vous avez un espace de message pour le PRF sans préfixe, composé d'un maximum de l − 1 blocs, de chaque taille? Bits. Ce que nous ferons, c'est que nous appliquerons une fonction de cartographie ou de codage que je dénote comme?? Et l'espace de message codé se compose maintenant d'une séquence de blocs jusqu'à 1 blocs, chacune d'entre elles? Bits. Et la façon dont le mappage est fait ici est le suivant. Donc, maintenant nous sommes en train d'envisager un mécanisme de codage déterministe, plus tard on considérera un mécanisme d'encodage aléatoire comme bien .Donc, la façon dont ce mécanisme de codage déterministe fonctionne est comme suit. Donc, dire que vous avez une séquence de blocs d'entrée?, l'entrée encodée correspondante? Sera comme suit: tous les blocs de messages de? Sont copiés tel qu'il est dans la sortie encodée et à part que nous introduisons ici un bloc supplémentaire ici, à savoir la représentation binaire du nombre de blocs dans votre entrée?. Donc c'est la notation, dans les crochets, vous avez la représentation binaire de?. C'est pourquoi vous pouvez voir que l'entrée peut comprendre jusqu'à l − 1 blocs. Et puisque nous introduisons maintenant un bloc supplémentaire dans la sortie encodée, c'est pourquoi la sortie peut maintenant consister en des blocs jusqu'à 1 bloc, nous avons un bloc additionnel ici introduit à cause du processus de codage. Et l'idée ici est que l'utilisation de ce processus de codage déterministe, nous espérons qu'au lieu d'exploiter le préfixe PRF de CBC libre sur l'espace de message original, nous allons maintenant l'utiliser sur l'espace de message codé. Et puisque l'espace de message encodé constituera un préfixe? libre, le distinguisher ne peut pas émettre de requêtes, qui constituent un ensemble sans préfixe et donc la construction globale sera un PRF.So entièrement sécurisé, maintenant, prouvons que le codage déterministe que nous avons vu ici constitue en effet un préfixe de mappage libre. Cela signifie que le mappage à partir de l'espace de message, qui pourrait être un ensemble sans préfixe gratuit, à l'ensemble encodé, vous donne un ensemble encodé qui constitue un ensemble sans préfixe ; c'est ce que nous voulons prouver. Tout d'abord il est facile de voir que le mappage est injectif, c'est-à-dire isone-to-one. Cela signifie que si vous avez 2 entrées,? 1 et? 2 consistant en une séquence de blocs, jusqu'à l − 1 blocs. Et si nous les cotons, alors ils seront différents, si? 1 et? 2 sont différents. Parce que si? 1 et? 2 sont différents, alors certainement les blocs qui sont présents dans? 1 et les blocs qui sont présents dans? 2 vont aussi continuer dans le codé? 1 et dans le codé? 2, et ils seront différents. Par conséquent, le codé? 1 et codé? 2 sera différent. Cela prouve que votre mappage que nous avons défini ici est en effet un mappage un à un. (Référez-vous à la diapositive: 04 :25) Maintenant, nous voulons prouver que le jeu d'images??, c'est-à-dire tous les messages codés que nous obtenons selon ce mappage, constitue un ensemble sans préfixe. Alors imaginez que vous avez 2 entrées appartenant à l'espace des messages, par exemple la séquence d'entrée? Et une autre séquence d'entrée, composée de? Et? Nombre de blocs. Et dis? Et? Sont des entrées différentes. Donc, ma demande est que la sortie codée?? (?) et la sortie encodée?? (?) ne sont pas un préfixe correct l'un de l'autre. Et si vous l'avez mis en preuve pour une entrée arbitraire? Et une entrée arbitraire?, qui prouve que le mappage que nous avons considéré vous donne en effet un ensemble sans préfixe. Donc, clairement, l'affirmation que nous faisons au sujet du codage? Et codé? Est vrai, si le nombre de blocs dans? Et un certain nombre de blocs dans? Sont les mêmes, à savoir si? Et? Sont les mêmes. Parce que si? Et? Sont différents, alors certainement au moins un des blocs dans le codé? Et codé? Sera différent, parce que tous les blocs dans? Et tous les blocs dans? Ne peut être identique, même si? Et? Sont différents. La revendication est donc banale si? =?. Alors que si? N'est pas égal à?, c'est-à-dire le nombre de blocs dans? Et le nombre de blocs dans? ne sont pas identiques, alors définitivement la représentation binaire du nombre de blocs dans? Et la représentation binaire du nombre de blocs dans? Sera différente. Cela signifie le premier bloc que nous sommes en train de mettre dans le codé? Et le premier bloc que nous mettons dans le codé? Sera différent, ce qui garantira que l'ensemble est codé? Et codé? Sont différents. Cela prouve notre affirmation selon laquelle l'ensemble d'images du mappage que nous avons envisagé ici vous donne en effet un ensemble sans préfixe. (Référez-vous à la diapositive: 06 :21) Donc, maintenant, voyons comment nous appliquons ce codage sans préfixe à un PRF sécurisé sans préfixe CBC et obtenez un bloc PRF entièrement sécurisé. Donc, notre objectif est de construire une clé de prise en compte sécurisée par blocs et une séquence de blocs en entrée jusqu'à l − 1 bloc de taille? Bits, et pour obtenir une sortie de taille fixe de taille? Bits. Et pour la démonstration, supposons que nous voulons exploiter ce PRF de Radio-Canada entièrement protégé par blocs sur une entrée constituée de 2 blocs? 1 et? 2.Donc, ce que nous ferons, c'est que nous allons d'abord convertir cette entrée? En appliquant notre préfixe déterministe? libre de codage. Namely ce message? Est converti en entrée codée. Et quand nous convertirons les entrées encodées, alors les blocs de messages sont répétés, comme c'est le cas et à part cela au début nous avons maintenant un nouveau bloc, à savoir la représentation binaire du nombre de blocs qui sont là. Alors maintenant, nous avons un bloc de plus par rapport au nombre de blocs qui sont présents dans? Et une fois que nous avons l'entrée encodée ce que nous faisons est d'appliquer la construction existante, c'est-à-dire le préfixe "block wise préfixe-free CBC" avec la clé de la taille? Bits. Et la production sera considérée comme la sortie du bloc dans la bonne direction de Radio-Canada pour le message? Sous la clé?. Maintenant, pourquoi cette construction est-elle intuitive? Parce que même si un adversaire demande la sortie de fonction sur une entrée? 1 et sur une entrée? 1,? 2, il obtient la sortie de la fonction sur la séquence d'entrée < 1 >,? 1 et la séquence de sortie < 2 >,? 1,? 2. Et donc, il ne peut pas lancer l'attaque que nous avions vue lorsque nous discuterons de l'insécurité du PRF sécurisé sans préfixe. Parce que même maintenant, il fait des requêtes qui ne constituent pas un ensemble sans préfixe, essentiellement ces requêtes sont converties en un autre ensemble de requêtes, qui est un ensemble sans préfixe et du point de vue d'un adversaire, il est maintenant aussi bon qu'il interagit avec un PRF.So normal, c'est l'idée générale de la preuve de sécurité, mais les détails formels sont effectivement avancés dans la nature et c'est pourquoi je ne saute pas les détails ici. Si vous voyez l'avantage de cette construction, c'est-à-dire la façon de construire un PRF entièrement sécurisé par blocs via un encodage déterministe (voir Diapositive: 09 :13). L'avantage est alors que nous avons besoin d'une seule clé, contrairement au PRF crypté de la CBC, où nous avons besoin d'utiliser 2 clés. Toutefois, les inconvénients sont les suivants. Nous avons besoin d'une invocation supplémentaire du PRF, pour ce bloc supplémentaire que nous introduisons ici. Dans l'idéal, nous attendons un PRF, où le nombre d'appels PRF de base est le même que le nombre de blocs dans le message. Mais en fait, dans cette construction globale, nous avons besoin d'un appel supplémentaire du PRF de base. Et la mauvaise nouvelle de cette construction, c'est qu'elle ne constitue plus une CMA de streaming. Parce que la longueur du message ou le nombre de blocs dans le message doivent être connus à l'avance à l'expéditeur. Parce que si le nombre de blocs dans le message n'est pas connu de l'expéditeur à l'avance que le codage du message ne peut pas se produire, car le codage nécessite la représentation binaire du nombre de blocs dans le message qui est présent et qui doit être inséré au début. Mais c'est pour cela qu'il ne vous donne pas de MAC en continu. Donc c'est l'approche d'aller d'un préfixe sans bloc sécurisé à un PRF sécurisé à un bloc de PRF complètement sécurisé à l'aide d'un encodage déterministe. (Voir la diapositive Time: 10 :30) Et maintenant, nous voyons comment nous pouvons passer de ce préfixe par blocs libres de PRF sécurisé à bloquer-sage complet de PRF en utilisant un préfixe aléatoire de codage libre. Donc la raison pour laquelle nous voulons aller pour un préfixe aléatoire sans codage est que les problèmes auxquels nous sommes confrontés avec le préfixe déterministe libre-encodage est que nous n'obtenons pas de flux MAC. Et nous avons besoin d'un appel supplémentaire de la base PRF.Et la solution pour contourner ces 2 problèmes est d'utiliser un préfixe aléatoire de préfixe libre qui sera un encodage clé. Et la façon dont nous faisons le codage est la suivante. Alors, d'abord, introduissons ici quelques notations. Alors imaginez que vous avez 2 entrées de séquence de bloc, dites entrées? Et l'entrée? Chacune comprenant jusqu'à 1 blocs, chacune d'entre elles? Bits et si? Est un préfixe de? Ou si? Est un préfixe de?, alors nous avons utilisé une notation? ~ ?.Alors maintenant, nous introduisons la définition de ce que nous appelons "randomisé"?-préfixe "free-encoding", où? Est un paramètre. Et ce qu'est ce codage, c'est qu'il prend comme entrée une clé de taille? Bits et une séquence de blocs comprenant jusqu'à 1 blocs et elle vous donne une sortie encodée qui est une sortie codée par clé pour l'entrée. Et quand je dis qu'il s'agit d'un encodage aléatoire? -prefx, ce que cela signifie, c'est que la probabilité d'obtenir 2 entrées? Et? Du domaine d'entrée, consistant en des blocs de 1, de sorte que sous la même clé?, les sorties codées correspondantes sont liées entre elles par cette relation de préfixe est bornée par?. Cela signifie que si vous avez une séquence? Et si vous avez une autre séquence?, alors la chance qui est encodée? Et codé? Est un préfixe les uns des autres, i. E le codé? Est un préfixe codé? Ou le codé? Est un préfixe codé? Est délimité par?. C'est ce que je veux dire quand je dis que j'ai un encodage aléatoire? -préfixe-free. (Référez-vous à la diapositive: 12 :44) Donc, en gros, l'idée ici est que, s'il y a un adversaire délimité par les calculs, et s'il ne connaît pas la valeur de la clé? Avec lequel nous faisons effectivement le codage, puis pour l'adversaire il est très difficile de trouver une paire d'entrées (?,?) consistant d'un maximum de blocs, de sorte que soit le codé? Est un préfixe codé? Ou le codé? Est un préfixe codé? .C' est ce qui est l'exigence de sécurité à partir de ce codage aléatoire? -prefix free-encoding. Je souligne ici que le mappage ou la façon dont cet encodage aléatoire est opéré, il n'est pas nécessaire que le mappage soit un mappage injectif. Cela signifie que vous pouvez avoir plusieurs entrées?, dont le codage sera le même sous la clé?. Mais la garantie de sécurité que nous obtenons de ce préfixe?-préfixe free-encoding est que même si plusieurs de ces candidats pouvaient être sous la clé? Vous aurait donné la même sortie encodée, la probabilité de trouver un tel multiple? ’ temps polynomial devrait être borné par une quantité négligeable ou par la quantité?. Je souligne aussi que, contrairement au préfixe déterministe sans codage, le codage que nous construisons ici, à savoir le codage à clé, il peut ne pas vous donner un ensemble sans préfixe. Cependant, même si cela ne va pas vous donner un ensemble sans préfixe, la chance que l'adversaire puisse trouver une mauvaise paire d'entrées (?,?), telle qu'encodée? Est un préfixe codé? Ou vice versa, doit être délimité par la probabilité?. Et si vous vous en assuriez? Est très petit, puis nous le faisons. (Référez-vous à la diapositive: 14 h 30) Donc, ce que nous allons faire maintenant, c'est de définir un codage aléatoire à préfixe gratuit pour notre PRF de la CBC. Et la façon dont nous définissons ce codage est la suivante. Alors imaginez que vous avez une entrée composée de plusieurs blocs, disons? Nombre de blocs, où? Est délimité par l et chaque bloc est de taille? Bits. Et nous avons une clé? Avec lequel nous voulons être encodé, donc la sortie encodée? Sera comme suit: vous répétez tous les blocs de? Sauf le dernier bloc. Et le dernier bloc est essentiellement le XOR du dernier bloc de la réalité? Et la clé?, de sorte que l'ishow que nous sommes en train de calculer le codé?. Et ma réclamation est que si la clé pour ce codage est sélectionnée uniformément au hasard à partir de l'ensemble des chaînes? -bit, alors ce mappage constitue un encodage de 12?-préfixe libre. Cela signifie la probabilité qu'un adversaire qui ne connaît pas la valeur de?, puisse trouver 2 entrées? Et?, c'est-à-dire que le codé? Est un préfixe codé? Ou vice versa est délimité par la probabilité 12?, ce qui est définitivement une fonction négligeable dans le paramètre de sécurité. Alors, prouvons ça. Alors imaginez que vous avez une entrée?, une séquence de blocage? Et une autre entrée?, une séquence de blocs et de dire? Et? Sont différents. Et nous voulons savoir quelles sont les chances que cela soit encodé? Et codé?, soit le codé? Est un préfixe codé? Ou vice versa. Alors d'abord de tout avis que si le nombre de blocs dans? Et un certain nombre de blocs dans? Sont les mêmes, et si? N'est pas égal à?, alors pour chaque valeur de la clé certainement pas le codé? Sera un préfixe codé? Ou vice versa. Parce que quand on fait le codage, tous les blocs de? Sauf le dernier bloc et tous les blocs de? Sauf le dernier bloc sera présent dans les sorties encodées respectées. Et le dernier bloc sera le XOR par rapport à la clé, donc certainement tous seront différents et ne seront pas les préfixes les uns des autres. D'un autre côté, considérons un scénario, où dire sans perte de généralité que le nombre de blocs? Dans? Est inférieur au nombre de blocs? Dans? Et? N'est pas égal à?. Alors quelle est la probabilité qui est encodée? Est un préfixe codé?? Bien codé? Sera un préfixe codé?, si et seulement si? ?échéant? =?? Les cales. Mais cela ne vaut que si la valeur de clé qui est sélectionnée pour faire le codage est en fait la XOR du dernier bloc de? Et le bloc de?. Et puisque la clé pour le codage est choisie au hasard à partir de l'ensemble des chaînes de bits, la probabilité qu'en effet la clé satisfait cette relation est 12?.Cela signifie, le codage que nous avons vu est un encodage très simple, mais il a une propriété très puissante qu'il vous donne un encodage de 12?-free-encoding. Namely if a computationally bounded adversaire, who does not know the value of the random key?, it cannot come up with a bad pair of inputs (?,?), such that either the encoded? Est un préfixe codé? Ou vice versa. (Référez-vous à la diapositive: 18 :33) Maintenant, voyons comment en utilisant ce préfixe aléatoire de codage libre, nous pouvons convertir le préfixe prudent en blocs libres de PRF en blocs PRF en bloc, entièrement sécurisé et sécurisé. Et l'idée est la même que celle que nous avons utilisée pour le codage déterministe. La seule différence est qu'au lieu d'appliquer l'encodage déterministe, nous allons appliquer l'encodage aléatoire. Alors maintenant, nous allons opérer avec 2 clés chacune de la taille? Donc, c'est pourquoi la clé globale de la CBC à part entière sécurisée sera de la taille 2? Bits et il peut prendre en charge une séquence de blocs comprenant jusqu'à 1 blocs, où chaque bloc est de taille? Et il vous donnera une sortie de taille fixe. Pour la démonstration, supposons que nous avons un message comprenant jusqu'à 3 blocs. Donc, ce que nous faisons, c'est que la clé globale pour le PRF de la CBC est interprétée comme 2 blocs de clés? -bit. Donc la première partie est? 1 et avec? 1, on fait d'abord le codage de l'entrée, c'est-à-dire le message? Est encodé selon la clé? 1 via le préfixe "free-encoding". Et la taille de la sortie encodée et la taille de l'entrée restent les mêmes, c'est important. Ceci est en contraste avec le préfixe déterministe sans codage, où la sortie encodée est constituée d'un bloc de plus par rapport au nombre de blocs présents dans l'entrée. Et une fois que nous avons l'entrée encodée, nous appliquons maintenant le préfixe "bloc-wise" à "free secure PRF" avec la seconde partie de la clé. C'est pourquoi nous avons besoin de 2 clés, l'une pour l'encodage aléatoire et l'autre pour le calcul réel des FPR. Et quelle que soit la sortie que nous avons obtenue du PRF sécurisé sans préfixe, qui est considéré comme le résultat global du FPR sécurisé par blocs sous la clé? 1,? 2pour la séquence de message?. Maintenant intuitivement, pourquoi cette construction est sécurisée, parce que ce que nous avons fait est avec une très forte probabilité, nous avons en fait converti l'ensemble d'entrée de ce PRF de CBC en un ensemble encodé sans préfixe. Même s'il n'est pas en principe, un ensemble encodé sans préfixe, la probabilité qu'un adversaire sans la connaissance de la clé? 1 se place avec une mauvaise paire d'entrées? Et? ′, telle que la codée? Est un préfixe codé? ′ ou vice versa, est très, très négligeable. Et cela garantit que la construction globale ressemble à une construction de PRF normale. Les avantages de cette façon de construire un PRF entièrement sécurisé par bloc sont que nous n'avons pas besoin que la longueur du message soit connue à l'avance. C'est pourquoi nous obtenons maintenant une MAC en continu ou un FPR en continu. Et nous n'avons pas besoin d'autres appels de base PRF. Donc on se débarras des deux défauts qui étaient là, quand on utilisait un préfixe déterministe sans encodages, il ne nous donnait pas de MAC en continu et nous avons besoin d'un appel de PRF supplémentaire parce que le préfixe déterministe libre-codage nécessite un bloc supplémentaire dans la sortie encodée, mais ce n'est pas le cas ici. Cependant, vous devez payer un prix ici, le désavantage est ici que vous devez maintenant opérer avec 2 clés, alors que si nous voyons le préfixe déterministe libre de codage, nous n'opérons qu'avec une seule clé, donc vous avez un échange. (Référez-vous à la diapositive: 22 :06) Donc maintenant, voyons comment nous allons construire des PRF complètement sûrs à partir de PRF complètement sécurisé par blocs. Rappelez-vous donc que notre objectif final est de construire un code PRF ou un code d'authentification de message qui peut prendre une séquence de bits comme entrée. Ainsi, jusqu'à présent, le PRF ou la CMA que nous avons construit ne peuvent prendre que des blocs ou des séquences de blocs comme entrées. Donc l'idée derrière la construction de PRF qui fonctionne sur une séquence de bits est que vous appliquez pour la première fois un remplissage sans ambiguïté, selon que la chaîne de bits d'entrée que vous voulez alimenter en entrée de votre PRF est un multiple de la taille de bloc du PRF de base ou pas. Donc, pour simplifier, supposons que la taille de bloc du PRF de base est? Bits. Maintenant, vous voulez concevoir un PRF que je dénote comme?CBC ∗, en prenant une clé de taille? Bits, et il peut prendre n'importe quel bit d'entrée de longueur jusqu'à? l bits. Et maintenant, il pourrait y avoir 2 cas possibles, selon qu'il s'agisse de l'apport de ce PRF?CBC ∗ it ’ est égal à un multiple de? Ou non. Alors rappelez-vous que je suppose que la taille de bloc de mon PRF de base est? Donc le cas 1 pourrait être quand la taille d'entrée de? Est une constante? Fois?. Et le cas 2 pourrait être quand la taille de l'entrée n'est pas égale à un temps constant?, cela signifie que ce n'est pas un multiple de?. Donc, en fonction de 2 cas, nous opérons le PRF aussi appelé?CBC ∗ que nous sommes intéressés à construire de deux façons différentes. Alors, prenons le cas 1, dans les deux cas, nous devons faire un padding. Que faisons-nous donc dans le cas 1? Par exemple, imaginez que mon message que je veux entrer ici est de taille 2? Bits. Cela signifie que je peux le diviser en deux blocs? Bits. Et maintenant je dois faire un padding sans ambiguïté, donc dans ce cas, en fait, je n'ai pas besoin de faire un padding parce que mon message est déjà un multiple de? Bits. Mais pour l'indiquer au destinataire qu'en fait je n'ai pas besoin de faire un padding, ce que je vais faire ici, c'est que je vais ajouter un bloc factice composé de? Bits commençant par 1 suivi de tous les 0s.Donc, c'est une indication du côté de l'expéditeur que je ne fais pas de remplissage. Maintenant, pour opérer?CBC ∗dans ce cas, ce que nous allons faire est que nous allons prendre une clé? 1 que nous allons bientôt voir comment exactement est calculé. Alors n'oubliez pas que la clé globale pour?CBC ∗n'est qu'une clé de taille? Bits. Mais ce que nous allons faire, c'est que nous allons dériver plusieurs sous-clés et selon que nous sommes dans les cas 1 et 2, nous allons utiliser certains sous-ensembles de ces sous-clés. Dans ce cas, nous utilisons une sous-clé que j'appelle? 1. Et alors ce que nous allons faire ici, c'est que nous allons faire fonctionner notre PRF entièrement sécurisé par blocs avec 2 clés, chacune de taille? Bits. Et comme il s'agit d'un PRF entièrement sécurisé par bloc, il peut prendre une séquence de blocs de? Bits, jusqu'à l + 1 blocs de ce type. Et ça vous donne un output.Donc, si vous voyez la vue extérieure du PRF?CBC ∗ que nous allons construire ici, il pourrait prendre une entrée de taille? l bits. Et si ma taille d'entrée est déjà un multiple de?, cela signifie qu'elle pourrait avoir jusqu'à un certain nombre de blocs. Mais si vous voyez l'appel interne du PRF complètement sécurisé par bloc, alors il pourrait prendre jusqu'à 1 blocs de taille peu? Bits. Vous vous demandez peut-être pourquoi ce bloc supplémentaire? Ce bloc supplémentaire 1 peut venir si votre taille de message est déjà un multiple de?, auquel cas vous devez ajouter un nouveau bloc factice complet? Bits. C'est pourquoi l'invocation interne de mon PRF complètement sécurisé par bloc peut prendre jusqu'à 1 blocs. Donc en interne ce que je fais c'est que je fais fonctionner mon PRF complètement sécurisé par bloc et pour faire ça, je prends d'abord le message de remplissage et j'applique un encodage aléatoire sans préfixe avec la sous-clé? 1 et ensuite j'utilise une autre sous-clé? 0. Là encore, on verra bientôt comment exactement les sous-clés? 0,? 1 sont dérivées. Donc, une fois que nous avons le préfixe "free-encoding" du message "pions", nous prenons la sous-clé? 0 et ensuite nous exécutons notre réseau CBC entièrement sécurisé et tout ce qui ressort comme la sortie, qui est considéré comme le résultat global du bit? sage sécurisé PRF?CBC ∗ sous la clé? Pour le message?. C'est le cas 1, quand la longueur du message est déjà un multiple de la taille de bloc de la base PRF.Laissez-nous voir comment les choses sont remises pour le cas 2. Alors, au cas où 2 imaginez que j'ai un message, ce qui accélère le bloc? Bits et le second bloc qu'il n'a pas plein? Bits. Encore une fois, je dois faire un padding ici, mais ici je n'ai pas à ajouter un nouveau bloc factice complet parce qu'il me suffit d'ajouter un 1, suivi du nombre requis de 0 ’ s pour m'assurer que j'ai le deuxième bloc qui a aussi? Et puis j'utilise une autre sous-clé dans ce cas, que j'appelle? 2, pour faire le préfixe "free-encoding" du message "padded". Et puis, en interne, j'invoque mon PRF complètement sécurisé par bloc, qui n'a plus qu'un nombre de blocs. Parce que je n'ajouterais aucun bloc factice dans le cas 2 ici. Et quel qu'il soit, une sortie qui est prise comme la sortie de mon PRF?CBC ∗ pour l'entrée? sur la clé?, il s'agit donc des 2 cas ici. (Référez-vous à la diapositive: 28 :08) Maintenant, voyons comment exactement ces sous-clés? 0,? 1,? 2 sont dérivées. Alors rappelez-vous que la clé globale pour mon PRF?CBC ∗ est juste 1 clé? De la taille? Bits. Donc les clés? 0,? 1,? 2 sont dérivées de la clé réelle? Pour le PRF?CBC ∗ par un algorithme de génération de sous-clé, qui sera connu publiquement. Et selon que l'expéditeur est dans le cas 1 ou est dans le cas 2, il détirera les clés? 0,? 1,? 2, mais selon que c'est le cas 1 ou 2, il va soit utiliser? 0,? 1 ou il va utiliser? 0,? 2.Maintenant, comment le récepteur va effectuer l'opération. Alors imaginez un message et une balise correspondante est envoyée à l'extrémité réceptrice et un récepteur doit vérifier, si le message est le droit, si la balise? Est la balise de droite sur le message? Ou non. Et imaginez que le récepteur ait aussi la même clé?. Donc ce que le récepteur va d'abord faire, c'est que le récepteur va dériver les sous-clés? 0,? 1,? 2.Et puis il doit retirer le remplissage car, rappelez-vous, le récepteur doit d'abord savoir ce qui était exactement le remplissage que l'expéditeur a effectué à la fin de l'expéditeur. Pour supprimer le remplissage, ce que le récepteur va faire est, il peut commencer à analyser le message depuis la position droite jusqu'à la position de gauche et il effectue une analyse complète. Et il arrête de scanner dès qu'il rencontre le premier lorsqu'il est scannant de droite à gauche. Dès qu'il rencontre le premier, il sait que c'est le remplissage qui a été fait et il peut enlever et lancer le remplissage. Et cela peut dire au récepteur si le récepteur doit fonctionner selon le cas 1 ou selon le cas 2. Et je prédis qu'il s'agit d'un remplissage sans ambiguïté. La stratégie du récepteur consistant à scanner le message de la position droite à la position de gauche et à rechercher la première occurrence de la première occurrence de la première occurrence de la première occurrence, suivie de toutes les années ultérieures, est en effet et sans ambiguïté pour le récepteur, car si nous étions effectivement au cas 1, cela signifie que l'expéditeur a effectivement ajouté un bloc factice complet. Alors en effet la première occurrence de 1 lorsque le récepteur fera le balayage sera quand il sera fait avec le dernier bloc, alors que si l'expéditeur aurait été dans le cas 2, pour le récepteur la première occurrence du 1 sera dans le dernier bloc lui-même et c'est une indication que c'est dans le cas 2.Donc une fois que les récepteurs identifient si c'est dans le cas 1 ou si c'est le cas 2, en fonction du cas requis, il peut vérifier que la balise part pour le message qu'elle a reçu, soit en opérant le PRF?CBC ∗ avec les sous-clés? 0,? 1 ou avec les sous-clés? 0,? 2.Donc, cela m'amène à la fin de cette conférence. Ce que nous avons fait dans cette conférence est que nous avons vu comment construire un code d'authentification de message pour les messages longs arbitraires à l'aide de la taille fixe PRF.Et l'approche pour la construction est que nous essayons de concevoir un PRF sécurisé qui peut prendre une chaîne de bits arbitraire comme entrée et vous donner une sortie de taille fixe. Si vous pouvez construire de tels PRF qui peuvent fonctionner sur une séquence arbitraire de bits et vous donne une sortie de taille fixe. Ensuite, nous pouvons facilement obtenir un code d'authentification de message qui peut fonctionner sur des chaînes de bits en entrée, et nous avons vu une construction candidate pour un FPR fonctionnant sur une séquence de bits, à savoir le PRF de la CBC. Et nous avons vu plusieurs façons de construire ce PRF de la CBC, à savoir, nous avons d'abord vu comment construire un FPR sécurisé sans préfixe, qui est sécurisé contre un adversaire plus faible. Et puis en appliquant différents mécanismes, à savoir cryptage, déterministe, préfixe free-encoding, préfixe libre aléatoire, nous convertisons cette forme plus faible de PRF, namelywhich is secure only against a prefix-free secure adversaire into a fully-secure PRF, which is secure even against an adversary, which can make queries which does not be a prefix-free set. Et enfin, nous construisons ou convertisons ce PRF complètement sécurisé en bloc en PRF sécurisé bit par bit en utilisant le mode CBC. Nous disposons donc maintenant d'un outil permettant d'authentifier les messages et même de vérifier si le message reçu a été correctement reçu ou non, si nous avons un expéditeur et un récepteur qui ont une clé partagée? Et si nous avons un code d'authentification de message qui peut vous donner une balise de taille fixe pour les messages longs arbitraires. Ensuite, pour authentifier l'expéditeur du message, vous pouvez simplement calculer une balise de longueur courte ou fixe pour ce message. Et avec le message, la balise peut être communiquée au récepteur. Quand le récepteur reçoit cette étiquette et si la balise est vérifiée avec une clé?, alors cela donne la garantie au destinataire qu'il provient de la même personne qui a la même clé? Avec laquelle la vérification de la balise a abouti. C'est ainsi que le problème de l'authenticité et de l'intégrité est résolu. J'espère que vous avez apprécié cette conférence.

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