 Willkommen zum Talk für Unbeweisbarkeit von Kommunikation und Moralität in Protokollen für das Off-the-Record-Protokoll-Version 4 von Sofia Tzeli und Jure van Bergen, die werden auch in dieser Präsentation über Moralität und Ethik sprechen. Und weshalb wird das in unserer Kommunikation brauchen? Ein warmes Willkommen für die zwei. Hallo und Willkommen, ich bin Sofia, hier ist Jure. Wir werden hier jetzt die Version 4 von OTR zeigen und wir werden hier die Präsentation unbenennen. Also weshalb brauchen wir sichere Kommunikation? Das war so das erste, was uns in den Senden gekommen ist, was wir hier präsentieren wollten. Hier gibt es eines der berühmtesten Publikationen in Kryptografie, der Moralkarakter von kryptografischer Arbeit. Die meisten akademischen Kryptografer denken wohl, dass das ein spaßiges und politisch-neutrales Spiel ist und die Vision hier, wer wir sind, ist intellektuell zwar beeindruckend und auch schneller Arbeit dadurch gebracht, aber eigentlich ist die Frage hier ja, wie es sieht das dann aus in der echten Welt und wo sollen wir unser intellektuelles Kapital denn effektiv ausgeben? Am Ende des Tages sind wir ja Privatsphäre und Sicherheit Leute und wir haben hier Entscheidungen, die wir treffen und die sind wichtig, weil das ist dann für alle Leute, die unsere Produkte benutzen und das hat auch mit ethischen und moralischen Entscheidungen zu tun. Er hat dir viele gute Punkte in seiner Publikation, aber hier geht es da um einen Hauptpunkt, das ist so etwas, was ein bisschen verlassen wurde von Kryptografie, Forschung, das war sicheres Messaging. Er sagt ja, er hat sicher ein bisschen Forschung gegeben und paar Optionen, aber noch nicht so intensiv untersucht und was wir hier jetzt zeigen wollen mit Version 4 von OTR, da haben wir das Problem von Anfang an, die sicheres Messaging-Problem, das wir lösen wollte und hier wollen wir die Privatsphäre wieder zurückgeben. Wie ich schon gesagt habe, hat es viele Alternativen zu den sicheren Messaging-Protokollen, aber hier zeigen wir, weshalb wir tatsächlich ein Protokoll brauchen, so wie OTR, dass die Limitation auch aufzeigt. Also etwas, was wir brauchen, was wir lösen wollen, das Problem, das wir lösen wollen. Da hat das Kommunikation zwischen mehreren Parteien und hier hat es eben das Problem, was wir hier brauchen, um das den Benutzern zu geben sind Optionen, die funktionieren. Manchmal hat es hier Protokolle, die gar keine Implementation bieten oder im Design gar nicht hier das berücksichtigte. Wir brauchen auch volle Spezifikationen, die für diese Protokolle gegeben werden, weil wir wollen hier keine falschen oder halben Spezifikationen. Wir wollen da gut strukturierte Protokolle, die nicht nur kryptografische Algorithmen vorschreiben, sondern auch wie diese Algorithmen benutzt werden sollen und wie sie miteinander zusammenspielen. Es reicht nicht aus, dass man hier sagt, man muss eliptische Kryptografie nutzen, sondern man muss auch zeigen oder sagen, wie diese eliptische Kryptografie mit allen anderen Algorithmen funktionieren soll und wie es mit verschiedenen Attackszenarien umgehen sollte, etc. Und hier brauchen wir eine vollstrukturierte Spezifikation. Wir müssen auch definieren, was für Eigenschaften dieses Protokolllösen versucht, welche Schwachstellen verteidigt es nur gegen gewisse Schwachstellen, hat das Vorwärtssicherheit. Wir müssen auch wissen, welche Einschreckungen hat, weil ein Protokoll kann nicht alles lösen, wie wir gesehen haben. Wir müssen auch mit dem Quanten-Computer-Problem umgehen, das heißt, wir brauchen Post-Quanten-Kryptografie, da kann man ja den Talk-Gestern von DJ Burst sein und Tanja Lange sehen, aber die sind noch nicht gut genug, um eingesetzt zu werden. Wir brauchen auch Protokolle, welche existierende Definitionen updaten und anpassen. Wir haben ja schon einen Protokoll, warum sollen wir updaten? Es sieht ja im Moment gut genug aus. Vielleicht sieht es heute gut genau, aber in der Zukunft nicht, aber vielleicht merken wir auch heute schon, dass wir gewisse Definitionen schärfen und besser definieren müssen. Wir brauchen auch Reviews und Bestätigungen, Verifikationen. Wir müssen es nicht nur ins Internet stellen, sondern wir müssen auch formell verifizieren durch verschiedene Parteien, Kryptografen, Software-Engineure. Wir brauchen auch Implementationen für verschiedene Betriebssysteme und überhaupt, damit man das auch wirklich laufen lassen kann. Am wichtigsten eigentlich, wir brauchen Ideen aus verschiedenen Richtungen. Die meisten Orteerentwickler kommen aus Lateinamerika, Ecuador und Brasilien. Wir brauchen Leute aus unterschiedlichen Regionen, weil es nicht ausreicht, Ideen nur aus einer Region der Welt zu haben, sondern man muss Ideen von überall haben, welche die spezifischen Nutzungen in verschiedenen Regionen der Welt abdecken. Okay, so, jetzt müssen wir mal drüber reden, was auf der Record Messaging ist und was Verleugnbarkeit ist. Zu Beginn gab es drei Leute, die ein Paper geschrieben haben, Ian Goldberg, Nikita Borisow und Eric Brewer, und die schrieben ein Paper namens Off the Record Messaging. Die wollten einen Nachrichtenalgorithmus, einen Nachrichtenprotokoll, damit man so Gespräche haben kann, wie man sie umgesprochen in der normalen Welt hat, die keine Aufzeichnungen hinterlassen. Und mit PGP kann man Nachrichten signieren und sagen, ja, ich habe das diese Nachricht geschickt. Aber in der echten Welt, wenn ich ein Gespräch habe mit Sophie, dann weiß ich, dass ich mit Sophie spreche, aber niemand sonst wird wissen, was wir besprechen. Und sie wollten diese Idee in einem kryptografischen Protokoll umsetzen. Und das haben sie getan. Und das ging durch verschiedene Revisionen. Und man kann jemanden verifizieren, dass man weiß, wer man spricht, aber in einer verleugnbaren, auf einer leugnbaren Art. Ob man über XMPP oder IRC kommuniziert, man will immer noch verifizieren, dass man mit der Person spricht, mit der man erwartet zu sprechen. Also man muss jemand verifizieren können, nicht authentifizieren. OTR hat einige andere Protokoll inspiriert, wie z.B. das Sigma. Und einige der Eigenschaften von dieser aufzeichnungsfreien Kommunikation ist, dass man einen authentifizierten Schlüssel austauscht, nutzt eine Variante des Sigma-Protokolls. Und was das anders macht als das Original, ist, dass man den Signierteil weglässt, aber den Message-Authentication-Code immer noch verwendet. Man will bei OTR nicht immer eine Signatur haben. Man kann hier eine Frage-Antwort-Verifikationsmechanismus haben, wo man eine Frage stellen kann, die hoffentlich nur die andere Person beantworten kann oder auch eine Fingerabdruck-Comparison, so wie Out-of-Band dann. Und natürlich alles ist end-to-end verschlüsselt, damit die Nachrichten auch sicher bleiben. Was auch wichtig ist, dass es eine perfekte Vorwärtssicherheit hat. Es werden einzigartige Schlüssel für die Verschlüsselung jeder Nachricht gebraucht in jeder Konversation. Und das ist darum wichtig, weil wenn ein Gerät kompromittiert wird, wenn jemand Zugriff auf dein Telefon kriegt, dann kann der Angreifer die zuvor verschlüsselten Nachrichten nicht mehr entschlüsselt, weil jede Session einen einzigartigen Schlüssel hat. Und Postkompromittierungssicherheit ist eben, dass wenn Alice eine Sicherheitsgarantie zur Kommunikation mit Bob hat, dann kann man immer noch sicher kommunizieren, auch wenn die Geheimnisse von Bob bereits kompromittiert wurden. Und jetzt kommen wir zu Erleugenbarkeit. Was ist das genau? In OTR Version 3, also die vorherige Version, in einem Szenario, wo Bob alles anschuldigt, dass sie einige Nachrichten gesendet hat. Und jetzt ist die Frage, ob Bob hier beweisen kann, dass Alice das tatsächlich gesendet hat oder nicht. Und dann kann man sagen, ja, ist es jetzt Eleugenbar oder eben nicht. Was jetzt hier mit Version 4 geändert hat, ist in dieser Eleugenbarkeit, ist, dass man die Eleugenbarkeit jetzt erweitert hat. Also fangen wir mit den zwei Einfachen an. Mit der Nachricht. Wenn man eine Nachricht sendet, kann man leugnen, dass man diese Nachricht gesendet hat. Aber man kann auch leugnen, dass man in einer Nachricht, in einer Konversation teilgenommen hat. Und der Offline Typ ist, dass man sagt, ja, wir hatten eine Konversation, die ist jetzt beendet und dann kann man das Transcript nicht mehr faken. Online ist, dass wenn jemand auf dem Netzwerk versucht herauszufinden, was hier passiert und dass man hier dann auch nicht verifizieren kann, dass eine Konversation stattfindet. Aber natürlich mit kryptografischen Protokollen, da hat man kein Panaceum, da muss man auch Obseck haben. Ein Protokoll ist Eleugenbar, wenn die Transkripte keinen Beweis liefern, obwohl der Schlüssel irgendwie kompromittiert wurde. Das ist Offline Denialability. Was wir eigentlich hier jetzt erreichen wollen, ist, dass wir alle die Eigenschaften von OTR haben wollen, sowie die ganzen Update. Wir wollen hier die Vorwärtssicherheit, postkompromittierte Sicherheit, Online und Offline, Leugenbarkeit und mit Nachricht auch. Wieso wir das noch nicht hatten, ist, weil in der Akademie Waage Begriffe hatten, was jetzt diese Leugenbarkeit genau bedeutet. Und was wir mit Version 4 erreichen wollten, ist dieses Protokoll abzudaten mit, was jetzt in der Akademie definiert wurden, sodass wir das in ein Protokoll einbauen können, das von mehr Leuten benutzt werden kann. Und was ihr hier seht, ist eine Vergleichstabelle, wo wir die meisten Protokolle hier zeigen. OTR hat eigentlich die meisten dieser Eigenschaften. Manchmal haben wir nicht die volle Eigenschaft, sondern nur partiell. Und das ist hier etwas, was wir auch klar zeigen wollen, dass wir Limitation haben in diesem Protokoll. Und da wollen wir nicht sagen, ja, das kann alles, sondern das hat auch ein paar Einschränkungen. Einige dieser Eigenschaften und mit diesem Mapping sind vielleicht nicht so genau, weil wir haben das hier basiert auf den Messaging-Protokollen oder Blog-Posts und die sind halt vielleicht nicht up-to-date. So, ja, das ist halt der Status hier. So, warum eine Version 4 von OTR? Ja, eben, wir wollen die Leugnbarkeit in der vollen Form hier, wie vorhin erwähnt, von Teilnehmungen, Nachrichten online oder offline. Wir wollen auch die starke, perfekte Vorwärtssicherheit und postkompomierte Sicherheit. Wir wollen eine höchstecurity-Level und wir wollen die kriptografischen primitiven Updaten. Das ist eigentlich auch, weshalb wir einen neuen brauchen, weil wir haben Algorithmen, die denken, ja, das ist gut genug, aber dann ja irgendwann findet ein Angriff auf so ein Algorithmus oder mit der Implementation des Algorithmus und deshalb müssen wir auch die kriptografischen primitiven Updaten zu etwas, das genug stark ist gegen Kryptoanalysen. Wir wollen auch erweiterte Sicherheit gegen Entschlüsse umgeben, falls elliptik Kurven kompromittiert werden, weil etwas, was wir schon in Vergangenheit gesagt haben, wir hatten noch keine Quantenresistenz gegen OTR Version 4. Wir haben hier noch keine Quantenalgorithmen, die gut genug sind, um das in einer Massenversion zu benutzen. Aber wir sehen da vielleicht weiter mit den NIST-Wettbewerb, was wir hier für Kandidaten haben. Aber falls die Quantensachen früher kommen, als wir gesagt haben, dann haben wir hier auf jeden Fall die Möglichkeit mit einer sehr großen Primzahl hier, dass das ziemlich schwer wird zu knacken. Aber wir wollten auch elliptische Kurven benutzen, weil die haben viel kleinere Primzahlen, aber sie haben, sie haben sogar einen größeren Sicherheitslevel. Wir wollten auch ein neues Kommunikationsmodell inkorporieren, das wir nun haben. Als wir OTR zuerst entwickelt hatten, hat es nur die synchrone Online-Konversation, aber wir wollen jetzt auch online und offline. Das ist etwas, was mit OTR 4 bereitgestellt wird und auch Asynchroneverteilung der Nachrichten und verschiedene Arten, wie man das implementieren könnte, weil vorher war es vielleicht nur möglich, die Online-Version zu implementieren und wir wollen keinen Servern trauen und so, wie wir das mit dem authentifizierten Schlüssel austauschen, dann müssen wir das in diesem Mechanismus mit dem Offline-Modus, müssen wir das vielleicht mit einem Server machen. Die Hauptänderungen zu Version 3, seht ihr hier im Über, in der Übersicht und jetzt die Designentscheidungen. Warum haben wir DAXZ und XEDH verwendet? Statt etwas simpler. Das ist der leugenbare authentifizierte Schlüsselaustausch und wir wollten diese beiden haben, weil die geben uns die Leugenbau-Eigenschaften, die wir benutzen. Wir wollten ED44 auch Goldilocks verwenden, weil das gibt uns das Security-Level, das wir wollten, weil wir uns auch ein bisschen gegen Quantencomputer schützen wollten. Verwenden wir einen Diffy-Helmen mit 3.072 bits. Wir verwenden Shuck und XS20 für das Hashing, Shake für Hashing, XS20 für die Verschlüsselung und haben die kryptografischen Algorithmen dafür abgedeitet. Wir verwenden ein Double-Ratchet-Algorithm, weil die uns wiederum die Eigenschaften geben, die wir brauchen. Was ist das Toolkit, das wir verwenden? Das ist das, was OTR sonst provided hat, bereitgestellt hat. Damit können Leute zeigen, dass OTR wirklich die Eigenschaften bereitstellt, die wir wollen. Wir haben schon darüber gesprochen, warum wir keine Post-Quanten-Algorithmen haben und wir haben keinen Gruppenschatz, weil wir keine Algorithmen gefunden haben, die uns die Eigenschaften geben, die diese starke Leugnbarkeit geben, die wir wollen in einem Gruppenschatz. Dafür gibt es keine Algorithmen, die uns gefallen haben, also haben wir das nicht. Okay, eine der Sachen, die ich von Beginn weg gesagt haben, die wir brauchen, wenn wir so ein Protokoll haben, ist eine echte Implementation, und zwar eine, die funktioniert, eine echt Weltimplementation. So, das haben wir gemacht. Wir haben mit Kryptografen und Entwicklern zusammengearbeitet, um so eine Implementation bereitzustellen. Die an der Universität Waterloo haben mit uns zusammengearbeitet für die kryptografischen Primitiven. Und wir haben eine Implementation für OTR Version 4 zusammen entwickelt. Das ist Goldilocks, eine Erweiterung von LibDecaf, von Mike Hamburg. Davon gibt es Leute, die arbeiten jetzt an verschiedenen Implementationen. Wir wollen, das ist uns wichtig, weil wir auch testen wollen, ob es irgendwelche Schwächen in der Spezifikation gibt, die Probleme gibt, wo wir die Spezifikationen klarifizieren können und verbessern können, damit es keine Fehler bei der Umsetzung geben kann. Wir haben mit Kryptografen zusammengearbeitet, während sie ihre Paid Purs zu dem Thema geschrieben haben. Und wir hatten die Spezifikation jetzt auch reviewed durch Ian Goldberg und Nick Unger. Zu dem verbunden ist auch, es ist immer wichtig mit anderen zusammenarbeiten, damit man sicherstellen kann, dass man die Algorithmen auch sauber umgesetzt hat, so wie sie gedacht sind. Wir wurden auch in den Papers bereits zitiert und das waren halt einige der Papers, wo die Algorithmen definiert wurden. Wenn wir auch eine solche echte Implementation machen, dann müssten wir auch eine Programmiersprache auswählen und wir haben das jetzt in C umgesetzt. Es gibt bereits Efforts, Versuche, um das ganze in Python, Java, GoLang umzusetzen, aber wir haben es in C gemacht. C wird oft als die Referenz verwendet und viele der Libraries, die wir verwenden, sind bereits in C geschrieben. Also wollten wir die gleiche Sprache verwenden. Ja, in C hat man Speicheprobleme und es gab gerade ein Talk zu Memsad, welche über Probleme beim Memory Management gesprochen hat. Und wenn wir eine Library bereitstellen wollen, die von echten Leuten verwendet wird, dann müssten wir eine haben, die nicht diese Speicheprobleme hat. Also haben wir sie in eine Testunggebung gesteckt, wo wir das ganze startlich auch testen können mit Unitests, mit Walgreens und verschiedenen Sanitisern, mit Clangtidy und Splint. Genau und wir haben auch Einheits- und Integrations-Teste gemacht, weil zum Teil werden Libraries in der Produktion eingesetzt, welche nicht alle Edge-Cases sauber abdecken und wir wollten sicher sein, dass das uns nicht passiert. Wir müssen auch, wenn es um kryptografische Themen geht, sicherstellen, dass der Code lesbar ist, damit andere Entwickler den verwenden können und auch verstehen können, wie unsere Library funktioniert, damit auch das besser überprüft werden kann. Wir wollten auch in der Lage sein, Empfehlungen für andere Entwickler abzugehen. Ja, wir haben das Protokoll entwickelt und das designet, aber wir sollten es nicht einfach nur rausschieben und sagen ja, versucht mal, sondern wir wollten ihnen auch Empfehlungen geben, Sachen klarifizieren können und das macht das Protokoll viel robuster, weil wir finden so Fehler, die die Kryptoraffen nicht entdeckt hätten oder die unsere Entwickler nicht entdecken, aber die Implementationen und die Community haben das gefunden. So, ja, wir haben also viel getestet, aber es ist auch interessant, dass wir das auf verschiedenen Architekturen und Systemen testen. Wir haben da ein paar Bugs gefunden, als wir das mal auf einer Online-Testwichte laufen gelassen haben. Wir haben ja mit verschiedenen GCC und C-Lang-Versionen und verschiedenen Linux-Versionen hier haben wir schon ein paar Probleme gefunden und wir wollen hier auch die Unterstützung der verschiedenen BSDs, die es da draußen gibt und da haben wir gearbeitet an kontinuierlicher Integration für diese Plattform und eine Lustgesache hier ist mit Debian haben wir da die verschiedenen Architekturen und die haben da auch so UNIX-artige Systeme, also haben wir da ein paar Systeme gefunden in GNU HURD und andere Architekturen wie MIPS und PowerPC. Das hilft, eine große Bandbreite hier für die Tests zu haben, dass wir da viel finden. Und etwas, was auch sehr wichtig ist, wenn wir hier das kryptografische Protokoll entwickeln, das Leute brauchen sollen, sollten wir auch die Endbenutzer hier priorisieren, weil am Schluss, ja, die Benutzer sind die Zählen, wenn man das einfach so raus schiebt, ja, dann klar gibt es irgendjemand, der das auch nutzen soll und wir versuchten hier da die Implementation und das Plugin für den Pitching-Klient hier irgendwie verständlich zu machen, vor allem in den Dialogen, zum Beispiel jemand, der gerade einen privaten Schlüssel generiert, dann sollte es klar sein, was diese Prozesse ist und dass der gerade stattfindet. Und es ist auch wichtig, dass das hier gebraucht wird, ist der formelle Verifizierung des Protokolls. Also wir haben hier im Moment Arbeit, wo wir versuchen, die Modelle zu überprüfen in der State-Maschine und am Schluss wollen wir hier eigentlich das volle Protokoll verifizieren. Das ist eine der Gründe, warum wir hier so eine Struktur haben mit dem Protokoll, weil wenn wir von einem Zustand zu einem anderen Zustand wechseln, da passieren die Probleme, also müssen wir die formell auch überprüfen, dass wir hier die potentiellen Bugs und Fehler schon abfangen können. Wir, uns ist auch wichtig, da die Sicherheit, vor allem da im pryktografischen Umfeld, dass mit dem Code, den wir den Leuten geben, dass der sicher ist. Und wir wollen hier so mit Fuzzing, haben wir, die haben wir integriert, so Lipfuzzer und Eiffel und hoffen wir auch mit OSS Laufen lassen zu können. Das sind Leute, die eine App Engine Berechnungszeit bereitstellen, um Fuzzing Tests zu laufen. Und wir möchten auch euch die Community einladen, hier audits durchzuführen, also die ganze Security Community. Hier wollen wir eigentlich, dass sie uns E-Mails senden, so dass wir die Autonomie Digitaladresse, dass sie uns hier Feedback geben und wir wollen auch ein professionelles Security Audit haben von unserem Code. Um abzuschließen, was wir jetzt erreichen wollten, ist ein strukturiertes Protokoll und eine gute Spezifikation zu erstellen, dass die Interaktion zwischen verschiedenen Algorithmen soll zeigen, dass alles korrekt ist. Und wir wollen auch eine echtwählte Spezifikation zeigen, das funktioniert, die zeigt, was für Limitationen, dass wir hier haben, was sind die Design Entscheidungen, die hineingeflossen sind und was sind die Sachen, die effektiv schon da sein müssen, dass das funktioniert. Weil der Benutzer kann sich ja da zwischen den verschiedenen Protokollen entscheiden, je nachdem, wie das die definiert sind. Wir wollten diese Implementierung auch bereitstellen, nicht nur als Implementation, dass das mal draußen ist, sondern dass das tatsächlich eine Standardimplementation ist, die bereit ist für die Produktion, die von Leuten benutzt werden kann und wo andere Implementationen sich darauf stützen können. So, und was wir da jetzt schon am Anfang gesagt haben mit dem Paper da, den Zitat, wollen wir eigentlich hier die Leugenbarkeit hier kreieren für die Leute, die in der digitalen Welt unterwegs sind und wir wollen auch diese Moralität dabei hineinnehmen und die, wenn wir da etwas haben, das sollte dann gut genug sein für diese Leute, die das brauchen. Hier sind unsere Repos, da könnt ihr mal drauf gehen. Unsere halb Implementation in Go und die Implementation in Java von Danny von Heumen. Schaut euch auf unsere Webseite. Wir wollen auch noch eine kleine Sache. Wir haben hier seine OTR Community, OTR....... Mit einer GitLab Instanz und mit kontinuierlicher Integration. Und falls ihr da jemals von GitHub nach GitLab euch bewegen wollt, dann wollen wir euch da auch die Möglichkeit geben und euch da hosten mit kontinuierlicher Integration. Wir wollen auch allen involvierten danken. Da waren viele Leute von fast allen Kontinenten der Welt da involviert. Da haben wir Leute mit mehr als 6000 Zeilen von Kalibration oder Code oder Text. Und falls ihr das wissen wollt, falls ihr noch mehr genauer wissen wollt, dann könnt ihr in unsere Repository schauen. Hier noch die Referenzen, die Papers, die wir benutzt haben. Und jetzt sind wir bereit für Fragen. So, danke für die Arbeit, für euers involvement hier. Jetzt ist es Zeit für Fragen. Eine Frage vom Internet. Die Frage ist, seid ihr da mit Entwicklern von Messenger-Applikationen wie Signal in Berührung? Wird das Protokoll auch andere Medien als Text unterstützen wie VIP oder Video? Wir haben nicht mit ihnen zusammengearbeitet, spezifisch oder so. Wir haben mit den Leuten zusammengearbeitet, die OTR ursprünglich entwickelt hat. Die haben da auch die neuesten Papers geschrieben. Wir wollten nur OTR updaten, weil das die Inspiration für andere Protokolle wie Signal ist, was ja auf OTR besiert. Und wir wollten das zuerst updaten. In der Vergangenheit, als wir den ersten Draft von OTR publiziert haben, wurde uns vorgeschlagen, dass wir das auch in einer Mailingliste veröffentlichen. Aber wir haben nicht sonst mit ihnen kollabriert. Nun zu den anderen Medien, es gibt den zusätzlichen symmetrischen Schlüssel und mit dem kann man solche Sachen teilen. Das wurde auch bereits in OTR V3 spezifiziert, aber nie tatsächlich implementiert in irgendeiner Implantation. Meine Frage hat mit den Freiheiten zu tun, mit OpenMemo, mit mehreren Geräten. Meine Frage ist, ob OTR IV mit allen Geräten zu tun hat und auch die Leugenbarkeit noch darstellt. Danke für die Frage. Das erlaubt uns zu diesen Slides zu gehen. Wir gratulieren. Das ist eine häufige Frage. Und abgesehen von der direkten Frage ist es auch wichtig, das zu beantworten. OTR kann verschiedene Geräte identifizieren und wenn man eine Nachricht verschickt, dann wird man nur für das Gerät identifiziert. Man ist nie auf mehreren Geräten gleichzeitig synchronisiert. Multisynchronisationen gibt es nicht, weil es Privacy-Probleme gibt. Man kann aber verschiedene Geräte benutzen und weil man ja für das Gerät identifiziert wird, werden die Nachrichten auch am richtigen Gerät einkommen. OTR ist agnostischer als OpenMemo. Es kann über jedes andere Protokoll funktionieren. Nicht nur XMPP, wenn man OTR über IRC verwenden will, dann geht das. Weil wir auch Offline-Messages unterstützen, kann man es auch über E-Mail machen beispielsweise. OTR hat bessere Leugnbareigenschaften. Ich habe keine Papers zu mehrfach mehreren synchronisierten Geräten gesehen. Aber das wäre ein spannendes Thema. Und OTR hat eine besser definierte Spezifikation. Entschuldigung, das ist vielleicht nicht in Scope. Ein Problem mit Messaging-Apps sind nicht nur die verschlüsselten Chats, sondern auch die Leute zu entdecken, um das so zu initiieren. Habt ihr da Gedanken mit diesem Problem? Ja, also das Kontaktentdeckungsproblem. Das ist relevant für etwas, was in Mobilgeräten und im Klient eingesetzt wird. Und wir sind an dem Punkt, wo wir das Protokoll definieren und die Library machen. Und wenn wir dann mal erst so weit sind, ein Klient zu implementieren, der auf Mobilgeräten eingesetzt wird, dann werden wir uns dazu mehr Gedanken machen müssen. Aber im Moment sind wir nicht an einem Punkt, wo das wichtig ist. Also kommt dann auch darauf an, welches Nachrichtenprotokoll verwendet wird. Das ist schwierig in IRC, aber es ist vielleicht nicht so ein Problem in anderen. Und wenn man das im Mobilfunk-Kontext verwendet, dann ist das was ganz anderes. Und daher kommt noch. Könntet ihr noch etwas mehr dazu sagen, wieso das mit Gruppenchat nicht funktioniert? Und glaubt ihr, dass das in Zukunft möglich werden könnte? Weil ich denke, das wäre sehr wichtig für täglichen Gebrauch. Ja. Wir haben einige Anstrengungen in die Richtungen gemacht. Es gab mindestens einen vor ein paar Jahren, um einen Multi-Partei-OTR zu machen. Und da gibt es ein sehr schönes Paper. Das letzte Paper hier, das SOC-Secure-Messaging, definiert einige dieser Eigenschaften, die ein sicheres Nachrichtenprotokoll haben muss, um auch sicheren Gruppenchat zu unterstützen. Und im Moment gibt es keinen guten Weg, um diese leugbarkeitseigenschaften zu haben, die wir wollen, mit den momentan verfügbaren Algorithmen. In der Zukunft sieht das sehr, sehr gut aus. Nikolas Hopper hat ein Paper zu Gruppenchats und Leugbarkeit gemacht. Das hat noch nicht alle Eigenschaften haben, aber das ist schon einmal sehr interessant. Und an der gleichen Komparenz hat Nick Unger uns auch erzählt, dass er ein Paper zu dem Thema ein Paper auf dem Schreiben ist. Und von daher, ja, das wird wahrscheinlich in der Zukunft kommen. Könntet ihr erklären, wie OTR mit Vorwärtssicherheit zu Signal hier sich verhält? Das hängt vom Schlüssel-Austausch aus. Signal verwenden X3DH, Extended Triple Diffle Helm, und der gibt eine schwache Vorwärtssicherheit. Und der Start des leugnbaren Schlüssel-Austauschen mit dem Double Ratchet Protocol ist das Problem. In OTR wollen wir von Beginn weg starke Vorwärtssicherheit, auch wenn nur eine Partei den Schlüssel-Austausch abschließt. In Signal muss man darauf warten, dass beide Parteien den Schlüssel-Austausch korrekt abschließen, um Vorwärtssicherheit zu haben. Wir wollten das bereits von der ersten Message weghaben. Es war da, ja, da erwähnt, ein Server, ist das ein Vor-Schlüssel-Server. Braucht ihr, ist das da gleich wie mit Signal, dass man das auch braucht in OTR, wie in Signal? Signal definiert auch einen Nicht-Vertrauten-Server. Ich weiß nicht, ob das ein Bedürfnis von der Implementation ist. Bei uns ist es so, dass wir alle Vorkehrungen treffen, die man muss, wenn man einen unvertrauenswürdigen Prekey-Server verwendet. Wir wollten hier alle möglichen Sicherheitsbedenken beachten, wenn man einen nicht-vertrauenswürdigen Prekey-Server verwendet. Ein Prekey-Server ist auch immer identifiziert in einer leugenbaren Art. Wir machen es anders als Signal, wenn man keine flüchtigen Schlüssel mehr hat, verwenden einen statischen Schlüssel. Das hat uns nicht gepasst. Wenn es kein flüchtiges Material mehr gibt im Server, dann warten wir darauf, dass mehr flüchtiges Material auf den Server publiziert wird. Den Server braucht es überhaupt nicht. Wenn man offline Messaging haben will, wenn man nur online will, dann kann man es auch ohne das machen. Wenn man offline Messaging haben will, dann braucht man den Server. Ich wollte wissen, ob ihr auch mit der Integration von OTR V4 und anderen Protokollen gearbeitet habt. Eine der Stärken von Memo ist die Wohldefiniertheit, wie es da z.B. über XMPP mit dem Account und dem Austausch funktioniert. Da hat man einen gut definierten Weg, wie man die Schlüssel findet. Mit OTR hat man die kleinen Tags, die dann sagen, das ist ein bisschen hässlich. Ich wollte wissen, ob ihr da auch etwas Arbeit gemacht habt in Bezug auf die Integration von der anderen Protokolle. Es ist etwas einfacher für OEMO, weil es nur über XMPP funktioniert. Für OTR V4 können wir uns über irgendein Nachrichtenprotokoll verbinden. Wenn man so etwas macht wie ein Pre-Key-Server über IRC, dann könnte das schwierig werden. Es könnte sein, dass das nicht wirklich möglich ist. Es kommt wohl darauf an, was für ein Nachrichtenprotokoll du brauchst und wie man das implementieren kann. Vielleicht sollten wir einfach auf Nachrichtenprotokolle wechseln, die diese Sachen beachten. Und wo wir die wir dann erweitern können und Sachen wie ein Pre-Key-Server einstöpseln können. Eine der Eigenschaften von OTR ist, dass es agnostisch ist gegenüber dem Protokoll, auf das es aufbaut. Und die Sachen zu definieren, die wir in XMPP brauchen, werden nicht Teil von OTR sein, die werden Teil der Empfehlungen sein, die wir an Entwickler geben, welche OTR über XMPP implementieren wollen. Das einzige Problem, dass wir bei einer XMPP-Implementation von OTR entdeckt haben, ist, dass wir ein Pre-Key-Server brauchen und als wir Pigeon verwendet haben, gab es keinen Header, der dafür exponiert war. Also mussten wir da ein bisschen tricksen, um das umsetzen zu können. Liebe Zuhörer, vielen Dank. Das war jetzt OTR Version 4.