Das Chaos in den Cloudflare-Büros nutzen

Im Kinderbuch „Die Schnecke und der Buckelwal“ kehrt die Hauptfigur nach einem unerwartet weit entfernten Abenteuer zu Kommentaren wie „Wie die Zeit vergeht“ und „Bist du nicht groß geworden!?“ nach Hause zurück. Es ist etwa vier Jahre her, dass wir das letzte Mal über LavaRand geschrieben haben. Seither haben sich viele Menschen dafür interessiert, wie Cloudflare physische Entropiequellen nutzt, um die Sicherheit im Internet zu erhöhen. Was ursprünglich mit einer einzigen Art von physikalischer Entropiequelle begann – Lavalampen – ist gewachsen und vielfältiger geworden. Wir möchten Ihnen ein wenig über die Geschichte von LavaRand erzählen. Dieser Blog-Beitrag befasst sich mit den neuen Quellen des „Chaos“, die zu LavaRand hinzugefügt wurden, und damit, wie Sie dieses nutzbar gemachte Chaos in Ihrer nächsten Anwendung einsetzen können. Wir werden uns damit beschäftigen, wie öffentliche Zufälligkeit die Verwendung von öffentlich vertrauenswürdiger Zufälligkeit ermöglichen kann – stellen Sie sich vor, Sie müssten den Inhabern einer „zufälligen Ziehung“ nicht beim Wort nehmen, wenn sie behaupten, das Ergebnis sei nicht in irgendeiner Weise manipuliert worden. Und schließlich besprechen wir die Timelock-Verschlüsselung, mit der sichergestellt wird, dass eine Nachricht erst zu einem bestimmten Zeitpunkt in der Zukunft entschlüsselt werden kann.

Die Entropie, die von unserer Wand aus Lavalampen in San Francisco ausgeht, spielt seit langem eine Rolle in der Zufälligkeit, die die über Cloudflare hergestellten Verbindungen sichert.

Lavalampen mit fließendem Wachs.

Die Server von Cloudflare verarbeiten zusammen mehr als 55 Millionen HTTP-Anfragen pro Sekunde, von denen die überwiegende Mehrheit über das TLS-Protokoll gesichert wird, um Authentizität und Vertraulichkeit zu gewährleisten. Technisch gesehen benötigen kryptografische Protokolle wie TLS eine zugrundeliegende Quelle von sicherer Zufälligkeit – andernfalls würden die Sicherheitsgarantien hinfällig.

Sichere Zufälligkeit, die in der Kryptographie verwendet wird, muss rechnerisch nicht von „echter“ Zufälligkeit unterscheidbar sein. Zu diesem Zweck muss sie statistische Zufallstests bestehen und der Output muss für jeden rechnerisch begrenzten Gegner unvorhersehbar sein, unabhängig davon, wie viele vorherige Outputs er bereits gesehen hat. Der typische Weg, dies zu erreichen, besteht darin, einen zufälligen „Seed“ zu nehmen und ihn in einen kryptografisch sicheren Zufallszahlengenerator (Cryptographically Secure Pseudorandom Number Generator, CSPRNG) einzuspeisen, der auf Anfrage einen im Wesentlichen unendlichen Strom unvorhersehbarer Bytes erzeugen kann. Die Eigenschaften eines CSPRNG stellen sicher, dass alle Outputs für jeden, der den internen Zustand nicht kennt, praktisch nicht von echten Zufallsoutputs zu unterscheiden sind. Das alles hängt jedoch davon ab, dass man zunächst einen sicheren zufälligen Startwert (Seed) hat. In diesem Blog-Beitrag erfahren Sie mehr über echte Zufälligkeit im Vergleich zu Pseudozufälligkeit, während Sie in diesem Blog-Beitrag einige großartige Beispiele dafür finden, was bei unsicherer Zufälligkeit schief gehen kann.

Viele Jahre lang verließen sich die Server von Cloudflare auf lokale Entropiequellen (wie z. B. das genaue Timing von Paketeingängen oder Tastaturereignissen), um ihre Entropie-Pools zu füllen. Es gibt zwar keinen Grund zu der Annahme, dass die lokalen Entropiequellen auf diesen Servern unsicher sind oder leicht kompromittiert werden könnten, aber wir wollten uns gegen diese Möglichkeit absichern. Unsere Lösung bestand darin, ein System einzurichten, bei dem unsere Server ihre Entropie-Pools regelmäßig mit echter Zufälligkeit aus einer externen Quelle auffrischen konnten.

Das bringt uns zu LavaRand. „Lavarand“ ist seit langem die Bezeichnung für Systeme, die für die Erzeugung von Zufälligkeit verwendet werden (erstmals von Silicon Graphics im Jahr 1997). Cloudflare hat seine Instanziierung eines LavaRand-Systems 2017 als ein System eingeführt, das Entropie von der Wand mit Lavalampen in unserem Büro in San Francisco sammelt und über eine interne API zur Verfügung stellt. Unsere Server fragen dann in regelmäßigen Abständen die API ab, um frische Zufallsdaten von LavaRand abzurufen und sie in ihre Entropie-Pools einzubauen. Die Beiträge von LavaRand können als Gewürz betrachtet werden, das dem Entropie-Pool-Mix hinzugefügt wird! (Weitere technische Details finden Sie in unserem früheren Blog-Beitrag.)

Lavalampen im Büro von Cloudflare in San Francisco.

Unsere Lavalampen in San Francisco arbeiten seit Jahren unermüdlich daran, unsere Systeme mit frischer Entropie zu versorgen, aber jetzt haben sie Geschwister in der ganzen Welt, die ihnen bei ihrer Aufgabe helfen! Mit unserem Unternehmenswachstum hat sich auch die Vielfalt der Entropiequellen in und aus unseren Büros erhöht. Das Team von Cloudflare Places arbeitet hart daran, sicherzustellen, dass unsere Büros Aspekte unserer Werte und Kultur widerspiegeln. An mehreren unserer größeren Bürostandorte befinden sich Installationen von physischen Entropie-Systemen, die wir im Laufe der Zeit in LavaRand integriert haben. Die faszinierende Anziehungskraft dieser Systeme besteht darin, dass sie auf einer physikalischen Mechanik beruhen, die wir instinktiv als zufällig wahrnehmen. Die Klumpen erwärmter, aufsteigender „Lava“, die an kühleren, sinkenden Klumpen in Lavalampen vorbeischwimmen, ziehen unsere Aufmerksamkeit auf sich, ebenso wie andere unvorhersehbare (und oft schöne) dynamische Systeme unser Interesse wecken.

Für Besucher unseres Londoner Büros ist eine Wand aus Doppelpendeln zu sehen, deren schöne Schwünge eine weitere Quelle der Entropie für LavaRand und den Pool der Zufälligkeit darstellen, aus dem die Server von Cloudflare schöpfen.

Nahaufnahme der ausgestellten Doppelpendel im Londoner Büro von Cloudflare.

Für das ungeübte Auge mögen die Schatten der Pendelständer und die der rotierenden Arme an der Rückwand chaotisch erscheinen. Wenn dem so ist, sollte diese Installation als Erfolg gewertet werden! Unterschiedliche Lichtverhältnisse und diese Schatten tragen zu dem Chaos bei, das von dieser Entropiequelle eingefangen wird.

Ausgestellte Doppelpendel im Londoner Cloudflare-Büro bei wechselnden Lichtverhältnissen.

Selbst wenn diese Arme auf eine zweidimensionale Bewegung beschränkt sind, ist der von den Armen zurückgelegte Weg faszinierend vielfältig und kann mathematisch als chaotisch dargestellt werden. Ja, selbst, wenn man den Luftwiderstand, die Temperatur und die Umgebung außer Acht lässt und davon ausgeht, dass die Mutation vollständig deterministisch ist, lässt sich die resultierende langfristige Bewegung nur schwer vorhersagen. Das System reagiert insbesondere sehr empfindlich auf die Anfangsbedingungen. Dieser Anfangszustand – wie die Arme in Bewegung gesetzt werden – gepaart mit deterministischem Verhalten ergibt einen eindeutigen Pfad, der verfolgt wird, bis das Pendel zum Stillstand kommt und das System von einem Cloudflare-Mitarbeitenden in London wieder in Bewegung gesetzt wird.

Das schöne neue Cloudflare-Büro in Austin, Texas, feierte kürzlich sein einjähriges Bestehen. Auch dieses Büro trägt seinen Teil zur physikalischen Entropie bei: Über dem Eingang des Cloudflare-Büros in der Innenstadt von Austin hängt eine Installation aus durchsichtigen regenbogenfarbigen Mobiles. Diese wirbeln, reflektieren das wechselnde Licht und werfen farbige Muster auf die umliegenden Wände. Die hängenden Mobiles und ihre Schatten reagieren sehr empfindlich auf die physische Umgebung, wie z. B. das Öffnen und Schließen von Türen, Änderungen der Klimaanlage und das Licht der Umgebung. Die faszinierende und sich verändernde Kulisse dieses chaotischen Systems wird periodisch aufgezeichnet und in den Zufallsstrom von LavaRand eingespeist.

Hängende Regenbogen-Mobiles im Cloudflare-Büro in Austin.

Wir haben die neuen Quellen des Bürochaos in das LavaRand-System integriert (das immer noch LavaRand heißt, obwohl es viel mehr als nur Lavalampen enthält), und zwar auf dieselbe Weise wie die bestehenden Lavalampen, die wir zuvor bereits ausführlich beschrieben haben.

Zur Erinnerung: In wiederholten Abständen nimmt eine Kamera ein Bild des aktuellen Zustands der zu sehenden Zufälligkeit auf. Da das zugrundeliegende System wirklich zufällig ist, enthält das erzeugte Bild echte Zufälligkeit. Sogar Schatten und wechselnde Lichtverhältnisse spielen eine Rolle, um etwas Einzigartiges und Unvorhersehbares zu schaffen! Es gibt noch ein weiteres Geheimnis, das wir lüften sollten: Im Grunde genommen sind die Bildsensoren in der realen Welt oft eine Quelle ausreichenden Rauschens, sodass sogar Bilder, die ohne abgenommenen Objektivdeckel aufgenommen wurden, als Quelle der Entropie dienen können! Wir betrachten dieses zusätzliche Rauschen als eine zufällige Ergänzung zu der schönen chaotischen Bewegung dieser Installationen.

Nahaufnahme der hängenden Regenbogen-Mobiles im Cloudflare-Büro in Austin.

Sobald wir ein Standbild haben, das den Zustand der zu sehenden Zufälligkeit zu einem bestimmten Zeitpunkt festhält, berechnen wir eine kompakte Darstellung – einen Hash – des Bildes, um ein Output von echten Zufallsbytes in fester Größe zu erhalten.

Prozess der Umwandlung von physikalischen Entropieanzeigen in zufällige Bytefolgen.

Die Zufallsbytes werden dann als Input (zusammen mit dem vorherigen Seed und etwas Zufälligkeit aus den lokalen Entropiequellen des Systems) für eine Key Derivation Function (KDF) verwendet, um einen neuen Zufälligkeitsseed zu berechnen, der in einen kryptografisch sicheren Zufallszahlengenerator (Cryptographically Secure Pseudorandom Number Generator, CSPRNG) eingespeist wird, der auf Anfrage einen im Wesentlichen unendlichen Strom unvorhersehbarer Bytes erzeugen kann. Die Eigenschaften eines CSPRNG gewährleisten, dass alle Outputs für jeden, der seinen internen Zustand nicht kennt, praktisch nicht von echten Zufallsoutputs zu unterscheiden sind. LavaRand stellt diesen Strom der Zufälligkeit dann über eine einfache interne API zur Verfügung, über die der Client neue Zufallsdaten anfordern kann.

seed = KDF(new image || previous seed || system randomness)
rng = CSPRNG(seed)
…
rand1 = rng.random()
rand2 = rng.random()

Anwendungen verwenden in der Regel sichere Zufallszahlen in einer von zwei Varianten: privat und öffentlich.

Private Zufälligkeit wird für die Generierung von Passwörtern, kryptografischen Schlüsseln, Nutzer-IDs und anderen Werten verwendet, die für immer geheim bleiben sollen. Wie wir bereits beschrieben haben, fordern unsere Server in regelmäßigen Abständen neue private Zufälligkeit von LavaRand an, um ihre Entropie-Pools zu aktualisieren. Aus diesem Grund ist die Zufälligkeit von LavaRand im Wesentlichen für die Außenwelt verfügbar! Eine einfache Möglichkeit für Entwickler, den privaten Zufallswert von LavaRand zu nutzen, ist die Verwendung der getRandomValues-Funktion der Web Crypto-API eines Cloudflare Workers, oder eine Funktion zu verwenden, die jemand bereits entwickelt hat, wie etwa csprng.xyz (Quelle).

Öffentliche Zufälligkeit besteht aus unvorhersehbaren und unvoreingenommenen Zufallswerten, die nach ihrer Veröffentlichung für jedermann zugänglich sind, und sollten daher nicht zur Erzeugung kryptografischer Schlüssel verwendet werden. Die Gewinnzahlen der Lotterie und der Münzwurf zu Beginn einer Sportveranstaltung sind einige Beispiele für öffentliche Zufallswerte. Eine Münze mit zwei Köpfen wäre keine unvoreingenommene und unvorhersehbare Quelle der Entropie und hätte drastische Auswirkungen auf die Welt der Sportwetten.

Es ist nicht nur wünschenswert, dass die öffentliche Zufälligkeit unvorhersehbar und unvoreingenommen ist, sondern auch, dass sie vertrauenswürdig ist, damit die Konsumenten der Zufälligkeit sicher sein können, dass die Werte getreu erzeugt wurden. Kaum jemand würde ein Lotterielos kaufen, wenn er glaubt, dass das Gewinnerlos ungerecht gezogen wird! Tatsächlich sind Fälle bekannt, in denen korrupte Insider das öffentliche Zufallsverfahren zu ihrem persönlichen Vorteil untergraben haben, wie der Angestellte der US-Lotterie, der den Zufallsgenerator der Lotterie mitbenutzt hat, sodass seine Freunde und seine Familie Millionen von Dollar gewinnen konnten.

Eine wichtige Voraussetzung für öffentliche Zufälligkeit ist, dass man der Instanz vertrauen muss, die die Zufallszahlen ausgibt. Das Vertrauen in eine bekannte Instanz wie das NIST mag für viele Anwendungen ausreichen, könnte aber für andere problematisch sein (insbesondere für Anwendungen, bei denen Dezentralisierung wichtig ist).

Um dieses Vertrauensproblem zu lösen, schloss sich Cloudflare im Jahr 2019 mit sieben anderen unabhängigen und geografisch verteilten Organisationen zur League of Entropy zusammen, um einen öffentlichen Zufallsgenerator zu starten, der das drand-Protokoll (sprich: dee-rand) verwendet. Jede Organisation steuert ihre eigene, einzigartige Zufallsquelle zum gemeinsamen Entropie-Pool bei, der als Seed für das drand-Netzwerk dient, wobei Cloudflare natürlich die Zufallsdaten von LavaRand verwendet!

Die League of Entropy begann als experimentelles Netzwerk. Unter der Leitung und mit der Unterstützung des drand-Teams bei Protocol Labs hat es sich zu einem zuverlässigen und einsatzbereiten Kernservice des Internets entwickelt, auf den sich Anwendungen von der   verteilten Dateispeicherung über Online Gaming oder bzeitgestempelten Nachweisen („timestamped proofs“) bis hin zu Timelock-Verschlüsselung verlassen (siehe unten). Die League of Entropy ist ebenfalls gewachsen. Inzwischen sind 18 Organisationen auf vier Kontinenten Mitglied im drand-Netzwerk.

Die drand-Zufallsgeneratoren der League of Entropy (von denen jede mit unterschiedlichen Parametern läuft, z. B. wie häufig Zufallswerte erzeugt werden und ob die Zufälligkeit verkettet ist – mehr dazu weiter unten) haben zwei wichtige Eigenschaften, die zu ihrer Vertrauenswürdigkeit beitragen: Sie sind dezentralisiert und verifizierbar. Die Dezentralisierung stellt sicher, dass ein oder zwei schlechte Akteure den Zufallsgenerator („randomness beacon“) nicht unterwandern oder beeinflussen können, und die Überprüfbarkeit ermöglicht es jedem, zu überprüfen, ob die Zufallswerte gemäß dem drand-Protokoll und unter Beteiligung einer bestimmten Anzahl (mindestens der Hälfte, in der Regel aber mehr) der Teilnehmer des drand-Netzwerks generiert werden. Mit jedem neuen Mitglied nehmen also die Vertrauenswürdigkeit und Zuverlässigkeit des drand-Netzwerks weiter zu.

Im Folgenden geben wir einen kurzen Überblick darüber, wie drand diese Eigenschaften mit Hilfe von verteilter Schlüsselgenerierung und Schwellensignaturen (threshold signatures) erreicht. Für einen tieferen Einblick in die Materie lesen Sie bitte unseren früheren Blog-Beitrag und einige der ausgezeichneten Beiträge des drand-Teams.

Während der anfänglichen Einrichtung eines drand-Zufallsgenerators führen die Knoten im Netzwerk ein verteiltes Protokoll zur Schlüsselgenerierung (Distributed Key Generation, DKG) aus, das auf dem Commitment-Verfahren nach Pedersen basiert. Dadurch besitzt jeder Knoten einen „Anteil“ (ein Schlüsselpaar) für einen verteilten Gruppenschlüssel, der für die Lebensdauer des Zufallsgenerators fest bleibt. Um etwas Nützliches mit dem geheimen Gruppenschlüssel zu tun, wie z. B. eine Nachricht zu signieren, muss sich mindestens eine minimale Anzahl (z. B. 7 von 9) der Knoten im Netzwerk an der Erstellung einer BLS-Schwellensignatur beteiligen. Die Gruppeninformationen für den quicknet-Zufallsgenerator im Mainnet der League of Entropy ist unten dargestellt:

(Der Hex-Wert 52db9b... in der obigen URL ist der Hash der Konfiguration des Zufallsgenerators. Besuchen Sie https://drand.cloudflare.com/chains, um alle Zufallsgeneratoren zu sehen, die von unseren Nodes im drand-Mainnet unterstützt werden.)

curl -s https://drand.cloudflare.com/52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971/info | jq
{
  "public_key": "83cf0f2896adee7eb8b5f01fcad3912212c437e0073e911fb90022d3e760183c8c4b450b6a0a6c3ac6a5776a2d1064510d1fec758c921cc22b0e17e63aaf4bcb5ed66304de9cf809bd274ca73bab4af5a6e9c76a4bc09e76eae8991ef5ece45a",
  "period": 3,
  "genesis_time": 1692803367,
  "hash": "52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971",
  "groupHash": "f477d5c89f21a17c863a7f937c6a6d15859414d2be09cd448d4279af331c5d3e",
  "schemeID": "bls-unchained-g1-rfc9380",
  "metadata": {
    "beaconID": "quicknet"
  }
}

Die Knoten im Netzwerk sind so konfiguriert, dass sie in regelmäßigen Abständen (bei quicknet alle 3 Sekunden) zusammenarbeiten, um eine Signatur über eine vereinbarte Nachricht zu erstellen, z. B. die Nummer der aktuellen Runde und die Signatur der vorherigen Runde (mehr dazu unten). Jeder Knoten verwendet seinen Anteil am Gruppenschlüssel, um eine Teilsignatur der aktuellen Nachricht zu erstellen, und sendet diese an andere Knoten im Netzwerk. Sobald ein Knoten über genügend Teilsignaturen verfügt, kann er diese zusammenfassen, um eine Gruppensignatur für die jeweilige Runde zu erstellen.

Die Gruppensignatur für eine Runde ist die Zufälligkeit (in der obigen Ausgabe ist der Zufallswert einfach der sha256-Hash der Signatur, für die Anwendungen, die ein kürzeres Output mit fester Größe bevorzugen). Die Signatur ist im Voraus nicht vorhersehbar, solange genügend (mindestens eine Mehrheit, kann aber auch höher konfiguriert werden) der Knoten im drand-Netzwerk ehrlich sind und keine Absprachen treffen. Außerdem kann jeder die Signatur für eine bestimmte Runde mit dem öffentlichen Gruppenschlüssel des Zufallsgenerators validieren. Es wird empfohlen, dass Entwickler die drand-Client-Bibliotheken oder CLI verwenden, um jeden vom Zufallsgenerator erhaltenen Wert zu überprüfen.

curl -s https://drand.cloudflare.com/52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971/public/13335 | jq
{
  "round": 13335,
  "randomness": "f4eb2e59448d155b1bc34337f2a4160ac5005429644ba61134779a8b8c6087b6",
  "signature": "a38ab268d58c04ce2d22b8317e4b66ecda5fa8841c7215bf7733af8dbaed6c5e7d8d60b77817294a64b891f719bc1b40"
}

Als die League of Entropy 2019 ihre erste Generation von drand-Zufallsgeneratoren auf den Markt brachte, enthielt die Nachricht pro Runde, über die die Gruppensignatur berechnet wurde, die Signatur der vorherigen Runde. So entsteht eine Kette von Zufallsrunden bis hin zur ersten „Genesis-Runde“. Verkettete Zufälligkeit bietet einige nette Eigenschaften für Zufallsgeneratoren mit einer einzigen Quelle und ist als Anforderung in der NIST-Spezifikation für interoperable öffentliche Zufallsgeneratoren enthalten.

2022 führte das drand-Team jedoch den Begriff der Unchained Randomness („unverkettete Zufälligkeit“), bei der die zu signierende Nachricht vorhersehbar ist und nicht von der Zufälligkeit früherer Runden abhängt, und zeigte, dass sie für das drand-Netzwerk die gleichen Sicherheitsgarantien bietet wie Chained Randomness („verkettete Zufälligkeit“; beide erfordern eine Mindestanzahl an ehrlichen Knoten). Bei der Implementierung von unverketteter Zufälligkeit im quicknet besteht die zu signierende Nachricht einfach aus der Nummer der aktuellen Runde.

Unverkettete Zufälligkeit bietet einige leistungsstarke Eigenschaften und Verbesserungen der Benutzerfreundlichkeit. Was die Benutzerfreundlichkeit betrifft, so muss ein Verbraucher des Zufallsgenerators nicht die gesamte Kette des Zufalls bis zur Genesis-Runde rekonstruieren, um eine bestimmte Runde vollständig zu validieren – die einzige Information, die benötigt wird, ist die Nummer der aktuellen Runde und der öffentliche Gruppenschlüssel. Dies bietet dem Kunden viel mehr Flexibilität, da er wählen kann, wie oft er Zufallsrunden konsumiert, ohne die Kette der Zufälligkeit ständig verfolgen zu müssen.

# chained randomness
signature = group_sign(round || previous_signature)

# unchained randomness
signature = group_sign(round)

Da die zu signierenden Nachrichten im Voraus bekannt sind (da es sich nur um die Zahl der Runde handelt), ermöglicht die unverkettete Zufälligkeit auch eine leistungsstarke neue Eigenschaft: die Timelock-Verschlüsselung.

Rotierende Doppelpendel.

Die Timelock-Verschlüsselung (oder „Timed-Release“-Verschlüsselung) ist eine Methode, um eine Nachricht so zu verschlüsseln, dass sie erst nach einer bestimmten Zeit entschlüsselt werden kann. Zwei grundlegende Ansätze zur Timelock-Verschlüsselung wurden von Rivest, Shamir und Wagner beschrieben:

- Die Verwendung von „Timelock-Rätseln“ – Rechenaufgaben, die nicht gelöst werden können, ohne dass der Computer mindestens eine bestimmte Zeit lang ununterbrochen läuft.

- Der Einsatz von vertrauenswürdigen Personen, die versprechen, bestimmte Informationen bis zu einem bestimmten Zeitpunkt nicht preiszugeben.

Der Einsatz von vertrauenswürdigen Personen birgt natürlich das Problem, dass sichergestellt werden muss, dass die Vertrauenspersonen auch wirklich vertrauenswürdig sind. Mit Konzepten zur gemeinsamen Nutzung von Geheimnissen können diese Bedenken ausgeräumt werden.

Das drand-Netzwerk ist eine Gruppe unabhängiger Personen, die für ihre Vertrauenswürdigkeit die gemeinsame Nutzung von Geheimnissen nutzen, und die „bestimmte Informationen“, die bis zu einem bestimmten Datum nicht preisgegeben werden dürfen, klingt sehr nach der Zufälligkeit pro Runde! Als Nächstes beschreiben wir, wie die Timelock-Verschlüsselung auf einem drand-Netzwerk mit unverketteter Zufälligkeit implementiert werden kann, und schließen mit einer praktischen Demonstration. Wir gehen zwar nicht näher auf die bilinearen Gruppen und Pairing-basierte Kryptographie ein, die dies möglich machen, doch wenn Sie sich für diese Themen interessieren, empfehlen wir Ihnen, den Beitrag „tlock: Practical Timelock Encryption from Threshold BLS von Nicolas Gailly, Kelsey Melissaris und Yolan Romailler zu lesen.

Identifizieren Sie zunächst die Zufallsrunde, deren Aufdeckung die Entschlüsselung Ihrer per Timelock verschlüsselten Nachricht ermöglichen würde. drand-Netzwerke erzeugen in festen Intervallen Zufälligkeit, sodass jede Runde in einem drand-Zufallsgenerator eng mit einem bestimmten Zeitstempel verbunden ist (vorbehaltlich kleiner Verzögerungen für das Netzwerk, um den Zufallsgenerator tatsächlich zu erzeugen), der leicht berechnet werden kann, indem man den Genesis-Zeitstempel des Zufallsgenerators nimmt und dann die Nummer der Runde multipliziert mit dem Zeitraum des Zufallsgenerators addiert.

Sobald die Runde festgelegt ist, können Sie dank der Eigenschaften bilinearer Gruppen Ihre Nachricht für eine bestimmte Runde mit dem öffentlichen Gruppenschlüssel des drand-Zufallsgenerators verschlüsseln.

Nachdem die Knoten im drand-Netzwerk zusammenarbeiten, um die Zufälligkeit für die Runde abzuleiten (eigentlich nur die Signatur der Nummer der aktuellen runde unter Verwendung des geheimen Gruppenschlüssels des Zufallsgenerators), kann jeder den Chiffriertext entschlüsseln (hier kommt die Magie der bilinearen Gruppen ins Spiel).

Praktisch bedeutet dies, dass die per Timelock verschlüsselte Nachricht eigentlich der geheime Schlüssel für ein symmetrisches System ist. Das heißt, wir verschlüsseln die Nachricht mit einem symmetrischen Schlüssel und verschlüsseln den Schlüssel mit einem Timelock bzw. einer „Zeitsperre“, die eine Entschlüsselung in der Zukunft ermöglicht.

ciphertext = EncryptToRound(msg, round, beacon_public_key)

Für eine praktische Demonstration der Timelock-Verschlüsselung verwenden wir ein Tool, das einer unserer eigenen Techniker auf der Grundlage von Cloudflare Workers entwickelt hat. Der Quellcode ist öffentlich zugänglich, wenn Sie sich genau ansehen möchten, wie es funktioniert.

random = Randomness(round)
message = Decrypt(ciphertext,random)

Wir hoffen, dass Sie den Rückblick auf die Geschichte von LavaRand genauso spannend fanden wie wir. Vielleicht konnten wir Sie ja sogar dazu inspirieren, in der nahen Zukunft eine unserer Cloudflare-Niederlassungen zu besuchen, um die auf Zufälligkeit ausgerichteten Installationen persönlich zu sehen und die überprüfbare öffentliche Zufälligkeit und die Timelock-Verschlüsselung von drand in Ihrem nächsten Projekt zu verwenden.

# 1. Create a file
echo "A message from the past to the future..." > original.txt

# 2. Get the drand round 1 minute into the future (20 rounds) 
BEACON="52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971"
ROUND=$(curl "https://drand.cloudflare.com/$BEACON/public/latest" | jq ".round+20")

# 3. Encrypt and require that round number
curl -X POST --data-binary @original.txt --output encrypted.pem https://tlock-worker.crypto-team.workers.dev/encrypt/$ROUND

# 4. Try to decrypt it (and only succeed 20 rounds x 3s later)
curl -X POST --data-binary @encrypted.pem --fail --show-error https://tlock-worker.crypto-team.workers.dev/decrypt

Die für die Sicherung des Internets verwendete Verschlüsselung benötigt ein Element des Chaos. LavaRand bei Cloudflare wird auch weiterhin die chaotische Schönheit unserer physischen Welt in einen Strom der Zufälligkeit verwandeln – auch wenn neue Quellen hinzukommen – für neuartige Verwendungszwecke, die wir Entdecker – genau wie diese Schnecke – uns noch ausdenken müssen.

Und sie betrachtete den Himmel, das Meer, das Land, die Wellen und die Höhlen und den goldenen Sand, und sie schaute und schaute und staunte über all das, und sie sagte zum Buckelwal: „Ich fühle mich so klein.“

Eine Schnecke auf einem Buckelwal.

Verpassen Sie keine weiteren Neuigkeiten, Ankündigungen und anregende Diskussionen! Werfen Sie einen Blick auf die Security Week Hub-Seite.