Bei Messenger mit End-to-End-Verschlüsselung (E2E) ist der Benutzer für seine Schlüssel verantwortlich. Wenn er sie verliert, muss er sein Konto zurücksetzen.

Das Zurücksetzen eines Kontos ist gefährlich. Sie löschen die öffentlichen Schlüssel und werden in allen Gesprächen zu einem kryptografischen Fremden. Sie müssen Ihre Identität wiederherstellen. In fast allen Fällen bedeutet dies ein persönliches Treffen und einen Vergleich der „Sicherheitsnummern“ mit jedem der Kontakte. Wie oft durchlaufen Sie wirklich einen solchen Test, der der einzige Schutz vor MiTM ist?

Selbst wenn Sie es mit Sicherheitsnummern ernst meinen, sehen Sie auf einer Konferenz nur einmal im Jahr viele Chat-Partner, sodass Sie nicht weiterkommen.

Aber das kommt selten vor, oder?

Wie oft erfolgt ein Reset? Antwort: In den meisten E2E-Chat-Anwendungen ständig.

In diesen Instant Messenger löschen Sie die Kryptografie und vertrauen einfach dem Server: (1) wenn Sie zu einem neuen Telefon wechseln; (2) wann immer ein Gesprächspartner zu einem neuen Telefon wechselt; (3) beim Zurücksetzen auf die Werkseinstellungen des Telefons; (4) wenn ein Gesprächspartner die Werkseinstellungen zurücksetzt; (5) wann immer Sie die Anwendung deinstallieren und neu installieren oder (6) wann immer eine Person, mit der Sie sprechen, sie deinstalliert und neu installiert. Wenn Sie Dutzende von Kontakten haben, wird alle paar Tage ein Reset durchgeführt.

Das Zurücksetzen erfolgt so regelmäßig, dass diese Anwendungen so tun, als sei dies kein Problem:

Es sieht so aus, als hätten wir ein Sicherheitsupgrade! (Aber nicht wirklich)

Ist es wirklich TOFU?

In der Kryptographie beschreibt der Begriff TOFU ("Vertrauen bei der ersten Verwendung") ein Glücksspiel, wenn zwei Parteien zum ersten Mal miteinander sprechen. Anstatt sich persönlich zu treffen, ist der Mediator für jede Seite verantwortlich ... und nachdem die Parteien sich präsentiert haben, überwacht jede Seite sorgfältig die Schlüssel, um sicherzustellen, dass sich nichts geändert hat. Wenn sich der Schlüssel geändert hat, gibt jede Seite einen Alarm aus.

Wenn sich der Schlüssel des Remote-Hosts in einer solchen Situation in SSH ändert, funktioniert er nicht nur, sondern wird vollständig kriegerisch:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is 00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff Please contact your system administrator. Add correct host key in /Users/rmueller/.ssh/known_hosts to get rid of this message. Offending RSA key in /Users/rmueller/.ssh/known_hosts:12 RSA host key for 8.8.8.8 has changed and you have requested strict checking. Host key verification failed.

Hier ist das richtige Verhalten. Und denken Sie daran: Dies ist kein TOFU, wenn Sie mit einer kleinen Warnung weiterarbeiten können. Sie sollten einen riesigen Schädel mit gekreuzten Knochen sehen .

Natürlich werden diese Instant Messenger behaupten, dass alles in Ordnung ist, weil der Benutzer gewarnt wird. Wenn er will, kann er die Sicherheitsnummern überprüfen. Deshalb sind wir uns nicht einig:

Die Überprüfung wird nicht durchgeführt, da dies zu oft vorkommt.
Überprüfen Sie saugt.
Selbst eine flüchtige Umfrage unter unseren Freunden, die sich um die Sicherheit sorgen, ergab, dass sich niemand Sorgen um diesen Test macht.
Es geht also nur darum, dem Server zu vertrauen und SMS zu vertrauen (na ja!). Immer wieder .
Schließlich sollten diese Anwendungen nicht auf diese Weise funktionieren. Besonders beim Gerätewechsel. Ein typischer Normalfall kann reibungslos und sicher behandelt werden. Je seltener die Situation, desto schlechter sollte sie aussehen. Zeigen Sie in einer Minute die Keybase-Lösung.

Hör auf, es TOFU zu nennen

Es gibt einen sehr effektiven Angriff. Angenommen, Eve möchte in das bestehende Gespräch von Alice und Bob einbrechen und zwischen ihnen stehen. Alice und Bob sind seit vielen Jahren in Kontakt, nachdem sie TOFU längst bestanden haben.

Eva lässt Alice nur denken, dass Bob ein neues Telefon gekauft hat:

Bob (Eva): Hey, hey!

Alice: Yo, Bob! Es sieht so aus, als hätten Sie neue Sicherheitsnummern.

Bob (Eva): Ja, ich habe das iPhone XS gekauft, ein gutes Telefon, sehr zufrieden damit. Lassen Sie uns die Sicherheitsnummern des RWC 2020 austauschen. Hey, haben Sie Ihre aktuelle Caroline-Adresse? Ich möchte sie überraschen, während ich in San Francisco bin.

Alice: Ich kann es nicht vergleichen, Android 4 Leben! Ja, Cosy Street 555.

Daher ist es unwahrscheinlich, dass die meisten verschlüsselten Messenger die TOFU-Konformität erreichen. Dies ähnelt eher TADA - Vertrauen nach dem Hinzufügen von Geräten. Dies ist ein reales, kein fiktives Problem, da es die Möglichkeit einer böswilligen Implementierung in einer bereits vorhandenen Konversation bietet. In einer echten TOFU kann jemand, der sich für Ihr Gespräch interessiert, es nicht infiltrieren. Mit TADA ist dies möglich.

In Gruppenchats ist die Situation noch schlimmer. Je mehr Personen im Chat sind, desto häufiger wird das Konto neu installiert. In einem Unternehmen mit nur 20 Mitarbeitern wird dies nach unserer Schätzung ungefähr alle zwei Wochen geschehen. Und jede Person im Unternehmen muss diese Person treffen. Persönlich. Andernfalls wird der gesamte Chat von einem Maulwurf oder Hacker kompromittiert.

Lösung

Gibt es eine gute Lösung, die kein Vertrauen in private Schlüsselserver impliziert? Wir glauben, dass es Folgendes gibt: echte Unterstützung für mehrere Geräte. Dies bedeutet, dass Sie eine Kette von Geräten verwalten, die Ihre Identität darstellen. Wenn Sie ein neues Gerät (Telefon, Laptop, Desktop-Computer, iPad usw.) erhalten, generiert es ein eigenes Schlüsselpaar und Ihr vorheriges Gerät signiert es. Wenn Sie das Gerät verlieren, löschen Sie es von einem der verbleibenden Geräte. Technisch gesehen ist ein solches Löschen ein Rückruf, und in diesem Fall gibt es auch eine Art Schlüsselumkehr, die automatisch erfolgt.

Daher müssen Sie dem Server nicht vertrauen oder sich persönlich treffen, wenn der Gesprächspartner oder Kollege ein neues Gerät erhält . Ebenso müssen Sie dem Server nicht vertrauen oder sich persönlich treffen, wenn er das Gerät entfernt, wenn es nicht das letzte war. Sie müssen nur dann eine Warnung sehen, wenn jemand wirklich den Zugriff auf alle Einstellungen verliert. Und in diesem Fall sehen Sie eine ernsthafte Warnung, wie es sein sollte:

Besonders maximal hässlich

Infolgedessen werden viel weniger Konten zurückgesetzt und neu installiert. In der Vergangenheit betrug die Gesamtzahl der Geräte-Add-Ons und -Bewertungen auf Keybase das Zehnfache der Anzahl der Kontoentladungen (Sie müssen nicht unser Wort dafür nehmen, dies ist in unserem Merkle-Baum öffentlich verfügbar). Im Gegensatz zu anderen Messenger können wir eine wirklich erschreckende Warnung anzeigen, wenn Sie mit jemandem sprechen, der kürzlich die Schlüssel neu installiert hat.

Das Geräte-Management ist ein komplexer Engineering-Vorgang, den wir mehrfach verfeinert haben. Das vorhandene Gerät signiert die öffentlichen Schlüssel des neuen Geräts und verschlüsselt alle wichtigen geheimen Daten für den öffentlichen Schlüssel des neuen Geräts. Dieser Vorgang sollte schnell (innerhalb einer Sekunde) ausgeführt werden, da es sich um den Aufmerksamkeitsbereich des Benutzers handelt. Infolgedessen verwendet Keybase eine Schlüsselhierarchie, sodass das neue Gerät beim Übertragen von 32 Byte geheimer Daten von einem alten Gerät alle langlebigen kryptografischen Daten anzeigen kann (weitere Informationen finden Sie in den FAQ unten). Dies mag ein wenig überraschend erscheinen, aber genau das ist der Punkt der Kryptographie . Es löst nicht Ihre Probleme bei der Verwaltung von Geheimnissen, sondern macht das System nur skalierbarer.

Das vollständige Bild der Sicherheit

Jetzt können wir vier grundlegende Sicherheitseigenschaften für die Keybase-Anwendung formulieren:

Langlebige geheime Schlüssel verlassen niemals die Geräte, auf denen sie erstellt wurden
Die vollständige Unterstützung mehrerer Geräte minimiert das Löschen von Konten
Der Schlüsselentzug kann nicht böswillig verzögert oder rückgängig gemacht werden
direkte Geheimhaltung durch kurzlebige Zeitnachrichten

Die ersten beiden scheinen verständlich. Ein dritter wird wichtig in einem Design, bei dem ein Geräte-Rückruf erwartet und als normal angesehen wird. Das System muss überprüfen, ob böswillige Server Geräteüberprüfungen nicht verzögern können, über die wir zuvor geschrieben haben .

Weitere Informationen zum vierten Sicherheitsmerkmal finden Sie in unserem Artikel zu kurzlebigen Nachrichten .

Viel neue Kryptographie, ist alles richtig implementiert?

Keybase hat die grundlegenden Sicherheitsfunktionen noch nie implementiert und sie noch nie in wissenschaftlichen Artikeln beschrieben. Wir mussten selbst einige kryptografische Protokolle erfinden. Glücklicherweise gibt es viele handelsübliche, standardisierte und weit verbreitete kryptografische Algorithmen für jede Situation. Unser gesamter Kundencode ist offen . Theoretisch kann jeder Design- oder Implementierungsfehler finden. Wir wollten jedoch die interne Struktur demonstrieren und stellten die beste Sicherheitsprüfungsfirma für eine vollständige Analyse ein.

Heute präsentieren wir den Bericht der NCC Group und sind von den Ergebnissen äußerst ermutigt. Keybase gab über 100.000 US-Dollar für Audits aus, und die NCC Group stellte hochrangige Sicherheits- und Kryptografieexperten ein. Sie haben zwei wichtige Fehler in unserer Implementierung gefunden und wir haben sie schnell behoben. Diese Fehler konnten nur auftreten, wenn unsere Server böswillig gehandelt haben. Wir können versichern, dass sie nicht so handeln werden, aber Sie haben keinen Grund, uns zu glauben. Das ist die Sache!

Wir glauben, dass das NCC-Team hervorragende Arbeit geleistet hat. Respektieren Sie die Zeit, die sie aufgewendet haben, um unsere Architektur und Implementierung vollständig zu verstehen. Sie fanden subtile Fehler, die die Aufmerksamkeit unserer Entwickler auf sich zogen, obwohl wir diesen Teil der Codebasis kürzlich wiederholt angesehen haben. Wir empfehlen Ihnen, den Bericht hier anzusehen oder unsere FAQ zu lesen.

FAQ

Wie können Sie es wagen, ein XYZ-Produkt anzugreifen?

Wir haben bereits Verweise auf bestimmte Produkte aus dem Artikel entfernt.

Was sonst?

Wir sind stolz darauf, dass Keybase keine Telefonnummern benötigt und die IDs von Twitter, HackerNews, Reddit und Github kryptografisch überprüfen kann, wenn Sie jemanden kennen.

Und ... sehr bald ... wird Mastodon unterstützt.

Was ist mit Telefonumleitungsangriffen?

Viele Anwendungen sind anfällig für Umleitungsangriffe. Eve betritt einen Kiosk in einem Einkaufszentrum und überredet Bob, den Mobilfunkbetreiber, Bobs Telefonnummer an ihr Gerät weiterzuleiten. Oder sie überzeugt den Vertreter telefonisch. Jetzt kann sich Eve auf den Messenger-Servern authentifizieren und behauptet, sie sei Bob. Das Ergebnis sieht so aus, als ob unser Beispiel für Alice, Bob und Eve höher ist, aber Eve muss keine Server durchdringen. Einige Anwendungen bieten "Registrierungsblockierung" zum Schutz vor diesem Angriff an, sind jedoch standardmäßig ärgerlich.

Ich habe gehört, dass Keybase einige private Schlüssel an den Server sendet.

In den frühen Tagen (2014 und Anfang 2015) arbeitete Keybase als PGP-Webanwendung, und der Benutzer konnte die Funktion zum Speichern seiner privaten PGP-Schlüssel auf unseren Servern auswählen, die mit Passphrasen verschlüsselt waren (die Keybase nicht kannte).

Im September 2015 haben wir das neue Keybase-Modell vorgestellt. PGP-Schlüssel werden im Keybase-Chat oder im Dateisystem niemals verwendet (und nie verwendet).

Wie werden alte Chats sofort auf neuen Handys angezeigt?

In einigen anderen Anwendungen sehen neue Geräte keine alten Nachrichten, da die Synchronisierung alter Nachrichten über den Server der direkten Geheimhaltung widerspricht. Mit der Keybase-App können Sie bestimmte Nachrichten - oder ganze Konversationen - als "kurzlebig" festlegen. Sie werden nach einer bestimmten Zeit zerstört und zweimal verschlüsselt: einmal mit langlebigen Chat-Verschlüsselungsschlüsseln und einmal mit häufig wechselnden kurzlebigen Schlüsseln. Daher bieten kurzlebige Nachrichten direkte Geheimhaltung und können nicht zwischen Telefonen synchronisiert werden.

Nicht kurzlebige Nachrichten bleiben bestehen, bis der Benutzer sie explizit löscht und E2E mit neuen Geräten im Slack-Stil synchronisiert, nur mit Verschlüsselung! Wenn Sie jemanden zu einem Team hinzufügen oder ein neues Gerät für sich selbst hinzufügen, werden Nachrichten daher entsperrt.

Mehr zur Synchronisation im nächsten Absatz.

Erzähl uns von PUKs!

Vor zwei Jahren haben wir Schlüssel für Benutzer (PUK) eingeführt . Die öffentliche Hälfte der PUK wird in der öffentlichen Sigchain der Benutzer beworben. Die geheime Hälfte wird für den öffentlichen Schlüssel jedes Geräts verschlüsselt. Wenn Alice ein neues Gerät vorbereitet, kennt ihr altes Gerät die geheime Hälfte ihres PUK und den öffentlichen Schlüssel des neuen Geräts. Es verschlüsselt die geheime Hälfte der PUK für den öffentlichen Schlüssel des neuen Geräts, und das neue Gerät lädt diesen Chiffretext über den Server herunter. Das neue Gerät entschlüsselt die PUK und kann sofort auf alle langlebigen Chat-Nachrichten zugreifen.

Immer wenn Alice ein Gerät zurückruft, ändert sie ihre PUK, sodass alle ihre Geräte mit Ausnahme der zuletzt zurückgerufenen eine neue PUK erhalten.

Dieses Synchronisationsschema unterscheidet sich grundlegend vom frühen Keybase-PGP-System. Hier haben alle beteiligten Schlüssel 32 Bytes echte Entropie, sie brechen im Falle eines Server-Hacks nicht mit brutaler Gewalt. Richtig, wenn der Curve25519 oder der PRNG von Go kaputt ist, bricht alles. Die PUK-Synchronisation macht jedoch keine anderen signifikanten kryptografischen Annahmen.

Was ist mit Chats in großen Gruppen?

tL; dr Gruppen haben ihre eigenen geprüften Signaturketten zum Ändern von Rollen, Hinzufügen und Entfernen von Mitgliedern.

Sicherheitsforscher schrieben über Phantom-User-Angriffe auf Gruppen-Chats. Wenn die Clients der Benutzer die Gruppenmitgliedschaft nicht kryptografisch überprüfen können, können böswillige Server Spyware und Maulwürfe in Gruppenchats einbetten. Keybase verfügt über ein sehr zuverlässiges System in Form einer speziellen Gruppenfunktion, über die wir in Zukunft schreiben werden.

Können Sie über NCC-KB2018-001 sprechen?

Wir glauben, dass dieser Fehler der wichtigste Befund des NCC-Audits ist. Keybase verwendet aktiv unveränderliche Datenstrukturen, um die Server-Mehrdeutigkeit vor dem Anhängen zu schützen. Im Falle eines Fehlers kann ein ehrlicher Server ausweichen: "Ich habe Ihnen A früher gesagt, aber ein Fehler ist aufgetreten, ich meinte B". Unsere Kunden haben jedoch die gemeinsame Richtlinie, dem Server keine solche Flexibilität zu gewähren: Sie haben fest codierte Ausnahmen im Falle von Fehlern.

Kürzlich haben wir auch Sigchain V2 eingeführt : Dieses System löst die Skalierbarkeitsprobleme, die wir in der ersten Version nicht richtig vorhergesagt haben. Jetzt sind Clients mit kryptografischen Daten, die sie vom Server abrufen, wirtschaftlicher und erhalten nur eine Signatur vom Ende der Signaturkette anstelle der Signatur jedes Zwischenglieds. Daher haben Kunden die Möglichkeit verloren, zyklisch nach einem bestimmten Signatur-Hash zu suchen. Wir haben diese Hashes jedoch zuvor verwendet, um in dieser Liste fest codierter Ausnahmen nach fehlerhaften Kettenlinks zu suchen. Wir bereiteten uns auf die Veröffentlichung von Sigchain V2 vor und vergaßen dieses Detail, das unter mehreren Abstraktionsebenen verborgen war, sodass das System dem Feld aus der Serverantwort einfach vertraute.

Nachdem der NCC diesen Fehler entdeckt hatte, war die Korrektur einfach genug: Suche nach fest codierten Ausnahmen mit einem Kettenglied-Hash anstelle eines Kettenglied-Signatur-Hash. Der Client kann diese Hashes immer direkt berechnen.

Wir können diesen Fehler auch auf die zusätzliche Komplexität zurückführen, die erforderlich ist, um Sigchain V1 und Sigchain V2 gleichzeitig zu unterstützen. Moderne Clients schreiben Sigchain V2-Links, aber alle Clients müssen ältere v1-Links unbegrenzt unterstützen. Denken Sie daran, dass Kunden für jedes Gerät Links mit ihren privaten Schlüsseln signieren. Wir können nicht alle Kunden koordinieren, die historische Daten in angemessener Zeit überschreiben, da diese Kunden einfach offline sein können.

Können Sie über NCC-KB2018-004 sprechen?

Wie in 001 (siehe oben) wurden wir durch eine bestimmte Kombination aus gleichzeitiger Unterstützung für veraltete Lösungen und Optimierung enttäuscht, was wichtig schien, da wir mehr Erfahrung mit dem System gesammelt haben.

In Sigchain V2 reduzieren wir die Größe der Ketten in Bytes, um die für die Suche nach Benutzern erforderliche Bandbreite zu verringern. Diese Einsparung ist besonders bei Mobiltelefonen wichtig. Daher codieren wir Chainlinks mit MessagePack , nicht mit JSON , was zu guten Einsparungen führt. Im Gegenzug signieren und überprüfen Kunden Signaturen in diesen Ketten. Forscher am NCC haben knifflige Wege gefunden, um „Signaturen“ zu erstellen, die gleichzeitig wie JSON und MessagePack aussehen und zu einem Konflikt führen. Wir haben diese Mehrdeutigkeit der Decodierung während der Optimierung unfreiwillig eingeführt, als wir JSON-Parser vom Standard-Go-Parser auf einen effizienteren umgestellt haben. Dieser schnelle Parser übersprang leise eine Menge Müll, bevor er den eigentlichen JSON fand, der diese polyglotte Angriffsfunktion enthielt. Der Fehler wird durch zusätzliche Eingabeüberprüfung behoben.

In Sigchain V2 haben wir auch den Vorschlag von Adam Langley akzeptiert, dass Unterzeichner ihren Paketen Signaturen mit dem Kontextzeilenpräfix und Byte \0 voranstellen, damit Verifizierer nicht durch die Absichten des Unterzeichners verwirrt werden. Auf der Überprüfungsseite dieser Kontextpräfix-Idee gab es Fehler, die zu anderen polyglotten Angriffen führen konnten. Wir haben diesen Fehler schnell mit einer Whitelist behoben.

Nachdem beide Fehler behoben wurden, weist der Server die böswilligen Lasten des Polyglot-Angriffs zurück, sodass die Ausnutzung dieser Sicherheitsanfälligkeiten nur mit Hilfe eines gefährdeten Servers möglich ist.

Wo ist die Dokumentation?

https://keybase.io/docs

In den kommenden Monaten werden wir mehr Zeit für die Dokumentation aufwenden.

Sie können mehr über diese Aussage von NCC erzählen: "Ein Angreifer kann jedoch die Aktualisierung der Sigchain verweigern oder die Sigchain eines Benutzers auf einen vorherigen Status zurücksetzen, indem er nachfolgende Glieder in der Kette abschneidet."

Keybase verwendet in großem Umfang unveränderliche öffentliche Datenstrukturen, die nur Anhänge enthalten und die Serverinfrastruktur dazu zwingen, eine echte Darstellung von Benutzerkennungen zu erfassen. Wir können den Rückruf von Geräten und das Entfernen von Gruppenmitgliedern so garantieren, dass ein gefährdeter Server nicht zurückgesetzt werden kann. Wenn der Server eine inkonsistente Ansicht anzeigt, wird diese Abweichung Teil des unveränderlichen öffentlichen Datensatzes. Keybase-Kunden oder ein Auditor eines Drittanbieters können jederzeit nach dem Angriff eine Nichtübereinstimmung feststellen. Wir glauben, dass diese Garantien die Garantien konkurrierender Produkte bei weitem übertreffen und nahezu optimal sind, wenn man die praktischen Einschränkungen von Mobiltelefonen und Kunden mit begrenzter Rechenleistung berücksichtigt.

Einfach ausgedrückt, Keybase kann nicht die Signaturen anderer erfinden. Wie jeder Server kann er Daten enthalten. Unser transparenter Merkle-Baum ist jedoch so konzipiert, dass er sie für einen sehr kurzen Zeitraum aufbewahrt und immer auffindbar ist.

Wie behandelt Keybase das Zurücksetzen von Konten?

Wenn Keybase-Benutzer tatsächlich alle ihre Geräte verlieren (anstatt neue hinzuzufügen oder einige zu verlieren), müssen sie zurückgesetzt werden. Nach dem Zurücksetzen des Kontos ist der Benutzer grundsätzlich neu, hat jedoch denselben Benutzernamen. Er kann die "Reset-Anweisung" nicht unterschreiben, da er alle seine Schlüssel verloren hat. Stattdessen schreibt der Keybase-Server die nicht löschbare Anweisung an den Merkle-Baum, was Zurücksetzen bedeutet. Kunden erzwingen die Unmöglichkeit, diese Anweisungen zurückzusetzen. In einem zukünftigen Artikel werden spezifische Mechanismen ausführlich beschrieben.

Dieser Benutzer muss Identitätsprüfungen (Twitter, Github usw.) mit den neuen Schlüsseln erneut hinzufügen.

Kann ein Server einfach das Merkle-Baumblatt einer anderen Person austauschen, um für einen völlig anderen Schlüsselsatz zu werben?

NCC-Autoren erwägen einen feindlichen Keybase-Server, der das Merkle-Baumblatt vollständig austauscht und Bobs wahren Schlüsselsatz durch einen völlig neuen gefälschten Satz ersetzt. Ein angreifender Server hat zwei Möglichkeiten. Erstens kann er den Zustand der Welt teilen, indem er Bob in eine Gabel legt und diejenigen, die er in eine andere täuschen möchte. Zweitens kann er "schummeln", indem er eine Version des Merkle-Baums mit dem richtigen Satz von Bob-Schlüsseln und andere Versionen mit einem gefälschten Satz veröffentlicht. Benutzer, die regelmäßig mit Bob interagieren, werden diesen Angriff entdecken, da sie überprüfen, ob zuvor heruntergeladene Versionen des Bob-Verlaufs gültige Präfixe der neuen Versionen sind, die sie vom Server herunterladen. Validatoren von Drittanbietern, die alle Keybase-Updates scannen, bemerken diesen Angriff ebenfalls. Wenn Sie einen Keybase-Validator eines Drittanbieters schreiben, den wir mögen, können wir eine signifikante Belohnung anbieten. Siehe max auf Keybase. Ansonsten hoffen wir, bald die Schaffung eines autonomen Validators zu planen.

Kannst du glauben, was ich bis zum Ende gelesen habe?

Lesen oder einfach nach unten scrollen?

Keybase und echte TOFU