Technisches Whitepaper von Nymchat

Post-Quantum Key Agreement bei Nymchat

ML-KEM-768 öffentliche Schlüssel über Nostr ohne Verzeichnis oder Register verteilen und aus einem Geheimnis säen, das kein öffentlicher Wert enthüllt.

Das Hinzufügen eines post-quantum-Schlüsselaustauschs zu einem Messenger ist meist kein Kryptografieproblem.Die Primitiven sind standardisiert und die Bibliotheken existieren. Zweiter Dieser Artikel beschreibt, wie Nymchat darauf antwortet – woher der zweite Schlüssel kommt, wie er die Menschen erreicht, die ihn benötigen, und was die Schnittstelle über das Ergebnis behaupten darf – und, im letzten Abschnitt, was dieses Ergebnis nicht schützt.

Diese Seite wurde der Einfachheit halber maschinell übersetzt. Es gilt das englische Original.

1Das Problem

Unsere privaten Nachrichten werden verschlüsselt NIP-44Die Hälfte, die den einfachen Text scrambles — ChaCha20 mit einem HMAC-SHA256-Tag, durchschlüsselt HKDF (Die RFC 5869- ist nicht bedeutungsvoll von einem Quantencomputer bedroht; Grovers Algorithmus kostet eine Quadratwurzelbeschleunigung gegen einen symmetrischen Schlüssel, und 256 Bits absorbieren das. zustimmen auf dem Schlüssel ist die elliptische Kurve Diffie-Hellman über Schlagwörter256k1, und Shors Algorithmus löst den diskreten Logarithmus direkt.Die Wiederherstellung eines privaten Schlüssels von seinem öffentlichen Gegenstück enthüllt rückwirkend jedes gemeinsame Geheimnis, das der Schlüssel je produziert hat.

Die Bedrohung, die dies schafft, wird nicht verschoben, bis eine solche Maschine existiert. Ein Gegner mit Speicher kann heute Verschlüsselungstext aufzeichnen und entschlüsseln, wenn die Fähigkeit ankommt. Alles, was jetzt gesendet wird, was dann noch zählt, ist bereits kompromittiert. Dies ist der spezifische Angriff, den ein Post-Quanten-Schlüsseltausch besiegt, und das ist der Grund, warum die Arbeit nicht warten kann, bis die Maschine gebaut wird.

1.1 Die Frage, die dieses Buch beantwortet

Die Minderung ist gut verstanden: Führen Sie einen Post-Quanten-Schlüssel-Enkapsulationsmechanismus neben dem klassischen Austausch, so dass ein Angreifer beide brechen muss, um alles zu lesen.FIPS 203Dies führt sofort zu einem Verteilungsproblem:

Sie können es auf Papier schreiben, laut lesen oder von einem Bildschirm scannen, und es ist alles, was Sie verschlüsseln müssen. Ein ML-KEM-768 öffentlicher Schlüssel ist 1,184 Byte. Es kann nicht laut gelesen werden, es passt nicht in einen Benutzernamen, und es gehört nicht zu einem QR-Code neben einer Identität, die nur 32 Byte ist.

Der schwierigere Teil ist, dass ein zweiter Schlüssel drei verschiedene Probleme mit sich bringt, und der Rest dieses Papers ist weitgehend eine Antwort auf sie:

• Er kann ersetzt werden. Ein Schlüssel, den niemand auf einen Blick lesen kann, ist genau die Art von Sache, die ein Angreifer für sich selbst austauscht. Abschnitt 4 bindet ihn mit einer Signatur an die Identität, die diese direkt festlegt.
• Es muss auf allen Geräten eines Benutzers übereinstimmen. Das gleiche Konto auf einem Telefon und einem Laptop muss den gleichen Schlüssel aufweisen, oder Nachrichten, die zu einem versiegelt sind, können nicht auf dem anderen geöffnet werden.
• Es kann verloren gehen. Der öffentliche Schlüssel wird aus einem Geheimnis wiederveröffentlicht, so dass das, was tatsächlich überleben muss, dieses Geheimnis ist - und durch Konstruktion nichts anderes rekonstruiert es.

2Design Beschränkungen

Vier Einschränkungen bildeten die Antwort, und sie ausschließen die meisten der offensichtlichen Entwürfe, bevor jeder Code geschrieben wird.

1. So wenig Geheimnisse wie möglich. Jedes zusätzliche Geheimnis ist eine andere Möglichkeit, Ihre Geschichte zu verlieren, und jemand, der weiß, wie man eine nsec sichert, wird nicht wissen, wie man etwas anderes sichert. Abschnitt 3.1 zeigt, dass dieser nicht direkt erfüllt werden kann - ein post-quantum-Schlüssel, der von der nsec abgeleitet wird, bietet überhaupt keinen post-quantum-Schutz - so dass das Design genau ein Geheimnis und nicht mehr verbraucht: ein einzelnes Stück Schlüsselmaterial, das einmal pro Identität generiert wird, in der gleichen Form wie der nsec und am gleichen Ort dargestellt wird, so dass jeder, der weiß, wie man den einen bewahrt, weiß, wie man den anderen bewahrt. Abschnitt 10.1 ist ehrlich darüber, was das noch kostet.
2. Keine Autorität Es gibt keinen Server, dem man vertrauen kann, um zu sagen, welcher Schlüssel zu wem gehört.
3. Mehrere Geräte, eine Identität Was auch immer Schlüsselmaterial existiert, muss auf allen von ihnen identisch sein, und die Wege, die es dort tragen, müssen nicht selbst vom Gegner, gegen den das Feature verteidigt, lesbar sein.
4. Keine Verhandlungen Jeder in-band-austausch von “welche cipher unterstützen sie?” ist eine oberfläche, die ein angreifer streichen kann, um die schwächere option zu zwingen.

3Ein unabhängiges Root-Geheimnis

Die belastende Entscheidung ist, dass der ML-KEM-Dekapsulationsschlüssel aus Schlüsselmaterial gesät wird, das kein öffentlicher Wert enthüllt.

pqRoot   = 32 bytes from a CSPRNG, generated ONCE per identity

seed     = HKDF-Expand(
               HKDF-Extract(salt = "nym-pq-root-v2", IKM = pqRoot),
               info = "mlkem768/epoch/" || epoch,
               64 bytes)

(ek, dk) = ML-KEM-768.KeyGen(seed)

Die Wurzel wird dem Benutzer wie ein nsec präsentiert: Bech32 Mit dem menschlich lesbaren Präfix nympqSo liest es sich als nympq1…, angezeigt neben dem nsec im identitätsbildschirm hinter der gleichen enthüllen interaktion, kopiert mit der gleichen kontrolle, nie angemeldet und nie irgendwo im klaren gesendet. es ist kein passwort und es ist kein login. es ist schlüsselmaterial, das der benutzer speichern kann, genau wie die nsec.

Das Salz ist absichtlich von der Domain getrennt, so dass kein anderes Geheimnis jemals das gleiche Schlüsselpaar abgeben kann. epoch Kontrahentrieb Rotation (Abschnitt 9).

3.1 Warum der Schlüssel nicht aus dem Identitätsschlüssel abgeleitet werden kann

Das offensichtliche Design besteht darin, das Keypair aus dem Geheimnis zu säen, das der Benutzer bereits hat:

seed = HKDF(salt = "…", IKM = nsec)          // do not do this

Es ist aus vier Gründen attraktiv, die alle real sind: Nichts Neues zu sichern, weil der nsec bereits das Backup ist; jedes Gerät, das von der Konstruktion zustimmt, ohne dass ein Synchronisierungsprotokoll schief geht; eine ersetzbare Ankündigung pro Identität ist offensichtlich richtig, weil Geräte über den Schlüssel nicht einverstanden sein können; und der Schlüssel, der vorhanden ist, bevor er jemals veröffentlicht wird, so dass ein Client etwas für sich selbst verschließen kann.

Alle vier Vorteile sind aus einem Grund wertlos. Shors Algorithmus läuft gegen einen veröffentlichten npub erzeugt den nsec. Die Samenableitung ist ein öffentlicher Algorithmus über den nsec. Also der Gegner, der die klassische Hälfte bricht, rekonstruiert die post-quantum-Halbheit, indem er die gleiche HKDF läuft, die jeder andere läuft.

Ein unabhängig generiertes Geheimnis, das dann zwischen den Geräten eines Benutzers innerhalb einer gewöhnlichen NIP-44-Nachricht synchronisiert wird, ist der gleiche Fehler mit zusätzlichen Schritten: Ein Gegner zeichnet diese Nachricht heute auf und erholt seinen klassischen Schlüssel später, und die Wurzel fällt heraus.

3.2 Die Wurzel auf die anderen Geräte des Benutzers bringen

Einschränkung 3 des Abschnitts 2 – eine Identität, mehrere Geräte – kann hier nicht durch Arithmetik befriedigt werden, denn der ganze Punkt ist, dass der Schlüssel keine Funktion von allem ist, was die Geräte bereits teilen. nympq1… Kodex selbst

Die Wurzel wird als nympq1… neben dem nsec, und ein zweites Gerät akzeptiert es in das gleiche Panel eingefügt. Das ist der gesamte Mechanismus. Ein Gerät, das nicht den Code gegeben hat, kann nicht teilnehmen, was Abschnitt 4.2 beschreibt.

Die Regel in Abschnitt 3.1 besagt, dass die Wurzel niemals unter klassischer-nur-Verschlüsselung reisen kann, und jeder Mechanismus, der dies automatisieren würde - synchronisieren Sie es über ein Relay, wickeln Sie es mit dem Identitätsschlüssel - verletzt genau das.

Das Format lässt Raum für einen verpackten Pfad: Ein Datensatz kann eine Liste von Verpackungen tragen, jede eine AEAD-Blob unter einem Schlüssel, den der Benutzer auf einem anderen Gerät reproduzieren kann - zum Beispiel eine passkey PRF-Ausgabe. nympq1… Der Code ist der einzige Weg durch. Abschnitt 10.1 gibt an, wie viel es kostet.

Die Aufzeichnung selbst lebt in ihrer eigenen Einstellungskategorie, nymchat-pq-rootAuch wenn es keine Umhüllungen trägt, tut es die notwendige Arbeit: Seine Anwesenheit ist, wie ein zweites Gerät erfährt, dass diese Identität bereits eine Wurzel hat, was es davon abhält, eine Rivale anzuziehen (Abschnitt 3.3).

3.3 Generation und Adoption

Beim Booten mit einer dauerhaften Identität arbeitet ein Client in dieser Reihenfolge:

1. Suchen Sie nach einem vorhandenen nymchat-pq-root Die Rekorde.
2. Aufzeichnung gefunden, und dieses Gerät kann es entwickeln - nimmt es an und verkündet diese Identität als post-quantum fähig.
3. Aufzeichnung gefunden, und dieses Gerät kann es nicht - generieren Sie keine neue Wurzel und veröffentlichen Sie keine Ankündigung überhaupt. Bitten Sie den Benutzer, dieses Gerät zu verknüpfen, indem Sie die nympq1… Code von einem Gerät, das es bereits hat.
4. Kein Rekord - erzeugen Sie eine Wurzel, veröffentlichen Sie die Aufzeichnung, verkünden und zeigen Sie die nympq1… Code an den Benutzer, damit er es speichern kann.

Schritt 3 ist der Schritt, der leicht falsch zu werden ist, und das ist der Grund, warum die Reihenfolge aufgeschrieben wird, anstatt zu jeder Implementierung zurückgelassen.Zwei Geräte, die sich entschließen, eine Wurzel zu generieren, produzieren zwei unabhängige Wurzeln unter einer Identität, und das ist das Versagen, das diese Reihenfolge besteht, um zu verhindern.

4Die Kapazität Ankündigung

Die öffentliche Hälfte des abgeleiteten Keypairs wird als adressierbar veröffentlicht Nippe 01 Veranstaltung — kind 30078, gekennzeichnet nym-pq:

{
  "kind": 30078,
  "tags": [
    ["d", "nym-pq"],
    ["t", "nym-pq"],
    ["expiration", "<unix seconds>"]
  ],
  "content": {
    "v":     2,
    "alg":   "mlkem768",
    "nym":   1,
    "epoch": 0,
    "pk2":   "<base64url ML-KEM-768 encapsulation key>",
    "exp":   <unix seconds>,
    "devices": [ ... ]
  }
}

Addressable bedeutet, dass das Relais ein Ereignis pro (kind, pubkey, d-tag) hält, so dass eine Republik die vorherige Ankündigung an Ort und Stelle ersetzt.

Die Unterschrift ist verbindlich. Das Ereignis wird durch den Identitätsschlüssel signiert, so dass die Behauptung “diese ML-KEM-Schlüssel gehört zu diesem npub” ist genau so stark wie der npub selbst.

Ankündigungen läuft aus. Ein Siebentag NIP-40 Expiration, wieder veröffentlicht alle 24 Stunden, hält die Aufzeichnung eine Aussage über einen Client, der noch läuft, anstatt einer, die früher war.

Eine verpasste Ankündigung wird genau so gelesen, wie eine, die niemals einen Schlüssel trug: Peers senden gewöhnliche NIP-44, die jedes Login lesen kann, und der Client setzt den post-quantum-Austausch bei seiner nächsten Verbindung fort, wenn er wieder veröffentlicht.

Ohne einen überlebt ein Datensatz den Schlüssel, den er benennt: Ein Gerät, das gelöscht, neu eingestellt oder seine Wurzel ersetzt wurde, hinterlässt eine stehende Anweisung, um zu einem Schlüssel einzufüllen, den niemand mehr hält, und Nachrichten, die unter ihm gesendet werden, werden ohne Fehler auf beiden Seiten verloren.

Das Schlüsselfeld benennt sein Format. Das Feld ist pk2Ein Leser, der das Feld nicht erkennt, schließt den “Nymchat-Client, keinen Post-Quanten-Schlüssel” und sendet den gewöhnlichen NIP-44, den jeder Login lesen kann. Das ist die richtige Fehlerrichtung, und es lohnt sich, als Regel die Formatnummerierung zu erklären, um durchzusetzen: eine nicht anerkannte Fähigkeitsklage muss Schutz kosten, niemals Lieferung. Ein Schlüssel, den ein Peer nicht verwenden kann, ist schlimmer als kein Schlüssel überhaupt, weil die Nachricht, die er produziert, ohne Fehler auf beiden Seiten verloren geht.

4.1 Abwesenheit ist sinnvoll und dreifach bewertet

Ein subtiles, aber wichtiges Detail: Die Ankündigung wird von jedem Nymchat-Client veröffentlicht, nicht nur von Post-Quantum-fähigen, und das Schlüsselfeld ist optional.

Eine schlüssellose Ankündigung ist eine unterschriebene Erklärung, dass der Absender Nymchat läuft, was es dem Senderweg ermöglicht, einen spekulativen Cross-Protokoll-Wrap zu überspringen, den er sonst für jeden enthalten müsse, den er nicht identifizieren kann.

4.2 Ein Gerät, das die Wurzel nicht öffnen kann, schweigt

Die Ankündigung ist ersetzbar: Ein Ereignis pro Identität, letztes Schreiben gewinnt.Das ist, was das Single-Record-Design funktioniert, und es ist auch, was ein nicht verknüpftes Gerät gefährlich macht, wenn es veröffentlicht.

Es ist nicht gebrochen und es ist nicht aus der Anwendung ausgeschlossen: Es liest immer noch jede Nachricht, für die es die Schlüssel hat, und sendet immer noch klassisch, während es den Benutzer auffordert, sie zu verlinken.

5Entdeckung und Entsendungsentscheidung

Kunden lernen die Peer-Schlüssel auf zwei Arten.Ein Standing-Abonnement deckt die Personen ab, mit denen ein Benutzer tatsächlich übereinstimmt – offene Gespräche und Gruppenmitglieder –, so dass ihre Ankündigungen als normale Ereignisse ankommen.Für ein Peer-Treffen zum ersten Mal läuft eine Ein-Schuss-Abfrage bei Sendenzeit, begrenzt auf 2,5 Sekunden; wenn sie nicht gelöst wird, wird die Nachricht klassisch, was das Verhalten ist, das vor dem Post-Quantum hinzugefügt wurde, anstatt einen neuen Fehlermodus.

Ein Benutzer, der ein neues Gerät verbindet, oder der von einem Browser-Erweiterungslogin zu einem lokalen Schlüssel bewegt, wird post-quantum-fähig in der Mitte-Konversation, und ein dauerhaft cached “no” würde sie auf der klassischen Verschlüsselung für das Leben der Ankündigung halten.

5.1 Warum es keinen Downgrade-Angriff gibt

Die Routingentscheidung reduziert sich auf eine einzige Frage:

pq = (we hold a signed, unexpired ML-KEM key for this recipient)

Es gibt keine Kapazitätsverhandlungen, keine Liste der unterstützten Algorithmen und kein Feld, das ein Angreifer klären kann, um einen schwächeren Weg zu erzwingen. Ist Der Ausfallmodus einer entzogenen oder zurückgehaltenen Ankündigung ist, dass die Nachricht klassisch wird - der Status quo vor dieser Funktion - anstatt dass eine hybride Nachricht auf etwas herabgerufen wird, das gefälscht werden kann.

Auch das Gegenteil hält und zählt mehr: Ein Kunde sendet Hybrid nur wenn es einen Schlüssel hält und der Schlüssel hält, ist der Beweis, dass der Empfänger entkapseln kann. Es gibt keinen Zustand, in dem eine Nachricht post-quantum an jemanden gesendet wird, der sie nicht lesen kann.

6Der Hybridbau

Ein unmodifizierter NIP-44-Verschlüsselungstext ist die innere Schicht, und ML-KEM schließt eine äußere AEAD um sie herum:

inner = nip44_encrypt(plaintext, conversation_key(sender, recipient))

info  = "nymchat-pq2" || sender_secp_pk || recip_secp_pk || kem_ct || recip_kem_pk
prk   = HKDF-Extract(salt = "nymchat-pq2-v1", IKM = kem_ss)
key   = HKDF-Expand(prk, info || "key",   32)
nonce = HKDF-Expand(prk, info || "nonce", 12)

outer = ChaCha20-Poly1305(key, nonce, plaintext = inner, aad = info)

payload = "pq2." || base64url(kem_ct) || "." || base64url(outer)

Beide Geheimnisse müssen noch wiederhergestellt werden, um die Nachricht zu lesen: Die äußere Schicht erzeugt nur einen NIP-44-Cybertext, und die Öffnung benötigt die klassische ECDH. Ein Quanten Gegner, der secp256k1 bricht, erhält den inneren Schlüssel und immer noch ML-KEM konfrontiert; ein Bruch von ML-KEM streckt die äußere Schicht ab und lässt NIP-44 stehen.

• kem_ss Nichts in dieser Derivation berührt die rohe ECDH-Ausgabe, was in Abschnitt 6.1 geschieht.
• kem_ct, recip_kem_pk und beide Identitätsschlüssel sind als assoziierte Daten gebunden, so dass die äußere Schicht der genauen Transkription verpflichtet ist, die sie erzeugt hat.

Der ML-KEM-Schlüssel des Empfängers ist langlebig, aber jede Nachricht trägt einen unabhängigen Verschlüsselungstext und daher einen unabhängigen Schlüssel. kem_ssDas ist es, was den Nonce abgeleitet, anstatt zufällig zu klingen macht: ChaCha20-Poly1305 ist durch die Wiederverwendung eines (Schlüssel, Nonce) Paares gebrochen, und hier ist der Schlüssel selbst für jede Nachricht neu, so dass kein Paar wiederholen kann.

6.1 Warum die Schichten getrennt bleiben

Die Alternative besteht darin, beide Geheimnisse in einen einzigen Gesprächsschlüssel zu mischen und diesen an NIP-44 zu übermitteln:

ck = HKDF-Extract(salt = "…",
                  IKM  = ecdh_x || kem_ss || …)          // do not do this

Diese Konstruktion klingt wie Kryptographie. Es hat ein strukturelles Problem: Es braucht ecdh_x, die rohe x-Koordinate der ECDH-Ausgabe, als Schlüsselmaterial - und eine Browser-Erweiterung (NIP-07) oder eine entfernte Unterschrift (NIP-46Es führt NIP-44 im Namen des Anrufers aus und gibt einen Verschlüsselungstext zurück, was der ganze Punkt ist, an dem der Schlüssel irgendwo gehalten wird, wo die Anwendung nicht erreicht werden kann.

Das Mischen der Geheimnisse schließt daher jedes Login aus, das den Identitätsschlüssel in einem Unterzeichner hält, das heißt die vorsichtigsten Benutzer, und keine Menge an Arbeit an der Schlüsselderivation kann es ändern.Layering entfernt die Abhängigkeit: NIP-44 bleibt ganz und wird von allem produziert, was den Identitätsschlüssel hält, Unterzeichner inklusive, während die KEM-Halbheit aus dem Wiederherstellungscode berechnet wird, den der Client direkt hält.

Die Kosten sind Bandbreite, und es ist nicht klein. Der ML-KEM-Verschlüsselungstext ist 1.088 Byte und fährt auf jeder Nachricht, base64url-verschlüsselt auf 1.451 Zeichen; die externe AEAD fügt ein 16-Bit Poly1305-Tag hinzu und erweitert die NIP-44-Nutzlast um ein Drittel. Eine 50-Zeichen-Nachricht wächst von 176 Bytes auf 1.712, und eine 2.000-Zeichen-Nachricht von 2.820 auf 5.238. Der Boden beträgt ungefähr 1,5 KB pro Nachricht, unabhängig davon, wie kurz die Nachricht ist, was der Preis der Einkapselung jedes Mal ist, anstatt ein gemeinsames Geheimnis neu zu verwenden.

6.2 Selbstbeschreibende Payloads

Die pq2. Präfix macht die Bereitstellung incremental: Es ist selbstbeschreibend, so dass ein Client den Entschlüsselungsweg wählt, indem er die Nutzlast überprüft, anstatt einem Tag zu vertrauen oder sich daran zu erinnern, was ein Peer unterstützt. Ein Leser, der ein Präfix nicht erkennt, versagt, diese Nutzlast zu öffnen, anstatt sie falsch zu lesen, und Nachrichten, die vor jeder Seite versiegelt wurden, könnten post-quantum wie gewöhnliche NIP-44 ohne Migration lesen.

6.3 Beide Schichten der Geschenkverpackung

A NIP-17 Private Nachricht ist a NIP-59 Geschenkverpackung: ein nicht unterzeichnetes Gerücht, das unter dem Identitätsschlüssel des Absenders (Art 13) versiegelt wird, dann unter einem nach einer Nachricht generierten Wurfschlüssel (Art 1059) verpackt wird.

Ein Signator-Login erhält nur die äußere Schicht. Das Siegel wird vom Signator als gewöhnliches NIP-44 erzeugt – die Anwendung sieht nie den Schlüssel, der es macht – so dass es nicht hybridisiert werden kann. Dies kostet nichts gegen den betreffenden Angriff: Das Siegel ist nur durch die Verpackung erreichbar, und das Siegel ist das, was ein Recorder speichert. Ein Gegner, der den aufgezeichneten Verkehr hält, muss ML-KEM brechen, bevor ein Siegel sogar sichtbar ist, um zu angreifen.

7Gruppennachrichten und teilweise Abdeckung

Eine Gruppennachricht ist kein einzelner Verschlüsselungstext. Es ist der gleiche einfache Text, der an jedes Mitglied weitergeleitet wird, jede Kopie in den eigenen ML-KEM-Schlüssel dieses Mitglieds eingekapselt. Ein Mitglied, das einen Schlüssel veröffentlicht hat, erhält eine Hybridverpackung; ein Mitglied, das keine klassische Verpackung hat.

Dies schafft ein Buchhaltungsproblem, dass eine naive Implementierung falsch wird. Wenn acht von zehn Mitgliedern eine Hybridkopie erhalten, ist die Nachricht nicht Ein Gegner braucht eine klassische Kopie eines einfachen Textes, der in allen zehn identisch ist, so dass die Nachricht nur dann geschützt ist, wenn jeder Die Kopie ist.

Nymchat verfolgt daher die Berichterstattung pro Nachricht während des Fan-outs - die Zählung ist nur erkennbar, während die Wraps gebaut werden - und das Badge berichtet “quantum-resistent zu 8 von 10 Mitgliedern” anstatt zu behaupten, dass die Nachricht geschützt ist. empfangen Gruppennachricht (nur der Absender zählt den Fan-out), die Schnittstelle meldet teilweise statt vollständigen Schutz.

7.1 Was der Schild berichtet

Der Schild sagt die Wahrheit über die Botschaftnicht über die Software, die es gesendet hat:

• Vollständiger Schutz: Jede Kopie dieses einfachen Textes wurde hybridisiert.
• Teilweise: Einige Kopien einer Gruppenbotschaft gingen klassisch aus und wurden eher degradiert als voll, weil eine klassische Kopie eines einfachen Textes, die in allen identisch ist, alle Bedürfnisse des Gegners darstellt.
• Klassisch wird direkt angegeben, anstatt als kein Badge angezeigt zu werden, da ein fehlender Indikator unklar ist zwischen “ ungeschützt”, “ gebrochen” und “dieses Build fehlt das Feature”.

Der Urteil wird aufgezeichnet, wenn die Nachricht versiegelt wird, anstatt von dem, was ein Peer später anzeigt, zurückgezählt.Cybertext, der bereits existiert, kann nicht besser geschützt werden, als es war, und eine Schnittstelle, die alte Nachrichten auf die Stärke einer neuen Ankündigung neu gestaltet, würde etwas Falsches über Byte auf einem Relay behaupten.

Die Gruppe-Regeln oben Stapel oben oben, anstatt es zu ersetzen: Eine Gruppe-Nachricht ist nur vollständig geschützt, wenn die Kopie jedes Mitglieds war, und eine empfangene Gruppe-Nachricht ohne Abdeckungszählung zeigt teilweise.

8Kopien an sich selbst gerichtet

Mehrere Dinge, die ein Client speichert, werden auf die eigene Identität des Benutzers verschlüsselt: Synchronisierte Einstellungen, die Gesprächsliste, die Gruppenschlüssel und das Nachrichtenarchiv. Diese tragen mehr über einen Benutzer als die meisten einzelnen Nachrichten, so dass sie klassisch bleiben, sie das schwächste gespeicherte Artefakt machen würde, unabhängig davon, wie sorgfältig die Nachrichten selbst versiegelt wurden. nymchat-pq-root Kategorie selbst, die nicht unter einem Schlüssel versiegelt werden kann, den nur sie produzieren kann.

Ein Einstellungsblob oder eine Archivreihe sitzt jahrelang an einem Ort, was genau die Form der Sache ist, die ein Ernte-Jetzt-Entschlüsselt-später Gegner sammelt - weit mehr als jede einzelne Nachricht, die zumindest im eigenen Kopf des Benutzers ephemeral ist.

Eine Einschränkung regelt hier das Format anstatt den Schlüssel. Eine selbst adressierte Kopie muss durch jeder Das Gerät auf dem Konto, so dass jedes Gerät werbt, was es öffnen kann in der Tabelle seine Ankündigung trägt, und das Konto schreibt nur, was alle von ihnen lesen können.

9Die Rotation

Die epoch Der Zähler in der Ableitung ist das, was die Rotation ohne neues Schlüsselmaterial möglich macht. Das Zunehmen erzeugt ein frisches Schlüsselpaar aus derselben Wurzel und eine wiederveröffentlichte Ankündigung; Peers holen den neuen Schlüssel aus der ersetzbaren Aufzeichnung auf.

9.1 Alte Epochen werden bewahrt, und nichts wird neu verschlüsselt

Ein Client baut Entschlüsselungskandidaten von der aktuellen Epoche bis zur Epoche − 3, so dass eine Nachricht, die kurz vor einer Rotation versiegelt wurde, immer noch gegen das Schlüsselpaar geöffnet wird, das aktuell war, als es gesendet wurde.

Das Fenster ist das, was die Rotation überhaupt sicher macht: Ohne sie würde jede Rotation alles, was im Flug war, zerstören. Alles, was bereits versiegelt ist, bleibt für das Leben der Identität lesbar, weil eine Nachricht, die der Benutzer nicht mehr öffnen kann, für sie strikt schlimmer ist als eine, deren Schutz nicht rückwirkend verbessert werden kann (Abschnitt 10.5).

10Was das nicht schützt

Ein Papier, das nur auflistet, was ein Design erreicht, beschreibt kein System, und eine Sicherheitseigenschaft in einer Schnittstelle zu übertreiben, ist schlimmer als es auszulassen.

10.1 Die Wurzel ist ein zweites Geheimnis, und es zu verlieren ist unwiederholbar

Dies ist der eigentliche Preis des Designs. Die Einschränkung in Abschnitt 2, dass ein Benutzer genau eine Sache zu behalten hat, kann nicht erfüllt werden: Der nsec allein rekonstruiert den post-quantum-Schlüssel nicht, weil der ganze Punkt darin besteht, dass kein öffentlicher Wert und kein anderes Geheimnis es aufdeckt. Wenn kein Gerät die Wurzel hält und keine der Verpackungen in Abschnitt 3.2 geöffnet werden kann, ist das Material, das zu dem Wurzelabgeleiteten Schlüssel versiegelt wurde, nicht wiederherstellbar.

Mit der manuellen Übertragung des einzigen Pfades ist dies schärfer, als es zuerst gelesen werden kann. nympq1… Code überall hat genau eine Kopie davon, auf einem Gerät, und verliert dieses Gerät verliert jede post-quantum Nachricht, Einstellungen blob und Archivzeile versiegelt. nsec hilft nicht; das ist die Eigenschaft, auf der das gesamte Design beruht.

Ein Angreifer greift den billigsten verfügbaren Pfad an, so dass ein Schema das wert ist, was seine schwächste Wiederherstellungsroute wert ist - ein unvergesslicher Passphrase, zum Beispiel, würde die ganze Sache auf alles setzen, was der Passphrase wert ist, und die gewickelte Reihe ist genau das Artefakt, das ein Ernte- jetzt-entschlüsselt-später Gegner offline in Freizeit sammelt und gräbt.

10.2 Authentifizierung, anders als Vertraulichkeit

Jede Signatur in Nostr ist Schnorr über secp256k1, und das ist hier unverändert. Ein Gegner mit einem Quantencomputer könnte Signaturen gefälscht und einen Benutzer in Echtzeit vorgeben. Was der Hybrid-Schlüsselwechsel verliert, ist Ernte-Jetzt-Entschlüsselung-später: Ein Angreifer, der heute Traffic aufnimmt, kann es später nicht lesen. Es macht eine Nachricht nicht unvergesslich gegen einen Gegner, der bereits die Maschine hat. Diese Unterscheidung wird absichtlich in die Anwendungen übertragen - der Padlock-Indikator meldet Authentifizierung, der Schild meldet Vertraulichkeit und sie sind separate Glyphen, weil eine Nachricht eine ohne die andere haben kann.

Die Bindung zwischen einem npub und einem ML-KEM-Schlüssel ist eine secp256k1-Signatur, so dass ein Gegner, der diese verfälschen kann, einen eigenen Schlüssel ersetzen kann.

10.3 Metadaten

Geschenkverpackung verbirgt den Sender, den Empfänger über eine einzige p Tag, Art und Zeitstempel der inneren Nachricht. Es verbirgt nicht, dass ein Ereignis existiert, seine Größe oder wenn ein Relay es erhalten hat.

10.4 Das Offline-Mesh

Nymchats Bluetooth-Mesh-Transport ist ein separates Protokoll mit eigenem Handschlag, und es ist nicht von dieser Arbeit abgedeckt.

10.5 Nachrichten, die bereits gesendet wurden

Ciphertext, der aufgezeichnet wurde, während beide Seiten immer noch klassisch waren, bleibt klassisch dauerhaft. Es existiert bereits und kann nicht neu versiegelt werden. Schutz beginnt bei der Nachricht, in der beide Seiten post-quantum-Tasten gehalten haben, nicht im Moment, in dem die Funktion eingeschaltet wurde.

11Überlegte Alternativen

12Implementierung Parität

Nymchat liefert zwei unabhängige Implementierungen dieser Konstruktion – eine in JavaScript für die Web-Anwendung, eine in Dart für die mobilen Anwendungen, einschließlich eines von Grund auf gefertigten ML-KEM-768-Ports.

Die Dart ML-KEM-Implementierung wird gegen den offiziellen NIST ACVP Wissenswertes über die Verwendung von Wassermitteln für die Verwendung von Wassermitteln (ML-KEM-768)ML-KEM-*-FIPS203) — 25 Key-Generation, 25 Encapsulation und 10 Decapsulation Fälle, die als ihre eigene Suite ausgeführt werden. Das sind die Vektoren, die NIST veröffentlicht, um eine Implementierung zu validieren, so dass sie durchlaufen, ist der Beweis, dass der Port korrekt ist, nicht nur der Beweis, dass die beiden Clients einig sind. Darüber hinaus wird eine gemeinsame Fixierung von Testvektoren — Samenableitung, Encapsulation, sowohl Nutzlastformate als auch komplette Geschenkverpackungen — aus der JavaScript-Referenz generiert und von beiden Test-Suiten überprüft. Das Root-Geheimnis erweitert diese Fixture, anstatt sie zu ersetzen: Root to Seed, Root to Keypair, der öffentliche Fingerabdruck der Wurzel und die abgeleiteten nympq1… Eine Divergenz in einer der beiden Implementierungen versagt dem Build statt eine Nachricht zu erzeugen, die der andere Client nicht öffnen kann.

Es ist das, was ein Gerät “dies ist die Wurzel, die ich halte” von “dies ist eine andere, und ein Client, der den Fingerabdruck eines anderen Clients nicht reproduzieren konnte, würde eine perfekt gute Aufzeichnung als keine Aufzeichnung überhaupt lesen - und dann, nach Abschnitt 3.3, eine zweite Wurzel schmieden und die Identität teilen.