Nymchat teknisk whitepaper

Post-Quantum Key Agreement i Nymchat

Distribusjon av ML-KEM-768 offentlige nøkler over Nostr uten et katalog eller et register, og såing dem ut av en hemmelighet som ingen offentlig verdi avslører.

Å legge til en post-quantum nøkkelutveksling til en budbringer er for det meste ikke et kryptografisk problem. primitivene er standardisert og bibliotekene eksisterer. andre Denne artikkelen beskriver hvordan Nymchat svarer på det - hvor den andre nøkkelen kommer fra, hvordan den når de som trenger den, og hva grensesnittet er tillatt å kreve om resultatet - og, i det siste avsnittet, hva det resultatet ikke beskytter.

Denne siden er maskinoversatt for enkelhets skyld. Den engelske originalen er versjonen som gjelder.

1Problemet

Våre private meldinger er kryptert med NIP-44, som har to separerbare halvdeler. Halvdelen som scrambles den enkle teksten - ChaCha20 med en HMAC-SHA256 tag, nøkkel gjennom HKDF (RFC 5869- er ikke meningsfullt truet av en kvante datamaskin; Grovers algoritme koster en kvadratroot accelerup mot en symmetrisk nøkkel, og 256 biter absorberer det. Enig på nøkkelen er elliptisk kurve Diffie-Hellman over Sykkel256k1Å gjenopprette en privat nøkkel fra sin offentlige motpart avslører retroaktivt hver delt hemmelighet som nøkkelen noensinne produserte.

Trusselen dette skaper er ikke utsatt før en slik maskin eksisterer. En motstander med lagring kan registrere krypteringstekst i dag og dekryptere det når muligheten kommer. Alt som sendes nå som fortsatt betyr noe, er allerede kompromittert. Dette er det spesifikke angrepet en post-kvantemessig nøkkelutveksling taper, og det er derfor arbeidet ikke kan vente på at maskinen skal bygges.

1.1 Spørsmålet denne artikkelen svarer på

Det er viktig å huske på at for å oppnå dette er det nødvendig å bruke en mekanisme for post-quantum key encapsulation ved siden av den klassiske utvekslingen, slik at en angriper må bryte begge deler for å lese noe.FIPS 203Dette skaper et distribusjonsproblem:

Du kan skrive den på papir, lese den høyt, eller skanne den fra en skjerm, og det er alt noen trenger å kryptere for deg. En ML-KEM-768 offentlig nøkkel er 1,184 bytes. Den kan ikke leses høyt, den vil ikke passe inn i et brukernavn, og den tilhører ikke en QR-kode i tillegg til en identitet som er bare 32 bytes.

Den vanskeligere delen er at en annen nøkkel bringer tre forskjellige problemer, og resten av dette papiret er i stor grad et svar på dem:

• Den kan erstattes. En nøkkel ingen kan lese på et øyeblikk er akkurat den typen ting en angriper bytter for sin egen.
• Det må avtales på tvers av en brukers enheter. Samme konto på en telefon og en bærbar datamaskin må vise samme nøkkel, eller meldinger forseglet til en kan ikke åpnes på den andre.
• Den kan bli tapt. Den offentlige nøkkelen er publisert fra en hemmelighet, så det som faktisk må overleve er den hemmeligheten - og ved konstruksjon gjenoppbygger ingenting annet den.

2Design begrensninger

Fire begrensninger dannet svaret, og de utelukker de fleste av de åpenbare designene før noen kode skrives.

1. Så få hemmeligheter som mulig. Hver ekstra hemmelighet er en annen måte å miste historien på, og noen som vet hvordan man sikkerhetskopierer en nsec, vil ikke vite hvordan man sikkerhetskopierer noe annet. avsnitt 3.1 viser at denne ikke kan oppfylles direkte – en post-kvantemessig nøkkel som er avledet fra nsec gir ingen post-kvantemessig beskyttelse i det hele tatt – så designet bruker nøyaktig en hemmelighet og ikke mer: et enkelt stykke nøkkelmateriale, generert en gang per identitet, presentert i samme form som nsec og på samme sted, slik at alle som vet hvordan man skal holde den ene vet hvordan man skal holde den andre.
2. Ingen myndighet Det er ingen server som kan stoles på å fortelle hvilken nøkkel som tilhører hvem.
3. Flere enheter, én identitet En Nostr-identitet brukes vanligvis fra flere klienter samtidig.Uansett hva nøkkelmaterialet eksisterer, må det ende opp identisk på alle dem, og stiene som bærer det der må ikke selv være lesbare av motstanderen funksjonen forsvarer mot.
4. Ingen forhandlinger Enhver utveksling i bandet av “hvilke cifre støtter du?” er en overflate en angriper kan stripe for å tvinge det svakere alternativet.

3En uavhengig rothemmelighet

Den belastende avgjørelsen er at ML-KEM-dekapsuleringsnøkkelen er sådd fra nøkkelmateriale som ingen offentlig verdi avslø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)

Roten presenteres for brukeren slik en nsec er: Bjørk32 Med det menneskelig lesbare prefikset nympqDermed leser den som nympq1…, som vises ved siden av nsec i identitetsskjermen bak samme avsløre interaksjon, kopiert med samme kontroll, aldri logget inn og aldri sendt noe sted i klar.

Saltet er domene-separert med hensikt, så ingen andre hemmeligheter kan noensinne avlede samme nøkkelpar. epoch motordrevne rotasjoner (seksjon 9).

3.1 Hvorfor nøkkelen ikke kan avledes fra identitetsnøkkelen

Den åpenbare utformingen er å så keypair fra hemmeligheten brukeren allerede har:

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

Det er attraktivt av fire grunner, alle av dem ekte: ingenting nytt å sikkerhetskopiere, fordi nsec allerede er sikkerhetskopien; hver enhet som samtykker ved konstruksjon, med ingen synkroniseringsprotokoll for å gå galt; en erstattbar kunngjøring per identitet er åpenbart riktig, fordi enheter ikke kan være uenige om nøkkelen; og nøkkelen som eksisterer før den noensinne er publisert, slik at en klient kan forsegle noe til seg selv i første omgang.

Alle fire fordelene er verdiløse, av en grunn. Shors algoritme kjører mot en publisert npub gir nsec. Frøavledningen er en offentlig algoritme over nsec. Så motstanderen som bryter den klassiske halvdelen gjenoppbygger den post-kvante halvdelen ved å kjøre den samme HKDF som alle andre kjører. Mot høst-nå-dekrypt-senere - den ene trusselen funksjonen eksisterer for å stoppe - en nøkkel avledet på denne måten legger ingenting til.

En uavhengig generert hemmelighet som deretter synkroniseres mellom en brukers enheter i en vanlig NIP-44-melding er den samme feilen med ekstra trinn: en motstander registrerer det meldingen i dag og gjenoppretter sin klassiske nøkkel senere, og roten faller ut.

3.2 Få roten til brukerens andre enheter

Begrensning 3 i avsnitt 2 - én identitet, flere enheter - kan ikke tilfredsstilles av aritmetikk her, fordi hele poenget er at nøkkelen ikke er en funksjon av noe som enhetene allerede deler. nympq1… Kode seg selv.

Røttene vises som nympq1… ved siden av nsec, og en annen enhet aksepterer den limt inn i samme panel. Det er hele mekanismen. En enhet som ikke har fått koden, kan ikke delta, som avsnitt 4.2 beskriver.

Regelen i avsnitt 3.1 sier at roten aldri kan reise under klassisk-kun-kryptering, og hver mekanisme som ville gjøre dette automatisk - synkronisere det gjennom en relay, pakke det til identitetsnøkkelen - bryter nettopp det.

Formatet gir plass til en pakket vei: en post kan bære en liste over pakker, hver en AEAD blob under en nøkkel som brukeren kan reprodusere på en annen enhet - en passkey PRF-utgang, for eksempel. nympq1… Avsnitt 10.1 beskriver hvor mye det koster.

Opptaket selv lever i sin egen innstillingskategori, nymchat-pq-rootSelv bærer ingen wraps det gjør nødvendig arbeid: dens tilstedeværelse er hvordan en annen enhet lærer at denne identiteten allerede har en rot, som er det som stopper den fra å minting en rival en (Seksjon 3.3).

3.3 Generasjon og adopsjon

Ved oppstart, med en varig identitet, fungerer en klient i denne rekkefølgen:

1. Søk etter eksisterende nymchat-pq-root og rekord.
2. Opptak funnet, og denne enheten kan løsne den - vedta det og kunngjøre denne identiteten som post-kvantemessig i stand.
3. Rekord funnet, og denne enheten kan ikke løse den - ikke generere en ny rot, og ikke publisere noen kunngjøring i det hele tatt. nympq1… Kode fra en enhet som allerede har den.
4. Ikke rekord generere en rot, publisere posten, kunngjøre og vise nympq1… kode til brukeren en gang slik at de kan lagre den.

Trinn 3 er trinnet som er lett å ta feil, og det er grunnen til at bestillingen er nedskrevet i stedet for igjen til hver implementering.To enheter som hver bestemmer seg for å generere en rot produserer to uavhengige røtter under en identitet, og det er feilen denne bestillingen eksisterer for å hindre.

4Kunngjøring av kapasitet

Den offentlige halvdelen av den avledede nøkkelparet publiseres som en adresserbar Nippe-01 event — type 30078, merket med 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 betyr at relay holder en hendelse per (kind, pubkey, d-tag), slik at en republikk erstatter den forrige kunngjøringen på plass.

Underskriften er bindende. Hendelsen er signert av identitetsnøkkelen, så påstanden “denne ML-KEM-nøkkelen tilhører denne npub” er akkurat like sterk som npuben selv.

Annonsene utløper nå. En sju dagers NIP-40 Utløpsdatoen, som publiseres hver 24. time, registrerer en uttalelse om en klient som fortsatt kjører i stedet for en som pleide å være.

En tapt kunngjøring leses nøyaktig som en som aldri bærer en nøkkel: peers sender vanlig NIP-44, som hver pålogging kan lese, og klienten gjenopptar post-quantum utveksling på sin neste tilkobling, når den publiseres.

Uten en overlever en post nøkkelen den kaller: En enhet som er slettet, tilbakestilt, eller har roten erstattet, etterlater en stående instruksjon om å kapslere til en nøkkel ingen holder lenger, og meldinger sendt under den går tapt uten feil på hver side.

Nøkkelfeltet heter formatet. Feltet er pk2En leser som ikke gjenkjenner feltet avslutter “Nymchat-klienten, ingen post-quantum-nøkkel” og sender vanlig NIP-44, som hver pålogging kan lese.Det er riktig feilretning, og det er verdt å si som en regel at formatnummerering eksisterer for å håndheve: en uoppdaget evne krav må koste beskyttelse, aldri levering. En nøkkel en peer ikke kan bruke er verre enn ingen nøkkel i det hele tatt, fordi meldingen den produserer er tapt uten feil på hver side.

4.1 Fravær er meningsfullt, og tre-vurdert

En subtil, men viktig detalj: kunngjøringen publiseres av hver Nymchat-klient, ikke bare de som er post-kvantemessige, og nøkkelfeltet er valgfritt.

En nøkkelfri kunngjøring er en signert uttalelse om at avsenderen kjører Nymchat, som tillater sendingspotensialet å hoppe over en spekulativ kryss-protokollpakning det ellers ville ha å inkludere for alle det ikke kan identifisere.

4.2 En enhet som ikke kan åpne roten, forblir stille

Annonsen er utskiftbar: én hendelse per identitet, siste skrive vinner.Det er det som gjør det enkeltoppførte designet til å fungere, og det er også det som gjør en uavhengig enhet farlig hvis den publiserer.En enhet som kunngjorde en nøkkel den hadde myntet for seg selv, ville klobbe den virkelige posten og sende hver peer til kryptering under en nøkkel som andre enheter ikke kan åpne.

Så en enhet som vet en rot eksisterer, men ikke kan åpne den, publiserer ingen kunngjøring i det hele tatt.Det er ikke ødelagt og det er ikke låst ut av applikasjonen: det leser fortsatt hver melding det har nøklene for og fortsatt sender klassisk, samtidig som brukeren oppfordrer til å koble den.

5Oppdagelse og beslutningen om å sende

Klienter lærer peer-nøkler på to måter.Et stående abonnement dekker de menneskene en bruker faktisk samsvarer med - åpne samtaler og gruppemedlemmer - så deres kunngjøringer kommer som vanlige hendelser.For en peer møttes for første gang, kjører en en-shot spørring på sendetid, begrenset til 2,5 sekunder; hvis det ikke løser, blir meldingen klassisk, som er atferden som eksisterte før post-kvantum ble lagt til i stedet for en ny feilmodus.

En bruker som kobler en ny enhet, eller som flytter fra en nettleser-utvidelse pålogging til en lokal nøkkel, blir post-kvantemessig i stand til mid-samtale, og en permanent cached “no” ville holde dem på klassisk kryptering for livet av annonsen.

5.1 Hvorfor det ikke er noen nedgradert angrep

Ruteavgjørelsen reduseres til et enkelt spørsmål:

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

Det er ingen kapasitetsforhandlinger, ingen liste over støttede algoritmer, og ingen felt en angriper kan rydde for å tvinge en svakere vei. er Feilmodus for en strippet eller tilbakeholdt kunngjøring er at meldingen går klassisk - status quo før denne funksjonen - i stedet for at en hybrid melding er nedgradert til noe forgjeves.

Den motsatte holder også og betyr mer: en klient sender hybrid Bare Når det holder en nøkkel, og holder nøkkelen er bevis mottaker kan dekapsulere.Det er ingen tilstand der en melding sendes post-kvantum til noen som ikke kan lese den.

6Hybrid konstruksjon

En uendret NIP-44-kryptertekst er det indre laget, og ML-KEM nøkkler en ekstern AEAD rundt 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 hemmelighetene må fortsatt gjenopprettes for å lese meldingen: det ytre laget gir bare en NIP-44-kryptertekst, og åpningen som trenger den klassiske ECDH. En kvantemotstander som bryter secp256k1 får den indre nøkkelen og fortsatt står overfor ML-KEM; et brudd av ML-KEM striper det ytre laget og etterlater NIP-44 stående.

• kem_ss Ingenting i denne derivasjonen berører den rå ECDH-utgangen, som er hva avsnitt 6.1 blir til.
• kem_ct, recip_kem_pk Og begge identitetsnøkler er bundet inn som tilknyttede data, så det ytre laget er forpliktet til den nøyaktige transkripsjonen som produserte den.

Mottakerens ML-KEM-nøkkel er langvarig, men hver melding bærer en uavhengig kryptertekst og derfor en uavhengig kode. kem_ssDet er det som gjør at det å avlede nonce i stedet for å randomisere det høres ut: ChaCha20-Poly1305 tilbehør er brutt ved å gjenbruke et (nøkkel, nonce) par, og her er nøkkelen selv ny for hver melding, slik at ingen par kan gjenta.

6.1 Hvorfor lagene forblir separate

Alternativet er å blande begge hemmelighetene i en enkelt samtalenøkkel og gi den til NIP-44:

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

Denne konstruksjonen høres ut som kryptografi. Den har ett strukturelt problem: den trenger ecdh_x, den rå x-koordinaten av ECDH-utgangen, som nøkkelmateriale - og en nettleserutvidelse (NIP-07) eller en fjernsigner (NIP-46Det utfører NIP-44 på vegne av den som ringer og returnerer en kryptertekst, som er hele poenget med å holde nøkkelen et sted hvor applikasjonen ikke kan nå.

Lagring fjerner avhengigheten: NIP-44 forblir hel og er produsert av hva som holder identitetsnøkkelen, signer inkludert, mens KEM halvdelen beregnes fra gjenopprettingskoden klienten holder direkte.

Kostnaden er båndbredde, og det er ikke lite. ML-KEM-krypterteksten er 1088 bytes og kjører på hver melding, base64url-kodet til 1,451 tegn; den eksterne AEAD legger til en 16-byte Poly1305-tagg og utvider NIP-44-brukerbelastningen den pakker med en tredjedel. En 50-karakter melding vokser fra 176 bytes til 1,712, og en 2000-karakter en fra 2,820 til 5,238. Gulvet er omtrent 1,5 KB per melding uavhengig av hvor kort meldingen er, som er prisen på innkapsling nylig hver gang i stedet for å gjenbruke en felles hemmelighet.

6.2 Selvbeskrivende payloads

Den pq2. Prefikset gjør distribusjonen inkrementell: det er selvbeskrivende, så en klient velger dekrypteringsbanen ved å inspisere nyttelastet i stedet for ved å stole på et tagg eller huske hva en peer støtter.En leser som ikke gjenkjenner et prefiks mislykkes i å åpne det nyttelastet i stedet for å lese det feil, og meldinger forseglet før hver side kan gjøre post-kvantemelding lesbar som vanlig NIP-44 uten migrasjon.

6.3 Begge lagene av gaveinnpakningen

A NIP-17 Det private budskapet er a NIP-59 Gift Wrap: Et usignert rykte, forseglet under avsenderens identitetsnøkkel (type 13), deretter pakket under en kastet nøkkel generert per melding (type 1059).

En signatorlogg får bare det ytre laget. Seglet produseres av signatoren som vanlig NIP-44 - applikasjonen ser aldri nøkkelen som gjør det - så det kan ikke hybridiseres på plass. Dette koster ingenting mot angrepet i spørsmålet: seglet er bare tilgjengelig gjennom pakningen, og pakningen er hva en opptaker lagrer. En motstander som holder registrert trafikk må bryte ML-KEM før en segl er til og med synlig for å angripe.

7Gruppemeldinger og delvis dekning

Et gruppemelding er ikke en enkle tekst. Det er den samme enkle teksten som sendes ut til hvert medlem, hver kopi innkapslet til medlemmets egen ML-KEM-nøkkel.

Dette skaper et regnskapsproblem at en naiv implementering blir feil.Hvis åtte av ti medlemmer mottar en hybridkopi, er meldingen ikke En motstander trenger en klassisk kopi av en enkel tekst som er identisk i alle ti, så meldingen er beskyttet bare hvis hver eneste Kopi er det.

Nymchat sporer derfor per melding dekning under fan-out - antallet er bare kjennbar mens wraps er bygget - og badge rapporterer “quantum-resistent til 8 av 10 medlemmer” i stedet for å hevde meldingen er beskyttet. mottatt gruppe melding (bare avsenderen teller fan-out), grensesnittet rapporterer delvis i stedet for fullstendig beskyttelse.

7.1 Hva skjoldet rapporterer

Skjoldet forteller sannheten om Budskapet, ikke om programvaren som sendte den:

• Full beskyttelse: Hver kopi av denne enkle teksten gikk ut hybrid.
• Deltakelse: Noen kopier av en gruppes melding gikk ut klassisk. Dratt nedgradert i stedet for fullstendig, fordi en klassisk kopi av en ren tekst identisk i alle av dem er alle en motstander behov.
• Klassisk er uttalt direkte i stedet for vist som ingen badge, fordi en fraværende indikator er tvetydig mellom “ ubeskyttet”, “brutt”, og “denne bygningen mangler funksjonen”.

Cipherteksten som allerede eksisterer, kan ikke bli bedre beskyttet enn det var, og et grensesnitt som revurderte gamle meldinger på styrken til en ny kunngjøring ville hevde noe falskt om bytes på en relay.

Gruppebestemmelsene ovenfor stables på toppen av dette i stedet for å erstatte det: en gruppes melding er fullstendig beskyttet bare når hver medlems kopi var, og en mottatt gruppes melding uten dekning antall viser delvis.

8Kopier adressert til deg selv

Flere ting en klient lagrer er kryptert til brukerens egen identitet: synkroniserte innstillinger, samtale listen, gruppe nøkler, og meldingsarkiv. Disse bærer mer om en bruker enn de fleste enkeltmeldinger gjør, så å forlate dem klassisk ville gjøre dem den svakeste lagrede artefakten uansett hvor nøye meldingene selv ble forseglet. nymchat-pq-root kategorien selv, som ikke kan forsegles under en nøkkel som bare den kan produsere.

En innstilling blob eller en arkiv rad sitter på ett sted i årevis, som er nøyaktig formen av ting en høst-nå-dekryptert-senere motstander samler - langt mer enn noen enkelt melding, som er minst ephemeral i brukerens eget sinn.

En begrensning styrer formatet her i stedet for nøkkelen. hver eneste enheten på kontoen, slik at hver enhet annonserer hva den kan åpne i ruten sin kunngjøring bærer, og kontoen skriver bare hva alle kan lese.

9rotasjon

Den epoch Teller i derivasjonen er det som gjør rotasjon mulig uten nytt nøkkelmateriale. Incrementing det gir et nytt nøkkelpar fra samme rotasjon og en gjenutgitt kunngjøring; peers plukke opp den nye nøkkelen fra den utskiftbare posten.

9.1 Gamle epoker blir bevart, og ingenting blir kryptert på nytt

En klient bygger dekrypteringskandidater fra den nåværende epoken ned til epoken − 3, slik at en melding forseglet kort før en rotasjon fortsatt åpnes mot nøkkelparet som var nåværende da den ble sendt.

Det vinduet er det som gjør rotasjon trygt å gjøre i det hele tatt: Uten det, ville hver rotasjon ødelegge hva som var i fly. Alt allerede forseglet forblir lesbar for livet av identiteten, fordi en melding brukeren ikke lenger kan åpne er strengt verre for dem enn en hvis beskyttelse ikke kan forbedres retroaktivt (Seksjon 10.5).

10Hva dette ikke beskytter

Et papir som bare oppgir hva et design oppnår, beskriver ikke et system, og overvurdering av en sikkerhetsegenskap i et grensesnitt er verre enn å utelate det.

Roten er en annen hemmelighet, og å miste den er uoppnåelig.

Dette er den virkelige prisen på designet. Begrensningen i avsnitt 2 at en bruker skal ha nøyaktig én ting å beholde, kan ikke oppfylles: nsec alene rekonstruerer ikke post-quantum-nøkkelen, fordi hele poenget er at ingen offentlig verdi og ingen annen hemmelighet avslører den. Hvis ingen enhet holder roten og ingen av avsnitt 3.2s wraps kan åpnes, er materiale forseglet til roten-derivert nøkkel ikke gjenopprettes.

Med manuell overføring den eneste banen, er dette skarpere enn det kan først lese. nympq1… koden hvor som helst har nøyaktig en kopi av den, på en enhet, og mister den enheten mister hver post-kvantemelding, innstillinger blob og arkiv rad forseglet til den. nsec Det hjelper ikke; det er eiendommen hele designet hviler på.

En angriper angriper den billigste veien tilgjengelig, så et system er verdt det den svakeste gjenopprettingsruten er verdt - en minneverdig passfrase, for eksempel, ville sette hele tingen på hva passfrasen er verdt, og den innpakkede raden er akkurat gjenstanden en høst-nå-dekryptert-senere motstander samler og maler offline på fritid.

10.2 Autentisering, som skiller seg fra konfidensialitet

Hver signatur i Nostr er Schnorr over secp256k1, og det er uendret her. En motstander med en kvante datamaskin kunne forfalske signaturer og late som en bruker i sanntid. Hva den hybride nøkkelutvekslingen taper er høst-nå-dekryptert-senere: en angriper som registrerer trafikk i dag kan ikke lese den senere. Det gjør ikke en melding uforglemmelig mot en motstander som allerede har maskinen. Denne forskjellen blir brakt inn i applikasjonene bevisst - padlockindikatoren rapporterer autentisering, skjoldet rapporterer konfidensialitet, og de er separate glyfer fordi en melding kan ha en uten den andre.

Bindingen mellom en npub og en ML-KEM-nøkkel er en secp256k1-signatur, så en motstander som kan forge dem kan erstatte en nøkkel av seg selv.

10.3 Metadata

Gift wrapping skjuler avsenderen, mottakeren utover en enkelt p Det skjuler ikke at en hendelse eksisterer, dens størrelse, eller når en relay mottok den.

10.4 Offline mesh

Nymchat's Bluetooth mesh transport er en egen protokoll med sin egen håndtrykk, og det er ikke dekket av dette arbeidet.

10.5 Meldinger som allerede er sendt

Ciphertext registrert mens begge sider var fortsatt klassisk forblir klassisk permanent. Det eksisterer allerede og kan ikke forsegles på nytt. Beskyttelse starter på meldingen hvor begge sider holdt post-kvantetastene, ikke på øyeblikket funksjonen ble slått på.

11Alternative vurderinger

12Paritet i gjennomføringen

Nymchat leverer to uavhengige implementeringer av denne konstruksjonen - en i JavaScript for webapplikasjonen, en i Dart for mobilapplikasjonene, inkludert en fra bunnen av ML-KEM-768 port.

Dart ML-KEM implementering er validert mot den offisielle NIST ACVP Kunnskaps- og svarstester for ML-KEM-768 (ML-KEM-*-FIPS203Dette er vektorene NIST publiserer for å validere en implementering, så passere dem er bevis på at porten er riktig, ikke bare bevis på at de to klientene er enige med hverandre.Over det, en delt fixture av testvektorer - frø derivasjon, encapsulation, både nyttelast formater, og komplette gave wraps - er generert fra JavaScript referanse og sjekket av begge test suites. Root hemmelighet utvider denne fixture i stedet for å erstatte den: rot til frø, rot til nøkkelpar, rotens offentlige fingeravtrykk, og den avledede nøkkelen, nonce og tilknyttede data av det ytre laget er vektorer av seg selv, så de to klientene kan ikke være uenige om hva en nympq1… En avvik i begge implementeringer svikter byggingen i stedet for å produsere en melding den andre klienten ikke kan åpne.

Det er det som forteller en enhet “dette er roten jeg holder” fra “dette er en annen én”, og en klient som ikke kunne reprodusere en annen klients fingeravtrykk ville lese en perfekt god rekord som ingen rekord i det hele tatt - og deretter, etter avsnitt 3.3, mynte en annen rot og splitte identiteten.