Die Nutzlosigkeit von Lavalampen: Was Zufälligkeit wirklich bedeutet

 (loup-vaillant.fr)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Cloudflares Werbung für zufällige Zahlen auf Basis von Lavalampen ist weniger ein wesentlicher praktischer Beitrag zur Internetverschlüsselung als vielmehr Marketing und Security-Theater
  • In der Kryptografie ist nicht die inhärente Zufälligkeit eines Werts entscheidend, sondern wie viel ein Angreifer über diesen Wert weiß; dieser Wissensunterschied bestimmt die Sicherheit
  • Ein One-time pad verbirgt mit einem ausreichend zufälligen Schlüssel, der nur einmal verwendet wird, die Information des Klartexts, bricht aber, wenn derselbe Schlüssel wiederverwendet und mit beobachteten Informationen kombiniert wird
  • Moderne Systeme verwenden statt One-time pads CSPRNGs und Stromchiffren; ChaCha20 oder AES-256-CTR bieten mit 256-Bit-Schlüsseln praktisch nutzbare Sicherheit
  • Physische true RNGs sind schwer von Verzerrungen zu befreien und erhöhen die Sicherheit nur geringfügig; ein einfaches Design, bei dem Server ihre Seeds selbst erzeugen und fast key erasure verwenden, ist sicherer

Zufälligkeit hängt vom Wissen des Beobachters ab, nicht vom Objekt

  • Cloudflare bewirbt Lavalampen als Hilfe für die Internetverschlüsselung, doch dieser Ansatz trägt weniger wesentlich zur Sicherheit bei als dass er Marketing und Security-Theater ist
  • Neben Lavalampen verwendet Cloudflare physische Vorrichtungen für Unvorhersagbarkeit wie doppelte Pendel, Wellenbewegung und Mobiles
  • Eine XKCD-artige Funktion, die nur return 4 ausführt, gibt immer 4 zurück und ist damit als Objekt selbst nicht zufällig; wenn der Aufrufer aber nur die Information „eine mit einem fairen Würfel gewählte Konstante“ kennt und sie einmal aufruft, kann sie in der Wahrscheinlichkeitsverteilung des Beobachters als zufällig behandelt werden
  • In der Kryptografie ist die wichtige Frage nicht, ob das Ergebnis inhärent zufällig ist, sondern wie viel ein Angreifer über dieses Ergebnis weiß
  • Selbst bei demselben Wert verändert sich die Bedeutung von Zufälligkeit je nachdem, wer welche Informationen hat; in kryptografischen Systemen bestimmt dieser Wissensunterschied die Sicherheit

Wie das One-time pad funktioniert und scheitert

  • In der Analogie mit Russischem Roulette kennt ein Komplize die Position der Kugel und nennt nach außen nur das Ergebnis, das entsteht, wenn er einen zuvor mit dem Spieler geteilten Würfelwert zur Kugelposition addiert
  • Der Spieler kann den Würfelwert vom ausgerufenen Wert abziehen und so die Kugelposition rekonstruieren, aber ein Dritter kennt den Würfelwert nicht und kann aus dem ausgerufenen Wert allein die Kugelposition nicht bestimmen
  • Bei einem fairen Würfel ist die Prior-Wahrscheinlichkeit P(Ci), die der Gegner hat, dieselbe wie die Posterior-Wahrscheinlichkeit P(Ci|S3), nachdem er eine bestimmte Zahl S3 gehört hat
  • Nach der Bayes-Formel gilt P(Ci|S3) = P(Ci) × 1/6 ÷ 1/6 = P(Ci), der Gegner lernt also trotz des ausgerufenen Werts überhaupt nichts
  • Das ist der Kern des One-time pad: Wird ein ausreichend zufälliger Schlüssel nur einmal mit der Nachricht kombiniert, verrät der Geheimtext nichts über den Klartext
  • Wird derselbe Schlüssel in einem zweiten Spiel wiederverwendet, kann der Gegner wegen der im ersten Spiel offengelegten Informationen den möglichen Bereich des Würfelwerts eingrenzen
  • Wenn im ersten Spiel bestätigt wurde, dass die ersten vier Kammern der Trommel leer sind, weiß der Gegner, dass als Würfelwert nur 3 oder 4 infrage kommen; ruft der Komplize im zweiten Spiel „Four“, erhält er zusätzlich die Information, dass die Kugel entweder in der ersten oder in der letzten Kammer liegt
  • Ein One-time pad ist seinem Namen nach nur einmal sicher; wird derselbe Schlüssel wiederverwendet, kombinieren sich beobachtete Geheimtexte mit früheren Informationen und die Sicherheit bricht zusammen

Schlüssellänge und die praktische Sicherheit moderner Kryptografie

  • Im Internet werden statt Kugelpositionen Bits und Bytes übertragen; eine 1-Bit-Nachricht mit „yes/no“ lässt sich mit einem einzelnen Münzwurf verbergen
  • Bei Kopf bleibt die Nachricht unverändert, bei Zahl werden „yes“ und „no“ vertauscht; für einen Beobachter ohne Kenntnis des Münzergebnisses bleibt der Klartext verborgen
  • Wenn aber mit demselben Münzergebnis zwei Bits verschlüsselt werden, reduziert der Geheimtext die vier möglichen Klartexte auf zwei
    • „Yes yes“ bedeutet, dass der Klartext entweder „yes yes“ oder „no no“ war
    • „No no“ bedeutet, dass der Klartext entweder „no no“ oder „yes yes“ war
    • „Yes no“ bedeutet, dass der Klartext entweder „yes no“ oder „no yes“ war
    • „No yes“ bedeutet, dass der Klartext entweder „no yes“ oder „yes no“ war
  • Verallgemeinert gilt: Wenn n Bits mit einem einzigen Münzwurf verschlüsselt werden, schrumpft der mögliche Klartextraum von 2^n auf 2
  • Um n Bits im vollständigen informationstheoretischen Sinn korrekt zu verschlüsseln, braucht man einen n-Bit-Schlüssel; bei längeren Nachrichten wird ein Teil rekonstruierbar, und wenn der Beobachter bereits mehr als n Bits Information kennt, kann in der Regel die gesamte Nachricht rekonstruiert werden
  • Es scheint, als brauche man astronomische Mengen an Zufallszahlen, um auf den gesamten von Cloudflare verarbeiteten Traffic One-time pads anzuwenden, aber moderne Systeme verwenden keine One-time pads
  • Bei korrekter Verwendung von Authenticated Encryption und Stromchiffren lassen sich mit einem 256-Bit-Schlüssel große Datenmengen praktisch sicher verschlüsseln
  • Mit geeigneten Stromchiffren wie ChaCha20 oder AES-256-CTR müsste ein passiver Beobachter ungefähr 2^255 Kombinationen ausprobieren, um den Klartext zu finden
  • Für jemanden, der den Schlüssel kennt, ist der Schlüsselstrom vollständig vorhersagbar; für einen Beobachter auf dem Niveau der gesamten irdischen Zivilisation, der den Schlüssel nicht kennt, verhält er sich wie vollständig unvorhersagbare „Entropie“
  • Der formale Name dafür ist Cryptographically Secure Pseudo-Random Number Generator, kurz CSPRNG

Echte Zufallszahlenerzeugung und fast key erasure

  • Um aus einem einzigen 256-Bit-Master-Schlüssel die benötigten Zufallszahlen abzuleiten, kann man den Master-Schlüssel auf einem Master-Server oder in einem Hardware-Sicherheitsmodul halten, lokale Schlüsselströme erzeugen und diese sicher im gesamten Unternehmen verteilen
  • Jeder Server oder CPU-Kern kann dann mit einem 256-Bit-lokalen Schlüssel und einem Zähler so viele Zufallsbytes erzeugen, wie benötigt werden
  • Das Kernproblem ist, dass sichere Verteilung sehr schwierig ist
  • Wenn ein lokaler Schlüssel kompromittiert wird, sind alle Nachrichten gefährdet, die diese Maschine in der Vergangenheit verschlüsselt hat oder künftig verschlüsseln wird; wird der Master-Schlüssel kompromittiert, ist der Schaden viel größer
  • fast key erasure ist ein Verfahren, um sowohl die Wahrscheinlichkeit eines Schlüssellecks als auch den Schaden im Leckfall zu verringern
    • Am Anfang eines 512-Byte-Puffers liegen 32 Byte zufälliger Seed
    • Mit diesem Seed werden 512 Byte erzeugt und der Puffer damit überschrieben
    • Alles außer den ersten 32 Byte wird auf Anfrage ausgegeben und danach gelöscht
    • Ist der Puffer aufgebraucht, beginnt der Prozess wieder beim Erzeugungsschritt
  • „erasure“ kommt daher, dass der Erzeugungsschritt den bisherigen Schlüssel überschreibt
  • Wenn der Puffer kompromittiert wird, können künftige Nachrichten gefährdet sein, aber bereits ausgegebene und gelöschte frühere Werte bleiben geschützt
  • Noch wichtiger ist, den Puffer nicht zu duplizieren
    • Es dürfen keine zwei Ströme aus demselben Seed erzeugt werden
    • Beim Forken eines Prozesses muss der Strom geeignet in zwei Teile aufgeteilt werden
  • Wenn mehr als ein identischer Strom entsteht, können sich dieselben Zufallsbytes wiederholen, was katastrophal sein kann
  • Deshalb werden RNGs im Userspace nicht empfohlen; Kernel-RNGs sind zwar nicht einfach, aber es gibt weniger Instanzen, die auditiert werden müssen

Auswahl von Stromchiffren und Sicherheitsmarge

  • Auch die interne Blockgröße der zugrunde liegenden Stromchiffre ist wichtig
  • Der 512-Bit-Block von ChaCha20 ist groß genug, um sich darüber keine Sorgen zu machen, und auch der 128-Bit-Block von AES ist groß genug
  • Gegen AES gibt es praktikable Angriffe mit deutlich besseren Erfolgschancen als einfache Brute Force; AES-128 gilt möglicherweise als brechbar, AES-256 dagegen als sicher
  • Kleinere Blockgrößen müssen für diesen Einsatzzweck als gebrochen gelten
  • Empfohlene Optionen sind ChaCha20 oder AES-256, mit einer Präferenz für ChaCha20
  • Moderne Stromchiffren sind sehr sicher, und unter Berücksichtigung der Fachliteratur sowie des Einsatzes durch verschiedene Regierungen, insbesondere die USA, ist es sehr unwahrscheinlich, dass sie in naher Zukunft gebrochen werden
  • Da sowohl CSPRNG als auch Verschlüsselung auf Kryptografie beruhen, bricht das Gesamtsystem, wenn eines von beiden gebrochen wird
  • Wenn man annimmt, dass AES-256 oder ChaCha20 in naher Zukunft mit nicht zu vernachlässigender Wahrscheinlichkeit gebrochen werden könnten, gibt es Möglichkeiten, die Sicherheitsmarge zu erhöhen
    • Wenn man für CSPRNG und Verschlüsselung dieselbe Chiffre verwendet, nimmt man dem Angreifer die Option, einfach AES oder ChaCha zu brechen; er muss dann eine bestimmte Chiffre brechen
    • Mehr Runden erhöhen nicht nur die Kosten von Brute Force, sondern helfen auch gegen Angriffe, die besser sind als Brute Force
    • AES-256 verwendet 14 Runden, ChaCha20 verwendet 20 Runden
    • Für ChaCha7 gibt es Angriffe, die besser sind als exhaustive search, für ChaCha8 aktuell nicht
    • ChaCha20 verwendet 20 Runden, um genügend Reserve zu haben, falls plötzlich ein Angriff auf 12 Runden entdeckt wird
  • Mehrere Systeme parallel zu betreiben erhöht die Gesamtkomplexität stark, und diese Komplexität führt mit höherer Wahrscheinlichkeit zu fatalen Schwachstellen als ein mathematischer Angriff auf eine der Komponenten

Physische true RNGs und der initiale Seed

  • Die Annahme, physische true RNGs seien sicherer als theoretisch brechbare CSPRNGs, sollte vorsichtig betrachtet werden
  • Zufällige Ausgaben müssen für Sicherheitszwecke oft frei von erkennbaren Verzerrungen sein; das bedeutet eine so gleichmäßige Verteilung, dass selbst nach Analyse von 2^64 Samples keine Verzerrung nachweisbar ist
  • Es ist schwierig, physische Prozesse auf dieses Niveau zu trimmen, weshalb man in der Praxis den Output der Rauschquelle durch einen kryptografischen Hash laufen lassen muss
  • Verglichen mit einer Stromchiffre mit fast key erasure ist der Sicherheitsgewinn gering, die Performance-Kosten können je nach Bedarf aber hoch sein
  • Um eine beliebige Menge Zufallszahlen zu erzeugen, braucht man zunächst einige Seed-Bytes
  • Wenn man eine unvorhersagbare Quelle lange genug digital aufzeichnet, um mehr als 256 Bit Entropie zu erhalten, und diese Aufzeichnung dann mit einem 256-Bit-Hash wie SHA-256 oder BLAKE2s hasht, erhält man einen Master-Seed
  • Mögliche Zufallsquellen sind Hardware Random Number Generator, CPU-Jitter, beliebige Fotos von Bäumen, ein Beam Splitter, Tastenanschläge oder Mausereignisse, Würfel und Ähnliches
  • Die Verteilung von Zufallszahlen zwischen Standorten ist unpraktisch, nicht nur komplex, sondern potenziell auch selbst eine Ursache für Kompromittierungen
  • Zufallszahlen werden nicht nur einmal benötigt, sondern immer dann erneut, wenn ein Verdacht auf Kompromittierung besteht oder wichtige Sicherheitsupdates anstehen
  • Um Aufwand und Risiko zu senken, ist es in der Regel besser, den vom jeweiligen Computer zu verwendenden Zufalls-Seed direkt auf diesem Computer zu erzeugen, statt ihn von außen zu beziehen
  • Gewöhnliche Server verfügen über CPU-Jitter, Peripherie-Interaktionen und Netzwerkereignisse, was für normale Einsatzzwecke meist ausreicht
  • Wer zusätzliche Sicherheit will, kann pro Server-Rack ein paar Hardware-RNG-Dongles ergänzen; komplexere Verfahren darüber hinaus sind unnötige Komplexität

Warum eine Lavalampenwand unnötig ist

  • Cloudflares Lavalampe-Wand ist unnötig; wenn sie über das lokale Netzwerk mit Servern verbunden wird, erhöht sie nur die zusätzliche Komplexität und die Angriffsfläche
  • Bei korrekter Implementierung kann das Risiko sehr gering sein, aber selbst dann ist es größer als der Nutzen
  • Wenn Cloudflare Sicherheit ernst nimmt, sollte das Unternehmen die Nutzung von Lavalampen einstellen und sie nur noch als Dekoration und für Marketingzwecke behalten
  • Es ist einfacher und sicherer, wenn Server ihre Zufallszahlen jeweils selbst erzeugen
  • Möglicherweise macht Cloudflare das ohnehin bereits so

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Lobste.rs-Kommentare

  • Der Artikel wirkt so, als sei er auf einer falschen Annahme aufgebaut und zudem ein wenig ein Spielverderber. Moderne Zufallszahlengenerierung verwendet mehrere unabhängige Entropiequellen und mischt diese während des Betriebs fortlaufend per Hash in den Entropie-Pool ein
    Ein Computer hat nicht nur einen einzigen „zufälligen Seed“, vielmehr wird während der Laufzeit immer wieder mit Entropie aus verschiedenen Quellen nachgesät, etwa nach dem Muster seed = hash(seed, new_data). Dass man zusätzlich Kameradaten von Lava-Lampen einspeist, verringert die Systemsicherheit überhaupt nicht. Daten, die in den Entropie-Pool gelangen, werden zusammen mit bereits vorhandenen Daten gehasht. Das System ist so ausgelegt, dass es sicher bleibt, solange es auch nur ein klein wenig Information gibt, die dem Angreifer unbekannt ist; deshalb beschädigt auch das Mischen vieler Daten mit sehr unterschiedlicher Zufälligkeit die Sicherheit nicht
    Lava-Lampen schaden der Systemsicherheit nicht, und ich persönlich sehe sie als ein unterhaltsames und funktionales Kunstwerk, das Teil des Systems ist. Sie verbessern die Qualität der Zufallszahlen in extrem geringem Maß und machen die Konzepte von Zufälligkeit und Entropie anschaulich

    • Stimmt, aber Kernel-Zufallszahlengeneratoren nutzen schon seit über 30 Jahren verschiedene Formen von Hardware-Zufälligkeit, und man sollte nicht übertreiben, wie „ständig“ oder „fortlaufend“ dabei neu gesät wird
      Zufälligkeit aus der Hardware wird zwar laufend gesammelt, aber der Linux-Zufallszahlengenerator wird periodisch neu gesät. In der ersten Minute nach dem Booten geschieht das alle paar Sekunden, danach verlangsamt es sich auf etwa einmal pro Minute

      https://zx2c4.com/projects/linux-rng-5.17-5.18/…

    • Ich weiß nicht, wo der Eindruck entstanden sein soll, dass gesagt oder angedeutet wurde, bestehende Systeme würden das nicht so machen. Hier ging es — abgesehen vom Lava-Lampen-Teil — nicht darum, bestehende Systeme zu beschreiben, sondern darum zu betonen, wie wenig wir tatsächlich brauchen, nämlich 256 Bit
      Bei der Aussage, dass zusätzliche Kameradaten von Lava-Lampen die Sicherheit nicht reduzieren, denke ich an die Attack Surface. Man fügt einen eingebetteten Computer und die Netzwerkkommunikation zwischen diesem Computer und dem Server hinzu. Für mich ist dieses zusätzliche kleine Risiko weit größer als das absurd kleine Risiko, bei dem man tatsächlich Lava-Lampen bräuchte

  • Eine andere Formulierung der philosophischen Unterscheidung wäre: Wie viele mögliche Ergebnisse gibt es, und wie vorhersagbar ist das Ergebnis
    Für kryptographische Zwecke hat man sich bei der Vorhersagbarkeit auf ein Niveau von 2^-256 eingependelt, aber interessant ist, dass es alltägliche Prozesse mit weit mehr möglichen Ergebnissen gibt, und manchmal möchte man, dass wirklich alle möglichen Ergebnisse erzeugbar sind, selbst wenn manche extrem unwahrscheinlich sind. In solchen Fällen könnte kryptographische Zufälligkeit unzureichend sein
    Ein Standard-Kartendeck hat 52! mögliche Mischungen, also ungefähr 2^226, sodass ein kryptographisch zufälliger Seed alle Mischungen erzeugen kann. Aber wenn man Uno spielt oder mehrere Kartendecks zusammen mischt, hat ein 256-Bit-Zufallszahlengenerator nicht genug Zustand, um alle Mischungen zu erzeugen. Wenn die gesamte User-Space-Zufälligkeit des Systems aus dem Kernel kommt und der Kernel alle Hardware-Zufälligkeit durch einen 256-Bit-CSPRNG leitet, reicht das in Las Vegas vielleicht nicht zum Kartenmischen :-)
    Was im Artikel fehlt, ist das Reseeding, das ein interessantes Thema ist, weil es zeigt, wie es mit schnellem Key Erasure zusammenwirkt und wie schwierig es ist, den initialen Seed zu bekommen. Der Artikel deutet an, Linux verwende nur CPU-Jitter, aber das ist eine zu starke Vereinfachung. Linux nutzt viele Zufälligkeitsquellen, und der Jitter-Tanz ist nur das letzte Mittel

    • Nein. In der Praxis macht man das absolut nicht so
      In der realen Welt bekommt man noch nicht einmal 2^128 Stichproben. Tatsächlich sind es viel weniger, und deshalb ist selbst AES-128 für viele Zwecke weiterhin ausreichend sicher. Wenn die Zahl möglicher Ergebnisse größer als 2^256 ist, dann ist es vollständig unmöglich, „alle möglichen Ergebnisse auszuführen“. Das kann man getrost vergessen. So etwas existiert nicht
      Auch beim Blackjack mit sechs statt einem Kartendeck will man in der Praxis kein Mischverfahren, das die Wahrscheinlichkeit wirklich gleichmäßig über alle möglichen Mischungen verteilt. Es genügt eine Verteilung, die so gut ist, dass man den Unterschied nicht erkennen kann, selbst wenn man so viele Stichproben wie möglich zieht. Selbst wenn die Zahl der Mischungen auf 2^256 oder sogar 2^128 begrenzt wäre, würde man keinen Unterschied bemerken
      Dass der Artikel das Reseeding auslässt, war Absicht. Man braucht es nur zu bestimmten Zeitpunkten, etwa bei vermuteten Kompromittierungen und manchen Sicherheitsupdates. Dasselbe gilt beim Neustart, falls es einfacher oder sicherer ist, als den Zustand des Zufallszahlengenerators in nichtflüchtigem Speicher aufzubewahren. Deshalb spreche ich lieber nicht von „Reseeding“, sondern davon, mit einem neuen initialen Seed neu zu starten
      Im Normalbetrieb ist Reseeding überhaupt nicht nötig. Wenn man es trotzdem implementiert, erhöht man nur die Komplexität
      Die Andeutung, Linux nutze nur CPU-Jitter, hätte ich überprüfen sollen. So wie ich es verstanden hatte, sei das zum Bootzeitpunkt die einzige Quelle gewesen. Vor allem bevor es Benutzereingaben und Netzwerkverkehr gibt, dachte ich, das sei so. Kennst du andere Quellen? Unterstützung für Hardware-Zufallszahlengeneratoren dürfte es natürlich schon geben
    • Diese Unterscheidung zwischen Möglichkeit und Vorhersagbarkeit erinnert mich an die Arbeit von Shamir, Rivest und Adleman. Darin wird bewiesen, dass es mathematisch unmöglich ist, dass zwei Menschen per Telefon mit einem virtuellen Kartendeck sicher Poker spielen
      Es geht nicht. Aber wenn wir diesen Punkt beiseitelassen, dann funktioniert es sicher so …
    • Interessant. Wenn ich mich richtig erinnere, ist das Lesen aus einer echten Zufallsquelle ein blockierender Vorgang, sodass es ziemlich lange dauern kann, bis genügend Zufälligkeit gelesen wurde, wenn der Kernel nicht genug zufällige Bytes hat
      Ich vermute, dass Zufallszahlengenerator-Hardwarekarten nicht nur existierten, um eine höhere Bitdichte zu liefern, sondern auch, um parallele Zufallsquellen zu haben, die nach Bits pro Zeiteinheit gemessen werden

  • Mit vielen der einzelnen Aussagen bin ich nicht stark uneinig, aber das Gesamtargument wirkte auf mich verschwommen. Der Artikel baut auf „moderne Kryptographie braucht viel weniger echte Zufälligkeit, als die Leute denken“ auf und landet dann bei „deshalb sind Lava-Lampen schlechter, weil sie die Attack Surface vergrößern“
    Beide Aussagen können wahr sein, aber der Weg von der einen zur Schlussfolgerung wirkt grob

    • Ehrlich gesagt finde ich auch die Erzählstruktur nicht besonders zufriedenstellend. Die Hälfte der Schlussfolgerung steht allerdings schon im Titel

  • LavaRand hat so etwas schon vor mehr als 20 Jahren gemacht. Damals war es niedlich, aber die Kamerasensoren jener Zeit waren viel kleiner und wegen vorhersehbarer Eigenschaften wie der Linsen als Entropiequelle nicht besonders gut
    Ich mag Lava-Lampen zwar, aber der Stromverbrauch einer Wand mit Hunderten davon ist für so eine Spielerei doch ziemlich hoch

  • Kommt Selbstwerbung ziemlich nahe. Fast nie werden Links geteilt, und wenn doch, dann eigene. Die letzten 5 Beiträge verweisen in 5 von 5 Fällen auf eigenes Material

    • Das hängt davon ab, wie man „stories and comments“ auslegt
      „Es ist gut, wenn ein Autor in der Community aktiv ist, aber das darf nicht als reines Einwegwerkzeug missbraucht werden, um Produktankündigungen zu posten oder Traffic auf die eigene Arbeit zu lenken. Als Faustregel sollte Selbstwerbung weniger als ein Viertel der eigenen stories und comments ausmachen.“
      Bei 15 Beiträgen und 1399 Kommentaren ist die Person ganz klar in der Community aktiv. Vorausgesetzt natürlich, dass sie nicht unter jedem eigenen Beitrag mehr als 90 eigene Kommentare hinterlässt

  • Cloudflare hat Entropie aus Lava-Lampen beigesteuert, die University of Chile Erdbebendaten, und wenn ich mich richtig erinnere, hat die EPFL Messwerte zum radioaktiven Zerfall beigetragen; dazu kamen noch verschiedene andere Beiträge zur anfänglichen Schlüsselerzeugungszeremonie des drand-Netzwerks
    Hätte man auch einen CSPRNG verwenden können? Natürlich. Aber wo bliebe dann der Spaß?

    • Spaß ist in Ordnung. Lava-Lampen sind hübsch, und ihre Wellenwand ist wirklich wunderschön. Die Grenze ist dort überschritten, wo so getan wird, als würde das tatsächlich der Sicherheit helfen