Nymchat technische whitepaper

Post-Quantum Key Agreement in Nymchat

Het verspreiden van ML-KEM-768 openbare sleutels over Nostr zonder een directory of een register, en het zaaien van een geheim dat geen openbare waarde onthult.

Het toevoegen van een post-quantum-sleutelwisseling aan een boodschapper is meestal geen cryptografieprobleem.De primitieven zijn gestandaardiseerd en de bibliotheken bestaan. Tweede Dit artikel beschrijft hoe Nymchat dat beantwoordt - waar de tweede sleutel vandaan komt, hoe het de mensen bereikt die het nodig hebben en wat de interface mag claimen over het resultaat - en, in het laatste gedeelte, wat dat resultaat niet beschermt.

Deze pagina is voor het gemak automatisch vertaald. Het Engelse origineel is de versie die van toepassing is.

1Het probleem

Onze privéberichten worden versleuteld met NIP-44De helft die de eenvoudige tekst scrambles — ChaCha20 met een HMAC-SHA256 tag, doorlopen HKDF (RFC 5869- is niet zinvol bedreigd door een kwantumcomputer; het algoritme van Grover kost een vierkante wortel versnelling tegen een symmetrische sleutel, en 256 bits absorbeert dat. akkoord op de sleutel is elliptische curve Diffie-Hellman over Hoofdstuk 256k1Het herstellen van een private sleutel van zijn publieke tegenhanger onthult retroactief elk gedeeld geheim dat de sleutel ooit heeft geproduceerd.

De dreiging die dit creëert wordt niet uitgesteld totdat een dergelijke machine bestaat. Een tegenstander met opslag kan vandaag de dag encryptie-tekst opnemen en decoderen wanneer de mogelijkheid aankomt. Alles wat nu wordt verzonden dat nog steeds belangrijk is, is al gecompromitteerd. Dit is de specifieke aanval die een post-quantum-sleutelwisseling verslaat, en dat is de reden waarom het werk niet kan wachten tot de machine wordt gebouwd.

1.1 De vraag die dit artikel beantwoordt

De mitigatie is goed begrepen: een post-quantum sleutel encapsulatie-mechanisme uitvoeren naast de klassieke uitwisseling, dus een aanvaller moet beide breken om iets te lezen.FIPS 203Dit brengt meteen een distributieprobleem met zich mee:

Je kunt het op papier schrijven, luid lezen of op een scherm scannen, en het is alles wat iemand nodig heeft om je te versleutelen.Een ML-KEM-768 openbare sleutel is 1,184 bytes.Het kan niet luid gelezen worden, het past niet in een gebruikersnaam, en het behoort niet tot een QR-code naast een identiteit die slechts 32 bytes is.

Het moeilijkste deel is dat een tweede sleutel drie verschillende problemen met zich meebrengt, en de rest van dit artikel is grotendeels een antwoord op hen:

• kan worden vervangen. Een sleutel die niemand in een oogopslag kan lezen, is precies het soort ding dat een aanvaller voor zichzelf ruilt. sectie 4 bindt het aan de identiteit met een handtekening, die deze volledig regelt.
• Het moet over de apparaten van een gebruiker overeenkomen. Hetzelfde account op een telefoon en een laptop moeten dezelfde sleutel presenteren, of berichten verzegeld aan de ene kan niet worden geopend op de andere.
• Het kan verloren gaan. De openbare sleutel wordt opnieuw gepubliceerd uit een geheim, dus wat eigenlijk moet overleven is dat geheim - en door constructie herbouwt niets anders het.

2Design beperkingen

Vier beperkingen vormden het antwoord, en ze uitsluiten de meeste van de voor de hand liggende ontwerpen voordat enige code wordt geschreven.

1. Zo weinig mogelijk geheimen. Elk extra geheim is een andere manier om je geschiedenis te verliezen, en iemand die weet om een nsec te back-up zal niet weten om iets anders te back-up. Sectie 3.1 toont deze niet kan worden voldaan rechtstreeks - een post-quantum sleutel afgeleid van de nsec biedt geen post-quantum bescherming helemaal - dus het ontwerp besteedt precies één geheim en niet meer: een enkel stuk van sleutel materiaal, geproduceerd eenmaal per identiteit, gepresenteerd in dezelfde vorm als de nsec en op dezelfde plaats, zodat wie weet hoe te houden een weet hoe om de andere te houden. Sectie 10.1 is eerlijk over wat dat nog kost.
2. Geen autoriteit Er is geen server die kan worden vertrouwd om te zeggen welke sleutel aan wie behoort.
3. Meerdere apparaten, één identiteit Een Nostr-identiteit wordt meestal gebruikt door meerdere klanten tegelijkertijd. wat voor sleutelmateriaal er ook bestaat, moet op hen allemaal identiek eindigen, en de paden die het daar dragen, mogen zelf niet leesbaar zijn door de tegenstander tegen wie de functie zich verdedigt.
4. Geen onderhandelingen Elke in-band uitwisseling van “welke cijfers ondersteunen u?” is een oppervlakte die een aanvaller kan verwijderen om de zwakkere optie te dwingen.

3Een onafhankelijk geheim

De lastige beslissing is dat de ML-KEM decapsulatie sleutel wordt gezaaid uit sleutelmateriaal dat geen openbare waarde blootstelt.

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)

De wortel wordt aan de gebruiker gepresenteerd zoals een nsec is: Beetje 32 Met het menselijk leesbare voorvoegsel nympqZo leest het als nympq1…, weergegeven naast de nsec in het identiteitsscherm achter dezelfde openbare interactie, gekopieerd met hetzelfde besturingselement, nooit ingelogd en nooit ergens in de clear gestuurd.

Het zout is domein gescheiden op doel, dus geen ander geheim kan ooit hetzelfde sleutelpaar afleiden. epoch Contrale aandrijvingen rotatie (sectie 9).

3.1 Waarom de sleutel niet kan worden afgeleid van de identiteits sleutel

Het voor de hand liggende ontwerp is om het sleutelpaar te zaaien uit het geheim dat de gebruiker al heeft:

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

Het is aantrekkelijk om vier redenen, allemaal echt: niets nieuws om te back-upen, omdat de nsec al de back-up is; elk apparaat dat instemt door constructie, zonder synchronisatieprotocol om verkeerd te gaan; één vervangbare aankondiging per identiteit is duidelijk correct, omdat apparaten niet het eens kunnen zijn over de sleutel; en de sleutel die bestaat voordat deze ooit wordt gepubliceerd, zodat een client iets voor zichzelf kan afsluiten op de eerste run.

Alle vier de voordelen zijn waardeloos, om één reden. Shor's algoritme loopt tegen een gepubliceerde npub geeft de nsec. De zaadderivatie is een openbaar algoritme over de nsec. Dus de tegenstander die de klassieke helft breekt, reconstrueert de post-quantum helft door hetzelfde HKDF te lopen dat iedereen anders loopt. Tegen de oogst-nu-decrypt-later - de ene dreiging die de functie bestaat om te stoppen - een sleutel die op deze manier wordt afgeleid, voegt niets toe.

Een onafhankelijk gegenereerd geheim dat vervolgens wordt gesynchroniseerd tussen de apparaten van een gebruiker binnen een gewoon NIP-44-bericht is hetzelfde falen met extra stappen: een tegenstander registreert dat bericht vandaag en herstelt zijn klassieke sleutel later, en de wortel valt uit.

3.2 De wortel naar andere apparaten van de gebruiker brengen

Beperking 3 van Sectie 2 - één identiteit, meerdere apparaten - kan hier niet worden bevredigd door aritmetica, omdat het hele punt is dat de sleutel geen functie is van iets wat de apparaten al delen. nympq1… Code zelf

De wortel wordt weergegeven als nympq1… naast de nsec, en een tweede apparaat accepteert het geplaatst in hetzelfde paneel. Dat is het hele mechanisme.

De regel in Sectie 3.1 zegt dat de wortel nooit onder klassieke alleen-versleuteling kan reizen, en elk mechanisme dat dit automatisch zou maken - het synchroniseren via een relais, het verpakken met de identiteitscode - schendt precies dat.

Het formaat laat ruimte voor een verpakt pad: een record kan een lijst met wraps dragen, elk een AEAD blob onder een sleutel die de gebruiker op een ander apparaat kan reproduceren - een passkey PRF-uitvoer, bijvoorbeeld. nympq1… De code is de enige manier om door te gaan. § 10.1 legt uit wat dat kost.

Het record zelf leeft in zijn eigen categorie instellingen, nymchat-pq-rootZelfs het dragen van geen wraps doet het noodzakelijke werk: de aanwezigheid ervan is hoe een tweede apparaat leert dat deze identiteit al een wortel heeft, wat het ervan weerhoudt om een rivaal te minten (Section 3.3).

3.3 Generatie en adoptie

Op de boot, met een blijvende identiteit, werkt een client in deze volgorde:

1. Op zoek naar een bestaande nymchat-pq-root Het record.
2. Record gevonden, en dit apparaat kan het ontvouwen - adopteer het en verkondig deze identiteit als post-quantum in staat.
3. Record gevonden, en dit apparaat kan het niet ontgrendelen - geen nieuwe wortel genereren en geen advertenties publiceren.Prompt de gebruiker om dit apparaat te koppelen door de nympq1… code van een apparaat dat het al heeft.
4. Geen record — een wortel genereren, het record publiceren, aankondigen en de nympq1… code aan de gebruiker eenmaal, zodat ze het kunnen opslaan.

Stap 3 is de stap die gemakkelijk verkeerd wordt gemaakt, en dat is de reden waarom de volgorde wordt geschreven in plaats van achtergelaten aan elke implementatie.Twee apparaten die elk besluiten een wortel te genereren, produceren twee onafhankelijke wortels onder één identiteit, en dat is het falen dat deze volgorde bestaat om te voorkomen.

4De capaciteit aankondiging

De publieke helft van het afgeleide sleutelpaar wordt gepubliceerd als een Nieuw-01 evenement — type 30078, gelabeld 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 betekent dat de relay één gebeurtenis per (kind, pubkey, d-tag) behoudt, dus vervangt een republiek de vorige aankondiging.

De handtekening is bindend. De gebeurtenis wordt ondertekend door de identiteitscode, dus de claim “deze ML-KEM-sleutel behoort tot deze npub” is precies zo sterk als de npub zelf.Het vervangen van een andere encapsulatie-sleutel vereist het smeden van een secp256k1-ondertekening.

De aankondigingen verlopen. Een zevende dag NIP-40 Expiration, elke 24 uur opnieuw gepubliceerd, houdt het record een verklaring over een client die nog steeds loopt in plaats van een die vroeger was.

Een gemiste aankondiging wordt precies gelezen als een die nooit een sleutel droeg: peers sturen gewone NIP-44, die elke login kan lezen, en de client hervat de post-quantum uitwisseling op zijn volgende verbinding, wanneer deze opnieuw wordt gepubliceerd.

Zonder één overleeft een record de sleutel die het noemt: een apparaat dat wordt gewist, hersteld of zijn wortel heeft vervangen, laat een staande instructie achter om te encapsuleren naar een sleutel die niemand meer houdt, en berichten die eronder worden verzonden, worden zonder fouten aan beide kanten verloren.

Het sleutelveld noemt zijn formaat. Het veld is pk2, en het cijfer is een deel van het contract in plaats van decoratie: het noemt het nuttige laadformaat waarmee de sleutel kan worden gebruikt. Een lezer die het veld niet herkent, sluit de “Nymchat-client, geen post-quantum-sleutel” en stuurt de gewone NIP-44, die elke login kan lezen. Dat is de juiste foutrichting, en het is de moeite waard om te zeggen als een regel dat de formatnummering bestaat om uit te oefenen: een niet-erkende capaciteitsclaim moet bescherming kosten, nooit levering. Een sleutel die een peer niet kan gebruiken is erger dan geen sleutel helemaal, omdat het bericht dat het produceert verloren gaat zonder fout aan beide kanten.

4.1 Afwezigheid is betekenisvol en drievoudig

Een subtiel maar belangrijk detail: de aankondiging wordt gepubliceerd door elke Nymchat-client, niet alleen de post-quantum-capabele, en het sleutelveld is optioneel.

Een sleutelloze aankondiging is een ondertekende verklaring dat de afzender Nymchat draait, waardoor de verzendpad een speculatieve cross-protocol wrap kan overslaan die het anders zou moeten opnemen voor iedereen die het niet kan identificeren.

4.2 Een apparaat dat de wortel niet kan openen, blijft stil

De aankondiging is vervangbaar: één gebeurtenis per identiteit, laatste schrijven wint.Dat is wat het ontwerp van één record werkt, en het is ook wat een ongebonden apparaat gevaarlijk maakt als het publiceert.

Het is niet gebroken en het is niet uit de app gesloten: het leest nog steeds elk bericht waarvoor het de sleutels heeft en stuurt nog steeds klassiek, terwijl het de gebruiker aanmoedigt om het te koppelen.

5Ontdekking en de beslissing om te sturen

Cliënten leren de sleutels van peers op twee manieren. Een stabiel abonnement dekt de mensen met wie een gebruiker feitelijk correspondeert - open gesprekken en groepsleden - dus hun aankondigingen komen als gewone gebeurtenissen. Voor een peer ontmoet voor de eerste keer, een eenmalige query loopt op de verzendtijd, beperkt tot 2,5 seconden; als het niet oplost, gaat het bericht klassiek, dat is het gedrag dat bestond voordat post-quantum werd toegevoegd in plaats van een nieuwe mislukkingsmodus.

Een gebruiker die een nieuw apparaat verbindt, of die van een browser-extensie login naar een lokale sleutel verplaatst, wordt post-quantum in staat mid-conversatie, en een permanent in de cache “no” zou ze op klassieke encryptie te houden voor de levensduur van de aankondiging.

5.1 Waarom er geen downgrade-aanval is

De routebeslissing wordt teruggebracht tot één vraag:

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

Er is geen vermogensonderhandeling, geen lijst met ondersteunde algoritmen en geen veld dat een aanvaller kan opruimen om een zwakker pad te dwingen. is De mislukkingsmodus van een verwijderde of terughoudende aankondiging is dat de boodschap klassiek gaat - de status quo vóór deze functie - in plaats van dat een hybride boodschap wordt gedegradeerd tot iets dat vervalst kan worden.

Het tegenovergestelde houdt ook vast en telt meer: een klant stuurt hybride alleen Wanneer het een sleutel heeft, en het houden van de sleutel is het bewijs dat de ontvanger kan decapsuleren.

6De hybride constructie

Een ongemodificeerde NIP-44-cryptertekst is de binnenlaag en ML-KEM sleutelt een externe AEAD eromheen:

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 geheimen moeten nog hersteld worden om de boodschap te lezen: de buitenste laag geeft alleen een NIP-44-cryptertekst, en die opening heeft de klassieke ECDH nodig. Een kwantum tegenstander die secp256k1 breekt krijgt de innerlijke sleutel en nog steeds ML-KEM geconfronteerd; een breuk van ML-KEM snijdt de buitenste laag en laat NIP-44 staan.

• kem_ss niets in deze derivatie raakt de ruwe ECDH-uitvoer, wat is wat Sectie 6.1 draait op.
• kem_ct, recip_kem_pk En beide identiteitssleutels zijn gekoppeld als geassocieerde gegevens, dus de externe laag is verbonden aan de exacte transcript die het heeft geproduceerd.

De ML-KEM-sleutel van de ontvanger is langdurig, maar elk bericht draagt een onafhankelijke encryptietext en dus een onafhankelijke code. kem_ssDat is wat het afleiden van de nonce in plaats van het willekeurig maken ervan klinkt: ChaCha20-Poly1305 van het bedrijf is verbroken door een (key, nonce) paar opnieuw te gebruiken, en hier is de sleutel zelf nieuw voor elk bericht, zodat geen enkel paar kan herhalen.

6.1 Waarom de lagen gescheiden blijven

Het alternatief is om beide geheimen te mengen in een enkele gesprekssleutel en die door te geven aan NIP-44:

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

Die constructie klinkt als cryptografie. Het heeft één structurele probleem: het heeft behoefte aan ecdh_x, de ruwe x-coördinaten van de ECDH-output, als sleutelmateriaal - en een browser-extensie (NIP-07) of een afstandsondertekenaar (NIP-46Het voert NIP-44 uit namens de oproeper en geeft een encryptie-tekst terug, wat het hele punt is van het houden van de sleutel ergens waar de applicatie niet kan bereiken.

Het mengen van de geheimen sluit dus elke login uit die de identiteitsleutel in een ondertekenaar bewaart, dat wil zeggen de meest voorzichtige gebruikers, en geen hoeveelheid werk op de sleutelderivatie kan het veranderen. Layering verwijdert de afhankelijkheid: NIP-44 blijft geheel en wordt geproduceerd door wat de identiteitsleutel bewaart, ondertekenaar inbegrepen, terwijl de KEM-half wordt berekend uit de herstelcode die de client rechtstreeks bewaart.

De kosten zijn bandbreedte, en het is niet klein. De ML-KEM ciphertekst is 1.088 bytes en rijdt op elk bericht, base64url-gecodeerd tot 1.451 tekens; de externe AEAD voegt een 16-byte Poly1305 tag toe en breidt de NIP-44 payload die het wraps met een derde. Een 50-karakter bericht groeit van 176 bytes tot 1.712, en een 2.000-karakter een van 2.820 tot 5.238.

6.2 Zelfbeschrijvende payloads

De pq2. Prefix maakt de implementatie incrementeel: het is zelfbeschrijvend, dus een client kiest het decryptiepad door de gebruiksbelasting te inspecteren in plaats van een tag te vertrouwen of te onthouden wat een peer ondersteunt. Een lezer die een prefix niet herkent, slaagt er niet in om die gebruiksbelasting te openen in plaats van het verkeerd te lezen, en berichten die voor beide zijden worden verzegeld, kunnen post-quantum lezen als gewone NIP-44 zonder migratie.

6.3 Beide lagen van de cadeau wrap

A NIP-17 Een privébericht is een NIP-59 gift wrap: een niet-ondertekend gerucht, verzegeld onder de identiteitsleutel van de afzender (type 13), vervolgens verpakt onder een wegwerpbare sleutel gegenereerd per bericht (type 1059).

Een signer login krijgt alleen de buitenste laag. Het zegel wordt door de signer geproduceerd als gewone NIP-44 - de applicatie ziet nooit de sleutel die het maakt - dus het kan niet worden hybridiseerd in plaats daarvan. Dit kost niets tegen de aanval in kwestie: het zegel is alleen bereikbaar via de wrap, en de wrap is wat een recorder opslaat. Een tegenstander die opgenomen verkeer houdt moet ML-KEM breken voordat een zegel zelfs zichtbaar is om aan te vallen.

7Groepsberichten en gedeeltelijke dekking

Een groepsboodschap is niet één ciphertekst. Het is dezelfde eenvoudige tekst die aan elk lid wordt uitgegeven, elk exemplaar dat is ingekapseld in de eigen ML-KEM-sleutel van dat lid. Een lid dat een sleutel heeft gepubliceerd, krijgt een hybride wrap; een lid dat geen klassieke wrap heeft.

Dit creëert een boekhoudprobleem dat een naïeve implementatie fout krijgt. Als acht van de tien leden een hybride kopie ontvangen, is het bericht niet Een tegenstander heeft één klassieke kopie van een eenvoudige tekst nodig die in alle tien identiek is, dus het bericht wordt alleen beschermd als elk Het is een kopie.

Nymchat volgt dus de dekking per bericht tijdens de fan-out - het aantal is alleen bekend terwijl de wraps worden gebouwd - en het badge rapporteert “quantum-resistent tot 8 van de 10 leden” in plaats van te beweren dat het bericht beschermd is. ontvangen groepsboodschap (alleen de afzender telt de fan-out), de interface rapporteert gedeeltelijke in plaats van volledige bescherming.

7.1 Wat het schild rapporteert

Het schild vertelt de waarheid over de Boodschapniet over de software die het heeft verzonden:

• Volledige bescherming: elk exemplaar van deze plaintext ging uit hybride.
• gedeeltelijk: sommige kopieën van een groepsboodschap gingen klassiek uit. gedegradeerd in plaats van volledig, omdat één klassieke kopie van een eenvoudige tekst identiek is in alle van hen is een tegenstander behoeften.
• Klassiek wordt uitdrukkelijk aangegeven in plaats van te worden weergegeven als geen badge, omdat een afwezige indicator dubbelzinnig is tussen “onbeschermd”, “gebroken”, en “deze constructie mist de functie”.

De uitspraak wordt opgenomen wanneer het bericht wordt verzegeld in plaats van opnieuw berekend op basis van wat een peer later adverteert.Cyphertext dat al bestaat, kan niet beter worden beschermd dan het was, en een interface die oude berichten opnieuw op de kracht van een nieuwe aankondiging zou beweren iets vals over bytes op een relay.

De bovenstaande groepsregels staan hier bovenop in plaats van deze te vervangen: een groepsboodschap wordt alleen volledig beschermd wanneer de kopie van elk lid is, en een ontvangen groepsboodschap zonder dekking wordt gedeeltelijk weergegeven.

8Kopieën gericht aan jezelf

Verschillende dingen die een client opslaat, worden gecodeerd naar de identiteit van de gebruiker: gesynchroniseerde instellingen, de gesprekslijst, groepsleutels en het berichtarchief. Deze dragen meer over een gebruiker dan de meeste enkele berichten, dus als ze klassiek zouden blijven, zouden ze het zwakste opgeslagen artefact zijn, ongeacht hoe zorgvuldig de berichten zelf werden verzegeld. nymchat-pq-root categorie zelf, die niet kan worden verzegeld onder een sleutel die alleen zij kan produceren.

Een instellingenblob of een archiefreeks zit jarenlang op één plek, wat precies de vorm is van iets dat een oogst-nu-decrypt-later tegenstander verzamelt - veel meer dan een enkele boodschap, die in de eigen geest van de gebruiker tenminste ephemeral is.

Een beperking regelt het formaat hier in plaats van de sleutel. elk apparaat op het account, dus elk apparaat adverteert wat het kan openen in de lijst van zijn aankondiging draagt, en het account schrijft alleen wat ze allemaal kunnen lezen. schrijven van iets anders zou een apparaat uit zijn eigen instellingen vergrendelen - dezelfde stille mislukking Sectie 3.2 voorkomt door andere middelen, komen uit een andere richting.

9rotatie

De epoch De counter in de derivatie is wat rotatie mogelijk maakt zonder nieuw sleutelmateriaal. Incrementeren geeft een nieuw sleutelpaar van dezelfde wortel en een herpubliceerde aankondiging; peers halen de nieuwe sleutel uit de vervangbare record.

9.1 Oude tijdperken worden bewaard en niets wordt opnieuw gecodeerd

Een client bouwt decryptiecandidaten van het huidige tijdperk naar het tijdperk − 3, dus een bericht dat kort voor een rotatie wordt verzegeld, wordt nog steeds geopend tegen het sleutelpaar dat actueel was toen het werd verzonden.

Dat raam is wat rotatie helemaal veilig maakt: zonder rotatie zou elke rotatie alles wat in de vlucht was verpesten. Alles wat al verzegeld is, blijft leesbaar voor de levensduur van de identiteit, omdat een bericht dat de gebruiker niet meer kan openen strikt slechter is voor hen dan een waarvan de bescherming niet retroactief kan worden verbeterd (Section 10.5).

10Wat dit niet beschermt

Een document dat alleen vermeldt wat een ontwerp bereikt, beschrijft geen systeem, en overdrijven van een beveiligingseigenschap in een interface is erger dan het weglaten.

10.1 De wortel is een tweede geheim en het verliezen ervan is onherstelbaar

Dit is de werkelijke prijs van het ontwerp. De beperking in Sectie 2 dat een gebruiker precies één ding moet behouden, kan niet worden vervuld: alleen de nsec reconstrueert de post-quantum-sleutel niet, omdat het hele punt is dat geen openbare waarde en geen ander geheim het onthult. Als geen enkel apparaat de wortel vasthoudt en geen van de wraps van Sectie 3.2 kan worden geopend, is het materiaal dat is verzegeld tot de wortel afgeleide sleutel niet herstelbaar.

Met de handmatige overdracht de enige weg, dit is scherper dan het eerst kan lezen. nympq1… code overal heeft precies één kopie van het, op één apparaat, en het verliezen van dat apparaat verliest elke post-quantum bericht, instellingen blob en archief rij verzegeld op het. nsec Het helpt niet; dat is de eigenschap waarop het hele ontwerp berust.

Een aanvaller aanvallen de goedkoopste weg beschikbaar, dus een schema is de moeite waard wat de zwakste herstel route is waard - een memorabele passphrase, bijvoorbeeld, zou het hele ding op wat de passphrase waard is, en de verpakte rij is precies het artefact een oogst-nu-decrypt-later tegenstander verzamelt en malen offline op vrije tijd.

10.2 Authenticatie, anders dan vertrouwelijkheid

Elke handtekening in Nostr is Schnorr over secp256k1, en dat is hier ongewijzigd. Een tegenstander met een kwantumcomputer kon handtekeningen vervalsen en een gebruiker in realtime voorstellen. Wat de hybride sleutelwisseling verslaat, is oogst-nu-decryptie-later: een aanvaller die vandaag verkeer opneemt, kan het niet later lezen. Het maakt een bericht niet onvergeeflijk tegen een tegenstander die al de machine heeft. Deze onderscheiding wordt opzettelijk in de applicaties gebracht - de padlock-indicator meldt authenticatie, het schild meldt vertrouwelijkheid en ze zijn afzonderlijke glyfen omdat een bericht zonder de ander kan hebben.

De binding tussen een npub en een ML-KEM-sleutel is een secp256k1-handtekening, dus een tegenstander die deze kan vervalsen, kan een eigen sleutel vervangen.

3.3 Metadata

Gift wrapping verbergt de afzender, de ontvanger verder dan een enkele p Het verbergt niet dat een gebeurtenis bestaat, de grootte ervan, of wanneer een relay het heeft ontvangen.

10.4 Het offline mesh

Nymchat's Bluetooth mesh transport is een apart protocol met zijn eigen handgreep, en het wordt niet gedekt door dit werk.

10.5 Berichten die al zijn verzonden

Ciphertext opgenomen terwijl beide zijden nog steeds klassiek klassiek bleven permanent. Het bestaat al en kan niet opnieuw worden afgesloten. Bescherming begint bij het bericht waar beide zijden post-quantum-toets hielden, niet op het moment dat de functie werd ingeschakeld.

11Alternatieven overwogen

12Uitvoeringspariteit

Nymchat levert twee onafhankelijke implementaties van deze constructie - een in JavaScript voor de webtoepassing, een in Dart voor de mobiele applicaties, waaronder een uit de grond gelegde ML-KEM-768-poort.

De implementatie van de Dart ML-KEM wordt gevalideerd tegen de officiële Nieuwe ACVP Gecontroleerd door de WMV-FZV-FZV-FZV-FZV (ML-KEM-*-FIPS203) — 25 sleutelgeneratie, 25 encapsulatie en 10 decapsulatie gevallen, uitgevoerd als hun eigen suite. Dit zijn de vectoren die NIST publiceert om een implementatie te valideren, dus doorgeven is het bewijs dat de poort correct is, niet alleen bewijs dat de twee cliënten het met elkaar eens zijn. Bovendien wordt een gedeelde fixture van testvectoren — zaadderivatie, encapsulatie, zowel payloadformaten als complete gift wraps — gegenereerd uit de JavaScript-verwijzing en gecontroleerd door beide testsuites. Het rootgeheim breidt die fixture uit in plaats van het te vervangen: wortel naar zaad, wortel naar keypair, de openbare vingerafdruk van de wortel, en de afgeleide sleutel, nonce en bijbehorende nympq1… Een divergentie in beide implementaties mislukt de build in plaats van het produceren van een bericht dat de andere client niet kan openen.

Het is wat een apparaat vertelt “dit is de wortel die ik houd” van “dit is een andere one”, en een client die de vingerafdruk van een andere klant niet kon reproduceren, zou een perfect goed record lezen als geen record helemaal - en vervolgens, na Sectie 3.3, een tweede wortel munt en de identiteit splitsen.