Loading
Notes d'étude
Study Reminders
Support
Text Version

Transformation Fiat-Shamir

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

    +

Foundations of Cryptography Prof. Dr. Ashish Choudhury Department of Computer Science Indian Institute of Science – Bangalore Lecture – 54 Schnorr Signature Scheme et TLS ou SSL (Référez-vous à la diapositive: 00:33) Bonjour tout le monde. Bienvenue à cette conférence. Le plan de cette conférence est le suivant et cette conférence nous allons discuter d'une transformation très puissante ou heuristique, que nous appelons comme heuristique Fiat-Shamir. Ce qui nous permet d'obtenir des schémas de signature numérique à partir de tout schéma d'identification sécurisé, puis nous verrons comment appliquer cette transformation à aucun schéma de signature pour obtenir un schéma de signature numérique basé sur l'hypothèse de log discret. Enfin, nous verrons une présentation du protocole TLS et SSL. (Référez-vous à la diapositive: 01:00)Alors, commençons notre discussion avec la transformation de Fiat-Shamir. Donc, ce que Fiat-Shamir heuristique ou transformation est, il faut un système d'identification interactif à 3 tours, qui a une structure d'engagement, de défi, de réponse. Et la transformation convertit ce protocole interactif en un protocole non interactif. Non interactive dans le sens où il n'y aura qu'une seule interaction entre le tube étalon et le vérificateur et en utilisant ce protocole non interactif au fond, nous finissons par obtenir un schéma de signature à 1 round. L'idée qui sous-tend cette transformation est que, si vous avez un schéma d'identification et si vous voulez obtenir un schéma de signature à partir de cela, alors pour signer le message à l'aide de la clé de signature, le signataire doit agir comme un étalon et il doit exécuter tout le protocole du schéma d'identification dans son esprit. Conformément aux règles de cette transformation, venez avec l'ensemble de la transcription en un seul coup et donnez-le au vérificateur. Cela signifie que, dans le protocole interactif à trois tours qui était là pour le système d'identification, le vérificateur aurait choisi le défi. Mais ce que nous disons ici, c'est qu'après cette transformation, même le défi sera aussi choisi par le prover lui-même. Il doit jouer le rôle du tube étalon aussi bien que le vérificateur en même temps. Donc, vous vous demandez peut-être que si l'on donne la disposition pour relever le défi au nom du vérificateur, le ver malveillant ou le prover à tricher peut tricher. Elle ne peut pas relever un défi uniformément aléatoire. Il s'avère que la transformation de Fiat-Shamir est si intelligente qu'elle finit même par forcer le tube à tricher à relever des défis uniformément aléatoires. Donc, voici comment nous faisons la conversion du protocole interactif à 3 tours en 1 round de protocole interactif. Donc, on nous donne un schéma d'identification à 3 tours Gen, 1, 2,. En l'utilisant, nous voulons obtenir un signe de schéma de signature à 1 round = (Gen, Sign, Vrfy). Dans le cadre de cette transformation, nous supposons que nous avons la description publique de certaines fonctions de hachage des entrées de longueur arbitraire dans les éléments de l'espace de remise en question du schéma d'identification sous-jacent. Ainsi, l'algorithme de génération de clé de ce schéma de signature sera le même que l'algorithme de génération de clé de votre schéma d'identification. L'algorithme de signature est maintenant comme suit. Imaginez, il ya un signataire qui a la clé de signature sk, et il a un message sur lequel il veut générer sa signature. Donc, comme je l'ai dit plus tôt, il doit jouer le rôle de l'étalon ainsi que le vérificateur du système d'identification lui-même. Ainsi, il exécute l'algorithme P1 sur la clé de signature pour obtenir l'engagement I et une information d'état, et maintenant il doit choisir le caractère aléatoire r au nom du vérificateur lui-même. Donc, idéalement, il devrait choisir le hasard challenger r uniformément au hasard dans l'espace de défi, mais maintenant nous allons concevoir un schéma de signature. Donc, le message devrait aussi entrer dans l'image tout en choisissant le caractère aléatoire r ou le challenger r. Donc, pour relever le défi. Donc, l'idée ici est fondamentalement, le défi r va être en quelque sorte associé au message, que l'expéditeur veut signer ici. Et si nous supposons ou si nous modélisons la fonction de hachage sous-jacente comme un oracle aléatoire ici, il s'avère que la valeur r, que le signataire va obtenir en générant r selon cette méthode, sera effectivement une valeur uniformément aléatoire de l'espace de défi du schéma d'identification sous-jacent. Une fois le r généré, le signataire doit générer la pièce de réponse, c'est-à-dire en exécutant l'algorithme P2, et enfin la signature est (r, s). Donc, maintenant pour envoyer un message signé au vérificateur, il enverra un message avec la signature (r, s). Et le vérificateur vérifie la signature, il exécute l'algorithme de vérification du schéma d'identification sous-jacent, mais il y a une différence. Dans le schéma d'identification original, le vérificateur vérifiait si la sortie de l'algorithme de vérification avec la clé de vérification et la partie (r, s) de la transcription donnent ou non la partie I de la transcription. Ici de l'autre côté, la partie de l'algorithme de vérification du schéma de signature, le vérificateur va exécuter l'algorithme de vérification du schéma d'identification sous-jacent, mais il ne compare pas la sortie de la fonction V avec le composant I , car il ne connaît pas le composant I tel qu'il est. Si vous voyez la structure de ce schéma de signature, le I n'est pas donné par le signataire au vérificateur, alors que dans le schéma d'identification, le vérificateur aurait déjà obtenu un I et c'est pourquoi il pourrait comparer la sortie de la fonction V avec l'engagement I donné par le ver. Par conséquent, dans l'algorithme de vérification du schéma de signature, I est calculé à partir de zéro par le vérificateur en exécutant la fonction V et, idéalement, ce I doit être le même que I, ce qui, dans le schéma d'identification, aurait été validé par un vérificateur honnête. Maintenant, pour vérifier la signature de ce que le vérificateur est, il a maintenant la valeur I , il a maintenant la valeur m et les vérifications. Ensuite, il accepte la signature, sinon il rejette la signature. Dans l'idéal, si le signataire et le signataire sont honnêtes, alors le I généré par l'exécution de la fonction de vérification ou de la fonction V sur la clé de vérification r et s aurait donné un I, ce qui devrait être égal à r. Donc, le théorème que nous pouvons prouver ici est que si vous êtes dans le modèle d'oracle aléatoire, et si ce schéma d'identification pi est un schéma d'identification sécurisé, alors le schéma de signature que nous avons généré ici est en effet un schéma de signature sécurisé. La preuve est légèrement impliquée, et nous devons aller dans les détails techniques du modèle d'oracle aléatoire. Donc, je saute la preuve formelle complète, nous allons juste voir un aperçu de la preuve, vous pouvez voir la preuve formelle complète dans le livre de Katz et Lindell. L'idée ici est que si vous voyez la distribution de r que le signataire a généré dans l'algorithme de signature, sa distribution est exactement la même qu'elle aurait été dans une exécution réelle du schéma d'identification, à condition que vous êtes dans le modèle d'oracle aléatoire. Cela signifie que même le signataire est corrompu, il n'a aucun contrôle sur le caractère aléatoire r parce qu'il s'agit d'une valeur uniformément aléatoire, car il s'agit d'une sortie de l'oracle aléatoire. La façon dont nous avons conçu le schéma de signature, dans l'algorithme de signature, le caractère aléatoire r, ou le défi r, que le signataire génère, est fondamentalement une fonction de l'engagement I ainsi que le message sur lequel il veut générer la signature. Donc, si nous avons un adversaire qui veut forger une signature au nom du signataire sans connaître réellement la clé de signature sk, alors fondamentalement ce que le faussaire a à faire est sans connaître la clé de signature, il doit trouver des informations I et de l'état et il doit relever un certain défi r, en interrogeant l'oracle aléatoire, et il doit trouver des réponses s, de sorte qu'il s'agit d'une transcription d'acceptation, c'est-à-dire (I, r, s) est une transcription d'acceptation et pas seulement la sortie de l'oracle aléatoire sur l'engagement I et le message est égal à r. Tout ce qu'il y a à faire sans vraiment connaître la clé de la signature. S'il existe un adversaire qui peut effectivement le faire avec une probabilité significative, alors intuitivement cela signifie qu'il a un adversaire qui peut même forger ou qui peut briser la sécurité de ce schéma d'identification sous-jacent, à savoir, même sans connaître la clé de signature ou la clé secrète, sk, que l'adversaire pourrait arriver avec une transcription légitime de l'acceptation au nom du prover et convaincre le vérificateur et l'accepter. Mais cela va à l'encontre de l'hypothèse selon laquelle le système d'identification sous-jacent est un système d'identification sécurisé. C'est donc une idée intuitive derrière cette transformation de Fiat-Shamir. Je ne vais pas entrer dans les détails formels. (Référez-vous à la diapositive: 10:20)Maintenant, voyons comment nous pouvons appliquer la transformation Fiat-Shamir sur le schéma d'identification dû à Schnorr et, par conséquent, nous obtenons un schéma de signature, que nous appelons Schnorr Signature Scheme. Je souligne que cette transformation de Fiat-Shamir est une transformation générique. Il peut être appliqué à n'importe quel schéma d'identification, sur n'importe quel schéma d'identification à trois tours, pour obtenir un schéma de signature à 1 tour. Nous l'appliquons ici dans le cadre du schéma d'identification Schnorr. Alors, rappelez-le que dans le schéma d'identification Schnorr, la clé secrète:, et le schéma d'identification est le suivant: le prover dans le schéma d'identification veut savoir, pour prouver qu'il s'engage, en soumettant gk. Le vérificateur émet une combinaison linéaire aléatoire r et le tube étalon doit présenter une réponse s. A savoir une combinaison linéaire (mod et le vérificateur vérifie le ∙ − = ou non. Si vous appliquez l'heuristique Fiat-Shamir au schéma d'identification, l'algorithme de génération de clé du schéma de signature sera le suivant: la clé de vérification où la clé de signature correspondante:. En plus de cela, il y aura une description publiquement connue d'une fonction de hachage ⇒ Z, parce que l'espace de défi ici n'est rien que Z. L'algorithme de signature sera le suivant: imaginez qu'il y a un signataire avec un pour signer un message m. Il calcule d'abord l'engagement en choisissant une valeur choisie au hasard, puis il sélectionne le défi au nom du vérificateur en appelant, il calcule le mod de réponse, et la signature est (r, s, m). Pour vérifier la signature, le vérificateur doit générer l'engagement ∙ − et, quoi qu'il arrive, qui est traité comme l'engagement du signataire pour le schéma d'identification Schnorr sous-jacent. Ensuite, le vérificateur génère le défi que cet engagement calculé et le message que le signataire envoie aurait produit, de sorte que le vérificateur appelle la sortie d'oracle aléatoire 1, iff, que le signataire prétend faire partie de la signature. Conformément à la sécurité de l'heuristique Fiat-Shamir, ce schéma de signature à 1 tour est en effet un schéma de signature de sécurité dans le modèle d'oracle aléatoire. Donc, nous avons maintenant un système de signature de candidat basé sur l'hypothèse de log discret. Il s'est avéré que Schnorr a breveté cette idée. Donc, il a fondamentalement breveté son système d'identification à trois tours, de sorte que le système de signature qui sort en appliquant la transformation Fiat-Shamir est également considéré comme breveté, donc nous ne pouvons l'utiliser dans le domaine public. Ce que NIST a fait, c'est qu'il a développé une variation du schéma d'identification de Schnorr et en appliquant la transformation Fiat-Shamir sur cette variante, il a obtenu un schéma de signature basé sur l'hypothèse de log discret, que nous appelons DSA, Digital Signature Algorithm. C'est une norme bien connue que nous utilisons dans la pratique et le groupe sous-jacent que nous utilisons dans cet algorithme DSA est le groupe basé sur le point de courbes elliptiques modulo prime, puis l'instanciation de l'DSA est appelée ECDSA, Elliptic Curve Digital Signature Algorithm et c'est un algorithme de signature numérique très populaire utilisé dans plusieurs applications du monde réel. (Référez-vous à l'heure de la diapositive: 14:48) Donc, maintenant plus ou moins, nous en venons à la fin de la discussion sur la cryptographie à clé publique. Nous avons vu l'instanciation du schéma de cryptage, des signatures numériques, etc. Au cours de la première moitié du cours, nous avons examiné rigoureusement le chiffrement des clés symétriques. Donc, maintenant nous allons voir comment combiner diverses primitives cryptographiques dans les deux mondes, nous avons un vrai protocole de communication sécurisé. Donc ce que je vais discuter est une vue d'ensemble très haute du protocole SSL, qui est en fait le successeur du protocole TLS et ce n'est qu'un aperçu très haut niveau. Nous ne devrions pas traiter la discussion comme une véritable mise en œuvre du protocole SSL pour les détails exacts en fin d'analyse complète du protocole SSL. Vous devez vous reporter à tout texte standard de la sécurité du réseau. Donc, voici comment fonctionne le protocole SSL. Donc, imaginez que vous avez un ordinateur et dans votre navigateur, vous tapez https suivi de xyz.com, par exemple google.com. Donc, dès que vous tapez https, les s ici indiquent que vous voulez lancer une session de communication sécurisée avec le serveur appelé mail.google.com. Et dès que vous tapez ce protocole SSL en cours d'exécution, et dans le cadre de ce protocole SSL, il y a deux sous-protocoles, qui sont exécutés. Il existe un protocole d'établissement de liaison où une interaction se produit entre le client, que le navigateur dans ce cas et le serveur qui est google.com dans ce cas. En ce qui concerne le protocole d'établissement de liaison si tout va bien, une clé est établie entre le serveur et le client. Donc, pour commencer avec le client, et le serveur n'a pas d'informations pré-partagées mais dès que le protocole d'établissement de liaison est exécuté et qu'un échange de clés authentifié se produit entre le serveur et le client. Si le protocole d'établissement de liaison réussit, la clé sera établie entre le serveur et le client. Maintenant, une fois la clé établie, le second sous-protocole qui est en cours d'exécution est le protocole de couche d'enregistrement. Ce protocole de couche d'enregistrement, ce qu'il fait, c'est la communication privée authentifiée entre le serveur et le client à l'aide des clés qui ont été établies au cours du protocole d'établissement de liaison. En termes de primitives cryptographiques pour effectuer l'échange de clés authentifiées, le protocole d'établissement de liaison utilise la cryptographie à clé publique alors qu'une fois que la clé a été établie pour effectuer la communication réelle entre le serveur et le client, le protocole de couche d'enregistrement utilise les primitives de clé privée. Vous pouvez maintenant voir comment exactement les différentes primitives cryptographiques se combinent pour faire ou résoudre l'ensemble du problème de la communication sécurisée ici. Maintenant, allons un peu plus loin dans les détails du protocole d'établissement de liaison et du protocole de couche d'enregistrement. Rappelez-vous donc que le but du protocole d'établissement de liaison est d'effectuer un échange de clés authentifié entre le client et le serveur. Imaginez que le serveur possède sa propre clé publique et une clé de déchiffrement pour un mécanisme d'encapsulation de clé sécurisé CCA et imaginez que nous avons plusieurs autorités de certification disponibles sur le marché qui ont leur propre clé de signature et clé de vérification.Dans cet exemple, je suppose qu'il y a quatre autorités de certification, et je suppose ici que la clé de vérification des autorités de certification est déjà préconfigurée dans le navigateur, qui est utilisé par le client. Ainsi, si vous voulez que vous puissiez accéder aux paramètres du navigateur que vous utilisez et que vous pouvez voir la clé de vérification des autorités de certification bien connues, qui sont déjà intégrées dans vos navigateurs. Je suppose également ici que le serveur dans ce cas dispose d'un certificat délivré par les autorités de certification de deuxième certification certifiant sa clé de chiffrement ou la clé publique et un tel certificat est disponible avec le serveur. Donc, dès que le protocole d'établissement de liaison commence à s'exécuter entre le client et le serveur, le premier message passe du client au serveur, où fondamentalement le client envoie les algorithmes de chiffrement pris en charge, à savoir la version de la fonction de hachage qu'il prend en charge, la version des algorithmes de chiffrement qu'il prend en charge, la version du générateur de pseudorandom qu'il prend en charge, et ainsi de suite, et ainsi de suite que le client envoie la valeur nonce choisie au hasard. En réponse, le serveur choisit une nonce aléatoire, et il envoie les algorithmes de chiffrement qu'il prend en charge, à savoir sa version de fonction de hachage, sa version des algorithmes de chiffrement par bloc, les générateurs de pseudorandom et ainsi de suite. Et avec le fait que le serveur envoie la clé publique de son mécanisme d'encapsulation clé, et pour convaincre que, en effet, cette clé publique appartient au soi-disant serveur, l'expéditeur envoie le certificat qu'il aurait pu obtenir de l'une de ces autorités de certification. Dans cet exemple, il s'agit de la deuxième autorité de certification. Donc, en gros, l'idée ici est que tant le client que le serveur essaient de s'entendre sur la version des algorithmes de chiffrement qu'ils vont utiliser pour le reste de la communication, et avec que le serveur envoie sa clé de chiffrement ou la clé publique et prouver qu'en effet la clé publique appartient au serveur en envoyant le certificat correspondant. Maintenant, ce que le client fait est, il vérifie, ou il vérifie le certificat. Pour vérifier le certificat, il utilise la clé de vérification de l'autorité de certification qui a émis ce certificat sur le serveur, et dans ce cas, le certificat a été émis par la deuxième autorité de certification. La clé de vérification de la deuxième autorité de certification sera utilisée et si seul le certificat est vérifié avec succès, la communication va continuer, sinon le client interrompra la session là itself.Now, il se peut que le certificat soit émis par une autorité de certification dont la clé de vérification n'est pas intégrée dans le navigateur du client. Dans ce cas, cette vérification n'aura pas de sortie. Par conséquent, le navigateur envoie un message d'avertissement à l'utilisateur ou au client, à savoir que, “ je ne peux pas identifier, ou je ne peux pas reconnaître la validité du certificat ”. Il s'agit d'un message d'erreur commun, que nous rencontrons très souvent lorsque nous essayons de faire une communication SSL avec un serveur, dont le certificat ne peut pas être reconnu par notre navigateur. Nous obtenons le message d'avertissement que vous pouvez procéder à vos propres risques. C'est pourquoi il est toujours recommandé de mettre à jour les versions de votre navigateur car chaque fois que vous venez avec votre nouvelle version de votre navigateur, la clé de vérification des nouvelles autorités de certification est intégrée dans les nouvelles versions et vous n'obtiendrez donc pas ce type de message d'erreur. Dans cet exemple, je suppose que la clé de vérification de l'autorité de certification est disponible avec le client et que le certificat est correctement vérifié. Une fois la vérification du certificat effectuée, maintenant ce que fait le client, il exécute l'algorithme d'encapsulation du mécanisme d'encapsulation de clé sous-jacent à l'aide de la clé publique fournie par le serveur. En conséquence, il va générer une clé secrète, que je dénote comme pmk. L'encapsulation de ce pmk n'est que la clé de la prémisse. Ainsi, cet algorithme d'encapsulation va générer une clé de prégénération et son encapsulation c. L'encapsulation c sera envoyée au serveur et ce que le client va faire est, il va exécuter une fonction de dérivation de clé sur les entrées Nc et Ns, à savoir les deux nonces, qui sont choisis respectivement par le client et le serveur, la clé et la sortie du pré-aster sont considérées comme une clé principale. De plus, quelle que soit la communication entre le client et le serveur jusqu'ici, y compris cette encapsulation c, qu'elle soit appelée comme transcription. Ce client de transcription complet s'authentifie en utilisant un code d'authentification de message et en utilisant la clé principale comme clé, et la balise correspondante est envoyée au serveur. Donc, c'est un message maintenant du côté client. Ce que le serveur fait est, il prend l'encapsulation c et exécute l'algorithme de décapsulation sur cette encapsulation c pour obtenir la même clé de préaster pmk. Une fois qu'il obtient la clé de préconfiguration, il exécute la fonction de dérivation des clés sur les deux valeurs nonce et la touche de préconfiguration pour obtenir la clé principale.Donc, comme dans notre hypothèse, le client et le serveur auraient accepté les versions de la fonction de dérivation de clé qu'ils vont utiliser car c'est la partie des algorithmes de chiffrement pris en charge. Il garantit que le client et le serveur utilisent la même version de la fonction de dérivation de clés et la même version du mécanisme d'encapsulation de clé. Maintenant, le serveur effectue également l'étape suivante. Donc, il a vu maintenant l'authentification de l'ensemble de la transcription que le client lui a envoyé, donc il vérifie la balise sur la transcription que le client lui envoie et il abandonne si la vérification de la balise échoue. Si la vérification de la balise aboutit, elle exécute un générateur de pseudorandom sur la clé principale et dégénère quatre clés, qui sont indiquées par kc, kc ’, ks, ks ’. De plus, quelle que soit la transcription que le serveur a déjà vue jusqu'à présent, nous l'appelons la transcription ’ et cela inclut toute la chose que le client lui a envoyée, suivie de l'authentification de la transcription que le client a envoyée au serveur. Toute cette chose que je appelle la transcription ’ et cette transcription ’ est maintenant authentifiée par le serveur à l'aide de la clé principale mk et la balise est envoyée au client. Ce que le client va faire, c'est qu'il effectuera une vérification sur la transcription ’ à l'aide de la clé principale. Si la vérification échoue, elle abandonne, sinon elle exécute également le même générateur de pseudorandom, qui a été exécuté par le serveur sur la clé principale mk, et dériver les quatre mêmes clés que le serveur a générées. Ceci complète le protocole d'établissement de liaison. Maintenant, vous pouvez voir dans ce protocole d'établissement de liaison complet, nous utilisons la primitive de clé publique, à savoir le mécanisme d'encapsulation clé, et avec que nous utilisons la fonction de dérivation de clé et un générateur de pseudorandom. Till the end of the handshake protocol, actual encryptions of the messages, which the client aimerait communiquer au serveur n'est pas arrivé. Till maintenant, seul l'échange de clés s'est produit et l'échange de clés n'appelle que le mécanisme d'encapsulation clé avec la fonction de dérivation de clé et le générateur de pseudorandom. Maintenant, en supposant que le protocole d'établissement de liaison soit correctement exécuté, le serveur et le client ont maintenant deux paires de clés. Chaque fois que le serveur souhaite communiquer quelque chose au client, il exécute un schéma de chiffrement authentifié à l'aide de la paire de clés et de ks ’ et nous pouvons utiliser n'importe quel schéma de chiffrement authentifié ici, disons celui obtenu à l'aide du chiffrement, puis authentifier le mécanisme. En réponse chaque fois que le client souhaite communiquer quelque chose au serveur, il utilise l'autre paire de clés, à savoir la clé kc, et la clé kc ‘.Vous pouvez vous rappeler que dans l'approche générique que nous avions vue pour construire le schéma de chiffrement authentifié, nous insistons sur le fait qu'il devrait y avoir une clé indépendante pour instancier le schéma de chiffrement sécurisé CPA qui se trouve à l'intérieur du schéma de chiffrement authentifié et qu'il devrait y avoir une clé indépendante pour instancier le composant MAC, qui est là dans le schéma de chiffrement authentifié et c'est pourquoi il existe une paire de clés, qui est utilisée dans le schéma de chiffrement authentifié. Nous avons une paire de clés dédiée chaque fois que le serveur veut communiquer avec le client, et nous avons une clé dédiée chaque fois que le client veut communiquer avec le serveur. Maintenant, vous pouvez voir que pour faire la communication réelle entre le client et le serveur, nous utilisons un processus de chiffrement de clé entièrement symétrique. (Référez-vous à la diapositive: 27:45) Pour résumer, nous devons absolument remercier ces deux personnes de génie Diffie et Hellman qui ont pensé à résoudre le problème de l'accord clé alors que l'expéditeur et le récepteur qui sont connectés par un canal sécurisé à la communication publique et qui peuvent encore se mettre d'accord sur une clé privée aléatoire commune connue uniquement pour l'expéditeur et le récepteur. Ce n'est qu'à cause de leur vision et en raison du travail de pionnier, l'ensemble du domaine de la cryptographie à clé publique est apparu et c'est ainsi que nous pourrions penser à faire des communications sécurisées avec toute personne inconnue avec qui nous n'avons jamais rencontré, avec qui nous n'avons jamais partagé aucune information secrète et nous pouvons facilement assurer une communication sécurisée avec ces personnes inconnues. Donc, nous devrions vraiment remercier ces deux personnes en raison de l'impact du travail que ce qu'ils ont fait, ils sont récompensés très récemment pour Turing award. C'est tout pour cette conférence. Donc, juste pour résumer dans cette conférence, nous avons vu, nous avons discuté à un niveau très élevé que nous avons heuristique Fiat-Shamir et comment nous pouvons l'appliquer pour convertir tout schéma d'identification à trois tours en un schéma de signature. Nous l'avons appliquée concrètement pour le schéma d'identification de Schnorr pour obtenir le schéma de signature de Schnorr et nous avons discuté d'une présentation très générale du protocole SSL et d'un protocole TLS. Donc, cela met plus ou moins fin à notre discussion sur le problème de la communication sécurisée. Nous savons maintenant comment faire une communication sécurisée entre deux entités sur un canal public où l'expéditeur et le destinataire peuvent ne pas avoir d'information pré-partagée. Pour les autres conférences, nous verrons comment utiliser des primitives cryptographiques pour concevoir des protocoles interactifs où