 Unser nächster Talk ist über die einfache Wahrheit der Entropie. Wir alle wissen, dass ihr Zufall und Entropie braucht, wenn ihr so was wie Verschlüsselung oder zufällige Schlüssel machen wollt. Du hast nur vier als Rennumnummer. Du musst einen randomen Nummergenerator sichert. Was ist das? Ein ähnlicher, kryptischen, zuverlegen Nummerngenerator. Und wie ein Findet wird, der Titel oder das Thema dieses Talks sein. How I learned to stop worrying and love your random. Hallo. Okay, I'm very glad so many people showed up. Ich bin froh, dass so viele Leute gekommen sind. Insbesondere die Beschreibung dieses Vortrags. Okay, no. Anyway. Hi. Wie auch immer. Ich bin Philippo Walzauer. Ich arbeite für CloudFair und ich arbeite in Kryptografie und System-Menschel-Entwicklungen. And maybe in April 2014 you used my ... Und vielleicht in April 2014 habt ihr mein Heartbleed-Test verwendet. Well, thank you. Vielen Dank. Okay. Ich bin hier, um euch über zufällige Bytes zu erklären. Hier sind einige zufällige Bytes. Und hier, ihr könnt es nutzen. Aber wenn ihr ... Aber wenn ihr Moor gebraucht, Amazon verkauft euch dieses wunderbare Buch. Über 1 Mio. Nummern. Aber jetzt ernsthaft. Zufällige Nummern sind wichtig für viele dieser Sicherheitssysteme und Technologie. Das Wichtigste ist euer Verschlüsselungsschlüssel. Ihr wollt euren Verschlüsselungskie möglichst sicher und möglichst zufällig sammeln. Und viele andere Systeme verwenden Zufälligkeit, um Angriffe zu verhindern. Was macht ein Stream von zufälligen Bytes gut? Was macht einen guten zufälligen Bytes aus? Wir wollen die gleiche Wahrscheinlichkeit haben, alle Werte zu erreichen. Von 0 zu 256. Ihr wollt eure ... Eures nicht so aussehen lassen haben. Aber das ist nicht genug. Ihr wollt eure zufälligen Bytes auch unvorhersehbar sagen. Und das ist, wo die Aufgabe schwierig wird. Und wir programmieren Computer. Und Computer sind sehr deterministische Systeme. Das heißt, sie sind sehr vorhersehbar. Sie sind Maschinen, die dafür gebaut werden, immer den gleichen Code auszuführen. Und wenn wir sie fragen, etwas zu tun, was immer unterschiedlich ist, jedes Mal, wenn sie es ausführen, dann ist das schwer. Wo kann eine Computer eine Quelle für Zufälligkeit haben? Für eine vorhersehbarer Sackbarkeit? Und natürlich kann es aus unserer ... ... unser schmutzigen Fleischwelt, wo nicht alles immer dem vorhersehbaren Weg geht. Und jedes Mal, wenn ihr jetzt mal Mausen und herbewegt, dann macht ihr es jedes Mal die eine Auf-an-Drahten-Weise. Und jedes Mal, wenn eine Computer etwas von der Festplatte ... ... eine Sackbarkeit hat, dann ist das schwer. Und wenn ihr die Sackbarkeit habt, und jedes Mal, wenn eine Computer etwas von der Festplatte ließ, dann dauert es immer eine leicht andere Zeit als beim anderen Mal. Und alle diese Ereignisse sind einsehbar für den Kernel. Euer Kernel ist der, der alle eure Eigenschaften kontrolliert und sie messen kann und beobachten kann mit der benötigten Genauigkeit. Jeder von diesen Ereignissen hat einen Feinbereich von unterschiedlichen Werten. Wie weit dieser Bereich ist, nennt sich Entropie. Essenziell ist das, wie viele verschiedene Werte, wie weit diese Werte verteilt sind und auch wie einfach sie soviel vorherzusagen sind. Aber etwas, was sie definitiv nicht sind, ist gleichförmig. Weil das Lesen von einer Datendauert bestimmt nicht genau zwischen 0,5 bis 1,5 Nanosekunden. Es ist jedenfalls nicht genug, um alle unserer Bedürfnisse nach Zufälligkeit zu erfüllen. Wir haben Vorhersehbarkeit in unserem System. Und wir möchten das in einen Stream von zufälligen Zahlen verwandeln. Wir reinkommen einen CSP-RNG. Einen Kryptografen lieben die Abkürzung sehr lange. Das ist ein kryptografisches, sicherer Pseudo-Zufall-Zahlen-Generator. Es ist nicht so schwierig, das jetzt auszusprechen. Es ist nichts anderes als ein kryptografisches Werkzeug, das ein Eingabe findet und eine begrenzten Folge von zufälligen, gleichförmigen Bytes generiert, die von nur dem Input abhängen, den man gegeben hat. Wir haben diese Menge an zufälligen Events. Wir führen diese in den CSP-RNG ein und erhalten zu viele Bytes, die wir für alles verwenden können. Um zu verstehen, wie ein CSP-RNG versteht, stelle ich euch einen sehr einfachen vor. Einen, der auf Hash-Funktionen basiert. Wenn man anders jeder in der Audienz weiß, was eine Hash-Funktion ist, aber die Eigenschaften, die uns interessieren, sind der Fakt, dass die Ausgabe gleichförmig ist. Wenn man die Ausgabe einer Hash-Funktion nimmt, dann sind sie ununterscheidbar von Zufälligkeit, wenn man den Input nicht weiß. Es ist fast unmöglich, eine Hash-Funktion zu invertieren, was man aus dem Output nicht auf den Input schließen kann. Man weiß genau, wie der Input aussieht. Und schließlich braucht es einen begrenzten Anzahl an Input und gibt einen fest gesetzten Anzahl an Output. So funktioniert das. Wir starten mit einem Pool, z.B. in den Area von Bytes, und wir füllen ihn mit nullen. Jedes Mal, wenn ein neues Event kommt, z.B. wenn man die Maus bewegt, nehmen wir, dass dieses Event serialisieren ist, in den BNR-Format, und z.B. wenn Maus ist, hat Position 15 und 235. Wir nehmen dann den Hash, der von dem Pool und dem Event. Wir hashen sie zusammen und bekommen eine Ausgabe. Das ist der neue Wert unseres Pools, und wir wiederholen das. Statt den nullen haben wir also nun den Output von vorhin. Wir nehmen den Output und ein neues Event passiert. Z.B. die Festplatte liest etwas, und das dauert genau 1,27 Sekunden. Wir herrschen diese beiden wieder zusammen, also den alten Inhalt des Pools und die neue Information. Wir herrschen sie zusammen und bekommen einen neuen Wert des Pools. Ihr seht bereits, wo das hinführt. Ihr werdet holen das, jedes Mal, sobald ein neues Ereignis geschieht. Jedes Mal, wenn sich die Maus bewegt oder der CPO-Interrupt sich erhöht oder von der Festplatte gelesen wird, und wir nennen das eine Mischfunktion. Was bleibt ist, dass wir einen Entropie Pool nennen. Um diesen Wert herauszufinden, brauchen wir genau alle die Ereignisse, die dahin führen, die zu diesem Wert führen. Wenn sie ein Angreifer sind und sie aussehen möchten, wie mein Entropie Pool aussieht, dürfen sie keine bessere Methode haben, als genau diese Ereignisse vorherzuseigen, die bis zu diesem Punkt geschehen sind. Also haben wir jetzt dieses essentiell unverhersehbare Wert und möchten daraus zum Beispiel Schlüssel generieren. Wir können einfach Haschfunktion verwenden. Wir nehmen also einen Entropie Pool und haschen ihn mit einem Zähler. Möchten Sie 5.000 zufällige Bytes? Dann nehmen wir den Entropie Pool und mit 1, 1, 2 und so weiter und haschen die zusammen. Wir kriegen dann die ganzen Ausgaben und dann haben wir 5.000 Bytes, die genauso unverhersehbar sind als all die Ereignisse, die in den Pool reingespielt haben. Also zur Wiederholung. Haschfunktionen sind nicht invertierbar. Selbst wenn man die Ausgabe weiß, dann kommt man nicht zurück zum Entropie Pool. Und Haschfunktionen haben alle Bytes in der Eingabe beeinflussen alle Bytes der Ausgabe. Das heißt, sobald wir ein Bit falsch haben, dann ist die Ausgabe komplett anders. Also haben wir Gleichförmigkeit, weil Haschfunktionen gleichförmig sind und es ist unverhersehbar, weil ein Angreifer muss genau die Ereignisse herausfinden. Dann muss all die Hardest Timings herausfinden. Und die User-Eingaben, was für eine dritte Partei komplett unmöglich ist. Und das ist unbegrenzt, weil wir den Counter einfach weiter erhöhen können. Und wir werden das jetzt ein bisschen implementieren. Philipp hat mir gesagt, dass das in Ordnung ist. Aber das ist nicht, was dieser Talk darüber sein wird. Wenn CSP-RNGs das Werkzeug um ein bestimmtes Ereignis zu interpretieren, und wir haben alle diese unverhersehbaren Ereignisse beobachtet von dem Köln, und dann lassen wir einfach den Körn will, dass CSP-RNG laufen, dass CSP-RNG, dass CSP-RNG, dass CSP-RNG, dass CSP-RNG, dass CSP-RNG laufen, wenn wir zuverläge Dateien suchen. Das ist genau das, was die Nutzung macht, wenn es hier random laufen lässt. Es sieht aus wie eine Datei. Man kann es auslesen, wie eine Datei aus ist. Und jedes Mal, wenn ihr 100 Bytes auslässt, das Rente ist dieses CSP-RNG. Und gibt es euch die Aus. Gibt euch die 100 zuverlägen Bytes aus. Und das ist alles vermischt mit allen Ereignissen, die der Körn will zu dem Zeitpunkt hatte. Andere Operatings-Betriebssysteme haben einen anderen. Die haben die Staff Random. Das ist in ein Unix-System. Und unter Windows, man kann es mit Crypt-Gen-Random bekommen. Eine letzte Sache ist, ein CSP-RNG in den Köln zu tun ist nicht nur für Bedienbarkeit, sondern auch für Sicherheit. Weil der Köln kann diese unvorhersehbaren Ereignisse beobachten. Und das CSP-RNG ist just code. Ihr könnt es in eurer Bibliothek oder in eure Anwendung anwenden. Jetzt habt ihr das Problem. Wir täglich die Zufälligkeit von dem Körnel und bringt ihn zu der Anwendung. Das ist etwas, was ihr vergessen könnt zu tun, oder ihr könnt es falsch machen. Und darüber hinaus kann der Körnel den Memory-Space besser beschützen als Anwendung. Das ist ein großer Bereich, was Anwendungen falsch machen können. Als letztes habt ihr eine zentralisierte Anwendung, die einfach zu Managing ist. Ist hier irgendjemand der Debian-Server in 2008 gemanaget? Ich frage nur, es hat nichts damit zu tun später. Wir haben eine Lösung. Wir haben ein Werkzeug, um unvorhersehbare Ereignisse in einen Stream aus zu verliegen Bytes zu schieben. Warum reden darüber? Warum braucht man darüber ein Talk? Das ist natürlich eine falsche Annahme in diesem Feld. Einer der ist davon, durch die Linux-Managed-Pages erzeugt. Sie geben euch immer noch die Erscheinung, dass ihr Defrandem benutzen soll. Es ist ein bisschen sicher, aber ihr müsst euch fragen. Defrandem ist dieses CPSG. Das ist alles, was ich brauche. Was kann ich noch von Defrandem bekommen? Was hat es mehr? Das Ziel dieses Talks ist es euch das Wissen zu geben, wenn ihr Defrandem benutzt und wann nicht. Ich gehe ein bisschen in das Detail. Das ist direkt aus den Kernelkellen. Sowohl Defrandem als auch Defrandem. Alles, was ich jetzt sagen werde, gilt sowohl für Defrandem als auch Defrandem. Sie basieren beide auf einem Pool von 4.996 Bits. Und es ist als Folge von 32 Bitswörtern implementiert. Der Pool wird mit diesen zuverlingen Ereignissen gemischt, mit einer CAC-Hashfunktion. Die Diskzeiten werden in den Pool gesteuert. Jedes Mal, wenn so ein Ereignis passiert, wird diese schnelle Funktion ausgeführt und modifiziert den Pool mit diesem zuverlingen Event. Und die Generation von zuverlingen Bites passiert dann mit SHA-1. Das heißt, SHA-1 auf den Pool angewendet, sendet die Ausgabe und nimmt die Ausgabe und mischt es zurück in den Pool. Das ist ein bisschen anders als unser Design, dass ein Counter verwendet. Das kann man auch zurücksetzen können. Das hat also bessere Sicherheits-Eigenschaften. Was also passiert ist, wenn es eine Ausgabe nimmt, dann wird es wieder zurückgeführt. Und der nächste Output ist dann wieder SHA-1 auf den neuen Pool, wird wieder zurück in den Pool gemischt. Das ist selber Codes, selber Größe, selber Entropiequellen, so Random Reads. Selbst die Random Reads sind die gleichen Aufrufe an extra random User. Die einzige Unterschied ist, dass Def Random versucht, sehr viele schwierige Sachen zu machen. Wie viele Bits von Entropie in den Pool gemischt wurden. Das ist schon sehr schwierig. Denken Sie mal drüber nach. Eine Lesevergang hat so viele Sekunden gebraucht. Wir wissen nicht, wie viele verschiedene Ereignisse das braucht. Wir wissen nicht, ob das eine sich drehende, verrostete Platte ist. Oder ob es eine SSD-Platte ist, die genauso viel Zeit braucht. Wie viel Unfallsegparki da mit einen eingeflossen ist. Das heißt, es hat also einen Counter, um die Entropie zu schätzen, also die Art, die Unfallsegparki, den Pool steckt, einzuschätzen. Wenn man jetzt die Hash Funktionen auf den Pool anwendet, dann wird dieser Zähle reduziert. Wenn diese Nummer zu klein wird, dann blockiert. Das heißt, wenn wir von der Brandenburg lesen, kann es sein, dass man blockiert wird, bis mehr Zufalls-Ereignisse geschehen. Das ist in der heutigen Zeit nutzlos. Weil Entropie nicht ausläuft. Sobald der Pool unfallsegbar wird, ist der immer unfallsegbar, weil der Angreifer aus der Ausgabe überhaupt nichts lernen kann. Es sei denn, der CSP-NG ist kaputt und liegt Information über den Pool. Aber zu sagen, dass er kaputt ist, ist equivalent zu sagen, dass viele der Kryptografiemodule kaputt sind. Das heißt, dass Streamsiphers kaputt sind. Das sagt, dass CTR kaputt ist und TLS und PGPs sind kaputt. Aber wenn Kryptografen nicht wissen, wie man einen sicheren CPNG baut, dann heißt das, dass Kryptografen nicht andere wichtige Dinge bauen können, die wir uns heute verlassen, heutzutage. Aber ich bin nicht DJB, ich kann nicht sagen, ob Kryptografie verdammt ist. Aber ich kann sagen, dass Kryptografie vertraut also darauf, dass man sichere CPNGs hat. Das macht also Defrand and Blocking nutzlos. Das ist unakzeptabel, weil wenn man eine TLS-Anfrage bekommt, ich habe die Seite der PS-Seite, aber ich brauche erst noch ein bisschen Entropie. Wartet kurz. Das kann sogar gefährlich sein, weil man Informationen an Angreifer gibt über z.B. was andere Benutzer am Rechner gerade machen. Auf der anderen Seite ist Defurandom sicher für jede jegliche Kryptografieanwendung. Meine PGB-Geschleüsse sind z.B. aus Defurandom generiert. Ich bin nicht der Einzige, der das sagt. Boring SSL, Python, Go, Ruby benutzen Defurandom als die einzige Quelle für Zufall. Und hier ist eine lange Liste von Leuten, die genau das wiedergeben, was ich hier auf der Bühne sage. Ich hoffe, dass am Ende des Vortrags sie sehen, dass man Defurandom wirklich nicht braucht. Man braucht auch nicht messen, wie viel Entropie im Pool ist. Man muss auch den Pool nicht wieder nachfühlen mit Hevegid. Ich weiß nicht, wie man das ausspricht. Viele Leute nehmen Output aus Defurandom und führen es zurück nach Defurandom, damit der Pool nicht ausläuft. Das ist genau das, was der Kernel macht. Das ist offensichtlich auch sehr hochabwotet. Antwort auf Stack Overflow. Schließlich nimmt die Qualität von Zufallsnummern nicht ab. Es gibt keine sehr guten Zufallszahlen. Sie brauchen sie nach einer Weile. Das gibt es nicht. Das ist nur ein kleiner Teil, in dem Defurandom nicht das tut, was ihr wartet. Das ist der frühe Boot. Wenn ihr euch erinnert, dass alles, was wir gesagt haben, über unvorhersehbare Merknisse ist, die Maschine startet, habt ihr noch nicht genug Geheignisse beobachtet. Das hat Embedded Devices erwischt, Raspberry Pirates erwischt. Das ist genau genommen ein Linux-Problem. Das Problem ist, dass uRandom auch nicht beim Boot blockt, bevor es eingeführt ist. Die Lösung ist, dass Linux das speichern sollte, beim Runterfahren. Das benutzen beim Booten, um das zu verhindern. Damit wäre das gelöst, um das zusammenzufassen. CSPRN ist ziemlich cool, sehr gut und funktioniert. Ihr solltet nicht Defurandom benutzen. Ihr solltet Users bei CPRNG benutzen. Wenn ihr 100 Beits braucht, holt es euch von Defurandom. Ich habe viele Worte gemacht, um es falsch zu machen. Wenn ihr Fragen habt, warum nicht diese andere Sache kommen? Weil die Leute im Stream nicht hier sein können, fangen wir mit deren Fragen an. Die erste Frage. Wie erklären Sie? Auf einem ... ... dass die Ausgabe von Defurandom diegleich ist. Entschuldigung, ich habe die Frage beantworten. Von Kernel 433 behauptet jemand, dass manchmal die Ausgabe von Defurandom und Defurandom identisch ist, zu etwas, das aus Def-Input kommt. Ich bin mir nicht sicher, dass ich bekommen habe, welches System das benutzt worden ist. Das klingt nach einem sehr schlechten Bug. Wenn das der Fall ist, dann bin ich nicht ... ... weiß ich nichts davon, weil ich lese den Kernel, und das passiert nichts davon. Ich wäre froh davon, über so etwas offline zu reden. Zweite Frage. Was denkt ihr über Hardware-Zufassungen? Ich habe eine Folie dafür. Sehr schnell. Einige Plattformen haben einen zuverlägenden Generator. Mir wurde besagt, sie nutzten nur elektrische Rauschen, um Dinox und Dinox zu unterstützen. Sie werden sofort benutzt, um diesen Pool zu füllen. Wenn sie angeschaltet werden, ihr müsst euch nicht darum kümmern. Sie werden even noch besser funktionieren lassen. Noch eine Frage aus dem Stream. Was ist Ihre Meinung über diese Entropie-Hammel-Demonen? Da war eine Zeit, in der Ihre Entropie-Hammel-Demonen die Gründe hatten, dass sie zu existieren. Und Linungsimplementierung auf dieses Entropie-Besorgen nicht existierten. Aber heute haben Sie keine Heimgrund zu existieren. Ich wollte fragen über das frühe Boot-Problem. Sie sagen, dass wir ... Was passiert, wenn eine Maschine abstürzt? Würde man nicht von einem früheren Status booten? Ich glaube, dass der korrekte Weg, das zu tun, bevor man den Input benutzt, um den Pool zu initialisieren, vom letzten, runterfahren, es sollte gelöscht werden. Es ist schwierig, aber ja. Leider gibt es keine Zeit mehr, weil wir diesen Räumen räumen müssen. Morgen hat es 15.30 Uhr. Ich werde einen kleinen Workshop geben. Wie das zu implementieren. Ich habe nicht so viel Platz wie viele Leute wie Rhein-Posten. Ich habe nicht so viel Platz, was ich sagen soll.