 bienvenue nos prochains orateurs sont sofiane soli et yore van bergen et vous parlez de de pas de preuves de communication entre et de moralité des protécoles donc sur le protécole off de récord version 4 et nous sommes yota et les méda votre adducteur n'hésitez pas à nous donner tous vos retours sur twitter hashtag c3t ou sur c3lingo.org et je vous laisse souhaiter la bienvenue à sofia bienvenue ça c'est sofia et ça c'est yore donc on va présenter donc on va faire une présentation sur le protécole off de récord et on l'a on l'a appelé no proof of communication et vous allez voir pourquoi donc quand on a quand on a voulu présenter la version 4 dothéa donc on voulait montrer déjà pourquoi on a besoin de sécurité on veut c'est on veut citer un article de cryptographie les plus connues qui a été fait par rogaway et donc il dit que la plupart des cryptographie académique pensent que leur leur domaine c'est c'est intéressant c'est profond et c'est c'est politiquement neutre donc c'est juste un cet énigme qui implique des gens qui communiquent et des adversaires et donc cette vision c'est c'est vraiment c'est impressionnant mais mais en même temps est ce que est ce que le est ce que c'est vraiment ça est ce que le monde dans lequel on vit c'est c'est le monde qu'on a envie de vivre et donc il faut faut vraiment qu'on qu'on fasse les choix qui qui vont influencer le monde pour que les gens qui vivent dans ce monde et le monde qui veulent et donc si on a un algorithme et des choses comme ça il faut aussi penser aux décisions éthiques et donc évidemment rogaway il adresse un certain nombre de points sur sur son article mais il y en a un qui parle surtout du principal problème de notre présentation donc c'est c'est le problème que du de la messagerie sécurisé donc évidemment il y a eu de la recherche évidemment il y a eu des options mais ça il n'y a jamais eu de recherches aussi insensives et donc pourquoi on publie otr dans sa version 4 c'est que dès le début otr en fait a voulu résoudre ce problème de la de la messagerie sécurisé et sécurisé bien sûr donc on va on va on va regarder les parties d'otr qui qui mettent les limites d'otr quand on quand on écrit notre protocole donc une des objectifs c'est c'est de résoudre le problème de la communication secrète donc c'est c'est un problème courant parce que tout le monde communique avec tout le monde et donc c'est un problème qu'on a vraiment besoin de résoudre et donc il faut pouvoir donner aux utilisateurs des options qui fonctionnent et parfois les les options de sécurité pour les utilisateurs ne donnent pas vraiment d'options utilisables et parfois ils ne donnent pas de conseils sur aux utilisateurs pour comprendre ce qu'ils font et donc donc il faut faut pas qu'on ait seulement trois articles de blog ou une moitié de documentation pour faire ça il faut vraiment qu'on ait une base solide et faut qu'on puisse dire non seulement ce que et quels algorithmes sont utilisés mais aussi comment ils sont utilisés et comment ils ils sont en relation les uns avec les autres c'est pas suffisant de décrire le protocole il faut aussi il faut aussi montrer pourquoi la cryptographie fonctionne avec tous ces algorithmes et comment ça tient compte de différentes attaques donc par exemple les problèmes de cofacteur ou ce genre de choses donc on a vraiment besoin de spécifications et donc il faut aussi définir quelle qu'elle propriété du protocole chaque composant va fournir et parfois il parfois on va on va assurer une sécurité persistante parfois on va assurer d'autres choses mais un protocole ne peut pas tout résoudre à l'époque dans otr comme vous allez voir dans les slides qui viennent on voulait gérer les algorithmes post quantiques donc évidemment les algorithmes quantiques si vous avez vu le talk sur les sur la cryptographie post quantique vous voyez que les algorithmes post quantiques sont pas encore assez bons pour être déployé et on a aussi besoin de protocole qui met à jour des spécifications existantes et donc les gens disent souvent pourquoi on devrait on devrait mettre à jour vers un autre protocole alors que quand on a un qui qui a l'air de marcher correctement mais il a l'air de marcher correctement mais mais l'académie qui essaye encore de raffiner les définitions et de mettre ça au clair et donc on a besoin de faire ses mises à jour et en plus ces protocoles ont besoin de vérification parce que ça on n'a pas enfin ça suffit pas de de publier ce protocole et de voir si ça marche mais on a besoin de vérification et on a besoin d'implémentation donc c'est du code qui qui peut marcher sur plusieurs systèmes d'exploitation et qui peuvent compiler et fonctionner et plus important encore on a besoin de plein d'idées de plusieurs endroits donc une bonne partie de hauteur v4 en fait viennent d'Amérique latine surtout d'équateur et donc on a besoin d'idées qui viennent un peu d'ailleurs parce que ça suffit pas d'avoir des idées qui viennent d'un côté du monde et les imposer en fait ailleurs il faut vraiment avoir des idées de partout dans le monde pour attirer l'attention donc maintenant on va parler de ce qu'est hauteur et de ce qu'est dénayabilité donc là le dénaillable donc 3 personnes ont écrit un papier en 2004 ce qu'ils voulaient c'était avoir des algorithmes de messager qui auraient le même comportement que des conversations que vous auriez dans le monde réel par exemple ce que pgp a fait c'est permettre de signer des messages c'est à dire le dire ok ce message vient vraiment de moi et ce qui se transcrivent dans le monde réel par exemple chez une conversation avec sofi et si on a une conversation juste entre nous personne ce qui est personne ne sait ce que l'on a effectivement dire donc vous pouvez inclure ça dans un protocole cryptographique donc c'est ce qu'ils ont fait ensuite ils ont ce qu'ils ont fait à subir plusieurs révisions on veut authentifier quelqu'un et parfois on veut aussi vérifier que que la personne contrôlée son son compte en fait via xmpp ou irc on veut vérifier que c'est bien la personne qu'on attend qui qui est enfin on veut en fait une façon de vérifier qui est la personne qui nous parle donc on a on a pas mal de protocoles de messagerie sécurisé et en fait quelques unes des propriétés d'otr donc c'est l'authentification il y a un échange de clé authentifié donc il y a le protocole signe signa sigma donc et en fait ce qui est différent avec otr4 on a enlevé la partie signer mais mais ça marche toujours grâce grâce en fait au hâchage de message parce que parce que vous avez ces signatures avec les le hâchage et donc la vérification le protocole du millénaire socialiste permet d'avoir une vérification vous pouvez comparer des des empreintes et vous pouvez poser une question et vous assurez que qu'il y a que cette personne à qui vous adresse et qui peut répondre à la question et en plus de ça il faut aussi une une chiffrement de bout en bout donc ça veut dire que tous les messages sont sont chiffrés du début à la fin donc quelque chose d'autre qui est important c'est c'est la sécurité persistante et donc ça veut dire que c'est l'utilisation de clé unique en fait pour pour le chiffrement de chacun des messages donc ça veut dire que si si vous donnez enfin si le serveur est compromis l'attaquant peut quand même pas déchiffrer les données de la communication et enfin la sécurité post compromis c'est que même si un message est compromis en fait les messages suivants ne peuvent pas être être déchiffrés même si si Alice et Bob donc si Alice et Bob communiquent avec un protocole post compromis en fait on peut pas savoir on peut pas si on déchiffre un message on peut pas avoir les autres donc concernant la déniabilité le déni posible qu'on appelle aussi parfois la répudiabilité concilier un scénario où Bob accuse Alice of sending a specific message si Bob accuse Alice d'avoir envoyé un certain message Bob va être capable de fournir des preuves que Alice a effectivement envoyé ce message et donc si si Bob prouve qu'Alice a envoyé ce message en fait on dit que donc ce message n'est pas n'est pas répudiable en fait donc il ya il ya deux types il ya plusieurs types de messages donc d'une certaine façon on peut montrer qu'on peut démentir qu'on a envoyé un message on peut aussi démentir qu'on a participé à une conversation et du point de vue offline en fait on a eu une conversation on a fini la conversation et en fait le côté offline ça veut dire que quelqu'un qui essayerait de faire collusion avec avec avec certaines personnes ne peut pas vérifier que cette conversation a bien eu lieu donc les protocoles de cryptographie sont pas la panacée donc on peut pas on peut pas juste se se caler sur un de ces protocoles et dire qu'on est qu'on est parfaitement sûr et donc et donc un protocole est fortement répudiable si si vraiment il ya pas il n'y a pas de preuve même sur le long terme que que des communications ont eu lieu donc en fait ce qu'on a essayé de faire dans la version 4 de hauteur c'est avoir des nouvelles propriétés auto gaffrique donc à la fois sur la répudiabilité en ligne républicain en ligne donc pourquoi ça n'a pas été utilisé c'est que en fait dans l'académie il n'y avait pas enfin il y avait déjà des termes et donc dans le protocole de version 4 on voulait réutiliser ce que ce qu'a fait ce qu'a fait l'académique de façon à ce que les les gens du monde réel peuvent puissent utiliser tout ça donc là on a montré une comparaison entre les différents protocoles de messagerie sécurité donc hauteur la majorité des des propriétés pleinement parfois on a on a seulement un support partiel de la propriété et on voulait vraiment être clair avec hauteur qu'on a qu'on a quand même des délimitations et que hauteur à des limitations il faut on y pas tout et donc certaines certaines des propriétés et ce qu'on a fait le le survol de ces protocoles est peut-être pas et peut-être pas parfait parce que on s'est juste basé sur sur la littérature qui en parlait des postes de blog et tout ça et peut-être que c'est pas tout à fait à jour donc faites attention donc pourquoi une quatrième version de terre donc on voulait plus d'habilité donc dans toutes ces formes à la fois sur la participation sur les messages en eux même en ligne et en ligne on voulait également de la une confidentialité persistante parfaite de même pour la confidentialité post-comprémission on voulait un niveau de sécurité plus élevé on voulait également mettre à jour des les primitives utilisés en les primitives cryptographiques utilisé et pour utiliser des primitives qui ont qui ont été analysées suffisamment et on a également voulu utiliser des protections supplémentaires contre le déchiffrement dans le cas de des courbes électriques compromises et on voulait utiliser les courbes électriques parce que en fait on voulait on va peut-être on va peut-être changer d'avis mais pour l'instant on attend encore on attend encore que tout ça soit soit testé mais si si les machines quantiques viennent en fait au moins on utilisera des l'algorithme de Diffie Allman sur sur des nombres premiers qui sont grands et donc ça limitera en fait un peu les dégâts mais évidemment on voulait utiliser des courbes électriques parce qu'elles peuvent utiliser des nombres premiers plus petits mais mais avec un niveau de sécurité qui est plus important donc on voulait également incorporer ça à un nouveau mode de communication de nouveau modèle de communication donc on veut pouvoir avoir des conversations synchronées à synchrones donc au terres c'est déjà ça et maintenant on veut de la solution à la vente on veut plusieurs on veut voir aussi plusieurs modes dans lesquels les choses peuvent être implémentées et on veut pas avoir à faire confiance aux serveurs et ça c'est vraiment pourquoi on utilise le mécanisme de des échanges de clés répudiables donc ça veut dire ce mécanisme veut dire que qu'en fait il faut un serveur un serveur fiable et donc si on regarde sur notre dépôt on peut voir les changements importants donc quelques décisions de conception donc pourquoi pourquoi utiliser d'aques et et cdh à la place de quelque chose de plus simple donc on voulait les utiliser parce que ce sont ce sont ceux qui qui vérifient le mieux ces propriétés de réput de liabilité ensuite on voulait aussi utiliser les courbes électriques 448 gold deluxe parce que ça atteint le niveau de sécurité qu'on voulait atteindre donc on va on veut aussi être en fin de s'assurer que même avec des ordinateurs quantiques ça risque de s'apprendre du temps de déchiffrer ce qu'on a actuellement on voulait avoir aussi la version à jour de ensuite on voulait on voulait aussi mettre à jour les primitifs cryptographiques on voulait aussi utiliser l'algorithme de double crémaillère et donc et donc une autre question que les utilisateurs nous posent c'est quelle quelle la suite d'outils c'est c'est ce que hauteur fourni et c'est c'est pour prouver aux gens qui utilisent otr que en fait otr donne le niveau de de sécurité qui prétend avoir donc pourquoi il ya il ya de l'algorithme de post quantiques c'est parce que je l'ai déjà dit ils sont pas encore suffisants et pourquoi pas de discussion de groupe en fait on c'est parce qu'il n'y a pas encore de de chemin de de faire quelque chose de de fortement répudiables pour un pour une discussion de groupe quelque chose que l'on doit également avoir quand on conçoit un protocole c'est une bonne implementation et donc une implementation qui compile une implementation qui s'exécute donc on a fait ça en en collaborant avec différentes entités donc des cryptographes qui travaillent sur des des des échanges de clé donc répudiables qui ont travaillé aussi sur sur le code pas que sur l'espécification et et donc lipgoldilox c'est c'est une extention donc de libdk par maca embourg ou en fait on utilise seulement ed448 il ya aussi des gens qui qui travaillent sur d'autres implementations et pourquoi c'est important c'est parce que si on veut aussi être capable de tester et voir s'il ya des problèmes en fait dans la spécification si des choses sont pas claires et si quelque chose nous a permis de si on peut trouver quelque chose qui permet de clarifier et améliorer en fait la spécification et donc on a collaboré avec les cryptographes qui ont fait les articles aussi et donc on a des travaux qui ont été révisés par Ian Goldberg et Nick Unger donc c'est toujours important que quand on quand on décrit un protocole en fait et qu'on utilise un article il faut toujours il faut toujours essayer de collaborer avec les auteurs de manière à être sûr d'implementer le bon le bon algorithme qui est défini dans le papier et de le définir correctement donc ici on on s'est basé sur sur le papier et aussi sur sur d'autres par exemple celui-là de l'université de atro donc ok si on voulait enfin vu qu'on voulait faire une implementation dans le monde réel fallait qu'on choisisse un langage et on a choisi de faire une implementation en c donc il ya déjà eu des des initiatives pour le mettre en piton en java et en bola mais mais donc c'est c'est toujours le langage qui est utilisé comme référence et la plupart des bibliothèques qu'on utilise ont été écrits dans c donc on voulait utiliser le même langage mais évidemment quand on utilise c'est il y aura toujours des problèmes de gestion de mémoire je sais pas si si vous avez vu notre notre talk même sade le talk même sade où où le laurateur expliquait les problèmes de gestion de mémoire donc on a dû on a dû vérifier que que la gestion de la mémoire se passait bien dans le programme et il faut faut pas avoir les problèmes mémoire que d'autres bibliothèques ont on a essayé d'incroporé aussi des tests des tests statiques donc utilisant ses langs tidy et splint et on a utilisé un certain nombre de sanitiser aussi pour pour s'assurer que que tout marchait bien et qu'il y avait pas de bug donc il faut aussi que le code soit lisible parce que parfois cette certain certaine personne envoie en production des des bibliothèques qui sont pas encore totalement finis qui qui ont pas toutes les propriétés donc on voulait être sûr que que tout est correct et on voulait aussi revenir sur le talk de Daniel Langa et Daniel Batheur il faut il faut aussi s'assurer que faut aussi s'assurer que le code soit soit lisible parce que en fait la bibliothèque sera peut-être utilisée par des développeurs ailleurs qui s'y connaissent pas autant ou d'autres domaines et donc il faut il faut quelque chose qui puisse être utilisé par d'autres et il faut aussi écrire des recommandations pour les développeurs parce que oui c'est vrai qu'on a qu'on a écrit ses protocoles et leur design mais c'est pas pour ça qu'il faudrait envoyer le protocole et dire débrouillez vous essayer de l'implémenter mais il faut qu'on essaye de garder le contact avec la communauté parce que il y a peut-être des choses qui sont pas assez bien dans le protocole et en fait ça rend le protocole plus robuste parce que on peut attraper certaines erreurs que que les cryptographes n'auraient pas vu ou que les expériences sécurité n'ont pas vu mais que les développeurs en fait qui implémentaient le protocole ont vu donc juste comme Sophie a dit on a fait des tests donc on a aussi fait attention à tester sur différents systèmes d'exploitation et d'architecture on a vu quelques bugs quand on a lancé les tests donc les suites de tests sur sur différentes sur différentes versions de gcc ou de clang par exemple ou sur différents systèmes d'exploitation sur différentes distributions de linux et il y avait on a on a trouvé des problèmes de temps en temps et on voulait aussi utiliser les différents bsd et on a on a essayé de faire tourner de l'intégration continue pour ses plateformes et une chose importante et marrante c'est que débian à différentes architectures et ils ont des systèmes unique like donc on on a trouvé on a trouvé des choses comme gnaward qui était là bas on a pu tester des choses sur des architectures comme mipps ou power pc et ça nous permet d'avoir d'avoir une couverture qui est très élargi sur les sur les architectures quelque chose qui est également très important lorsqu'on définit des protocoles cryptographiques et qu'il faut qu'on priorise que les gens vont vraiment utiliser il vous il faut si vous créez quelque chose si vous publiez quelque chose évidemment les gens vont l'utiliser et et si si vous mettez votre implementation par exemple dans le clé en pijet et pijin il faut que il faut que les dialogues soient compréhensibles sur ce qu'ils vont faire il faut être il faut montrer à l'utilisateur ce qu'on fait quand on génère des clés pourquoi ça se passe comme ça c'est aussi nécessaire quand on quand on conçoit un protocole on a essayé de le mettre dans dans otr c'est c'est qu'on essaie de vérifier en fait tous les protocoles donc il y a un travail qui qui est en cours sur sur la vérification des modèles et donc ça va être fait dans le dans l'outil c'est Murphy et ensuite on veut on veut commencer une une verte une vérification formelle complète du protocole parce que c'est important et donc une des parties importantes de l'interaction entre plusieurs états c'est quand des erreurs se produisent il faut être capable de vérifier que qu'on est à l'abri de plusieurs erreurs qui peuvent apparaître lors de l'exécution du problème on voulait aussi s'intéresser à la sécurité aux audites de sécurité on veut aussi être sûr que le code que les gens utilisent est raisonnablement sûr par exemple quand quand vous essayez de faire du fuzzing donc vous essayez d'utiliser de l'hyper fuzzer par exemple si on veut essayer de lancer sur oss fuzz donc qui a un service de google où ils font un un un engin de calcul qui permet de faire des tests fuzzing et on est très ouvert aux audites de la communauté donc moi j'ai fait un audite j'ai n'hésitez pas à m'envoyer des e-mail si vous trouvez aussi des failles de sécurité et si vous si vous vérifiez en fait la sécurité du protocole n'hésitez pas à rentrer en contact avec nous on on veut pas rester là on veut aussi avoir un un audit c'est professionnel de sécurité donc en conclusion ce qu'on voulait atteindre avec otr c'est c'est donc un protocole qui dit comment comment l'interaction entre les différents algorithmes fonctionne pour montrer que c'est correct on veut faire aussi une spécification qui qui s'applique au monde réel qui qui est structuré et qui a suffisamment de structure qui qui est suffisamment documenté qui montre les les dépendances aussi c'est quelque chose que les utilisateurs ou les implémentes les gens qui implémentent auront besoin parce que peut-être que les utilisateurs devront savoir ce qu'ils ont besoin d'installer et donc il faut aussi faire une implementation qui qui fait qui s'occupe pas de son propre langage mais être sûr que cette implémentation est propre et est prête à la production et peut servir de base pour d'autres implémentations qui qui se base de fin qui partent de là et donc comme j'ai dit avec le papier de rohaways donc otr a une partie du protocole qui essaye de de régler le problème de de la de la répudiabilité et qui essaye de tenir compte de l'éthique aussi et donc quand quand et respecter les utilisateurs quand ils demandent d'avoir quelque chose qui implémentait suffisamment bien pour eux donc n'oubliez pas de vérifier nos dépôts de nos dépôts les libres les spécifications les les bibliothèques les les suites d'outils une implémentation en go qui est en cours donc il y a une implémentation en java qui est faite par dany van heunmen aussi et n'oubliez pas de regarder notre notre site web et on voulait on voulait dire merci à toutes les personnes qui étaient dedans donc je voulais quand même rajouter un peu quelque chose donc on a aussi une communauté on a un serveur git lab on a on a pas mal de d'options de l'intégration continue donc si vous voulez partir de github par exemple vers git lab on serait heureux de vous héberger sur cette plateforme et vous fournir une intégration continue des des fonctionnalités d'intégration continue pour vous donc on voulait aussi remercier toutes les personnes qui sont impliquées donc ça a été fait par des gens qui sont un peu partout sur tous les continents et partout dans le monde et on voulait on voulait aussi montrer les gens qui ont plus de 6000 lignes de contribution dans le dans les dépôts mais en fait il y en a beaucoup plus si vous voulez voir tout ce qu'il y a tous ceux qui ont collaboré vous pouvez toujours voir nos dépôts et donc voilà quelques références et voilà des questions donc merci à tout le monde pour pour ce travail impressionnant sur otr et pour la présentation donc on a du temps pour les questions on a cinq microphones alignez-vous devant les microphones question d'internet est-ce que vous êtes en contact avec les développeurs de doutils de messagerie comme signal et est-ce que le protocole supportera aussi d'autres d'autres protocoles d'autres médias que le texte donc je sais pas trop on n'a pas on n'a pas collaboré avec eux spécifiquement on a juste collaboré avec des des gens qui ont qui ont fait otr par le passé parce que c'est aussi ceux qui qui ont fait les les articles récents et la raison pour laquelle on voulait mettre à jour otr et donc le protocole signal est basé sur otr donc on voulait d'abord mettre à jour otr et donc par le passé quand on a montré le premier le premier jet d'otr il proposait qu'on envoie aussi le premier jet sur sur la main list de modern curves mais on n'a pas vraiment collaboré avec eux ensuite la question sur la vidéo et l'audio vous pouvez toujours la supporter on veut si vous voulez de du chiffrement en fait de vidéo ou d'audio on a donc on a donc des outils pour ça avec avec des clés des clés supplémentaires donc le problème c'est qu'il n'y a pas il n'y a pas eu vraiment d'implémentation merci microphone numéro 1 donc ma question concerne la capacité de omimo qui qui supporte plusieurs plusieurs appareils et est-ce que est-ce que otr fait toujours fourni toujours des garanties suffisantes pour la répudiabilité donc ça vous donne accès à ça félicitations vous avez vous avez débloqué les planches secrètes de la présentation donc ça c'est une question courante qu'on a et je pense que c'est important de répondre à ces questions donc otr v4 à quelque chose qui s'appelle system sat qui qui en fait permet d'identifier certains certains appareils et ça ça fait pas de synchronisation en fait entre les entre les appareils parce que ça ça serait des problèmes de sécurité donc il n'y a pas de synchronisation entre les entre les différents appareils mais on vous pouvez utiliser les différents les les différents appareils et il va reconnaître quel instant s'il utilise et ça va toujours envoyer au bon endroit donc la différence avec omimo donc otr est plus agnostique il peut être mis sur d'autres protocoles de messagerie qui existe pas seulement xmpp si vous voulez mettre otr sur irc par exemple vous pouvez faire ça on supporte aussi les messages offline donc par exemple vous pouvez le mettre sur les e-mail donc otr a des propres et été de répudiabilité j'ai pas vu d'articles partant de parlant de de répudiabilité sur sur les les appareils multiples et évidemment otr v4 à une spécification qui est beaucoup mieux définie et donc on va reprendre une question du micro 1 mais excuse ça sera peut-être hors de propos mais un des problèmes avec les applications de messagerie c'est pas seulement la messagerie chiffrée mais aussi la découverte en fait de personnes de faire des pour faire des premiers contacts est ce que vous allez dépenser là dessus sur comment est ce qu'on peut régler ce problème là donc ça c'est le problème de la découverte de contacts donc ça c'est c'est plutôt sur quelque chose qui est déployable sur un appareil mobile et avec un client et otr maintenant on est à l'étape de faire le protocole et la bibliothèque et si ici un moment on commence à écrire un client qui est qui est supporté par les par les téléphones mobile évidemment qu'il faudra s'en occuper mais pour l'instant on n'est pas occupé parce que ça fait pas partie du protocole principal et mais peut-être qu'il y a des gens qui ont envie de développer ces clients pour le mobile et donc ça dépend aussi du protocole de messagerie que vous utilisez ça va être difficile par exemple pour IRC mais peut-être que XMPP c'est pas vraiment un problème si vous allez dans le paysage mobile tout change de toute façon et donc c'est quelque chose qu'il va falloir s'occuper micro numéro 3 est ce que vous pourriez élaborer sur pourquoi nous chat n'est pas possible et pourquoi est ce que ça serait possible par le futur parce que ça serait utilisable au jour le jour donc il y a eu des efforts par le passé il y en a eu au moins un il y a quelques années pour pour faire du MPOTR et donc il y a un papier très bien qui s'appelle j'ai trouvé ce dernier papier donc messagerie sécurité secure messagerie défini donc les propriétés qu'une messagerie se sécuriser a besoin d'avoir pour supporter les discussions de groupe le problème c'est qu'il n'y a pas de moyens d'achever c'est enfin d'atteindre le même niveau de répudiabilité qu'on a avec les algorithmes qu'on a nous mais ce qui a l'air intéressant on a vu ça en 2013 Nicolas Hopper a déjà proposé un article à propos de des discussions de groupe et de répudiabilité et dans cette même conférence nick hunger nous a dit qu'il est en train de préparer un article à propos de la répudiabilité pour les messagerie de groupe donc ça peut être quelque chose qui sera mis par le futur une autre question d'internet est-ce que vous pourriez expliquer pourquoi la sécurité persistante parfaite de terre est meilleure que celle de signal oui donc pour faire simple ça dépend de de dake que vous utilisez signal utilise quelque chose d h qui fournit en fait la sécurité persistante parfaite au tr utilise aussi quelque chose qui qui nous donne cette sécurité mais l'utilisation de l'algorithme de double ratchet ça veut dire le problème avec dake c'est c'est seulement pro donc donner la sécurité quand les clés ont été correctement échangés alors que alors qu'un dans eotr même si c'est pas même si c'est pas totalement fini vous avez déjà la sécurité persistante parfaite alors que dans signal il faut attendre que les deux clients et bien reçus les clés merci question du micro numéro un il y a eu une mention aussi d'un d'un serveur de casser un serveur que pardon un briquille serveur est-ce que c'est la même chose que que que signal est-ce que c'est la même question pour otr donc signal définit aussi un serveur non qui n'est pas de confiance mais donc ce qu'on a dit aussi c'est que otr part du principe qu'il n'y a pas de serveur d'in de confiance et on on fait attention de prendre de prendre nos donc on peut on peut faire en sorte que d'assurer la sécurité même si on est sur un serveur qui n'est pas d'in de conférence par exemple que qu'on peut pas avoir des nids de service qu'on peut que personne ne peut publier ce qu'on a quand on utilise un serveur qui n'est pas de confiance par exemple les serveurs sont sont aussi authentifiés avec un moyen répudiable alors que on n'utilise pas des signals parce que signal utilise des informations comme quoi les cléons expirés expirés parce que ça peut aller à l'encontre de propriété de répudiabiliser donc il y a plus de donc s'il n'y a plus de matériaux éphémères on attend juste que quelqu'un d'autre en publie et donc évidemment un serveur qui n'est pas de confiance on n'a pas besoin si on si on veut juste supporter des des messages offline donc il faut seulement des des communications à synchro offline avec un avec un serveur prix qui une dernière question du micro numéro 1 je voulais savoir si si vous avez travaillé entre l'intérêt avec l'intégration de d'otterre v4 avec les autres protocoles donc un des avantages d'omémo c'est que on sait très bien où sont stocké les clés dans le xmpp et ça vous donne un moyen simple et bien défini pour trouver les clés dans au xmpp alors que dans otr il y a toujours ce petit tag au début des messages qui est un peu moche est ce que est ce que vous avez pensé à ça est ce que vous avez essayé d'y travailler par rapport à ça donc pour l'intégration entre otr v4 et les autres protocoles donc ouais c'est un peu c'est au mémo un peu plus simple en fait parce que ça enfin au mémo est plus simple parce que ça travaille seulement sur sur xmpp alors que otr v4 on peut fédérer on peut pas vraiment fédérer mais mais fonctionner en fait sur sur n'importe quel protocole le messagerie et si si on voulait faire un serveur prix qui d'irc en fait ça serait compliqué ça serait probablement même pas possible complètement et je pense que ça dépend de de quel protocole le messagerie en fait est sous-jacent et il faut il faut essayer de trouver comment est-ce qu'on peut implémenter ces choses là peut-être qu'il faudrait passer à des protocoles de messagerie qui qui prennent qui prennent en considération ce genre de choses qui fournissent des extensions sur lesquels on peut se baser qui par exemple on peut mettre des prix qui serveurs qui serait le raisonnement que je voudrais utiliser donc une des propriétés d'otr c'est que ça devrait être agnostique par rapport au protocole donc sur lequel il se base donc une propriété qui est spécifique à xmpp ça serait pas une partie d otr mais peut-être une recommandation aux gens qui écrivent des implémentations par-dessus xmpp donc le seul le seul problème avec l'implémentation xmpp c'est qu'on a besoin de découvrir les serveurs prix qui et on utilisait la librairie pijine qui n'était pas un qui n'avait pas de haideur exposé pour faire ça et donc on a on a dû avoir des astuces pour pour faire ce genre de choses c'était la dernière question merci pour ce magnifique et cette magnifique présentation merci pour votre travail