1 00:00:00,000 --> 00:00:14,660 *34C3 Vorspannmusik* 2 00:00:15,680 --> 00:00:19,420 Herald-Engel: So. In unserem nächsten Vortrag lernt ihr etwas darüber, was 3 00:00:19,420 --> 00:00:23,930 passiert, wenn das tolle TPM und das tolle Intel ME dann doch irgendwie nicht so toll 4 00:00:23,930 --> 00:00:29,310 sind und was denn schief gehen kann, wenn man seine Keys auf so nem TPM 5 00:00:29,310 --> 00:00:35,180 initialisieren will. Dazu helfen euch jetzt gleich die Herrn Professoren 6 00:00:35,180 --> 00:00:41,030 Doktoren Weis und Forler weiter, bitte einen schönen Applaus! 7 00:00:41,030 --> 00:00:46,290 *Applaus* 8 00:00:47,870 --> 00:00:51,910 Ruediger Weis: So, also herzlichen Dank für die nette Einführung, auch herzlichen 9 00:00:51,910 --> 00:00:59,040 Dank für die zahlreichen Zuhörenden. Es wird heute ein Vortrag, wo ich ein 10 00:00:59,040 --> 00:01:03,920 bisschen auch mit dem Kollegen Forler von der Realität irgendwie auch ein bisschen 11 00:01:03,920 --> 00:01:08,579 massiv gerempelt worden bin. Eigentlich war unsere Intention, wirklich zu 12 00:01:08,579 --> 00:01:14,210 diskutieren, wie macht man Kryptographie robuster, und auch in einem feindlichen 13 00:01:14,210 --> 00:01:19,740 Umfeld. Und ich hab gelernt ein neues Buzzwort: riesa...lienzte? 14 00:01:19,740 --> 00:01:23,130 *lacht* Kryptographie war eigentlich wirklich als 15 00:01:23,130 --> 00:01:29,230 Titel geplant, jedoch müssen wir, glaube ich, wegen der realen Entwicklung noch ein 16 00:01:29,230 --> 00:01:35,700 paar Einordnungen gleich am Anfang machen. Also zunächst mal die übliche gute 17 00:01:35,700 --> 00:01:39,950 Nachricht, die ich auch immer gern bring: wissenschaftlich starke Kryptographie ist 18 00:01:39,950 --> 00:01:44,249 selbst gegen übermächtige Geheimdienstgegner wahrscheinlich das 19 00:01:44,249 --> 00:01:50,140 Einzige, was überhaupt hält, aber es hält. Also wir haben einigermaßen die Sachen 20 00:01:50,140 --> 00:01:53,919 verstanden, die Sachen, die freundlicherweise im Zusammenhang mit der 21 00:01:53,919 --> 00:01:59,009 Snowden-Geschichte veröffentlicht wurden, zeigten auch, dass die Kryptographen in 22 00:01:59,009 --> 00:02:06,009 der NSA mit Wasser kochen und da gab es eigentlich für die großen Mengen Geld, die 23 00:02:06,009 --> 00:02:11,050 da rein geworfen wird, relativ wenig Überraschungen da. Also man kann sagen, 24 00:02:11,050 --> 00:02:14,900 Krypto hält, oder um's mal ein bisschen lyrischer von Bruce Schneier zu machen: 25 00:02:14,900 --> 00:02:19,160 "Vertraue auf die Mathematik, Verschlüsselung ist dein Freund". Also 26 00:02:19,160 --> 00:02:23,780 insofern eigentlich eine ganz gute Situation, bis diese gute Situation auf 27 00:02:23,780 --> 00:02:31,030 die reale Welt kommt. Wir Kryptographen können wirklich eine Art Magie entwickeln. 28 00:02:31,030 --> 00:02:34,670 Wir können mit ein paar Bits, die man sicher speichert, wirklich sicher gegen 29 00:02:34,670 --> 00:02:40,950 alle möglichen Angriffe bestehen. Das Problem ist, wenn diese paar wenigen Bits 30 00:02:40,950 --> 00:02:45,680 aber nimmer sicher sind, dann können wir halt gar nichts mehr machen. Und man kann 31 00:02:45,680 --> 00:02:49,360 es auch, wenn man es ein bisl modell- theoretisch macht, kann man auch sagen, na 32 00:02:49,360 --> 00:02:54,040 ja, irgendwas muss die berechtigten Kommunikations-Partner von den Angreifern 33 00:02:54,040 --> 00:02:57,470 unterscheiden. Und das Kleinste, was wir anbieten können, sind ein paar wenige 34 00:02:57,470 --> 00:03:00,510 Bits, die sicher gespeichert werden müssen. Weniger können wir nicht machen. 35 00:03:00,510 --> 00:03:04,760 Also wir sind mit unserem Latein nicht am Ende, aber eigentlich schon in der 36 00:03:04,760 --> 00:03:08,430 Situation, wo wir gesagt haben, OK passt auf ein paar Bits auf, mehr können wir 37 00:03:08,430 --> 00:03:13,230 nicht für euch tun. Und genau das ist das, was ja im Moment episch uns um die Ohren 38 00:03:13,230 --> 00:03:17,820 fliegt. Also es gab hier auch schon einen sehr interessanten Vortrag, deswegen will 39 00:03:17,820 --> 00:03:22,040 ich auch gar nicht so arg ins Detail zu gehen, aber der Titel ist einfach zu 40 00:03:22,040 --> 00:03:27,020 schön: "How to hack a turned off computer", oder dass man beliebigen Code 41 00:03:27,020 --> 00:03:32,910 ausführt auf dieser Management Engine. Und diese Management Engine ist relativ 42 00:03:32,910 --> 00:03:39,460 spannende Geschichte, insbesondere für meine Forschungsarbeiten ganz interessant, 43 00:03:39,460 --> 00:03:45,069 weil Dank der Intel Management Engine kann ich auf die lästerliche Frage, wo mich 44 00:03:45,069 --> 00:03:48,890 eigentlich Leute schon seit Jahrzehnten immer.. naja, seit anderthalb Jahrzehnten, 45 00:03:48,890 --> 00:03:53,000 damit aufziehen: "Wann ist endlich das Jahr von Minix auf dem Desktop?" kann ich 46 00:03:53,000 --> 00:03:57,320 inzwischen freundlich grinsen und sag: "Seit 2012 ist es IN deinem Desktop und 47 00:03:57,320 --> 00:04:02,150 niemand hat's gemerkt". Also diese Management Engine läuft in der Tat auf 48 00:04:02,150 --> 00:04:07,840 diesem Minix 3, was ein akademisches Projekt, das irgendwie über Jahre halt 49 00:04:07,840 --> 00:04:11,850 niemand benutzt hat, und jetzt bin ich auch im Minix Steering Committee und wir 50 00:04:11,850 --> 00:04:15,240 waren ziemlich traurig, dass wenig Beteiligung letztes Jahr von der Konferenz 51 00:04:15,240 --> 00:04:19,680 war, bis wir dann mitgekriegt haben, dass das Minix, was wir da entwickelt haben, 52 00:04:19,680 --> 00:04:24,580 wirklich auf allen Intel-Plattformen läuft und damit ist wirklich diese lästerliche 53 00:04:24,580 --> 00:04:28,930 Bemerkung, dass Minix auf mehr Rechnern läuft - auf Windows als auch Mac, weil 54 00:04:28,930 --> 00:04:34,139 auch Mac haben die Intel-Hardware und diese selbe ME-Geschichte drin - ein ganz 55 00:04:34,139 --> 00:04:40,189 witziges Detail, aber wie gesagt, bei den witzigen Detail ist natürlich das 56 00:04:40,189 --> 00:04:46,219 Hauptproblem da, wenn das nicht ordentlich gemacht worden ist, dann können da 57 00:04:46,219 --> 00:04:49,759 Sicherheitslücken kommen. Und offensichtlich ist es so, dass die zwar 58 00:04:49,759 --> 00:04:55,159 dieses Minix genommen haben, das steht aber halt unter einer freien Lizenz und 59 00:04:55,159 --> 00:04:59,280 nicht GPL, und dann natürlich die ihre Arbeiten und Modifikationen nicht 60 00:04:59,280 --> 00:05:02,620 veröffentlicht haben und sich offensichtlich nicht gut genug damit 61 00:05:02,620 --> 00:05:06,560 auskennen, das einigermaßen sicher zu machen. Minix ist ein militant auf 62 00:05:06,560 --> 00:05:10,329 Sicherheit getrimmtes System, das hat so Inflexibilitäten, z.B. dass alle 63 00:05:10,329 --> 00:05:15,660 Nachrichten für eine gewisse Prozessorarchitektur genau 24 Byte lang 64 00:05:15,660 --> 00:05:20,049 sind. Also es gibt sehr wenig Angriffsvektoren, die wir da haben. Und es 65 00:05:20,049 --> 00:05:24,389 ist ein Microkernel-System, ich weiß nicht genau, wie die genaue Code-Entwicklung 66 00:05:24,389 --> 00:05:30,469 ist, aber in der Anfangszeit waren wir da bei unter 10.000 lines of code. Und das 67 00:05:30,469 --> 00:05:34,539 ist auch wieder ein schöner Moment, wo man als Betriebssystem-Professor relativ 68 00:05:34,539 --> 00:05:40,371 einfach die Welt erklären kann. Linux hat inzwischen 10 oder 20 Millionen Zeilen of 69 00:05:40,371 --> 00:05:45,360 code. Windows irgendwie 100 Millionen - frag mich nicht. Und es ist auch so ein 70 00:05:45,360 --> 00:05:50,430 Lemma, dass man sagt, alle 1000 Programm- Zeilen gibt es einen Fehler. Und jetzt 71 00:05:50,430 --> 00:05:54,639 können wir ausrechnen: das ist bei Minix halt 20.000 Fehler, äh bei Linux 20.000 72 00:05:54,639 --> 00:05:57,819 Fehler und bei Minix vielleicht eine Handvoll Fehler, und da könnte man 73 00:05:57,819 --> 00:06:03,059 eigentlich vorbeigehen und das anschauen. Kleines weiteres Lemma: wie problematisch 74 00:06:03,059 --> 00:06:06,360 sind Fehler? Da ist die Antwort, wenn man mit C programmiert, kann man davon 75 00:06:06,360 --> 00:06:10,229 ausgehen, dass ein Fehler mit hoher Wahrscheinlichkeit echte Schmerzen 76 00:06:10,229 --> 00:06:17,240 verursacht. Also die Gruppe der Sachen, der Fehler, die wirklich zu ignorieren 77 00:06:17,240 --> 00:06:21,919 sind - oder ignoriert werden können - sind bei C deutlich geringer als bei anderen 78 00:06:21,919 --> 00:06:26,781 Systemen. Insofern sage ich also, die reine Information, dass Minix ein sehr 79 00:06:26,781 --> 00:06:30,740 kleines System ist, das so klein ist, dass man es so wunderbar in einer Vorlesung 80 00:06:30,740 --> 00:06:36,580 erklären kann, ist wirklich direkt verbunden mit der Sicherheit. OK. Neben 81 00:06:36,580 --> 00:06:40,819 diesem Problem, das wir halt Ärger auf der untersten Ebene haben, war ein anderes 82 00:06:40,819 --> 00:06:45,060 Ding, das wir über Jahre lang auch verfolgt haben, diese TPM-Diskussion, und 83 00:06:45,060 --> 00:06:51,300 hier gibt es wieder was sehr Bizarres. Hier, wer ein RSA verwendet, wer 84 00:06:51,300 --> 00:06:55,919 vielleicht meine alten Diskussionen mit RSA und ECC kennt, weiß, dass ich RSA 85 00:06:55,919 --> 00:07:00,589 eigentlich ganz, ganz, ganz gern hab und das hat auch eine Reihe von Gründen, nämlich es 86 00:07:00,589 --> 00:07:05,259 gibt Sicherheitsbeweise, wirklich harte Sicherheitsbeweise, es ist verstandene 87 00:07:05,259 --> 00:07:10,450 Mathematik. Und es ist eine relativ kurze Implementierung, wo man doch nicht allzu 88 00:07:10,450 --> 00:07:14,360 viel falsch machen kann. Und da das, sage ich, immer noch ein bisschen ne Hacker- 89 00:07:14,360 --> 00:07:18,569 Konferenz ist, seien mir auch ein paar Sachen hier erlaubt. Zunächst mal, was ist 90 00:07:18,569 --> 00:07:23,829 RSA? Wir brauchen Primzahlen. Wenn wir 2048-bit-Schlüssel haben, brauchen wir 91 00:07:23,829 --> 00:07:28,409 1024 Bit lange Primzahlen, die multipliziert man. Erste Frage an den 92 00:07:28,409 --> 00:07:33,320 Mathematiker: gibt's die? Ja, es gibt Primzahlen in jeder Menge. Zweitens: wie 93 00:07:33,320 --> 00:07:37,430 viel gibt es da? Und da hat man eine Formel, die sagt, also die Anzahl der 94 00:07:37,430 --> 00:07:44,919 Primzahlen ist etwa x/ln(x), also ganz grob gesagt, alle 1024 Zahlen sind.. ist 95 00:07:44,919 --> 00:07:51,589 eine Primzahl. Also man hat irgendwie 2^10^15 mögliche Primzahlen und wer ein 96 00:07:51,589 --> 00:07:55,099 bisschen aufpasst, sollte bei Mathematikern immer zusammenzucken, wenn 97 00:07:55,099 --> 00:07:59,400 die 'in ungefähr gleich' schreiben, dann bedeutet das, es ist gleich bis auf einen 98 00:07:59,400 --> 00:08:01,039 linearen Faktor, *lacht* 99 00:08:01,039 --> 00:08:03,379 der möglicherweise beliebig groß sein kann. 100 00:08:03,379 --> 00:08:05,070 *Lachen* Und das ist für die Leute, die 101 00:08:05,070 --> 00:08:08,659 implementieren, immer so mäßig befriedigend, deswegen haben wir noch mal 102 00:08:08,659 --> 00:08:14,379 nachgeguckt und für x > 17 gilt, dass diese Abschätzung schon sehr genau ist. 103 00:08:14,379 --> 00:08:18,369 Und im Vertrauen: für echte Systeme sollten wir Primzahlen, die deutlich 104 00:08:18,369 --> 00:08:22,210 größer sind als 17 verwenden. *Lachen* 105 00:08:22,210 --> 00:08:27,119 Ja, das war ein mathematischer Witz, vielen Dank für die Leute, 106 00:08:27,119 --> 00:08:28,119 *lacht* *Lachen* 107 00:08:28,119 --> 00:08:32,970 die es gefunden haben. Ok. Zurück zu der Hacker-Welt. Wie sieht es in der 108 00:08:32,970 --> 00:08:36,250 praktischen Implementierung aus? Schauen wir uns mal gpg an, das bedeutet, wir 109 00:08:36,250 --> 00:08:41,330 nehmen halt Zahlen, Zufallszahlen, und testen die dann. Zuerst mit einem Sieve- 110 00:08:41,330 --> 00:08:46,030 Algorithmus, also ein einfaches Durchteilen der Primzahlen kleiner/gleich 111 00:08:46,030 --> 00:08:53,090 2000.. 400.. äh, 4999. Das muss ich, glaube ich, hier nicht machen. Der zweite 112 00:08:53,090 --> 00:08:57,840 Teil ist ein Fermat-Test, der ist auch so niedlich, dass ich den Wikipedia-Artikel 113 00:08:57,840 --> 00:09:07,070 nehm: das ist alles. Und der dritte Test ist bisl ausführlicher, weil da mit Bit 114 00:09:07,070 --> 00:09:12,260 hin und her geschubst wird, ein bisschen, aber das ist der komplette Code. Also wir 115 00:09:12,260 --> 00:09:17,230 machen Zufallszahlen und machen diese Tests, diese wenigen Zeilen Tests durch. 116 00:09:17,230 --> 00:09:19,540 Und haben dann eine hohe Wahrscheinlichkeit, dass es eine Primzahl 117 00:09:19,540 --> 00:09:23,810 ist, multiplizieren das dann, sind fertig. Was kann da passieren? Nochmal zur 118 00:09:23,810 --> 00:09:29,940 Erinnerung: wir sind in einem Zahlenraum, wo wir 2^1015 Primzahlen zur Verfügung 119 00:09:29,940 --> 00:09:34,340 haben, also da kann doch nichts schiefgehen. Außer man kommt auf die tolle 120 00:09:34,340 --> 00:09:38,380 Idee, wir machen mal ganz schnelle Primzahl- Erzeugung. Mein erster Eindruck 121 00:09:38,380 --> 00:09:42,700 war: Nein, echt lieber nicht. Dann habe ich gesagt: "Guck Dir mal die Literatur 122 00:09:42,700 --> 00:09:47,050 an", hab die zwei, drei Tage angeguckt und dann kam ich zur Entscheidung: Echt lieber 123 00:09:47,050 --> 00:09:53,180 nicht. Und die Praxis haut dann hier auch nochmal voll auf die Computersicherheit 124 00:09:53,180 --> 00:09:59,880 ein. Nämlich diese TPM-Systeme, die kriegen das hin, die haben einen 125 00:09:59,880 --> 00:10:03,280 Schlüssel, also einer der zentralen Schlüssel ist der Storage Root Key. Der 126 00:10:03,280 --> 00:10:10,460 wird genau ein Mal erzeugt. In der Lebenszeit des Gerätes. Also ein Mal. Also 127 00:10:10,460 --> 00:10:16,530 hier ist kein.. keine Notwendigkeit, das mit einer unsicheren schnellen Erzeugung 128 00:10:16,530 --> 00:10:20,170 zu machen, wird allerdings trotzdem gemacht. Weiterhin haben die ganzen TPM- 129 00:10:20,170 --> 00:10:28,380 Chips eine Schlüssellänge kleiner/gleich 2048 Bit. So, und dann passierte der 130 00:10:28,380 --> 00:10:32,160 preiswerte Totalschaden, das haben die Kollegen in einem Vortrag hier auch 131 00:10:32,160 --> 00:10:36,530 gemacht, als Professor muss ich da noch mal darauf hinweisen, dass die Hauptidee - 132 00:10:36,530 --> 00:10:40,510 haben die jungen Leute auch ordentlich hingeschrieben - von 1996 ist, 133 00:10:40,510 --> 00:10:47,200 unmodifiziert. Dieser Coppersmith.. unmodifiziert, gar nix. Und was ich ihnen 134 00:10:47,200 --> 00:10:50,530 sehr dankbar bin ist, dass sie da bei den ganzen Sachen mal die Preisliste 135 00:10:50,530 --> 00:10:55,460 drangeschrieben haben. Also, ich weiß nicht, was das in Bitcoin ist, aber das 136 00:10:55,460 --> 00:11:03,110 sind Cent-Bruchteile in Dollar. Und für das 2048, was die höchste Schlüssellänge 137 00:11:03,110 --> 00:11:11,260 für TPM-Chips ist, ist es Kosten von 944 $. Wer sieht noch was Ultra-bizarres? 138 00:11:11,260 --> 00:11:18,160 *unverständliche Antwort* Ja. Also, irgendjemand erklärt mir nach 139 00:11:18,160 --> 00:11:23,801 dem dritten Bier, warum.. wie man das hinkriegt, dass 3072 eine 10^17 mal 140 00:11:23,801 --> 00:11:32,300 größere Sicherheit gegen Angriffe haben als 4096. Also ihr merkt, das ist an 141 00:11:32,300 --> 00:11:40,140 Bizzarität relativ wenig zu überbieten. Gut, wie gesagt, wenn wir gerade bei 142 00:11:40,140 --> 00:11:43,990 Sachen sind, die in die Hose gehen können, habe ich auch noch überlegt: Was gibt es 143 00:11:43,990 --> 00:11:47,320 noch aus dem letzten Jahrtausend? Nämlich den Bleichenbacher-Angriff. Und da hat 144 00:11:47,320 --> 00:11:52,860 eine Gruppe um Hanno Böck und andere Autoren auch mit Robot das sehr schön 145 00:11:52,860 --> 00:11:54,110 gezeigt, *lacht* 146 00:11:54,110 --> 00:11:57,570 dass das heute auch noch genau geht, aber nur bei so kleinen Firmen wie F5, Citrix 147 00:11:57,570 --> 00:12:00,800 und Cisco. *Lachen* 148 00:12:00,800 --> 00:12:07,490 Und so bei 27 der 100 häufigsten Webservices, unter anderem Facebook und 149 00:12:07,490 --> 00:12:11,730 *lacht* PayPal. Das ist, glaube ich, die Firma die 150 00:12:11,730 --> 00:12:14,280 irgendwas mit Geld macht also das ist irgendwie 151 00:12:14,280 --> 00:12:18,280 *Lachen* auch ein Punkt, wo ich irgendwie sag, das 152 00:12:18,280 --> 00:12:23,090 ist eine Sache, wo man sich fragt, und da werd ich nicht näher auf.. gehen, aber 153 00:12:23,090 --> 00:12:27,990 noch mal der Hinweis: Coppersmith [ist von] 96, Bleichenbacher [von] 98. Ihr 154 00:12:27,990 --> 00:12:33,240 merkt, ich steh auf alte Angriffe, insofern seid versichert, im Laufe 155 00:12:33,240 --> 00:12:34,240 *lacht* 156 00:12:34,240 --> 00:12:36,350 des Vortrags kommen dann noch ältere Geschichten raus. 157 00:12:36,350 --> 00:12:37,350 *Lachen* 158 00:12:37,350 --> 00:12:42,470 Aber das ist natürlich relativ schmerzhaft. Also wir sollten hier auch 159 00:12:42,470 --> 00:12:47,330 nochmal sagen, was wir empfehlen: es hilft alles nichts, wir brauchen Open Source im 160 00:12:47,330 --> 00:12:52,740 Booting. Wir müssen weg von UEFI. Wir brauchen so was wie Core Boot, Libre Boot 161 00:12:52,740 --> 00:12:58,570 oder U-Boot, und das muss jetzt relativ schnell passieren, weil ansonsten haben 162 00:12:58,570 --> 00:13:02,920 wir.. sind wir Kryptographen auch wehrlos. Also wenn die uns die unterste Ebene 163 00:13:02,920 --> 00:13:07,750 wegschießen und dann alle Bits, die wir irgendwie sichern wollen, einsammeln, dann 164 00:13:07,750 --> 00:13:12,030 können wir auch keine Magie machen. Interessant ist, dass auch Google das im 165 00:13:12,030 --> 00:13:17,100 Bereich des NERF - schöner Akronym für Non-Extensible Reduced Firmware - sehr 166 00:13:17,100 --> 00:13:22,400 stark weiter betreibt. Kommen wir zu dem Thema, das ich eigentlich hauptsächlich 167 00:13:22,400 --> 00:13:26,680 bespielen wollte, das ist Robuste Kryptographie. Und jetzt geb ich mal 168 00:13:26,680 --> 00:13:31,360 wirklich ein paar Sachen, die sehr vom Ingenieurs-mäßigen Standpunkt interessant 169 00:13:31,360 --> 00:13:36,510 sind, aber natürlich mathematisch fundiert sind. Erste Regel: XOR ist dein Freund. 170 00:13:36,510 --> 00:13:41,390 Das bedeutet, wenn man z.B. aus mehreren Quellen den Zufall nimmt und das dann 171 00:13:41,390 --> 00:13:47,570 XORt, dann tut man eigentlich das System stärken. Also es bedeutet auch, ich hab 15 172 00:13:47,570 --> 00:13:52,330 schlechte random Quellen und eine gute, und wenn ich alles zusammen XOR, tue ich 173 00:13:52,330 --> 00:13:56,381 weitgehend die Eigenschaft der guten Geschichte erben. Auch hier muss man ein 174 00:13:56,381 --> 00:14:00,870 paar Sachen beachten, aber 'XOR ist dein Freund' ist, denk ich, sagen wir mal, als 175 00:14:00,870 --> 00:14:04,670 erste Annäherung schon mal ein guter Punkt. Zweitens: man kann Sachen doppelt 176 00:14:04,670 --> 00:14:08,820 hashen, das habe ich auch vor vielen Jahren gemacht, ist heute auch - [das] 177 00:14:08,820 --> 00:14:13,630 erste Mal Blockchain - bei Bitcoin der Fall, dass die zweimal hashen, bevor sie 178 00:14:13,630 --> 00:14:17,050 in den Mining-Prozess.. aber die machen das halt nicht richtig, denen fehlt ein 179 00:14:17,050 --> 00:14:22,860 XOR und dadurch haben sie nicht die Sicherheit, die sie natürlich durch höhere 180 00:14:22,860 --> 00:14:27,570 Sachen.. äh, durch doppelt hashen erreichen würden. Längere Schlüssellängen, 181 00:14:27,570 --> 00:14:32,880 na, das ist generell eine gute Empfehlung, außer wenn ihr euch an die vorletzte Folie 182 00:14:32,880 --> 00:14:38,510 erinnert, also es ist kein Allheilmittel. Aber für sehr viele Sachen ist eine lange 183 00:14:38,510 --> 00:14:45,530 Schlüssellänge doch eine deutlich bessere Idee. Gut. Historische Sachen.. 184 00:14:45,530 --> 00:14:53,970 Cryptophone. Ein Telefon, das auch Snowden ganz gern benutzt, haben wir da für 2003 185 00:14:53,970 --> 00:14:59,710 ein Design gemacht, und da können wir sehen: Schon damals, wo die Rechner etwas 186 00:14:59,710 --> 00:15:03,280 langsamer waren - wir haben das für Handy gemacht - ging das irgendwie, dass wir 187 00:15:03,280 --> 00:15:10,400 4096-bit.. äh, Diffie-Hellmann machen, wir haben es einmal gehasht und dann haben wir 188 00:15:10,400 --> 00:15:14,620 vor der Schlüsselableitung es ein zweites Mal gehasht, aber mit einer modifizierten 189 00:15:14,620 --> 00:15:18,710 Hash-Funktion. Also hier ist es ein bisl verkürzt dargestellt: Wir nehmen die SHA-2- 190 00:15:18,710 --> 00:15:24,580 Funktion von damals, aber tun die mit dem anderen Wert parametrisieren, das hat z.B. 191 00:15:24,580 --> 00:15:28,870 die Eigenschaft, ihr könnt überlegen, wenn man Kollisionsprobleme hat und zweimal 192 00:15:28,870 --> 00:15:32,610 hintereinander hasht und schon nach einem Hash eine Kollision da ist, dann hilft das 193 00:15:32,610 --> 00:15:37,140 nicht allzu sehr weiter. Aber durch das Umparametrisieren, wie gesagt, es ist 194 00:15:37,140 --> 00:15:41,749 manchmal nur ein Bit, also im Prinzip wär Bitcoin sehr viel sicherer, wenn sie nach 195 00:15:41,749 --> 00:15:46,240 dem.. - also, sicherer gegen einige Angriffs-Sachen - wenn sie nach dem ersten 196 00:15:46,240 --> 00:15:51,739 Hashing ein Bit umrempeln würden. Also das ist irgendwie manchmal ein bisschen 197 00:15:51,739 --> 00:15:54,960 gruselig, wenn man sich überlegt, das manchmal ein Bit an der richtigen Stelle 198 00:15:54,960 --> 00:15:58,920 gesetzt oder nicht gesetzt wirklich drastische Auswirkungen hat. Später dazu 199 00:15:58,920 --> 00:16:03,890 noch ein paar weitere Bemerkungen. Und hier aus der beliebten Serie 'XOR ist dein 200 00:16:03,890 --> 00:16:11,230 Freund': wir haben damals AES-256 und Twofish einfach mit XOR verknüpft, das ist 201 00:16:11,230 --> 00:16:15,550 eine Verknüpfung, die die schöne Eigenschaft hat, das dann Angreifer beide 202 00:16:15,550 --> 00:16:21,240 Funktionen brechen müssen, etwas verkürzt dargestellt, aber durchaus zutreffend. 203 00:16:21,240 --> 00:16:25,689 Also wie gesagt, es sind relativ einfache Sachen, bei Hash-Funktionen ein bisl 204 00:16:25,689 --> 00:16:30,480 darauf achten: XOR ist ganz spannend. Kommen wir noch mal zur Hash-Funktion, da 205 00:16:30,480 --> 00:16:35,770 möchte ich hier heute mal ein bisschen Werbung für SHA-512 machen. Ich bin der 206 00:16:35,770 --> 00:16:43,450 Meinung, man sollte lieber SHA-512 nutzen als SHA-256. Warum? Naja, Abschneiden ist 207 00:16:43,450 --> 00:16:51,660 OK, man kann die, wenn man nur 256 Bit ist, kann man die anderen Bits schlicht 208 00:16:51,660 --> 00:16:55,900 und einfach verwerfen. Wer es nochmal im Standard da hinten.. kann es sich 209 00:16:55,900 --> 00:17:01,600 angucken, SHA-356 ist im Prinzip, mit einer leichten Modifikation, SHA-512 mit 210 00:17:01,600 --> 00:17:06,980 abgeschnittenen Bits. Zweiter Punkt: Kryptographisch hochwertige Bits, genauer 211 00:17:06,980 --> 00:17:12,400 gesagt schön randomisierte Bits, kann man immer brauchen. Also wenn man 512-bit 212 00:17:12,400 --> 00:17:17,160 Ausgabe hat, dann hat man noch zusätzlich ein paar random Bits rumliegen, wie schon 213 00:17:17,160 --> 00:17:21,280 gesagt, man kann dann noch überlegen 'XOR ist dein Freund' und das in andere Sachen 214 00:17:21,280 --> 00:17:30,430 nochmal anzubringen. Weiterhin ist SHA-512 sehr schnell, auf 64-bit Plattformen, ist 215 00:17:30,430 --> 00:17:35,651 eigentlich fast genauso schnell auf älteren Plattformen wie SHA-256 und wie 216 00:17:35,651 --> 00:17:40,240 gesagt, rein aus dem kryptographischen Bauchgefühl: Man hat in SHA-512 mehr 217 00:17:40,240 --> 00:17:45,980 Runden und man hat 64-bit-Operation, also von allem kryptographischen Bauchgefühl 218 00:17:45,980 --> 00:17:50,040 wird da deutlich mehr durcheinander gewirbelt und die Sicherheit auch in einer 219 00:17:50,040 --> 00:17:58,290 gewissen Weise erhöht. Gut, das machen wir kurz. Längere Kurven, nochmal der Hinweis: 220 00:17:58,290 --> 00:18:03,630 Ich bin der Meinung, unter anderem die Gruppe um D.J. Bernstein hat da schöne 221 00:18:03,630 --> 00:18:12,230 Arbeit gemacht bei der kleinen Kurve, er hat auch irgendwie bei der 256-bit Kurve 222 00:18:12,230 --> 00:18:16,480 interessante Ergebnisse gehabt. Er hat auch längere Kurven bereitet, aber das 223 00:18:16,480 --> 00:18:21,800 nicht mit der.. mit dem In.. mit dem Nachdruck bearbeitet, die man vielleicht 224 00:18:21,800 --> 00:18:25,960 dafür braucht. Und außerdem bin ich halt wirklich der Meinung, wenn man schon auf 225 00:18:25,960 --> 00:18:31,790 die elliptischen Kurven kommt, ist ja SHA-256, also ist 256 Bit wirklich sehr 226 00:18:31,790 --> 00:18:37,340 nahe an der Grenze, wo man irgendwie sagt, das könnte schnell problematisch werden. 227 00:18:37,340 --> 00:18:46,470 Insbesondere, weil auch djb verwiesen hat auf die Probleme, die RSA bei 228 00:18:46,470 --> 00:18:49,850 Quantencomputern hat, muss ich sagen, elliptische Kurven, wegen der kleineren 229 00:18:49,850 --> 00:18:54,690 Schlüssellänge würd ich vom Bauchgefühl sagen, da knallt's deutlich früher als bei 230 00:18:54,690 --> 00:19:02,540 den RSA-Operationen. Gut, alles klar, jetzt in einem zweitem Teil tut mein 231 00:19:02,540 --> 00:19:07,630 geschätzter Kollege Christian Forler mal ein paar konstruktive Tips geben, wie man 232 00:19:07,630 --> 00:19:12,120 wirklich bestehende Systeme besser nutzen können, und es ist eigentlich auch 233 00:19:12,120 --> 00:19:16,510 überraschend: Wir haben uns in dem Vorfeld halt da noch mal reingeguckt und sind an 234 00:19:16,510 --> 00:19:23,030 einigen Stellen gekommen, dass z.B. einige neue Ideen, TLS, z.B. 1.3, eigentlich auf 235 00:19:23,030 --> 00:19:28,860 den ersten Blick gut aussehen, außer wenn man mal ein paar andere Angriffsmodelle 236 00:19:28,860 --> 00:19:32,930 zugrunde legt. Insofern sind die Arbeiten, die Christian jetzt vorstellt, glaube ich 237 00:19:32,930 --> 00:19:36,920 auch, vom hohen Maße praxisrelevant. Christian Forler: Hallo. Jetzt wird es 238 00:19:36,920 --> 00:19:40,550 gleich ein bisschen technisch werden, da müsst ihr jetzt halt durch. 239 00:19:40,550 --> 00:19:42,570 *lacht* OK. Und zwar geht es jetzt um den 240 00:19:42,570 --> 00:19:47,390 richtigen Einsatz von AES. Ne? Also das Problem ist, dass jetzt die ganzen 241 00:19:47,390 --> 00:19:51,480 Hersteller von Softwareprodukte irgendwie Sicherheit bewerben, indem sie erzählen: 242 00:19:51,480 --> 00:19:55,840 "Wir nutzen AES". Ja. Das ist zwar jetzt erst mal nicht so die schlechteste Idee, 243 00:19:55,840 --> 00:19:59,430 AES zu nutzen, aber in der Regel findet man halt nicht raus, wie sie das 244 00:19:59,430 --> 00:20:03,540 einsetzen, ja, und da kann man auch viel falsch machen. Und das schauen wir uns 245 00:20:03,540 --> 00:20:06,540 dann gleich mal an, das heißt, wenn jemand irgendwie behauptet, er macht irgendwie 246 00:20:06,540 --> 00:20:10,790 AES, online erstmal nachfragen, wie das eingesetzt wird und wenn man das nicht 247 00:20:10,790 --> 00:20:15,620 rausfindet, ist das meistens ein Indiz dafür, dass da ein Fehler gemacht wird. 248 00:20:16,630 --> 00:20:20,523 Und dann schauen wir uns mal an hier: Also AES ist keine Wunderwaffe, das ist einfach 249 00:20:20,523 --> 00:20:24,590 nur ein Blockchiffre, das heißt, ich kann mit AES einen Klartextblock verschlüsseln, 250 00:20:24,590 --> 00:20:29,760 bzw. einen Chiffretextblock entschlüsseln, und die Blockgröße ist 128 Bit, das heißt 251 00:20:29,760 --> 00:20:34,320 16 Byte. Das hilft jetzt in der Regel nicht so wirklich viel, weil in der Regel 252 00:20:34,320 --> 00:20:38,860 habe ich halt Nachrichten, die ein wenig größer sind als 16 Byte, ja, wenn man es 253 00:20:38,860 --> 00:20:42,220 so irgendwie Dateien uns anschaut, auch Netzwerkpakete. Und da ist jetzt die 254 00:20:42,220 --> 00:20:46,520 Frage: Wie kann ich jetzt einen größeren Klartext verschlüsseln? Und dann ist die 255 00:20:46,520 --> 00:20:50,100 Antwort irgendwie klar: Ich zerhacke den in Blöcke und bearbeite die Blöcke 256 00:20:50,100 --> 00:20:54,780 nacheinander irgendwie mit AES ab. Ja, das ist so die elementare Strategie. Und dann 257 00:20:54,780 --> 00:20:58,410 schauen wir uns mal an: da in der i-Folge jetzt, da geht das auf jeden Fall schief, 258 00:20:58,410 --> 00:21:02,710 und ihr könnt euch vorstellen, man tut jeden Block einmal durch AES jagen, 259 00:21:02,710 --> 00:21:08,850 Nachteil: gleiche Klartextblöcke, ja, wenn die Klartextblöcke gleich sind und AES 260 00:21:08,850 --> 00:21:11,750 eine Funktion, dann kommt auch das Gleiche raus. Das heißt, gleiche Klartextblöcke 261 00:21:11,750 --> 00:21:15,340 ergibt gleiche Chiffretextblöcke, ja, alles schon mal gehört, das heißt, da 262 00:21:15,340 --> 00:21:19,160 bleibt Struktur erhalten und wenn da Struktur erhalten bleibt bei einer 263 00:21:19,160 --> 00:21:22,950 Verschlüsselung, dann ist das irgendwie extrem schlecht. Also das, was wir grad 264 00:21:22,950 --> 00:21:26,760 nicht haben. Ja, das ist halt die Idee, warum wir Kryptographie nutzen, damit ja 265 00:21:26,760 --> 00:21:29,350 von der Struktur nichts mehr übrig bleibt. Ja, und falls doch, gibt es da dieses 266 00:21:29,350 --> 00:21:33,870 Wikipedia-Beispiel, das wir irgendwie alle kennen. Das heißt, das ist irgendwie AES- 267 00:21:33,870 --> 00:21:36,880 verschlüsselt, das ist 'military-grade security', da, so Werbung.. so, ja. 268 00:21:36,880 --> 00:21:40,150 *räuspert sich* Also da gibts ja Leute, die bewerben halt 269 00:21:40,150 --> 00:21:44,160 ihre Software mit 'military-grade security' und machen dann sowas. Das ist 270 00:21:44,160 --> 00:21:48,490 irgendwie schlecht. Nächster Schritt, was man jetzt machen kann: Wir wissen alle, ja 271 00:21:48,490 --> 00:21:52,440 man macht Schlüsselstrom. Man nehme ein AES, generiere einen Schlüsselstrom. Die 272 00:21:52,440 --> 00:21:55,660 Idee ist schon mal gar nicht mal so schlecht, weil wir haben ja irgendwie 273 00:21:55,660 --> 00:21:59,870 gelernt so, One-Time-Pad funktioniert. Und das wollen wir irgendwie da ein bisschen 274 00:21:59,870 --> 00:22:05,370 emulieren. Dann gibt's jetzt die einfache Variante, dann.. genau, verschlüssel ich 275 00:22:05,370 --> 00:22:09,620 jetzt was, indem ich einen Counter, irgendwie, also ich nehm einen Counter, 276 00:22:09,620 --> 00:22:15,770 verschlüssel den und tu das Ergebnis, der Schlüsselstrom, der raus kommt, XORen mit 277 00:22:15,770 --> 00:22:19,320 meinem Klartext. Und das Problem ist hier bei dieser Variante, hier gibt's keinen 278 00:22:19,320 --> 00:22:23,670 Zustand, das ist zustandslos, das heißt, das ist deterministisch. Das heißt, jedes 279 00:22:23,670 --> 00:22:27,770 Mal, wenn ich hier das anwerfe, die Verschlüsselungsverfahren, kommt der 280 00:22:27,770 --> 00:22:31,570 gleiche Schlüsselstrom raus. Und wie wir auch wissen, One-Time-Pads mehrmals 281 00:22:31,570 --> 00:22:35,470 anwenden ist auch eine schlechte Idee, dann kommt .. das heißt, ich muss jedes 282 00:22:35,470 --> 00:22:39,990 Mal bei AES den Schlüssel wechseln, ja wenn ich da jetzt eine neue Nachricht 283 00:22:39,990 --> 00:22:44,201 verschlüsseln möchte. Und das ist irgendwie auch.. irgendwie nicht so 284 00:22:44,201 --> 00:22:46,950 richtig praktikabel, wenn ich jetzt vergesse, den Schlüssel zu wechseln, bei 285 00:22:46,950 --> 00:22:50,390 dem einfachen Verfahren, dann fällt es erstmal gar nicht so auf, weil ich habe 286 00:22:50,390 --> 00:22:54,059 hier jetzt einmal Tux verschlüsselt und einmal Beastie, und hier sieht man 287 00:22:54,059 --> 00:22:57,899 erstmal: die Struktur ist weg, weißes Rauschen, das ist schon mal irgendwie ganz 288 00:22:57,899 --> 00:23:02,380 angenehm. Problem ist jetzt nur, ich habe zweimal den gleichen Schüsselstrom, das 289 00:23:02,380 --> 00:23:07,710 heißt, wenn ich den Chiffretext XORe, dann kürzt sich der weg. Und dann, genau, kommt 290 00:23:07,710 --> 00:23:14,160 irgendwie das raus. Und da kann man sich vorstellen, das das jetzt nicht so der 291 00:23:14,160 --> 00:23:20,670 Riesenaufwand ist, aus diesem XOR dann die zwei Klartexte zu extrahieren, das kriegt 292 00:23:20,670 --> 00:23:24,230 man auch hier noch als Geheimdienst hin, selbst als schlecht ausgestatteter 293 00:23:24,230 --> 00:23:29,220 Geheimdienst, das kriegt man auch noch als Student noch hin. Das ist eventuell mal 294 00:23:29,220 --> 00:23:34,270 eine Übungsaufgabe, so im.. für Bachelor- studenten, das ist jetzt net so schwer. 295 00:23:34,270 --> 00:23:35,270 *lacht* 296 00:23:35,270 --> 00:23:39,760 Deswegen also, wie funktioniert's richtig? Das heißt, ich brauch einen Zustand, ja? 297 00:23:39,760 --> 00:23:42,450 Das heißt, wenn ich einen Schlüssel nur habe und möchte damit mehrere Nachrichten 298 00:23:42,450 --> 00:23:47,210 verschlüsseln, brauche ich einen Zustand, das nennen wir hier Nonce. Und das heißt, 299 00:23:47,210 --> 00:23:50,740 und beim Counter-Mode setzt sich halt mein Counter im Anfangswert nicht auf 1, 300 00:23:50,740 --> 00:23:54,940 sondern ich setze ihn auf seinen Zustand. Und jetzt ist die Idee: Jedes Mal, wenn ich 301 00:23:54,940 --> 00:23:58,450 eine neue Nachricht verschlüssele, würfel ich mir einen neuen Zustand aus, neue 302 00:23:58,450 --> 00:24:04,190 Nonce. Und das heißt, wenn ich da jetzt eine neue Nonce anfange, bekomme ich immer 303 00:24:04,190 --> 00:24:08,690 wieder einen neuen Schlüsselstrom und das ist halt vorteilhaft, das heißt, genau. 304 00:24:08,690 --> 00:24:12,730 Das heißt, wenn ich halt.. neuer Schlüsselstrom heißt halt, das können wir 305 00:24:12,730 --> 00:24:16,610 wieder nutzen und so falls sich jetzt.. das Ganze ist sicher so, falls sich kein 306 00:24:16,610 --> 00:24:22,621 Nonce-Schlüssel-Paar wiederholt. So weit, so gut. Das heißt, die Anforderung halt 307 00:24:22,621 --> 00:24:27,270 hier ist jetzt.. ist, der Nonce darf sich nicht wiederholen. Ja und das ist halt so 308 00:24:27,270 --> 00:24:31,580 ein bisl kritisch, es gibt uns, genau, es gibt da noch so mehrere 309 00:24:31,580 --> 00:24:34,440 Verschlüsselungsverfahren, die sind alle Nonce-basiert, und das erste Problem, wie 310 00:24:34,440 --> 00:24:37,140 ich gesagt habe, man darf den Nonce irgendwie.. muss aufpassen, dass der sich 311 00:24:37,140 --> 00:24:41,220 nicht wiederholt. Und das zweite Problem ist, man schützt nicht die Integrität der 312 00:24:41,220 --> 00:24:44,559 Nachricht damit. Ja das heißt, wenn ich da was mit verschlüssele, z.B. so eine Bank- 313 00:24:44,559 --> 00:24:47,660 Transaktion, ist es sozusagen geschickt, dass die hier im Internet niemand lesen 314 00:24:47,660 --> 00:24:50,940 kann, aber wenn ich das Format irgendwie kenne, der Bank-Transaktion, kann ich es 315 00:24:50,940 --> 00:24:55,650 so manipulieren, dass der Betrag sich ändert, oder die Empfängeradresse und das 316 00:24:55,650 --> 00:25:03,200 auch kontrolliert. Und eventuell möchte man das nicht. Ja. Genau. Und deswegen 317 00:25:03,200 --> 00:25:05,930 gibt es die Authentisierte Verschlüsselung. Das heißt, als Kryptograh 318 00:25:05,930 --> 00:25:09,360 ist man auch auf die Idee gekommen, seit längerem schon, das man nicht nur die 319 00:25:09,360 --> 00:25:11,950 Vertraulichkeit irgendwie schützen möchte einer Nachricht, sondern auch die 320 00:25:11,950 --> 00:25:18,290 Integrität. Und das in einem Rutsch und das auch irgendwie mit AES. Genau. Das ist 321 00:25:18,290 --> 00:25:22,740 jetzt das große Ziel. Und wie funktioniert das, so ein Verfahren? Ich hab jetzt, wie 322 00:25:22,740 --> 00:25:27,530 gesagt, wieder mein Nonce und mein N und meinen Klartext P, den kipp ich da rein, 323 00:25:27,530 --> 00:25:30,250 und dann fällt es nicht nur unter Chiffretext raus, sondern es fällt auch 324 00:25:30,250 --> 00:25:34,950 noch so eine kryptographische Prüfsumme raus. Ja? Und das heißt, wenn ich jetzt 325 00:25:34,950 --> 00:25:38,920 die Inputs ändere, ändern sich auch alle Outputs bei der Verschlüsselung. Das 326 00:25:38,920 --> 00:25:41,929 heißt, ich komm jedesmal, wenn ich dann irgendwie mindestens ein Bit ändere oder 327 00:25:41,929 --> 00:25:46,700 mehr im Input, ändert sich halt auch die Prüfsumme und der Chiffretext. Das ist 328 00:25:46,700 --> 00:25:51,490 schon mal ganz nett. Und wenn ich entschlüssle, ganz einfach, dann kipp ich 329 00:25:51,490 --> 00:25:55,280 wieder so ein valides Nonce-Chiffretext- Tag-Paar rein und es kommt mein Klartext 330 00:25:55,280 --> 00:25:58,840 raus, Juhu! Und das ist, der Clou ist jetzt, der Hammer: Wenn ich jetzt 331 00:25:58,840 --> 00:26:02,040 irgendwie am.. wenn jetzt jemand manipuliert, das heißt wenn ich jetzt 332 00:26:02,040 --> 00:26:07,320 Nonce, Chiffretext oder Tag ändere, dann gibts ne Fehlermeldung. Ja? Dann heißt es, 333 00:26:07,320 --> 00:26:10,660 der Klartext ist nicht valide, das heißt die Eingabe war invalide und es gibt eine 334 00:26:10,660 --> 00:26:15,080 Fehlermeldung. Das ist irgendwie ganz nett, sowas will ich eigentlich haben. Ja 335 00:26:15,080 --> 00:26:18,650 da gibt es irgendwie so zwei ganz berühmte Verfahren, das eine ist der Galois/Counter 336 00:26:18,650 --> 00:26:21,611 Mode, der wird eigentlich überall.. der ist in der Industrie weit verbreitet, den 337 00:26:21,611 --> 00:26:27,929 gibt es z.B. so bei Sachen wie IPSec oder auch bei TLS und so weiter und das ist, 338 00:26:27,929 --> 00:26:33,680 das Problem.. also, das Gute ist, das Ding ist superschnell, der Galois/Counter Mode, 339 00:26:33,680 --> 00:26:37,720 Nachteil ist, er ist ein bissel fragil. Das schauen wir uns gleich mal an und das 340 00:26:37,720 --> 00:26:44,720 andere Verfahren, das ich dann noch empfehlen kann, ist OCB, Offset Codebook 341 00:26:44,720 --> 00:26:49,230 von.. genau, Rogaway, hat er mit gebaut und das.. genau. Also wenn man die Wahl 342 00:26:49,230 --> 00:26:53,710 hat, sollte man OCB einsetzen. Problem ist halt auch wieder hier: Bei all den 343 00:26:53,710 --> 00:26:58,050 Verfahren, wenn sich eine Nonce wiederholt dann ist es.. dann bricht so alles 344 00:26:58,050 --> 00:27:02,140 zusammen. Ja und ich hab mir das nochmal angeschaut, wie schlimm die Situation ist, 345 00:27:02,140 --> 00:27:07,830 wenn sich eine Nonce wiederholt, 2011. Und d.h. das Schlimme ist, das ist wirklich 346 00:27:07,830 --> 00:27:11,500 total kaputt. D.h ich kann da immer von O(1) Angriff finden, d.h. ich kann das 347 00:27:11,500 --> 00:27:16,460 Ding in Echtzeit alles kaputt machen. 'Vertraulichkeit und Integrität'. Und das 348 00:27:16,460 --> 00:27:20,410 möchte man nicht so wirklich haben. Also das ist irgendwie.. d.h. wenn sich eine 349 00:27:20,410 --> 00:27:24,750 Nonce wiederholt, ist das so eine mittlere Katastrophe. Ja und das ist irgendwie vom 350 00:27:24,750 --> 00:27:30,960 Design her nicht so gut, d.h. da muss man irgendwann mal irgendwie die.. also die 351 00:27:30,960 --> 00:27:34,419 Anforderungen für einen Kryptograph, der ist Mathematiker, man hat so einen 352 00:27:34,419 --> 00:27:37,640 Zustand, der sich wiederholt, das klingt jetzt erstmal irgendwie so nicht so 353 00:27:37,640 --> 00:27:41,750 schlimm, aber in der Praxis ist das echt ein Problem. Schauen wir uns auch gleich 354 00:27:41,750 --> 00:27:46,080 an, erstmal noch mal hier bisl GCM- Bashing. GCM, na das liegt.. das ist 355 00:27:46,080 --> 00:27:51,640 extrem fragil. Also, [auf] das muss mans aufpassen, wenn man es einsetzt. Wenn ihr 356 00:27:51,640 --> 00:27:56,120 GCM einsetzt, Galois/Counter Mode, dann bitte nur mit 96-bit Nonces. Ansonsten 357 00:27:56,120 --> 00:27:59,530 gibt's Probleme, da können Konstanz- Kollisionen auftreten, weil dann das 358 00:27:59,530 --> 00:28:04,030 gehasht wird. Das möchte man eigentlich nicht tun. Ja und die Hashfunktion hat da 359 00:28:04,030 --> 00:28:09,669 so ein bisschen Schwächen. Dann, kurz nachdem GCM raus kam, hat sich mal Niels 360 00:28:09,669 --> 00:28:13,820 Ferguson - also sprich: Microsoft - das Ding angeschaut und hat gemeint so, oh, 361 00:28:13,820 --> 00:28:21,090 das Problem ist, wenn ich jetzt den.. die Nachricht, also die Prüfsumme, kürze, dann 362 00:28:21,090 --> 00:28:24,630 wird das Ganze extrem unsicher. Das heißt, es nimmt überproportional stark ab, die 363 00:28:24,630 --> 00:28:28,030 Sicherheit. D.h. Kürzen ist eine schlechte Idee. Und das ist auch so manche komische 364 00:28:28,030 --> 00:28:31,630 Eigenschaft, die man eigentlich nicht haben möchte. Ja. Das andere, was man 365 00:28:31,630 --> 00:28:35,900 jetzt rausgefunden hat: ja, bei Nonce Wiederholung, da fliegt da so ein 366 00:28:35,900 --> 00:28:39,540 Schlüssel raus. Ja, d.h. da irgendwie kriegt man noch einen Schüssel frei Haus 367 00:28:39,540 --> 00:28:44,410 und das Gute ist, GCM hat zwei Schlüssel. Einen Schlüssel zum Verschlüsseln, einen 368 00:28:44,410 --> 00:28:47,970 Schlüssel für die Integrität, für die Prüfsumme. Und es fällt da nur der 369 00:28:47,970 --> 00:28:53,560 Schlüssel raus für die Prüfsumme. Das ist aber irgendwie trotzdem irgendwie schlimm. 370 00:28:53,560 --> 00:28:57,080 Das möchte man eigentlich nicht. Dass man mal einen Fehler macht, der Schlüssel raus 371 00:28:57,080 --> 00:29:01,880 fällt. Das ist halt auch bisl.. so bisl fragil. Und es gibt noch auch ein paar 372 00:29:01,880 --> 00:29:06,040 Handvoll schwache Schlüssel, weil dieses Galois/Counter Mode, ja, das 'Galois' 373 00:29:06,040 --> 00:29:08,990 steht halt für Galois field multiplication, d.h. da findet eine 374 00:29:08,990 --> 00:29:13,110 Multiplikation statt, und da kann man sich denken, ja, Multiplikation mit 0 ist 375 00:29:13,110 --> 00:29:16,650 vielleicht nicht die beste Idee. Ja, wenn man so einen 0-Schlüssel hat, weil 376 00:29:16,650 --> 00:29:20,250 irgendeine Nachricht mal 0, ne, ist halt immer 0, unabhängig von der Nachricht und 377 00:29:20,250 --> 00:29:24,340 eine Prüfsumme, die unabhängig von der Nachricht ist, ist irgendwie nutzlos. Und 378 00:29:24,340 --> 00:29:28,549 da gibts noch weitere Schlüssel, die auch irgendwie noch Schwächen haben. Genau. 379 00:29:28,549 --> 00:29:33,630 Also, als das rauskam, wie gesagt, hat sich das mal Niels Ferguson angeschaut, 380 00:29:33,630 --> 00:29:38,730 der ist bei Microsoft tätig, und hat dann so ein Papier geschrieben, da stand drin, 381 00:29:38,730 --> 00:29:44,560 ja, ich kann das nicht zufällig empfehlen, besser nicht. Wenn ihr keine andere Wahl 382 00:29:44,560 --> 00:29:52,640 habt , dann nutzt GCM, aber bitte, bitte nicht.. niemals die Prüfsumme kürzen. Da.. 383 00:29:52,640 --> 00:29:56,710 genau, dann.. das Zweite, was ich hier habe, als Code-Schnipsel ist RFC 4103.. 384 00:29:56,710 --> 00:30:02,620 06, da steht beschrieben, wie man denn jetzt GCM bei IPSec benutzt und da steht 385 00:30:02,620 --> 00:30:05,809 drin, ja wenn ihr das implementiert, natürlich müsst ihr dann die volle 386 00:30:05,809 --> 00:30:08,520 Prüfsumme unterstützen - ich glaub, das kann man auch gar nicht anders 387 00:30:08,520 --> 00:30:10,850 implementieren, dafür ist es nicht möglich, dass man es eben anders 388 00:30:10,850 --> 00:30:14,030 implementiert - und aber, was optional noch erlaubt ist, ihr dürft die Prüfsumme 389 00:30:14,030 --> 00:30:20,610 kürzen, auf.. genau. Von 16 Byte auf 12 oder 8 Byte, und das ist natürlich eine 390 00:30:20,610 --> 00:30:25,230 schlechte Idee. Ja, weil dann die Sicherheits.. also mehr, die Sicherheit, 391 00:30:25,230 --> 00:30:28,590 wenn man nur 8 Byte hat, ist halt wesentlich geringer, als man da vermutet. 392 00:30:28,590 --> 00:30:33,910 D.h. erstmal: tuwat! Ne? Wer Admin ist, erst mal nachschauen: IPSec - nutzt ihr 393 00:30:33,910 --> 00:30:42,070 GCM mit kurzen Prüfsummen? Und dann erstmal das Feature deaktivieren. Das 394 00:30:42,070 --> 00:30:47,650 hilft. Dann, genau. Jetzt gehts wieder zurück zum Nonce-Reuse, nachdem ich ein 395 00:30:47,650 --> 00:30:51,050 paar Nachteile von GCM aufgezählt habe. Weil der Vorteil ist halt, es ist halt 396 00:30:51,050 --> 00:30:55,920 verdammt schnell, aber der Preis ist Fragilität. Und bei Nonce, genau, 397 00:30:55,920 --> 00:31:00,530 Wiederholung: Es ist halt praxisrelevant, da gab es ja irgendwie Diskussionen am 398 00:31:00,530 --> 00:31:04,280 Anfang, als der da herauskam und irgendwie, da nenn ich mal drei Beispiele. 399 00:31:04,280 --> 00:31:11,640 Ja, ich glaube schon, weil erster Grund ist halt: Programmierer machen Fehler und 400 00:31:11,640 --> 00:31:15,750 auch Leute, die sowas designen, machen auch mal ab und zu Fehler. Und genau, da 401 00:31:15,750 --> 00:31:19,320 gibt es so drei lustige Beispiele. Eins, so irgendwie so eine kleine Klitsche aus 402 00:31:19,320 --> 00:31:23,550 Redmond, mit so Nischen-Software - Word, Excel - hat es irgendwie nicht so richtig 403 00:31:23,550 --> 00:31:27,870 hinbekommen beim ersten Anlauf, dann das andere, was ich hier noch hab ist so 404 00:31:27,870 --> 00:31:30,910 WinZip, auch so irgendwie Nischen- Software, die keiner nutzt. Und das dritte 405 00:31:30,910 --> 00:31:35,790 haben wir jetzt dieses Jahr ganz brandneu, ist KRACK hier, WPA2 Wi-Fi, ja, auch so 406 00:31:35,790 --> 00:31:40,870 ein Nischen-Produkt. Und das ist so, sieht man, das geht halt immer wieder.. also 407 00:31:40,870 --> 00:31:45,500 selbst die großen Firmen eben.. und Standard und Komitees kriegen das nicht so 408 00:31:45,500 --> 00:31:49,280 richtig hin. D.h. da gibts halt irgendwie ein Problem. Und ich denke, auch in 409 00:31:49,280 --> 00:31:54,250 Zukunft wirds immer wieder Probleme geben, ja? Und das andere ist, wenn man sich mal 410 00:31:54,250 --> 00:31:59,669 schaut so, die ganzen App Stores, was es da an Software gibt, den nutzen halt viele 411 00:31:59,669 --> 00:32:03,740 Leute, also, was heißt.. es gibt halt irgendwie.. ich denke, jede zehnte App, 412 00:32:03,740 --> 00:32:08,660 die irgendwie so AES einsetzt, wird so irgendwie diesen.. als Nonce hier den 413 00:32:08,660 --> 00:32:13,520 Zufallszahlengenerator von xkcd verwenden, d.h. das ist alles schlimm, wenn man sich 414 00:32:13,520 --> 00:32:15,990 mal das anschaut. *räuspert sich* 415 00:32:15,990 --> 00:32:20,660 Ja also, das ist halt strukturelles Problem. Das andere sind da so 416 00:32:20,660 --> 00:32:24,180 Bedienfehler, ja, Admins sind auch teilweise mal schuld, nicht nur die 417 00:32:24,180 --> 00:32:30,590 Programmierer, d.h. was man da oft macht, ist jetzt hier restore ein Backup, und der 418 00:32:30,590 --> 00:32:34,150 Nonce ist halt dann persistent geschrieben worden irgendwo auf Platte, den letzten 419 00:32:34,150 --> 00:32:38,040 Wert so, dann wird das wieder geladen, oder wenn man klont, bei virtuellen Maschinen, 420 00:32:38,040 --> 00:32:40,950 da kann auch mal was schief gehen bei Nonces, dass mal eine Nonce öfters 421 00:32:40,950 --> 00:32:44,470 aufkommt. Oder das andere ist, wenn ihr jetzt zu wenig Entropie habt, dann zieht 422 00:32:44,470 --> 00:32:48,810 man öfter mal die gleiche Nonce. Ja, das ist irgendwie alles unlustig. Das 423 00:32:48,810 --> 00:32:53,620 Problem.. also, das Gute der Nachricht ist, das Problem wurde eigentlich 2006 424 00:32:53,620 --> 00:32:58,740 schon gelöst, ja, von den Kryptographen. Da gab es jetzt ein Paper, das rauskam, 425 00:32:58,740 --> 00:33:03,780 das hat vorgestellt ein Verfahren, das ist Misuse Resistant AE Schemes, heißen die, 426 00:33:03,780 --> 00:33:09,250 und die bieten auch Sicherheit, wenn man das mit einem Nonce vergeigt. Ja, genau. 427 00:33:09,250 --> 00:33:12,449 Und das Coole ist, die haben beliebig.. unterstützen beliebig lange Nonces, 428 00:33:12,449 --> 00:33:16,650 i.d.R., die Verfahren. D.h. wenn man da Netzwerk-Pakete verschlüsselt, dann kann 429 00:33:16,650 --> 00:33:21,620 man den Header als Nonce nehmen und den Payload als Klartext. Wunderprima. Sollt 430 00:33:21,620 --> 00:33:26,510 man mal machen. Und zwar überall. Das Verfahren, wie gesagt, wurde jetzt 431 00:33:26,510 --> 00:33:29,430 vorgestellt, da gibt's auch ein RFC für, d.h. es gibt jetzt keinen Grund, das 432 00:33:29,430 --> 00:33:34,450 irgendwie nicht zu implementieren als Entwickler oder Netzwerk-Mensch. Und 433 00:33:34,450 --> 00:33:38,179 genau, da gab es noch eine Schwäche, also SIV ist eigentlich idiotensicher, d.h. man 434 00:33:38,179 --> 00:33:41,120 kann auch ein Nonce wiederholen, aber es ist halt nicht irgendwie 435 00:33:41,120 --> 00:33:45,350 vollidiotensicher, deswegen habe ich da noch 2016 an einem Verfahren gearbeitet, 436 00:33:45,350 --> 00:33:50,870 das das Ganze noch verstärkt. Warum ist SIV nicht idiotensicher? Ja, man muß ja 437 00:33:50,870 --> 00:33:56,400 noch die kryptographische Prüfsumme verifizieren. Und ja, und wenn man das 438 00:33:56,400 --> 00:33:59,490 nicht hinkriegt, ja, wir erinnern uns, hier Apple z.B. kriegt das auch nicht 439 00:33:59,490 --> 00:34:03,420 immer hin, mit goto fail Bug, d.h. wenn das Apple passiert, kann es eventuell auch 440 00:34:03,420 --> 00:34:07,549 anderen Firmen passieren, haben wir uns da gedacht. Und deswegen haben wir das 441 00:34:07,549 --> 00:34:11,289 irgendwie so gebaut, dass selbst wenn man jetzt irgendwie die Verifikation 442 00:34:11,289 --> 00:34:15,710 versemmelt, dass dann irgendwie bei der.. genau, dass dann immer noch.. irgendwie 443 00:34:15,710 --> 00:34:20,409 das irgendwie bemerkbar wird, indem man als.. das so baut, das der Klartext, wenn 444 00:34:20,409 --> 00:34:23,858 man den Chiffretext manipuliert, immer weißes Rauschen ergibt. D.h. man hat immer 445 00:34:23,858 --> 00:34:28,270 weißes Rauschen. Und dann war die Idee so, eventuell fällt es bei.. wenn man den 446 00:34:28,270 --> 00:34:33,918 Input validiert, dann auf, bei der Input- Validierung, dass da irgendwie nur weißes 447 00:34:33,918 --> 00:34:38,650 Rauschen ist, und dass es keine valide Eingabe ist, oder die Software wirft 448 00:34:38,650 --> 00:34:44,789 eine Exception oder stürzt ab oder so. Ja genau. Wie das genau machen, überspringe 449 00:34:44,789 --> 00:34:50,159 ich mal, aus Gründen der Zeit. Genau und das Ding ist, hier tutwat! Benutzt diese 450 00:34:50,159 --> 00:34:55,949 MRAE-Schemes. Die haben einen gravierenden Nachteil: man muss zweimal komplett über 451 00:34:55,949 --> 00:35:00,310 den Klartext gehen. D.h. das dauert halt ein bisschen länger als andere Verfahren. 452 00:35:00,310 --> 00:35:04,630 D.h. die sind nicht so super effizient. Und jetzt kann es natürlich sein, dass man 453 00:35:04,630 --> 00:35:09,860 jetzt irgendwie Echtzeitanforderungen hat, die das nicht erlauben. Ja dann, was soll 454 00:35:09,860 --> 00:35:14,390 ich tun, wenn das irgendwie technisch nicht möglich, realisierbar ist? Ja, nicht 455 00:35:14,390 --> 00:35:19,750 in Panik verfallen, auch da hab ich irgendwie.. gibt es eine Lösung, da war 456 00:35:19,750 --> 00:35:24,770 ich dabei, die mit zu entwickeln. Und die Antwort hier ist Robuste AE-Schemes, die 457 00:35:24,770 --> 00:35:29,200 hießen vorher mal 'Nonce Misuse Resistant AE-Schemes', und wir haben das jetzt 458 00:35:29,200 --> 00:35:33,900 umbenannt, nur noch Robust, weil es da irgendwie ein bisl Konflikt gab, 459 00:35:33,900 --> 00:35:40,330 Potenzial, in der Crypto-Szene. Und was wir da gebaut haben, ja, 2012, war ein 460 00:35:40,330 --> 00:35:44,590 Verfahren, McOE, da kann man jetzt irgendwie, wenn man da jetzt irgendwie 461 00:35:44,590 --> 00:35:48,820 Probleme hat mit den Nonces, eine Nonce wiederholt, dann ist hier immer noch, die 462 00:35:48,820 --> 00:35:52,640 Integrität immer noch gewährleist, Integritätsschutz, und die Vertraulichkeit 463 00:35:52,640 --> 00:35:56,890 bleibt auch noch irgendwie.. je nachdem, wie schlimm man da Fehler macht, noch 464 00:35:56,890 --> 00:36:00,140 teilweise erhalten, oder eventuell auch ganz. Also was man auf jeden Fall erkennen 465 00:36:00,140 --> 00:36:07,140 kann, wenn man Nonce wiederholt, dass zwei Klartexte den gleichen Prefix haben. Das 466 00:36:07,140 --> 00:36:10,700 konnten wir eben nicht wegkriegen, wenn wir nur einmal über den Klartext gehen. 467 00:36:10,700 --> 00:36:15,880 Genau. Das.. die Idee hat sich dann irgendwie fortgepflanzt, d.h. da gab es 468 00:36:15,880 --> 00:36:20,450 dann auch diesen CAESAR Competition, und das R steht auch für Robust. Das.. genau. 469 00:36:20,450 --> 00:36:24,080 Und die CAESAR Competition sucht halt einen Nachfolger für GCM. Ja, das ist eine 470 00:36:24,080 --> 00:36:27,800 Crypto Competition, auch von Dan Bernstein, der hat die da angetriggert, 471 00:36:27,800 --> 00:36:31,760 ist der Schirmherr. Und da haben jetzt einen Nachfolger von McOE, auch, da hab 472 00:36:31,760 --> 00:36:35,780 ich auch mit.. POET - da war ich auch wieder mit dabei gewesen - ins Rennen 473 00:36:35,780 --> 00:36:39,450 geschickt. Wir haben es in die zweite Runde gepackt, leider nicht in die dritte, 474 00:36:39,450 --> 00:36:42,830 weil wir waren wahrscheinlich ein bisl zu super-schwergewichtig und auch nicht so 475 00:36:42,830 --> 00:36:48,620 performant auf Hardware. Was noch im Rennen ist, was ich empfehlen kann: COLM, 476 00:36:48,620 --> 00:36:52,450 das ist ein Zusammenschluss aus AES-COPA und ELmD. Das waren praktisch zwei 477 00:36:52,450 --> 00:36:55,630 Zweirunden-Verfahren, die sind jetzt.. haben sich zusammengeschlossen, ist jetzt 478 00:36:55,630 --> 00:36:59,760 noch Drittrunden-Kandidat, was es jetzt noch gibt, was ich noch empfehlen kann, 479 00:36:59,760 --> 00:37:05,200 beim CAESAR Competition, was man näher anschauen kann, ist AEZ, AEZ ist ein MRAE- 480 00:37:05,200 --> 00:37:11,490 Scheme, mit von Phil. Und genau, zumindest hat der Phil mitgemacht, das sind die zwei 481 00:37:11,490 --> 00:37:14,530 Kandidaten, die ich da noch empfehlen kann. Genau und jetzt schauen wir uns mal 482 00:37:14,530 --> 00:37:20,109 an, also alle die Verfahren, ja, sind irgendwie beweisbar sicher. Und genau. Und 483 00:37:20,109 --> 00:37:22,820 das heißt, da gibt es immer so einen Sicherheitsbeweis. Und da gibt's immer.. 484 00:37:22,820 --> 00:37:25,480 irgendwie da unten.. das schauen wir uns mal man hier: also das ist jetzt so eine 485 00:37:25,480 --> 00:37:29,630 Sicherheitsschranke, und wenn man einfach sieht, hier hat man da.. ist das eine 486 00:37:29,630 --> 00:37:34,400 Birthday Security-Bound. Also die haben alle so komische Bounds. Ja und da gibt es 487 00:37:34,400 --> 00:37:39,130 jetzt so drei Parameter: q, l und t. q ist die Anzahl Nachrichten, die man damit 488 00:37:39,130 --> 00:37:42,732 verschlüsselt, l sind die Anzahl Blöcke, die man insgesamt verschlüsselt und t ist 489 00:37:42,732 --> 00:37:48,160 die Zeit. Und was hier steht ist, ihr könnt ungefähr so 100 Terabyte unter einem 490 00:37:48,160 --> 00:37:51,110 Schlüssel verschlüsseln, ein paar hundert Terabyte, und dann sollt ihr den Schlüssel 491 00:37:51,110 --> 00:37:55,500 wechseln. Genau. Und natürlich ist es nur sicher, wenn auch AES sicher ist, wer 492 00:37:55,500 --> 00:37:59,150 hätte es gedacht, weil das Ding nutzt ja irgendwie AES. Und ja genau. Also und die 493 00:37:59,150 --> 00:38:03,099 Idee ist auch irgendwie bei POET, das ist immer so'n.. also das ist halt super 494 00:38:03,099 --> 00:38:07,490 strong, ja so das Superheavyweight, weil wir machen hier die erste lane, obere 495 00:38:07,490 --> 00:38:12,160 lane, ist einfach nur eine Prüfsumme über den Klartext, die untere lane ist eine 496 00:38:12,160 --> 00:38:17,799 Prüfsumme über den Chiffretext und in der Mitte drin ist die Verschlüsselung. Genau, 497 00:38:17,799 --> 00:38:22,190 d.h. die kryptographische Prüfsumme ist ja ziemlich, irgendwie.. wenn Klartext und 498 00:38:22,190 --> 00:38:26,060 Chiffretext.. und das zweite coole Ding, ja, wenn ich hier jetzt z.B. was 499 00:38:26,060 --> 00:38:33,380 manipuliere bei C 2, dann kommt ab M 2 weißes Rauschen raus. D.h. da kann ich 500 00:38:33,380 --> 00:38:37,210 auch wieder.. da ist auch wieder die Idee, wenn man jetzt die Verifikation jetzt 501 00:38:37,210 --> 00:38:41,210 nicht richtig macht, dass man da viel weißes Rauschen hat und dass damit 502 00:38:41,210 --> 00:38:45,040 irgendwie vielleicht auffallen könnte bei der Eingabe-Validierung. D.h. da ist jetzt 503 00:38:45,040 --> 00:38:48,220 auch noch irgendwie so ein bisschen Schutz drin, das, wenn man die Verifikation nicht 504 00:38:48,220 --> 00:38:52,070 richtig hinbekommt. Also if-Abfrage ist nicht immer ganz einfach zu 505 00:38:52,070 --> 00:38:55,930 implementieren. Genau, jetzt bin ich auch schon so gut wie durch. Das ist gleich 506 00:38:55,930 --> 00:38:58,290 geschafft, dann darf wieder Ruedi. *lacht* 507 00:38:58,290 --> 00:39:01,670 Und genau, also was ich mit.. das, was ihr tun sollt: niemals nicht eine Nonce 508 00:39:01,670 --> 00:39:04,390 wiederholen! Das ist eine mittlere Katastrophe, das ist also, das ist 509 00:39:04,390 --> 00:39:09,880 praktisch so ein Unfall. Das ist irgendwie.. genau. Also, und jetzt die 510 00:39:09,880 --> 00:39:13,450 Frage, so, sei wie soll ich meine Daten verschlüsseln? Da gibt es jetzt wie 511 00:39:13,450 --> 00:39:20,200 gesagt, mal schauen, also da gibt es jetzt 4 Kategorien: die erste ist die stärkste, 512 00:39:20,200 --> 00:39:23,590 die vierte ist die schwächste, und man sollte schauen, dass man jetzt irgendwie 513 00:39:23,590 --> 00:39:27,150 schaut, kann ich ein Verfahren aus der Kategorie 1 nehmen? Lässt das mein .. 514 00:39:27,150 --> 00:39:30,330 irgendwie, mein Umfeld zu, meine Anforderungen? Wenn nicht, dann 2, wenn 515 00:39:30,330 --> 00:39:34,160 nicht 3 und ansonsten 4. D.h. eine klassische Verschlüsselung, die wir so 516 00:39:34,160 --> 00:39:37,720 kennen, ist so halt ziemlich das schwächste - schlechteste - was man tun 517 00:39:37,720 --> 00:39:41,550 kann. D.h. wir müssen jetzt irgendwie schauen, dass wir mal da besser werden und 518 00:39:41,550 --> 00:39:46,310 mal so auf 1 und 2 kommen und nicht nur bei 3 und 4 rumdümpeln hier. Damit die 519 00:39:46,310 --> 00:39:49,200 Verahren auch robuster und stärker werden in Zukunft. 520 00:39:49,200 --> 00:39:53,620 ruedi: OK, vielen Dank, ah, dein Zitat noch! *lacht* 521 00:39:53,620 --> 00:39:56,660 cforler: Ah, ich hab noch eins, ja, genau - also, allerwichtigste Botschaft für 522 00:39:56,660 --> 00:40:00,930 heute ist: Redet verdammt noch mal mit Kryptographen, ja! Also, ihr macht ja 523 00:40:00,930 --> 00:40:04,430 einen Haufen cooler Software und die fällt dann auseinander, weil man nie mit uns 524 00:40:04,430 --> 00:40:07,240 geredet hat. *lacht* 525 00:40:07,240 --> 00:40:11,960 Also wir sind irgendwie beide.. unsere E-Mail-Adresse, unsere Telefonnummer sind 526 00:40:11,960 --> 00:40:18,150 irgendwie im Internet, stehen die, und da kann man uns mal sprechen und, ja. 527 00:40:18,150 --> 00:40:24,510 *lacht* *Applaus* 528 00:40:24,510 --> 00:40:27,910 und genau, also man kann irgendwann mal nach Berlin kommen und mit uns reden. Bei 529 00:40:27,910 --> 00:40:30,590 einem Käffchen. ruedi: Ja, noch mal also vielen Dank. Ich 530 00:40:30,590 --> 00:40:35,190 möchte das auch noch einmal ein bisl aufgreifen, also damit es noch mal ganz 531 00:40:35,190 --> 00:40:40,560 klar ist, dass das jetzt wirklich ein praxisrelevantes Problem ist. Also wenn 532 00:40:40,560 --> 00:40:43,040 ich mich nicht täusche, also das ändert sich, aber als ich das letzte Mal 533 00:40:43,040 --> 00:40:47,890 reingeguckt hab, war wirklich in TLS die Überlegung: Wir sind clever, wir benutzen 534 00:40:47,890 --> 00:40:52,680 keine Verfahren, wo nicht Authentifizierung mit eingebaut ist und 535 00:40:52,680 --> 00:40:59,880 wir verwenden zwangsweise das GCM, also Galois/Counter Mode. Das ist auch supi, 536 00:40:59,880 --> 00:41:03,490 bis auf die Tatsache, wenn ein Nonce wiederholt wird, ist das katastrophal 537 00:41:03,490 --> 00:41:08,000 schwächer als alle katastrophal.. alle Fehler, die man auf der unteren Ebene 538 00:41:08,000 --> 00:41:13,530 machen kann. Also Kryptographie ist relativ schwer. Aber noch einmal der Apell 539 00:41:13,530 --> 00:41:18,200 von Christian wirklich deutlich wiederholt: die Crypto-Gemeinde hat einen 540 00:41:18,200 --> 00:41:23,720 starken wissenschaftlichen Teil, die auch offen publizieren und so weiter. Also 541 00:41:23,720 --> 00:41:27,960 insofern noch einmal da der Hinweis: da mal rein zu gucken, was da ist, ist 542 00:41:27,960 --> 00:41:33,170 wirklich eine gute Idee. Und nochmal wirklich an dieses: redet mit 543 00:41:33,170 --> 00:41:36,730 Kryptographen, mal anbuzzen.. kommt jetzt der Grund, warum hier so voll ist: weil 544 00:41:36,730 --> 00:41:41,160 wir noch was mit Blockchain machen wollen in diesen nächsten Folien. Auch da möchte 545 00:41:41,160 --> 00:41:47,690 ich an ein paar Stellen sagen: Ein bisschen reden mit Kryptographen wäre ganz 546 00:41:47,690 --> 00:41:51,730 angenehm gewesen. Also wir arbeiten da auch an verschiedenen virtuellen 547 00:41:51,730 --> 00:41:56,570 Kooperationspartnern, also wir möchten da auch besser werden in Richtung verteilter 548 00:41:56,570 --> 00:42:02,090 Echtzeit, aber da arbeiten wir schon *lacht* intensiv daran. Also wer da noch 549 00:42:02,090 --> 00:42:05,260 weitere Tips hat, was es da noch für Forschungseinrichtungen gibt, der kann 550 00:42:05,260 --> 00:42:12,500 sich auch bei uns freundlich melden. So, mal ein paar Worte zu Bitcoin. Ich hab's 551 00:42:12,500 --> 00:42:15,720 mal schon vor Jahren hier gemacht, ich hätte damals vielleicht Bitcoin kaufen 552 00:42:15,720 --> 00:42:19,410 sollen, anstatt das zu.. sicherheits zu evaluieren. - Nein, hätte ich nicht - soll 553 00:42:19,410 --> 00:42:23,360 man nicht machen, ich bin da altmodischer Professor. Ich bin der Meinung - wenn da 554 00:42:23,360 --> 00:42:29,900 von.. also, von führenden kapitalistischen Zeitungen gefragt wird, wie sicher das ist 555 00:42:29,900 --> 00:42:34,640 - dann solltest du nicht irgendwelche Aktien drin haben, um da zu antworten. Ich 556 00:42:34,640 --> 00:42:42,190 will es mal so sagen: die Kryptographie in Bitcoin wäre eine befriedigende 557 00:42:42,190 --> 00:42:47,450 Bachelorarbeit. Das sind schon.. und das reicht eigentlich. Die Crypto ist so 558 00:42:47,450 --> 00:42:51,790 stark, dass eine befriedigende Bachelorarbeit völlig dazu führt, dass die 559 00:42:51,790 --> 00:42:56,960 Probleme woanders zu sagen sind. Es ist vorsichtige Amateur-Kryptographie. Doppelt 560 00:42:56,960 --> 00:43:01,280 hält besser, die hashen zweimal hintereinander, aber wie gesagt, meine 561 00:43:01,280 --> 00:43:06,160 Erweiterung, nach dem ersten Hash ein Bit umzurempeln und dann weiter zu hashen 562 00:43:06,160 --> 00:43:10,369 würde bedeuten, dass z.B. die Kollisionseigenschaften sich nicht einfach 563 00:43:10,369 --> 00:43:14,470 weiter vererben. Also diese zweimal Hash hintereinander bringen z.B. gegen 564 00:43:14,470 --> 00:43:18,270 Kollision nicht allzu viel, wenn sie nach dem ersten Hash ein Bit gerempelt hätten, 565 00:43:18,270 --> 00:43:22,049 weiter gehasht, hätten sie eine deutlich bessere.. bessere Eigenschaften gehabt. 566 00:43:22,049 --> 00:43:27,589 Also so ist jetzt das Doppelhash ziemlich.. nicht besonders relevant. Also 567 00:43:27,589 --> 00:43:31,971 jedenfalls, wenn man starke Sachen macht. Was relativ cool ist, ist dass die die 568 00:43:31,971 --> 00:43:36,810 Public Keys nicht veröffentlichen, sondern halt hier auch eine zweimal gehashte 569 00:43:36,810 --> 00:43:41,080 Kontonummer. Und da sieht man, dass die möglicherweise doch ein paar Hacker- 570 00:43:41,080 --> 00:43:45,280 Konferenzen gehört haben und gewusst haben, sie sind nicht so fit in Crypto: 571 00:43:45,280 --> 00:43:49,780 "Machen wir es lieber mal ein bisschen robuster", und so weiter. Insofern ist das 572 00:43:49,780 --> 00:43:56,380 eigentlich relativ erfreulich, aber wenn die jungen Leute mit.. oder alten Leute, 573 00:43:56,380 --> 00:44:00,220 oder was immer für Leute, mal mit Kryptographen geredet hätten, hätten wir 574 00:44:00,220 --> 00:44:06,540 ganz interessante Implikationen gehabt. Es ist ganz lustig, der Bitcoin-Hauptautor 575 00:44:06,540 --> 00:44:11,849 hat gesagt: "Oh ja, jetzt hashen die, alle Leute, mit Spezialhardware, und unser 576 00:44:11,849 --> 00:44:16,760 demokratischer Ansatz 'jeder PC hat eine Stimme und alles verteilt' geht den Bach 577 00:44:16,760 --> 00:44:20,530 runter. Wir sollten ein Gentlemen's Agreement machen, dass nur auf CPUs 578 00:44:20,530 --> 00:44:22,530 gemined wird." *Lachen* 579 00:44:22,530 --> 00:44:25,950 *ruedi seufzt* Ach, ist das schön, junge Leute! Dann.. 580 00:44:25,950 --> 00:44:27,320 ich mache einen.. *lacht* 581 00:44:27,320 --> 00:44:31,240 ein Konzept von kryptogra.. äh, von kapitalistischen Anarchisten, die 582 00:44:31,240 --> 00:44:35,170 irgendwie alles so designen, dass keine zentrale Stelle ist, und will mit diesen 583 00:44:35,170 --> 00:44:40,740 verteilten Anarcho-Kapitalisten weltweit Gentlemen's Agreements zu machen. Ohne der 584 00:44:40,740 --> 00:44:43,020 Geschichte vorzugreifen: es ist nur beschränkt gelungen. 585 00:44:43,020 --> 00:44:49,000 *Lachen* Wobei das wirkt alles lustig, da, wenn 586 00:44:49,000 --> 00:44:52,550 schlecht bezahlte Berliner Professoren hier rum[unverständlich] und gute Witze darüber 587 00:44:52,550 --> 00:44:56,360 machen, das Problem ist, wenn man hier Fehler macht, dann hat das auf einmal 588 00:44:56,360 --> 00:45:02,250 Auswirkungen, dass irgendwie eine große Menge an Energie völlig sinnlos verheizt 589 00:45:02,250 --> 00:45:04,971 wird. Und da muss ich auch sagen, am Anfang habe ich gesagt, oh, Leute kommt 590 00:45:04,971 --> 00:45:09,160 runter, es ist EIN Kraftwerk - was mir dann erst irgendwann mal siedend heiß 591 00:45:09,160 --> 00:45:14,210 eingefallen.. ne, mit Erhöhung der Hashing-Komplexität tut praktisch linear 592 00:45:14,210 --> 00:45:19,450 auch der Stromverbrauch irgendwie steigen. Also es ist jetzt schon auf dem Weg, eine 593 00:45:19,450 --> 00:45:24,640 deutliche Umwelt-Sauerei zu werden und wir Krypto-Hippies könnten natürlich sagen: 594 00:45:24,640 --> 00:45:29,170 "Können wir wenigstens nur mit Wasserkraft minen?" usw, aber unser Einfluss auf 595 00:45:29,170 --> 00:45:35,890 verteilte krypto- und kapitalistischen Anarchisten ist relativ überschaubar. Also 596 00:45:35,890 --> 00:45:42,560 insofern ist es wirklich kein Witz, dass einige Sachen, die wir haben.. wirklich es 597 00:45:42,560 --> 00:45:47,050 hilfreich gewesen wäre, wenn die mit Kryptographen geredet hätten. Und hier 598 00:45:47,050 --> 00:45:50,550 haben wir auch ein Bild, was ich mal einfach mal vorstellen wollte: Dieses 599 00:45:50,550 --> 00:45:56,590 Proof of Work demokratisch zu halten, das ist sehr verwandt mit der Frage Passwort- 600 00:45:56,590 --> 00:46:00,260 Hashing. Also Passwort-Hashing ist die Idee, aus dem gehashten Passwort soll es 601 00:46:00,260 --> 00:46:05,200 sehr schmerzhaft, sehr arbeitsspeicher- intensiv sein, das Passwort wieder zurück 602 00:46:05,200 --> 00:46:10,240 rechnen. Also klassischer Proof of Work. Dass ihr seht, dass das nicht ganz aus der 603 00:46:10,240 --> 00:46:17,400 Welt ist: scrypt wird z.B. in Lite.. Moment, Litecoin? Litecoin verwendet, das 604 00:46:17,400 --> 00:46:23,010 ist auch eine der größeren Sachen, und die haben scrypt verwendet. Die haben aber 605 00:46:23,010 --> 00:46:26,940 auch nicht mit Kryptographen geredet, wie man die Parameter da vernünftig fährt mit 606 00:46:26,940 --> 00:46:30,640 dem Ergebnis, dass jetzt mit ein bisschen Verspätung da auch ASICs kommen und 607 00:46:30,640 --> 00:46:36,660 dieselbe Problematik, die wir bei Bitcoin haben, haben wir dort genauso. Auch hier 608 00:46:36,660 --> 00:46:39,280 kriege ich manchmal bisschen die Krise, und ich sage, wir hätten das alles 609 00:46:39,280 --> 00:46:43,080 demokratisch regeln können, wenn ihr mit uns geredet hättet. Wir hätten euch 610 00:46:43,080 --> 00:46:46,860 umfangreiche Änderungen gesagt, nämlich genau eine Zahl geändert, einen Parameter 611 00:46:46,860 --> 00:46:51,150 geändert. Dann wäre die ganze Sache auf einmal eine demokratische Veranstaltung 612 00:46:51,150 --> 00:46:55,500 gewesen und nicht so, dass jetzt irgendwie sinnlos Sachen verbrannt werden und 613 00:46:55,500 --> 00:46:59,030 irgendwelche.. nur noch Fabriken mitspielen dürfen. Das ist manchmal selbst 614 00:46:59,030 --> 00:47:02,830 für Hacker und Mathematiker, die wissen, dass Zahlen eine gewisse Magie hat, 615 00:47:02,830 --> 00:47:09,610 relativ gruselig. Also hier einen scrypt- Parameter richtig einzustellen, wär eine 616 00:47:09,610 --> 00:47:15,750 gute Idee. Dann gibt es noch Passwort- Hashingverfahren.. äh, -Wettbewerbe, da 617 00:47:15,750 --> 00:47:19,280 ist Argon2i, ne, war nicht - 2d! *unverständlicher Kommentar aus dem Off* 618 00:47:19,280 --> 00:47:21,750 Du hast den Tippfehler wieder reingemacht, *lacht* 619 00:47:21,750 --> 00:47:25,630 den du vorhin korrigiert hast! cforler: Ja, ja, wieder hinten integriert. 620 00:47:25,630 --> 00:47:28,620 ruedi: Ä-ä-ä, das ist immer... cforler: Problem mit der Versionierung, ja. 621 00:47:28,620 --> 00:47:31,390 ruedi: Das ist "d"! cforler: Das muß "d" sein. 622 00:47:31,390 --> 00:47:34,349 ruedi: Naja, aber Catena-Stonefly, da hat er ja sich auch als Hauptautor 623 00:47:34,349 --> 00:47:39,050 rausgemogelt, also Christian ist der Autor des ganzen Frameworks. 624 00:47:39,050 --> 00:47:41,809 cforler: Mitautor, Co-Autor. ruedi: Co-Autor, ach so. 625 00:47:41,809 --> 00:47:45,240 cforler: Das hab ich zusammen mit Stefan Lucks und Jakob Wenzel gemacht. 626 00:47:45,240 --> 00:47:49,730 ruedi: Und das Catena-Stonefly ist eine Implementierung, die ganz besonders diese 627 00:47:49,730 --> 00:47:56,231 Sachen adressiert, und - ne, haben wir die nicht - also, so sieht das aus, also ihr 628 00:47:56,231 --> 00:48:02,200 seht, das ist ein bisschen was. Aber wenn man irgendwie große Geschichten jetzt 629 00:48:02,200 --> 00:48:06,349 erwartet, ist es relativ überschaubar. Also das sind relativ naheliegende 630 00:48:06,349 --> 00:48:10,470 Funktionen und das schöne ist halt an den Arbeiten von Forler et al., 631 00:48:10,470 --> 00:48:13,930 *lacht* dass da also sehr brutale Sicherheits.. 632 00:48:13,930 --> 00:48:17,960 also sehr ordentliche mathematische Sicherheitsschranken da ist. Also nochmal, 633 00:48:17,960 --> 00:48:21,560 man könnte scrypt nehmen mit ein bisschen cleveren Parametern, oder man könnte das 634 00:48:21,560 --> 00:48:26,030 andere Passwort-Hashing machen und dann hätte man mathematisch beweisbar, dass die 635 00:48:26,030 --> 00:48:30,550 Leute nicht das auf Spezialhardware relativ einfach machen können. Also 636 00:48:30,550 --> 00:48:34,360 nochmal diese Sache, die wir mehrfach gesagt.. redet mit Kryptographen. Noch 637 00:48:34,360 --> 00:48:39,420 einmal, eine Zahl in diesen bitcoinartigen Sachen richtig gesetzt, hätten wir es 638 00:48:39,420 --> 00:48:44,400 weiterhin demokratisch. Nicht mit Kryptographen geredet, gesagt: "OK, wir 639 00:48:44,400 --> 00:48:47,700 machen Gentlemen's Agreement" bedeutet halt, dass irgendwie im Moment eine 640 00:48:47,700 --> 00:48:52,410 obszöne Menge an Energie einfach fürs Mining verbrannt wird, und zwar völlig 641 00:48:52,410 --> 00:48:55,990 nutzlos. Entschuldigung, ich stehe eigentlich auf Hashfunktionen, aber 642 00:48:55,990 --> 00:48:59,260 irgendwie sinnlos irgendwie da vor sich hin zu hashen und alles wegzuschmeißen, 643 00:48:59,260 --> 00:49:04,040 das kann nicht so die pfiffige Idee sein. Wenn man Proof of Work ist, noch einmal, 644 00:49:04,040 --> 00:49:08,480 hier wäre es hilfreich gewesen, entweder also mit Kryptographen zu reden oder 645 00:49:08,480 --> 00:49:17,030 zumindestens mal die Damen und Herren von Litecoin: Da mal überlegen, dass man die 646 00:49:17,030 --> 00:49:21,160 Parameter vielleicht ein bisschen ordentlich setzen könnte. Gut, ich bin der 647 00:49:21,160 --> 00:49:27,750 Meinung, dass wir wegkommen müssen von dem sinnlosen Heizen und deswegen werd ich in 648 00:49:27,750 --> 00:49:31,190 den nächsten Monaten auch mit einem Doktoranden zusammen mal ein bisschen 649 00:49:31,190 --> 00:49:37,510 arbeiten, Proof of Work nützlich zu machen. Da sind schon Ideen da, die im 650 00:49:37,510 --> 00:49:42,460 Bereich Storage sind, da ist Filecoin z.B. ein Kandidat, der ähnliche Sachen macht. 651 00:49:42,460 --> 00:49:46,829 Oder Network Services: ich habe durchaus die Überlegung dass es vielleicht sinnvoll 652 00:49:46,829 --> 00:49:52,750 ist, bei der Anonymisierung des Webtraffics nicht auf das Tor-Projekt zu 653 00:49:52,750 --> 00:49:55,030 vertrauen, dass seine Hauptfinanzierung vom amerikanischen 654 00:49:55,030 --> 00:50:00,940 Verteidigungsministerium hat. Also ich hätte ganz gerne eine Konstruktion, wo 655 00:50:00,940 --> 00:50:06,240 Router Netzwerk-Service, Tor-artige Services anbieten und damit praktisch auch 656 00:50:06,240 --> 00:50:10,600 nebenher minen. Also dass praktisch Geräte sich selbst finanzieren und wenn man 657 00:50:10,600 --> 00:50:14,150 irgendwie halt mal ein bisschen träumt, dann kann man halt sagen, man entwickelt 658 00:50:14,150 --> 00:50:18,040 einen Router, den stellt man in der dritten Welt in die Sonne, solange Sonne 659 00:50:18,040 --> 00:50:24,120 ist, tut der Energie machen und Services machen und wenn die Sonne weg ist, holt er 660 00:50:24,120 --> 00:50:28,160 den Strom, aber bezahlt das mit der Arbeit, die er gemacht hat. Also dieser 661 00:50:28,160 --> 00:50:32,980 Traum eines wirklich ganz autonomen Systems, das möchte ich noch auferhalten, 662 00:50:32,980 --> 00:50:37,339 vielleicht einen Schritt zurück, ich hab einfach keine Lust, dass irgendwie Mining 663 00:50:37,339 --> 00:50:45,609 - also wirklich 2^17 oder 2^73 Operationen - immer in sinnlose Umsetzung von Strom, 664 00:50:45,609 --> 00:50:49,060 in Wärme, gemacht werden. Also vielleicht gibts.. 665 00:50:49,060 --> 00:50:51,185 *Applaus* Ja, Dankeschön. 666 00:50:51,185 --> 00:50:56,770 *Applaus* 667 00:50:56,770 --> 00:50:59,100 *Applaus* Und um es noch einmal zu wiederholen, den 668 00:50:59,100 --> 00:51:03,940 ganzen Mist hätte man.. also diese Sachen sind anspruchsvoll und da sind sehr viele 669 00:51:03,940 --> 00:51:07,711 Fragen zu klären, deswegen ist es eine schöne Promotion und ich bin da ein 670 00:51:07,711 --> 00:51:11,220 altmodischer Professor, wenn es irgendwie die Welt nicht revolutioniert, 'ne gute 671 00:51:11,220 --> 00:51:14,630 Promotionsthema ist es auf jeden Fall. *Lachen* 672 00:51:14,630 --> 00:51:18,220 Insofern passiert die Revolution im Rahmen meiner dienstlichen Aufgaben, was 673 00:51:18,220 --> 00:51:22,410 irgendwie von Professoren in meinem Alter immer eine ganz angenehme Perspektive auch 674 00:51:22,410 --> 00:51:26,829 ist. Aber um es noch einmal zu betonen, wenn die Damen und Herren, die das gemacht 675 00:51:26,829 --> 00:51:30,390 hätten, wirklich das Passwort-Hashing angeguckt hätten, wenn diese Litecoin- 676 00:51:30,390 --> 00:51:35,180 Leute die Parameter richtig gemacht hätten, also nochmal: Macht euch die Kraft 677 00:51:35,180 --> 00:51:38,990 von euch Programmierern und Mathematikern, und ne, sogar von euch Programmierern, 678 00:51:38,990 --> 00:51:42,730 lest die Mathematik, die wir euch präsentieren, setzt die Zahl richtig und 679 00:51:42,730 --> 00:51:46,430 ihr habt eine bessere Welt dadurch. Zumindestens, sagen wir mal, in dieser 680 00:51:46,430 --> 00:51:51,190 virtuellen Welt, warte mal ab mit den Auswirkungen. Aber noch einmal, ich sage, 681 00:51:51,190 --> 00:51:56,880 also erstens möchte ich einen wirklichen Proof of nützlicher, gesellschaftlich 682 00:51:56,880 --> 00:52:01,640 nützlicher Arbeit. Zweitens, wenn ich dieses alte Proof of Work mach, das hätten 683 00:52:01,640 --> 00:52:05,609 wir weiterhin demokratisch gehalten, wenn die Leute dieses Passwort-Hashing gemacht 684 00:52:05,609 --> 00:52:09,960 hätten. Entweder das scrypt oder halt, sagen wir mal, die Sachen mit richtig hart 685 00:52:09,960 --> 00:52:14,140 brutalen Sicherheitsbeweisen, die Christian da unter anderem entwickelt hat. 686 00:52:14,140 --> 00:52:19,540 Kommen wir noch mal zum Ende. 'Wir sollten was tun' ist irgendwie das Ding, und ich 687 00:52:19,540 --> 00:52:23,940 habe ja damals gesagt, Krypto-Magie ist, dass man auf einer kleinen, 688 00:52:23,940 --> 00:52:28,650 fingernagelgroßen Fläche, oder mit ein paar Programmierzeilen, Code erzeugen 689 00:52:28,650 --> 00:52:32,400 kann, den die Geheimdienste nicht brechen können. Das hat schon ein bisschen was 690 00:52:32,400 --> 00:52:37,329 magisches, die.. problematisch ist, wenn man halt nicht reingucken kann und die 691 00:52:37,329 --> 00:52:42,430 Leute das halt schlecht implementieren, wie das jetzt bei Infineon in Zusammenhang 692 00:52:42,430 --> 00:52:47,910 mit den TPM-Chips passiert hat. - Oh, da haben wir eine Folie, die muss ich, glaube 693 00:52:47,910 --> 00:52:55,079 ich, nachhalten. - Also bei den TPM-Chips, Infenion war einer der Hauptkandidaten, 694 00:52:55,079 --> 00:52:59,230 und da ist es einfach so, das ist zwar vom BSI zertifiziert worden, aber 695 00:52:59,230 --> 00:53:02,510 offensichtlich reicht das nicht aus. Wenn das Open Source gewesen wäre, wenn man da 696 00:53:02,510 --> 00:53:06,430 reingucken könnte, dann hätte ein talentierter Doktorand wirklich nur wenige 697 00:53:06,430 --> 00:53:10,470 Stunden gebraucht, um aufzuschreien und den Fehler zu finden. Also wir brauchen 698 00:53:10,470 --> 00:53:16,720 wirklich auf der untersten Ebene Open Source ganz dringend. Wir brauchen freie 699 00:53:16,720 --> 00:53:20,040 Software, die verhindert Hintertüren und ermöglicht das Finden der Fehler. Noch mal 700 00:53:20,040 --> 00:53:25,680 zusammenzufassen: das BSI ist gutmütig, sie haben auch sehr gute Kryptographen, 701 00:53:25,680 --> 00:53:29,840 aber sie haben es nicht gefunden. Und BSI ist noch eine der staatlichen 702 00:53:29,840 --> 00:53:34,339 Organisationen, die ich noch am ehesten vertraue, sie haben es da episch gefailed. 703 00:53:34,339 --> 00:53:38,849 Nochmal zur Erinnerung, diese Infineon- Chips stecken in den ganzen Google 704 00:53:38,849 --> 00:53:43,400 Chromebooks an, wo in Amerika wirklich eine ganze Generation von Schülern mit 705 00:53:43,400 --> 00:53:48,829 rumspringt: die haben's vermasselt. Also offensichtlich klappt es nur, wenn es 706 00:53:48,829 --> 00:53:54,280 öffentlich ist und da darf ich noch mal auf meine geschätzten Kolleginnen und 707 00:53:54,280 --> 00:54:02,360 Kollegen Bernstein, Lange und Nadja ... äh, Namen vergessen? 708 00:54:02,360 --> 00:54:05,360 cforler: Tanja? ruedi: Heninger. Heninger, Entschuldigung. 709 00:54:05,360 --> 00:54:11,599 Nadja Heninger. In dem Vortrag war einer der Highlights, wo sie gezeigt haben: Ha! Da 710 00:54:11,599 --> 00:54:15,599 sind die Ergeb.. da sind die Submissions, Veröffentlichungen für diese Post-Quantum 711 00:54:15,599 --> 00:54:19,680 Sache und innerhalb des ersten Abends, die haben sich wirklich einen Spaß gemacht, 712 00:54:19,680 --> 00:54:25,220 und haben irgendwie 10 % von den Sachen innerhalb von drei Stunden zertrümmert. 713 00:54:25,220 --> 00:54:28,880 Nehmen wir einfach mal zur Kenntnis, die öffentliche Kryptographie ist so viel 714 00:54:28,880 --> 00:54:34,510 besser als Kryptographie hinter verschlossenen Türen. Dass das wirklich 715 00:54:34,510 --> 00:54:38,609 hier ein Punkt ist: es ist nix ideologisches, aber der Code muss lesbar 716 00:54:38,609 --> 00:54:43,150 sein. Das ist vernünftigerweise unter Open-Source-Lizenz, aber er muss lesbar 717 00:54:43,150 --> 00:54:47,000 sein, die Community muss da reingucken. Keine Behörde ist offensichtlich dazu in 718 00:54:47,000 --> 00:54:52,079 der Lage, das in irgendeiner Weise ordentlich zu machen. Der letzte Teil wird 719 00:54:52,079 --> 00:54:59,560 nicht bei 'tuwat!' - Dankeschön. *Applaus* 720 00:54:59,560 --> 00:55:02,950 Der letzte Teil von 'tuwat!' ist auch ein bisschen launisch, das habe 721 00:55:02,950 --> 00:55:08,190 ich mir erlaubt, aber da irgendwie die Mathematik scheinbar so abschreckend ist, 722 00:55:08,190 --> 00:55:13,119 dass es kaum jemand programmiert, gehen jetzt immer mehr Mathematiker dazu über, 723 00:55:13,119 --> 00:55:16,720 brandneue Protokolle direkt zu implementieren. Als Erstes muss ich 724 00:55:16,720 --> 00:55:21,510 sehr.. als sehr positives Beispiel den Herrn Kollegen Heiko Stamer erwähnen, der 725 00:55:21,510 --> 00:55:26,140 hat auch am Datengarten einen sehr schönen Vortrag gemacht, da ging es um verteilte 726 00:55:26,140 --> 00:55:28,960 Schlüsselerzeugung und Schwellenwertkryptographie. Da sind so 727 00:55:28,960 --> 00:55:33,070 Sachen, wie wenn man sagt, in einer Welt, wo man wenig Leuten vertrauen kann, ist es 728 00:55:33,070 --> 00:55:37,190 gut kryptographische Verfahren haben, wo man mathematische Beschreibung hat, des 729 00:55:37,190 --> 00:55:40,790 Vertrauens. Also muss man einem aus einer Gruppe vertrauen, zwei aus einer Gruppe.. 730 00:55:40,790 --> 00:55:43,770 das können wir alles mit Schwellenwertkryptographie ganz gut 731 00:55:43,770 --> 00:55:50,010 machen. Wie gesagt, das sind ganz aktuelle Implementierungen von 2017, die Arbeiten 732 00:55:50,010 --> 00:55:56,120 vorher sind auch relativ neu, die sind von 1987. 733 00:55:56,120 --> 00:56:00,013 *Kichern* Ja, ihr könnt ruhig lachen, das ist ein 734 00:56:00,013 --> 00:56:04,410 Weilchen her, aber ihr könnt auch auf diese Folie warten, weil diese Sachen - 735 00:56:04,410 --> 00:56:09,089 oh, das ist jetzt auch rausgeflogen - Blind Signature, wo ich also mit einem 736 00:56:09,089 --> 00:56:14,470 Masterstudenten von mir ein bisl was entwickelt hab, 2016, auch auf der Open 737 00:56:14,470 --> 00:56:19,569 TechSummit vorgestanden hab, basiert auf Blind Signature von David Chaum und die 738 00:56:19,569 --> 00:56:24,750 sind von 1983. Und wir haben uns auch nur soviel Zeit gemacht, weil jetzt die 739 00:56:24,750 --> 00:56:28,010 Patente endlich abgelaufen sind. *Lachen* 740 00:56:28,010 --> 00:56:33,270 Spaß beiseite. Nicht alles, was wir hier machen.. also, elliptische Kurven ist 741 00:56:33,270 --> 00:56:39,109 schon relativ harte Mathematik. Auch die Schwellwertkryptographie ist durchaus 742 00:56:39,109 --> 00:56:42,450 harte Mathematik. Ich will das gar nicht so sagen: "Also guckt es einfach an, dann 743 00:56:42,450 --> 00:56:47,360 ist es lösbar". Aber es gibt einen ganzen Kanon voll Sachen, wo es wirklich eine 744 00:56:47,360 --> 00:56:51,710 kurze Frage an Kryptographen benötigt, um dann den richtigen Tipp in die richtige 745 00:56:51,710 --> 00:56:56,900 Richtung zu machen. Auch diese Sache, dass wir halt programmieren, das war jetzt ein 746 00:56:56,900 --> 00:57:02,760 bisschen arg schnippisch gesagt also: "Wir tun idiotensichere Krypto entwickeln". 747 00:57:02,760 --> 00:57:06,880 Idiotensicher ist ein relativer Begriff. Ein armes, eingebettetes Gerät ohne 748 00:57:06,880 --> 00:57:13,650 externe.. ohne interne Zufallsquelle hat halt keine gute Zufallsquelle. Also 749 00:57:13,650 --> 00:57:19,220 insofern noch einmal, also wir arbeiten wirklich an einem System, möglichst robust 750 00:57:19,220 --> 00:57:22,690 zu sein, in anderen Worten. Eine Nachricht, die hier noch einmal vielleicht 751 00:57:22,690 --> 00:57:28,069 an die Standardisierung geht, ist wirklich der Punkt, zu sagen, GCM ist 752 00:57:28,069 --> 00:57:32,980 offensichtlich für einige Probleme, also wenn diese Leute richtige Nonces machen - 753 00:57:32,980 --> 00:57:37,359 wunderbar, supi. Aber willkommen in der realen Welt: Angreifer können dann 754 00:57:37,359 --> 00:57:42,180 irgendwie anfangen, eben Nonces zu rempeln und dann auf einmal die Sicherheit und die 755 00:57:42,180 --> 00:57:47,660 Integrität des ganzen Systems nachhaltig gefährden. Insofern ist das, glaube ich, 756 00:57:47,660 --> 00:57:53,690 keine gute Idee, das als einzige Sache zu machen. Enden wir mit den guten Worten von 757 00:57:53,690 --> 00:58:00,870 Edward Snowden: "Krypto ist keine dunkle, alte Kunst, sondern es ist wirklich eine 758 00:58:00,870 --> 00:58:06,800 basic Protection, eine grundlegende.. Schutz da, wir müssen implementieren und 759 00:58:06,800 --> 00:58:11,450 aktiv daran forschen". Und noch einmal, um zusammenzufassen, zu sagen, auch nach 760 00:58:11,450 --> 00:58:16,589 vielen Jahren Snowden muss ich sagen, Kryptographie ist das, was uns vor der 761 00:58:16,589 --> 00:58:22,320 Barbarei der Geheimdienste schützt. Die Politik hat da auch in den letzten Jahren 762 00:58:22,320 --> 00:58:26,500 nicht unbedingt sehr gute Ergebnisse gezeigt. Insofern, vielen Dank für eure 763 00:58:26,500 --> 00:58:31,830 Aufmerksamkeit. *Applaus* 764 00:58:31,830 --> 00:58:36,779 cforler: Just in time! ruedi (zu cforler): Oh, da fehlten 1,2 765 00:58:36,779 --> 00:58:46,829 Folien noch... Herald: So es hat ja geheißen, man soll 766 00:58:46,829 --> 00:58:50,950 die Kryptographen fragen, nur leider ist die Zeit jetzt alle. 767 00:58:50,950 --> 00:58:54,119 *Unmuts-Laute* Das heißt, ihr dürft, wie angekündigt, die 768 00:58:54,119 --> 00:58:57,560 Fragen über ein Käffchen stellen, allerdings leider nicht mehr hier drin. 769 00:58:57,560 --> 00:59:02,460 Aber trotzdem eine Runde schönen Applaus für unsere beiden Vortragenden! Vielen 770 00:59:02,460 --> 00:59:06,770 Dank. *Applaus* 771 00:59:06,770 --> 00:59:11,620 *Abspannmusik* 772 00:59:11,620 --> 00:59:28,955 Untertitel erstellt von c3subtitles.de im Jahr 2018. Mach mit und hilf uns!