Nymchat teknisk whitepaper

Post-Quantum nøgleaftale i Nymchat

Distribuere ML-KEM-768 offentlige nøgler over Nostr uden et katalog eller et register, og så dem ud af en hemmelighed, som ingen offentlig værdi afslører.

Tilføjelse af en post-quantum nøgleudveksling til en messenger er for det meste ikke et kryptografi problem. de primitive er standardiseret og bibliotekerne eksisterer. Andet Denne artikel beskriver, hvordan Nymchat svarer på det - hvor den anden nøgle kommer fra, hvordan den når de mennesker, der har brug for det, og hvad grænsefladen er tilladt at hævde om resultatet - og i det sidste afsnit, hvad det resultat ikke beskytter.

Denne side er maskinoversat for nemheds skyld. Den engelske original er den version, der gælder.

1Problemet er

Vores private beskeder er krypteret med NIP-44, som har to adskillelige halvdele. Den halvdel, der scrambles den simple tekst — ChaCha20 med en HMAC-SHA256 tag, nøglet gennem HKDF (RFC 5889) — er ikke meningsfuldt truet af en kvantecomputer; Grovers algoritme koster en kvadratroot acceleration mod en symmetrisk nøgle, og 256 bits absorberer det. Enig på nøglen er elliptisk kurve Diffie-Hellman over Sæson256K1, og Shors algoritme løser den diskrete logaritme direkte. Gendanne en privat nøgle fra sin offentlige modpart retroaktivt afslører hver delt hemmelighed, at nøglen nogensinde produceret.

Den trussel, som dette skaber, udskydes ikke, indtil en sådan maskine eksisterer. En modstander med lagring kan optage kryptertekst i dag og dekryptere det, når evnen ankommer. Alt, der sendes nu, som stadig betyder noget, er allerede kompromitteret. Dette er det specifikke angreb, som en post-quantum-nøgleudveksling taber, og det er grunden til, at arbejdet ikke kan vente på, at maskinen skal bygges.

1.1 Spørgsmålet denne artikel besvarer

Det er vigtigt at være opmærksom på, at der ikke er nogen, der er i tvivl om, at der er tale om en forebyggende reaktion, og at der er tale om en forebyggende reaktion, og at der er tale om en forebyggende reaktion, og at der er tale om en forebyggende reaktion, og at der er tale om en forebyggende reaktion, og at der er tale om en forebyggende reaktion, og at der er tale om en forebyggende reaktion.Fællesskab 203Dette skaber et distributionsproblem:

Du kan skrive det på papir, læse det højt, eller scanne det fra en skærm, og det er alt, hvad nogen har brug for at kryptere til dig. En ML-KEM-768 offentlig nøgle er 1,184 bytes. Det kan ikke læses højt, det vil ikke passe ind i et brugernavn, og det tilhører ikke en QR-kode ud over en identitet, der kun er 32 bytes.

Den sværere del er, at en anden nøgle bringer tre forskellige problemer, og resten af dette papir er stort set et svar på dem:

• Den kan erstattes. En nøgle, som ingen kan læse med et blik, er præcis den slags ting, som en angriber bytter for sig selv.
• Det skal aftales på tværs af en brugers enheder. Den samme konto på en telefon og en bærbar computer skal præsentere den samme nøgle, eller meddelelser forseglet til den ene kan ikke åbnes på den anden.
• Den kan gå tabt. Den offentlige nøgle genudgives fra en hemmelighed, så det, der faktisk skal overleve, er den hemmelighed - og ved konstruktion genopbygger intet andet den.

2Design begrænsninger

Fire begrænsninger formede svaret, og de udelukker de fleste af de indlysende designs, før nogen kode skrives.

1. Så få hemmeligheder som muligt. Hver ekstra hemmelighed er en anden måde at miste din historie, og nogen, der ved, hvordan man sikkerhedskopierer en nsec, vil ikke vide, hvordan man sikkerhedskopierer noget andet. afsnit 3.1 viser, at denne ene ikke kan opfyldes direkte - en post-kvantemærke, der stammer fra nsec, giver ingen post-kvantemærkebeskyttelse overhovedet - så designet bruger nøjagtigt en hemmelighed og ikke mere: et enkelt stykke nøglemateriale, der genereres én gang pr. identitet, præsenteret i samme form som nsec og på samme sted, så den, der ved, hvordan man holder den ene, ved, hvordan man holder den anden. afsnit 10.1 er ærlig om, hvad det stadig koster.
2. Ingen myndighed Der er ingen server, der kan stole på at fortælle, hvilken nøgle der tilhører hvem.
3. Masser af værktøjer, én identitet. Uanset hvilket nøglemateriale der findes, skal det ende med at være identisk på alle dem, og de stier, der bærer det der, må ikke selv være læselige for modstanderen, som funktionen forsvarer mod.
4. Ingen forhandlinger Enhver udveksling i båndet af “hvilke cifre understøtter du?” er en overflade en angriber kan stribe for at tvinge den svagere mulighed.

3En uafhængig rød hemmelighed

Den belastende beslutning er, at ML-KEM-dekapsulationsnøglen er sået fra nøglemateriale, som ingen offentlig værdi afslører.

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)

Root præsenteres for brugeren, som en nsec er: Køge32 Med det menneskeligt læselige præfix nympqDet læser som nympq1…, vist ved siden af nsec i identitetsskærmen bag den samme afsløre interaktion, kopieret med den samme kontrol, aldrig logget og aldrig sendt nogen steder i det klare.

Salt er domænet adskilt med hensigt, så ingen anden hemmelighed kan nogensinde udlede det samme nøglepar. epoch Det drejer sig om roterende drivlinjer (afsnit 9).

3.1 Hvorfor nøglen ikke kan udledes fra identitetsnøglen

Det indlysende design er at så nøgleparet ud af den hemmelighed, som brugeren allerede har:

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

Det er attraktivt af fire grunde, alle reelle: intet nyt at sikkerhedskopiere, fordi nsec allerede er sikkerhedskopien; hver enhed, der accepterer ved konstruktion, uden at synkroniseringsprotokollen går galt; en udskiftelig meddelelse pr. identitet er åbenbart korrekt, fordi enheder ikke kan være uenige om nøglen; og nøglen eksisterende, før den nogensinde er offentliggjort, så en klient kan forsegle noget til sig selv i første omgang.

Alle fire fordele er værdiløse, af en grund. Shors algoritme kører mod en offentliggjort npub giver nsec. Frøderivationen er en offentlig algoritme over nsec. Så modstanderen, der bryder den klassiske halvdel, genopbygger den post-kvante halvdel ved at køre den samme HKDF, som alle andre kører. Mod høst-nu-decrypt-senere - den ene trussel, at funktionen eksisterer for at stoppe - en nøgle, der er afledt på denne måde, tilføjer intet.

En uafhængigt genereret hemmelighed, der derefter synkroniseres mellem en brugers enheder inden for en almindelig NIP-44-meddelelse, er den samme fiasko med ekstra trin: en modstander registrerer den meddelelse i dag og genopretter sin klassiske nøgle senere, og roden falder ud.

3.2 Få roden til brugerens andre enheder

Begrænsning 3 i afsnit 2 - én identitet, flere enheder - kan ikke tilfredsstilles ved aritmetik her, fordi hele pointen er, at nøglen ikke er en funktion af noget, som enhederne allerede deler. nympq1… Kode selv

Rødderne vises som nympq1… ved siden af nsec, og en anden enhed accepterer det indlejret i samme panel. Det er hele mekanismen. En enhed, der ikke er blevet givet koden, kan ikke deltage, som afsnit 4.2 beskriver.

Reglen i afsnit 3.1 siger, at roden aldrig kan rejse under klassisk-kun-kryptering, og enhver mekanisme, der ville gøre dette automatisk - synkronisere det gennem en relæ, pakke det til identitetsnøglen - overtræder præcis det.

Formatet efterlader plads til en indpakket vej: En rekord kan bære en liste over indpakninger, hver en AEAD blob under en nøgle, som brugeren kan reproducere på en anden enhed - en passkey PRF-udgang, for eksempel. nympq1… Koden er den eneste vej igennem. afsnit 10.1 angiver, hvad det koster.

Selve pladen lever i sin egen indstillingskategori, nymchat-pq-rootSelv ved at bære ingen wraps gør det nødvendigt arbejde: dets tilstedeværelse er, hvordan en anden enhed lærer, at denne identitet allerede har en rod, hvilket er, hvad der stopper det fra at mint en rivaliserende en (afsnit 3.3).

3.3 Generation og adoption

Ved opstart, med en varig identitet, fungerer en klient i denne rækkefølge:

1. Søg efter en eksisterende nymchat-pq-root Det rekord.
2. Optagelse fundet, og denne enhed kan afpakke det - vedtage det og erklære denne identitet som post-kvantemæssig i stand.
3. Optagelse fundet, og denne enhed kan ikke løse den - ikke generere en ny rod, og ikke offentliggøre nogen meddelelse overhovedet. opfordre brugeren til at linke denne enhed ved at indtaste nympq1… Kode fra en enhed, der allerede har det.
4. Ikke rekord generere en rod, offentliggøre posten, annoncere og vise nympq1… kode til brugeren én gang, så de kan gemme det.

Trin 3 er det trin, der er let at tage fejl, og det er grunden til, at ordren skrives ned i stedet for at blive efterladt til hver implementering.To enheder, som hver beslutter sig for at generere en rod, producerer to uafhængige rødder under en identitet, og det er den fiasko denne ordre eksisterer for at forhindre.

4Kapacitetsannoncering

Den offentlige halvdel af den afledte nøglepar offentliggøres som en adresserbar af Nip-01 begivenhed — type 30078, tagget 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 betyder, at relæet holder en begivenhed pr. (kind, pubkey, d-tag), så en republik erstatter den foregående meddelelse på plads. Hver identitet har derfor nøjagtigt en aktuel rekord, hvilket er, hvad der gør “look up Alice's key” en enkelt entydig hentning i stedet for en liste at forene.

Underskriften er bindende. Begivenheden er underskrevet af identitetsnøglen, så påstanden “denne ML-KEM-nøgle tilhører denne npub” er nøjagtigt lige så stærk som npub selv.

Annoncer udløber En syvende dag NIP-40 Udløbet, genudgivet hver 24. time, holder optegnelsen en erklæring om en klient, der stadig kører i stedet for en, der plejede at være.

En udeladt meddelelse læses nøjagtigt som en, der aldrig bærer en nøgle: peers sender almindelig NIP-44, som hver login kan læse, og klienten genoptager post-quantum udveksling på sin næste forbindelse, når den genudgives.

Uden en overlever en rekord den nøgle, den hedder: En enhed, der er slettet, nulstillet eller har sit rod erstattet, efterlader en stående instruktion til at indkapsles til en nøgle, ingen holder mere, og meddelelser sendt under den går tabt uden fejl på hver side.

Nøglefeltet navngiver dets format. Feltet er pk2, og cifret er en del af kontrakten snarere end dekoration: det navngiver det brugsbelastningsformat, som nøglen kan bruges med. En læser, der ikke genkender feltet, konkluderer “Nymchat-klienten, ingen post-kvante-nøgle” og sender den almindelige NIP-44, som hver login kan læse. Det er den korrekte fejlretning, og det er værd at bemærke som en regel, at formatnummerering eksisterer for at håndhæve: en uigenkendt kapacitetsansøgning skal koste beskyttelse, aldrig levering. En nøgle, som en peer ikke kan bruge, er værre end ingen nøgle overhovedet, fordi den besked, den producerer, er tabt uden fejl på hver side.

4.1 Fravær er meningsfuldt og tredoblet

En subtil, men vigtig detalje: meddelelsen offentliggøres af hver Nymchat-klient, ikke kun dem, der er post-kvantemagtige, og nøglefeltet er valgfrit.

En nøglefri meddelelse er en underskrevet erklæring om, at afsenderen kører Nymchat, hvilket gør det muligt for afsendelsesvejen at hoppe over en spekulativ krydsprotokolpakning, som den ellers ville have at inkludere for alle, den ikke kan identificere.

4.2 En enhed, der ikke kan åbne roden, forbliver tavs

Det er det, der gør single-record design arbejde, og det er også det, der gør en uafhængig enhed farlig, hvis den offentliggør.

Det er ikke brudt og det er ikke låst ud af applikationen: det læser stadig hver besked, det har nøglerne til, og sender stadig klassisk, samtidig med at brugeren opfordrer til at linke det.

5Opdagelse og afgørelsen om at sende

Klienter lærer peer-nøgler på to måder. Et stående abonnement dækker de mennesker, en bruger faktisk korresponderer med - åbne samtaler og gruppemedlemmer - så deres meddelelser ankommer som almindelige begivenheder. For en peer mødt for første gang, kører en one-shot forespørgsel på sendetid, begrænset til 2,5 sekunder; hvis det ikke løser, bliver meddelelsen klassisk, hvilket er den adfærd, der eksisterede før post-kvantum blev tilføjet i stedet for en ny fiasko-tilstand.

En bruger, der forbinder en ny enhed, eller som flytter fra en browser-udvidelse login til en lokal nøgle, bliver post-kvantemæssigt i stand til mid-samtale, og en permanent cachede “no” ville holde dem på klassisk kryptering for livet af meddelelsen.

5.1 Hvorfor der ikke er nogen nedgradering angreb

Ruteafgørelsen reduceres til et enkelt spørgsmål:

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

Der er ingen kapacitetsforhandlinger, ingen liste over understøttede algoritmer, og intet felt kan en angriber klare for at tvinge en svagere vej. er Den mislykkede tilstand af en stripped eller tilbageholdt meddelelse er, at meddelelsen går klassisk - status quo før denne funktion - snarere end at en hybrid meddelelse nedgraderes til noget forgæves.

Den modsatte holder også og betyder mere: en klient sender hybrid Kun til når den holder en nøgle, og holder nøglen er bevis modtageren kan decapsulate. der er ingen tilstand, hvor en besked sendes post-kvante til nogen, der ikke kan læse det.

6Hybrid konstruktion

En uændret NIP-44 kryptertekst er det indre lag, og ML-KEM nøgler en ekstern AEAD omkring det:

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)

Begge hemmeligheder skal stadig genoprettes for at læse meddelelsen: det ydre lag giver kun en NIP-44 kryptertekst, og åbningen, der har brug for den klassiske ECDH. En kvantemodstander, der bryder secp256k1, får den indre nøgle og stadig står over for ML-KEM; et brud af ML-KEM striber det ydre lag og efterlader NIP-44 stående.

• kem_ss Intet i denne derivation berører den rå ECDH-udgang, hvilket er, hvad Afsnit 6.1 drejer sig om.
• kem_ct, recip_kem_pk og begge identitetsnøgler er bundet i som associerede data, så det ydre lag er forpligtet til den nøjagtige transkription, der producerede det.

Modtagerens ML-KEM-nøgle er langvarig, men hver meddelelse bærer en uafhængig kryptertekst og derfor en uafhængig kode. kem_ssDet er det, der gør, at der udledes nonce i stedet for at randomisere det lyder: ChaCha20-Poly1305 tilgængelig er brudt ved at genbruge et (nøgle, nonce) par, og her er nøglen selv ny for hver meddelelse, så intet par kan gentage.

6.1 Hvorfor lagene forbliver adskilt

Alternativet er at blande begge hemmeligheder i en enkelt samtale nøgle og håndtere det til NIP-44:

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

Denne konstruktion lyder som kryptografi. Den har et strukturelt problem: den har brug for ecdh_x, den rå x-koordinat af ECDH-udgangen, som nøglemateriale - og en browserudvidelse (NIP-07) eller en fjernsigner (NIP-46Det udfører NIP-44 på opfordrerens vegne og hænder tilbage en kryptertekst, som er hele punktet for at holde nøglen et sted, hvor applikationen ikke kan nå.

Blanding af hemmelighederne udelukker derfor hver login, der holder identitetsnøglen i en underskriver, det vil sige de mest omhyggelige brugere, og ingen mængde arbejde på nøglederivationen kan ændre det. Layering fjerner afhængigheden: NIP-44 forbliver hel og produceres af hvad der holder identitetsnøglen, underskriver inkluderet, mens KEM halvdelen beregnes fra genoprettelseskoden, som klienten holder direkte.

Omkostningerne er båndbredde, og det er ikke lille. ML-KEM-krypterteksten er 1.088 bytes og kører på hver besked, base64url-kodet til 1.451 tegn; den eksterne AEAD tilføjer en 16-byte Poly1305-tag og udvider NIP-44-nyhedsbelastningen, den pakker med en tredjedel. En 50-karakter besked vokser fra 176 bytes til 1.712, og en 2.000-karakter en fra 2.820 til 5.238.

6.2 Selvbetegnende payloads

Den pq2. Præfix gør implementeringen inkrementel: det er selvbeskrivende, så en klient vælger dekrypteringsvejen ved at inspicere brugsbelastningen i stedet for ved at stole på et tag eller huske, hvad en peer understøtter.En læser, der ikke genkender et præfix, undlader at åbne den brugsbelastning i stedet for at mislæse den, og meddelelser forseglet før hver side kunne gøre post-kvantemeddelelser læselige som almindelig NIP-44 uden migration.

6.3 Begge lag af gavebåndet

A NIP-17 Det private budskab er en NIP-59 gave wrap: en usigneret rygte, forseglet under afsenderens identitetsnøgle (type 13), derefter pakket under en kastet nøgle genereret pr. besked (type 1059).

En signeringslog får kun det ydre lag. Seglet produceres af signereren som almindelig NIP-44 - applikationen ser aldrig nøglen, der gør det - så det kan ikke hybridiseres på plads. Dette koster intet mod angrebet i spørgsmålet: Seglet er kun tilgængeligt gennem pakningen, og pakningen er, hvad en optager opbevarer. En modstander, der holder registreret trafik, skal bryde ML-KEM, før en segl er endda synlig for at angribe.

7Gruppemeddelelser og delvis dækning

Et gruppemeddelelse er ikke én kryptertekst. Det er den samme tekst, der udleveres til hvert medlem, hver kopi indkapslet til det pågældende medlems egen ML-KEM-nøgle. Et medlem, der har offentliggjort en nøgle, får en hybridpakning; et medlem, der ikke har en klassisk pakning.

Dette skaber et regnskabsproblem, at en naiv implementering bliver forkert. Hvis otte ud af ti medlemmer modtager en hybridkopi, er meddelelsen ikke En modstander har brug for en klassisk kopi af en simpel tekst, der er identisk i alle ti, så meddelelsen er kun beskyttet, hvis hver Kopi er det.

Nymchat sporer derfor per-meddelelsesdækning under fan-out - antallet er kun kendeligt, mens wraps er ved at blive bygget - og badget rapporterer “quantum-resistent til 8 ud af 10 medlemmer” i stedet for at hævde meddelelsen er beskyttet. modtaget gruppe besked (kun afsenderen tæller fan-out), grænsefladen rapporterer delvis snarere end fuld beskyttelse.

7.1 Hvad skjoldet rapporterer

Skjoldet fortæller sandheden om Meddelelseikke om den software, der sendte den:

• Fuld beskyttelse: Hver kopi af denne simple tekst gik ud hybrid.
• Delvis: Nogle kopier af en gruppeseddel gik ud klassisk. Træk nedgraderet snarere end fuld, fordi en klassisk kopi af en ren tekst identisk i alle dem er alle en modstander behov.
• Klassisk er angivet direkte i stedet for vist som ingen badge, fordi en fraværende indikator er tvetydig mellem “ ubeskyttet”, “brudt”, og “denne bygning mangler funktionen”.

Dommen registreres, når meddelelsen er forseglet i stedet for genberegnet fra, hvad en peer annoncerer senere.Cybertekst, der allerede eksisterer, kan ikke blive bedre beskyttet end det var, og en grænseflade, der omskrev gamle meddelelser på styrken af en ny meddelelse, ville hævde noget falskt om bytes på en relay.

Gruppereglerne ovenfor er på toppen af dette i stedet for at erstatte det: en gruppeseddel er kun fuldt beskyttet, når hver medlems kopi var, og en modtaget gruppeseddel uden dækningstælling viser delvis.

8Kopier rettet mod dig selv

Flere ting, som en klient gemmer, er krypteret til brugerens egen identitet: synkroniserede indstillinger, samtale listen, gruppe nøgler og meddelelsesarkivet. Disse bærer mere om en bruger end de fleste enkeltbeskeder gør, så forlader dem klassiske ville gøre dem den svageste gemte artefakt, uanset hvor omhyggeligt meddelelserne selv blev forseglet. De bruger den samme hybrid, indkapslet til brugerens egen rod-deriveret nøgle - med en undtagelse beskrevet i afsnit 3.2, nymchat-pq-root kategorien selv, som ikke kan forsegles under en nøgle, som kun den kan producere.

En indstillinger blob eller en arkiv række sidder på ét sted i årevis, hvilket er præcis den form af ting en høst-nu-dekrypteret-senere modstander indsamler - langt mere end nogen enkelt besked, som er i det mindste ephemeral i brugerens eget sind.

En begrænsning styrer formatet her i stedet for nøglen. hver enhed på kontoen, så hver enhed annoncerer, hvad den kan åbne i den liste, dens meddelelse bærer, og kontoen skriver kun, hvad de alle kan læse.

9Rotation af

Den epoch Counter i derivationen er det, der gør rotation mulig uden nyt nøglemateriale. Incrementering det giver et nyt nøglepar fra den samme rod og en genudgivet meddelelse; peers hente den nye nøgle fra den udskiftelige rekord. rotation derfor ikke bede brugeren om at skrive noget ned en anden gang: roden genereres en gang per identitet og epoken gør omdrejningen.

9.1 Gamle epoker bevares, og intet genkrypteres

En klient opbygger dekrypteringskandidater fra den aktuelle epoke ned til epoke − 3, så en besked forseglet kort før en rotation stadig åbner mod det nøglepar, der var aktuelt, da det blev sendt.

Det vindue er, hvad der gør rotation sikker at gøre overhovedet: uden det, hver rotation ville stjæle, hvad der var i flyvning. Alt allerede forseglet forbliver læsbar for livet af identiteten, fordi en besked brugeren ikke længere kan åbne er strengt værre for dem end en, hvis beskyttelse ikke kan forbedres retroaktivt (afsnit 10.5).

10Hvad der ikke beskytter

Et papir, der kun lister, hvad et design opnår, beskriver ikke et system, og overvurdering af en sikkerhedsegenskab i en grænseflade er værre end at udelade det.

10.1 Roden er en anden hemmelighed, og det er uigenkaldeligt at miste den

Dette er designens reelle pris. Begrænsningen i afsnit 2, at en bruger skal have nøjagtigt én ting at holde, kan ikke opfyldes: nsec alene rekonstruerer ikke post-kvantemærket, fordi hele pointen er, at ingen offentlig værdi og ingen anden hemmelighed afslører det. Hvis ingen enhed holder roden og ingen af afsnit 3.2's wraps kan åbnes, er materiale forseglet til den rod-deriverede nøgle ikke genopretteligt.

Med den manuelle overførsel den eneste vej, dette er skarpere, end det kan først læse. nympq1… kode overalt har nøjagtigt en kopi af det, på en enhed, og mister den enhed mister hver post-kvantemeddelelse, indstillinger blob og arkiv række forseglet til det. nsec Det hjælper ikke; det er den ejendom, hele designet hviler på.

En angriber angriber den billigste vej til rådighed, så en ordning er værd, hvad dens svageste genopretningsrute er værd - en mindeværdig passphrase, for eksempel, ville sætte hele tinget på hvad passsphrase er værd, og den indpakkede række er præcis det artefakt en høst-nu-dekrypteret-senere modstander indsamler og maler offline i fritid.

10.2 Autentificering, som adskiller sig fra fortrolighed

Hver underskrift i Nostr er Schnorr over secp256k1, og det er uændret her. En modstander med en kvantecomputer kunne forfalske underskrifter og foregive en bruger i realtid. Hvad den hybride nøgleudveksling nederlag er høst-nu-decrypt-senere: en angriber optagelse trafik i dag kan ikke læse det senere. Det gør ikke en besked uforglemmelig mod en modstander, der allerede har maskinen. Denne sondring transporteres i applikationerne bevidst - padlock indikatoren rapporterer autentisering, skjoldet rapporterer fortrolighed, og de er separate glyfer, fordi en besked kan have en uden den anden.

Forbindelsen mellem en npub og en ML-KEM-nøgle er en secp256k1-signatur, så en modstander, der kan forfalde dem, kan erstatte en egen nøgle.

10.3 Metadata

Gaveindpakning skjuler afsenderen, modtageren ud over en enkelt p Det skjuler ikke, at en begivenhed eksisterer, dens størrelse, eller når en relæ modtog den.

10.4 Den offline mesh

Nymchats Bluetooth mesh transport er en separat protokol med sit eget håndtryk, og det er ikke dækket af dette arbejde.

10.5 Beskeder, der allerede er sendt

Ciphertext optaget, mens begge sider var stadig klassisk forbliver klassisk permanent. Det eksisterer allerede og kan ikke genforsegles. Beskyttelse begynder på meddelelsen, hvor begge sider holdt post-kvante nøgler, ikke på det tidspunkt funktionen blev tændt.

11Overvejede alternativer

12Paritet i gennemførelsen

Nymchat leverer to uafhængige implementeringer af denne konstruktion - en i JavaScript til webapplikationen, en i Dart til de mobile applikationer, herunder en fra bunden ML-KEM-768 port.

Dart ML-KEM implementering er valideret mod den officielle Næste ACVP Særligt kendt er det, at der er tale om en test af kendte svar for ML-KEM-768 (ML-KEM-*-FIPS203) – 25 nøglegenerering, 25 encapsulation og 10 decapsulation tilfælde, kører som deres egen suite. Det er de vektorer NIST offentliggør for at validere en implementering, så passere dem er bevis for, at porten er korrekt, ikke blot bevis for, at de to klienter er enige med hinanden. Hertil kommer, en fælles fixture af testvektorer – frø derivation, encapsulation, både payload formater og komplette gift wraps – genereres fra JavaScript reference og kontrolleres af begge test suites. Root secret udvider denne fixture i stedet for at erstatte det: root til frø, root til keypair, rodens offentlige fingerprint, og den afledte nøgle, nonce og relaterede data af det ydre lag er deres egne vektorer, så de to klienter kan ikke være uenige om nympq1… En afvigelse i begge implementeringer fejler bygningen i stedet for at producere en meddelelse, som den anden klient ikke kan åbne.

Det er det, der fortæller en enhed “dette er roden jeg holder” fra “dette er en anden én”, og en klient, der ikke kunne reproducere en anden kundes fingeraftryk ville læse en perfekt god rekord som ingen rekord overhovedet - og derefter, efter afsnit 3.3, mint en anden rod og splitte identiteten.