 Et voici Haute, ce qui va nous parler de la cryptographie. Bienci, merci beaucoup. Comme il se la vient d'être dit, j'ai travaillé en cryptographie ces dernières six années et j'ai remarqué que la plupart des personnes ont une image mentale de la cryptographie, du chiffrement et parfois cette image mentale ne coincide pas du tout avec la réalité. Et donc je voulais faire une introduction à la cryptographie qui serait accessible à tous. Ça peut être utile à ceux qui n'ont pas de passif en mathématiques ou en cryptosciences. Cette conférence adresse donc à une audience qui n'a pas de formation technique, même si je pense que certains d'entre vous ont ici une formation technique. Mais je le répète, je parlais ici des bases de la cryptographie. En plus de travailler en cryptographie, je m'amuse avec du code, avec des théories mathématiques et j'aime essayer de casser des codes. Voici une photo du chat de mes parents, parce que chaque conférence devrait avoir des photos de chats. Voici ma checklist. La première étape vient d'être accomplie. Ensuite je vais vous expliquer ce que c'est le chiffrement, ce qu'il fait et ce qu'il ne fait pas. Je voudrais vous expliquer l'authentification qui résout des problèmes que le chiffrement ne résout pas. Je vais vous parler des certificats qui résout également des problèmes que l'authentification et le chiffrement ne résout pas. Et je vais vous expliquer comment ces trois choses peuvent être liées entre elles pour arriver à une cryptographie puissante. D'abord je vais vous expliquer ce que c'est que le chiffrement. Le chiffrement est une solution à un problème. Donc parlons d'abord du problème. Le problème ici ou un des problèmes plus classiques est le suivant. Deux parties veulent communiquer. Les cryptographes les appellent souvent Alice et Bob. Alice va envoyer un message à Bob. Ici c'est juste bonjour. Mais la cryptographie a été utilisée par la diplomatie, par les militaires pendant des centaines d'années. Imaginons que ce message soit quelque chose de plus critique. Le problème que nous voulons résoudre est qu'il pourrait y avoir quelqu'un entre les deux parties qui voudrait savoir ce qui voudrait connaître le contenu du message. Ce que certains pensent sur la cryptographie est ça. C'est assez proche de la réalité mais en vrai il y a quelques changements. Alice applique une procédure de chiffrement obscur à son message pour faire une suite de caractères absolument incompréhensible. Bob connaît la procédure de déchiffrement pour inverser le processus de chiffrement et peut ensuite lire le message en toutes lettres. Ce que beaucoup de gens pensent est que la connaissance nécessaire pour déchiffrer un message est secret. Mais aujourd'hui ce n'est plus vrai. En 1883, Auguste Kharkovs a formulé des principes que les codes devraient utiliser. L'un d'entre eux et celui-ci, un code ne doit pas être secret et il ne devrait pas être problématique qu'un code tombe dans des mains ennemies. C'est ce qu'on appelle le principe de Kharkov. Cela veut dire que le code que vous utilisez doit être tellement sécurisé que si l'ennemi apprend comment le processus de déchiffrement fonctionne, cela ne devrait pas mettre à mal la sécurité de la communication. En d'autres mots, si le code que vous utilisez est si faible et tellement faible que vous ne pouvez pas dire comment il fonctionne, vous ne devriez pas l'utiliser. Revenons à notre image précédente. Si l'attaquant sait comment déchiffrer le message, bien entendu le principe de Kharkov tombe. Ce qu'on a fait, c'est qu'on a introduit une clé. Donc le processus de chiffrement utilise une clé. Donc Alice fait un calcul qui se base sur le chiffrement et la clé et Bob a la même clé et peut déchiffrer le texte. Dans ce cas-ci, la clé est connue de Alice et Bob, mais pas l'attaquant et donc l'attaquant ne peut rien déchiffrer. Je ne vais pas entrer dans les détails du chiffrement, mais dans ces boîtes que vous voyez sur la diapositive, dans les boîtes qui représentent le chiffrement et le déchiffrement, il y a des algorithmes très compliqués. Je ne vais pas entrer dans les détails sur ces algorithmes afin de protéger la simplicité de cette conférence. Alice et Bob doivent tous les deux être d'accord sur la clé. Donc Alice ne peut pas envoyer la clé à Bob. Si elle le fait, l'attaquant qui écoute la connexion connaît la clé et ainsi l'attaquant n'a plus qu'à utiliser la clé pour déchiffrer le message au même titre que Bob. Donc c'est stupide d'en rile la clé sur le même canal de communication. Ce qu'on a fait pendant le dernier siècle, c'est utiliser ce processus de chiffrement qui s'appelle chiffrement symétrique. Parce que si on inverse l'image, eh bien Bob peut aussi envoyer un message à Alice en utilisant la même clé. Vous imaginez bien que si on parle de chiffrement symétrique, il y a aussi un chiffrement asymétrique. Et là il y a une paire de clés. L'une est utilisée pour le chiffrement et l'autre est utilisée pour le déchiffrement. Et dans un schéma de chiffrement asymétrique, voilà ce qu'on fait. Bob a la clé de déchiffrement, Alice a la clé de chiffrement. C'est pour cela que l'on appelle la clé de déchiffrement la clé secrète. Alice peut publier sa clé de chiffrement de manière publique, mais il faut toujours la clé secrète pour déchiffrer le message. Un attaquant peut avoir la clé de chiffrement, mais ce n'est pas grave puisque celle-ci est publique. Ensuite, la clé de chiffrement est utilisée par Alice pour chiffrer un message, mais la clé de déchiffrement est toujours nécessaire. L'attaquant n'a pas cette clé de déchiffrement et donc il ne peut pas déchiffrer le message puisqu'il n'a pas la clé secrète. Mais cette solution reste risquée. Il y a encore un problème en effet, c'est qu'il faut s'assurer que les clés sont distribués à l'avance. Si on utilisait le schéma simple où Bob envoie sa clé publique à Alice, alors il y a un problème si l'attaquant interfère activement avec la connexion. Par exemple, ce tiers-partie pourrait intercepter l'envoi de la clé publique que Paul Bob envoie à Alice et la remplacer avec sa propre clé publique. Et dans ce cas, Alice pensera que la clé qu'elle a reçu appartient à Bob et pourrait l'utiliser pour chiffrer son message, mais l'attaquant pourrait le lire. Alors pour résumer, le chiffrement masque le contenu d'une donnée. C'est ce qu'il fait et c'est à peu près la seule chose qu'il fait. En particulier, ça veut dire qu'il ne masque pas le fait qu'il y ait une communication. Et donc un tiers-partie qui écoute la communication peut voir que Alice envoie un message à Bob et rien que ça peut être déjà dangereux dans certains cas. Imaginez par exemple le cas où Alice travaille pour l'Agence de l'Enseignement et Bob et le journaliste. L'attaquant voyant Alice envoyer beaucoup de documents à Bob pourra avoir une bonne indication que Alice est une lanceuse d'alerte et elle pourrait être mise en prison. Alors une autre chose qui n'est pas cachée par le chiffrement, c'est la quantité de données qui étaient changées. Si Alice envoie juste un court message, alors le tiers-partie qui écoute la communication peut deviner que le message envoyé n'est pas un dossier de 20 Giga. Donc toutes ces sortes de métadonnées sont des choses que le chiffrement ne peut dissimuler. Il y a également d'autres problèmes. L'un d'elles est que l'attaquant peut changer le message. Protéger, contrôler ces changements n'est pas le rôle du chiffrement. L'autre problème, on l'a déjà vu, c'est que les clés doivent être échangés en avance. Encore un autre problème est que l'attaquant peut enregistrer le message lorsqu'il est envoyé et ensuite repasser par Bob, ou alors il pourrait aussi intercepter le message et le jeter fait en sorte qu'il n'arrive jamais jusqu'à Bob. Le premier problème ici, c'est que l'attaquant peut changer le message et ça me amène au deuxième point de cette présentation, c'est-à-dire l'authentification. Alors qu'est-ce que c'est l'authentification ? C'est ce qui permet de détecter les changements dans les données. Ça ne permet pas d'empêcher les modifications, mais ça permet seulement le dessinateur de détecter qu'il y a eu des changements qui ont été faits. Par exemple, un cas où l'authentification peut être nécessaire, c'est lorsque Bob envoyait sa clé publique à Alice. Mais ce n'est pas le seul scénario où c'est important. Il mesure par exemple qu'Alice soit à la tête d'une organisation caractéristique, qui serve des réfugiés dans la mer méditerranée et que Bob veut lui donner de l'argent pour l'aider à faire ceci. Alors Alice doit envoyer son numéro bancaire à Bob pour que Bob puisse faire cette donation. Dans ce scénario, le message qu'Alice envoie à Bob, c'est son numéro bancaire, n'est pas vraiment un secret, il n'a pas besoin d'être chiffré. C'est une information qui peut largement être publique. Cependant, il est important de s'assurer que le message qui arrive à Bob est bien le bon numéro bancaire de compte bancaire pour empêcher un cas comme celui qui est à l'écran d'arriver, c'est-à-dire un cas où un criminel intercepte le message et remplace le numéro de compte bancaire pour que Bob envoie de l'argent au criminel à la place d'Alice. Une manière de parvenir à l'authentification est d'avoir une paire de clés, une utilisé pour l'antification et une utilisé pour la félicitation, c'est-à-dire vérifier que le message a été changé ou pas. La clé de identification doit être secrète, c'est la clé secrète, alors que la clé de vérification peut être une clé publique. Si vous avez une configuration comme celle-ci, alors Alice peut prendre le message qu'elle va envoyer, lui appliquer à un processus avec sa clé secrète pour arriver à ce qu'on appelle une signature numérique. Ensuite, elle peut envoyer cette signature à Bob, en même temps que le message contenant son numéro de compte bancaire. Et Bob peut prendre la signature qu'il reçoit ainsi que le contenu du message, lui appliquer un calcul grâce à la clé publique qui lui permettra de vérifier si le numéro de compte bancaire a été changé ou si c'est bien le numéro original. Si l'attaquant change le numéro de compte bancaire, Bob pourra le détecter en vérifiant la signature. Cela marche même si l'attaquant change non seulement le numéro de compte bancaire, mais aussi la signature. Cela rend impossible pour l'attaquant de forger une signature valide pour autre chose que le message original. La seule manière dont Bob pourra accepter la signature qu'il reçoit, c'est si l'attaquant ne change pas le numéro de compte bancaire. Et dans ce cas-là, Bob peut, en toute sécurité, envoyer l'argent au numéro de compte. Une autre solution au même problème. C'est en fait très semblable à la solution précédente, mais cette fois nous avons une seule clé utilisée pour l'antidification et la vérification. Et dans ce cas, les choses ont un nom différent, mais elles fonctionnent de la même façon. La signature est appelée, cette fois, un message d'authentification en acronyme anglais Mac. Très bien. Dans ces deux scénarios, qu'est-ce qu'on a ? Ils en soient une deux clés différentes ou une même clé, mais il reste le problème de la distribution de ces clés. Imaginez que dans le scénario avec deux clés, Alice envoie sa clé publique à clé et on aurait eu la même possibilité d'attaquer avant, c'est-à-dire que l'attaquant pourrait changer la clé publique envoyée par Alice à Bob et la remplacer par sa propre clé. Ainsi, si l'attaquant envoie sa propre clé publique ou sa clé de vérification à Bob, alors il pourra par la suite créer une signature valide pour le numéro de compte bancaire qu'il voudra envoyer à Bob et Bob l'accepterait. Il y a donc encore une fois le problème de la distribution des clés, qui est que la clé de vérification doit être connue de Bob en avance. Cela me conduit à la prochaine section de cette présentation. Tant que l'authentification a été faite, nous allons essayer d'expliquer les certificats. Un certificat est un document qui confirme qu'une clé publique spécifique appartient bien à une entité spécifique, c'est-à-dire à une personne ou une organisation. Si on veut utiliser des certificats, alors repartons au scénario que nous avons précédemment. Alice va envoyer un numéro de compte bancaire, sa clé publique et sa signature à Bob et le problème c'est qu'un attaquant pourrait changer la clé publique, le numéro de compte bancaire et la signature. Si on a un produit certificat, ce qu'elle veut nous savoir c'est une autorité certificatrice, c'est-à-dire un tiers parti de confiance qui crée des certificats qui confirment l'association entre une personne et sa clé publique. Avant qu'Alice envoie un message à Bob, elle peut se rapprocher de l'entité certificatrice, lui donner sa clé publique et demander un certificat pour sa clé publique. Le certificateur pourra vérifier que Alice est bien Alice, que Alice possède bien sa clé publique et si Alice passe ses vérifications, alors l'autorité certificatrice va créer un certificat qu'elle pourra donner à Alice, c'est-à-dire un document qui confirme que l'autorité certificatrice a vérifié que la clé fournie appartient bien à Alice. Une fois qu'Alice a ce certificat, elle peut envoyer sa clé publique à Bob accompagné du certificat et ensuite Bob, s'il connaît l'autorité certificatrice, peut vérifier auprès de celle-ci que le certificat est bien correcte, c'est-à-dire que le certificat a bien été créé par cette autorité, et s'il fait confiance à cette autorité, il saura que la clé qu'il a reçu est bien celle d'Alice. Ainsi, plus tard, Bob saura que cette clé publique est bien celle d'Alice, et vérifier qu'elle n'a pas été changée dans les futurs messages qu'elle recevra. On n'est pas complètement libérés du problème de distribution des clés cependant, car Bob doit savoir la clé publique de l'autorité certificatrice par avance. Il n'est pas besoin de connaître celle d'Alice en avance, certes, mais il doit connaître celle de l'autorité certificatrice en avance. En pratique, il n'y a pas une seule autorité certificatrice, mais on a un certain nombre, et celles-ci peuvent même créer des certificats pour d'autres autorités certificatrices. Ainsi, Bob ne doit pas connaître toutes les autorités publiques, de tous les gens avec qui il communique, mais il doit uniquement connaître les clés publiques de quelques autorités certificatrices. Pour résumer sur les certificats, comme je l'ai déjà dit, le certificat confirme qu'une clé publique spécifique appartient à une entité spécifique, mais nous ne sommes pas libérés du problème de la distribution des clés publiques, car les gens doivent savoir la clé publique de l'autorité certificatrice. Un autre problème ici, c'est que cette manière de fonctionner donne élan de pouvoir aux autorités certificatrices. Ainsi, si un attaquant peut compromettre une autorité certificatrice, alors il pourrait forcer cette autorité à créer de faux certificats, faisant le lien entre des fausses clés et des identités réelles. Il pourrait créer des faux certificats qui dirait que l'autorité certificatrice a vérifié que la clé publique de l'attaquant appartient à un anniversaire. Pour résoudre ce problème de pouvoir des autorités certificatrices, et quelque chose que ceux qui travaillent sur le chiffrement travaillent encore sur ce problème aujourd'hui. Ce n'est pas qu'un problème théorique, il y a un certain nombre d'incidents qui sont venus avec les autorités certificatrices, et un de ces cégants plaît que l'autorité nommée Diginotar a été hackée et l'attaquant avait créé un faux certificat pour un non-domaine Google.com ou un non-domaine de Google, je ne suis un peu local exactement, et ce certificat a été utilisé en Iran. Vous voyez que ce n'est pas juste un problème théorique, c'est quelque chose qui est bien arrivé. Voilà qui conclut ce que je voulais dire sur les certificats. Voyez maintenant comment toutes ces différents concepts peuvent être mises ensemble pour construire des outils puissants. L'un d'entre eux s'appelle le chiffrement authentifié. C'est une combinaison entre le chiffrement et l'authentification. Ce procédé est souvent utilisé dans les cas symétriques, où une clé est utilisée pour le chiffrement et une clé est utilisée pour l'authentification. Cela peut être recréé dans un schéma de chiffrement asymétrique. Dans ce cas, ça ne s'appelle plus le chiffrement authentifié. Un des moyens de le faire, si Alice va envoyer un message à Bob, elle va chiffrer le message utilisant la clé de chiffrement, elle va envoyer le message chiffré à Bob, puis elle va utiliser une copie du message chiffré pour générer un code d'authentification utilisant la deuxième clé. Alice envoie ce message d'authentification à Bob. Et Bob peut déchiffrer le message utilisant la clé qui lance la possession. Et Bob peut voir si ce message a été altéré ou si il est original en utilisant la procédure de vérification. De nouveau, ce type d'authentification n'empêche pas d'altérer un message, mais par contre, Bob peut s'assurer de l'originalité du message. Cette technique permet d'augmenter la sécurité d'un message. Voici le chiffrement hybride. C'est une sorte de mélange entre la technique symétrique et asymmétrique. Si on va envoyer un message très long à Bob et qu'il n'y a qu'une clé publique et donc un schéma symétrique, cela prendrait beaucoup de temps de chiffrer et de déchiffrer le message. Cependant, on peut combiner les techniques symétriques et asymmétriques afin que le processus de chiffrement soit plus rapide. Alice envoie un message à Bob. Elle génère une nouvelle clé pour le schéma symétrique. Elle envoie le message chiffré à Bob et ensuite, elle va prendre la clé symétrique qu'elle vient de générer. Elle va chiffrer cette clé avec la clé publique de Bob. Et cette clé est ensuite envoyée à Bob. Bob peut décrypter, déchiffrer la clé en utilisant sa clé secrète, celle qui est en or sur le slide. Et ensuite, il va utiliser la clé symétrique déchiffrée pour déchiffrer le message. Cependant, un attaquant qui écoute... Cela signifie plutôt que l'attaquant qui écoute Alice et Bob ne peut pas déchiffrer le message parce qu'il n'a pas la clé secrète de Bob. On peut continuer et on se retrouve avec quelque chose qu'on appelle la sécurité couche transport ou TLS. C'est un protocole de transport qui combine le chiffrement, symétrique ou hybride, l'authentification, les max, les signatures et les certificats et à cela s'ajoute d'autres choses comme la détection des réenregistrements du message. TLS peut aussi détecter si un message a été altéré par un attaquant et ce à l'intérieur même de la connexion. TLS permet d'établir une connexion sécurisée entre deux entités comme Alice et Bob sur un réseau qui est non sécurisé. Une des applications fréquentes de TLS est pour l'envoi d'e-mail par exemple. Alice veut envoyer un message à Bob. L'e-mail n'est généralement pas envoyé directement mais l'e-mail passe par un serveur e-mail qui sera envoyé au serveur de Bob et quand Bob se connecte pour aller voir ses e-mails, l'e-mail sera téléchargé sur son appareil électronique, son smartphone ou son ordinateur et Alice peut s'assurer que lors de l'upload de son e-mail sur son serveur la connexion est sécurisée et ce rien quand chiffrant le message en utilisant TLS et tout ce que TLS implique au niveau de l'authentification au niveau du chiffrement etc. Cependant Alice ne peut pas voir si son serveur utilise une connexion sécurisée pour envoyer l'e-mail au serveur e-mail de Bob. Observons cela de manière plus détaillée. Chaque cadena vert représente une connexion sécurisée et donc dès qu'une connexion sécurisée est faite il y a à chaque fois un chiffrement et une authentification puis un déchiffrement et une vérification et comme vous pouvez voir sur la diapositive le message est chiffré, authentifié, déchiffré et vérifié plusieurs fois et ce jusqu'à Bob et une fois de plus Bob à la fin de la chaîne recevra un message et qu'il devra déchiffrer et vérifier. Cependant dans ce cas de figure bien que le message est chiffré à chaque fois qu'il est envoyé sur le réseau le serveur d'Alice et le serveur de Bob reçoivent le message en texte clair et pour cela il y a une technique qui s'appelle le chiffrement de transport pour éviter que le message se retrouve déchiffré sur le serveur. Pour éviter cela on utilise une technique qui s'appelle le chiffrement point à point. Alice va donc directement chiffrer son message avec la clé publique de Bob. Alice envoie ce message chiffré sur son propre serveur puis celui ci sera chiffré et authentifié et dans ce cas là le serveur ne peut pas retirer cette première couche de sécurisation. À chaque fois que le message sera déchiffré ce qui l'en restera sera un message chiffré par la clé publique de Bob. Lorsqu'il arrive sur le serveur de Bob le message sera de nouveau déchiffré et vérifié et Bob n'aura plus qu'à utiliser sa clé qui l'a en sa position et enfin Bob peut lire le message. L'avantage est que les serveurs ne peuvent pas lire les messages parce qu'ils seront toujours chiffrés par la clé publique de Bob. Cela étant dit je voudrais maintenant conclure. Voilà quelques informations que j'aimerais que vous reteniez. Le chiffrement cache le contenu des données c'est tout. Il ne cache pas les métadonnées. Il ne permet pas le chiffrement ne permet pas un message de garder son originalité. Pour le chiffrement et l'authentification il faut des clés qui doivent pouvoir être distribués en amont. Un des moyens de faire cette distribution de manière assez simple est d'utiliser des certificats afin de confirmer que la clé appartient bien à une entité spécifique. Ainsi on peut établir un protocole de réseau qui permet de transférer des messages d'un point à un autre de manière sécurisée. Mais le chiffrement transport est inférieur au chiffrement en point à point parce que les intermédiaires peuvent toujours lire le message envoyé. Ce qui n'est pas le cas dans le chiffrement de point à point. C'est ainsi que ce conclut ma conférence. Je suis ouvert à toutes les questions. Si il y a des questions que vous ne pouvez pas me poser maintenant, vous pouvez toujours m'envoyer un email sur l'adresse qui s'affiche. Je tâcherai de la garde ouverte pendant un ou deux ans. Merci pour votre intervention. Nous arrivons à la partie de questions-réponses. N'hésitez pas à venir auprès des micros parce qu'il y a des questions qui nous viennent de l'Internet. Nous avons encore le temps si vous avez des questions, n'hésitez pas. Près à la question au micro numéro 2. Bonjour et merci pour cette présentation. J'aimerais savoir comment est-ce qu'on peut changer un message qui a été déchiffré adéquatement, sans que le receveur ne sache que vous avez fait ce travail. Alors ça dépend de la méthode de chiffrement que vous utilisez. Pour le faire des méthodes, changer le message est en fait assez facile. Il y a beaucoup de méthodes chiffrement qui fonctionnent en remplissant quelques bits. Le message est fait composer deux bits et votre méthode de chiffrement vous permet de déterminer lequel de ces bits changer et lesquels conserver à la même place. Ainsi quand vous chiffrez, vous utilisez ce méthode de chiffrement pour déterminer quelles bits devraient être changées de 0 à 1 ou de 1 à 0 et que vous appliquez ce changement au message qui est envoyé. Ensuite le dessinataire peut juste défaire cette opération pour revenir au message original. Alors qu'un attaquant qui ne sait pas quelles bits ont été changées ne peut pas. Cependant, l'attaquant peut changer lui-même un certain nombre de bits et dans ce cas, ils mesulons par exemple que des bits ont été changés par Alice et qu'ils ont été changés à nouveau par l'attaquant. Quand Bob va tenter de faire les changements, il va arriver un message transformé. Il y a quelques différentes choses que vous pouvez faire avec ce type de changement appliqué au message. Ce n'est pas que le dessifrement ne marche pas, c'est juste qu'il vous donne le mauvais résultat dans ce cas de figure. Merci pour cette question s'il vous plaît. Vous avez dit que le chiffrement ne concerne pas les métadonnées. Est-ce qu'il y a d'autres solutions pour chiffrer les métadonnées ? Eh bien c'est assez dur à faire. Ce que je veux dire c'est que pour les emails par exemple, il y a l'idée aussi de chiffrer le sujet du message qui souvent ne l'est pas. Mais par exemple si vous voulez cacher la taille du message, ce que vous pouvez faire c'est simplement compléter le message en s'arrangant des choses inutiles à la fin pour masquer sa longueur réelle. L'attaquant aura donc une limite maximale de la taille de message, mais il ne sait pas à l'intérieur de cette limite la taille de votre message. Il sait juste qu'il est au maximum aussi long que le message qui est transformé. Si vous voulez décimer votre identité en vache, là il faut utiliser quelque chose comme tord ou vous n'êtes pas connecté directement à la personne avec laquelle vous souhaitez communiquer. Mais vous avez l'est par le biais de certains intermédiaires. Il y a d'une certaine façon que aucun des intermédiaires ne connaît à la fois votre identité et celle du dessinateur. Je pense que nous avons une question arrivant d'internet. Alors internet demande si vous pouvez dire quelque chose sur la consommation électrique du chiffrement à l'échelle mondiale. Malheureusement je ne sais pas combien d'énergie est consommée par le chiffrement. En revanche, en ce qui concerne la puissance de calcul, le chiffrement symétrique est assez simple. Les circuits des processeurs sont tout à fait capables de déchiffrer des centaines de méga octets de données en quelques secondes. Malheureusement je n'ai pas de chiffres mais vous pouvez estimer si tout le monde dans un pays développé utilise le chiffrement du jour au lendemain il y aura effectivement des répercussions. Vous avez mentionné plusieurs fois qu'un attaquant peut être en mesure de jouer à nouveau un message. Je comprends pas en quoi ça bénéficierait à l'attaquant. Imaginez que Alice envoie à Bob un ordre bancaire pour lui transférer de l'argent et à chaque fois que la banque reçoit un tel ordre, elle commence à se transférer. En tant que attaquant, ça peut être intéressant. Si vous avez réussi à intercepter ce message, vous pouvez répéter cette ordre bancaire et de plus en plus d'argent sera envoyé. Si c'est vous le destillateur, ça peut être très intéressant et vous pourriez complètement envidé le bancaire d'Alice. Ensuite une question du micro numéro 3. J'assistais une conférence sur la cryptographie et je me demandais quelle pourrait être l'application de la code Langtie. Attendez, je me rends sur la bonne slide. Habituellement, les chiffrement et les combats électriques sont utilisés dans les boîtes de chiffrement et de chiffrement. C'est des procédés mathématiques. Je ne suis pas rentré pour rester accessible à une danse spécialiste, mais une des manières d'arriver à ces chiffrement et d'utiliser ces courbes électriques dans ces procédés de chiffrement. Microphone numéro 1. Une autre limitation qui me vient à l'esprit. L'internet des objets ont des capacités calculatoires limitées. Est-ce que ce ne serait pas une limitation au chiffrement ? Il y a des recherches sur des techniques de chiffrement très légères qui seraient particulièrement appropriées pour ce genre d'objet. Mais pour autant que je sache, il y a quelques faiblesses dans les résultats de ces recherches. Malheureusement, il n'y a pas les mêmes garanties sécuritaires dans ces objets que si vous avez des objets avec des ressources plus grandes. Vous avez mentionné le pouvoir que les autorités de certification peuvent avoir. Je me demandais quelles sont les solutions possibles qui existent à l'état de l'art pour résoudre ce problème. Une des solutions qui existent est la transparence des certificats qui fonctionnent en créant beaucoup de log public où tous les certificats qui sont créés doivent être ajoutés à ce fichier de log. Si par exemple vous êtes Google et que vous voyez quelqu'un créé un certificat Google dans votre log et que vous savez que vous n'avez pas demandé de certificat, alors vous savez qu'il y a un faux certificat qui a été créé. Dès que vous recevez un certificat, on attend de vous que vous vérifiez que ce certificat est bien entré dans ce fichier de log. Est-ce que ça répond à votre question ? Oui, mais comment est-ce qu'on ajoute un certificat ? Comment est-ce qu'on reconnaît qu'un certificat est légitime ? Eh bien l'idée c'est que je vois que vous recevez un certificat, il est ajouté dans ce fichier de log et tout le monde qui reçoit un certificat, on attend de lui qui vérifie que le certificat est bien dans ce fichier de certificat. C'est comme ça qu'on n'espère que ça marche en tout cas. Dernière question d'Internet. Internet aimerait savoir si on peut avoir une authentification pour des clés PGP et dans ce cas comment l'appliquer à une clé ? Est-ce que c'est possible ? Ça dépend, j'imagine, avec PGP le modèle le plus commun est qu'il n'y a pas d'autorités qui distribuent des certificats mais plusieurs. Donc on peut établir un grave social avec les gens qui se connaissent et qui échangent des emails et chacun de ces utilisateurs devrait authentifier la clé publique de leur père. Donc si vous voulez communiquer avec quelqu'un que vous ne connaissez pas mais qui pourrait être un ami d'ami, eh bien espérons que votre ami aura authentifié la clé publique de son ami et si vous faites confiance à votre ami, eh bien vous pouvez vous assurer que votre ami a créé un certificat pour son ami. Est-ce qu'il y a d'autres questions d'Internet ? Une autre ? Je ne sais pas si c'est une question qui concerne vraiment le sujet mais quelqu'un veut savoir, est-ce que vous recommanderiez TLS ou plutôt SSL dans les emails ? Eh bien ce qui me concerne, j'y recommanderai toujours à utiliser les chiffres sur les coups extérieurs, en particulier sur l'envoi à votre serveur email. Par exemple ce protocole SMTP qui vous relient sur le serveur. Je pense qu'établir une connexion sécurisée dès le départ est une meilleure manière de faire avec un TLS ajouté posteriori. La cabine française vous remercie.