34C3 - Resilienced Kryptographie

34C3 Vorspannmusik

Herald-Engel: So. In unserem nächsten
Vortrag lernt ihr etwas darüber, was

passiert, wenn das tolle TPM und das tolle
Intel ME dann doch irgendwie nicht so toll

sind und was denn schief gehen kann, wenn
man seine Keys auf so nem TPM

initialisieren will. Dazu helfen euch
jetzt gleich die Herrn Professoren

Doktoren Weis und Forler weiter, bitte
einen schönen Applaus!

Applaus

Ruediger Weis: So, also herzlichen Dank
für die nette Einführung, auch herzlichen

Dank für die zahlreichen Zuhörenden. Es
wird heute ein Vortrag, wo ich ein

bisschen auch mit dem Kollegen Forler von
der Realität irgendwie auch ein bisschen

massiv gerempelt worden bin. Eigentlich
war unsere Intention, wirklich zu

diskutieren, wie macht man Kryptographie
robuster, und auch in einem feindlichen

Umfeld. Und ich hab gelernt ein neues
Buzzwort: riesa...lienzte?

lacht
Kryptographie war eigentlich wirklich als

Titel geplant, jedoch müssen wir, glaube
ich, wegen der realen Entwicklung noch ein

paar Einordnungen gleich am Anfang machen.
Also zunächst mal die übliche gute

Nachricht, die ich auch immer gern bring:
wissenschaftlich starke Kryptographie ist

selbst gegen übermächtige
Geheimdienstgegner wahrscheinlich das

Einzige, was überhaupt hält, aber es hält.
Also wir haben einigermaßen die Sachen

verstanden, die Sachen, die
freundlicherweise im Zusammenhang mit der

Snowden-Geschichte veröffentlicht wurden,
zeigten auch, dass die Kryptographen in

der NSA mit Wasser kochen und da gab es
eigentlich für die großen Mengen Geld, die

da rein geworfen wird, relativ wenig
Überraschungen da. Also man kann sagen,

Krypto hält, oder um's mal ein bisschen
lyrischer von Bruce Schneier zu machen:

"Vertraue auf die Mathematik,
Verschlüsselung ist dein Freund". Also

insofern eigentlich eine ganz gute
Situation, bis diese gute Situation auf

die reale Welt kommt. Wir Kryptographen
können wirklich eine Art Magie entwickeln.

Wir können mit ein paar Bits, die man
sicher speichert, wirklich sicher gegen

alle möglichen Angriffe bestehen. Das
Problem ist, wenn diese paar wenigen Bits

aber nimmer sicher sind, dann können wir
halt gar nichts mehr machen. Und man kann

es auch, wenn man es ein bisl modell-
theoretisch macht, kann man auch sagen, na

ja, irgendwas muss die berechtigten
Kommunikations-Partner von den Angreifern

unterscheiden. Und das Kleinste, was wir
anbieten können, sind ein paar wenige

Bits, die sicher gespeichert werden
müssen. Weniger können wir nicht machen.

Also wir sind mit unserem Latein nicht am
Ende, aber eigentlich schon in der

Situation, wo wir gesagt haben, OK passt
auf ein paar Bits auf, mehr können wir

nicht für euch tun. Und genau das ist das,
was ja im Moment episch uns um die Ohren

fliegt. Also es gab hier auch schon einen
sehr interessanten Vortrag, deswegen will

ich auch gar nicht so arg ins Detail zu
gehen, aber der Titel ist einfach zu

schön: "How to hack a turned off
computer", oder dass man beliebigen Code

ausführt auf dieser Management Engine. Und
diese Management Engine ist relativ

spannende Geschichte, insbesondere für
meine Forschungsarbeiten ganz interessant,

weil Dank der Intel Management Engine kann
ich auf die lästerliche Frage, wo mich

eigentlich Leute schon seit Jahrzehnten
immer.. naja, seit anderthalb Jahrzehnten,

damit aufziehen: "Wann ist endlich das
Jahr von Minix auf dem Desktop?" kann ich

inzwischen freundlich grinsen und sag:
"Seit 2012 ist es IN deinem Desktop und

niemand hat's gemerkt". Also diese
Management Engine läuft in der Tat auf

diesem Minix 3, was ein akademisches
Projekt, das irgendwie über Jahre halt

niemand benutzt hat, und jetzt bin ich
auch im Minix Steering Committee und wir

waren ziemlich traurig, dass wenig
Beteiligung letztes Jahr von der Konferenz

war, bis wir dann mitgekriegt haben, dass
das Minix, was wir da entwickelt haben,

wirklich auf allen Intel-Plattformen läuft
und damit ist wirklich diese lästerliche

Bemerkung, dass Minix auf mehr Rechnern
läuft - auf Windows als auch Mac, weil

auch Mac haben die Intel-Hardware und
diese selbe ME-Geschichte drin - ein ganz

witziges Detail, aber wie gesagt, bei den
witzigen Detail ist natürlich das

Hauptproblem da, wenn das nicht ordentlich
gemacht worden ist, dann können da

Sicherheitslücken kommen. Und
offensichtlich ist es so, dass die zwar

dieses Minix genommen haben, das steht
aber halt unter einer freien Lizenz und

nicht GPL, und dann natürlich die ihre
Arbeiten und Modifikationen nicht

veröffentlicht haben und sich
offensichtlich nicht gut genug damit

auskennen, das einigermaßen sicher zu
machen. Minix ist ein militant auf

Sicherheit getrimmtes System, das hat so
Inflexibilitäten, z.B. dass alle

Nachrichten für eine gewisse
Prozessorarchitektur genau 24 Byte lang

sind. Also es gibt sehr wenig
Angriffsvektoren, die wir da haben. Und es

ist ein Microkernel-System, ich weiß nicht
genau, wie die genaue Code-Entwicklung

ist, aber in der Anfangszeit waren wir da
bei unter 10.000 lines of code. Und das

ist auch wieder ein schöner Moment, wo man
als Betriebssystem-Professor relativ

einfach die Welt erklären kann. Linux hat
inzwischen 10 oder 20 Millionen Zeilen of

code. Windows irgendwie 100 Millionen -
frag mich nicht. Und es ist auch so ein

Lemma, dass man sagt, alle 1000 Programm-
Zeilen gibt es einen Fehler. Und jetzt

können wir ausrechnen: das ist bei Minix
halt 20.000 Fehler, äh bei Linux 20.000

Fehler und bei Minix vielleicht eine
Handvoll Fehler, und da könnte man

eigentlich vorbeigehen und das anschauen.
Kleines weiteres Lemma: wie problematisch

sind Fehler? Da ist die Antwort, wenn man
mit C programmiert, kann man davon

ausgehen, dass ein Fehler mit hoher
Wahrscheinlichkeit echte Schmerzen

verursacht. Also die Gruppe der Sachen,
der Fehler, die wirklich zu ignorieren

sind - oder ignoriert werden können - sind
bei C deutlich geringer als bei anderen

Systemen. Insofern sage ich also, die
reine Information, dass Minix ein sehr

kleines System ist, das so klein ist, dass
man es so wunderbar in einer Vorlesung

erklären kann, ist wirklich direkt
verbunden mit der Sicherheit. OK. Neben

diesem Problem, das wir halt Ärger auf der
untersten Ebene haben, war ein anderes

Ding, das wir über Jahre lang auch
verfolgt haben, diese TPM-Diskussion, und

hier gibt es wieder was sehr Bizarres.
Hier, wer ein RSA verwendet, wer

vielleicht meine alten Diskussionen mit
RSA und ECC kennt, weiß, dass ich RSA

eigentlich ganz, ganz, ganz gern hab und das hat
auch eine Reihe von Gründen, nämlich es

gibt Sicherheitsbeweise, wirklich harte
Sicherheitsbeweise, es ist verstandene

Mathematik. Und es ist eine relativ kurze
Implementierung, wo man doch nicht allzu

viel falsch machen kann. Und da das, sage
ich, immer noch ein bisschen ne Hacker-

Konferenz ist, seien mir auch ein paar
Sachen hier erlaubt. Zunächst mal, was ist

RSA? Wir brauchen Primzahlen. Wenn wir
2048-bit-Schlüssel haben, brauchen wir

1024 Bit lange Primzahlen, die
multipliziert man. Erste Frage an den

Mathematiker: gibt's die? Ja, es gibt
Primzahlen in jeder Menge. Zweitens: wie

viel gibt es da? Und da hat man eine
Formel, die sagt, also die Anzahl der

Primzahlen ist etwa x/ln(x), also ganz
grob gesagt, alle 1024 Zahlen sind.. ist

eine Primzahl. Also man hat irgendwie
2^10^15 mögliche Primzahlen und wer ein

bisschen aufpasst, sollte bei
Mathematikern immer zusammenzucken, wenn

die 'in ungefähr gleich' schreiben, dann
bedeutet das, es ist gleich bis auf einen

linearen Faktor,
lacht

der möglicherweise beliebig
groß sein kann.

Lachen
Und das ist für die Leute, die

implementieren, immer so mäßig
befriedigend, deswegen haben wir noch mal

nachgeguckt und für x > 17 gilt, dass
diese Abschätzung schon sehr genau ist.

Und im Vertrauen: für echte Systeme
sollten wir Primzahlen, die deutlich

größer sind als 17 verwenden.
Lachen

Ja, das war ein mathematischer Witz,
vielen Dank für die Leute,

lacht
Lachen

die es gefunden haben. Ok. Zurück zu der
Hacker-Welt. Wie sieht es in der

praktischen Implementierung aus? Schauen
wir uns mal gpg an, das bedeutet, wir

nehmen halt Zahlen, Zufallszahlen, und
testen die dann. Zuerst mit einem Sieve-

Algorithmus, also ein einfaches
Durchteilen der Primzahlen kleiner/gleich

2000.. 400.. äh, 4999. Das muss ich,
glaube ich, hier nicht machen. Der zweite

Teil ist ein Fermat-Test, der ist auch so
niedlich, dass ich den Wikipedia-Artikel

nehm: das ist alles. Und der dritte Test
ist bisl ausführlicher, weil da mit Bit

hin und her geschubst wird, ein bisschen,
aber das ist der komplette Code. Also wir

machen Zufallszahlen und machen diese
Tests, diese wenigen Zeilen Tests durch.

Und haben dann eine hohe
Wahrscheinlichkeit, dass es eine Primzahl

ist, multiplizieren das dann, sind fertig.
Was kann da passieren? Nochmal zur

Erinnerung: wir sind in einem Zahlenraum,
wo wir 2^1015 Primzahlen zur Verfügung

haben, also da kann doch nichts
schiefgehen. Außer man kommt auf die tolle

Idee, wir machen mal ganz schnelle
Primzahl- Erzeugung. Mein erster Eindruck

war: Nein, echt lieber nicht. Dann habe
ich gesagt: "Guck Dir mal die Literatur

an", hab die zwei, drei Tage angeguckt und
dann kam ich zur Entscheidung: Echt lieber

nicht. Und die Praxis haut dann hier auch
nochmal voll auf die Computersicherheit

ein. Nämlich diese TPM-Systeme, die
kriegen das hin, die haben einen

Schlüssel, also einer der zentralen
Schlüssel ist der Storage Root Key. Der

wird genau ein Mal erzeugt. In der
Lebenszeit des Gerätes. Also ein Mal. Also

hier ist kein.. keine Notwendigkeit, das
mit einer unsicheren schnellen Erzeugung

zu machen, wird allerdings trotzdem
gemacht. Weiterhin haben die ganzen TPM-

Chips eine Schlüssellänge kleiner/gleich
2048 Bit. So, und dann passierte der

preiswerte Totalschaden, das haben die
Kollegen in einem Vortrag hier auch

gemacht, als Professor muss ich da noch
mal darauf hinweisen, dass die Hauptidee -

haben die jungen Leute auch ordentlich
hingeschrieben - von 1996 ist,

unmodifiziert. Dieser Coppersmith..
unmodifiziert, gar nix. Und was ich ihnen

sehr dankbar bin ist, dass sie da bei den
ganzen Sachen mal die Preisliste

drangeschrieben haben. Also, ich weiß
nicht, was das in Bitcoin ist, aber das

sind Cent-Bruchteile in Dollar. Und für
das 2048, was die höchste Schlüssellänge

für TPM-Chips ist, ist es Kosten von 944
$. Wer sieht noch was Ultra-bizarres?

unverständliche Antwort
Ja. Also, irgendjemand erklärt mir nach

dem dritten Bier, warum.. wie man das
hinkriegt, dass 3072 eine 10^17 mal

größere Sicherheit gegen Angriffe haben
als 4096. Also ihr merkt, das ist an

Bizzarität relativ wenig zu überbieten.
Gut, wie gesagt, wenn wir gerade bei

Sachen sind, die in die Hose gehen können,
habe ich auch noch überlegt: Was gibt es

noch aus dem letzten Jahrtausend? Nämlich
den Bleichenbacher-Angriff. Und da hat

eine Gruppe um Hanno Böck und andere
Autoren auch mit Robot das sehr schön

gezeigt,
lacht

dass das heute auch noch genau geht, aber
nur bei so kleinen Firmen wie F5, Citrix

und Cisco.
Lachen

Und so bei 27 der 100 häufigsten
Webservices, unter anderem Facebook und

lacht
PayPal. Das ist, glaube ich, die Firma die

irgendwas mit Geld macht also das ist
irgendwie

Lachen
auch ein Punkt, wo ich irgendwie sag, das

ist eine Sache, wo man sich fragt, und da
werd ich nicht näher auf.. gehen, aber

noch mal der Hinweis: Coppersmith [ist
von] 96, Bleichenbacher [von] 98. Ihr

merkt, ich steh auf alte Angriffe,
insofern seid versichert, im Laufe

lacht

des Vortrags kommen dann noch ältere
Geschichten raus.

Lachen

Aber das ist natürlich relativ
schmerzhaft. Also wir sollten hier auch

nochmal sagen, was wir empfehlen: es hilft
alles nichts, wir brauchen Open Source im

Booting. Wir müssen weg von UEFI. Wir
brauchen so was wie Core Boot, Libre Boot

oder U-Boot, und das muss jetzt relativ
schnell passieren, weil ansonsten haben

wir.. sind wir Kryptographen auch wehrlos.
Also wenn die uns die unterste Ebene

wegschießen und dann alle Bits, die wir
irgendwie sichern wollen, einsammeln, dann

können wir auch keine Magie machen.
Interessant ist, dass auch Google das im

Bereich des NERF - schöner Akronym für
Non-Extensible Reduced Firmware - sehr

stark weiter betreibt. Kommen wir zu dem
Thema, das ich eigentlich hauptsächlich

bespielen wollte, das ist Robuste
Kryptographie. Und jetzt geb ich mal

wirklich ein paar Sachen, die sehr vom
Ingenieurs-mäßigen Standpunkt interessant

sind, aber natürlich mathematisch fundiert
sind. Erste Regel: XOR ist dein Freund.

Das bedeutet, wenn man z.B. aus mehreren
Quellen den Zufall nimmt und das dann

XORt, dann tut man eigentlich das System
stärken. Also es bedeutet auch, ich hab 15

schlechte random Quellen und eine gute,
und wenn ich alles zusammen XOR, tue ich

weitgehend die Eigenschaft der guten
Geschichte erben. Auch hier muss man ein

paar Sachen beachten, aber 'XOR ist dein
Freund' ist, denk ich, sagen wir mal, als

erste Annäherung schon mal ein guter
Punkt. Zweitens: man kann Sachen doppelt

hashen, das habe ich auch vor vielen
Jahren gemacht, ist heute auch - [das]

erste Mal Blockchain - bei Bitcoin der
Fall, dass die zweimal hashen, bevor sie

in den Mining-Prozess.. aber die machen
das halt nicht richtig, denen fehlt ein

XOR und dadurch haben sie nicht die
Sicherheit, die sie natürlich durch höhere

Sachen.. äh, durch doppelt hashen
erreichen würden. Längere Schlüssellängen,

na, das ist generell eine gute Empfehlung,
außer wenn ihr euch an die vorletzte Folie

erinnert, also es ist kein Allheilmittel.
Aber für sehr viele Sachen ist eine lange

Schlüssellänge doch eine deutlich bessere
Idee. Gut. Historische Sachen..

Cryptophone. Ein Telefon, das auch Snowden
ganz gern benutzt, haben wir da für 2003

ein Design gemacht, und da können wir
sehen: Schon damals, wo die Rechner etwas

langsamer waren - wir haben das für Handy
gemacht - ging das irgendwie, dass wir

4096-bit.. äh, Diffie-Hellmann machen, wir
haben es einmal gehasht und dann haben wir

vor der Schlüsselableitung es ein zweites
Mal gehasht, aber mit einer modifizierten

Hash-Funktion. Also hier ist es ein bisl
verkürzt dargestellt: Wir nehmen die SHA-2-

Funktion von damals, aber tun die mit dem
anderen Wert parametrisieren, das hat z.B.

die Eigenschaft, ihr könnt überlegen, wenn
man Kollisionsprobleme hat und zweimal

hintereinander hasht und schon nach einem
Hash eine Kollision da ist, dann hilft das

nicht allzu sehr weiter. Aber durch das
Umparametrisieren, wie gesagt, es ist

manchmal nur ein Bit, also im Prinzip wär
Bitcoin sehr viel sicherer, wenn sie nach

dem.. - also, sicherer gegen einige
Angriffs-Sachen - wenn sie nach dem ersten

Hashing ein Bit umrempeln würden. Also das
ist irgendwie manchmal ein bisschen

gruselig, wenn man sich überlegt, das
manchmal ein Bit an der richtigen Stelle

gesetzt oder nicht gesetzt wirklich
drastische Auswirkungen hat. Später dazu

noch ein paar weitere Bemerkungen. Und
hier aus der beliebten Serie 'XOR ist dein

Freund': wir haben damals AES-256 und
Twofish einfach mit XOR verknüpft, das ist

eine Verknüpfung, die die schöne
Eigenschaft hat, das dann Angreifer beide

Funktionen brechen müssen, etwas verkürzt
dargestellt, aber durchaus zutreffend.

Also wie gesagt, es sind relativ einfache
Sachen, bei Hash-Funktionen ein bisl

darauf achten: XOR ist ganz spannend.
Kommen wir noch mal zur Hash-Funktion, da

möchte ich hier heute mal ein bisschen
Werbung für SHA-512 machen. Ich bin der

Meinung, man sollte lieber SHA-512 nutzen
als SHA-256. Warum? Naja, Abschneiden ist

OK, man kann die, wenn man nur 256 Bit
ist, kann man die anderen Bits schlicht

und einfach verwerfen. Wer es nochmal im
Standard da hinten.. kann es sich

angucken, SHA-356 ist im Prinzip, mit
einer leichten Modifikation, SHA-512 mit

abgeschnittenen Bits. Zweiter Punkt:
Kryptographisch hochwertige Bits, genauer

gesagt schön randomisierte Bits, kann man
immer brauchen. Also wenn man 512-bit

Ausgabe hat, dann hat man noch zusätzlich
ein paar random Bits rumliegen, wie schon

gesagt, man kann dann noch überlegen 'XOR
ist dein Freund' und das in andere Sachen

nochmal anzubringen. Weiterhin ist SHA-512
sehr schnell, auf 64-bit Plattformen, ist

eigentlich fast genauso schnell auf
älteren Plattformen wie SHA-256 und wie

gesagt, rein aus dem kryptographischen
Bauchgefühl: Man hat in SHA-512 mehr

Runden und man hat 64-bit-Operation, also
von allem kryptographischen Bauchgefühl

wird da deutlich mehr durcheinander
gewirbelt und die Sicherheit auch in einer

gewissen Weise erhöht. Gut, das machen wir
kurz. Längere Kurven, nochmal der Hinweis:

Ich bin der Meinung, unter anderem die
Gruppe um D.J. Bernstein hat da schöne

Arbeit gemacht bei der kleinen Kurve, er
hat auch irgendwie bei der 256-bit Kurve

interessante Ergebnisse gehabt. Er hat
auch längere Kurven bereitet, aber das

nicht mit der.. mit dem In.. mit dem
Nachdruck bearbeitet, die man vielleicht

dafür braucht. Und außerdem bin ich halt
wirklich der Meinung, wenn man schon auf

die elliptischen Kurven kommt, ist ja
SHA-256, also ist 256 Bit wirklich sehr

nahe an der Grenze, wo man irgendwie sagt,
das könnte schnell problematisch werden.

Insbesondere, weil auch djb verwiesen hat
auf die Probleme, die RSA bei

Quantencomputern hat, muss ich sagen,
elliptische Kurven, wegen der kleineren

Schlüssellänge würd ich vom Bauchgefühl
sagen, da knallt's deutlich früher als bei

den RSA-Operationen. Gut, alles klar,
jetzt in einem zweitem Teil tut mein

geschätzter Kollege Christian Forler mal
ein paar konstruktive Tips geben, wie man

wirklich bestehende Systeme besser nutzen
können, und es ist eigentlich auch

überraschend: Wir haben uns in dem Vorfeld
halt da noch mal reingeguckt und sind an

einigen Stellen gekommen, dass z.B. einige
neue Ideen, TLS, z.B. 1.3, eigentlich auf

den ersten Blick gut aussehen, außer wenn
man mal ein paar andere Angriffsmodelle

zugrunde legt. Insofern sind die Arbeiten,
die Christian jetzt vorstellt, glaube ich

auch, vom hohen Maße praxisrelevant.
Christian Forler: Hallo. Jetzt wird es

gleich ein bisschen technisch werden, da
müsst ihr jetzt halt durch.

lacht
OK. Und zwar geht es jetzt um den

richtigen Einsatz von AES. Ne? Also das
Problem ist, dass jetzt die ganzen

Hersteller von Softwareprodukte irgendwie
Sicherheit bewerben, indem sie erzählen:

"Wir nutzen AES". Ja. Das ist zwar jetzt
erst mal nicht so die schlechteste Idee,

AES zu nutzen, aber in der Regel findet
man halt nicht raus, wie sie das

einsetzen, ja, und da kann man auch viel
falsch machen. Und das schauen wir uns

dann gleich mal an, das heißt, wenn jemand
irgendwie behauptet, er macht irgendwie

AES, online erstmal nachfragen, wie das
eingesetzt wird und wenn man das nicht

rausfindet, ist das meistens ein Indiz
dafür, dass da ein Fehler gemacht wird.

Und dann schauen wir uns mal an hier: Also
AES ist keine Wunderwaffe, das ist einfach

nur ein Blockchiffre, das heißt, ich kann
mit AES einen Klartextblock verschlüsseln,

bzw. einen Chiffretextblock entschlüsseln,
und die Blockgröße ist 128 Bit, das heißt

16 Byte. Das hilft jetzt in der Regel
nicht so wirklich viel, weil in der Regel

habe ich halt Nachrichten, die ein wenig
größer sind als 16 Byte, ja, wenn man es

so irgendwie Dateien uns anschaut, auch
Netzwerkpakete. Und da ist jetzt die

Frage: Wie kann ich jetzt einen größeren
Klartext verschlüsseln? Und dann ist die

Antwort irgendwie klar: Ich zerhacke den
in Blöcke und bearbeite die Blöcke

nacheinander irgendwie mit AES ab. Ja, das
ist so die elementare Strategie. Und dann

schauen wir uns mal an: da in der i-Folge
jetzt, da geht das auf jeden Fall schief,

und ihr könnt euch vorstellen, man tut
jeden Block einmal durch AES jagen,

Nachteil: gleiche Klartextblöcke, ja, wenn
die Klartextblöcke gleich sind und AES

eine Funktion, dann kommt auch das Gleiche
raus. Das heißt, gleiche Klartextblöcke

ergibt gleiche Chiffretextblöcke, ja,
alles schon mal gehört, das heißt, da

bleibt Struktur erhalten und wenn da
Struktur erhalten bleibt bei einer

Verschlüsselung, dann ist das irgendwie
extrem schlecht. Also das, was wir grad

nicht haben. Ja, das ist halt die Idee,
warum wir Kryptographie nutzen, damit ja

von der Struktur nichts mehr übrig bleibt.
Ja, und falls doch, gibt es da dieses

Wikipedia-Beispiel, das wir irgendwie alle
kennen. Das heißt, das ist irgendwie AES-

verschlüsselt, das ist 'military-grade
security', da, so Werbung.. so, ja.

räuspert sich
Also da gibts ja Leute, die bewerben halt

ihre Software mit 'military-grade
security' und machen dann sowas. Das ist

irgendwie schlecht. Nächster Schritt, was
man jetzt machen kann: Wir wissen alle, ja

man macht Schlüsselstrom. Man nehme ein
AES, generiere einen Schlüsselstrom. Die

Idee ist schon mal gar nicht mal so
schlecht, weil wir haben ja irgendwie

gelernt so, One-Time-Pad funktioniert. Und
das wollen wir irgendwie da ein bisschen

emulieren. Dann gibt's jetzt die einfache
Variante, dann.. genau, verschlüssel ich

jetzt was, indem ich einen Counter,
irgendwie, also ich nehm einen Counter,

verschlüssel den und tu das Ergebnis, der
Schlüsselstrom, der raus kommt, XORen mit

meinem Klartext. Und das Problem ist hier
bei dieser Variante, hier gibt's keinen

Zustand, das ist zustandslos, das heißt,
das ist deterministisch. Das heißt, jedes

Mal, wenn ich hier das anwerfe, die
Verschlüsselungsverfahren, kommt der

gleiche Schlüsselstrom raus. Und wie wir
auch wissen, One-Time-Pads mehrmals

anwenden ist auch eine schlechte Idee,
dann kommt .. das heißt, ich muss jedes

Mal bei AES den Schlüssel wechseln, ja
wenn ich da jetzt eine neue Nachricht

verschlüsseln möchte. Und das ist
irgendwie auch.. irgendwie nicht so

richtig praktikabel, wenn ich jetzt
vergesse, den Schlüssel zu wechseln, bei

dem einfachen Verfahren, dann fällt es
erstmal gar nicht so auf, weil ich habe

hier jetzt einmal Tux verschlüsselt und
einmal Beastie, und hier sieht man

erstmal: die Struktur ist weg, weißes
Rauschen, das ist schon mal irgendwie ganz

angenehm. Problem ist jetzt nur, ich habe
zweimal den gleichen Schüsselstrom, das

heißt, wenn ich den Chiffretext XORe, dann
kürzt sich der weg. Und dann, genau, kommt

irgendwie das raus. Und da kann man sich
vorstellen, das das jetzt nicht so der

Riesenaufwand ist, aus diesem XOR dann die
zwei Klartexte zu extrahieren, das kriegt

man auch hier noch als Geheimdienst hin,
selbst als schlecht ausgestatteter

Geheimdienst, das kriegt man auch noch als
Student noch hin. Das ist eventuell mal

eine Übungsaufgabe, so im.. für Bachelor-
studenten, das ist jetzt net so schwer.

lacht

Deswegen also, wie funktioniert's richtig?
Das heißt, ich brauch einen Zustand, ja?

Das heißt, wenn ich einen Schlüssel nur
habe und möchte damit mehrere Nachrichten

verschlüsseln, brauche ich einen Zustand,
das nennen wir hier Nonce. Und das heißt,

und beim Counter-Mode setzt sich halt mein
Counter im Anfangswert nicht auf 1,

sondern ich setze ihn auf seinen Zustand.
Und jetzt ist die Idee: Jedes Mal, wenn ich

eine neue Nachricht verschlüssele, würfel
ich mir einen neuen Zustand aus, neue

Nonce. Und das heißt, wenn ich da jetzt
eine neue Nonce anfange, bekomme ich immer

wieder einen neuen Schlüsselstrom und das
ist halt vorteilhaft, das heißt, genau.

Das heißt, wenn ich halt.. neuer
Schlüsselstrom heißt halt, das können wir

wieder nutzen und so falls sich jetzt..
das Ganze ist sicher so, falls sich kein

Nonce-Schlüssel-Paar wiederholt. So weit,
so gut. Das heißt, die Anforderung halt

hier ist jetzt.. ist, der Nonce darf sich
nicht wiederholen. Ja und das ist halt so

ein bisl kritisch, es gibt uns, genau, es
gibt da noch so mehrere

Verschlüsselungsverfahren, die sind alle
Nonce-basiert, und das erste Problem, wie

ich gesagt habe, man darf den Nonce
irgendwie.. muss aufpassen, dass der sich

nicht wiederholt. Und das zweite Problem
ist, man schützt nicht die Integrität der

Nachricht damit. Ja das heißt, wenn ich da
was mit verschlüssele, z.B. so eine Bank-

Transaktion, ist es sozusagen geschickt,
dass die hier im Internet niemand lesen

kann, aber wenn ich das Format irgendwie
kenne, der Bank-Transaktion, kann ich es

so manipulieren, dass der Betrag sich
ändert, oder die Empfängeradresse und das

auch kontrolliert. Und eventuell möchte
man das nicht. Ja. Genau. Und deswegen

gibt es die Authentisierte
Verschlüsselung. Das heißt, als Kryptograh

ist man auch auf die Idee gekommen, seit
längerem schon, das man nicht nur die

Vertraulichkeit irgendwie schützen möchte
einer Nachricht, sondern auch die

Integrität. Und das in einem Rutsch und
das auch irgendwie mit AES. Genau. Das ist

jetzt das große Ziel. Und wie funktioniert
das, so ein Verfahren? Ich hab jetzt, wie

gesagt, wieder mein Nonce und mein N und
meinen Klartext P, den kipp ich da rein,

und dann fällt es nicht nur unter
Chiffretext raus, sondern es fällt auch

noch so eine kryptographische Prüfsumme
raus. Ja? Und das heißt, wenn ich jetzt

die Inputs ändere, ändern sich auch alle
Outputs bei der Verschlüsselung. Das

heißt, ich komm jedesmal, wenn ich dann
irgendwie mindestens ein Bit ändere oder

mehr im Input, ändert sich halt auch die
Prüfsumme und der Chiffretext. Das ist

schon mal ganz nett. Und wenn ich
entschlüssle, ganz einfach, dann kipp ich

wieder so ein valides Nonce-Chiffretext-
Tag-Paar rein und es kommt mein Klartext

raus, Juhu! Und das ist, der Clou ist
jetzt, der Hammer: Wenn ich jetzt

irgendwie am.. wenn jetzt jemand
manipuliert, das heißt wenn ich jetzt

Nonce, Chiffretext oder Tag ändere, dann
gibts ne Fehlermeldung. Ja? Dann heißt es,

der Klartext ist nicht valide, das heißt
die Eingabe war invalide und es gibt eine

Fehlermeldung. Das ist irgendwie ganz
nett, sowas will ich eigentlich haben. Ja

da gibt es irgendwie so zwei ganz berühmte
Verfahren, das eine ist der Galois/Counter

Mode, der wird eigentlich überall.. der
ist in der Industrie weit verbreitet, den

gibt es z.B. so bei Sachen wie IPSec oder
auch bei TLS und so weiter und das ist,

das Problem.. also, das Gute ist, das Ding
ist superschnell, der Galois/Counter Mode,

Nachteil ist, er ist ein bissel fragil.
Das schauen wir uns gleich mal an und das

andere Verfahren, das ich dann noch
empfehlen kann, ist OCB, Offset Codebook

von.. genau, Rogaway, hat er mit gebaut
und das.. genau. Also wenn man die Wahl

hat, sollte man OCB einsetzen. Problem ist
halt auch wieder hier: Bei all den

Verfahren, wenn sich eine Nonce wiederholt
dann ist es.. dann bricht so alles

zusammen. Ja und ich hab mir das nochmal
angeschaut, wie schlimm die Situation ist,

wenn sich eine Nonce wiederholt, 2011. Und
d.h. das Schlimme ist, das ist wirklich

total kaputt. D.h ich kann da immer von
O(1) Angriff finden, d.h. ich kann das

Ding in Echtzeit alles kaputt machen.
'Vertraulichkeit und Integrität'. Und das

möchte man nicht so wirklich haben. Also
das ist irgendwie.. d.h. wenn sich eine

Nonce wiederholt, ist das so eine mittlere
Katastrophe. Ja und das ist irgendwie vom

Design her nicht so gut, d.h. da muss man
irgendwann mal irgendwie die.. also die

Anforderungen für einen Kryptograph, der
ist Mathematiker, man hat so einen

Zustand, der sich wiederholt, das klingt
jetzt erstmal irgendwie so nicht so

schlimm, aber in der Praxis ist das echt
ein Problem. Schauen wir uns auch gleich

an, erstmal noch mal hier bisl GCM-
Bashing. GCM, na das liegt.. das ist

extrem fragil. Also, [auf] das muss mans
aufpassen, wenn man es einsetzt. Wenn ihr

GCM einsetzt, Galois/Counter Mode, dann
bitte nur mit 96-bit Nonces. Ansonsten

gibt's Probleme, da können Konstanz-
Kollisionen auftreten, weil dann das

gehasht wird. Das möchte man eigentlich
nicht tun. Ja und die Hashfunktion hat da

so ein bisschen Schwächen. Dann, kurz
nachdem GCM raus kam, hat sich mal Niels

Ferguson - also sprich: Microsoft - das
Ding angeschaut und hat gemeint so, oh,

das Problem ist, wenn ich jetzt den.. die
Nachricht, also die Prüfsumme, kürze, dann

wird das Ganze extrem unsicher. Das heißt,
es nimmt überproportional stark ab, die

Sicherheit. D.h. Kürzen ist eine schlechte
Idee. Und das ist auch so manche komische

Eigenschaft, die man eigentlich nicht
haben möchte. Ja. Das andere, was man

jetzt rausgefunden hat: ja, bei Nonce
Wiederholung, da fliegt da so ein

Schlüssel raus. Ja, d.h. da irgendwie
kriegt man noch einen Schüssel frei Haus

und das Gute ist, GCM hat zwei Schlüssel.
Einen Schlüssel zum Verschlüsseln, einen

Schlüssel für die Integrität, für die
Prüfsumme. Und es fällt da nur der

Schlüssel raus für die Prüfsumme. Das ist
aber irgendwie trotzdem irgendwie schlimm.

Das möchte man eigentlich nicht. Dass man
mal einen Fehler macht, der Schlüssel raus

fällt. Das ist halt auch bisl.. so bisl
fragil. Und es gibt noch auch ein paar

Handvoll schwache Schlüssel, weil dieses
Galois/Counter Mode, ja, das 'Galois'

steht halt für Galois field
multiplication, d.h. da findet eine

Multiplikation statt, und da kann man sich
denken, ja, Multiplikation mit 0 ist

vielleicht nicht die beste Idee. Ja, wenn
man so einen 0-Schlüssel hat, weil

irgendeine Nachricht mal 0, ne, ist halt
immer 0, unabhängig von der Nachricht und

eine Prüfsumme, die unabhängig von der
Nachricht ist, ist irgendwie nutzlos. Und

da gibts noch weitere Schlüssel, die auch
irgendwie noch Schwächen haben. Genau.

Also, als das rauskam, wie gesagt, hat
sich das mal Niels Ferguson angeschaut,

der ist bei Microsoft tätig, und hat dann
so ein Papier geschrieben, da stand drin,

ja, ich kann das nicht zufällig empfehlen,
besser nicht. Wenn ihr keine andere Wahl

habt , dann nutzt GCM, aber bitte, bitte
nicht.. niemals die Prüfsumme kürzen. Da..

genau, dann.. das Zweite, was ich hier
habe, als Code-Schnipsel ist RFC 4103..

06, da steht beschrieben, wie man denn
jetzt GCM bei IPSec benutzt und da steht

drin, ja wenn ihr das implementiert,
natürlich müsst ihr dann die volle

Prüfsumme unterstützen - ich glaub, das
kann man auch gar nicht anders

implementieren, dafür ist es nicht
möglich, dass man es eben anders

implementiert - und aber, was optional
noch erlaubt ist, ihr dürft die Prüfsumme

kürzen, auf.. genau. Von 16 Byte auf 12
oder 8 Byte, und das ist natürlich eine

schlechte Idee. Ja, weil dann die
Sicherheits.. also mehr, die Sicherheit,

wenn man nur 8 Byte hat, ist halt
wesentlich geringer, als man da vermutet.

D.h. erstmal: tuwat! Ne? Wer Admin ist,
erst mal nachschauen: IPSec - nutzt ihr

GCM mit kurzen Prüfsummen? Und dann
erstmal das Feature deaktivieren. Das

hilft. Dann, genau. Jetzt gehts wieder
zurück zum Nonce-Reuse, nachdem ich ein

paar Nachteile von GCM aufgezählt habe.
Weil der Vorteil ist halt, es ist halt

verdammt schnell, aber der Preis ist
Fragilität. Und bei Nonce, genau,

Wiederholung: Es ist halt praxisrelevant,
da gab es ja irgendwie Diskussionen am

Anfang, als der da herauskam und
irgendwie, da nenn ich mal drei Beispiele.

Ja, ich glaube schon, weil erster Grund
ist halt: Programmierer machen Fehler und

auch Leute, die sowas designen, machen
auch mal ab und zu Fehler. Und genau, da

gibt es so drei lustige Beispiele. Eins,
so irgendwie so eine kleine Klitsche aus

Redmond, mit so Nischen-Software - Word,
Excel - hat es irgendwie nicht so richtig

hinbekommen beim ersten Anlauf, dann das
andere, was ich hier noch hab ist so

WinZip, auch so irgendwie Nischen-
Software, die keiner nutzt. Und das dritte

haben wir jetzt dieses Jahr ganz brandneu,
ist KRACK hier, WPA2 Wi-Fi, ja, auch so

ein Nischen-Produkt. Und das ist so, sieht
man, das geht halt immer wieder.. also

selbst die großen Firmen eben.. und
Standard und Komitees kriegen das nicht so

richtig hin. D.h. da gibts halt irgendwie
ein Problem. Und ich denke, auch in

Zukunft wirds immer wieder Probleme geben,
ja? Und das andere ist, wenn man sich mal

schaut so, die ganzen App Stores, was es
da an Software gibt, den nutzen halt viele

Leute, also, was heißt.. es gibt halt
irgendwie.. ich denke, jede zehnte App,

die irgendwie so AES einsetzt, wird so
irgendwie diesen.. als Nonce hier den

Zufallszahlengenerator von xkcd verwenden,
d.h. das ist alles schlimm, wenn man sich

mal das anschaut.
räuspert sich

Ja also, das ist halt strukturelles
Problem. Das andere sind da so

Bedienfehler, ja, Admins sind auch
teilweise mal schuld, nicht nur die

Programmierer, d.h. was man da oft macht,
ist jetzt hier restore ein Backup, und der

Nonce ist halt dann persistent geschrieben
worden irgendwo auf Platte, den letzten

Wert so, dann wird das wieder geladen, oder
wenn man klont, bei virtuellen Maschinen,

da kann auch mal was schief gehen bei
Nonces, dass mal eine Nonce öfters

aufkommt. Oder das andere ist, wenn ihr
jetzt zu wenig Entropie habt, dann zieht

man öfter mal die gleiche Nonce. Ja, das
ist irgendwie alles unlustig. Das

Problem.. also, das Gute der Nachricht
ist, das Problem wurde eigentlich 2006

schon gelöst, ja, von den Kryptographen.
Da gab es jetzt ein Paper, das rauskam,

das hat vorgestellt ein Verfahren, das ist
Misuse Resistant AE Schemes, heißen die,

und die bieten auch Sicherheit, wenn man
das mit einem Nonce vergeigt. Ja, genau.

Und das Coole ist, die haben beliebig..
unterstützen beliebig lange Nonces,

i.d.R., die Verfahren. D.h. wenn man da
Netzwerk-Pakete verschlüsselt, dann kann

man den Header als Nonce nehmen und den
Payload als Klartext. Wunderprima. Sollt

man mal machen. Und zwar überall. Das
Verfahren, wie gesagt, wurde jetzt

vorgestellt, da gibt's auch ein RFC für,
d.h. es gibt jetzt keinen Grund, das

irgendwie nicht zu implementieren als
Entwickler oder Netzwerk-Mensch. Und

genau, da gab es noch eine Schwäche, also
SIV ist eigentlich idiotensicher, d.h. man

kann auch ein Nonce wiederholen, aber es
ist halt nicht irgendwie

vollidiotensicher, deswegen habe ich da
noch 2016 an einem Verfahren gearbeitet,

das das Ganze noch verstärkt. Warum ist
SIV nicht idiotensicher? Ja, man muß ja

noch die kryptographische Prüfsumme
verifizieren. Und ja, und wenn man das

nicht hinkriegt, ja, wir erinnern uns,
hier Apple z.B. kriegt das auch nicht

immer hin, mit goto fail Bug, d.h. wenn
das Apple passiert, kann es eventuell auch

anderen Firmen passieren, haben wir uns da
gedacht. Und deswegen haben wir das

irgendwie so gebaut, dass selbst wenn man
jetzt irgendwie die Verifikation

versemmelt, dass dann irgendwie bei der..
genau, dass dann immer noch.. irgendwie

das irgendwie bemerkbar wird, indem man
als.. das so baut, das der Klartext, wenn

man den Chiffretext manipuliert, immer
weißes Rauschen ergibt. D.h. man hat immer

weißes Rauschen. Und dann war die Idee so,
eventuell fällt es bei.. wenn man den

Input validiert, dann auf, bei der Input-
Validierung, dass da irgendwie nur weißes

Rauschen ist, und dass es keine valide
Eingabe ist, oder die Software wirft

eine Exception oder stürzt ab oder so. Ja
genau. Wie das genau machen, überspringe

ich mal, aus Gründen der Zeit. Genau und
das Ding ist, hier tutwat! Benutzt diese

MRAE-Schemes. Die haben einen gravierenden
Nachteil: man muss zweimal komplett über

den Klartext gehen. D.h. das dauert halt
ein bisschen länger als andere Verfahren.

D.h. die sind nicht so super effizient.
Und jetzt kann es natürlich sein, dass man

jetzt irgendwie Echtzeitanforderungen hat,
die das nicht erlauben. Ja dann, was soll

ich tun, wenn das irgendwie technisch
nicht möglich, realisierbar ist? Ja, nicht

in Panik verfallen, auch da hab ich
irgendwie.. gibt es eine Lösung, da war

ich dabei, die mit zu entwickeln. Und die
Antwort hier ist Robuste AE-Schemes, die

hießen vorher mal 'Nonce Misuse Resistant
AE-Schemes', und wir haben das jetzt

umbenannt, nur noch Robust, weil es da
irgendwie ein bisl Konflikt gab,

Potenzial, in der Crypto-Szene. Und was
wir da gebaut haben, ja, 2012, war ein

Verfahren, McOE, da kann man jetzt
irgendwie, wenn man da jetzt irgendwie

Probleme hat mit den Nonces, eine Nonce
wiederholt, dann ist hier immer noch, die

Integrität immer noch gewährleist,
Integritätsschutz, und die Vertraulichkeit

bleibt auch noch irgendwie.. je nachdem,
wie schlimm man da Fehler macht, noch

teilweise erhalten, oder eventuell auch
ganz. Also was man auf jeden Fall erkennen

kann, wenn man Nonce wiederholt, dass zwei
Klartexte den gleichen Prefix haben. Das

konnten wir eben nicht wegkriegen, wenn
wir nur einmal über den Klartext gehen.

Genau. Das.. die Idee hat sich dann
irgendwie fortgepflanzt, d.h. da gab es

dann auch diesen CAESAR Competition, und
das R steht auch für Robust. Das.. genau.

Und die CAESAR Competition sucht halt
einen Nachfolger für GCM. Ja, das ist eine

Crypto Competition, auch von Dan
Bernstein, der hat die da angetriggert,

ist der Schirmherr. Und da haben jetzt
einen Nachfolger von McOE, auch, da hab

ich auch mit.. POET - da war ich auch
wieder mit dabei gewesen - ins Rennen

geschickt. Wir haben es in die zweite
Runde gepackt, leider nicht in die dritte,

weil wir waren wahrscheinlich ein bisl zu
super-schwergewichtig und auch nicht so

performant auf Hardware. Was noch im
Rennen ist, was ich empfehlen kann: COLM,

das ist ein Zusammenschluss aus AES-COPA
und ELmD. Das waren praktisch zwei

Zweirunden-Verfahren, die sind jetzt..
haben sich zusammengeschlossen, ist jetzt

noch Drittrunden-Kandidat, was es jetzt
noch gibt, was ich noch empfehlen kann,

beim CAESAR Competition, was man näher
anschauen kann, ist AEZ, AEZ ist ein MRAE-

Scheme, mit von Phil. Und genau, zumindest
hat der Phil mitgemacht, das sind die zwei

Kandidaten, die ich da noch empfehlen
kann. Genau und jetzt schauen wir uns mal

an, also alle die Verfahren, ja, sind
irgendwie beweisbar sicher. Und genau. Und

das heißt, da gibt es immer so einen
Sicherheitsbeweis. Und da gibt's immer..

irgendwie da unten.. das schauen wir uns
mal man hier: also das ist jetzt so eine

Sicherheitsschranke, und wenn man einfach
sieht, hier hat man da.. ist das eine

Birthday Security-Bound. Also die haben
alle so komische Bounds. Ja und da gibt es

jetzt so drei Parameter: q, l und t. q ist
die Anzahl Nachrichten, die man damit

verschlüsselt, l sind die Anzahl Blöcke,
die man insgesamt verschlüsselt und t ist

die Zeit. Und was hier steht ist, ihr
könnt ungefähr so 100 Terabyte unter einem

Schlüssel verschlüsseln, ein paar hundert
Terabyte, und dann sollt ihr den Schlüssel

wechseln. Genau. Und natürlich ist es nur
sicher, wenn auch AES sicher ist, wer

hätte es gedacht, weil das Ding nutzt ja
irgendwie AES. Und ja genau. Also und die

Idee ist auch irgendwie bei POET, das ist
immer so'n.. also das ist halt super

strong, ja so das Superheavyweight, weil
wir machen hier die erste lane, obere

lane, ist einfach nur eine Prüfsumme über
den Klartext, die untere lane ist eine

Prüfsumme über den Chiffretext und in der
Mitte drin ist die Verschlüsselung. Genau,

d.h. die kryptographische Prüfsumme ist ja
ziemlich, irgendwie.. wenn Klartext und

Chiffretext.. und das zweite coole Ding,
ja, wenn ich hier jetzt z.B. was

manipuliere bei C 2, dann kommt ab M 2
weißes Rauschen raus. D.h. da kann ich

auch wieder.. da ist auch wieder die Idee,
wenn man jetzt die Verifikation jetzt

nicht richtig macht, dass man da viel
weißes Rauschen hat und dass damit

irgendwie vielleicht auffallen könnte bei
der Eingabe-Validierung. D.h. da ist jetzt

auch noch irgendwie so ein bisschen Schutz
drin, das, wenn man die Verifikation nicht

richtig hinbekommt. Also if-Abfrage ist
nicht immer ganz einfach zu

implementieren. Genau, jetzt bin ich auch
schon so gut wie durch. Das ist gleich

geschafft, dann darf wieder Ruedi.
lacht

Und genau, also was ich mit.. das, was ihr
tun sollt: niemals nicht eine Nonce

wiederholen! Das ist eine mittlere
Katastrophe, das ist also, das ist

praktisch so ein Unfall. Das ist
irgendwie.. genau. Also, und jetzt die

Frage, so, sei wie soll ich meine Daten
verschlüsseln? Da gibt es jetzt wie

gesagt, mal schauen, also da gibt es jetzt
4 Kategorien: die erste ist die stärkste,

die vierte ist die schwächste, und man
sollte schauen, dass man jetzt irgendwie

schaut, kann ich ein Verfahren aus der
Kategorie 1 nehmen? Lässt das mein ..

irgendwie, mein Umfeld zu, meine
Anforderungen? Wenn nicht, dann 2, wenn

nicht 3 und ansonsten 4. D.h. eine
klassische Verschlüsselung, die wir so

kennen, ist so halt ziemlich das
schwächste - schlechteste - was man tun

kann. D.h. wir müssen jetzt irgendwie
schauen, dass wir mal da besser werden und

mal so auf 1 und 2 kommen und nicht nur
bei 3 und 4 rumdümpeln hier. Damit die

Verahren auch robuster und stärker werden
in Zukunft.

ruedi: OK, vielen Dank, ah, dein Zitat
noch! lacht

cforler: Ah, ich hab noch eins, ja, genau
- also, allerwichtigste Botschaft für

heute ist: Redet verdammt noch mal mit
Kryptographen, ja! Also, ihr macht ja

einen Haufen cooler Software und die fällt
dann auseinander, weil man nie mit uns

geredet hat.
lacht

Also wir sind irgendwie beide.. unsere
E-Mail-Adresse, unsere Telefonnummer sind

irgendwie im Internet, stehen die, und da
kann man uns mal sprechen und, ja.

lacht
Applaus

und genau, also man kann irgendwann mal
nach Berlin kommen und mit uns reden. Bei

einem Käffchen.
ruedi: Ja, noch mal also vielen Dank. Ich

möchte das auch noch einmal ein bisl
aufgreifen, also damit es noch mal ganz

klar ist, dass das jetzt wirklich ein
praxisrelevantes Problem ist. Also wenn

ich mich nicht täusche, also das ändert
sich, aber als ich das letzte Mal

reingeguckt hab, war wirklich in TLS die
Überlegung: Wir sind clever, wir benutzen

keine Verfahren, wo nicht
Authentifizierung mit eingebaut ist und

wir verwenden zwangsweise das GCM, also
Galois/Counter Mode. Das ist auch supi,

bis auf die Tatsache, wenn ein Nonce
wiederholt wird, ist das katastrophal

schwächer als alle katastrophal.. alle
Fehler, die man auf der unteren Ebene

machen kann. Also Kryptographie ist
relativ schwer. Aber noch einmal der Apell

von Christian wirklich deutlich
wiederholt: die Crypto-Gemeinde hat einen

starken wissenschaftlichen Teil, die auch
offen publizieren und so weiter. Also

insofern noch einmal da der Hinweis: da
mal rein zu gucken, was da ist, ist

wirklich eine gute Idee. Und nochmal
wirklich an dieses: redet mit

Kryptographen, mal anbuzzen.. kommt jetzt
der Grund, warum hier so voll ist: weil

wir noch was mit Blockchain machen wollen
in diesen nächsten Folien. Auch da möchte

ich an ein paar Stellen sagen: Ein
bisschen reden mit Kryptographen wäre ganz

angenehm gewesen. Also wir arbeiten da
auch an verschiedenen virtuellen

Kooperationspartnern, also wir möchten da
auch besser werden in Richtung verteilter

Echtzeit, aber da arbeiten wir schon
lacht intensiv daran. Also wer da noch

weitere Tips hat, was es da noch für
Forschungseinrichtungen gibt, der kann

sich auch bei uns freundlich melden. So,
mal ein paar Worte zu Bitcoin. Ich hab's

mal schon vor Jahren hier gemacht, ich
hätte damals vielleicht Bitcoin kaufen

sollen, anstatt das zu.. sicherheits zu
evaluieren. - Nein, hätte ich nicht - soll

man nicht machen, ich bin da altmodischer
Professor. Ich bin der Meinung - wenn da

von.. also, von führenden kapitalistischen
Zeitungen gefragt wird, wie sicher das ist

- dann solltest du nicht irgendwelche
Aktien drin haben, um da zu antworten. Ich

will es mal so sagen: die Kryptographie in
Bitcoin wäre eine befriedigende

Bachelorarbeit. Das sind schon.. und das
reicht eigentlich. Die Crypto ist so

stark, dass eine befriedigende
Bachelorarbeit völlig dazu führt, dass die

Probleme woanders zu sagen sind. Es ist
vorsichtige Amateur-Kryptographie. Doppelt

hält besser, die hashen zweimal
hintereinander, aber wie gesagt, meine

Erweiterung, nach dem ersten Hash ein Bit
umzurempeln und dann weiter zu hashen

würde bedeuten, dass z.B. die
Kollisionseigenschaften sich nicht einfach

weiter vererben. Also diese zweimal Hash
hintereinander bringen z.B. gegen

Kollision nicht allzu viel, wenn sie nach
dem ersten Hash ein Bit gerempelt hätten,

weiter gehasht, hätten sie eine deutlich
bessere.. bessere Eigenschaften gehabt.

Also so ist jetzt das Doppelhash
ziemlich.. nicht besonders relevant. Also

jedenfalls, wenn man starke Sachen macht.
Was relativ cool ist, ist dass die die

Public Keys nicht veröffentlichen, sondern
halt hier auch eine zweimal gehashte

Kontonummer. Und da sieht man, dass die
möglicherweise doch ein paar Hacker-

Konferenzen gehört haben und gewusst
haben, sie sind nicht so fit in Crypto:

"Machen wir es lieber mal ein bisschen
robuster", und so weiter. Insofern ist das

eigentlich relativ erfreulich, aber wenn
die jungen Leute mit.. oder alten Leute,

oder was immer für Leute, mal mit
Kryptographen geredet hätten, hätten wir

ganz interessante Implikationen gehabt. Es
ist ganz lustig, der Bitcoin-Hauptautor

hat gesagt: "Oh ja, jetzt hashen die, alle
Leute, mit Spezialhardware, und unser

demokratischer Ansatz 'jeder PC hat eine
Stimme und alles verteilt' geht den Bach

runter. Wir sollten ein Gentlemen's
Agreement machen, dass nur auf CPUs

gemined wird."
Lachen

ruedi seufzt
Ach, ist das schön, junge Leute! Dann..

ich mache einen..
lacht

ein Konzept von kryptogra.. äh, von
kapitalistischen Anarchisten, die

irgendwie alles so designen, dass keine
zentrale Stelle ist, und will mit diesen

verteilten Anarcho-Kapitalisten weltweit
Gentlemen's Agreements zu machen. Ohne der

Geschichte vorzugreifen: es ist nur
beschränkt gelungen.

Lachen
Wobei das wirkt alles lustig, da, wenn

schlecht bezahlte Berliner Professoren hier
rum[unverständlich] und gute Witze darüber

machen, das Problem ist, wenn man hier
Fehler macht, dann hat das auf einmal

Auswirkungen, dass irgendwie eine große
Menge an Energie völlig sinnlos verheizt

wird. Und da muss ich auch sagen, am
Anfang habe ich gesagt, oh, Leute kommt

runter, es ist EIN Kraftwerk - was mir
dann erst irgendwann mal siedend heiß

eingefallen.. ne, mit Erhöhung der
Hashing-Komplexität tut praktisch linear

auch der Stromverbrauch irgendwie steigen.
Also es ist jetzt schon auf dem Weg, eine

deutliche Umwelt-Sauerei zu werden und wir
Krypto-Hippies könnten natürlich sagen:

"Können wir wenigstens nur mit Wasserkraft
minen?" usw, aber unser Einfluss auf

verteilte krypto- und kapitalistischen
Anarchisten ist relativ überschaubar. Also

insofern ist es wirklich kein Witz, dass
einige Sachen, die wir haben.. wirklich es

hilfreich gewesen wäre, wenn die mit
Kryptographen geredet hätten. Und hier

haben wir auch ein Bild, was ich mal
einfach mal vorstellen wollte: Dieses

Proof of Work demokratisch zu halten, das
ist sehr verwandt mit der Frage Passwort-

Hashing. Also Passwort-Hashing ist die
Idee, aus dem gehashten Passwort soll es

sehr schmerzhaft, sehr arbeitsspeicher-
intensiv sein, das Passwort wieder zurück

rechnen. Also klassischer Proof of Work.
Dass ihr seht, dass das nicht ganz aus der

Welt ist: scrypt wird z.B. in Lite..
Moment, Litecoin? Litecoin verwendet, das

ist auch eine der größeren Sachen, und die
haben scrypt verwendet. Die haben aber

auch nicht mit Kryptographen geredet, wie
man die Parameter da vernünftig fährt mit

dem Ergebnis, dass jetzt mit ein bisschen
Verspätung da auch ASICs kommen und

dieselbe Problematik, die wir bei Bitcoin
haben, haben wir dort genauso. Auch hier

kriege ich manchmal bisschen die Krise,
und ich sage, wir hätten das alles

demokratisch regeln können, wenn ihr mit
uns geredet hättet. Wir hätten euch

umfangreiche Änderungen gesagt, nämlich
genau eine Zahl geändert, einen Parameter

geändert. Dann wäre die ganze Sache auf
einmal eine demokratische Veranstaltung

gewesen und nicht so, dass jetzt irgendwie
sinnlos Sachen verbrannt werden und

irgendwelche.. nur noch Fabriken
mitspielen dürfen. Das ist manchmal selbst

für Hacker und Mathematiker, die wissen,
dass Zahlen eine gewisse Magie hat,

relativ gruselig. Also hier einen scrypt-
Parameter richtig einzustellen, wär eine

gute Idee. Dann gibt es noch Passwort-
Hashingverfahren.. äh, -Wettbewerbe, da

ist Argon2i, ne, war nicht - 2d!
unverständlicher Kommentar aus dem Off

Du hast den Tippfehler wieder reingemacht,
lacht

den du vorhin korrigiert hast!
cforler: Ja, ja, wieder hinten integriert.

ruedi: Ä-ä-ä, das ist immer...
cforler: Problem mit der Versionierung, ja.

ruedi: Das ist "d"!
cforler: Das muß "d" sein.

ruedi: Naja, aber Catena-Stonefly, da hat
er ja sich auch als Hauptautor

rausgemogelt, also Christian ist der Autor
des ganzen Frameworks.

cforler: Mitautor, Co-Autor.
ruedi: Co-Autor, ach so.

cforler: Das hab ich zusammen mit Stefan
Lucks und Jakob Wenzel gemacht.

ruedi: Und das Catena-Stonefly ist eine
Implementierung, die ganz besonders diese

Sachen adressiert, und - ne, haben wir die
nicht - also, so sieht das aus, also ihr

seht, das ist ein bisschen was. Aber wenn
man irgendwie große Geschichten jetzt

erwartet, ist es relativ überschaubar.
Also das sind relativ naheliegende

Funktionen und das schöne ist halt an den
Arbeiten von Forler et al.,

lacht
dass da also sehr brutale Sicherheits..

also sehr ordentliche mathematische
Sicherheitsschranken da ist. Also nochmal,

man könnte scrypt nehmen mit ein bisschen
cleveren Parametern, oder man könnte das

andere Passwort-Hashing machen und dann
hätte man mathematisch beweisbar, dass die

Leute nicht das auf Spezialhardware
relativ einfach machen können. Also

nochmal diese Sache, die wir mehrfach
gesagt.. redet mit Kryptographen. Noch

einmal, eine Zahl in diesen bitcoinartigen
Sachen richtig gesetzt, hätten wir es

weiterhin demokratisch. Nicht mit
Kryptographen geredet, gesagt: "OK, wir

machen Gentlemen's Agreement" bedeutet
halt, dass irgendwie im Moment eine

obszöne Menge an Energie einfach fürs
Mining verbrannt wird, und zwar völlig

nutzlos. Entschuldigung, ich stehe
eigentlich auf Hashfunktionen, aber

irgendwie sinnlos irgendwie da vor sich
hin zu hashen und alles wegzuschmeißen,

das kann nicht so die pfiffige Idee sein.
Wenn man Proof of Work ist, noch einmal,

hier wäre es hilfreich gewesen, entweder
also mit Kryptographen zu reden oder

zumindestens mal die Damen und Herren von
Litecoin: Da mal überlegen, dass man die

Parameter vielleicht ein bisschen
ordentlich setzen könnte. Gut, ich bin der

Meinung, dass wir wegkommen müssen von dem
sinnlosen Heizen und deswegen werd ich in

den nächsten Monaten auch mit einem
Doktoranden zusammen mal ein bisschen

arbeiten, Proof of Work nützlich zu
machen. Da sind schon Ideen da, die im

Bereich Storage sind, da ist Filecoin z.B.
ein Kandidat, der ähnliche Sachen macht.

Oder Network Services: ich habe durchaus
die Überlegung dass es vielleicht sinnvoll

ist, bei der Anonymisierung des
Webtraffics nicht auf das Tor-Projekt zu

vertrauen, dass seine Hauptfinanzierung
vom amerikanischen

Verteidigungsministerium hat. Also ich
hätte ganz gerne eine Konstruktion, wo

Router Netzwerk-Service, Tor-artige
Services anbieten und damit praktisch auch

nebenher minen. Also dass praktisch Geräte
sich selbst finanzieren und wenn man

irgendwie halt mal ein bisschen träumt,
dann kann man halt sagen, man entwickelt

einen Router, den stellt man in der
dritten Welt in die Sonne, solange Sonne

ist, tut der Energie machen und Services
machen und wenn die Sonne weg ist, holt er

den Strom, aber bezahlt das mit der
Arbeit, die er gemacht hat. Also dieser

Traum eines wirklich ganz autonomen
Systems, das möchte ich noch auferhalten,

vielleicht einen Schritt zurück, ich hab
einfach keine Lust, dass irgendwie Mining

- also wirklich 2^17 oder 2^73 Operationen
- immer in sinnlose Umsetzung von Strom,

in Wärme, gemacht werden. Also vielleicht
gibts..

Applaus
Ja, Dankeschön.

Applaus

Applaus
Und um es noch einmal zu wiederholen, den

ganzen Mist hätte man.. also diese Sachen
sind anspruchsvoll und da sind sehr viele

Fragen zu klären, deswegen ist es eine
schöne Promotion und ich bin da ein

altmodischer Professor, wenn es irgendwie
die Welt nicht revolutioniert, 'ne gute

Promotionsthema ist es auf jeden Fall.
Lachen

Insofern passiert die Revolution im Rahmen
meiner dienstlichen Aufgaben, was

irgendwie von Professoren in meinem Alter
immer eine ganz angenehme Perspektive auch

ist. Aber um es noch einmal zu betonen,
wenn die Damen und Herren, die das gemacht

hätten, wirklich das Passwort-Hashing
angeguckt hätten, wenn diese Litecoin-

Leute die Parameter richtig gemacht
hätten, also nochmal: Macht euch die Kraft

von euch Programmierern und Mathematikern,
und ne, sogar von euch Programmierern,

lest die Mathematik, die wir euch
präsentieren, setzt die Zahl richtig und

ihr habt eine bessere Welt dadurch.
Zumindestens, sagen wir mal, in dieser

virtuellen Welt, warte mal ab mit den
Auswirkungen. Aber noch einmal, ich sage,

also erstens möchte ich einen wirklichen
Proof of nützlicher, gesellschaftlich

nützlicher Arbeit. Zweitens, wenn ich
dieses alte Proof of Work mach, das hätten

wir weiterhin demokratisch gehalten, wenn
die Leute dieses Passwort-Hashing gemacht

hätten. Entweder das scrypt oder halt,
sagen wir mal, die Sachen mit richtig hart

brutalen Sicherheitsbeweisen, die
Christian da unter anderem entwickelt hat.

Kommen wir noch mal zum Ende. 'Wir sollten
was tun' ist irgendwie das Ding, und ich

habe ja damals gesagt, Krypto-Magie ist,
dass man auf einer kleinen,

fingernagelgroßen Fläche, oder mit ein
paar Programmierzeilen, Code erzeugen

kann, den die Geheimdienste nicht brechen
können. Das hat schon ein bisschen was

magisches, die.. problematisch ist, wenn
man halt nicht reingucken kann und die

Leute das halt schlecht implementieren,
wie das jetzt bei Infineon in Zusammenhang

mit den TPM-Chips passiert hat. - Oh, da
haben wir eine Folie, die muss ich, glaube

ich, nachhalten. - Also bei den TPM-Chips,
Infenion war einer der Hauptkandidaten,

und da ist es einfach so, das ist zwar
vom BSI zertifiziert worden, aber

offensichtlich reicht das nicht aus. Wenn
das Open Source gewesen wäre, wenn man da

reingucken könnte, dann hätte ein
talentierter Doktorand wirklich nur wenige

Stunden gebraucht, um aufzuschreien und
den Fehler zu finden. Also wir brauchen

wirklich auf der untersten Ebene Open
Source ganz dringend. Wir brauchen freie

Software, die verhindert Hintertüren und
ermöglicht das Finden der Fehler. Noch mal

zusammenzufassen: das BSI ist gutmütig,
sie haben auch sehr gute Kryptographen,

aber sie haben es nicht gefunden. Und BSI
ist noch eine der staatlichen

Organisationen, die ich noch am ehesten
vertraue, sie haben es da episch gefailed.

Nochmal zur Erinnerung, diese Infineon-
Chips stecken in den ganzen Google

Chromebooks an, wo in Amerika wirklich
eine ganze Generation von Schülern mit

rumspringt: die haben's vermasselt. Also
offensichtlich klappt es nur, wenn es

öffentlich ist und da darf ich noch mal
auf meine geschätzten Kolleginnen und

Kollegen Bernstein, Lange und Nadja ...
äh, Namen vergessen?

cforler: Tanja?
ruedi: Heninger. Heninger, Entschuldigung.

Nadja Heninger. In dem Vortrag war einer der
Highlights, wo sie gezeigt haben: Ha! Da

sind die Ergeb.. da sind die Submissions,
Veröffentlichungen für diese Post-Quantum

Sache und innerhalb des ersten Abends, die
haben sich wirklich einen Spaß gemacht,

und haben irgendwie 10 % von den Sachen
innerhalb von drei Stunden zertrümmert.

Nehmen wir einfach mal zur Kenntnis, die
öffentliche Kryptographie ist so viel

besser als Kryptographie hinter
verschlossenen Türen. Dass das wirklich

hier ein Punkt ist: es ist nix
ideologisches, aber der Code muss lesbar

sein. Das ist vernünftigerweise unter
Open-Source-Lizenz, aber er muss lesbar

sein, die Community muss da reingucken.
Keine Behörde ist offensichtlich dazu in

der Lage, das in irgendeiner Weise
ordentlich zu machen. Der letzte Teil wird

nicht bei 'tuwat!' - Dankeschön.
Applaus

Der letzte Teil von 'tuwat!'
ist auch ein bisschen launisch, das habe

ich mir erlaubt, aber da irgendwie die
Mathematik scheinbar so abschreckend ist,

dass es kaum jemand programmiert, gehen
jetzt immer mehr Mathematiker dazu über,

brandneue Protokolle direkt zu
implementieren. Als Erstes muss ich

sehr.. als sehr positives Beispiel den
Herrn Kollegen Heiko Stamer erwähnen, der

hat auch am Datengarten einen sehr schönen
Vortrag gemacht, da ging es um verteilte

Schlüsselerzeugung und
Schwellenwertkryptographie. Da sind so

Sachen, wie wenn man sagt, in einer Welt,
wo man wenig Leuten vertrauen kann, ist es

gut kryptographische Verfahren haben, wo
man mathematische Beschreibung hat, des

Vertrauens. Also muss man einem aus einer
Gruppe vertrauen, zwei aus einer Gruppe..

das können wir alles mit
Schwellenwertkryptographie ganz gut

machen. Wie gesagt, das sind ganz aktuelle
Implementierungen von 2017, die Arbeiten

vorher sind auch relativ neu, die sind von
1987.

Kichern
Ja, ihr könnt ruhig lachen, das ist ein

Weilchen her, aber ihr könnt auch auf
diese Folie warten, weil diese Sachen -

oh, das ist jetzt auch rausgeflogen -
Blind Signature, wo ich also mit einem

Masterstudenten von mir ein bisl was
entwickelt hab, 2016, auch auf der Open

TechSummit vorgestanden hab, basiert auf
Blind Signature von David Chaum und die

sind von 1983. Und wir haben uns auch nur
soviel Zeit gemacht, weil jetzt die

Patente endlich abgelaufen sind.
Lachen

Spaß beiseite. Nicht alles, was wir hier
machen.. also, elliptische Kurven ist

schon relativ harte Mathematik. Auch die
Schwellwertkryptographie ist durchaus

harte Mathematik. Ich will das gar nicht
so sagen: "Also guckt es einfach an, dann

ist es lösbar". Aber es gibt einen ganzen
Kanon voll Sachen, wo es wirklich eine

kurze Frage an Kryptographen benötigt, um
dann den richtigen Tipp in die richtige

Richtung zu machen. Auch diese Sache, dass
wir halt programmieren, das war jetzt ein

bisschen arg schnippisch gesagt also: "Wir
tun idiotensichere Krypto entwickeln".

Idiotensicher ist ein relativer Begriff.
Ein armes, eingebettetes Gerät ohne

externe.. ohne interne Zufallsquelle hat
halt keine gute Zufallsquelle. Also

insofern noch einmal, also wir arbeiten
wirklich an einem System, möglichst robust

zu sein, in anderen Worten. Eine
Nachricht, die hier noch einmal vielleicht

an die Standardisierung geht, ist wirklich
der Punkt, zu sagen, GCM ist

offensichtlich für einige Probleme, also
wenn diese Leute richtige Nonces machen -

wunderbar, supi. Aber willkommen in der
realen Welt: Angreifer können dann

irgendwie anfangen, eben Nonces zu rempeln
und dann auf einmal die Sicherheit und die

Integrität des ganzen Systems nachhaltig
gefährden. Insofern ist das, glaube ich,

keine gute Idee, das als einzige Sache zu
machen. Enden wir mit den guten Worten von

Edward Snowden: "Krypto ist keine dunkle,
alte Kunst, sondern es ist wirklich eine

basic Protection, eine grundlegende..
Schutz da, wir müssen implementieren und

aktiv daran forschen". Und noch einmal, um
zusammenzufassen, zu sagen, auch nach

vielen Jahren Snowden muss ich sagen,
Kryptographie ist das, was uns vor der

Barbarei der Geheimdienste schützt. Die
Politik hat da auch in den letzten Jahren

nicht unbedingt sehr gute Ergebnisse
gezeigt. Insofern, vielen Dank für eure

Aufmerksamkeit.
Applaus

cforler: Just in time!
ruedi (zu cforler): Oh, da fehlten 1,2

Folien noch...
Herald: So es hat ja geheißen, man soll

die Kryptographen fragen, nur leider ist
die Zeit jetzt alle.

Unmuts-Laute
Das heißt, ihr dürft, wie angekündigt, die

Fragen über ein Käffchen stellen,
allerdings leider nicht mehr hier drin.

Aber trotzdem eine Runde schönen Applaus
für unsere beiden Vortragenden! Vielen

Dank.
Applaus

Abspannmusik

Untertitel erstellt von c3subtitles.de
im Jahr 2018. Mach mit und hilf uns!