Wenn sich Bitcoiner an Nostr als zensurresistente Kommunikationsplattform wenden, werden Probleme bei der Verwaltung von Benutzerschlüsseln auftreten.
Dies ist ein Meinungsleitartikel von Shinobi, einem autodidaktischen Pädagogen im Bitcoin-Bereich und technisch orientierten Bitcoin-Podcast-Moderator.
Ich schlage vor, dass Sie, bevor Sie dies lesen, den vorherigen Artikel lesen, den ich geschrieben habe, in dem ich erklärt habe, was Nostr ist und wie es auf hohem Niveau funktioniert. An diesem Punkt sollten Sie dann eine gute Vorstellung vom Kerndesign des Systems haben, also lassen Sie uns jetzt einen Blick auf wahrscheinliche Probleme werfen, die auftreten werden, wenn die Akzeptanz zunimmt. Da die Plattform für die Bitcoin-Community immer beliebter wird, sollten Sie sich dieser Probleme bewusst sein.
Wie ich im vorherigen Artikel besprochen habe, sind öffentliche/private Schlüsselpaare von Benutzern ein wesentlicher Bestandteil der Funktionsweise von Nostr als Protokoll. Es gibt keine Benutzernamen oder irgendeine Art von Identifikatoren, die ein Relay-Server kontrolliert, um sie einzelnen Benutzern zuzuordnen. Es sind einfach die Schlüssel dieser Benutzer, die vollständig unter ihrer Kontrolle sind.
Dies fungiert als enge Bindung zwischen dem tatsächlichen Benutzer und der Art und Weise, wie er von anderen identifiziert wird, die verhindert, dass ein Relay-Server diese beiden Dinge entbindet, dh jemandes Kennung an einen anderen Benutzer weitergibt. Damit wird eines der größten Grundprobleme von Plattformen zur zwischenmenschlichen Kommunikation gelöst: die fehlende Kontrolle über die eigene Identität der Nutzer. Aber es bringt auch alle Probleme der Schlüsselverwaltung mit sich, auf die jemand stößt, der einen privaten Schlüssel besitzt. Schlüssel können verloren gehen und Schlüssel können kompromittiert werden, und wenn ein solches Ereignis eintreten sollte, haben die Benutzer niemanden, an den sie sich wenden können, genau wie bei Bitcoin. Es gibt keinen Kundensupport, um etwas wiederherzustellen. Du verlierst es, das war’s.
Dies wird unweigerlich ein Schema erfordern, mit dem Benutzer von einem Schlüsselpaar zu einem anderen wechseln können, und zwar auf eine Weise, die für andere Benutzer, mit denen sie über das Protokoll interagieren, überprüfbar und auffindbar ist. Das gesamte Protokoll basiert darauf, zu beweisen, dass ein Ereignis von einem bestimmten Benutzer (Identitätsschlüssel) stammt, sodass alle diese Garantien aus dem Fenster fallen, sobald die Schlüssel einer Person kompromittiert werden.
Wie gehen Sie damit um? Gehen Sie einfach auf ihren Twitter-Account? Nun, das ist letztendlich kein sehr dezentralisiertes System, wenn Sie eine zentralisierte Plattform verwenden müssen, auf der sie keine Kontrolle über ihre Identität haben, um ihre Nostr-Identität zu überprüfen.
Lassen Sie andere Benutzer die Legitimität eines neuen Schlüssels bestätigen? Das betrifft nicht Situationen wie Massenschlüsselkompromittierungen oder die Tatsache, dass sie niemanden in ihrer Nähe gut genug kennen, um ihrer Bestätigung zu vertrauen.
Nostr benötigt ein tatsächliches kryptografisches Schema, das die Rotation eines Schlüssels an einen anderen bindet. Es gibt einen Vorschlag des Entwicklers fiatjaf für ein grundlegendes Schema, das dieses Problem möglicherweise lösen könnte. Die Grundidee wäre, einen langen Satz von Adressen zu nehmen, die von einem einzigen Master-Seed abgeleitet sind, und einen Satz „optimierter“ Schlüssel zu erstellen, ähnlich wie Taproot-Bäume an einen Bitcoin-Schlüssel gebunden werden. Taproot nimmt die Merkle-Baumwurzel des Taproot-Baums und “fügt” sie dem öffentlichen Schlüssel hinzu, um einen neuen öffentlichen Schlüssel zu erstellen. Dies kann repliziert werden, indem diese Merkle-Baumwurzel zum privaten Schlüssel hinzugefügt wird, um den passenden privaten Schlüssel für den neuen öffentlichen Schlüssel zu erhalten. Die Idee von Fiatjaf besteht darin, Verpflichtungen rückwärts vom Ende zum Anfang zu verketten, sodass jeder angepasste Schlüssel tatsächlich einen Beweis dafür enthält, dass der nächste angepasste Schlüssel verwendet wurde, um ihn zu erstellen.
Stellen Sie sich also vor, Sie beginnen mit Schlüssel Z, dem letzten in der Kette. Sie würden dies mit etwas optimieren und dann rückwärts gehen und eine optimierte Version der Taste Y erstellen, indem Sie die optimierte Z-Taste verwenden (Z ‘+ Y = Y’). Von hier aus würden Sie Y’ nehmen und es dann verwenden, um X zu optimieren (Y’ + X = X’). Sie würden dies den ganzen Weg zurück zu Schlüssel A tun, um A’ zu erhalten, und von dort aus beginnen, diesen Schlüssel zu verwenden. Wenn es kompromittiert ist, kann der Benutzer ein Ereignis aussenden, das den ungeschmälerten Schlüssel A und den optimierten Schlüssel B’ enthält. Dies würde alle Daten enthalten, die erforderlich sind, um zu zeigen, dass B’ verwendet wurde, um A’ zu generieren, und Benutzer könnten sofort aufhören, A’ zu folgen, und stattdessen B’ folgen. Sie würden definitiv wissen, dass B’ der nächste Schlüssel dieses Benutzers ist, und stattdessen diesem folgen.
Dieser Vorschlag weist jedoch noch einige Probleme auf. Erstens müssen Sie alle Schlüssel, die Sie jemals verwenden würden, im Voraus generieren, und es gibt keine Möglichkeit, zu einem ganz neuen Satz von Schlüsseln zu wechseln. Dies könnte dadurch behoben werden, dass man sich in diesem Schema auf einen Hauptschlüssel festlegt, der solche Rotationen beglaubigen könnte, oder einfach von Anfang an einen sehr großen Satz von Schlüsseln generiert. Jeder Weg wäre ein gültiger Weg, aber letztendlich würde es erfordern, einen Stammschlüssel oder Schlüsselmaterial sicher aufzubewahren und nur einzelne Hotkeys für Nostr-Clients offenzulegen.
Dieses Schema trägt jedoch nicht dazu bei, Benutzer zu schützen oder bietet einen Mechanismus zur Wiederherstellung der Identität für den Fall, dass das Stammschlüsselmaterial verloren geht oder selbst kompromittiert wird. Nun, das soll nicht heißen, dass das Schema von Fiatjaf keinen Nutzen hat, das ist absolut der Fall, aber es ist wichtig, darauf hinzuweisen, dass keine Lösung jedes Problem löst.
Um hier ein wenig über mögliche Lösungen zu sprechen, stellen Sie sich statt einer Kette von optimierten Schlüsseln, wie er vorschlägt, vor, dass ein Schlüssel mit einem Master-Kaltschlüssel optimiert wird, der auch verwendet werden muss, um das Ereignis zu signieren, das von einem Schlüssel zum anderen rotiert. Sie haben Schlüssel A’, der durch Addieren von A und M (dem Hauptschlüssel) abgeleitet wird, und das Rotationsereignis wäre A, M und B’ (erzeugt durch Addieren von B und M) mit einer Signatur von M. M könnte a sein Multisig-Schwellenwertschlüssel – zwei von drei, drei von fünf usw. Dies könnte möglicherweise Redundanz gegen Verlust hinzufügen und einen sicheren Mechanismus für die Schlüsselrotation bereitstellen. Dies öffnet auch die Tür zur Nutzung von Diensten zur Unterstützung der Wiederherstellung oder zur Weitergabe einiger dieser Schlüssel an vertrauenswürdige Freunde. Es bietet die gleiche Flexibilität wie Multisig mit Bitcoin selbst.
NIP26 ist auch ein Vorschlag, der bei der Behandlung dieses Problems sehr nützlich sein könnte. Dies gibt eine Protokollerweiterung für Ereignisse an, die es einer Signatur von einem Schlüssel ermöglicht, einen anderen Schlüssel zu autorisieren, Ereignisse in seinem Namen zu veröffentlichen. Das “Token” oder der Unterschriftsbeweis der Delegierung würde dann in alle Ereignisse aufgenommen, die vom zweiten öffentlichen Schlüssel im Namen des ersten gepostet werden. Es kann sogar zeitlich begrenzt werden, sodass Delegierungstoken automatisch ablaufen und erneuert werden müssen.
Letztlich wird aber dieses Problem gelöst hat für Nostr langfristig zu lösen. Ein Protokoll, das vollständig auf öffentlichen/privaten Schlüsselpaaren basiert, die als Identitäten verwendet werden, kann keine Zugkraft und Akzeptanz erlangen, wenn die Integrität dieser Identitäten nicht geschützt und für Benutzer aufrechterhalten werden kann. Das läuft letztendlich darauf hinaus, dass Sie ständig Out-of-Band- und zentralisierte Plattformen verwenden müssen, um neue Schlüssel zu überprüfen und Personen zu koordinieren, die Ihrer neuen Identität folgen, wenn etwas verloren geht oder kompromittiert wird, und an diesem Punkt werden diese anderen Plattformen zu einem Mittel, um Verwirrung zu stiften und Zensur betreiben.
Fragen der Schlüsselverwaltung und Sicherheit sind große Probleme mit einem sehr großen Designraum voller Kompromisse und Schmerzpunkte, aber es sind Probleme, die im Kontext von Nostr gelöst werden müssen, damit es funktioniert. In meinem nächsten Artikel werde ich einige Probleme zusammenfassen, die meiner Meinung nach in Bezug auf die Relay-Server-Architektur und Skalierungsprobleme auftauchen, mit denen sich Nostr-Entwickler angesichts der grundlegenden Datenstrukturen auseinandersetzen müssen, auf denen Nostr aufbaut.
Für alle, die lesen und sich fragen, warum ich dezentrale Identifikatoren (DIDs) nicht erwähnt habe: Ja, das ist eine potenzielle Lösung für diese Probleme, die meiner Meinung nach ziemlich umfassend ist. Die Nostr-Entwickler scheinen jedoch sehr zu zögern, DIDs in das Protokoll oder die Clients zu integrieren, da dies externe Abhängigkeiten außerhalb des Nostr-Protokolls schaffen würde. Wenn Sie mit der Funktionsweise von DIDs auf technischer Ebene nicht vertraut und interessiert sind, ist dieser Artikel von Level 39 eine sehr gut geschriebene Zusammenfassung ihrer Funktionsweise.
Dies ist ein Gastbeitrag von Shinobi. Die geäußerten Meinungen sind ausschließlich ihre eigenen und spiegeln nicht unbedingt die von BTC Inc oder Bitcoin Magazine wider.
