Eine Einführung in die registrierungsbasierte Verschlüsselung

Die Verknüpfung kryptographischer Schlüssel mit Identitäten ist seit langem ein Problem.die Einführung der Technologie. Die Herausforderung besteht darin, eine öffentlich verfügbare und konsistente Zuordnung zwischen Identitäten und öffentlichen Schlüsseln (zu denen diese Identitäten den privaten Schlüssel haben) bereitzustellen und aufrechtzuerhalten. Ohne eine solche Zuordnung können Nachrichten, die geheim bleiben sollen, fehlschlagen - manchmal mit katastrophalen Folgen. Diese Herausforderung besteht auch in Web3.

Derzeit gibt es drei mögliche Lösungen. Die beiden klassischen Ansätze sind ein Public-Key-Verzeichnis und eine identitätsbasierte Verschlüsselung. Die dritte ist die registrierungsbasierte Verschlüsselung, die bis vor kurzem rein theoretisch war. Die drei Ansätze bieten unterschiedliche Kompromisse zwischen Anonymität, Interaktivität und Effizienz, was auf den ersten Blick klar erscheinen mag, aber die Blockchain-Umgebung führt neue Möglichkeiten und Einschränkungen ein. Das Ziel dieses Beitrags ist es daher, diesen Designraum zu erkunden und diese Ansätze zu vergleichen, wenn sie auf einer Blockchain eingesetzt werden. Wenn Nutzer Transparenz und Anonymität auf der Blockchain benötigen, ist ein praktisches RBE-System der klare Gewinner – es überwindet die starke Vertrauensannahme der identitätsbasierten Verschlüsselung, aber zu einem Preis.

Die drei Ansätze in Kürze

Der klassische Ansatz zum Verknüpfen kryptografischer Schlüssel mit Identitäten ist eine Public-Key-Infrastruktur (PKI) mit einem Public-Key-Verzeichnis als Herzstück. Dieser Ansatz erfordert, dass ein potenzieller Absender mit einem vertrauenswürdigen Dritten (dem Verwalter des Verzeichnisses oder der Zertifizierungsstelle) interagiert, um Nachrichten zu senden. Darüber hinaus kann die Verwaltung dieses Verzeichnisses in der Web2-Umgebung kostspielig und mühsam sein und fehleranfällig, und Benutzer laufen Gefahr, Missbrauch durch die Zertifizierungsstelle.

Kryptographen haben Alternativen vorgeschlagen, um die Probleme mit PKIs zu umgehen. Im Jahr 1984 Adi Shamir schlug vorIdentitätsbasierte Verschlüsselung (IBE), bei der die Kennung einer Partei - Telefonnummer, E-Mail, ENS-Domainname - als öffentlicher Schlüssel dient. Dadurch entfällt die Notwendigkeit, ein öffentliches Schlüsselverzeichnis zu pflegen, jedoch wird dafür eine vertrauenswürdige dritte Partei (der Schlüsselgenerator) benötigt. Dan Boneh und Matthew Franklin haben dies eingeführt.erste praktische IBE-Konstruktion im Jahr 2001 eingeführt, aber IBE hat außerhalb von geschlossenen Ökosystemen wie Unternehmen keine weite Verbreitung gefunden.Regierungseinsätze, vielleicht aufgrund der starken Vertrauensannahme. (Wie wir unten sehen werden, kann diese Annahme teilweise durch die Abhängigkeit von einem vertrauenswürdigen Gremium von Parteien gemildert werden, was eine Blockchain leicht ermöglichen kann.)

Eine dritte Option, die auf Registrierung basierende Verschlüsselung (RBE), warvorgeschlagenim Jahr 2018. RBE behält die gleiche allgemeine Architektur wie IBE bei, ersetzt jedoch den vertrauenswürdigen Schlüsselgenerator durch einen transparenten „Schlüssel-Kurator“, der nur Berechnungen auf öffentlichen Daten durchführt (genauer gesagt akkumuliert er öffentliche Schlüssel zu einer Art öffentlich verfügbarem „Digest“). Die Transparenz dieses Schlüssel-Kurators macht die Blockchain-Umgebung - in der ein Smart Contract die Rolle des Kurators übernehmen kann - zu einer natürlichen Ergänzung für RBE. RBE war theoretisch bis 2022, als meine Mitautoren und ich es einführten.erste praktisch effiziente RBE-Konstruktion.

Die Abwägung bewerten

Dieser Designraum ist komplex, und der Vergleich dieser Schemata erfordert die Berücksichtigung vieler Dimensionen. Um die Dinge einfacher zu halten, werde ich zwei Annahmen machen:

1. Benutzer aktualisieren oder widerrufen ihre Schlüssel nicht.
2. Der Smart Contract verwendet keinen Off-Chain Datenverfügbarkeitsservice (DAS) oder Blob-Daten.

Am Ende werde ich besprechen, wie sich jede dieser zusätzlichen Überlegungen auf unsere drei potenziellen Lösungen auswirken könnte.

Öffentlicher Schlüsselverzeichnis

Zusammenfassung: Jeder kann einen (id, pk)-Eintrag in einer On-Chain-Tabelle (dem Verzeichnis) hinzufügen, indem er den Smart Contract aufruft, vorausgesetzt, die ID wurde noch nicht beansprucht.

Eine dezentrale PKI ist im Wesentlichen ein Smart Contract, der ein Verzeichnis von Identitäten und den entsprechenden öffentlichen Schlüsseln verwaltet. Zum Beispiel ist die Ethereum Name Service (ENS) Registerpflegt eine Zuordnung von Domänennamen ("Identitäten") und ihren entsprechenden Metadaten, einschließlich der Adressen, auf die sie sich auflösen (aus deren Transaktionen ein öffentlicher Schlüssel abgeleitet werden kann). Eine dezentralisierte PKI würde sogar eine einfachere Funktionalität bieten: Die von dem Vertrag gepflegte Liste würde nur den öffentlichen Schlüssel zu jeder ID speichern.

Um sich zu registrieren, generiert ein Benutzer ein Schlüsselpaar (oder verwendet ein zuvor generiertes Schlüsselpaar) und sendet seine ID und seinen öffentlichen Schlüssel an den Vertrag (möglicherweise zusammen mit einer Zahlung). Der Vertrag überprüft, ob die ID noch nicht beansprucht wurde, und fügt dem Verzeichnis die ID und den öffentlichen Schlüssel hinzu, wenn dies nicht der Fall ist. Zu diesem Zeitpunkt kann jeder eine Nachricht an einen registrierten Benutzer verschlüsseln, indem er den Vertrag nach dem öffentlichen Schlüssel fragt, der einer ID entspricht. (Wenn der Absender diesem Benutzer zuvor etwas verschlüsselt hat, muss er den Vertrag nicht erneut abfragen.) Mit dem öffentlichen Schlüssel kann der Absender seine Nachricht wie gewohnt verschlüsseln und den Chiffretext an den Empfänger senden, der mit dem entsprechenden geheimen Schlüssel die Nachricht wiederherstellen kann.

Lassen Sie uns einen Blick auf die Eigenschaften dieser Methode werfen.

Auf der negativen Seite des Ledgers:

• Nicht prägnant. Das vollständige Schlüsselverzeichnis muss auf der Kette gespeichert werden, damit es immer für alle verfügbar ist (denken Sie daran, dass wir vorerst keine DAS annehmen). Für die ~900K eindeutige Domainnamen, die zum Zeitpunkt der Erstellung dieses Artikels in der ENS registriert sindbedeutet dies fast 90 MB persistenten Speicher. Registrierende Parteien müssen für den Speicher bezahlen, den ihr Eintritt in Anspruch nimmt, etwa 65.000 Gas (derzeit etwa 1 US-Dollar – siehe Leistungsbewertung unten).
• Etwas interaktive Verschlüsselung. Der Absender muss die Kette lesen, um den öffentlichen Schlüssel eines Benutzers abzurufen, aber nur, wenn es das erste Mal ist, dass der Absender eine Nachricht an diesen bestimmten Benutzer verschlüsselt. (Denken Sie daran, dass wir davon ausgehen, dass Benutzer ihre Schlüssel nicht aktualisieren oder widerrufen.)
• Nicht Absender-anonym. Wenn Sie den öffentlichen Schlüssel einer Person abrufen, verknüpfen Sie sich mit dem Empfänger und zeigen an, dass Sie eine Beziehung zu ihm haben. Stellen Sie sich zum Beispiel vor, Sie erhalten den öffentlichen Schlüssel für WikiLeaks: Das könnte den Verdacht erwecken, dass Sie geheime Dokumente preisgeben. Dieses Problem könnte durch "Cover Traffic" (Abrufen eines großen Stapels von Schlüsseln, von denen Sie die meisten nicht verwenden möchten) oder ähnliches durch Ausführen eines vollständigen Knotens oder mit Private Information Retrieval (PIR) gemildert werden.

Auf der positiven Seite:

• Nicht-interaktive Entschlüsselung. Benutzer entschlüsseln Nachrichten mit ihrem lokal gespeicherten geheimen Schlüssel, daher erfordert es keine Interaktion.
• Transparent. Die Liste der Benutzer und Schlüssel ist vollständig öffentlich, so dass jeder überprüfen kann, ob sie korrekt registriert wurden oder nicht.
• Beliebige ID festgelegt. Der Bereich der IDs ist nicht a priori durch die Konstruktion begrenzt; Theoretisch kann die ID ein beliebige Zeichenfolge(unter Berücksichtigung der Einschränkungen, die durch die spezifische Implementierung und Speicherung des Vertrags auferlegt werden).

Wann möchten Sie ein öffentliches Schlüsselverzeichnis verwenden? Ein dezentrales öffentliches Schlüsselverzeichnis ist einfach einzurichten und zu verwalten, daher ist es eine gute Basiskonfiguration. Wenn jedoch Speicherkosten oder Datenschutz ein Anliegen sind, könnte eine der unten aufgeführten Optionen eine bessere Wahl sein.

(Threshold) Identitätsbasierte Verschlüsselung (IBE)

Zusammenfassung: Die Identität eines Benutzers ist ihr öffentlicher Schlüssel. Eine vertrauenswürdige dritte Partei oder Parteien ist erforderlich, um Schlüssel auszustellen und ein Hauptschlüsselgeheimnis (Falltür) während der Lebensdauer des Systems aufzubewahren.

In IBE generiert ein Benutzer kein eigenes Schlüsselpaar, sondern registriert sich stattdessen bei einem vertrauenswürdigen Schlüsselgenerator. Der Schlüsselgenerator hat ein "Master"-Schlüsselpaar (in der Abbildung msk, mpk). Anhand der ID eines Benutzers verwendet der Schlüsselgenerator den geheimen Hauptschlüssel msk und die ID, um einen geheimen Schlüssel für den Benutzer zu berechnen. Dieser geheime Schlüssel muss dem Benutzer über einen sicheren Kanal mitgeteilt werden (der mit einem Schlüsselaustauschprotokoll).

IBE optimiert die Erfahrung des Absenders: Es lädt den öffentlichen Schlüsselgenerator mpk einmal herunter und kann anschließend eine Nachricht an eine beliebige ID verschlüsseln, indem es die ID selbst verwendet. Auch die Entschlüsselung ist einfach: Ein registrierter Benutzer kann den ihm vom Schlüsselgenerator ausgegebenen geheimen Schlüssel verwenden, um den Geheimtext zu entschlüsseln.

Der Hauptschlüssel des Schlüsselgenerators ist beharrlicher als die "giftige Abfälle", die bei den Vertrauensstellungzeremonien erzeugt werdenWird für einige SNARKs verwendet. Der Schlüsselgenerator benötigt es, um neue geheime Schlüssel auszugeben, daher kann der Schlüsselgenerator es nach der Einrichtung nicht löschen, wie es die Teilnehmer an SNARK-Zeremonien tun. Es handelt sich auch um eine gefährliche Information. Jeder mit dem msk kann alle Nachrichten entschlüsseln, die an jeden Benutzer im System gesendet werden. Dies bedeutet, dass es ständig ein Risiko der Exfiltration mit katastrophalen Folgen gibt.

Auch wenn die msk sicher aufbewahrt wird, muss jeder Benutzer, der sich im System registriert, dem Schlüsselgenerator vertrauen, um seine Nachrichten nicht zu lesen, da der Schlüsselgenerator jederzeit eine Kopie des geheimen Schlüssels des Benutzers behalten oder diesen aus msk neu berechnen kann. Es könnte sogar möglich sein, dass der Schlüsselgenerator dem Benutzer einen fehlerhaften oder "eingeschränkten" geheimen Schlüssel ausstellt, der alle Nachrichten entschlüsselt, außer einigen verbotenen, wie vom Schlüsselgenerator bestimmt.

Dieses Vertrauen kann stattdessen auf eine Gruppe von Schlüsselgeneratoren verteilt werden, so dass ein Benutzer nur einer bestimmten Anzahl von ihnen vertrauen muss. In diesem Fall können eine kleine Anzahl von böswilligen Schlüsselgeneratoren keine geheimen Schlüssel wiederherstellen oder schlechte Schlüssel berechnen, und ein Angreifer müsste in mehrere Systeme eindringen, um das vollständige Mastergeheimnis zu stehlen.

Wenn Benutzer mit dieser Vertrauensannahme einverstanden sind, bietet (Schwellenwert) IBE viele Vorteile:

• Konstante/minimale Speicherung auf der Chain. Nur der Master-Public-Key (ein einzelnes Gruppenelement) muss auf der Chain gespeichert werden. Dies ist viel weniger als der Speicherplatz, der für ein öffentliches Schlüsselverzeichnis auf der Chain benötigt wird. Für die Boneh-Franklin IBE über die BN254-Kurve bedeutet dies, dass während der Einrichtungsphase nur 64 Byte an persistenter On-Chain-Speicherung hinzugefügt werden müssen und der Service nur 40K Gas ausgeben muss.
• Nicht-interaktive Verschlüsselung. Ein Sender benötigt nur den Master-Public-Key (den er einmal zu Beginn herunterlädt) und die Empfänger-ID, um eine Nachricht zu verschlüsseln. Dies steht im Gegensatz zum Public-Key-Verzeichnis, wo er für jeden neuen Benutzer, mit dem er kommunizieren möchte, einen Schlüssel abrufen müsste.
• Nicht-interaktive Entschlüsselung. Benutzer verwenden erneut ihre lokal gespeicherten geheimen Schlüssel, um Nachrichten zu entschlüsseln.
• Sender-anonym. Der Sender muss keine Informationen pro Empfänger aus der Kette abrufen. Im Vergleich dazu muss der Sender im Falle eines öffentlichen Schlüsselregisters auf eine Weise mit dem Vertrag interagieren, die vom Empfänger abhängt.
• Beliebiger ID-Satz. Wie im öffentlichen Schlüsselregister können die IDs beliebige Zeichenketten sein.

Aber!

• Starke Vertrauensannahme. Im Gegensatz zum Public-Key-Register, bei dem Benutzer ihre eigenen Schlüssel generieren, erfordert IBE eine vertrauenswürdige Partei oder ein Quorum von Parteien mit einem Hauptschlüssel (Hintertür), um Schlüssel auszustellen. Der Hauptschlüssel muss während der gesamten Lebensdauer des Systems aufbewahrt werden und kann alle Nachrichten der registrierten Benutzer gefährden, wenn er jemals durchgesickert oder missbraucht wird.

Wann möchten Sie (Threshold) IBE verwenden? Wenn eine vertrauenswürdige dritte Partei oder Parteien verfügbar ist und Benutzer bereit sind, ihnen zu vertrauen, bietet IBE eine viel platzsparendere (und daher kostengünstigere) Option im Vergleich zu einem On-Chain-Schlüsselregister.

Registrierungsbasierte Verschlüsselung (RBE)

Zusammenfassung: Ähnlich wie bei IBE dient die Identität eines Benutzers als öffentlicher Schlüssel, aber der vertrauenswürdige Dritte/das Quorum wird durch einen transparenten Akkumulator (genannt "Schlüsselkurator") ersetzt.

In diesem Abschnitt werde ich den effizienten RBE-Aufbau von Gate diskutieren.mein Papier, da im Gegensatz zu meinem Wissen die (meines Wissens nach) nur andere praktische Konstruktion, es ist derzeit auf einer Blockchain einsetzbar (basierend auf Paarung anstelle von Gittern). Wenn ich 'RBE' sage, meine ich diese spezielle Konstruktion, obwohl einige Aussagen auf RBE im Allgemeinen zutreffen könnten.

In RBE generiert ein Benutzer sein eigenes Schlüsselpaar und berechnet einige "Update-Werte" (a in der Abbildung), die aus dem geheimen Schlüssel und dem gemeinsamen Referenzstring (CRS) abgeleitet werden. Obwohl das Vorhandensein eines CRS bedeutet, dass das Setup nicht vollständig vertrauenswürdig ist, ist das CRS einPotenzen von TauKonstruktion, die sein kanngemeinsam auf der Blockchain berechnet und ist sicher, solange es einen einzigen ehrlichen Beitrag gab.

Der Smart Contract wird für eine erwartete Anzahl von Benutzern N eingerichtet, die in Buckets gruppiert sind. Wenn sich ein Benutzer im System registriert, sendet er seine ID, seinen öffentlichen Schlüssel und seine Aktualisierungswerte an den Smart Contract. Der Smart Contract unterhält eine Reihe von öffentlichen Parametern pp (im Unterschied zum CRS), die man sich als eine prägnante "Zusammenfassung" der öffentlichen Schlüssel aller im System registrierten Parteien vorstellen kann. Wenn er eine Registrierungsanforderung erhält, führt er eine Überprüfung der Aktualisierungswerte durch und multipliziert den öffentlichen Schlüssel in den entsprechenden Bucket von pp.

Registrierte Benutzer müssen auch einige "Hilfsinformationen" lokal speichern, die sie zur Entschlüsselung benötigen und die jedes Mal angehängt werden, wenn sich ein neuer Benutzer im selben Bucket registriert. Sie können diese Informationen selbst aktualisieren, indem sie die Blockchain auf Registrierungen in ihrem Bucket überwachen oder der Smart Contract kann helfen, indem er eine Liste der Update-Werte führt, die er von den jüngsten Registrierungen erhalten hat (sagen wir, innerhalb der letzten Woche), die die Benutzer regelmäßig abrufen können (mindestens einmal pro Woche).

Absender in diesem System laden das CRS einmal herunter und gelegentlich die neueste Version der öffentlichen Parameter. Bei den öffentlichen Parametern kommt es aus Sicht des Absenders nur darauf an, dass sie den öffentlichen Schlüssel des beabsichtigten Empfängers enthalten. Es muss nicht die aktuellste Version sein. Der Absender kann dann die CRS- und die öffentlichen Parameter zusammen mit der Empfänger-ID verwenden, um eine Nachricht an den Empfänger zu verschlüsseln.

Nach Erhalt einer Nachricht überprüft der Benutzer seine lokal gespeicherten Hilfsinformationen auf einen Wert, der eine Prüfung besteht. (Wenn er keinen findet, bedeutet dies, dass er ein Update vom Vertrag abrufen muss.) Mit diesem Wert und seinem geheimen Schlüssel kann der Benutzer den Chiffretext entschlüsseln.

Offensichtlich ist dieses Schema komplexer als die anderen beiden. Es erfordert jedoch weniger On-Chain-Speicher als das Public-Key-Verzeichnis und vermeidet gleichzeitig die starke Vertrauensannahme des IBE.

• Knappe Parameter. Die Größe der Parameter, die on-chain gespeichert werden sollen, ist sublinear in der Anzahl der Benutzer. Das ist viel kleiner als der gesamte Speicherplatz, der für ein Public-Key-Verzeichnis benötigt wird (linear in der Anzahl der Benutzer), aber immer noch nicht konstant und daher im Vergleich zu IBE schlechter.
• Einigermaßen interaktive Verschlüsselung. Um eine Nachricht zu senden, benötigt ein Sender eine Kopie der öffentlichen Parameter, die den beabsichtigten Empfänger enthält. Dies bedeutet, dass er die Parameter aktualisieren muss, und dies nicht unbedingt für jeden beabsichtigten Empfänger, der sich registriert, da ein Update mehrere Empfängerschlüssel enthalten kann. Insgesamt ist das Nachrichten senden interaktiver als bei IBE, aber weniger interaktiv als bei einem Verzeichnis.
• Etwas interaktive Entschlüsselung. Ähnlich wie beim Verschlüsselungsfall benötigt der Empfänger eine Kopie der Hilfsinformationen, die der Version der öffentlichen Parameter entspricht, die für die Verschlüsselung verwendet wurden. Genauer gesagt werden sowohl der öffentliche Parameter als auch die Hilfseimer aktualisiert, wenn sich ein neuer Benutzer in diesem Eimer registriert, und der Wert, der in der Lage ist, einen Chiffretext zu entschlüsseln, ist derjenige, der der PP-Version entspricht, die zur Verschlüsselung verwendet wurde. Wie bei den Aktualisierungen der öffentlichen Parameter kann ein Benutzer entscheiden, die Aktualisierungen der Hilfsdaten nur periodisch abzurufen, außer wenn die Entschlüsselung fehlschlägt. Im Gegensatz zu den Aktualisierungen der öffentlichen Parameter führt das häufigere Abrufen von Hilfsaktualisierungen nicht zwangsläufig zu einem Informationsverlust.
• Sender-anonym. Wie im Verzeichnisfall kann der Sender eine Nachricht vollständig eigenständig verschlüsseln (sofern er aktuelle Parameter hat), ohne nach empfängerspezifischen Informationen zu fragen. Die Informationen, die bei Bedarf aus der Kette gelesen werden, sind unabhängig vom beabsichtigten Empfänger. (Um die Kommunikation zu reduzieren, könnte der Sender nur einen bestimmten pp-Bucket anfordern und so teilweise Informationen preisgeben.)
• Durchsichtig. Obwohl das System mit einer (potenziell verteilten und/oder extern verwalteten) vertrauenswürdigen Einrichtungszeremonie eingerichtet werden muss, die ein durchlöchertes CRS ausgibt, ist es nach Abschluss der Einrichtung nicht auf eine vertrauenswürdige Partei oder ein Quorum angewiesen: Obwohl es sich auf einen koordinierenden Dritten (den Vertrag) stützt, ist es völlig transparent und jeder kann ein Koordinator sein oder überprüfen, ob er sich ehrlich verhält, indem er seine Zustandsübergänge bestätigt (deshalb kann es als Smart Contract implementiert ist). Darüber hinaus können Benutzer einen knappen (Nicht-)Mitgliedschaftsnachweis verlangen, um zu überprüfen, ob sie (oder jemand anderes) im System registriert/nicht registriert sind. Dies steht im Gegensatz zum IBE-Fall, bei dem es für die vertrauenswürdige(n) Partei(en) schwierig ist, tatsächlich zu beweisen, dass sie einen Entschlüsselungsschlüssel nicht heimlich preisgegeben haben (für sich selbst oder für jemand anderen). Das Public-Key-Verzeichnis hingegen ist vollständig transparent.
• Eingeschränkter ID-Satz. Ich habe eine "grundlegende" Version des RBE-Aufbaus beschrieben. Um transparent zu bestimmen, in welchen Eimer eine ID fällt, müssen die IDs eine öffentliche und deterministische Ordnung haben. Telefonnummern können einfach in Ordnung gebracht werden, aber die Ordnung beliebiger Zeichenketten ist unhandlich, wenn nicht unmöglich, da die Anzahl der Eimer extrem groß oder unbegrenzt sein könnte. Dies könnte durch Angebot eines separaten Vertrags, der eine solche Zuordnung berechnet, oder durch Annahme des vorgeschlagenen Cuckoo-Hashing-Ansatzes gemildert werden. Diese Folgearbeiten.

Mit Erweiterungen:

• Empfänger-anonym. Das Schema kann erweitert werden, damit die Chiffren nicht die Identität des Empfängers offenbaren.

Wann sollten Sie RBE verwenden? RBE verwendet weniger On-Chain-Speicher als eine On-Chain-Registry und vermeidet gleichzeitig die von IBE geforderten starken Vertrauensannahmen. Im Vergleich zu einer Registry bietet RBE dem Absender auch stärkere Datenschutzgarantien. Da RBE jedoch gerade erst zu einer praktikablen Option für die Schlüsselverwaltung geworden ist, sind wir uns noch nicht sicher, welche Szenarien am meisten von dieser Kombination von Eigenschaften profitieren würden. Bitte lass es mich wissen wenn Sie Ideen haben.

Leistungsvergleich

Ich habe die Kosten (Stand: 30. Juli 2024) für die Bereitstellung jedes dieser drei Ansätze auf der Blockchain in dieses Colab-Notizbuch. Die Ergebnisse für eine Systemkapazität von ~900K Benutzern (die Anzahl der zu diesem Zeitpunkt registrierte einzigartige Domänennamen im ENS) werden in der unten stehenden Tabelle angezeigt.

PKI hat keine Einrichtungskosten und niedrige Registrierungskosten pro Benutzer, während IBE geringe Einrichtungskosten und praktisch kostenlose Registrierung pro Benutzer hat. RBE hat höhere Einrichtungskosten und auch unerwartet hohe Registrierungskosten, trotz des geringen erforderlichen On-Chain-Speichers.

Der Großteil der Registrierungskosten (unter der Annahme, dass die Berechnung auf einem L2 durchgeführt wird) kommt von der Tatsache, dass Parteien ein Stück der öffentlichen Parameter dauerhaft speichern müssen, was zu hohen Registrierungskosten führt.

Obwohl RBE teurer ist als die Alternativen, zeigt diese Analyse, dass es heute im Ethereum-Mainnet eingesetzt werden kann – ohne die potenziell riskanten Vertrauensannahmen von PKI oder IBE. Und das vor Optimierungen wie der Bereitstellung mehrerer, kleinerer (und damit kostengünstigerer) Instanzen oder der Verwendung von Blobdaten. Angesichts der Tatsache, dass RBE Vorteile gegenüber dem Public-Key-Verzeichnis und IBE in Form von stärkerer Anonymität und geringeren Vertrauensannahmen hat, könnte es für diejenigen attraktiv sein, die Wert auf Privatsphäre und vertrauenslose Setups legen.

Noemi Glaeser ist Doktorand in Informatik an der University of Maryland und am Max-Planck-Institut für Sicherheit und Privatsphäre und war im Sommer '23 Forschungspraktikant bei a16z crypto. Sie ist Empfängerin des NSF Graduate Research Fellowship und war zuvor Forschungspraktikantin bei NTT Research.

Anhang: Weitere Überlegungen

Umgang mit Schlüsselaktualisierungen/Entziehungen

Im Falle eines öffentlichen Schlüsselverzeichnisses ist die Bearbeitung von Schlüsselaktualisierungen und -widerrufen einfach: Um einen Schlüssel zu widerrufen, bittet eine Partei den Vertrag, ihn aus dem Verzeichnis zu löschen. Um einen Schlüssel zu aktualisieren, wird der Eintrag (id, pk) mit einem neuen Schlüssel zu (id, pk') überschrieben.

Für den Widerruf in IBE schlugen Boneh und Franklin vor, dass Benutzer ihre Schlüssel regelmäßig aktualisieren (z. B. jede Woche) und dass Absender bei der Verschlüsselung den aktuellen Zeitraum in die Identitätszeichenfolge aufnehmen (z. B. "Bob "). Aufgrund der nicht-interaktiven Natur der Verschlüsselung haben Absender keine Möglichkeit zu wissen, wann ein Benutzer seinen Schlüssel widerruft, sodass einige periodische Aktualisierungen inhärent sind. Boldyreva, Goyal und Kumar hielten eine effizienterer Widerrufsmechanismusbasiert auf"Fuzzy" IBEDie Entschlüsselung erfordert zwei Schlüssel: einen „Identitäts“-Schlüssel und einen zusätzlichen „Zeit“-Schlüssel. Auf diese Weise muss nur der Zeit-Schlüssel regelmäßig aktualisiert werden. Die Zeit-Schlüssel der Benutzer werden in einem binären Baum angesammelt, und ein Benutzer kann jeden Knoten entlang des Pfads verwenden (im Grundfall ist nur die Wurzel erforderlich und sie ist der einzige Teil, der vom Schlüsselgenerator veröffentlicht wird). Der Schlüsselentzug wird erreicht, indem keine Aktualisierungen mehr für einen bestimmten Benutzer veröffentlicht werden (Löschen von Knoten entlang des Pfads dieses Benutzers im Baum), in diesem Fall erhöht sich zwar die Größe des Updates, ist aber niemals größer als der Logarithmus der Anzahl der Benutzer.

Unsere effiziente RBE-Konstruktion berücksichtigte keine Updates und Widerrufe, eine Nachbereitung gibt einen Compiler an, der unser Schema "upgraden" kann, um diese Funktionalitäten hinzuzufügen.

Verschieben von Daten außerhalb der Kette mit DAS

Die Verwendung einer Datenverfügbarkeitslösung (DAS), um die Speicherung der On-Chain auf Off-Chain zu verlagern, würde nur den Kalkül für das Public-Key-Verzeichnis und RBE beeinflussen und beide auf die gleiche Menge an On-Chain-Speicher reduzieren. RBE würde den Vorteil beibehalten, für den Sender privater zu sein, da es immer noch das Auslaufen der Empfängeridentität über Zugriffsmuster vermeidet. IBE hatte bereits minimalen On-Chain-Speicher und würde von DAS nicht profitieren.

Haftungsausschluss：

1. Dieser Artikel ist abgedruckt von [a16zcrypto], Alle Urheberrechte gehören dem Originalautor [ Noemi Glaeser ]. Falls es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an den Tor lernenTeam, und sie werden es schnell erledigen.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verteilen oder Plagiieren der übersetzten Artikel untersagt.