 Schönen guten Abend! Schön, dass ihr alle gekommen seid. Danke dem Wock und dem Mikrofon engeln zu unserem Vortrag ein VPN zum Schutz vor Quantencomputern. Wir werden damit anfangen zu erklären, was dieses Häschen und Rosenpass eigentlich soll. Rosenpass ist nicht nur ein VPN, Rosenpass ist Postquantum, Kryptografie, Kryptografie für die Zeit, nachdem wir tatsächlich Quantencomputer erfunden und implementiert haben werden. Und angefangen haben wir damit sichere, postquantensichere VPNs zu bauen, mithilfe des WireGuard-Protokolls. Und mehr wird jetzt noch nicht verraten. Ich stelle euch mal vor. Unser Lied der Korra, hallo Korra, und unseren Oberingenieur Vanya, der heute frisch aus Japan eingeflogen in der anderen Zeitzone wohnt und ein bisschen den Filmvorführer spielen wird und ein bisschen Live-Demo machen. Das ist unser erster deutschsprachiger Vortrag. Der ist ganz neu und wie immer ist der Vortrag buchstäblich fünf Minuten vorher fertig geworden. Er wurde also wie immer sehr, sehr gut. Wer Taipo findet darf sie behalten. Und damit fangen wir mal mit Folie 1 einfach an. Genau, wie so oft bei so einem Vortrag es ganz sinnvoll zu klären, worum es eigentlich geht. Wir können uns hier beiderseitig organisieren. Bei so einem Vortrag ist es immer ganz sinnvoll vorher zu sagen, worum es geht und was euch heute erwartet. Wir haben das so strukturiert, dass die Kryptografie nicht allzu schmerzhaft ist. Wir haben eine Demo und dann nochmal was in Farbe, das Animationen beinhaltet. Also wir werden das unterbrechen und dazwischen kommen dann unangenehme Mathematik. Genau. Aber wir fangen an erst mal damit zu klären, was Rosenpass eigentlich ist. Rosenpass ist nämlich mehrere Sachen gleichzeitig. Rosenpass ist auf der einen Seite eine Software und zwar ein Add-on für WireGuard, um Postquanten-Sicherheit zu ermöglichen. Das ganz implementierten Schlüsseltausch, der auch sehr entalone benutzt werden kann, also mit anderen Kryptografie-Softwares, Produkten oder Open-Source-Projekten integriert werden kann, die noch keine Postquanten-Kryptografie unterstützen. Wenn die Protokolle sinnvoll Design sind, die dahinter stehen, könnte das auch Postquanten-Sicherheit für andere Protokolle ermöglichen. Auf der anderen Seite ist Rosenpass eben ein eigenes kryptografisches Protokoll. Wir haben das nicht komplett alleine entwickelt, aber wir haben eben eine besonders gute neue Version von der Arbeit an Postquanten-Sicheren-Protokollen. Es ist ein kryptografisches Protokoll, ein Schlüsseltauschverfahren. Es ist Postquanten-Sicher. Ich glaube, ich habe hier einen Typ gefunden. Darf ich den behalten? Postquanten-Sicher. Und wir stehen auch an, dass wir formal verifiziert sind. Das ist eigentlich in sinnvoller Kryptografie, vor allem sinnvolle Open-Source-Kryptografie heute Standard, dass man ordentlich verifiziert, was für Kot man da produziert hat. Aber bei so manchen Kryptografie-Produkten ist das noch nicht so der Fall. Deswegen dachte ich mir das hervor. Genau und das Wichtigste für mich und für meine Aufgabe ist der dritte Punkt. Wir sind ein community-nahes Projekt, um Forschung zu ermöglichen und wir sind auch eine Wissenschaftskommunikationsinitiative, um Kryptografie der breiten Öffentlichkeit zugänglich zu machen. Also hier sind die Leute, die Gutes tun und ich bin dafür zuständig darüber zu reden und das irgendwie verständlich zu machen. Genau, weil wenn Menschen die Kryptografie, die sie einsetzen sollen, nicht verstehen, kommen meistens auch nicht so gute Systeme in der Praxis heraus. Das heißt, gute, sichere Kryptografie braucht auch gute Bildung, was Kryptografie angeht. Genau. Und bitte nicht frustrieren lassen. Es ist wie im alten Matheunterricht, ihr müsst das nicht alles gleich anschließend im Test reproduzieren, was hier so an die Wand geworfen wird. Und wir haben auch super schöne Illustrationen und es gibt ja Gott sei Dank eine Rückspultaste und MediaCCC.de. Es kommt auf jeden Fall nicht in der Klausur vor. Genau. Ja, also angefangen mit der Frage, was ist eigentlich das Problem? Angriffe von Quantencomputern sind das Problem und da gibt es ja schon diverse Vorträge, die das erklären. Wir rollen das hier nochmal kurz auf. Auf der einen Seite gibt es Shores Algorithmus. Also den Algorithmus von Peter Schor. Ich dachte, wir haben das mal hier aufgezeichnet, wo überall Namen drin vorkommen, weil diese ganzen kryptischen Abkürzungen sind eigentlich nur die Namen von Kryptografen, die sich da selbst verewigt haben. Und mit viel jargon löst das einige mathematische Probleme, auf denen moderne Kryptografie basiert effizient und effiziente Lösungen für diese Probleme bedeuten, dass die Kryptografie dann nicht mehr benutzt werden kann. Im Konkreten sind gebrochen die viel benutzten Verfahren RSA, Defi Helmen und Elliptikörf Defi Helmen. Also mit anderen Worten, wenn wir tatsächlich einmal Quantencomputer bei der Arbeit beobachten können, werden sie vielleicht gar nicht so viel können. Aber vermutlich werden sie gerade das besonders gut können, was die bisherige, häufig vorhandene Verschlüsselung in unserem Internet an allen entscheidenden Punkten bricht. Also ist es, meinen wir mittlerweile, fahrlässig, nicht bereits jetzt damit anzufangen, Kryptografie auszurollen, die das nicht mehr so einfach macht. Genau. Mit etwas weniger jargon bricht brechen Quantencomputer so ziemlich alle moderne Kryptografie, die derzeit eingesetzt wird. Es gibt viele Primitiven, die davon nicht betroffen sind. Das sind meistens symmetrische Primitiven, aber die meisten Applikationen, benutzen eine Kombination aus unsichern asymmetrischen Primitiven und sicheren symmetrischen Primitiven. Das heißt, in der Praxis sind so ziemlich alle Protokolle, die wir so benutzen, betroffen. Ein paar Protokolle haben schon den Schritt gemacht, daran zu arbeiten. OpenSSH waren, glaube ich, die Ersten, die das tatsächlich in der Praxis versucht haben. Es gibt dann noch einen anderen Angriff von Quantencomputern oder einen anderen Algorithmus über den über den man reden muss. Das ist Grovers Algorithmus. Auch hier wieder ist der Name Love Grover. Wieder komplex Suche durch ungeordnete Listen in O von Wurzel N, statt klassisch O von N. Übersetzt heißt das Bootforce Angriffe werden einfacher, aber nicht so viel einfacher, dass damit Kryptosysteme ernsthaft angegriffen werden können. Deswegen würde ich das mal als mostly harmless bezeichnen. Genau. Würdest du sagen, wenn, würdest du es sozusagen gut heißen, wenn ich sagte, es gibt schon seit langem die Mathematik, die es den Quantencomputern ausreichend schwer machen wird und wir können das bereits heute beweisen. Nur war diese Mathematik bisher viel zu schwer zu implementieren und wir haben jetzt damit angefangen. Ich glaube, Leute haben es einfach in der Praxis nicht getan, weil es ihnen egal war, aber wir haben jetzt auf jeden Fall damit angefangen und tatsächlich analysiert, während diese Probleme seit den 90er Jahren angefangen, hat das ganze mit dem Prozess die Schiffren selber, also wir nennen das die Primitiven abzudaten, dass die Postquanten sicher sind und jetzt müssen wir eben damit anfangen, die in der Praxis eingesetzten Protokolle auch Postquanten sicher zu machen und wir updaten eben so ein Protokoll. Quantencomputers sind ein ganz heißes Eisen. Absolute Hype-Technologie, die werden alles anders machen. Wir haben es noch nicht ganz geschafft, die wirklich zu erfinden. XKCD sagt, dazu ist dauert zehn Jahre. Es gab da ein paar Umfragen unter Kryptografinnen und Experten, die mal das Risiko abgeschätzt hatten. Da kamen im Großen und Ganzen raus, Kryptografinnen und Forscherinnen an Quantencomputern, sie sich auch nicht so ganz sicher, wie lang es noch dauern wird. Es kann auf jeden Fall passieren. Genau, vielleicht fragt man mal bei den Buchmachern oder den Versicherern nach. Das sind meistens die, die die besten Daten darüber haben. Seit einigen Jahren streitet man sich, wie viele Jahre es noch dauert. Also wir haben es noch nicht ganz erfunden, aber wir sind dabei und wenn wir es erfunden haben werden, dann wird es ganz toll oder furchtbar. Ich bin mir sicher, es kann nicht viel länger dauern als Fusionskraftwerke. Genau, immer zehn Jahre in der Zukunft von dem Punkt. Jetzt danke dafür. Es ist trotzdem wichtig, dass wir daran arbeiten, unsere Kryptografie gegen Angriffe durch Quantencomputer abzusichern. Da gibt es nämlich die Mann-Schnau-Decryp-Later-Attacke. Andere Leute nennen das nicht so, ich nenne das so. Da geht es nämlich einfach darum, dass Angreifer, zum Beispiel Nation-States, die uns ausspionieren wollen, einfach die ganzen Daten, die wir übertragen, zwischenspeichern und sie dann, wenn es mal Quantencomputer gibt, entschlüsseln. Genau. Das machen Sie seit, soweit wir wissen, wir Hacker und die anderen auch inzwischen, seit über 20 Jahren. Das sind schon ein paar Bytes. Genau. Das heißt auch, dass wir eigentlich, das beste Case-Szenario, in dem wir halbwegs geschützt sind, ist, es dauert jetzt noch 20 Computer, bis es tatsächlich Quantencomputer, 20 Jahre, bis es Quantencomputer tatsächlich gibt. Weil wenn es die in fünf Jahren gibt, haben wir ernsthaft ein Problem, weil dann sind die ganzen Daten, die wir jetzt heute übertragen, geliegt. Genau. Und der Zeitablauf ist zumindest in seiner Wahrnehmung auf gar keinen Verlierer. Denkt an den Hype, um JetGPT jetzt und so weiter. Plötzlich ist es passiert, wer hätte denn das ahnen können? Hätte uns doch nur jemand gewarnt? Na ja, wir versuchen es mal wieder. Ja, dieser Hamster mag vielleicht süß sein, die NSA ist es nicht so und deswegen sollten wir uns schützen. Das andere Argument für Firmen im Wesentlichen ist, man kann denen einfach sagen, ja, es wird halt schon standardisiert und dann müsste euch daran halten, etch a batch. Linist, das National Institute for Standards and Technology, also eine Standardisierungs- Organisation aus den USA, hat bereits damit angefangen, Postquanten, Kryptografie zur Verschlüsse standardisieren. Der Prozess läuft seit etlichen Jahren. Inzwischen gibt es ein paar Finalisten, von denen man davon ausgeht, dass sie dann auch tatsächlich standardisiert werden und dass sie praktisch eingesetzt werden. Bei der Verschlüsselung ist das Crystal Skyber. Der Name Skyber kommt von den Lightsabern, den Lichtschwertern, die man in Star Wars benutzt. Der Mensch, der damit gearbeitet hat, einer derjenigen ist ein Star Wars Buff. Auch die Namen bedeuten wenig, Kryptonamen bedeuten selten viel. Es ist einfach Mathematik. Ein paar andere Verfahren, meistens Signaturverfahren, bei Verschlüsselung ist es so, dass es da eine Schiffe, eine Handvoll Schiffen gibt, die relativ gute Eigenschaften haben, die relativ vielseitig einsetzbar sind. Bei den Signaturen ist es so, dass es unterschiedliche Einsatzzwecke gibt und bestimmte Verfahren einfach für einen Einsatzzweck nicht okay sind, weil die Schlüssel besonders groß sind oder bei die Ciphertext besonders groß sind. Das heißt, da gibt es ein paar Trade-offs, deswegen gibt es da mehr. Und auch das BSI, also das Bundesamt für Sicherheit in der Informationstechnik, hat Empfehlungen rausgehauen, was man denn so an Postquanten Gryptografie benutzen sollte, und zwar Frodo, Fachwort, Frodo und Classic McLeese. Das heißt, man kann auch einfach sagen, ja, nimmt halt die Standards, die Standards sagen, tut das. So, und jetzt wird es langsam etwas kompliziert. Da sind jetzt so ein paar fiese Abkürzungen. Camp, Nike, ARD, böhmische Dörfer. Camp steht für Key and Capsulation Method, Nike steht für Non-Interactive Key Exchange, keine Schuhe. Auch wenn die Kryptoforträge, die mit Nikes zu tun haben, gerne Schuhe abbilden als Scherz, das wird dann immer etwas ermüdend. Dann kann man sich das besser merken. Ja, oder man wird einfach nur müde und hat so einen Geruch in der Nase. Genau. Und ARD steht für Authenticated Encryption with Associated Data, also authentifizierte. Ich finde das ja fantastisch mit den Akronümen. Wir haben nachher noch eine Akronümen-Generationsmatrix. Ja, also ich habe das vorher auch geübt, und zwar vor dem Spiegel, und dreimal hinter den Anlagen sagen, dann dreht man sich um und schaudert. Genau. Camps und ARDs sind okay. Symmetrische Kryptografie, heutzutage baut meistens auf der, auf der, auf der, üblicherweise auf der symmetrischen Kryptografie auf. Also es gibt viele Spezialfälle, aber die Verschlüsselung nutzt üblicherweise ARDs, symmetrische Kryptografie, einfach weil die sehr effizient ist. Und da geht es bei der asymmetrischen Kryptografie nur noch darum, ein Schlüssel zu erzeugen, der dann von der symmetrischen Kryptografie benutzt werden kann. Deswegen bauen die meisten Protokolle eben auf so eine ARD auf. Und dann muss man eben sich über den Schlüsseltausch einigen, und den Schlüsseltausch kann man ungefähr auf zwei Weisen machen. Da gibt es auf der einen Seite eben die Camps und die Nikes. Ausgründlich nachher noch erläutern werde, benutzen die meisten Protokolle heutzutage Nikes, inklusive WireGuard. Aber die sind eben im Post-Quantum-Setting nicht verfügbar. Deswegen muss ich gar nicht so viel von Quantencomputern wissen. Ich muss selber eigentlich gar keine Quantenkryptoanalyse machen. Für mich reicht es, einfach Protokolle mit Camps zu bauen. Und dann können Leute immer sagen, ja voll krass, du machst Dinge mit Quanten. Und ich weiß in meinem Kopf, dass ich davon auch nichts verstehe. So. Und um das Ganze ein bisschen aufzulocken, ich habe versprochen, wir haben ein paar Demos. Genau. Deswegen zeigen wir euch gleich, wie Rosenpass funktioniert. Also wie man das einsetzen kann. Hier seht ihr die QuickStart Instruktionen auf unserer Webseite Rosenpass.eu. Könnt ihr durchgehen und Rosenpass einfach bei euch selber aufsetzen. Firewall-Regeln stellen sich als tricky raus. Achtet auf eure Firewall-Regeln. Das Ganze benutzt UDP. Aber wenn ihr dem Guide folgt, dann sollte ihr in der Lage sein, einfach heute Abend vielleicht noch sogar ein Post-Quantum-Sicheres VPN-Netzwerk aufzusetzen. Also ich hoffe zumindest, dass es Post-Quantum-Sicher ist, so ganz sicher sein. Ist natürlich schwierig. Also unsere wunderschöne Webseite mit ihren schönen Illustrationen, die ihr auch noch sehen werdet, ist natürlich ein ewiger Quell der Weisheit, der weiterentwickelt wird. Und wir haben auch ein wunderschönes, kleines White Paper und fast alles, was ihr heute Abend seht, ist da drin oder wird in Kürze dort aufscheinen. Schauen wir mal, was passiert. Ja, ich würde einfach mal einmal reinschauen, wie das aussieht mit so einem Exchange, kurz reinschauen in die Zutaten. Im Prinzip hat man, was man normalerweise für ein Wireguard-Exchange braucht, man hatte so ein Wireguard-Key, gibt es einen Private-Key und einen Public-Key. Der Private-Key, den haben wir mal, weil beides mit P-Public anfängt, SK genannt, also der Secret-Key für Wireguard und der Public-Key für Wireguard. Und dann hat man einfach das gleiche noch mal für Rosenpass. Das heißt, wir haben beides. Und das wäre dann hier der PQ wie Post-Quantum, Kryptografie, Public-Key und Secret-Key, also der PQ-SK. Die größten Probleme der Mathematik und der Informatik sind eigentlich nicht Informatik oder Mathematik, sondern Namen für Dinge finden. Ist es schwer? Genau. Und dann kann man sich ein wahnsinnig langes Kommando ins Terminal eintippen. Ich glaube, es sind 23 Argumente in Summe. Also wie viel auch sonst? Übersichtlich. Lange Rede, kurzer Sinn. Wir wollen einen Exchange machen. Wir geben an in einem Ordner, in dem wir unsere Secret-Key finden. Wir geben an, dass wir einen Device anlegen wollen, ein Wireguard-Interface einfach, das wir Rosenpass 0 nennen. Wir wollen auf diesem Server, also ein Server, der woanders ist, nicht mein Laptop, auf Port 9999 Horchen. Und wir haben einen Pier, mit dem wir interagieren. Und dieser eine Pier, der hat ein Public-Key, den wir kennen, der ist also auch schon hier abgeliefert. Und der darf unter einer bestimmten IP-Adresse mit uns kommunizieren. Und dann können wir den Server hier einmal starten. Und dann machen wir sowas ähnliches auf meinem Laptop-Lokal. Dann haben wir wieder ein übersichtliches Kommando. In diesem Fall machen wir den Exchange mit dem Client Secret. Und wir legen auch ein Rosenpass 0-Device an. Wir haben einen Pier, und zwar hat dieser Pier einen Public-Key und das ist dann der Domainname von meinem Server und der Port, auf dem wir verbinden wollen. So, und das Versprechen aus der Werbung ist, dass wenn ich das starte, wir hier dann gleich vielleicht ein Key-Exchange bekommen. Das Interface existierte schon, jetzt sollte das klappen. Wir haben uns überlegt, ob wir mutig sind oder nicht. Und dann festgestellt, dass wir dumm sind und uns für eine Live-Demo entschieden. Ja, jetzt ist die Frage, funktioniert das Ganze? Daher würde ich einmal eine IP-Adresse auf das Interface hinzufügen auf meinem Laptop und eine IP-Adresse hinzufügen auf dem Server. Wie ihr seht, wir sind ganz vorne dabei. Wir benutzen bereits ausschließlich IPv6. Wir waren so gnädig. Rosenpass funktioniert auch mit IPv4, aber nur weil wir einen guten Tag hatten und echt gut aufgelegt waren. Genau. Und einen riesigen Kater. Und dann können wir einmal reinschauen in den Output von WireGuard ShowAll Pre-Shared Keys auf meinem lokalen Rechner, auf dem Laptop. Und wir sehen hier ist also irgendwie schon was da. Es gibt irgendwie einen Pier. Und wenn ich ganz viel Glück habe, dann kriegen wir sogar einen Ping an den Server durch. Und es funktioniert. Also wir haben jetzt eine WireGuard-Verbindung aufgebaut. Jetzt bin ich erleichtert. Vielleicht noch mal eine Sache, die hier ganz interessant ist. Wir machen eine neue Dinge und neue Dinge können kaputt gehen. Und es kann sein, dass wir was falsch gemacht haben. Tatsächlich haben wir heute einen Fehler gefunden in Rosenpass und natürlich sofort korrigiert. Und deswegen nutzen wir die Kryptografie, die in WireGuard drin steckt, zusammen mit der Rosenpass-Kryptografie. Das heißt Rosenpass macht ein Key Exchange. Da fällt ein Pre-Shared Key raus. Also ein gleiches Geheimnis auf beiden Seiten. Und das geben wir einfach als Pre-Shared Key in WireGuard mit rein. Aber WireGuard macht auch seinen eigenen Key Exchange. Deswegen ist es auch so interessant hier in die Pre-Shared Keys reinzuschauen. Aber dazu haben wir, glaube ich, auch eine Folie, oder? Genau. Das haben wir noch in Folien aber schon mal merken. Wir machen also an WireGuard nichts kaputt. Im Gegenteil, wir nutzen eine Funktion, die davon anfangen an, die in diesen 1700-Zeilen Beautiful Code vorgesehen ist, nämlich den Pre-Shared Key zu erzeugen und zu injizieren. Und wenn aus irgendeinem Grund, dass mit Rosenpass nicht geht, dann läuft WireGuard einfach weiter, als hätte es nichts bemerkt. Genau. Zwei Dinge, die ich hier noch bemerken möchte. Wir wissen, dass dieses Kommando da oben, das ein bisschen breit ist, dass das vielleicht ein bisschen anstrengend ist. Wir haben nachher noch eine Umfrage, wie ihr es gerne besser hättet. Genau. Publikums Beteiligung. Genau. Nachher ist Community Activity hier. Genau. Das andere Thema ist, was wir da haben, was ihr vielleicht wissen solltet, was uns vor allem beim Testen auch aufgefallen ist. Wenn ihr Rosenpass, also dem kleinen RP-Tool sagt, ja, nimm mal Port 9999, dann nimmt der auch Port 10.000 für WireGuard selber. Das heißt, ihr müsst dann zwei Ports öffnen. Das hat uns vor allem ganz schön Zeit gekostet, weil ich hatte es auch wieder vergessen. Ja. So, das war eine Demonstration. Wie viel Zeit haben wir denn noch? Jede Menge. Ja, super. Dann darf ich euch jetzt Mathematik zeigen. Genau. Ein Scheuerblick in Dinge, die ihr am liebsten nicht gewusst hättet. Genau. Kurz zum wieder reinkommen. Wir hatten ja vorhin diese Folie und haben gesagt, ARDs. Symmetische Verschlüsselung, auf denen baut das Ganze aus. Auf Heutzutage benutzen alle Leute NICs. Die gibt es nicht im Post-Quantum-Setting. Was es gibt, sind Cams, NICs, Non-Interactive Key Exchange, CAM, Key Encapsulation Method. Das heißt, das Problem, an dem wir eigentlich arbeiten, ist, von NICs zu Cams zu kommen. Genau. Und, da wir genug Zeit haben, darf ich euch diese Folie präsentieren? Genau. Und diesen wunderschönen Generator für Akronüme da rechts, merkt ihr euch gut, dem es ihr wiederholen und im Dunkeln aufzeichnen können. Static Secret Key Initiator. Oder dann gibt es auch zum Beispiel den Ephemeral Public Key Responder. Jede Kombination ist möglich und wir dachten, wir brauchen nochmal ein Naming-Schemie, die Kriptographen sagen immer K und dann nehmen sie Groß-K und als Nächstes nehmen sie Kappa. Und dann kommt Kappa in Blackboard-Bold und dann kommt Kappa in Bolt und dann bekommen sie die E-Ball von mir. Genau. Also es gibt noch viel zu tun. Genau. Deswegen haben wir, auch im White Paper haben wir eben diese Nomenklatur eingeführt für die verschiedenen Variablen, die wir benutzen. Und wir benutzen tatsächlich sprechende Variablen. Sie sind vier Buchstaben lang. Wir haben uns aber trotzdem an der Informatik orientiert. Was ich hier links sehe, ist ein ganz simpler Schlüsseltausch mit NYX. Da habt ihr diese Linie nach unten und das ist ein Flussdiagramm, falls ihr das schon mal gesehen habt. Nach unten ist weiter in der Zeit links ist der Initiator, das ist einfach da das Ganze startet. In TLS, in der Server-Kleinwelt würde man sagen, dass der Kleint auf der rechten Seite habt ihr den Responder. Den darf ich auch behalten, den Typ. Auf der rechten Seite habt ihr den Responder und dann haben wir jeweils dazu, was übertragen wird, das ist auf dem Pfeil. Und wir haben dazu auf der jeweiligen Seite die Operationen, die ausgeführt werden. NYX haben zwei Operationen. Key-Gen, Schlüsselgenerieren. Und die NYX-Operation selber, die hier DH heißt, bei der Praxis ist das immer Diffie-Helmen. Also NYX sind quasi die Klasse von Algorithmen, die so funktionieren wie Diffie-Helmen. Dann gibt auch ein paar andere, die so ausprobiert werden, aber das sind die, die benutzt werden. Genau, und dann generiert der eine Participant, generiert einen Schlüsselpaar, also einen Private Key und ein Public Key. Der andere Participant tut das auch. Die schicken sich gegenseitigere Schlüsse zu. Also beide kennen ihre jeweiligen Schlüsse. Wir sagen jetzt hier in dem Beispiel, ja, das passiert in der Präambel, also bevor das Protokoll selber läuft und dann das Protokoll selber, seht ihr ja ganz unten, dass es dieses Key, vor allem nach links, DH, SSKI, SPKR auf beiden Seiten, da werden gar keine Daten übertragen. Daher kommt auch der Name NYC, Non- Interactive Key Exchange. Es ist ein Schlüsseltausch, der keine Interaktion enthält. Wir haben also keine Kommunikation und beide Parteien führen die DH-Operation auf, hier war es mit ihrem eigenen Private Key und dem Public Key des Partners. Und die kommen dabei, so will es die Mathematik bei den gleichen Werten raus und haben damit einen Schlüssel getauscht. Ich habe eine Vokabelfrage. Vokabelfrage? Ja. Und zwar, was ist ephemeral? Ah, danke, danke. Ja, Aesthetic steht für Statisch, also der wird vorgeneriert. Das ist das, was wir vor einem Terminal in dem schönen Listing gesehen haben, was wir so feils generiert werden. Und ephemeral ist Kryptografen-Sprech für Temporary Aufzeit. Ephemeral Keys sind Schlüsse, die generiert werden während dem Ablauf des Protokolls und hinterher wieder sofort gelöscht werden, um Forward Secrecy zu erreichen. Also zwischendurch mal nachfragen, ob noch alles okay ist und ob da keiner was ... Wir haben auch schon überlegt, ob wir Kekse bringen sollen. Dann ist aufgefallen, es war Sonntag. Passiert mir da ... Oh, das ist Ostern auch, das habe ich auch nicht bemerkt. Any way, beide Parteien führen diese Operation aus. Hier war es mit ihren Schlüsseln, ob die es ephemeral oder Statisch sind, funktioniert beides. Die unterscheiden es sich nicht und kommen bei dem gleichen Schlüssel raus und das Ganze ist ziemlich effizient, weil man dafür keine weitere Kommunikation braucht. Das ist auch der Grund, warum alle diese Mikes nehmen, weil die einfach so ein bisschen effizienter sind. Okay, wir haben es vorher noch mal in diesem Pyramidensystem gesehen. Das ist was bisher meistens benutzt wird aus guten Gründen. Leider geht das in Zukunft nicht mehr und das ist eine der wesentlichen Leistungen von Rosenpast, dass wir dafür eine Lösung anbieten. Das ist auch tasselig, gar nicht unsere Arbeit. Andere Leute haben das schon gemacht, aber wir haben es in eines auch für die Benutzbarhäste eingebaut. Genau. So, hier sieht man Cams. Das, was wir in Zukunft werden benutzen müssen. Schwere Schicksal. Cams haben drei Operationen. Auf der einen Seite haben sie die Operation Key, Genereme ein Key, das ist genauso wie bei Nikes. Und dann haben sie die Operation Encaps und D-Caps. Encapsulate verpackest mir und D-Capsulate packst mir wieder aus. Encapsulate nimmt den öffentlichen Schlüssel. Das Gegenüber ist, dass man den Schlüssel schicken möchte. D-Capsulate nimmt den privaten Schlüssel des Empfängers. Wenn ich an eine Partei etwas, was Encapsulated ist, schicke und die mir sagen kann, was es war, dann hat die Partei bewiesen, dass sie den Private Key dazu besitzt. Das nennt man Authentifikation. Die beweist, dass sie einen Private Key besitzt. Kann man auch mit Verschlüsselungsmethoden wie hier machen, oft werden Signaturen verwendet, aber Signaturen sind dazu gar nicht strictly necessary. Genau, Encapsulate gibt nicht nur den Encapsulate, gibt den symmetrischen Schlüssel zurück, das den Dainee, der es Encapsulated auch besitzt. Encapsulate gibt auch einen Cyphertext, also verschlüsselte Daten zurück, die dann an den Empfänger geschickt werden. Das Ganze ist analog zu dem, was man so als asymmetrische Verschlüsselung kennt. Früher war das auch mal asymmetrische Verschlüsselung, da würde man jetzt RSA oder sowas nehmen. Heutzutage macht man eigentlich nicht mehr asymmetrische Verschlüsselung, sondern man definiert einfach eine CAM, weil für die eigentliche Verschlüsselung sind ARDs symmetrische Primaetiven eh besser und schneller. Das heißt, man baut einfach nur noch die und bekommt dann manchmal so noch ein bisschen effizientere Keysize, ein bisschen weniger Daten, die man übertragen muss. Also ich gehe nochmal zurück. Diffy Heymann braucht keine Interaktion und kombiniert den eigenen Private Key mit dem Public Key des Gegenübers und CAMs Schlüsse erstellen, Schlüsse übertragen, symmetrischen Key verschlüsseln, encapsulieren, encapsulate und dann wieder decapsulieren. So und das wirkt jetzt auf den ersten Blick ein bisschen einfacher als das vorherige Protokoll, weil hier auch zwei Pfeile sind, die ein bisschen weiter auseinander sind. Ich habe da aber ausgespart, dass das hier ein Protokoll ist, was eigentlich nur eine einseitige Authentifikation macht. Ich habe gerade erklärt, Beweis, dass ein Private Key im Besitz des Empfängers ist, passiert hier implizit auf beiden Seiten, also beide Parteien wissen, ja, das ist schon die richtige Person, mit der ich gerade schreibe, der richtige Participant würde man sagen und hier ist es nur einseitig. Also der Responder beweist dem Initiator, dass der Responder sein Private Key kennt, das ist aber nicht umgekehrt und bei decaps sollte noch ein Parameter mehr dabei sein, den behalte ich auch, den typo. Das hier ist, wie man ein Static-Static-Exchange, also wo beide Partner sich beweisen, dass sie den jeweiligen Schlüsse besitzen, realisieren würde mit CAMs, beide erzeugen ihre Schlüsse im Setup, übertragen die sich aneinander und beide Parteien für jeweils Encapsulate und Decapsulate-Operationen durch und schicken die jeweils aneinander gegenseitig. Eigentlich im Protokollverlauf sind das zwei Nachrichten, die übertragen werden eine Runde, sagen wir, eine Runde einmal hin und zurück. Bei NICs sind es Nullrunden. NICs, City hier wird falsche Folie. NICs, wenn hier keine Daten übertragen werden, können dem eigentlichen Protokoll bei CAMs werden zwei Nachrichten übertragen. Es ist auch ein bisschen gelogen, was ich schreib. In der Praxis benutzen die Protokolle komplexere Dinge. Da möchte man irgendwie noch andere Eigenschaften haben. Es ist aber auch tatsächlich so, dass Rosenpass ein bisschen mehr Interaktion braucht als WireGuard. WireGuard braucht zwei Pakete, Rosenpass braucht drei. Nicht so schlimm in der Praxis, aber sollte man gesagt haben. So, und das ist jetzt, wie Rosenpass funktioniert. Hier seht ihr drei von diesen Flussdiagrappen. Ich habe mir mal aus Platz gründen, die Operationen an den Seiten jeweils gespart. Das sind einfach im Prinzip dreimal diese Operationen hier. Keygen, NCAPs, DCAPs. Passiert hier genauso. Bei allen Plätzen ganz oben Keygen wird einmal der Schlüssel übertragen. Dann wird vielleicht im Fall von Initiator-Orth aus protokollspezifischen Gründen, also im Fall der Initiator, Authentifizierung, wird die Identität des Initiators übertragen. Einfach, weil es das einfacher macht und der Empfänger nicht raten muss, mit wem spreche ich da eigentlich. Dann wird der Beweis zurückgeschickt. Ja, ich kann das wirklich. Dann wird eine Challenge geschickt, also ein Ciphertext generiert. Der Empfänger entpackt die Challenge, bekommt dadurch den Schlüssel und beweist dann auch mit einem Actualagement, wie wir es hier genannt haben, also mit einer Bestätigung. Ich kann das wirklich auspacken. Das machen wir dreimal. Einmal um den Initiator, den Beginner, den Starter zu authentifizieren. Dann einmal um den Responder, den Empfänger zu authentifizieren. Und dann ein drittes Mal mit dem zufällig gewählten Schlüssel, um Forward Secrecy zu erreichen. Das ist diese Sicherheitsproperty Eigenschaft, die wir vorhin erklärt haben, die dafür sorgt, dass selbst, wenn die Polizei bei den Cyberbetreibern einreitet und die Private Keys, die Static Private Keys mitnimmt, bleibt immer noch eine Sicherheit erhalten. Genau, also wir fragen zwischendurch immer noch mal nach, bist du eigentlich immer noch derselbe, der da sitzt und lauscht? Genau, selbst wenn die statischen Schlüssel eingesackt werden von der Polizei, können sie die Interaktion, die Daten, die hier und her gesendet wurden, nicht mehr entschlüsseln, weil das ja noch der dritte Schlüssel, der ephemeral, der zeitweise Key. Und der wird dann gelöscht, sicher gelöscht, der wird auch gar nicht auf Platte geschrieben oder so, sondern der bleibt einfach im Speicher. Und darauf, dass er gelöscht wird, kann er auch nicht mehr eingesackt werden. Ich habe eine Frage, wenn der ephemeral Key, also dann nach einer Zeit gelöscht wird, wie lange lebt er denn so, so lange wie Hase oder Fliege? Arme Hasen, so lange leben die auch nicht. Aber der ephemeral Key lebt zwei Minuten, der ist ja kurzlebig. Wir machen ähnlich wie Wireguard, machen wir in der Paxis alle zwei Minuten einen Key exchange, dann wird der neue Schlüssel an Wireguard geschickt. Und der alte ephemeral Key wird dann nach weiteren zwei Minuten gelöscht. Also hier hatten wir drei Cam-Operationen, zwei mit statischen Keys, einen mit einem ephemeral Key, einem Key, der spontan erzeugt wird und dann übertragen wird. Zwei Operationen mit den statischen, um zu beweisen, dass die Teilnehmer wirklich die sind, die sie vorgeben, zu sein und einer, um forward secrecy zu erreichen. Ja, und ich habe es im Wesentlichen geschafft, weil das war auch schon wie das Ganze funktioniert hat. Dieses Leid hier, es ist nicht ganz akkurat, im White Paper wird das noch mal genauer beschrieben, wie das in der Paxis funktioniert, aber dieses Leid, dieses Diagramm ist einfach die verschiedenen Operationen zusammengefasst. Und dann werden eben die Pakete entsprechend kombiniert. SPKI sieht ja in der Preamble auf der ersten Linie SPKI, SPKI R. Kennt ihr von der Responder-Authentifizierung, wird dann hier auch übertragen und dann so weiter, Komma bedeutet einfach nur, die werden aneinander gehängt in einem Netzwerkpaket. Stumpf diese drei Operationen werden zusammengehängt. Man muss die Keys, die Schlüssel übertragen und genau, dann werden noch drei Pakete hin und her gesendet und dann ist man eigentlich durch. So sieht das Ganze in unserem White Paper-Aussatz kommt noch ein bisschen Kram dazu, das Biscuit oder das Biscuit. Ja, wie die genau aussehen und wie lang die sind, könnt ihr im White Paper nachlesen. Da müssen wir jetzt aus Zeitgründen, wenn ich einen Sprung mache. Genau, es gibt mir ein bisschen drüber, genau, aber das Biscuit sorgt dafür, dass noch bestimmte Attacken, die bei WireGuard und bei PostQuantum WireGuard unser Vorgängerpaper möglich waren, nicht mehr möglich sind. Details erzählen wir dann ein anderes Mal. Ah, dieses Leid wollte ich doch eigentlich runter bewegen. Das ist super viel Text. Beginne einfach direkt drüber, ihr dürft euch das hinterher, wenn ihr unbedingt wollt, nochmal durchlesen. Eigentlich wollte ich euch das hier zeigen, das ist nämlich die Demo. Also es gibt, wir benutzen sozusagen Rechtschreibkontrolle für kryptografischen Code und auf einer Konsole sieht das unter anderem Altersdiskriminieren so aus. Also mein Konsolefond ist ja sehr, sehr groß. Ich habe das absichtlich kleiner gemacht, dass ihr das ganze Gründe unten sehen wollt, sehen könnt. In Farbe. In Farbe, genau, wie bei, wie bei, wie bei Software-Tests ist es auch hier so, dass wir eben testen, wie gut die Kryptografie funktioniert und dass wir uns freuen, wenn alles Grün ist, wenn es rot ist, heißt, dass wir haben Fehler gemacht. Jetzt ist es natürlich so, ich würde sagen, das Rosenpass-Projekt ist auf der Komplexitätsebene für Software, so beim Moderat. Das heißt, wir haben schon ein bisschen verschiedene Tools, der reingehen wir hintergehen mit WireGuard, wir nutzen Kryptografie-Implementierung, die in C geschrieben sind. Rosenpass selber ist in Rust geschrieben. Proverif, diese statische Analyse, die schreibt man in einer Sprache. Das ist eigentlich gar keine Sprache, die ist ganz gruselig. Und das ist alles irgendwie ein bisschen unübersichtlich. Das sind viele kleine Zahnrädchen. Und um das ein bisschen verfügbarer zu machen, aber vor allem, damit ich es auch ausführen kann, habe ich das Ganze ein bisschen mit nix gepackaged. Kurze Frage, wer kennt nix? Okay, das ist motiviert. Das richtige Publikum. Man muss nur zum richtigen Publikum gehen. Entschuldige mich im Voraus für den dunklen Witz, aber alle, die nix nicht kennen, das macht auch nichts. Im Prinzip ist es also so, wir haben unser Projekt organisiert in einem Repo. Ich ist mein lokaler Checkout von dem Repo und wir haben diverse Checks definiert in einem Flake. Flakes sind die neue heiße Sache, wenn man was mit nix machen möchte. Der Satz klingt auf Deutsch sehr doof. Und das, was wir hier drin haben, sind also sowohl entsprechende Pakete, die man bauen kann, wo das Rosenpass binary drin ist, wenn man das benutzen möchte. Aber wir haben zum Beispiel auch diesen erwähnten Beweis oder die statische Analyse mit dem Proverif Tool gepackaged. Also man könnte jetzt anfangen mit nixbild und dann irgendwas mit Proof und dann müsste ich habe schon gebaut, aber ich könnte es noch mal bauen. Und dann würde das anfangen, das zu bauen. Und dann dauert es sehr lange, also auf meinem Laptop ungefähr eine Viertelstunde. Wir waren es besser nicht ab, aber hier würden nach geraumer Zeit dann kleine Beweise rausfallen oder kleine Behauptungen, dass bestimmte Eigenschaften, die wir auf dem Protokoll claim, tatsächlich auch eingehalten sind. Der Fernseher, muss man sagen, das prüft nicht den tatsächlichen Source Code, sondern eine abstrakte Definition von dem Protokoll. Das heißt, das Protokoll kommt mit einer Form der formalen Verifizierung. Der Source Code ist halt so gut, wie er ist. Er ist ein Rust geschrieben, also er könnte schlechter sein. Aber das sind garantierte noch maskierte und auch nicht maskierte Fehler drin. Und wenn jemand einen findet, anders als mit den Slides, dann ist das auch super, wenn er den Fehler dann kommuniziert. Also auf GitHub Rosenpaß findet ihr unser Rebus und dann tut er mal Issus hin und so. Wir würden sehr gerne über kryptografische Fehler in unserem Protokoll wissen. Haltet euch da nicht zurück, behaltet die Fehler bitte nicht. Ich bin ganz besonders stolz darauf, dass es in Farbe ist, wie ich eben schon gesagt habe. Als ich dieses Tool das erste Mal benutzt habe, hat das so Textbrechreiz bekommen. Und da hatte ich so ein paar Zehntausendzeichen Texte und ich wusste gar nicht, was ich damit anfangen sollte. Ich habe kürzlich auf einer Konferenz gelernt, die anderen Kryptografinnen haben das gleiche Problem und alle haben ihr eigenes Tool. Das ist genau das, was ihr macht. Und wir sind dann überlegen, ob man da vielleicht nicht mal irgendwie Arbeit reinstecken sollte. Wir sind dann darauf gekommen, dass man daraus kein Paper rausmachen kann und dass man es deswegen lieber lasten sollte. Ja, es scheint da eine Konferenz für Usability zu geben, aber die wissen nichts von symbolischen Beweisen und formellen Beweisen. Deswegen ist das ein bisschen schwierig. Wir bemühen uns, wir beschweren uns laut. Vielleicht um das nochmal zu illustrieren. Der Output von dem Tool ist also ein Dot-Graph und ein paar HTML-Dokumente, wo drin steht, welche Clauses überprüft wurden und ob die Behauptung gehalten hat oder nicht. Die Summe aus diesen HTML-Dokumenten, die nicht gestylt sind, das ist einfach groß, HTML ist ungefähr 200 Megabyte groß. Also, das ist eine Menge extrem unlesbarer Output, der da für den Menschen produziert wird. Ja, wir hatten das Repository am Anfang in so einem privaten Github. Ging es einfach, weil wir in Ruhe problemieren wollten. Und dann hat Vanja angefangen, da dieses hier iTools einzubauen und einfach alle Artifakte hochzuladen. Irgendwann hatte Github so eine böse E-Mail geschrieben und so geschrieben, schönes Repository haben sie dann doch da. Geben Sie uns mal Geld, ansonsten können Sie keine weiteren Artifakte hochladen. Und dann hat mich Vanja sehr treu angeschaut, da habe ich gesagt, okay, ich züge meine Kreditkarte. Ich musste aber am Schluss nichts zeigen, wo ich sehr froh bin, denn Geld habe es nicht so in der Firma insofern. Wir haben das dann früh genug veröffentlicht, das Github doch gesagt, ja, das müsste doch nichts sein. Wir mussten uns nur die Kreditkartendaten geben. Na, dann machen wir mal weiter mit der Präsentation. Genau. Ja, jetzt kommt die allerbeste Grafik von allen. Das ganze Team sitzt übrigens hier auch unsere Illustratorin Molana. Also extra Applaus, ohne die so alte Menschen, so alte Menschen-TM, wie ich, nie eine Chance gehabt hätten zu kopieren, was hier läuft. Aber jetzt. Genau, also diese Grafik ist made by Molana und Marei bei der Unglaublich. Vielen Dank. Ich habe gestern, danke, danke, das war awkward von mir. Ich hätte das vorbereiten sollen. Die Grafik, wo habe ich letzte Nacht noch gemacht? Sie sah sehr schlecht aus und dann habe ich die so hochgeladen und gesagt, können daraus noch schnell was machen. Und dann ist heute Abend das Star rausgefallen zum Niederklin. Frisch von der Presse. Das stellt da wie Rosenpass und Wireguard miteinander interagieren. Also dann? Auf der einen Seite ist Rosenpass, auf der anderen Seite ist Wireguard beide laufen zusammen. Das ist das Wichtigste, was wir immer dazusagen müssen. Wir ersetzen Wireguard nicht, beide funktionieren einfach zusammen. Rosenpass macht Handshakes und dann macht es noch ein Handshake und dann macht es noch ein Handshake immer weiter. Und jedes Mal, wenn Rosenpass ein Handshake gemacht hat, etwa alle zwei Minuten, setzt es den PSK, den Pre-Share-Key in Wireguard. Wireguard war klar genug, sich zu denken, ah, in zehn Jahren haben wir vielleicht das Problem mit Quanten-Computern und hat gleich eine Funktion eingebaut, die es quasi einfach macht. Da Post-Quantengryptografie einzubauen. Andere Protokolle sollten sich da vielleicht auch eine Scheibe abschneiden, andere Implementierung zumindest sowas einzubauen, dass so ein Tool wie unser es dazu gepackt werden kann. Wireguard selbst macht alle zwei Minuten auch einen neuen Handshake. Da lädt man den Schlüssel rein, den neuen PSK, dann bricht keine Verbindung ab oder so, sondern einfach beim nächsten Re-King das Wireguard macht, sondern man benutzt es den neuen Schlüssel. Und das heißt das Ganze ist vollständig transparent. Im Hintergrund werden einfach immer neue Schlüssel erzeugt und dann werden die übertragen und es funktioniert einfach im Wesentlichen. Und da kann es natürlich passieren, dass Wireguard aus irgendeinem Grund weiter funktioniert, aber Browsenpass nicht, zum Beispiel, weil die Firewall verkonfiguriert ist, wie bei uns heute. Und dann geht Browsenpass tatsächlich hin, erzeugt einen zufälligen, einen kaputten Schlüssel, den der Pierre nicht kennt, schreibt den Wireguard rein, um absichtlich die Verbindung zu unterbrechen, weil die ist dann ja nicht mehr vollständig kryptographisch gesichert. Das hört sich jetzt so ein bisschen unangenehm an, ja, da verlieh ich doch meine Verbindung. Wenn wir das nicht tun würden, würde man das eine Downgrade-Attacke nennen. Dann würden Leute einfach Browsenpass unterbrechen und Wireguard würde fröhlich weiter funktionieren. Deswegen unterbrechen wir absichtlich die Wireguard-Verbindung. Und dann, wenn aber Browsenpass wieder eine Verbindung hat, wird der Schlüssel einfach ganz normal an Wireguard gegeben und Wireguard kann auch eine neue Verbindung aufbauen. Und die Recovery, also das Wiederherstellen der Verbindung, geht sogar relativ schnell, weil Wireguard da Funktionalität drin hat, die, wenn es einen Fehler gibt, schneller noch mal einen neuen Handshake macht. Das heißt, sobald die Verbindung wieder funktioniert, baut sich die auch wieder automatisch auf. Vielleicht an der Stelle noch einmal ein Chapot an Wireguard, der Mechanismus ein pre-shared Key zu benutzen, um eine Kryptografieimplementierung mit Erweiterungen versehen zu können. Das ist sehr genial. Wir linken gar nicht gegen den Wireguard-Code selber. Wir brauchen den Source Code von Wireguard gar nicht. Und trotzdem können wir einen eigenen Key-Exchange davor klemmen, haben die kombinierte Sicherheit von dem Wireguard-Key-Exchange und unserem Key-Exchange. Das heißt, jemand müsste beide Exchanges brechen, um die eigentliche Information im Tunnel zu kompromittieren. Und dadurch, dass der pre-shared Key zwei Slots hat, das hat man wie so AB-Buffering, kann man den einen Key aktualisieren, wenn wir gerade einen Handshake durchgeführt haben nach zwei Minuten mit Rowsenpass. Aber selbst wenn das nicht instantan passiert, bleibt der Tunnel erhalten. Das heißt, das permanente Durchtauschen von dem pre-shared Key verursacht nicht mal eine minimale Service-De-Schraption, bei der kurze Zeit Nachrichten nicht entschlüsselt werden können, sondern es geht einfach seamless durch. Wenn ihr vorhabt, ein Kryptografie- beinhaltendes Software-Tool zu bauen, die Idee, dass man von externen ein pre-shared Key substituten kann und man da einen AB-Buffering hat, ist eine sehr gute Idee. Das macht es sehr zugunstfähig. Genau, das ist sehr, sehr schön designt tatsächlich. Und das hat auch noch so Vorteile, wie das Wire-Guard im Kernel läuft. Und im Kernel möchte man ja nicht so einfach neue Software draufwerfen. Die vorherigen Versuche, Wire-Guard zu bauen, haben das gemacht. Die haben einfach in den Kernel fast Quantengryptografie reingeworfen und sich dann gedacht, es wird schon gehen. War eine coole Demonstration, war aber halt für einen akademischen Zwerg in der Praxis, möchte man das vielleicht eher so haben, dass dann der neu heiße Scheiß gut isoliert in einem Docker-Container oder in einer Micro-VM, woran wir vielleicht arbeiten werden. Läuft und besonders gesichert ist. Genau, das ist so ein bisschen schon die Zukunft. Das sehen wir dann gleich, nachdem wir noch ganz kurz in die Kryptografie geguckt haben, was da eigentlich drin ist. Rosenpass für Wire-Guard ist der Anfang. Da war es aus eben geschilderten Gründen das einfachste und das glaubwürdigste tatsächlich. Aber natürlich braucht auch die Cloud, braucht unsere ewig vorhandene E-Mail, brauchen Embedded Systems, brauchen Micro-VMs und so weiter. Unbedingt auch sowas. Dahin wird die Reise gehen. Genau. Kurz noch zu den Verwendeten Schifrern. Beide Leute uns immer wieder fragen. Rosenpass verwendet Classic-Macalies. Classic-Macalies ist ein Verfahren, das ... Ah, ich habe die Jahreszahl korrigiert. Ah, sehr gut. Danke für den Catch-Folgenvollen. Für den alten Mann, der das noch wusste, ja. Opa erzählt von alten kryptografischen Verfahren. Vom Krieg der Sterne. Genau, wir benutzen Classic-Macalies. Das wurde in den 70er Jahren, Ende der 70er Jahre schon erfunden. Wird seitdem kryptoanalysiert, steht. So, ist richtig gut abgehangen. Damit machen wir unsere Authentifizierung. Der Grund, warum Classic-Macalies nicht so benutzt wurde, ist, weil die Schlüsselgrößen riesig sind. Es gibt ja immer so diese drei Werte. Den Private Key, den Public Key und den Cypher Text. Private Key ist klein. Cypher Text ist auch super klein, super effizient. Und der Public Key ist so ein paar 100 Kilobyte bis megabyte groß. In der Praxis eher meist so vier MB. Ihr könnt überlegen, was das in früheren Netzwerken so gemacht hat und warum das keiner benutzt hat. Genau, das heißt, es war eine lange Zeit, da hat man gesagt, ja, das wäre gar nicht praktisch. Und dann haben Leute irgendwie absurd große, effiziente Computer mit viel Speicher entwickelt. Heutzutage ist das gar nicht so ein Problem. Und für uns ist es zufälligerweise auch genau das Richtige. Denn wir übertragen die statischen Public Keys gar nicht selber, sondern nur eine PRID, also die Identifikation des Piers. Das heißt, wir profitieren von den kleinen Private Keys und von den kleinen Cypher Texts, aber müssen diese großen Schlüssel nur einmal übertragen. Das heißt, unser Key Exchange passt tatsächlich in drei Pakete, die jeweils in UDP-V6-Frames reinpassen. Das heißt, es ist tatsächlich in der Praxis ziemlich effizient, obwohl wir klassisch Macalese verwenden. Und wir benutzen Kyber, das ist das mit den Lightsabern. Und das benutzen wir für die Ephemeral Secrecy, also für diese Forward Secrecy. Und das ist auch Sicherheit gegen Storn Now, Decrypt Later-Attacken. Manch Now, Decrypt Later, wie wir es vorhin genannt haben. Und das erfüllt auch so im Wesentlichen, was die Agencies gerade von Postquandtankriptografie wollen. Das heißt, wir haben auf der einen Seite die Sicherheit von dieser ganz sicheren, mehr Open Source von diesen alternativen Schiffen, und dann haben wir auf der anderen Seite die standardisierte Schiffe in genau dem, was sie standardz wollen. Wir holen uns das Beste aus allen Welten, aber wir arbeiten auch daran, weil uns immer mal wieder Leute anschreiben, ist das nicht doch ein Problem, dass die Schlüsse so groß sind? Also haben wir gesagt, ja, okay, bauen wir euch halt ein Kommandleinflag ein. Und das wird auch irgendwann kommen, dass man dann sagen kann, ja, in dem Protokam, dann ist das BSI vielleicht auch superglücklich. Muss man im Wesentlichen darauf aufpassen, dass man Leute nicht erlaubt, ihre Systeme zu verkonfigurieren. Es gibt so ein paar Postquandtankritten, in denen in den letzten Jahren gebrochen wurden und die möchte man dann nicht Leuten erlauben. Du meinst Krypto by Hirnschmalz? Krypto by Hirnschmalz? Also es gab da so Sachen wie C-Side, wo auf alle gehofft haben, und dann gab es so Menschen, die viel von Isogenien erklärt haben. Isogenien ist das Wort bei dem Kryptografenwerkrennen, weil sie nicht wissen, was es ist, außer eine Handvoll Menschen, die immer kommen, darf ich dir von Isogenien erzählen? Jedenfalls Isogenien, so wie sie da verwendet wurden, haben sich als nicht so gut gezeigt, waren lange Hoffnungsträger für Likes. Und es passiert schon ab und zu, dass da so auch Algorithmen brechen. Also, dass die nicht mehr sicher sind. Genau, und der Ausblick hier, noch ganz schnell, was wir in Zukunft planen. Rosenpass in Kubernetes wollen wir eventuell tun, einfach mal so zeigen, dass es geht. Leute versprüßen ja auch relativ wichtige Daten, so zwischen Kubernetes-Clustern. So wollen wir einfach einbauen. Isolation, Micro VMs und Docker, für die Leute, die wirklich Angst haben, unseren schlimmen Rustcode einzubauen. Für die machen wir dann das, die dürfen dann auch ihren Raspberry Pi nehmen, um unseren Code laufen zu lassen, und das in ihre WireGuard-Instanz reinschieben oder so. Und wir wollen Wissenschaftskommunikation machen, weil Leute Kryptografie nicht verstehen. Das heißt, wir arbeiten gerade daran, Leute Partner-Ideen zu finden, wie wir das Ganze gut vermitteln, wie wir das Ganze komplex herinnen. Moderne Anwendungsfälle von Kryptografie, nicht nur, ja, hier hast du dein Padlock, dein Vorhänge-Schloss, und dann kannst du asymetrisch verschlüsseln, sondern wir wollen vielleicht auch mal Multi-Party-Computation, ich erklär jetzt nicht, was das ist, aber Multi-Party-Computation wollen wir vielleicht auch mal erklären. Und wir wollen zusammenarbeiten mit high assurance Kryptografie-Projekten, einfach, um mal so ein Projekt zu haben, was als Demonstrator für ein paar von diesen Technologien dienen kann, weil das sind dann immer schöne Paper. Aber dann wird es versucht, in TLS einzubauen, und TLS ist doch schon ein ganz schöner Brocken. Und vielleicht ist es einfacher, erstmal Rosenpass zu als Demonstrator zu verwenden. Und wenn es gut genug ist, würden wir es auch tatsächlich in die downloadbare Binary einbauen. Ja. Genau, ich überspringe das. Genau, das gibt es zum Nachlesen. Genau, das ist, wie das Ganze in White Paper aussieht, wenn ihr es nachprogrammieren wollt. Dann hat Mulana wieder da so eine Grafik gebaut, die es einfach macht, und dann hat sie dann auch noch ein paar Zeilennummern, die schön durchnummeriert sind, dass sie das auch noch taggen können im Code. Das heißt, das ist schön. So könnt ihr vergleichen, was hier steht und was dann in der Implementierung steht, um die Protokollimplementierung auch zu verstehen. Sag Hallo. Genau. Grüß dich schön. Und? Ja. Wir hatten ja in der Demo schon gesehen, dass wir eine relativ große Anzahl an Worten haben, die man also hintereinander in so eine Shell eintippseln muss, die man in der Demo startet hat. Damit sind wir unglücklich. Also, zum einen ist es so, im Moment, wenn man einen neuen Peer hinzufügen möchte, zu einem existierenden Setup, dann würde man den Rosenpass-Prozess beenden und einen neuen Rosenpass-Prozess, der dann mehr als 23 Argumente hat, starten. Und dann hätte man noch einen Peer mehr. Ich glaube, es sind pro Peer 3-4 Argumente, also unter 30 immer noch für zwei Peers. Das andere ist, es ist durchaus denkbar, dass es nicht jeder überhaupt eine Kommando-Zeile benutzen möchte. Es wäre zum Beispiel vielleicht schön, wenn man ein grafisches User-Interface anbieten könnte. Jetzt ist es so, wir machen Dinge im Rahmen von High-Asurance-Krypto, die fragil sind. Wir haben zum Beispiel unseren eigenen Allocator für Secrets eingebaut, der basierend auf LibSodium-Malloc versucht, aus Versehen das Liegen von Secrets noch unwahrscheinlicher zu machen. Und sowas könnte kaputtgehen, wenn jemand einfach unseren Rosenpass-Bild linkt gegen seine Software. Und daher wollen wir irgendwie auch ein Interface, das am besten Rosenpass als eigenen Prozess laufen lassen kann, aber trotzdem zur Laufzeit ohne einen Neustart von dem Rosenpass-Prozess umkonfigurieren lässt. Dann haben wir drüber nachgedacht, wie könnte man das machen? Wir haben unsere Boxhandschuhe vergessen, aber wir sind Feinde, wir haben zwei verschiedene Ansätze. Ich sage, ich hätte gerne eine Konfigurationsdatei, irgendwas einfaches, vielleicht Tommel, wo man also reinschreiben kann, wenn man eine Konfigurationsdatei hat, oder ein Public Key von dem Pier und dann halt Private Key und Public Key-Pfile, also als Pfeilparf für den Server. Und K.O. hat eher die Vision, dass man da ein Unix-Domain-Socket benutzt, also dass man vielleicht dem Rosenpass-Server die Möglichkeit gibt, dass ein Controller mit dem sprechen kann und man ganz einfache Sprache vielleicht sagen kann, ich möchte einen Pier hinzufügen, ich möchte noch einen Pier hinzufügen, ich würde diesen Pier jetzt gerne kicken. Ich möchte einen Pferd von Mulwart im Raum, oder anderen VPR-Anbieter. Was wünscht ihr euch? Was meint ihr, was ist hier ein guter Lösungsansatz? Wie wollen wir die Anzahl der Kommandozeilen, Argumente in Rosenpass verringern? Hashtag shameless self-plug. Wir wollen, dass andere Leute Rosenpass einsetzen. Und die Frage an euch ist, wie würde die es gerne einbinden in andere externe Tools? Rauf runter, machen wir mal eine Umfrage. Ja, das ist eine gute Idee. Das lässt du wünschen, so intuitiv. Hinzufügen entfernen von PS ohne Neustart. Also CLI Improvement. Wer das gut findet, mach mal so. Das sind immerhin so ein paar. Okay, und Caro, sag mal, was du möchtest. Scheiße, darauf bin ich jetzt nicht vorbereitet. Rosenpaß konfigurieren per Unix Domains, das ist eine gute Idee. Wir brauchen noch Wissenschaftskommunikation, um das aus diesem schrecklichen Selbstversuch herauszuführen. Wenn wir so wenig Leute ihre Hand heben, dann brauchen wir noch Wissenschaftskommunikation. Wir haben übrigens so ein Chaos-Social-Account, also Rosenpaß. Das ist eine gute Idee. Wir brauchen noch Wissenschaftskommunikation. Wir brauchen noch Wissenschaftskommunikation. Das ist ein Chaos-Social-Account, also Rosenpaß. Lasst uns wissen. Und lasst die anderen wissen, worüber wir hier so diskutieren. Wie kann ich ködern, wenn wir sagen, wir haben einfach einen Daumen, der kriegt einen Konfigurierter als Argument übergeben. Der Konfigurierter den Daumen findet das gut. Ich glaube, das war es. Wir haben nur noch dieses Slide, vielleicht finde ich eine, die gut zum Anschauen ist. Den Hasen, ich finde den gut. Wir sind auf dem Easter-Hack. Ich glaube, ich lasse das. Das ist inhaltlich. Vielen Dank, dass du so lange durchgehalten habt. Ich weiß gar nicht, ob jetzt noch was kommt. Du hast noch gesagt, wie wir auf den Namen kommen. Richtig, ich soll noch sagen, wie wir auf den Namen Rosenpaß kommen. Also, habe ich getiesert. Das ist eine lange Geschichte. Ja, ich zahle es eines Tages so da und habe im Internet gebraust. Was machen Leute für Post-Quanten-Kryptografie-Dinge? Und habe mir dann so diverse Anbieter angeschaut und gesagt, ich werde das jetzt. Die Fans-Shield. Star Wars. Star Wars, Martial-Military-Thing. Defend yourself now. Mir geht das ganz schön auf den Geist. Ich dachte, was kann nicht nehmen, dass Maximal-Girlie klingt? Genau. Denn, wie wir wissen, ich mache mir mehr die Kommunikation. Mit der Entwicklung lassen wir die Frauen machen. Der Code wird eh besser, wissen Sie ja. Ich wollte auch aktiv dafür sorgen, dass nur Leute, die sich trauen, Pink zu tragen, Dinge mit Rosenpaß machen können. Und wenn ihr auch so fancy Merch haben will, den gibt es hier bei Linda in Hamburg bei Bremenbüdel. Genau wo es den anderen Merch gibt. Wir haben eine Frage. Ich habe mich interessiert, was für eine Organitätsform seid ihr? Wir sind ein unglaublich fossiges Foss-Projekt. Wir lassen uns Geld über den Zaun werfen und schreiben dafür Code. Sogar unser Logo ist CC-Buy. Wenn ihr ein Porn-Shop mit Hasen aufmachen wollt, bitte aber vergesst nicht die Quelle. Ich habe eine andere Antwort. Unsere Rechtsform ist ephemeral. Um die Antwort ernsthaft zu geben, bisher ist das nicht so eine Rechtsform. Wir haben so ein Projekt gearbeitet. Wir wirklich doch dahin. Da gibt es Funding. Dann habe ich Text geschrieben. Dann sind Leute dazu gekommen. Das ist so cool, wie es ist. Das macht uns zu einem Verein in der Gründung. Wir verfolgen einen gemeinsamen wirtschaftlichen Zweck. Das Ziel ist, was erwachsen zu lassen, was benutzt werden kann, um mehr Science-Communication zu machen. Ein eigenes Forschungsding. Das ist das, was nebenbei hier ist. Wir haben noch eine Frage. Ich habe eine Wiskom-Frage. Vielleicht führt es zu weit hier. Warum kann man mit dem Shore-Algorithmus einen Nike angreifen und einen Chem nicht? An welcher Stelle setzt der Shore-Algorithmus bei dem Nike an, was er beim Chem nicht kann? Ich sollte zurückgehen. Ich habe noch eine Frage. Es ist eine Chem. Nein, es ist nicht. Es ist quasi eine Chem. Nike, Diffie-Helmen und ECDH. Diffie-Helmen sind jeweils Nikes. Es gibt sowohl Nikes als auch Camps, die gebrochen wurden. Die Frage ist nicht, ob Postquadren-Griptografien Nikes oder Camps angreifen können, sondern die Frage ist, welche mathematischen Probleme löstbar sind mit Quantencomputern? Nun ergibt es sich so, dass niemand gut funktionierende Nikes gefunden hat im Post-Quantum-Setting. Es gab Versuche, es wird aktiv dran geforscht. Leute, die das schaffen, werden hart bejubelt werden, aber es hat niemand geschafft. Es gibt keinen fundamentalen Grund. Wir haben eine gute Frage. Das ist das erste Problem. Der Instanzen des hidden subgroup Problems. Da gibt es eine Klasse von Problemen, die es lösen kann. Da fallen zufällig Dieter drunter. Lettes oder Kurt-basierte Verfahren. Wie will sie einwenden? Weitere Hand, da gibt es eine lange Schlange am Mikro. Ich wollte fragen, ob man das aus dem Sport angreift, oder ist das weiter nicht möglich? Da haben wir eine gute Mitigation. Es ist aufgefallen, dass Rosenpass abstürzt, wenn man es mit N-Web anfingert. Das war eine Mitigation, aber wir haben uns dagegen entschlossen. Das macht andere Feste auf. Wenn ich spontan meinen Kryptoanalysebrain anwerfe, ich habe mir das noch nicht so genau überlegt. Ich denke, wenn man den Publiki desgegenübers kennt und dann ein Paket hinschickt, bekommt man eine Antwort, an der man detektieren könnte, dass da Rosenpass läuft. Wenn man den Publiki desgegenübers noch nicht kennt, sollte da nichts rausfallen, wo man detektieren kann, dass das Rosenpass ist. Das war jetzt aber nicht primär ein Ziel. Da laufen jetzt genau Pakete mit 1100 something bytes drüber. Die werden wahrscheinlich schon sich denken, das ist wahrscheinlich Rosenpass, wenn das mehrere Leute einsetzen. Es ist relativ Starfy. Ich glaube, wenn eine N-Web-Detection zu bauen, wäre gar nicht so einfach. Wie sieht das auf Klientseite aus? Es gibt Piers. Die können sich gegenseitig Nachrichten schicken. Der, der die erste Nachricht schickt, den nennen wir initiator, den anderen den responder. Wenn beide Piers aber eine Soccer-Adress zum anderen kennen, also ein Doppelport und eine IPv4 oder IPv6, dann ist es quasi Zufall, welcher als erstes die initiator Message schickt. Es gibt keine kleinen Server-Rolle, es gibt Piers und eine andere Nachricht, der initiator, der andere der responder. Guten Abend, ich habe eine technische Frage. Da Rosenpass ein Top-Layer ist über WireGuard, ich würde da erst ein Penalty geben in Millisekunden. Wir müssen uns beeilen. Oder gibt es da Limitierung an die Bandbreite? Die Bandbreite ist mal, da es ein Top-Layer ist. Die zweite Frage ist, wäre es kompatibel? Ich glaube, die zweite Frage können wir gleich online noch klären. Wir treffen uns sicher gleich hier, dann gehen wir vielleicht an die Bar und gehen. Wir machen jetzt das, was Fossbrücher gerne wollen. Wir dürfen uns alle in der Marte kaufen. Wir werden ansonsten hier rausgefegt. Vielen Dank, dass ihr durchgehalten habt. Ich habe die erste Frage verstanden. Wie viele Bandbreite das braucht? Pro-Cakes-Change? Es ist nicht so, wie groß die Pakete sind. Ungefähr 8 Millisekunden braucht das Ganze. Bis gleich an der Bar. Wer noch hasen möchte, hier sind welche. Das ganze Team sitzt hier.