 Gleich sehen Sie den Vortrag Cutting the onion, the top protocol von Emil Engler. Emil hat sich schon seit seiner Jugend für dezentrale Netze interessiert und setzt sich seitdem für zensurfreies Internet ein. Außerdem fährt er gerne Fahrrad, liest gerne und, was mich sehr erstaunt hat, er ist Imker und hat eigene Bienen, stimmt das? Ja genau und du sagst, wenn du soweit bist? Ja, mach ich. Außerdem interessiert er sich sehr für freie und offene Software und wir freuen uns alle gleich auf seinen Vortrag. Genau. So, habser Bild. Perfekt, alles richtig soweit? Ja, alles richtig soweit. Bei mir steckt der Kabel eigentlich drin. Dann begrüßen wir ganz herzlich Emil Engler und viel Spaß. Danke, danke, aber ich hab da noch gar nichts gemacht. Gut, ein Bild wäre jetzt ganz schön, bekommt ihr da was rein? Dann haben wir hier noch mal auf unserer technischen Seite kleine Schwierigkeiten. Wir bitten ganz kurz um Geduld. Machen Sie sich schon mal bequem und holen Sie Popcorn raus. Alternativ, Let's Dennis ist... Let's Dennis ist es nur ein PDF, das ich durchklicken muss. Das könnt ihr euch herunterladen, das ist im Internet verfügbar. Wer ist denn das erste Mal heute hier auf der GPM? Einmal melken. Oh ja, ganz schön viele Hände oben. Dann viel Spaß, wie lange seid ihr hier? Ich hoffe alle vier Tage. Danke, probiere ich den mal. Wo kommt ihr jetzt was? Hast du das PDF offen? Ich werde gerade gerettet. Ich hatte auf jeden Fall auch mal später beim Gulasch oder bei der Bar oder beim Flammkuchen vorbei. Danke. Den Flammkuchen durfte ich eben auch schon probieren, ganz lecker. Genau. Ja, das geht schon deutlich besser. 10 Sekunden. Können ja schon mal ein Countdown starten. Oh, das ist darauf nachher schon. Danke. Das noch in den Slides Modus? Ja, kommt sofort. Jetzt machen wir mal so auf. Ah, damit okay. Ah, okay. Deswegen heißt das ganze Chaos Computer Club. Noch mal die Fokus auf was andere, damit ich durch ... Ja. Der Fokus ist? Ja, geht. Okay. Ja. Vielen Dank, dass ihr alle so zahlreich erschienen seid und vielen Dank, dass ihr mir die Startschwierigkeiten ein bisschen verzeiht. Ich bin Emil und ich werde heute ein bisschen über Tor reden. Genau. Erst ein paar Dinge zu mir. Mein Name ist Emil Engler. Ich bin mit allen Pronomen zufrieden. Ich hab jetzt dieses Jahr mein Abitur gemacht und ich werde ab Oktober hier in Karlsruhe am KIT Mathe studieren und ich suche aktuell noch eine Wohnung und falls da vielleicht Leute kennt in irgendwelchen Ständenwohnheimen, dann, ja, da wäre ich euch mal ganz genedig, wenn ihr mir da vielleicht ein bisschen was ermitteln könntet, denn eine Wohnung ist ganz sinnvoll. Ja, ich mach seit meiner Jugend, bin ich ein Konsributor zu vielen Open Source Projekten. Ich hab in den letzten Jahren viel für Köl gemacht, ein bisschen jetzt bin ich bei Rosenpass drin. An Tor hab ich auch schon ein paar Patches geschickt, weshalb ich auch diesen Vortrag halte. Aber ich bin jetzt nicht irgendwie offiziell mit Tor affiliert, ich bin dann nur so ein Konsributor, der hier und da mal ein Patchen schickt, ein bisschen in Maia Sirum lungert und so weiter. Und ich bin ein Sturkopf, der der Meinung ist, dass Kugelfische besser als Bingwene sind. Ja, genau, das ist das erste Mal, dass ich diesen Vortrag jetzt halte. Ich hoffe, dass werde ich schon irgendwie hinkriegen, aber viele sollte sagen mir manchmal, dass mein Kopf auf 120 FPS ist, aber meine Stimme irgendwie nur auf 30 und ich im Kopf manchmal fünf Schritte weiter bin. Also falls es irgendwelche Fragen gibt, meldet euch einfach. Und dann können wir das mit Sicherheit klären. Ja genau, dann erst mal zur ersten Frage. Wer von euch hat denn schon mal ein Torbrowser benutzt? Nehmt ruhig die Hände hoch, wir sind ja nicht in Karlsruhe, wir sind auch nicht direkt neben der Generalbundesanwaltschaft. Wie? Sind wir doch? Ja, okay, das, ja, gut, gibt es ja auch Leute, die vielleicht ein bisschen mehr mit Tor machen, so ein Relay betreiben oder sowas in der Richtung. Gibt es ja dann auch Leute, die sich doch schon sehr gut mit Tor auskennen und wissen, was da wirklich abgeht in einem Netzwerkprotokoll? Ah, gut, dann gibt es hier keine Klugscheiße, das ist schon mal von Vorteil. Normalerweise ist das nämlich immer meine Aufgabe, aber jetzt spreche ich mal. Ja, genau, und um Tor erst mal zu verstehen, müssen wir eine Technologie verstehen, die sich Onion Routing nennt. Vermutlich haben schon mal viele das gehört, vielen ist das ein Begriff. Onion Routing ist an sich ein Konzept, das in den 90ern, also noch vor Tour, Tour gibt es nämlich erst in den Frühjahr 2000 dann, von Paul Tsaiwassen im Auftrag der Navy entwickelt wurde und im Prinzip ist das eine Technologie, welche folgende Ziele verfolgt. Alice's IP muss gegenüber Bob geheim bleiben, der darf dir auf gar keinen Fall wissen. Bob's IP darf öffentlich sein, sie kann auch unter Umständen privat sein, Onion Routing erlaubt das, aber sie muss es nicht. Sie muss sich dann als Hinservice, das vielleicht kennt, diese coolen Punkt-Onion-Adressen dann und der Traffic muss beziehungsweise sollte so gut wie möglich verschüsselt sein, dass es im Prinzip die Ziele, die Onion Routing lösen möchte. Bevor es Onion Routing gab, gab es schon einige andere Ansätze, die wir uns jetzt einmal anschauen werden. Der erste ist der klassische gute Proxy. Man hat einen VPN-Server in der Mitte, eine VPN kann auch irgendein anderer Proxy sein, der im Prinzip Alice-Traffic nimmt und mit seiner IP mit Bob kommuniziert. An sich hat schon einige Vorteile, also einige Ziele werden erfüllt, nämlich Alice's IP ist gegenüber Bob geheim, aber der Traffic ist nicht so ganz verschlüsselt, das ist insbesondere blöd, ja genau. Das ist natürlich insbesondere blöd, wenn der Proxy auf einmal böse ist, weil dann kann er nicht nur den ganzen Traffic mitlesen, sondern erkennt auch Alice's IP und damit ist das Ziel oder die Ziele, die wir vorhin formuliert haben, verfehlt und es gibt ein Single-Point-of-Failer, wenn man das eine Ding kontrolliert, hat man schon ziemlich viel macht und das ist nicht so sonderlich schön, wenn es gerade um eine anonyme Kommunikation geht. Genau, der Proxy weiß ja darauf, dass er Alice kennt, er Bob kennt und sämtliche Daten kennt. Peng, nicht sonderlich, sicher nicht sonderlich anonym. Viele Leute haben auf die, insbesondere letzten Jahren sind da viele Bullshit-Anbieter aufgekommen, die gerne so was verstrichen wie absolute Privatsphäre mit NordVPN oder sonstigen anderen Bullshit-Anbieter anbieten. Problem ist, man vertraut seinen Daten dann einfach nur jemand anderen an, anstatt dass sie wirklich anonym sind und vertrauen es gut, aber Kontrolle ist letztendlich noch besser, weshalb dieses Modell nicht wirklich effizient ist. Dann gibt es auch noch einen anderen Ansatz, den man sich überlegt hat dazu, dass man einfach ja eine Art Multi-Hop-Routing macht, also anstatt dass man es durch einen einzigen Proxy sendet, so wie vorher, setzt man einfach mehrere dazwischen, so dass die sich untereinander auch, dann kennt nämlich nur der hier, die IP von Alice, der kennt nur die IP von Bob und der hier weiß, dass irgendwer mit irgendwerem redet. Das hat den Vorteil, wenn der erste Hop auf einmal böse ist, dann weiß der Hop halt nur, OK, Alice redet mit irgendjemandem, aber ich weiß nicht, mit wem sie redet. Ist der mittlere Hopbböse? OK, irgendwer redet mit irgendwem und ist der letzte Hopbböse? OK, Bob redet mit irgendwem, aber ich weiß nicht mit wem. Das Problem ist, wie man hier unten sieht, das Ganze ist noch ziemlich ohne Kryptografie. Gut, man könnte natürlich sowas verwenden wie TLS, aber es können auch alle mitlesen und gerade wenn man den erst so die letzten kontrolliert, peng. Natürlich werden auch einige Ziele erfüllt, die wir vorher gesetzt haben. Bob kennt Alice das IP nicht. Ja, niemand weiß, dass Alice mit Bob kommuniziert. Ja, stimmt auch, aber die Daten sind immer noch unverschlüsselt und das ist nicht so ganz schön. Can we do any better? Yes, we can. Irgendwann kamen dann die Leute und haben sich etwas ausgedacht namens Onion Routing. Onion Routing basiert darauf, dass es eine Netzwerk von Routern gibt, ein Netzwerk von Proxys. Und jeder einzelne Proxy hat Publikis. Diese Publikis sind allen Teilnehmern bekannt. Die sind öffentlich. Und mit diesen Publikis kann dann eben eine gewisse Kryptografie aufgebaut werden, sodass die Daten auch noch verschlüsselt sind und man ein bisschen plausible deniability etc. pp hat. Im Prinzip funktioniert das dann wie folgt. Alice sucht sich ein Fahrt aus drei oder mehreren Hops aus und mit diesen Publikis daraus derived sie also leitet her symmetrische Schlüsse. Das klingt jetzt vielleicht mal okay, wie passiert das? Da gibt es auch Verfahren für das bekannteste, das Diffy-Helmen-Verfahren, sodass es dann, sodass dann jedes Hopp auf dem FAT Path einen eigenen Symmetric Key hat, den es nur mit Alice teilt. Hier habe ich das jetzt K1, K2, K3 genannt. Und dann können die Daten schon irgendwie verschlüsselt werden. Aber wie werden sie denn nun verschlüsselt? Ich meine, warum heißt es Onion Routing? Das sieht noch nicht so zwiebelig aus. Das kommt jetzt nämlich. Wenn Alice eine Nachricht versendet, dann nimmt sie diese Nachricht, diesen Plain Text und verschlüsselt ihn symmetrisch mit dem Key vom letzten Hopp. Der Cypher-Text, der dabei rauskommt, wird noch einmal verschlüsselt mit dem Key von dem zweiten Hopp. Und dieser zweite Cypher-Text, der dann wieder rausgekommen ist, wird noch einmal verschlüsselt mit dem Key von dem ersten Hopp, sodass dann eine dreischichtige, deshalb diese Zwiebelmetapher, weil die Zwiebel hat Schichten, entstehen. Alice schickt dann diese Nachricht an das erste Hopp. Das erste Hopp entschlüsselt die Nachricht mit dem Key, den es hat. Und dann überlegt es sich, okay, kann ich mit der Nachricht was anfangen? Oder ist das immer noch Cypher-Text, Garbage? Ich kann mich nicht verstehen. In dem letzten Fall wird dann die Nachricht einfach weitergeleitet. Okay, ich verstehe es nicht. Ich schick's weiter, vielleicht kann der mehr damit anfangen. Dann geht es an den zweiten Hopp und der zweite Hopp macht genau dasselbe. Er entschlüsselt es mit dem Key, den er hat. Schaut, okay, kann ich damit was anfangen? Nee, ist immer noch verschlüsselt, schick ich weiter an dritten Hopp. Der dritte Hopp nimmt sich das, entschlüsselt es wieder und entscheidet dann, kann ich damit was anfangen? Ja, kann ich! Keine Verschlüsselung mehr. Und die Nachricht geht zu Bob. Wenn's zurückgeht, ist das logischerweise genau umgekehrt. K3, also das letzte Hopp bekommt eine Antwort von Bob und verschlüsselt diese Plaintext-Antwort mit seinem eigenen Key, mit K3. Dann wird es weiter zurückgeschickt an K2. K2 verschlüsselt diesen Cypher-Text noch mal, wird dann wieder weiter geschickt an K1 und K1 verschlüsselt es dann wieder noch einmal, so dass es damit Alice ankommt und Alice. Und ausschließlich Alice ist die einzige Person, die alle drei Schlüssel hat, um es vollständig zu entschlüsseln. Und genau das macht sie auch. Erste Layer entfernt, dann wieder Cypher-Text, noch mal entfernt, wieder Cypher-Text, wieder entfernt. Oh, die Nachricht ist angekommen. Das ist im Prinzip die ganze Magie hinter dem Onion-Routing. Und diese Technologie macht sich Torzunutze, um dann ein anonymes Traffic zu erlauben. Aber dazu kommen wir dann gleich noch mal an. Gibt's bis hierhin irgendwelche Fragen? Ja, da in der Mitte. Ja, dazu komme ich, wenn wir im Tor-Protokoll sind, noch mal. Im Prinzip war es jetzt darauf, dass das Hopp inkrementell erweitert wird. Sprich, es wird erst mal eine Verbindung zum ersten aufgebaut. Und dann wird dem ersten mitgeteilt von Alice. Okay, bau jetzt bitte eine Verbindung mit dem zweiten auf. Genauso basiert das. Und dann wird es eben nicht mit K3 verschlüsselt, sondern nur mit K1. Und dann weiß ich, ich kann mit der Nachricht was anfangen. Ja, dahinten? Ja, das stimmt. Aber er kann es sich zuordnen. Und das ist der Grund, dass man immer, wenn man ein Tor verwendet, immer sowas wie TLS verwenden sollte. An sich kann der letzte Hopp alles mitlesen. Das ist ein bisschen blöd. Ja, genau, TLS, genau. Dafür muss man erst mal die Grundsagen verstanden haben. Aber das fällt leichter in der Vortrag vorbei. Also hoffe ich mal. Genau, Tor ist erst mal so eine Software, den vielen ein Begriff ist. Aber kann niemand hier sagen, was jetzt der genaue Anwendungszweck von Tor ist. So die Definition, der erste Satz ins Speck. Das Problem, das Tor versucht zu lösen oder Tor versucht im Prinzip die Anonymisierung von TCP-Traffic möglich zu machen. Das ist im Prinzip das, was Tor versucht. UDP geht noch nicht über Tor. Das will man jetzt mal angehen, dieses Problem nach über 20 Jahren. Aber aktuell nur um TCP-Anwendungen. Ja, anonymer zu machen. Genau. Die allgemeinen Infos dazu, wie ich gerade eben schon erzählt hat, ist ein verteiltes Netzwerk zur Anonymisierung von TCP-Traffic. Die Kleins wählen ein Fahrt an Notes aus und bauen daraus ein Circuit. Und die Kommunikation findet in festen Paketen den sogenannten Cells statt. Jetzt wird es hier etwas Netzwerk theoretisch. Also wir schauen uns die Paketformat an, das Tor verwendet zur Kommunikation. Genau. Aber zuerst müssen wir bedenken, welche Keys hat so ein Tor-Note überhaupt? Ich habe jetzt ein bisschen kurz da oben erklärt, als sich das On-and-Routing-Konzept erklärt hat. Jo, es werden Public Keys erwendet, aber ich habe hier noch gar nicht über die Algorithmen geredet, die überhaupt verwendet werden. Also jedes Note hat mehrere öffentliche Keys. Dazu gibt es einmal ein RS-A1024. Ja, RS-A1024, ich weiß. Und ein ED2519 Identity-Key. Diese beiden Keys identifizieren das Note eindeutig. Warum habe ich jetzt gefragt, warum ist der RS-A1024 drin? Das hat einen ganz einfachen Grund. Bis ungefähr 2012 lief in Tor alles über RS-A1024. Und die haben das dann allmählich auf elliptik-Körfung gestellt. Und das ist sozusagen das einzige Relikt, das noch übrig geblieben ist. Genau. Zu den Keys gehören dann auch noch ein ED2519 Signing und ein ED2519 Authentication-Key. Wir kommen auf die dann nochmal zurück. Im Prinzip kann man sich merken, der ED2519 Signing-Key wird von dem Identity-Key signiert für eine gewisse Periode in einem Certificat. Der Sinn dahinter liegt darin, dass man diese beiden Keys, die halt das Note identifizieren, offline speichern kann, dass die kalt sind. Der Authentication-Key wird in den Connections Handshakes verwendet, auf die kommen wir gleich zu sprechen. Und da gibt es noch ein Curve 2519 Handshake-Key. Der wird für die Circuit-Handshakes verwendet, auf die wir dann danach zu sprechen kommen. Genau. Und ganz wichtig ist jeder kennt die Public Keys von jedem. Diese Annahme, auf der Basit on en Routing, jeder kennt die Keys von jedem. Wie zustande kommen, wie die verbreitet werden, woher diese magische Liste kommt, ist leider ein Thema für ein anderes Mal. Für die, die interessiert sind, die können mal nachlesen, das sind sich das Tour Directory Protokoll. Genau, diese Liste ist auf jeden Fall sehr wichtig und definitiv nicht unwichtig, weil sie halt eben fest, wenn man die kontrolliert, kann man sich natürlich alle Notes auswählen, die einem gehören. Das ist ein großer Punkt auf Failure, aber um den geht es heute leider nicht. Wir nehmen einfach an, dass diese Liste von Gott gegeben ist, von der Bundesregierung gegeben ist und schon alles gut sein wird. Wir können ja mal nebenan nachfragen, vielleicht könnt ihr es ja. Ja, ich habe gerade schon erklärt, dass das fundamentale Paket, in dem alle in der gesamte Traffic durchgeht, das ist eine genannte Cell. Das ist eine 514-byte-lange Nachricht und diese Nachricht hat folgende Felder. Eine Circuit ID, die ist 4-byte lang, ein Kommand, der ist 1-byte und ein Payload, der ist 509-byte. Die Circuit ID identifiziert das Circuit, darauf können wir gleich nochmal zu sprechen. Der Kommand gibt an, was der semantische Inhalt dieses Payloads eigentlich bedeutet und der Payload enthalten eben die Daten, die sie im Kommand gehören. Es gibt keine Verschlüsse, noch kein Onion-Routing in diesem Sinne statt, weil eine Connection-Enttour immer nur eine Verbindung zwischen einem Klein- oder einem Server ist. Aber darauf, das kommt jede Sekunde. Genau, hier haben wir noch mal eine Visualisierung von dieser Cell. Genau, die Circuit ID identifiziert das Circuit und das Circuit ID 0 bezieht sich auf die gesamte Connection. Das ist ein Wert, der eine semantisch besondere Bedeutung hat, sozusagen reservierter Wert. Wir werden uns heute diese ganzen Kommands ansehen. Die List ist definitiv nicht vollständig. Es gibt einige mehr. Aber wir werden uns heute nur diese anschauen. Genau, ich habe jetzt schon viel von der Connection geredet. Aber was ist diese Connection überhaupt? Eine Connection-Tour-Protokoll, wird auch öfter mal Channel genannt, ist im Prinzip einfach nur eine stumpfe TLS-Verbindung zwischen einem Klein- und einem Node, beziehungsweise zwischen einem Node und einem Node. Sie verwenden im Prinzip fast das selbe Protokoll, also ein Klein mit Node redet im Prinzip fast das selbe Protokoll wie ein Node mit einem Node. Am Anfang findet immer ein Handshake statt und jede Connection besteht immer aus mehreren Circuits. Genau, wenn so eine Connection entsteht, dann muss natürlich immer irgendeine Art Handshake stattfinden. Ich habe gerade schon irgendwie gesagt, es geht jetzt nicht mehr in TLS-Handshake, die TLS-Verbindung wurde schon erfolgreich hergestellt, es wurde gehandshaked. Was passiert dann? Genau, der Client sendet als allererstes eine Version-Zell. Danach kommen ein paar andere Cells zurück und danach kommt eine nette Info-Zell weil es auch noch mal zurückgeschickt. Ich gehe jetzt auf die Cells-Einzellen ein und dann werden wir am Ende schauen, dass wir mal mehr an, dann macht es mehr Sinn. Nur damit ihr wisst, was hier schon mal langgeschickt wird. Genau, die Version-Zell, man kann sich vielleicht schon denken, welche Version diese Implementierung von Tour unterstützt. Das Tour Protokoll gibt es aktuell in fünf Versionen. Die haben alle mal einige Kleinigkeiten geändert, zum Beispiel bei Version 3 kam ein neuer Handshake, bei Version 4 wurde die Länge vom Circuit ID verlängert und so weiter. Die aktuelle Tour Implementierung unterstützten nur die neuesten 3 Versionen, also 1 und 2 sind schon längst Legacy, die werden schon lange nicht mehr verwendet. Der Payload enthält ein Lister an 2 Byte Integern und wenn da zum Beispiel Version 3 drinsteht, heißt das Version 3. Wenn da eine 4 drinsteht, eine Version 4 und so weiter. Die Third Cell ist dann schon ein bisschen interessanter. Die Third Cell enthält im Prinzip alle Public Keys, die diese Instanz behauptet, von sich zu besitzen. Die Public Keys sind dann in entsprechenden Zertifikaten kodiert, welche einen Ablaufdatum noch enthalten, noch schön selbst signiert sind und zu beweisen, ja, ich habe den Public Key, den ich behaupte wirklich, der Gold wirklich mir. Genau, diese Cell hat im Prinzip beginnt mit einer Nummer an Zertifikaten, die da drin sind und danach folgt einmal diese Datenstruktur einmal der Zertifikat Typ, enthält das jetzt ein ED25519 Identity Key, ein ED25519 Authentication Key, enthält es den RSA 1024 Key, dann einmal die Länge des Zertifikats und dann das entsprechende Zertifikat logischerweise. Dann gibt es noch die Orth Challenge Cell, die mag vielleicht etwas unintuitiv am Anfang klingen, aber die hat schon ihren Sinn. Die Orth Challenge Cell enthält im Prinzip erstmal eine Liste an Challenges, das ist, enthält erstmal am Anfang eine Challenge, das ist in dem Sinne einfach nur ein Random String, ganz einfach deshalb damit man Replay-Attacken verhindern kann. Eine Replay-Attacke ist, wenn Daten designiert werden, die kryptografisch designiert werden, indem man sie einfach normal sendet, sprich wenn Angreifer die abfängt, kann er sie einfach normal abspielen, Replayen und theoretisch dann sagen, ja, ich hab ja die Signaturen, jetzt ist die alle gültig. Kann man damit natürlich verschwören, wenn man in jede einzelne Connection noch ein bisschen Zufall mitreindringt. Im Ende sind noch 4 Byte on Magic Data und sagen schon zugutell jetzt auch die Net Info Cell, die sieht komplizierter aus, als sie in Wahrheit ist. Im Prinzip enthält sie nur ein Timestamp, die aktuelle Systemzeit, ja, 4 Byte, ja, wir werden 2038 ein Problem haben und dann 2 IPs, nämlich die IP von dem Gegenüber und die IP, die die man selbst hat. Das sind einfach darüber um gewissen, um jedenfalls Men in the Middle Attacks zu kontern, indem beide nochmal sich gegenseitig mitteilen, was verwende ich eigentlich gerade genau, mit wem sprich ich genau. Ja, und dann können wir uns das nochmal anschauen, ich habe das am Anfang schon kurz gezeigt, die Grafik, war da vielleicht mehr verwirrend. Hier machst du noch mal mehr Sinn und hier will ich noch ein bisschen besser darauf eingehen. Der Client, beziehungsweise der Initiator sendet zuerst eine Version-Zelle und sagt an Jo, welche Version, das ist die Version, die ich habe, gib mir darauf etwas zurück, wenn du die Version verstehst. Zurück kommen dann auch eine Version-Zelle und dem gesagt wird Jo, ich unterstützt die Version, dann gibt dem Note die Zertifikate, die es selbst von sich behauptet zu haben, mit entsprechenden Signaturen noch ein bisschen Zufall hier und zum Schluss eine net Info-Cell, in dem nochmal geklärt wird Jo, ich kommuniziere mit dem, mit dem ich kommunizieren möchte und die wird auch nochmal zurückgegeben. Genau, wenn ein Note mit einem anderen Note spricht, ist das wieder ein klein bisschen anders, sehr ähnlich, aber ein klein bisschen anders. Der Anfang ist identisch wieder eine Version-Zelle vom Initiator, dann wieder dieser Block an den 4-Cells von Responder. Der einzige Unterschied ist jetzt, dass statt dieser einen net Info-Cell auch noch zwei andere Cells zurückkommen, nämlich eine Zert-Cell und eine Authenticate-Cell. Eine Zert-Cell deshalb, weil wenn ein Note mit einem anderen Note spricht, haben ja beide Public Keys, aber wenn ein Klein nur mit einem Note spricht, dann hat der Klein ja keine Public Keys in dem Sinne. Genau, und die Authenticate-Cell, die authentifiziert das, die enthält im Prinzip ein kleines Rätsel, das gelöst werden muss und die Identifizierung auch wirklich durchführen zu können. Auf die kommen wir jetzt zu sprechen. Das sind die Daten, die diese Authenticate-Cell enthält. Ihr müsst euch das jetzt hier nicht alles merken, ich werde nur kurz ein bisschen auf die Felder eingehen. In dieser Cell sind nämlich erstmal ein paar Magic Bytes, dann der Initiator-RSA-Key, der Responder-RSA-Key, dann auch der ED25519 Identity-Key, der Responder-ED25519 Identity-Key und vieles mehr. Das sind die Daten über TLS-Meter-Daten. Was ganz interessant ist, ist auch der Schad 2-Hash von allen Daten drin, die vom Responder an den Klein gegangen sind und es ist auch der Schad 2-Hash drin von allen Daten, die vom Initiator zum Responder gegangen sind. Das heißt, alle Daten, die bisher hingeflossen werden, sind da auch mit drin im Hash. Noch ein bisschen Zufallsdaten und am Ende wird das alles mit dem ED25519 Identity-Key signiert mit dem ED25519 so ein Authentication-Key, das der einzige Zweck, den er damit hat und damit wird praktisch validiert, diese Person hat wirklich diese Keys, die sie behauptet zu haben. Hier haben wir es nochmal, das ist im Prinzip, das heißt, die Authentication enthält all diese Daten auch noch praktisch, wodurch wirklich Sichergang wird, diese Person hat die Keys, die sie behauptet zu haben, das ist gut, das kann man auch kommunizieren. Gibt es für der Connection bisher Fragen? Da hinten sehe ich was? Ja, das liegt daran, ursprünglich war die Circuit-ID längst, die ist ja 4-byte. Ursprünglich war das 2-byte lang und da hatte man natürlich 512. Aber das Tonnetzwerk ist ein bisschen gewachsen und man hat es dann auch 4-byte erhöht und deshalb ist halt so was schön unelegantes rausgekommen mit 514. Ja, man hätte damals ein bisschen mehr nachdenken können, aber ja, Skalierung ist ein Thema für sich. Genau, da kommen wir jetzt auch schon auf das Circuit zu sprechen. Ich habe das schon ein bisschen öfter erwähnt. Das Circuit ist dann der tatsächliche Fahrt auf dem Tonnetzwerk. Der tatsächliche Fahrt besteht aus den 3 Notes. Ein Tor Klein hat in der Regel mehrere Circuits offen, gleichzeitig, das ist jetzt keine teure Ressource und sie sind immer einer Connection zugewiesen. Eine Connection ist, wie bereits gesagt, schon nur so eine stumpfe Verbindung und der ist jedes Circuit eben zugewiesen. Sie werden inkrementell mit Handshakes aufgebaut. Das war ja schon die Frage, die ganz vorne kam, wie das zweite Note weiß, was schon das dritte Note ist. Das weiß es am Anfang natürlich nicht, es wird erst mit dem ersten Note verbunden, da wird mit dem zweiten Note verbunden und abschließend mit dem dritten Note und das wird alles step-by-step aufgebaut. Das wird dann wieder zuschnitten oder wieder andere gebaut werden, aber darauf kommen wir später bzw. gar nicht ein. Ich muss an dieser Stelle vorwarnen, es wird, wenn wir um die Circuit Extensions wie die Circuits erweitert werden, weil wir darauf eingehen, wird es zu einem kleinen Hennerei-Problem kommen, aber ich hoffe, das können wir gut lösen. Bei Fragen, wie bereits gesagt, einfach nur Bescheid sagen. Ein Circuit Handshake bzw. wie so ein Circuit aufgebaut wird, und wir denken, ein Circuit kann erstellt werden und ein Circuit kann erweitert werden. Das sind zwei Unterschiede. Wir behandeln hier erst mal die Circuit-Erstellung. Das ist im Prinzip, wie das Circuit mit dem ersten Note, mit dem ersten Hopp erstellt wird. Dazu muss erst mal eine Connection zwischen dem Client und dem Note logischerweise herrschen. Also wir setzen jetzt schon mal voraus, es gab mir erfolgreich ein Connection Handshake, das, was wir vorhin gesehen haben, war alles erfolgreich und gut. Und dann denkt sich der Client, das ist einer Create2Cell. Und da ist es ein bisschen Handshake-Data drin. Zurück kommt eine Created2Cell mit einem Reply zu diesem Handshake. Und daraus werden entsprechende Keys abgeleitet. Ja, das ist der grobe Überblick. Wir schauen uns das gleich nochmal im Detail an. Im Prinzip, die Create und Created2Cell müssen wir uns erst mal anschauen. Die sind ziemlich stumpf aufgebaut. Ich habe gerade schon ein bisschen was von Handshake-Data gelabert. Wichtig ist, an dieser Stelle die CircuitID in der Connection bezieht, sondern auf ein spezifisches Circuit. Da wird schon ausgewählt irgendein Integer zwischen 1 bis 2 hoch 32 im Prinzip, der eben dieses Circuit eindeutig identifiziert. Dann gibt es den Command, der ist dann entsprechend Create2, ein bisschen Magic am Anfang, dann die Länge des Handshakes und dann der eigentliche Handshake. Die Created2Cell ist sehr simpel, da gibt es dann keine Magic-Data mehr, sondern es ist sehr simpel. Hier sehen wir es nochmal. Und jetzt muss ich eine kleine Vorwarnung machen. Jetzt wird es richtig kryptografisch. Wir werden jetzt nicht so tief in die Mathematik einsteigen. Wenn ihr wisst, was ein Diffy-Helmen-Verfahren ist und wenn ihr wisst, was ein Age-Mick ist, alles ist gut. Wenn nicht, braucht ihr euch die letzte Folie der Kryptografies-Section anschauen und könnt jetzt erst mal abschalten und das lernen. Aber das werden wir sehen. Ja, im Prinzip müssen wir erstmal ein paar Dinge, wir schauen uns erst mal an, was der Klein erster macht, wenn er den Handshake erstellt. Wir deklarieren dazu vier Variablen. Erstmal die ID, das ist der Schad 2-Hash von dem RS1024 Identity Key des Notes. Dann Groß B ist der Public Curve 2519 Key des Notes, der auch öffentlich einsehbar ist und einfach zum Handshake herzugehört. Und X und Groß X ist dann ein temporärer Key, den der Klein nur für diesen Handshake kurzzeitig generiert, danach wieder erweckwürft und nie wieder verwendet. Und Groß X ist halt eben der Public Key davon. Und der eigentliche Handshake besteht dann im Prinzip nur aus der Schad 2-Hash des RS1024 Keys dazu noch einen String Public Curve 2519 Key und der eigene Public Key, die man gerade kurz temporär generiert hat. Da kommen wir auf eine Länge von 84 Bytes bei ein Schad 2-Hash und 20 Bytes und Curve 2519 Keys sind jeweils 32 Bytes. Genau. Und der Klein erstellt dann eben, erstellt und senden diese CREATE 2 Cell mit genau diesen Daten. Wenn das dann beim Note ankommt, dann macht das Note ganz viel magische Mathematik. Zuerst wird ein temporäres Keyperr erstellt. Dieses temporäre Keyperr nicht verwechseln mit B. B ist dieser Curve 2519 Public Key, die wir vorhin auch schon gerade eben gesehen haben. Aber on top wird noch zufällig ein Curve 2519 Key nur für diesen Handshake erstellt, nämlich Y. Genau. Und damit werden dann über das Diffy-Helmenverfahren bzw. Elliptic Curve Diffy-Helmen ein paar Schad Secrets abgeleitet. Wir sehen hier ein Schad Secret, das nur der Klein und durch das Note wissen können. Ja, damit erst mal eine Elliptic Curve Diffy-Helmen statt mit dem Public Key mit dem Public Key vom Note, den wir gerade eben erhalten haben in der Cell plus dem Private Key von Y und dem Private Key von B. Ja, und dazu eben noch diese Konstanten, die wir auch gerade eben erhalten haben mit noch eine Magic Value hier hinter. Und dann wird dann noch aus dem Schad Secret wird ein Key Seat weiter abgeleitet. Das findet mit der Schad 256 HMAC Funktion statt. Wobei der Key dieser HMAC Funktion eine konstante Magic Value ist, die allen bekannt ist. Also im Prinzip ist es kein richtiger Mix, sondern eher eine Zweckentfremdung von einer MAC Funktion. Ja, noch eine kleine Verify Value, die noch eine Bedeutung hat, die wird ähnlich generiert wie der Key Seat bloß mit einem Magic Value am Ende dann und noch einen sogenannten Orth-Input. Was das alles bedeutet, komme ich gleich nochmal darauf zurück. Der enthält im Prinzip diese Verify Value und dann dahinter auch noch diese Konstanten, die wir vorhin erhalten haben. Der Handshake Reply ist im Prinzip der Public Key, die wir gerade im Temporier generiert haben, den der Kleinte noch gar nicht wissen kann plus eine andere Magic Value und der wird dann mit dem Handshake Reply zurückgeschickt. Und das Einzige, was wir uns noch merken müssen, ist der Key Seat ist noch wichtig und die Verify Value ist eine temporäre Variable, die nur kurz verwendet wird um diesen Orth-Input zu generieren, welcher wiederum auch nur kurz verwendet wird, um diesen Age-Mack zu generieren. Ja, wenn der Kleinte dieses Handshake Reply empfängt, generiert er damit das Scherz-Secret, welches identisch ist, mit dem, dass er Server für sich generieren konnte. Das ist nämlich das ziemlich cool an Defi-Helmen. Er hat jetzt nämlich den Y-Key erhalten und nutzt dann halt sein Private Key, den du erkennst, um Defi-Helmen durchzuführen und auf das selbe Scherz-Secret zu kommen. Und das coole ist, da das Orth-Input bzw. der Age-Mack-Share 256 von dem Orth-Input ebenfalls mitgesendet wurde im Handshake Reply, kann es verifiziert werden, ob alles wirklich korrekt durchgeführt wurde, weil dieser Wert ist bekannt und er kann selbst nur hergeleitet werden, wenn man das Scherz-Secret richtig berechnet hat. Das ist eine ganz coole Funktion, um nachzugucken, um man das richtig implementiert hat. Jetzt kommen wir zu der wichtigen Folie, wozu das alles eben gerade geführt hat. Falls ihr das jetzt nicht verstanden habt, ist okay, mache ich euch keinen Vorwurf drauf. Wichtig ist nur, dass jetzt im Prinzip ein gemeinsamer Wert besteht, den man für eine Key-Dirivation-Funktion verwenden kann. Was ist eine Key-Dirivation-Funktion, fragt ihr euch. Das ist vielleicht ein bisschen mit Zufalls-Generatoren aus, vor allem wenn ihr die C-Programm hier spau verwendet. Zufalls-Funktionen zeichnen sich dadurch aus, also schlechte Zufalls-Funktionen zeichnen sich dadurch aus, dass sie sozusagen ein Seat haben, eine Initial Value und wenn man diesen Seat immer wieder verwendet, kommen in dem Zufalls-Generator immer wieder dieselben Daten raus. Im Prinzip ist eine Key-Dirivation-Funktion zu ähnlich, man gibt ein Seat rein und erhält dann, kann damit theoretisch sein, da das Shared-Secret ja nur begrenzt ist. Ich glaube, es ist 20-byte groß, ich will jetzt nichts falsches sagen. Und das ist auch nicht ausreichend für Keys. Nimmt man eben eine Key-Dirivation-Funktion und dann tatsächlich die wirklich symmetrischen Keys zu bekommen. Genau. Wichtiger sind bei 0 bis 19 werden für eine Forward-Digest verwendet und bei 20 bis 39 für den Backward-Digest. Und das ist das Henne-Eye-Problem, auf das ich gerade immer referenziert habe. Das ist ein bisschen zu verbrauchen haben. Macht dieser Digest ziemlich wenig Sinn. Merkt euch einfach nur, dass beide nun so einen komischen Wert haben. Die ersten 40-byte machen so einen komischen Wert, auf der später noch wichtig wird. DF und DB. Die anderen aus den restlichen Daten werden dann die ersten 16-byte für den AIS 128 Key für die Encryption, die nach vorne geht, zu Bob-Hinn verwendet und dann die anderen 16-byte mit dem KB. Ja. Damit ist das hohe Kapitel auch schon vorbei und wir können weiter mit der eigentlichen Netzwerktechnik machen. Ja. Jetzt kommen wir auf das Henne-Eye-Problem, auf das ich gerade eben schon mal kurz hingewiesen habe. Bisher haben wir nur einen Circuit im Hopp. Rein logisch müssten wir jetzt über Circuit-Extensions reden, weil ein Hopp mit nur einem, ein Circuit mit nur einem Hopp, das macht wenig Sinn. Und diese Relay-Cells machen den Circuits mit mehr als einem Hopp nun mal mehr Sinn. Bisschen blöd gelaufen, aber ich weiß ehrlich gesagt nicht, wie man das ohne ein Henne-Eye-Problem erklären könnte. Wenn ihr etwas wisst, sagt mir da auf jeden Fall Bescheid, bin ich gern offen für. Ja, deshalb müssten wir jetzt jetzt auf die Relay-Cell eingehen bzw. was ist leider, die ist sehr wichtig. Die Relay-Cell ist nämlich dieses eigentlich magische Ding. Die Relay-Cell ist das, was letzten Endes Onion-Routing verwendet. Erst ab hier findet das tatsächliche Onion-Routing im Sinne der layer-encryption statt. Eine Relay-Cell ist nämlich ähnlich auf dem Wort wie ein es ist nur letzten Endes auch nur eine Cell, ein weiterer Kuman für eine Cell. Sie enthält eine Circuit-ID, welche eben auf ein Circuit, auf das Circuit referenziert. Und der gesamte Payload ist IS128-Counter-Mode Genau, der verwendete Cypher ist, wie bereits gesagt, IS128, aber im Counter-Mode und wenn man IS in Counter-Mode verwendet wird IS, was ja normalerweise ein Block-Cypher ist, auf einmal zu einem Stream-Cypher, hat ganz nette Eigenschaften, wenn ihr gerade den Unterschied zwischen Stream und Block-Cypher nicht wisst, ganz grob gesagt, wenn ihr in ein Stream-Cypher 42-Balt reinschmeißt, bekommt ihr auch immer 42-Balt raus. In einem Stream-Cypher ist das ein bisschen anders, da ist das ein Blöcken, also falls ihr z.B. 42-Balt reinschmeißt, kann es passieren, dass dann 64-Balt an Cypher-Text rauskommt. Aber das ist so eine Kleinigkeit zu wissen, aber das ist der Grund, dass der Payload, auch wenn er verschlüsselt ist, immer noch 509-Balt groß sind, da es da eben Stream-Cypher praktisch verwendet wird. Ja, aber ich habe gerade eben gesagt, das hier ist Cypher-Text. Aber was hat dieser Cypher-Text keine Struktur, wenn man ihn entschlüsselt? In Schlüssel zieht dieser Cypher-Text nämlich so aus. Ihr seht hier wieder ein weiterer Kommand, wieder eine weitere, irgendeine ID, dann diese digits auf dem Fohren kurz eingegangen sind, dann wieder andere Daten, was klar war ich hier gerade, es ist eine Cell, bzw. eine andere Form einer Cell in einer Cellin drin. Und das heißt, dieser Plain-Text, der da verschlüsselt wird, enthält erstmal einen Kommand, welcher unterschiedliche Bedeutung hat. Einer dieser Kommand kann zum Beispiel Relay Extend sein. Ich möchte das Circuit erweitern, aber dann werden hiermit tatsächlich auch die eigentlichen TCP-Daten durchgeschickt und so weiter. Joa. Insbesondere wichtig sind diese Felder Recognized und Digits, die geben nämlich an, ob es jetzt tatsächlich verschlüsselt oder entschlüsselt ist. Darauf komme ich gleich zu sprechen. Andere Daten sind halt auch die Länge der Daten, die eigentlichen Daten und das Padding. Das ist ziemlich interessant. Sprich, die restlichen Daten werden, wenn man die ganzen 509 Bytes nicht ausschöpft, wird es trotzdem auf 509 Bytes hochgepaddet, damit man nicht an der Länge erkennen kann, wie groß der Inhalt überhaupt ist, weil das einem Angreifer einen deutlichen Vorteil liefern würde. Anstatt wenn alle einfach eine konstante Länge haben. Joa. Im Prinzip, wie bereits gesagt, enthält es ein Onion Skin. Wenn es vorwärts verschlüsselt wird, verschlüsselt man den KFs, den allen Vorwortkeys, die ihr mit allen Hops habt. Vom letzten bis zum ersten, da ihr im Prinzip der Letzte zuletzt entschlüsselt muss, deshalb wird der Letzte zuerst verwendet, weil der so schichtenartig aufgebohrt wird, wie ich am Anfang gezeigt habe. Hier habe ich auch nochmal ein bisschen Pseudocode, im Prinzip von hinten nach vorne, verschlüsselt mit dem Key. Jedes Note im Circuit entschlüsselt an diesen Psypha Text und dann kommt da eine kleine Verzweigung rein. Ich habe gerade noch immer verschlüsselt. Ich habe jetzt gerade einmal entschlüsselt, aber das ist immer noch Psypha Text. Wenn ja, ok, ich kann es weiterreichen ans nächste Note. Wie? Ich kann es lesen, es ist auf einmal plaintext. Ok, cool, dann kann ich damit ja was anfangen. Joa, rückwärts ist es ähnlich. Jedes Note verschlüsselt mit seinem Backward Key und schickt es zurück. Im Prinzip in Crypt mit dem eigenen Backward Key send. Und nur der Client hat eben alle Keys, alle Backward Keys, um es vollständig zu entschlüsseln. Von 1. bis zum Letzten und nicht vom Letzten bis zum 1. Joa. Und jetzt kommen wir zu diesem Digis, den ich vorher schon mal angeschnitten habe. Den Recognized Field, was bedeutet das alles überhaupt? To be plain or to be Psypha, that's the question. Das Problem ist, wenn ein Note nun eine Ebene entfernt hat, nun einmal entschlüsselt hat. Wie weiß es dann, ob der plaintext, der dabei rauszukommen ist, schon der tatsächliche plaintext ist oder schon Psypha Text ist? Gut, man könnte argumentieren, ja, wenn dabei Gabitsch rauskommt, dann muss es ja passen. Das ist aber nicht wirklich schön. Psypha Text soll ja zufällig aussehen. Und wenn dann nur mal zufällig was Valides rauskommt, das ist keine elegante Lösung. Deshalb baut man mal ein paar Tipps und Tricks ein, womit man elegante herausfinden kann, ob es jetzt nun vollständig entschlüsselt ist oder ob ich es weiterreichen muss, ob es noch nicht vollständig entschlüsselt ist. Im Prinzip ist es so, wenn die Relay Cell, unverschuldet, muss die Relay Cell in dem Recognized field, das muss auf Null gesetzt sein. Wenn es sich um diesen plaintext tatsächlich handelt. Das Problem dahinter ist, ein einziges Feld wird nicht ausreichen, weil es ist nur 2 weit lang und mit einer Wahrscheinlichkeit von 1 zu 2 hoch 16 ist dieses Feld auch im Psypha Text noch immer Null. 2 hoch 16 klingt vielleicht etwas groß, ist es aber nicht. Ich habe mal ein bisschen nachgerechnet, ungefähr alle 35 Megabyte die transferiert werden müsste so ein FHK es einmal vorkommen und das ist nicht wirklich akzeptabel. Deshalb ist noch ein anderes Feld drin, das Digist Feld. Ich muss vorfahren, diese Lösung über diesen Digist, das ist unfassbar hässlich, unfassbar ekelhaft. Es macht keinen Spaß das zu implementieren oder zu migrieren zu einer anderen Lösung. Aber es ist wirklich nicht schön. Im Prinzip ist ein Digist nur ein Hash. Ein Hash, der alle Daten enthält, welche zwischen dem Client und diesem, diesem einen Note versendet wurden. Dieser Digist zeichnet sich aber noch, und ganz wichtig ist, dass auch das nur die unverschlüsselten Daten einfließen. Das heißt Cells, die encrypted werden, die decrypted werden, aber noch immer weitergeleitet werden, fließen darin nicht mit ein. Nur die, die tatsächlich für dieses eine Note bestimmt sind. Und dieser Hash, der erste Wetter da reinkommt, ist tatsächlich keine Cell, sondern eben diese Initial Value, dieses DF oder das DB, das wir vorher bei der KeyDrivation mit raus bekommen haben. Das ist keine schöne Lösung. Und ich kann verstehen, wenn das verwirrt, wichtig ist nur, dass mit dieser Technik herausgefunden wird, ob jetzt diese Relay Cell tatsächlich schon vollständig entschlüsselt ist, oder ob ich sie weiterreichen muss. Letzten Endes ist das auch keine perfekte Lösung. Eine perfekte Lösung gibt es hier nämlich nicht. Weil es kann immer sein, dass das Cypher Text zufälligerweise eine vollkommen valide Cells mit der alles passen würde. Stattdessen verringert man die Wahrscheinlichkeit mit diesem 2 hoch 16 mal 1 zu 32 auf 1 zu 2 hoch 48. 1 zu 2 hoch 48 ist wiederum eine vernachlässigbar geringe Wahrscheinlichkeit, weil der Digist, es sind die ersten vier weite Digist. Genau. Ja. Jetzt bezielen vielleicht erstmal Fragen. Ich kann verstehen, dass gerade dieses Ding mit dem Digist durchaus kompliziert ist. Ja. Wir haben nicht die Unterscheidendbarkeit, dass es jetzt Cypher Text oder kein Cypher Text ist. Würde man einfach dieses Paket nochmal senken? Kannst du die Frage nochmal wiederholen? Ja, angenommen, wir haben jetzt diesen Fall, dass eben diese Funk von hash-kundischen ja auftritt. Ja. Dann haben wir ja das Problem, dass wir eben jetzt nicht wissen, okay, ist das Cypher Text, ist das kein Cypher Text. Was macht man dann eben? Das Paket wird weitergeleitet. Aber die Wahrscheinlichkeit ist eben wirklich 1 zu 2 hoch 48. Dring, aber möglich. Aber kommen tatsächlich auf die Daten ein. Wenn es ein Beispiel, wenn der Inhalt dann tatsächlich TCP-Daten sind, da wird das vermutlich auf Protokoll-Ebene irgendwie gemerkt, dass da irgendwas faulig war. Aber ja, dann hat man ein Problem. Ja. Okay. Ja. Jetzt können wir zum wirklich spannenden, wenn die Circuits dann tatsächlich extended werden. Wenn es vom ersten Note zum zweiten Note gibt, zum dritten und dann schlussendlich zu Bob. Dafür gibt es einen Relay-Command, nämlich einen Extend-To und einen Extended-To-Command. Und ihr seht ja schon wieder, die sind sementisch sehr, sehr ähnlich zu der Create-To-Cell. Mit dem Unterschied, dass sie halt eben noch die IP enthalten, was jetzt der next Note eigentlich ist. Im Prinzip funktioniert so, der Kleint erstellt erstmal einen Circuit mit dem ersten Note und dann schickt da eine Relay-Cell, eine Relay-Extend-To-Cell mit einer Handshake-Data an das erste Note. Das erste Note nimmt diese Relay-Cell, entschlüsselt sie, weiß okay, die Relay-Cell ist für mich bestimmt, es ist plaintext, ich habe jetzt plaintext, ich kann mit dem Inhalt etwas anfangen. Oh, ich nehme mal die Handshake-Data, verbinde mich, schau, ob ich eine, okay, ich sehe, der möchte das Circuit jetzt zu einem weiteren Note erweitern. Mit der Connection habe ich die, gut, habe ich die noch nicht, erstelle ich eine, stecke ich wieder diese Version-Cell, NetInfo-Cell, Third-Cell und so weiter und dann habe ich damit auch eine Connection und wenn dann diese Connection besteht, macht das erste Note eine Create-To-Cell und erstellt im Prinzip das Circuit ähnlich wie hier, bloß nicht mit eigener Handshake-Data, sondern mit der Handshake-Data, die hier drin ist und das ist ganz interessant. Beziehungsweise kann es schon, in dem nachgeschaut wird, ob BIP, die sich verbindet in diesem Konsens-State, in dieser Liste steht, ob es überhaupt ein Relay ist, aber theoretisch an Protokoll-Ebene ist es nicht möglich, das zu erkennen. Ja, und die eigentliche Handshake-Data, die da ausgetauscht wird, ist identisch mit dem ersten Hopping. Dieser kriptografische Handshake, den ich euch da eben vorgezeigt habe, ist derselbe, bloß das dann logischerweise die Public Keys für den zweiten Note verwendet werden, dann schaut die Public Keys vom ersten Note. Ja, man-in-the-Middle-Attacken wären an dieser Stelle auch zwecklos, da der klein, ja letztendlich, in das alle Keys kennt, erkennt ja das, den Key, die Public Keys von dem zweiten Note und wenn da irgendwas faulig wäre, das wird auf jeden Fall spätestens im Handshake-Replay auffallen. Ja, nun kommen wir zu den eigentlichen Streams, wenn in das Circuit letzten Endes vollständig erweitert ist. Wenn zum dritten Note auch aufgebaut, zum dritten Hop-off auch aufgebaut wurde, das passiert im Prinzip in dem ähnlichen System, bloß das die Relay-Cell dann an das zweite Note anstatt das erste geschickt wird. Ja, und die Streams sind dann das eigentliche, coole das eigentliche, was an die tcf-Daten enthält. Bisher haben wir nämlich doch gar nicht darüber geredet, dass wir versuchen, tcf-Daten anonym hin- und herzuschicken. Und das tun wir jetzt endlich mal. Ein Circuit kann mehrere Streams haben. Ein Stream ist dann tatsächlich eine reale physische tcf-Verbindung zwischen dem letzten Hop und einem tcf-Server. Die Streams werden über das Stream-ID-Feld in den Relay-Cells, das da ziemlich weit am Anfang kommt, eindeutig identifiziert, ähnlich wie das auch mit den Circuit-IDs auf der Cell-Ebene funktioniert. Und das Ganze ist dreischrittig. Ein Stream wird mit Relay Beginn erstellt, da kommt ein Relay-Connector zurück und dann werden einfach tcf-Daten in Relay-Data-Cells, wir kommen auf die gleich zu sprechen, geschickt und am Ende wird das Streamer mit Relay endet. Und ich glaube, ihr könnt euch denken, warum Tor bisher nur tcp unterstützt, weil einfach an dieser ganzen Architektur, die ich euch gerade gezeigt habe, Streams sich wirklich nice integrieren. Aber wir kriegen vielleicht hoffentlich Ende des Jahres dann endlich mal die UDP Support. Ja, schauen wir uns da mal die Relay Beginn-Cell an, wie so ein Stream überhaupt erstellt wird. Relay Beginn funktioniert so, dass da ein Relay-Command erstmal drin ist, ja, dann die ganzen anderen Daten, die in der Relay-Cell drin sind. Dann die Adresse, auf die wir uns connecten wollen, das ist ein Null-Terminated-String. Ja, die erste Tor-Implementierung wurde in C geschrieben. Das ist nicht so schön. Aber es wird gerade in Rust neu geschrieben. Also, die sind auf einem guten Weg. Trotzdem ist hier ein Null-Terminated-String drin, der die IP enthält. Und mit dieser IP löst dann noch das letzte Note tatsächlich auf. Also, guten IP wird nicht aufgelöst, aber wenn der Name drin steht, der wird dann aufgelöst. Am Ende sind noch ein paar Flex drin, die Flex enthalten sowas wie, möchte ich IPv6 haben, kann ich IPv6, mag ich IPv6, bin ich noch in der Steinzeit und kann IPv6. Im Prinzip gibt es hier nur um IPv6, also bin ich cool und modern, oder bin ich noch legacy? Ja. Und die Relay-Connected-Cell ist dann im Prinzip die Antwort darauf. Eine Relay-Connected-Cell enthält im Prinzip die IPv4-Adresse, die hinter dieser Domain steckt, bzw. wenn es kein Domain ist, eben die IPv4-Adresse und ein Time-To-Life, ein Eintrag bestehen darf. Und wenn der IPv6 kommt, alternativ stattdessen kann auch eine IPv6-Adresse drin stehen, mit der 0.0.0.0 IPv4-Adresse, die vorhin da steht und dann am Ende auch noch mal Time-To-Live. Die eigentlichen Daten werden dann in Relay-Data-Cells übertragen, das sind im Prinzip auch Relay-Cells, wo der gesamte Payload dann tatsächlich die eigentliche TCP-Daten sind. Beendet wird das Stream dann mit Relay-End-Cells und die haben im Prinzip da ist der Payload nicht sonderlich wichtig, der enthält nur so eine Reason, warum wir das beendet ist dann Time-Out. Summa Summa herum. Tor ist ein sehr umfassendes und sehr verbührendes Netzwerk Protokoll gerade am Anfang. Man merkt, dass es 20 Jahre alt ist, dass da sehr viele Fehler mitgeschrieben haben und dass deshalb sehr an der Komplexität gewachsen ist. Meiner Meinung nach hat Tor deshalb eine ziemliche Ähnlichkeit zu Schach und Schachbross. Easy to learn, hard to master. Ja, und es war definitiv nicht genug Platz, um alles zu behandeln. Wie bereits gesagt, easy to learn, hard to master. Wir sind gar nicht eingengang auf Circuit-Tairdowns, wie werden die Circuits geschlossen? Wir sind gar nicht auf Eingang wie die Verbindungen geschlossen werden. Wir sind gar nicht auf die alten Legacy-Methoden eingegangen, wie das vor 10 Jahren gemacht wurde. Directory-Server, wie überhaupt diese Publikis ausgetauscht werden, gar nicht behandelt sind. Ein umfassendes, umfangreiches Protokollis. Aber wenn ihr euch daran interessiert, schaut euch gerne die Specs durch, speck.torproject.org. Ich versuche die nicht mit diesem Vortrag zu ersetzen. Liest sie euch gerne durch. Und ich habe an dieser Stelle auch gerade, wenn irgendwo Magic stand, sind das irgendwelche Werte, auf die ich nicht eingengang bin, weil sie eben nur in Legacy-Fällen einen anderen Wert gehabt hätten. Einige Stellen sind auch sehr vereinfacht worden. Zum Beispiel habe ich euch bei den Sales ein bisschen angelogen. Ich bin darauf ausgegangen, dass alle Sales diese 514 Byte groß sind. Aber es gibt auch sogenannte Variable-Lengths Sales, auf die ich diesmal zum Beispiel gar nicht eingengang bin. Es war wirklich eine einfache Darstellung und ich hoffe, ich kann euch mal kurz erklären, wie das Tod-Netzwerk-Protokoll ungefähr im Gruppen funktioniert. Und ich bedanke mich dann schon mal für eure Aufmerksamkeit. Gibt es irgendwelche Fragen noch? Nein, ich habe keine Fragen gemacht. Aber gleich kommt noch ein anderer Vortrag. Ja? Es muss ein extremer Aufwand sein, jedes Mal gegen Helden zu betreiben. Es muss ja richtig krass sein. Ich betreibe einen Relay und das hat immer so 20.000 bis 30.000 Verbindungen. Das geht. Und das ist ein Server von Netcup, ein V-Server mit, ich glaube, 4GB Arbeitsspeicher. Hat sie noch keiner beschwert? Und bei Elliptic Curve, kann es wissen, nach deutlich effizienter ist. Ja, klar. Nur noch kurze Anmerkung. Man kann sowohl den RSA 1024 Identity Key oder den Long-Tam Key als auch den ED251's neue Identity Key offline betreiben. Meines Wissens ist es aber nur möglich, den ED251's neuen Long Identity Key offline zu betreiben. Ja, das liegt daran, der RSA 1024 Key signiert den ED251's neuen Identity Key. Das hätte ich vielleicht noch mal erwähnen sollen. Und er wird auch an einigen Legacy-Stellen verwendet, auf die ich hier nicht eingegangen bin, weil Legacy, was vor 10 Jahren behandelt wurde, hat vielleicht nicht mehr so die Relevanz. Ja, geht. Ja, theoretisch bist du laut dem Protokoll auch gar nicht auf maximal 3 Notes beschränkt. Wobei es tatsächlich muss man sagen die Extent Two nachrichten, werden nicht in Relay Cells übertragen, wo der Command Relay ist, sondern der ist Relay Early. Und es gibt eine Hard Limit darauf. Das heißt, wenn du, ich glaube, bis zu acht könntest du tatsächlich machen, ab da wird's richtig, ab da wird's nicht mehr gehen. Aber ja, du könntest da tatsächlich reklusiv machen, das geht. Wenn das nicht gehen würde, dann wird ja irgendwer wissen, was das Problem ist, das wäre auffällig. Das wird den Sinn dahinter ja kaputt machen. Ja? Welches Problem ergibt es einem bei mit Schicke, damit ich nicht das komplexe Problem habe, dass ich einen Pelon identifizieren muss, das kann verschlossen werden, sondern dass ich einfach den Counter dekumentiere proHoffe und damit dann weiß, wenn der Counter nur ist, dann muss das Ding nicht gehen. Das Problem ist, dafür müssten wir sagen, der Hoppe steht aus drei, da müsste das erste Not ja auf eine... Das Problem ist, dann weiß das zweite Not, dass das zweite Not ist. Dann weiß jedes Not, welche Rolle es im Zirkut hat und das ist vielleicht nicht das, was man haben möchte. Dann weiß es ja, in welcher Position es sich befindet und damit, wer die Privatsphäre leicht kompromitiert. Ja, dann danke für Raufmann. Ja? Aber in der Praxis gibt's ja auch Guardflex, Mittelflex und Exitflex. Das ist auch tatsächlich so, theoretisch kann jeder Not eine beliebige Rolle übernehmen nach dem Protokoll. Aber man ist wissend, dass es so, wenn ein Not zum Beispiel einen Exitflex hat, wird die Bandbreite quasi nicht als Mittelrelay verschwendet, weil es gibt Exitrelays was Kritisches. Ja, tatsächlich, aber das wird außerhalb des Torprotokolls geregelt. Das war nur das Netzwerkprotokoll, wie es vom Netzwerk her funktioniert in dem Directory-Protokoll. An sich ist es möglich, auch ein Exitrelay als Guardrelay als erstes zu verwenden, als ersten Not. Das Protokoll verbietet es nicht und man kann auch als Garten, man kann auch als erstes Not irgendwas nehmen, das nicht den Guardfleck hat. Die sind auch, diese ganzen Flex, ob das jetzt ein Exit, ein Entry oder Middle-Notes, das Management dafür findet außerhalb vom Torprotokoll statt. Das ist auch eher eine unverbindliche Empfehlung, weil das Torprotokoll macht es theoretisch möglich, dass du es auch darüber hinweg setzt. Ja, da hinten sehe ich noch 2 Millionen, ja, erst mal. Da fehlen mir leider die Infos. Ich habe das nur im ARC gesehen, als ich Fragen gestellt habe, da meinten die, ja, er setzt mir bald, aber mehr weiß ich nicht. Okay, und jetzt geht es irgendwie um Matrix, habe ich gehört. Ja, danke für Ihre Aufmerksamkeit, nochmal.