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:27,970
Abspannmusik