 Ich glaube, viele von euch benutzen PGP hier. Wenn ihr das macht, dann raise die Hand. Gut, Hackers. Also, wenn ihr eine Entschuldigung zu jemandem neu habt, wo ihr jemand anderes einen Schlüssel dazu hattet, dann muss man den kriptografischen Schlüssel für die anderen Seite holen. Aber die Realität ist, dass man die Schlüssel einfach vom Schlüsselzerbe herunterlädt. Aber was, wenn ich euch jetzt sage, dass es einen neuen Weg gibt, wenn ihr jetzt einen neuen Weg gibt, dass ihr netter zeigen könnt, dass es eine andere Person wirklich zu diesem Schlüssel hat. Und der neue Vortragende wird einen Vortrag zu Clamchains haben. Also, einen großen Applaus für Marius. Das ist Sakades und los geht's. Hallo. Wir haben eine wunderschöne Einführung in unseren Vortrag bekommen. Das ist ein Clamchains und das ist ein moderner Schlüsselaustausch, Protokoll und Implementation. Und die haben wir in Zusammenarbeit mit Leuten von der EPLFL gemacht aus London. Und ich bin auch wieder aus der Universität London. Und Clamchains ist eine dezentralisierte öffentliche Keyinfrastruktur, die privates, fairen, freundliche Verifikation von Menschen und Schlüssel ermöglicht. Wir werden viel über Blockchain reden. Es ist natürlich aktuell ein Hype und Blockchain können in sehr vielen unterschiedlichen Applikationen verwendet werden, aber sie haben auch viele gute Eigenschaften, die für öffentliche Keyinfrastruktur benutzbar sind. Sie können hohe Integrität für die gespeicherten Daten ermöglichen. Sobald die Daten in der Blockchain sind, können sie nicht mehr überschrieben werden. Wir können auch Authentizität verifizieren, weil die ganzen kryptografischen Signaturen und Hashings benutzt wird. Per Definition sind Blockchain dezentralisiert, also sind sie erreichbar. Man kann zu irgendeinem Bitcoin voll Knoten hingehen und die Transaktion verifizieren. Bei einem Bitcoin runter zerstören muss man alle vollen Knoten zerstören. Es gibt auch diesen Proof of Work, damit man viele Tickets bekommt. Die erste Generation von Blockchain-pabilisierte Public Keyinfrastruktur ist das der Proof of Work von diesen Blockchain, z.B. bei Namecoin oder BlockStack, die haben den Bitcoin-Kryptografietoken benutzt, um Identitäten zu speichern. Das heißt, man kann Identities kaufen und sie verkaufen usw. und sie gehören zu einem. Das ist eine stärkere Abstraktion als PGP-Schlüsse, wie wir sie heutzutage verwenden. Sie haben auch einen globalen Namensraum. Wenn wir sie Identität in Namecoin haben, dann ist du das. Jeder kann dich als Besitzer der Identität erkennen. Aber es gibt auch keine Möglichkeiten, eine soziale Verifikation zu machen. Wenn jemand behauptet, Alie zu sein, dann wissen wir nicht, wer dieser Alie ist oder ob jemand dieser Alie ist. Alle Transaktionen sind öffentlich, d.h. es gibt Privatzwehren, Implementationen, d.h. man kann z.B. durch die Transaktionen herausfinden, dass einige Identitäten zusammen verbunden sind. Es gibt einige Kosten, die bezahlt werden müssen, die beinhalten sind für Transaktions-Fees. Und das ist ziemlich aufwendig. Transaktionen, Proof of Work, und es gibt eine große Detailattent. Es gibt noch gewisse Anzahl von Transaktionen, die inkludiert werden können usw. Dann kam die nächste Generation von Publiki-Infrastruktur auf Blockchain. Keybase und Conics, die können von E-Mail-Providern verwendet werden, z.B. bei Gmail. Und was sie gemacht haben, ist, sie haben die Transaktionsböcke durch ein Merkel-Hashtrike-Prefectsbaum ersetzt. Und die Providers können Beweise über die Nutzer erstellen. D.h. wenn Gmail jetzt Conics benutzen würde, könnte man den öffentlichen Schlüsselmaterial für einen speziellen Gmail-User herunterladen, von deren Conicserver hätte auch Beweise bekommen können, dass es derselbe Schlüssel ist, den andere bekommen zu diesem spezifischen Zeitpunkt. D.h. man kann es relativ einfach finden, man weiß z.B. Ali-at-Gmail gehört zu Gmail, man kann dann dort nachfragen, und es ist nur Google, der diese Struktur unterstützt. Man kann sehr effizient Beweis, wenigen Kilobytes benutzen, dass die richtigen Daten sind, die man bekommt. Aber andererseits gibt es keine Schlüssel-Zurückrufung, das kann doch später wiedererkennen, aber dann ist es schlecht, um zu spähen. Und außerdem zum größten Punkt zentralisieren Sie die öffentliche Ki-Infrastruktur, wie da was wieder neue Angriffe ermöglicht. Es ist ein einfach, einzelnen Failpunkt, vieler Böcklichkeitspunkt es. Und wenn der Server ausgeschaltet ist, kann man die PGP-Schüssel nicht mehr bekommen, für die Einzelne, für alle Benutzer. Und außerdem können Sie Überwachung durchführen, darüber, wer jetzt die Schlüssel bekommt und wer. Und es wird auch dieser soziale Graf aufgebaut. Der Merkel-Binary-Prefix-Baum, den ich vorhin ernannt habe, ist ein Merkel-Baum. Und die Sonderheit ist, um die Knoten zu sortieren, benutzen wir eine zuverlässige, verifizierbare, zufällige Funktion. Es ist eine Funktion, die einen eindeutigen Output erstellt, wenn man einen privaten Schlüssel hier gibt. Das heißt, wir haben einen privaten Schlüssel, der mit dieser Verifikation ist. Und ich kann einen Output erstellen, der zufällig ist. Aber wenn du einen öffentlichen Schlüssel hast, kannst du verifizieren, dass dies der eindeutige Output ist. Und diese Funktion kann, wenn man es auf Merkel-Bäume anwendet, kann man zeigen, dass jeder, der einen Zertifikat für den spezifisches Label hat, immer zu den selben Blattknoten in dem Merkel-Baum kommt. Wenn zwei Leute kommen zu einem Profil, weil diese Property existiert, kriegen beide denselben Knoten. Wie verbessern wir uns gegenüber den normalen Conics? Was wir anders machen, ist, wir forcieren Dezentralisierung. Das tun wir, indem wir den Host des Users, in dem der Benutzer, oder für das Gerät oder für die Identität der Benutzer nutzen möchten. Wir haben z.B. Alice, Bob und Charlie. Und die haben alle eigene andere Caps. Es gibt kein Konsens. Wir brauchen kein Blockchain darüber. Wir brauchen nur diese Struktur. Signieren Sie mit einem Sigma-Tour-Schlüssel. Und das ist es. Jeder kann verifizieren, dass diese Sequence gültig ist. Nun stellt euch vor, dass es irgendwo eine Gabelung in dieser Kette gibt, weil zwei gültige Blöcke von einem Block ausgehen. Das kann dann als eine Kompromittierung verstanden werden. Das könnte bedeuten, dass jemand meinen Signaturschlüssel bekommen hat. Es könnte sein, dass ich versucht habe, einen anderen Kiel zu erzeugen. Was wir auch machen, ist, wir haben einen granularen Zugangsmechanismus, der auf Capability ist beruht. Die Besitzer, jeder Claimchain, können regeln, wer die Claimchain lesen darf. Und durch diese Nicht-Evokation können wir sicherstellen, dass alle denselben Inhalte bekommen. Und brauchen wir einen Weg, um diese Information zu verbreiten. Wir müssen wissen, wenn unsere Freunde ihre Chains updaten. Irgendwie müssen wir den Schlüssel verteilen. Dazu führen wir diesen Mechanismus ein Crosshashing ein. Dort bauen wir ein Siegel ein, des letzten Standes, der Claimchain unserer Freunde. Hier beispielsweise nimmt alles ein Attest für die Blöcke von Bob und Guy Forks. Auch Bob hat einen Statement an einem früheren Punkt, dass er weiß, dass er ein bisschen veraltet sein kann, aber dass er vom Konsens dieses Systems weiß. Damit haben wir also eine Propagation von Schlüsseln in Usergruppen, also wie Tratsch in der realen Welt funktioniert. Wir hängen nicht einfach kryptografische Signaturen an die Blöcke anderer User an, sondern wir bestätigen auch den aktuellsten Zustand ihres Weltbilds. Wir nutzen diesen Mechanismus, um Freunde vorzustellen, sie in unser Web of Trust einzunehmen. Gleichzeitig können wir dabei trotzdem die Privatsphäre unserer Claimchain sich erstellen. Eine weitere Eigenschaft von Claimchain ist es, dass sie hohe Integrität besitzen und authentisierte Data Stores sind. Weil die ganzen Signaturen, die dort passieren, das sich erstellen. Was wir Claimchain machen können, ist, wir können generische Claims abbilden. Zum Beispiel für die Delegation von Zugänge, für Kontrolle eines Botnets oder für irgendwas, was man sich vorstellen kann. Gleichzeitig unterstützen wir auch die Privatsphäre dieser Claims, denn wir zeigen keinen Inhalt des Claims an, sondern signieren nur, dass er da ist. Es wird auch keinen Inhalt über die Leser eines Claims rausgegeben. Das stellt dieser Capability-Mechanismus sich an, den ich euch nachher erklären werde. Mit dieser Funktion können wir sogar verschiedene Dinge für verschiedene Leser verschlüsseln. Das heißt, alle bekommen dieselbe Sicht. Schließlich diese Cross-Signatures stellen sicher, dass die Klicke dieser Gruppe immer dieselbe Sicht auf das aktuelle Weltbild hat. Des Weiteren kann jede Claimchain als selbststehendes Beweismaterial für Sicht genommen werden. Und widerspiegelt die ganze Chain, um das Ganze auszurollen, haben wir viel Arbeit reingesteckt zu nationalisieren, wie das Ganze skalieren kann, wie dort Gees verteilen können, mit welchen Bandfreien Anforderungen so was möglich ist, wie lange es dauert, um das zu berechnen. Und diese Analysen, die wir gemacht haben, findet ihr auf unserer GitHub-Seite. Claimchain ist sehr flexibel und das funktioniert in federierten Szenarien wie Connix oder auch in Sandelone-Applikationen, wo man eigene Blöcke herauflädt. Und es funktioniert auch in Traged-Szenarien in einem offen peer-to-peer-Netzwerk. Es ist mir das Wort entfallen. Es ist ein Netzwerk, wenn man den Beweis, den man beweisen will, einfach anhängt an einer E-Mail zum Beispiel, die man seinen Freunden sendet. Es kann ihr sehr effizient tun, indem wir nur die Claims, die wir einem Leser senden wollen, einfügen, plus einige Beweise, dass diese Claims auch Teil unserer Claimchain sind. Also eine Proof of Inclusion, die wir mit seinen Metadaten haben. Nun kommen wir zu den Interner, und ich glaube, wir haben noch kurz Zeit dafür. Die Blockstruktur hat ein bisschen Versionsinformation, ein Timestime natürlich, die Blocksequenz, einen Nons, die wir brauchen, um den Zusammenhang zwischen Claims und Capability sicherzustellen, Claimchain-Metadaten, dass die Identität muss dazugehört, was wir mit diesem Claim abbilden wollen, wie zum Beispiel ein Twitterhandel oder sowas, und einige öffentliche Schlüssel, die wir brauchen, um die Claimchain zu betreiben. Es benötigt einen Public Key für das Signieren neuer Blöcke, für die verreffizierbare Zufallsfunktion und den DH-Schlüssel, den wir für die Technik dort brauchen. Und zum Schluss, das Kern-Element ist die Blockmap. Dort werden alle Claims und Capabilities gespeichert. Und natürlich die Verbindungen zu vorherigen Blocks. Damit können wir überhaupt erst eine Blockchain aufbauen. Und was ihr hier seht, auf der rechten Seite, ist, alle diese Felder links werden signiert mit einer selbststehenden Signatur aus einem Stück Information, dass wir eben an eine E-Mail anhängen können oder speichern können, irgendwo online in einem Datenspeichert, den wir sonst nicht als vertrauenswürdig halten würden. Und niemand kann diese Information verändern. Wenn ihr jetzt ein Claim erstellen wollt, ihr stellt ja einen Merkel-Baum und dann könnt ihr einen Cross-Tash für Bob erstellen. Dann müsst ihr zuallererst ein Label erstellen, das ihr für Bob von diesem Punkt definiert, z.B. Bob.riseup.net. Und wenn ihr euch jetzt feststellen wollt, dass der Claim der oberste Block von ihm ist, dann müsst ihr eine private Claim erstellen in der entsprechenden Funktion, nimmt ihr Bob.riseup.net mit einer Nonst, damit ihr die Zugangsbeschränkungen erstellen könnt. Dann erstellt ihr den Indie-X von dem Leaf-Node, wie ihr den Leaf-Node in dem Baum speichert, das ist in dem ihr gegen Claim-Key benutzt und mit einem String-Lookup-Hash. Und dann eine symmetrische Verschlüsselungsschlüssel, wieder in dem der Claim-Key benutzt wird, um in 15 Minuten dran zu sehen und dann das Ganze zu häschen. Wir haben den Inhalt jetzt mit den symmetrischen Verschlüssel, den wir im zweiten Schritt erstellt haben und wir hängen auch den VRF-Beweis dran, um sicherzustellen, dass die Schüsse, den wir im ersten Schritt erstellt haben, der einzig ist. Und damit erstellen wir den Blattknoten, der zu dem Cross-Hash für Bob's Kette ist. Den speichern wir in unserem Bauch. Nächte Szenario. Wir wollen eine Möglichkeit für Guy-Fox erstellen, damit er Bob's Cross-Hash lesen kann in der Claim-Chain von Alice. Wir benutzen den Diffy-Hellmann, um ein geteiltes Geheimnis zwischen Bob und zwischen Alice und Guy-Fox zu erstellen. Und dann benutzen wir diesen geteilten Geheimnis, um den Nons und einem Lookup um die Kapitabilitäts-Lookupschlüssel zu erstellen. Das ist der Index von diesem Lookupschlüssel, von diesen Fähigkeiten für den Zugriff. Und die Nons ist um, damit es eindeutig ist, und damit es ein bisschen weiter versteckt, dass man nicht traten kann. Und dann erstellen wir den symmetrischen Verschlüsselungsschlüssel. Und dann verschlüsseln wir den Claim-Key von dem blauen Liefknot, den wir zuvor hinzugefügt haben und mit dem symmetrischen Verschlüsselungsschlüssel aus dem dritten Schritt. So dass Guy-Fox es in der Zukunft entschlüsseln kann. Das erstellen wir. Den Liefknoten wird erstellt und in den Baum abgespeichert. Wenn Guy-Fox nun diese Information oder heraushint, möchte, was die aktuelle Version von Bob in Alice als Baum ist, dann wird er den Funktionen rückwärts gehen. Er wird das Teil der Geheimnisse berechnen und dann die Fähigkeiten symmetrischen Schlüssel herausfinden, genauso wie Alice es ihm berechnet hat. Und dann wird er zu Alice gleich im Baum, unter der merke prefix Baum gehen und dort entsprechend den Blattknoten herausfinden. Er wird dann den symmetrischen Schlüssel benutzen, um ihn zu entschüsseln und dann wird der Claim-Schlüssel für Bob's Claim kann er berechnet werden. Soweit, wenn wir uns noch mal daran erinnern, der Claim-Schlüssel für Bob's Claim beinhaltet den Hash eines VRF, also eines verifizierbaren, zufälligen Funktionen. Und er wird dann Bob's Claim entschüsseln. Er kann auch wieder den VRF-Schüssel überrechnen. Und sind wir jetzt fertig? Nein, noch nicht wirklich. Er muss auch noch den Beweis, den VRF-Beweis benutzen, der in dem Entschüsselten Claim beinhaltet ist, um zu verifizieren, dass der VRF-Beweis, den er bekommt, der Einzige ist, den er das erstellt haben könnte mit dem VRF-Privatenschlüssel. Wir sind jetzt ziemlich schnell durchgerannt, aber wieder, diese ganze Information ist in dem Artikel und den könnt ihr euch später anschauen. Also findet mich, ich habe noch mehr Folien, wie die ganzen Beweise funktionieren. Was ich noch sagen möchte, ist der Schritt 6. Wenn GuyFox versucht, die Fähigkeiten Block herunterzuladen und das nicht findet, dann bedeutet, dass alles GuyFox noch nicht die Fähigkeiten gegeben hat, diesen Schlüssel, diesen Claim über Bob herauszulesen. Und in dieser Situation weiß GuyFox nicht, ob dieser Block überhaupt existiert. Wir haben diesen Vortrag für den 34D3 Resilience-Track eingereicht. Wir verstehen, dass es ein akademischer Vortrag ist. Wir würden gerne wissen, dass es wichtig, dass es ein starkes Verfahren ist. Warum haben wir das gemacht? Zunächst haben wir Feldresearch benutzt, weil Leute gefragt, was sie brauchen. Hauptsächlich Paar Pariser Forscher haben das gemacht. Dann haben wir uns Projekte angeschaut und die Research-Probleme müssen zusammenarbeiten mit anderen, die auch dort arbeiten. Wir haben da mit einer deutschen Organisation zusammengearbeitet und wir arbeiten mit denen zusammen. Wir haben Techniken benutzt, die schon häufig benutzt werden. In Akademia gibt es Techniken, die aktuell benutzt werden. Mit angewandter Forschung, die führen wollen, dass alles formal verifiziert wird. Der ganzen Code, den man verifiziert, ist formal verifizierbar. Für Claim-Chain haben wir alle Sicherheits- und Privatsphärmen Möglichkeiten definiert. Wir haben in welchen Situationen den Linker-Bach zwischen Blöcken haben wegen den unterschiedlichen kryptografischen Inhalten. Wir haben auch eine formale verifizierte Implementation der kryptografischen Komponenten in F-Stern. Das heißt, ihr könnt den Merkelbaum und die VRRF-Funktion in unserem Github-Repository finden. Wenn wir jetzt auf Stabilität reden, müssen wir wissen, wie unser System es skalieren. Da haben wir Simulationen mit echt Zeit, mit wirklichen Daten versucht. Das ist mit einem geliegten E-Mail-Directorie von einer Firma. Das wird von Akademia häufig benutzt, wenn eine echte Weltkommunikation und die Effizienz der Crosshashing-Protokoll verwendet. Wie man in den letzten Status übermittelt mit dem Chematerial von heute. Wie wir das ausrollen wollen, ist es sehr flexibel, wie man das jetzt benutzt. Wir haben jetzt, wie man das ausrollen will, wie man das ausrollen will, ist es sehr flexibel, wie man das jetzt benutzt. Wir haben uns entschieden, wir haben das jetzt noch nicht gemacht, aber wir wollen, die ausgerüstet implementieren wollen, um die Emotionen zu benutzen, müssen die Kompatibilität sein mit existierenden Implimentationen. Wir brüsten auch viel darauf achten, wie man das benutzt. Wie wird Keymanagement in einer Art und Weise gemacht, dass die Benutzer nicht Fehler machen? Wie ruft man einen Schlüssel zurück? Wie kommuniziert man das mit einem Benutzer? Und wie können wir darauf daran arbeiten? Damit arbeiten. Ja, das ist eine große Debatte, die hier drüber läuft. Und leider haben wir das noch nicht gelöst. Wir haben darüber versucht, eine Struktur zu erstellen, die Fähigkeiten und die Eigenschaften zu erstellen, das Ganze zu simulieren, wie das funktionieren kann. Hoffentlich haben wir das Ganze hier schon zeigen können, weil wir haben ein paar Soziologen, wir haben Philosophen dabei, wir haben Kryptografen dabei. Es ist toll, dass wir europäische Projekte haben, die auf Privatsphäre und sichere Kommunikation abziehen und dieses Wissen von den ganzen Teilnehmern aufbauen können. Das ist auch zu offener Innovation. Das ganze Material, was wir erstellt haben, das Quake Code ist offen für die Öffentlichkeit und jeder kann sich anschauen, die Kultur benutzen und andere Applikationen für andere Applikationen verwenden. Und darum können wir diese Claimshands erweitern. Okay, wir haben... Ja, soweit ich weiß, um dieses System zu benutzen, das sind beide, die diese Signature machen, genau wie bei PGB, aber auch die Freunde darum fragen, darum bitten... die Freunde darum bitten, Lesezugreff zu ihrzuhören, sozialen Grafen haben. Es ist nicht noch schwierig, um das System zu benutzen, der Lektor richtig... wir müssen immer noch diesen... despite komplizierten Tänze und Serumonien machen. Wenn du dir sicher sein willst, dass du wirklich die richtigen Aussagen zu einer anderen Person hast, dann kommst du nicht darum herum. Aber wir glauben, dass dieser Mechanism Aber wir glauben, dass dieser Mechanismus von Vorstellungen, dass dieser Mechanismus, ja, wir werden sehen, wie gut er funktioniert. Das hier ist ein Teil unserer Simulation, und was du hier auf der linken Seite siehst, was wir simulieren, ist das komplett dezentralisiertes Szenario. In diesem Szenario hängen wir einfach Vorstellungen an E-Mails an, und wir sehen, dass es eigentlich funktioniert. Wenn man der Person vertraut, die einen jemanden vorstellt, dann können wir eigentlich sagen, dass es funktioniert. Dann haben wir einen guten Stand, dass E-Mails mit den richtigen Schlüsseln verschlüsselt rausgehen. Die Ausdrückstache ist euer Zugriffsmodell. Die wird zurückrufen von Credentials erwendet. Unterstützt ihr, dass das Schreibzugriff delegiert. Ja, das kann man alles tun. Was wir z.B. auch erlauben, ist Sackball-Semantiken. Man kann z.B. grenzwertrevokationen machen. Man kann auf dieser Struktur, die wir haben, aufbauen. Aber das haben wir noch nicht selber implementiert. Das ist Schad 256. Wie schwer wäre das, auszuwechseln, wenn es irgendwann mal kaputtläufig wird? Wir haben eine Claimt-Shame-Version in diesem Block einbauen. Das ist die Struktur. Dann könnten wir das dort anbringen. Ich denke nicht, dass es einfacher wird. Vielen Dank für den tollen Vortrag. Es ist ein Krypto-Anteil davon. Der Schlüssel-Ableitungsprozess. Warum benutzt ihr SHAR-Hash-Funktion, um die Schlüssel abzuleiten? Und nicht in der Key-Schüssel-Ableitung-Schlüssel wie HKDF oder WPKDF? Ich denke, das ist der Einfachheit halber. Aber eine andere Antwort habe ich nicht. Wahrscheinlich ist dein Vorschlag besser. Und sprechen wir doch drüber. Unterhalten ist drüber. Eine Frage aus dem Internet? Ja. Wie ist Privatsphäre des sozialen Gras? Es ist ganze Cross-Hashing bewiesen. Ich habe das noch nicht wirklich verstanden. Die Privatsphäre des sozialen Grafs? Wie beschützen wir sie? Die Privatsphäre des sozialen Grafs? Wie wird die Privatsphäre im Cross-Hashing unterstützt? Wenn wir einen Klaim hinzufügen, dann ist der Inhalt dieses Claims, den wir in den Merken einbauen. Und es gibt keine Informationen über die Beschriftung oder den Inhalt dieses Claims raus. Weil es an diesem Capability-Mechanismus gibt, der nur einer bestimmten Menge von Lesern erlaubt, einen Cross-Hash zu lesen. Ich denke, genau deshalb können wir diese Privatsphäre gewährleisten. Vielen Dank, alle. Wir haben keine Zeit mehr, aber Marijosch wird hier noch ein bisschen länger sein. Dann könnt ihr noch mal mit ihm mit einem Chunk oder einem Pia nachfragen. Vielen Dank, Marijosch.