 Translation Team und wir werden den Talk aus dem englischen Instalt für euch übersetzen. Unser nächster Vortrag beschäftigt sich damit, was man alles falsch machen kann, wenn man Kryptoprimitiven verwendet. Um euch darüber mehr zu erzählen, haben wir Florian und Lukas. Guten Morgen und vielen Dank, dass ihr aufgewacht ist. Wir fühlen uns geerrt, diesen Vortrag nach Daniel Bernstein und Anja Langer. Wir möchten ein paar Punkte herausstellen, die vielleicht in dem Vortrag nicht so ganz klar sind. Wir finden beweisbare Sicherheit gut und Autokolltreich ist ein sehr guter Kryptografer. Wir werden den Talk folgenderweise organisieren. Wir werden zuerst erklären, warum wir das machen. Anschließend werden wir euch Beweise und Modelle zeigen. Und die anschließenden zwei Punkte drehen sich über Sachen, die so passieren können, wenn ihr die ersten zwei anwendet. Zitat von Bruce Schneier, jeder selber der völlig ahnungsloseste Programmierer, der sich mit Krypto beschäftigt, kann einen Algorithmen erschaffen, den er selber nicht knacken kann, das ist nicht hart. Das heißt, das Brech überwinden eines Algorithmus heißt nicht, dass der Algorithmus an sich sicher ist. Lars Knutzen sagt, wenn es vielleicht sicher ist, dann ist es vielleicht nicht sicher. Ich bin mir sicher, er kennt dieses Beispiel, das elektronische Codebook-Mode. Es ist ein Verschlüsselungsverfahren, bei dem ihr jeden Block mit sich selbst kombiniert. Und es ist insofern sicher, als der Output so ausschaut, dass jeder Block anders ausschaut, als der Input-Block. Jedoch ist die Gesamtheit des Outputs nicht ganz das, was wir unter sicherer Verschlüsselung verstehen. Ein bekannteres Beispiel ist der Server-Blocks-Chaining-Mode. Und wir beginnen mit Klartext, der durch den Verschlüsselungsschritt. Wir verwenden den verschlüsselten Text aus einem Block. Wir wenden eine XOR-Transformation an, gemeinsam mit dem Key und erhalten daraus den Klartext. Wenn ihr mehr über CBC erfahren wollt, dann solltet ihr euch den Talk von Hano über TLS 1.3 anschauen. Das Problem damit ist, dazu muss ich aber erzählen, was ORAKL sind. Ein Protokoll, ein ORAKL meint, dass wir einen Teil mehr haben, der einen Input entgegen nimmt, der einen wohldefinierten Output antwortet und der selbst nichts weiter damit anfangen kann. Dieses Verfahren nimmt einen Klartext, nimmt einen verschlüsselten Text als Input, wendet eine Transformation an. Das Anwenden dieses ORAKLs auf den Verschlüsselungsalgorithmus wird uns den Schlüssel zeigen, weil wir aus der Transformation den Schlüssel raten können. Um zu verstehen, ob der Algorithmus sicher ist, müsst ihr verstehen, was der Algorithmus mit dem klar oder ziffer Text macht und dann könnt ihr beweisen, ob der Algorithmus sicher ist oder nicht. Vielleicht habt ihr schon mal vom P nach NP-Problem gehört. Ihr könnt relativ reich werden, wenn ihr die Antwort auf die Frage weist. Und ihr könnt beweisen, dass das sicher ist und zwar auf folgende Weise. Die Frage lautet, ist der String auf der linken Seite eine Verschlüsselung der Ziffer Null und ihr könnt das dadurch beweisen, dass ihr einen String zeigt, der Teil von NP ist. Aber es ist schwierig, dass ohne ein Beispiel zu zeigen, dass nicht Mitglied von NP ist. Wenn ihr es könntet, werdet ihr reich und berühmt. Was tun wir? Das heißt, wir müssen ein paar Annahmen treffen. Florian wird euch jetzt darüber erzählen. Guten Morgen. Viele von euch kennen wahrscheinlich RSA. Ich habe das mal hier angeschrieben, eine kleine Version davon. Es ist relativ bekannt, dass man hier zwei große Primzahlen P und Q haben. Die multipliziert man, kriegt N, dann nimmt man einen Exponenten. Ich habe den einfach mal auf drei gesetzt in diesem Beispiel. Das ist alles, was man braucht für einen öffentlichen Schlüssel. Es ist ein bisschen kompliziert, den geheimen Schlüssel zu bestimmen. Wenn man das hat, dann ist die Verschlüsselung einfach, dass man den Plantex nimmt und hoch E nimmt. Nimmt man durch Modulo N, falls euch nicht erinnert. Das ist einfach, wenn ihr den Rest bei Divisionen durchnimmt. Also alle Beispiele, die wir hier zeigen, werden wahrscheinlich in Modulo drin haben. Die Verschlüsselung ist nicht so besonders schwer hier. Und die Verschlüsselung ist genau das gleiche. Wir nehmen bloß den privaten Schlüssel stattdessen. Das werden wir euch jetzt zwar nicht zeigen, aber das gibt einem das ... ... die übliche den ursprünglichen Text. RSA ist nicht sicher, wenn Primzahlen nicht faktorisierbar sind, sondern es braucht noch etwas stärkeres, nämlich die RSA. Factoring Assumption. Die Annahme ist in etwa, RSA ist sicher, falls er es sicher ist. Aber diese Art und Weise, RSA zu machen, ist tatsächlich nicht sicher. Bloß, weil, dass man nicht den ganzen Plantex extracten kann, heißt nicht, dass man nicht vielleicht den halben Plantex erraten kann. Und das ist natürlich schlecht, weil, wenn man auch nur das erste Beid lesen kann, kann das schon sehr viel bedeuten. Es gibt noch viel mehr Probleme mit RSA, wenn man zum Beispiel kleine Zahlen ... Wie viele Schüsseln möchtest? Dann haben wir ... Falls wir kleine Zahlen verschüsseln, dann können wir einfach eine dritte Wurzel ziehen und dann schauen, ob da was sinnvolles rauskommt. Wenn ja, dann hat man eine kleine Zahl direkt wieder. Ich werde ja eigentlich RSA nicht direkt meinen Zeug verschlüsseln, aber das würde man auch in der Realität machen. Aber wenn man darüber nachdenkt, sagen wir, wir benutzen 256-Bit für IES und wir benutzen nur 1024-Bit für RSA. 256 mal 3 ist immer noch kleiner als 1024. Diese Engriff funktioniert also perfekt. Außerdem ist es deterministisch, falls man eine Idee hat, was der Plantex sein könnte, dann kann man es einfach selber verschüsseln und schauen, ob das richtige rauskommt. Versionen von RSA funktionieren, aber normalerweise ist es relativ schwer, RSA zu benutzen. Die häufige Idee zu signieren, indem man den Text mit dem Secret Key verschlüsselt, aber das funktioniert so nicht. Ich kenne auch keinen Verschlüsselungsverfahren, bei dem das anders ist. Wir schauen uns L-Gamal an und selbst da, wenn man eine schlechte Gruppe wählt, dann hat es große Probleme. Wenn ich ein Bit deines Plantex errate, kann ich den kompletten Klartext re-covern. Und ja, das trifft zu, wenn ich einen zufälligen Input eines Ziffertexts nehme. Wenn ich einen kleinen Pool habe, dann kann ich den Klartext einfach raten. Das Ergebnis ist verletzliche Algorithmen oder verletzliche Implementierungen überall. Daraus folgt, dass wir eine verwendbare Definition brauchen, die uns sagt, was sichere Verschlüsselung tatsächlich ist. Eine alte, leider unbrauchbare Definition ist die semantische Sicherheit. Wenn der verschlüsselte Text und der öffentliche Schlüssel gegeben ist, dann ist es unpraktisch, irgendetwas über den Klartext zu herauszufinden, abgesehen von seiner Länge. Wir können jetzt natürlich etwas sichernennen, wenn es semantische Sicherheit bietet, das Problem dabei ist, das ist uns nicht ausreicht. Wir haben eine zweite Forderung, die nennt sich IND-CPA. Das ist jetzt die Ungangssprachli-Version, aber am Schluss kommt alles trotz, wenn du der Angräfer bist und zwei Stücke Klartext raten kannst. Du kannst das beliebige Stück Klartext dem Verschlüsselten geben, der Verschlüsselte antwortet mit dem verschlüsselten Text. Die Forderung lautet, dass du nicht in der Lage sein darfst, den Klartext daraus herzuleiten. Alles, was bessere Performance als das reine Raten, also eine Wahrscheinlichkeit von 50% liefert, ist ein Problem für die Sicherheit. Leider bringt uns das zum Problem, dass wenn du IND-CPA Sicherheit beweist, hast du bewiesen, dass es nur semantisch sicher ist. Das ist aber nicht ausreichend für das, was du für sichere Verschlüsselung fordern solltest. CBC-Mode liefert uns semantische Sicherheit. Das Padding-Urakel, das heißt also, mit Hilfe des Padding-Attacks, den Klartext herzuleiten, ist nicht Teil der Definitions-Semantische Sicherheit. Eine sehr bemerkenswerte Variante der Angriffe sind Side-Channel-Angriffe. Diese Angriffe können dazu führen, den Verschlüsselung zu erfahren, einfach durch Zeitmessung auf dem Side-Channel. Das bedeutet für uns, dass wenn ein Verschlüsselungsverfahren an sich sicher ist, reicht uns das nicht. Es muss auch sicher sein gegen andere Formen der Angriffe. Und wenn wir auch das in unsere Definition einbauen, dann erhalten wir eine Definition, die wir als sicher betrachten können. Wir spielen jetzt reduzieren. Wir können keine absoluten Beweise führen, die ohne Annahmen ausführen. Das heißt, wir brauchen eine Reihe Annahmen. Und Annahmen formulieren wir in der Art eines Spiels. Das Spiel schaut so aus, dass wir eine Aufgabe definieren. Zum Beispiel, das kann die Aufgabe lauten. Hier ist ein mit RSA verschlüsselter Text. Die Aufgabe lautet, gibt mir den Klartext zurück. Zum Beispiel könnte ein Angreifer auf das, nach dem Int-CPA Beweis, dieses Spiel mitzuspielen, indem er die ausgesprochene Herausforderung nach den Regeln des Spiels zurückliefert. Wir müssen die Annahmen so definieren, dass die Annahmen an sich nicht angreifbar sind. Wir gehen davon aus, dass das Schema an sich angegriffen werden muss. Und das konkret zu betrachten, werden wir jetzt ein Verschlüsselungsverfahren namens Eljamal betrachten, von dem wir annehmen, dass es bei Design sicher ist. Wir beginnen mit P und Q als Prim-Zahlen mit speziellen Eigenschaften. P muss zweimal Q plus 1 sein und Q muss größer 2 sein. Wir werden die Gründe dafür nicht erklären. Wir brauchen einen Generator, den wir G nennen. Den definieren wir als 4. Jetzt führen wir verschiedene Operationen auf die Exponente durch. Unsere Exponenten sind Modulo Q. Wir führen Operationen auf die Basis durch, die immer Modulo P sein müssen. Um das Mathematisch sauber darzustellen, definieren wir ZQ als die Menge von 0,1 bis Q minus 1. Eljamal funktioniert so, dass ein Schlüssel erzeugt wird. Der Key-Generator wird sich einen zufälligen Exponenten aus der Menge ZQ aussuchen und anschließend G hoch X ausrechnen. Und das Ergebnis davon ist der öffentliche Schlüssel. Wir gehen davon aus, dass die Umkehrfunktion von G hoch X unpraktisch schwierig auszurechnen ist. Deswegen gehen wir davon aus, dass es schwer anzugreifen ist. Die Verschlüsselung an sich ist unpraktisch, aber durchführbar. Wir wählen ein zufälliges R aus ZQ und jedes für jeden Verschlüsselungsvorgang wählen wir ein anderes A. Wir wählen G hoch R, dann wählen wir den öffentlichen Schlüssel G hoch X und rechnen G hoch R und anschließend multiplizieren wir mit dem Klartext M. Mehr müsst ihr nicht tun, um das mit Eljamal zu verschlüsseln. Schließlich die Endschlüsselung. Wir nehmen den resultierten verschlüsselten Text G hoch R, G hoch X hoch R mal M. Wir transformieren den in der Weise, dass wir das Verfahren praktisch umdrehen in G hoch R X mal M mal G hoch R hoch minus X. Das gibt uns nach der Transformation M mal G hoch R X minus R X. Das ist also gar nicht so schwierig. Wir brauchen trotzdem noch eine Annahme, auf deren Basis wir beweisen können, dass Eljamal sicher ist. Wir definieren nun die DDH-Annahme ein und die Alme lautet, dass für ein beliebiges X, Y und Z aus der Menge ZQ soll gelten. Das G hoch X, G hoch Y, G hoch Z, dass wir zu einem Diffel Hermann-Triebel sagen können, ob es ein echtes Diffel Hermann-Triebel ist. Um das jetzt zu beweisen, benutzen wir die Spielstruktur, die wir vorhin gesehen haben. So sieht die Struktur aus. Wir kriegen einen Triepel zum Übersetzer und am Ende kriegen wir ein B und was sagt, ob das ein echtes Diffel Hermann-Triebel ist. So, hier sehen wir einen öffentlichen Diffel G hoch X zum Eljamal-Angreifer. Dann kriegen wir M0 und M1 als mögliche ... ... mögliche Plaintexte, dann wählen wir jetzt zufällig einen davon aus ... ... und dann nehmen wir G hoch Y statt G hoch X und G hoch Z anstatt G hoch RX. Also es ist gleiche bloß, halt modifiziert. Das sieht so aus wie ein Eljamal-Cyphertext. Und dann schauen wir uns ... ... dann kann uns irgendwas tun und am Ende kriegen wir ein B Strich. Darüber wissen wir dann, welcher der beiden Plaintexte ... ... ausgewählt worden ist. Und dann geben wir das einfach wieder weiter und dann haben wir geraten, ob es richtig ist. Also sagen wir, der Angreifer hat eine Erfolgsrate von 1,5 plus Epsilon. 1,5 ist zufälliges Raten. Und wenn der Angreifer besser als zufällig ist, dann gibt es 1,5 plus Epsilon. Falls X mal Y gleich Z ist, dann ist es perfekt. Wir haben G hoch X, ist zufällig, G hoch Y auch volllich zufällig. Hier ist G hoch Z gleich G hoch X hoch Y. Perfekt in der Simulation. Also kriegen wir hier einfach die Erfolgs-Wahrscheinlichkeit des Angreifers. Falls das nicht der Fall ist, dann hat G hoch Z nichts mit G hoch X mal Y zu tun. Das heißt, der verstöckelte Text wird auch keine Korrelation zu irgendeinem, der beiden Plaintextes hat. Das heißt, hier kriegen wir bloß eine Erfolgsrate von 1,5. Weil beides ungefähr ... Weil beides 1,5-Wahrscheinlichkeit hat, sehen wir, dass wir am Ende 1,5 plus Epsilon halber ausbekommen. Das heißt, wenn wir einen Elgamal-Angreifer haben, dann kriegen wir daraus einen Elgamal für die Defi-Hermann-Assumption. Und dann kriegen wir, falls Epsilon nicht vernachlässigbar ist, dann ist Epsilon halber auch nicht vernachlässigbar. Das heißt, wir kriegen auf diese Art und Weise einen Defi-Hermann-Assumption. Das heißt, andersrum, wenn wir annehmen, dass Defi-Hermann sicher ist in diesem Respekt, dann wissen wir auch, dass Elgamal sicher ist. So, was kriegen wir daraus? Naja, es ist ein bisschen komisch, diese Annahme, aber was kriegen wir daraus? Aber wir sehen, dass die Annahme ein bisschen weniger komplex ist, aber nicht viel. Hier, hier seht ihr eine alte Version des TLS-Handshakes. Was ihr hier seht, ist wahrscheinlich zu kompliziert, um es zu sehen, weil es zu klein ist, aber das ist gerade der Punkt, den ich machen möchte. Falls die Sicherheit hier von reduzieren kann auf eine simplen Annahme, dann ist das eine gute Sache. Es gibt viele Sachen, die auf die DDH-Assumption... Annahme, und was uns das gibt, ist, dass jeder auf die DDH-Annahme gehen kann. Und so sind entweder alle Schematah kaputt oder keins. Gestern wurde über Post-Quantum-Kryptografie geredet, und solche Schematah hier können helfen, um alles zu widerlegen. Wenn man mehrere Annahme hat, dann ist es vielleicht... Dann ist das komisch, weil wenn man mehrere Sachen, falls man mehrere Dinge kombiniert, dann kann man durch diese Reduktion zeigen, dass man keine zusätzlichen Verwundbarkeiten eingeführt hat. Also, zurück zu der Definition von Sicherheit. Was ihr gerade gesehen habt, war ein Spielbasierterbeweis. Es ist relativ intuitiv. Diese Art sind normalerweise einfacher als die Alternative. Es gibt Ausnahmen, aber sie haben häufig weniger intuitive Bedeutung. Ich habe nur eine kurze Definition von NCBDA und anderer Sicherheit gegeben. NCBDA war ein bisschen komisch, aber simantisch Sicherheit war relativ klar. Das heißt, spieldefinierte Definitionen sind manchmal ein bisschen komplizierter und schwerer zu verstehen, was sie tatsächlich bedeuten. Ab irgendeinem Punkt skalieren die aber nicht mehr gut, und das ist die simulationsbasierten Beweise. Wir definieren da eine ideale Funktionalität mit einem vertrauten Teilnehmer. Dann schauen wir, dass die Verbindung zu allen komplett sicher ist. Falls sie komplett genau so sicher sind wie ein eigenes Protokoll, dann haben wir einen klaren Beweis. Das sind normalerweise ein bisschen intuitiver, aber leider sind sie auch etwas schwerer durchzuführen. Insbesondere bei denen, wobei das vielleicht daran liegt, dass die Scheme hat, die man beweist, komplizierter sind, werden auch die Beweise komplizierter. Gibt es manchmal Beweis-Aterfakte, zum Beispiel öffentliche Schlüssel, für die niemand einen geheimen Schlüssel hat? Das klingt komisch, aber manchmal sind sie doch sinnvoll. Es ist zwar unklar, warum, aber manchmal sind sie doch wichtig. Am Anfang habe ich RSA erwähnt, und habe auch erwähnt, dass es sichere Versionen von RSA gibt, dass sie aber etwas mehr Arbeit erfordern. Hedge Functions sind ein wesentlicher Bestandteil dieser zusätzlichen Komplexität. Hedge Functions transformieren eine Zeichenkette beliebiger Länge in eine zufällig ausschauende Zeichenkette fester Länge, die kompliziert ausschauen, ich sage, dass sie kompliziert ausschauen oder dass sie zufällig ausfallen. Hedge Funktionen ist gemein, dass sie einfach ausschauen, aber wirklich kompliziert sind. Ein paar der Probleme, die wir mit Hedge Funktionen haben, sind, dass die Probleme nicht mit den Standard verfahren, sondern auf den eher seltsamen Eigenschaften. Wenn wir uns Hedge Funktionen nähern wollen, verwenden wir ein Zufallsurakel. Wir definieren einen Zwerg, der Zwerg lebt in einer Schachtel, und den Zwerg kann man was fragen. Man kann ihm einen Hesch geben, und der Zwerg wird verlässlich immer dieselbe Antwort auf dieselbe Frage geben. Für den Fall, dass er die Frage noch nie gesehen hat, wird er eine zufällige Zahl als Antwort liefern. Das einzige Problem dabei ist, dass noch niemand eine solche Schachtel mit diesem speziellen Zwerg drin gefunden hat. Es wäre zwar schön, wenn man jedes Mal, wenn man einen Hesch wollte, immer zum Zwerg gehen könnte. Und das wirkliche Problem dabei ist aber, dass es keine gültige Absraktion, eine Heschfunktion ist. Ich werde euch jetzt gleich zeigen, was das Problem damit ist. Gehen wir davon aus, dass wir einen sicheren Verschlüsselungsverfahren haben. Und gehen wir davon aus, dass H entweder eine Heschfunktion sei oder ein Zufallsurakel. Dann verwenden wir den Schlüsselerzeugungsalgorithmus von vorhin, der einen Schlüsselpaar zeugt. Und wir verwenden den Secret Key, um eine verschlüsselte Nachricht zu erzeugen. Wir verändern die Verschlüsselung wie folgt, wenn die Nachricht M wie Programmcode ausschaut, dann für den Code aus auf den gelieferten zufälligen Input X. Wenn das Ergebnis der Ausführung der Evaluierung von M von X ungleich dem Verschlüsselungsergebnis von H von X ist, dann nimmt nur den Verschlüsselungstext, sonst verwendet den geheimen Schlüssel als Schlüsseltext. Das klingt jetzt extrem komisch, aber ihr werdet gleich sehen, dass für ein Zufallsurakel ein sicheres Verfahren der Verschlüsselung ist, dass es aber ein unsicheres Verschlüsselungsverfahren ist, wenn ihr eine Heschfunktion verwendet. Der Grund dafür liegt darin, dass das Orakel zuverlässig einen Zufallswert zurückliefert, wenn es eine Frage sieht, die es vorher noch nie gesehen hat. Das trifft leider auf eine Heschfunktion nicht zu. In diesen Fällen würde man von der Heschfunktion den geheimen Schlüssel zurück erhalten. Deswegen können wir daraus schließen, dass die Verwendung einer Heschfunktion in dieser Art der Verschlüsselung zu einem unsicheren Algorithmus führt. Dazu zitieren wir Goldreich. Es sollte klar sein, dass die Methode des Zufallsurakels nicht sicher ist, dass tatsächlich das, was dem Zufallsurakel passiert, erinnert uns an die biblische Geschichte der bronzenden Schlange. Die Geschichte erzählt uns von dem Verfahren, in dem eine Ansicht gute Sache, ein Fetisch, ein Idol werden könnte und was, wie wir uns in einem solchen Verhalten verhalten sollten. Wiederum andere haben dazu gesagt, wenn einer der führenden Experten der Welt sein volles Wissen einsetzt, um die Gültigkeit dieses Orakels in Frage zu stellen und wenn diese schadhafte Annahme das beste Ergebnis ist, zu dem er kommen kann, dann ist vielleicht Zuversicht darin erlaubt, das Zufallsurakelmodell für sich zu halten. Das alles führt dazu, dass wir am liebsten das Zufallsurakelmodell loswerden würden. Also, was haben sich die Leute einfallen lassen? Sie haben sich einen Verfahren einfallen lassen, indem das Zufallsurakelmodell keine Rolle mehr spielte, aber dafür andere Seltsamkeiten aufwiesen. Wie zum Beispiel die Boniboyen Signatures. H hoch X versus R von Gerre und einen sehr komplizierten Exponenten. Vielleicht ist das für deinen speziellen Anwendungsfall kein Problem, aber du musst dir klar darüber sein, dass es im Prinzip passieren kann, wenn du diese Typen von Signaturen verwendest. Ein anderes Beispiel dieser Signature-Probleme ist, dass man im einfachen Modell zwei Komponenten hat und im zweiten Verfahren eine schwierig auszurechnende mathematische Formel hat. Wo die Wahrscheinlichkeit, dass ein Programmierer das mathematisch-falsch Abbild sehr hoch ist, was dann dazu führt, dass der Algorithmus an sich schwach wird. Das heißt, wir haben jetzt also zwei Alternativen. Wir können entweder das einfache Verfahren wählen, das zuverlässig zu implementieren ist oder wir können das komplizierte Verfahren, das an sich sicher ist, aber schwierig zu implementieren ist, wählen. Mit einer Höhenwahrscheinlichkeit ist durch die Implementierung zu schwächen. Das führt uns zum nächsten Verfahren, wie wir zu beweisen versuchen, ob ein Verfahren sicher ist oder nicht. Wir begegnen wieder Alice und Bob und Alice wählt R zufällig. Als Beispiel wird Alice eine Nachricht verschlüsseln, den Inhalt der Nachricht aber nicht mitteilen. Als Beispiel schreibt Alice ihren Klartez auf, schmeißt den Geldschrank, sperrt zu, gibt Bob den Geldschrank, wenn Bob die Kombination weiß, kann er den Schlüsseltext ableiten. Unsere anderen sind hier. Sobald Alice die Nachricht verschlüsselt, also den Save zugesperrt hat, sollte sie nicht in der Lage sein, im Falle Commitment Selbstverpflichtung M wieder zu ändern. Und zweitens, Bob darf nicht in der Lage sein, aus C irgendetwas über M abzuleiten. Das eine nennen wir Commit Selbstverpflichtung, das andere nennen wir Anvil. Nehmen wir also an, wir haben jetzt dieses sichere Verfahren und daraus bauen wir jetzt wieder ein etwas komplizierteres Verfahren. Wir wollen wissen, ob eine Nachricht die Alice ausgewählt hat, größer ist als eine andere Nachricht die Alice ausgewählt hat. Alice schickt die Nachricht C an Bob, Bob schickt C Strich zurück, Alice schickt M und R an Bob und Bob schickt M und R Strich zurück. Nun haben wir das Problem, dass der böswillige Mallory am Spielteil nimmt, der auch wieder C und MR empfängt. Jedoch böswillig wird er antworten mit veränderten Werten, nämlich als Antwort auf C, C Strich als G mal C und als Antwort auf MR als M plus 1, R. Ein falsches Verhalten in diesem Fall kann dazu führen, dass unser Protokoll beweisbar schwach wird. Was wir möchten ist, dass die Definitionen von Sicherheit alle vorstellbaren Eigenschaften abdecken und dass ein Verfahren sicher sein soll, unabhängig von den Umweltfaktoren oder Einwirkungen. Um das zu tun, verwenden wir wieder diese Simulations- oder Spielbasierten Beweisverfahren und dafür verwenden wir eine der Funktionen, die Florian Feuer eingeführt hat und wir verwenden sie in einer Umgebung, die überhaupt nichts mit dem Protokoll zu tun hat. Wir gehen davon aus, dass unser Verfahren nicht in der Lage sein wird, mit der realen Fall, dem idealen Fall gegenüber und wir haben eine vertrauenswürdige Instanz, der wir einen Importwert übergeben. Im wirklichen Fall werden die Beteiligten das Protokoll verwenden, um das Ergebnis zu kalkulieren, was sie womit wir uns gegenüber sehen, im realen Fall ist, dass böswegelige Angreifer das Protokoll verändern können oder unter Umständen auch auf beteiligte Verfahrensbeteiligte einwirken könnten, um das Ergebnis zu verändern. Im anderen Idealfall verwenden wir, dass es in einer beliebigen Umgebung nicht möglich ist, in welcher der beiden Welten es lebt. Wie sieht so eine Funktionalität aus? Wir schauen uns dafür Commitments an, Alice kann die Message reintun, dann sagt die Funktionalität, dass Alice zu Bob das alles committed hat und dann kann man irgendwann sagen, dass die Nachricht enthüllt werden soll und dann kriegt Bob die Nachricht. Dann schauen wir uns das mal anders an. Dann sehen wir hier dieses Commitment, dann wird der kompiertes Sender dieses Commitments weitergeben, dann wird es weitergegeben, die Entfüllung und dann kriegt der Empfänger, der kann einfach die Nachricht beantworten. Dann ist der Simulator auf der guten Seite und der arbeitet zusammen mit der unnetten Party, dann haben wir hier das falsche Commitment und das geht weiter, die ideale Funktionalität ist verwirrt, weil wir kriegen hier irgendwie eine Nachricht stattdessen. Wir könnten jetzt anschauen, die Nachricht von diesem Commitment rauszukriegen, aber das würde die Sicherheit kaputt machen. Das heißt, es kann keinen Commitment geben, was diese ideale Funktionalität geben kann. Das ist doof, weil wir denken, dass es sichere Commitments geben gibt. Also was ist eine vernünftige Definition, vernünftige Lösung für das? Wir könnten natürlich ein Backdoor, wir könnten einen Common Reference String einführen. Das ist ein zufälliges, aus einer Verteilung zufällig ausgewählten Verteilung, aber das existiert nur in der realen Welt. Nehmen wir also an, dass unser Common Reference String der Public Key ist und die zwei Generatoren, so dass der Public Key zufällig gewählt worden ist und der geheimisch das nicht zufällig gewählt, niemand den kennt, dann kann alles das gleiche Commitments geben benutzen. Sie verschüsselt die Nachricht mit dem Public Key, sie beweist mit magischer Kryptografie, dass die Nachricht in beiden das gleiche ist und nimmt das als Commitment. Der Simulator kann den Common Reference String nehmen, aber er nimmt das nicht von irgendeiner Distribution, sondern nimmt die realen Generationsalgorithmus, aber er macht das so, dass er dann auch einen privaten Key rauskriegt und jetzt kann er die Message Bits rausnehmen aus den Commitments und es in die ideale Funktionalität tun. So dass wir den Common Reference String dieses Verfahren als sicher beweisen können, das heißt, als wir ECD-Ampg gegeben haben, wollten sie uns vielleicht nicht nachschlüffeln, sondern vielleicht helfen bei Beweisen. Das Problem ist, diese Common Reference Strings sind halt leider backdoor. Das Einzige, was ein Common Reference String benutzt hat, das war bei CCash, es ist vermutlich gut, aber es muss und, es muss nicht unterscheidbar sein, aber ob das so ist, keine Ahnung, in anderen Szenarien gibt es, könnte man zum Beispiel nichts in meinem Ärmel zahlen, die nutzen irgendwelche Sachen, die in jedem Fall, in jedem Fall müssen wir davon ausgehen, dass niemand den Diskretenlogarithmus ausrechnen kann oder einfach nur kennt von dieser Zeit. Da nehmen wir einfach, die haben einfach Drei genommen und durch S3 gejagt und das ist schon plausibel, dass es so funktioniert. Die erste Regel, die wir hier raus tragen wollen, ist nicht, euren eigenen Krypto zu rollen. Selbst wenn man es schafft, ein Schema in einem Modell als sicher beweisen kann, mag es immer noch nicht sicher sein in der realen Welt. Sicherheit ist schwer und wenn ihr es tut, dann macht wenigstens Beweise und seid euch bewusst über die Shortcomings. Kein random oracle Modell ist zwar nicht richtig, aber es gab doch keinen Verschlußungserfahren, was so bewiesen worden ist und dann gebrochen worden ist. Falls eure Beweise zu kompliziert sind, ist es damit andere Leute zu lesen, dann lesen sie sie vielleicht einfach nicht und das heißt, schreibt lieber einfache Beweise, denn die sind, damit überzeugt man mehr Leute, weil mehr Leute sie verstehen. Mit allen diesen Sachen gesagt, würden wir jetzt gerne Fragen von euch nehmen. Vielen Dank für diesen tollen Gespräch. Wir haben Mikrofonen in der Saal hier, also bitte nach hinten. Um es zu starten, haben wir eine Frage von der Internet. Okay. Könntest du uns bitte erklären, warum du so viel Zutrauen in die DDH-Annahmen hast? Naja, also zum einen, die Leute schauen sich das sehr lange an und wenn Leute sich das schon ganz lange angeschaut haben und niemand was gefunden hat, dann ist es vielleicht sicher. Es gibt noch ein anderes Argument. Es gibt nämlich noch das generische Groupmodell. Es formulisiert diese mathematischen Konzepte. Ich habe euch jetzt bloß eine sehr technische Definition des RGMA-Schemas gegeben. Es gibt tatsächlich eine Art und Weise, in der Mittelsgruppentheorie zu definieren und dann wird es deutlich einfacher. Und dann sieht man, wie man das im generischen Gruppenmodell macht. In diesem generischen Gruppenmodell sieht man dann, dass es nichts gibt, wenn man die Gruppenstruktur erkennt. Das heißt, es kann keinen generischen Angriff geben, aber es kann natürlich einen nicht generischen Angriff geben. Das heißt, mit elektrischen Kurven ist, mit elektrischen Kurven kann man das einfacher machen. Das heißt, sobald man ein Computer macht, ist alles kaputt. Danke für deinen Vortrag. Meine Frage ist, glaubst du, dass einem Beweis im Zufallsoragtemodell zuführen, wäre am Ende erweiterbar auf ein Verfahren, dass weniger schadhaft als das randomoragtemodell ist? Ja, am Anfang beweist man sein Modell im randomoragtemodell. Aber wir haben die Resultate gesehen. Man muss etwas ändern im Protokoll, um das randomoragtemodell zu entfernen. Das macht das sehr kompliziert und kann komische Eigenschaften hervorrufen. Was zeigt die letzte Slide? Das ist die Bonus-Fulde. Ich glaube, wir haben noch 4 Minuten Zeit. Das sollte genug sein. Hier kommt man häufig zur Idee, dass es einen Sicherheitslevel gibt, der genug ist. Es gibt da einfach fundamental verschiedene Sachen von Sicherheit. Das erste, worüber Leute nachdenken, ist berechenbare Sicherheit. Das heißt, falls ich den Angreifer einen gegebenen Anzahl an Zeit gebe, sollte es dem Angreifer nicht möglich sein, dass Brutforce physisch nicht möglich ist. 128-Bit war vollkommen genug. Es gibt auch statistische Sicherheit. Das ist an sich viel besser. Hier ist nicht die Frage, wie viel Rechenkraft der Gegner hat, sondern wie viel Glück er hat. Das ist eigentlich viel besser. Falls man eine 1.000-Chance hat, einen Schlüssel zu kriegen mit Brutforce. Das heißt, man kriegt die Schlüssel nur in 1.000-Chance. Das heißt, vielleicht kriegen wir bloß 40-Bits von 40-Bits in statistische Sicherheit. Das ist weniger, aber vielleicht nicht furchtbar. Perfekte Sicherheit ist komplett sicher. Es ist vollkommen unmöglich zu brechen, selbst mit Glück nicht. Da gibt es für jeden plaintext, für jeden ciphertext, gibt es einen plaintext. In dem plaintext gibt es ein Schlüssel, der den ciphertext in den plaintext umwandelt. Ich denke, wir können noch eine weitere Frage nehmen. Nein, keine Fragen. Dann eine Runde Applaus für die beiden.