Nymchat technikai whitepaper

Post-Quantum kulcsmegállapodás a Nymchatben

Az ML-KEM-768 nyilvános kulcsok szétosztása a Nostr felett könyvtár vagy nyilvántartás nélkül, és egy olyan titokból való vetés, amelyet semmilyen nyilvános érték nem tár fel.

A posztkvantum kulcscsere hozzáadása egy üzenetküldőhöz többnyire nem kriptográfiai probléma.A primitívek szabványosítva vannak, és a könyvtárak léteznek.A nehéz rész az, hogy minden résztvevőnek most szüksége van egy Második Ez a dokumentum leírja, hogy a Nymchat hogyan válaszol erre - honnan származik a második kulcs, hogyan jut el azokhoz, akiknek szüksége van rá, és mit kérhet az interfész az eredményről - és az utolsó szakaszban, hogy mi az eredmény nem védi.

Ez az oldal a kényelem kedvéért gépi fordítással készült. Az eredeti angol nyelvű változat az érvényes.

1A probléma

Privát üzeneteink titkosítva vannak NIP-44, amelynek két elválasztható fele van. A fele, amely a tiszta szöveget – a ChaCha20-at egy HMAC-SHA256 címkével, kulcsszavakkal A HKDF (Az RFC 5869) - nem jelent jelentősen fenyegeti a kvantumszámítógép; Grover algoritmusa egy szimmetrikus billentyűvel szemben egy négyzetgyökeres gyorsulást tesz lehetővé, és 256 bit elnyeli azt. Egyetértek Az elliptikus görbe Diffie-Hellman Székesfehérvár256k1, és Shor algoritmusa megoldja a diszkrét logaritmust. Egy privát kulcs visszahívása a nyilvános társaitól visszamenőlegesen feltárja minden olyan közös titkot, amelyet a kulcs valaha készített.

A fenyegetés, amit ez hoz létre, addig nem halasztódik el, amíg egy ilyen gép létezik. A tárolóval rendelkező ellenfél ma rögzítheti a titkosított szöveget, és visszafejti azt, amikor a képesség megérkezik. Bármi, ami most elküldik, ami még mindig számít, akkor már kompromittálva van. Ez a konkrét támadás egy poszt-kvantum kulcscserét legyőz, és ez az oka annak, hogy a munka nem várhat a gép építésére.

1.1 A kérdésekre a könyv válaszol

A mérséklés jól érthető: a klasszikus csere mellett poszt-kvantum kulcs encapsulációs mechanizmust futtat, így a támadónak mindkettőt meg kell szakítania, hogy bármit elolvasson.Fülszöveg 203Ez azonnal felvet egy elosztási problémát:

Egy npub önellátó. Papíron írhatja, hangosan elolvashatja, vagy egy képernyőről beolvashatja, és mindenkinek szüksége van titkosításra az Ön számára.Az ML-KEM-768 nyilvános kulcs 1,184 bájt. Nem olvasható hangosan, nem illeszkedik egy felhasználónévbe, és nem tartozik egy QR-kódhoz egy azonosító mellett, amely csak 32 bájt.

A nehezebb rész az, hogy egy második kulcs három különböző problémát hoz, és a papír többi része nagyrészt válasz rájuk:

• Ez helyettesíthető. Egy kulcs, amit senki sem tudja egy pillantásra elolvasni, pontosan az a fajta dolog, amit a támadó saját maga cserél.
• Meg kell egyezni a felhasználó eszközein. Ugyanaz a számla egy telefonon és egy laptopon ugyanazt a kulcsot kell bemutatnia, vagy az egyikre lezárt üzeneteket a másikra nem lehet megnyitni.
• Ez elveszhet. A nyilvános kulcsot egy titokból újra kiadják, így valójában csak ennek a titknak kell fennmaradnia - és építéssel semmi más nem rekonstruálja azt.

2Design korlátozások

Négy korlátozás formálta a választ, és kizárják a legtöbb nyilvánvaló tervet, mielőtt bármilyen kódot írnának.

1. Minél kevesebb titok. Minden további titok egy másik módja annak, hogy elveszítse a történelmet, és valaki, aki tudja, hogy mentse az nsec nem fog tudni, hogy mentse bármi mást. szakasz 3.1 azt mutatja, hogy ez az egyik nem lehet teljesíteni közvetlenül – egy poszt-kvantum kulcs származó az nsec nem nyújt poszt-kvantum védelmet egyáltalán – így a tervezés tölti pontosan egy titkot, és nem több: egy darab kulcs anyag, generált egyszer egy identitás, bemutatott ugyanabban a formában, mint az nsec és ugyanazon a helyen, így aki tudja, hogyan kell tartani az egyik tudja, hogyan kell tartani a másik.
2. Semmilyen hatóság. Nincs olyan szerver, amelyben megbízhatnánk, hogy megmondja, melyik kulcs kinek tartozik.
3. Több eszköz, egy identitás Bármilyen kulcsfontosságú anyag létezik, mindegyikükön azonosnak kell lennie, és az azt hordozó ösvények nem lehetnek olvashatóak az ellenfél számára, akivel szemben a funkció véd.
4. Nem a tárgyalás. A “mely titkosítókat támogatod?” bármilyen csere a sávban egy olyan felület, amelyet a támadó a gyengébb opciót kényszerítheti.

3Független gyökér titok

A terhelést hordozó döntés az, hogy az ML-KEM decapsulációs kulcsot olyan kulcsanyagból vetik ki, amely nem tárja fel a nyilvános értéket.

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)

A gyökér úgy jelenik meg a felhasználónak, ahogyan egy nsec: Székesfehérvár 32 Az emberileg olvasható előtag nympqEzért úgy olvasható, mint nympq1…, amely az azonosító képernyőn az nsec mellett jelenik meg ugyanazon felfedi interakció mögött, ugyanazzal a vezérlővel másolva, soha nem jelentkezett be, és soha nem küldött sehol a világosban. Ez nem jelszó, és nem bejelentkezés.

A sót szándékosan elkülönítik, így egyetlen más titok sem származhat ugyanabból a kulcspárból. epoch A csővezeték meghajtása (9. szakasz)

3.1 Miért nem származhat a kulcs a személyazonossági kulcsból

A nyilvánvaló tervezés az, hogy a billentyűparot a felhasználó már meglévő titkából vetjük:

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

Négy okból vonzó, mindegyik valódi: semmi újat nem kell menteni, mert az nsec már a biztonsági mentés; minden eszköz, amely beleegyezik az építésbe, anélkül, hogy a szinkronizációs protokoll helytelen lenne; egy helyettesíthető bejelentés identitásonként nyilvánvalóan helyes, mert az eszközök nem tudnak ellentmondani a kulcsnak; és a kulcs, amely még a közzététele előtt létezik, így az ügyfél először elzárhat valamit magának.

Mind a négy előnye értéktelen, egy okból. A Shor algoritmusa egy közzétett npub ellen fut, ami az nsec-t eredményezi. A vetőmag-származás egy nyilvános algoritmus az nsec felett. Így az ellenfél, aki megszakítja a klasszikus felét, újjáépíti a poszt-kvantum felét, ugyanazt a HKDF-t futva, amelyet mindenki más fut. A betakarítás-most-decrypt-később ellen - az egyetlen fenyegetés, hogy a funkció megáll - egy ilyen módon származó kulcs semmit sem ad hozzá.

Egy önállóan generált titok, amely egy szokásos NIP-44 üzenetben a felhasználó eszközei között szinkronizálódik, ugyanaz a hiba, további lépésekkel: az ellenfél ma rögzíti az üzenetet, és később visszanyeri a klasszikus kulcsot, és a gyökér kiesik.

3.2 A gyökér elérése a felhasználó más eszközeire

A 2. szakasz 3. korlátozása – egy identitás, több eszköz – itt nem lehet aritmetikával kielégíteni, mert a lényeg az, hogy a kulcs nem a már megosztott eszközök egyik funkciója. nympq1… saját maga kódolja.

A gyökerek úgy jelennek meg, mint nympq1… az nsec mellett, és egy második eszköz elfogadja, hogy ugyanazon a panelen illessze be. Ez az egész mechanizmus.

A 3.1. szakaszban szereplő szabály szerint a gyökér soha nem utazhat a klasszikus, csak titkosítás alatt, és minden mechanizmus, amely ezt automatikussá tenné – szinkronizálva azt egy relén keresztül, csomagolva az identitási kulccsal – pontosan ezt sérti.

A formátum helyet hagy egy csomagolt utat: egy rekord tartalmazhat egy listát a csomagolások, mindegyik egy AEAD blob alatt egy kulcs, a felhasználó reprodukálhatja egy másik eszköz - egy passkey PRF kimenet, például. nympq1… A 10.1 pontban meg van határozva, hogy mennyibe kerül.

A rekord maga a saját beállítási kategóriájában él, nymchat-pq-rootMég akkor is, ha nincs csomagolás, szükséges munkát végez: jelenléte az, ahogyan egy második eszköz megtanulja, hogy ennek az identitásnak már van gyökere, ami megakadályozza, hogy egy versenytársra gondoljon (3.3. szakasz).

3.3 Generáció és örökbefogadás

A bootnál, tartós identitással, az ügyfél a következő sorrendben működik:

1. Keresse meg a meglévő nymchat-pq-root A rekordot.
2. Megtalált rekord, és ez a készülék feloldhatja - fogadja el, és ezt az identitást post-kvantum képességként hirdeti.
3. Megtalált rekord, és ez a készülék nem tudja feloldani - ne hozzon létre új gyökeret, és egyáltalán ne tegyen közzé semmilyen hirdetést. nympq1… egy olyan eszközről, amely már rendelkezik vele.
4. Nincs rekord - generáljon egy gyökeret, tegye közzé a rekordot, jelentse be és mutassa meg a nympq1… A felhasználó csak egyszer adja meg a kódot, hogy megmenthesse.

A 3. lépés az a lépés, amely könnyen tévedhet, és ez az oka annak, hogy a sorrendet leírják, nem pedig minden egyes megvalósításra hagyják.Két eszköz, amelyek mindegyike úgy dönt, hogy gyökeret hoz létre, két független gyökeret hoz létre egy identitás alatt, és ez a hiba, hogy ez a sorrend megakadályozza.

4A képességek bejelentése

A származékos kulcspár nyilvános fele címezhetőként kerül közzétételre Férfiak-01 esemény – típus 30078, címkézett 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": [ ... ]
  }
}

A címezhető azt jelenti, hogy a relé megtart egy eseményt (kind, pubkey, d-tag), így a köztársaság helyettesíti az előző bejelentést.

Az aláírás kötelező. Az eseményt az identitási kulcs írja alá, így az állítás “ez az ML-KEM kulcs ehhez az npub-hoz tartozik” pontosan olyan erős, mint maga az npub. Egy másik encapsulációs kulcs helyettesítése megköveteli a secp256k1 aláírás kovácsolását.

A bejelentések lejártak. Hétnapos NIP-40 A 24 óránként újra közzétett lejárati idő egy olyan kliensről szóló nyilatkozatot rögzít, amely még mindig fut, nem pedig azt, amely korábban volt.

Egy kihagyott bejelentés pontosan úgy olvasható, mint egy olyan, amely soha nem hordozott kulcsot: a társaik rendszeres NIP-44-et küldenek, amelyet minden bejelentkezés elolvashat, és az ügyfél folytatja a poszt-kvantum cserét a következő kapcsolatán, amikor újra közzéteszi.

Ez az aszimmetria a lejárat oka, nem pedig a véletlen. egy rekord meghaladja az általa megnevezett kulcsot: egy eszköz, amelyet törölnek, visszaállítanak, vagy a gyökere helyettesít, állandó utasítást hagy egy kulcsra, amelyet senki sem tart többé, és az alatta elküldött üzeneteket mindkét oldalon hiba nélkül elveszítik. hét nap korlátozza ezt az ablakot, és lehetővé teszi a továbbítók számára, hogy maguk dobják a rekordot, ahelyett, hogy az ügyfelekre támaszkodnának.

A kulcsszó mező nevezi a formátumot. A mező az pk2, és a számjegy a szerződés részét képezi, nem pedig a díszítést: megnevezte a használati terhelés formátumát, amellyel a kulcs használható. Az olvasó, aki nem ismeri fel a mezőt, befejezi a "Nymchat kliens, nincs poszt-kvantum kulcs", és elküldi a szokásos NIP-44-et, amelyet minden bejelentkezés elolvashat. Ez a helyes hibairány, és érdemes megemlíteni, mint a szabály a formátum számlálása létezik érvényesíteni: az el nem ismerett képesség követelése védelmet igényel, soha nem szállít. Egy kulcs, amelyet a társa nem tud használni, rosszabb, mint egyáltalán nincs kulcs, mert az üzenet, amelyet termel, mindkét oldalon hiba nélkül elveszett.

4.1 A hiányzás értelmes, és hármas értékű

Egy finom, de fontos részlet: a bejelentést minden Nymchat kliens közzéteszi, nem csak a poszt-kvantum-képesek, és a kulcsterület opcionális.

A kulcs nélküli bejelentés egy aláírt nyilatkozat, hogy a feladó fut Nymchat, amely lehetővé teszi, hogy a küldő út átugorjon egy spekulatív keresztprotokoll csomagolás, amelyet máskülönben mindenkinek magában kell foglalnia, aki nem tudja azonosítani.

4.2 Az a készülék, amely nem tudja megnyitni a gyökeret, hallgat.

A bejelentés helyettesíthető: egy esemény identitásonként, az utolsó írást nyert.Ez az, ami az egyszeri rekordtervezést működteti, és ez is az, ami veszélyesvé teszi a nem kapcsolódó eszközt, ha közzéteszi.Egy olyan eszköz, amely bejelentette, hogy egy kulcsot hozott létre magának, megbotránkoztatja a valódi rekordot, és minden társat egy olyan kulcs alatt titkosít, amelyet más eszközök nem tudnak megnyitni.

Tehát egy olyan eszköz, amely ismeri a gyökeret, de nem tudja megnyitni, egyáltalán nem tesz közzé hirdetést.Nem törik, és nem záródik ki az alkalmazásból: még mindig elolvassa az összes üzenetet, amelyhez a kulcsok vannak, és továbbra is klasszikusan küldi, miközben arra ösztönzi a felhasználót, hogy összekapcsolja azt.

5A felfedezés és a küldés döntése

Az ügyfelek kétféleképpen tanulják meg a társaik kulcsait.Az állandó előfizetés magában foglalja azokat az embereket, akikkel a felhasználó valójában egyeztet – nyílt beszélgetések és csoporttagok – így az értesítéseik hétköznapi eseményekként érkeznek.Egy társaik találkozása során először egy egyszeri lekérdezés fut a küldés idején, 2,5 másodpercre korlátozva; ha nem oldja meg, az üzenet klasszikus lesz, ami a poszt-kvantum hozzáadása előtt létezett viselkedés, nem pedig egy új hiba mód.

A felhasználó, aki összekapcsolja az új eszközt, vagy aki a böngészőbővítmény bejelentkezéséről egy helyi kulcsra költözik, poszt-kvantum képessé válik a beszélgetés közepén, és egy állandóan gyorsítótárban “no” tartja őket a klasszikus titkosításon a hirdetés élettartama alatt.

5.1 Miért nincs downgrade támadás

Az útválasztási döntés egyetlen kérdésre korlátozódik:

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

Nincs képesség-tárgyalás, nincs támogatott algoritmusok listája, és nincs olyan mező, amelyben a támadó egy gyengébb utat kényszeríthetne. van A kihagyott vagy visszatartott hirdetés hiba módja az, hogy az üzenet klasszikus lesz - a funkció előtti status quo - ahelyett, hogy a hibrid üzenetet valamilyen megtéveszthetőnek minősítenék.

A fordított is megtartja és fontosabb: egy ügyfél hibridet küld Csak Amikor egy kulcsot tart, és a kulcs megtartása bizonyíték arra, hogy a címzett felkapcsolhatja.Nincs olyan állapot, amelyben egy üzenetet post-kvantum módon küldenek valakinek, aki nem tudja elolvasni.

6Hibrid építkezés

A nem módosított NIP-44 kódolási szöveg a belső réteg, és az ML-KEM egy külső AEAD-t nyithat meg körülötte:

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)

Mindkét titkot újra kell találni az üzenet elolvasásához: a külső réteg csak NIP-44 kódolási szöveget ad, és a nyílásnak szüksége van a klasszikus ECDH-re.A kvantumellenes, aki megszakítja a secp256k1-et, megkapja a belső kulcsot, és még mindig szembesül az ML-KEM-vel; az ML-KEM szakadása megszorítja a külső réteget, és hagyja NIP-44-et állva.

• kem_ss Semmi ebben a származékban nem érinti a nyers ECDH kimenetét, ami a 6.1 szakaszban történik.
• kem_ct, recip_kem_pk Mindkét identitási kulcs kapcsolódik a kapcsolódó adatokhoz, így a külső réteg a pontos átirathoz kötődik, amely létrehozta azt.

A címzett ML-KEM kulcsa hosszú élettartamú, de minden üzenet hordoz egy független titkosított szöveget és ezért egy független titkosított szöveget. kem_ssEz az, ami miatt a nonce származik, nem pedig véletlenszerűen hangzik: Székesfehérvár20-Poly1305 Egy (kulcs, nonce) pár újrafelhasználásával megszakad, és itt maga a kulcs minden üzenet esetében új, így egyetlen pár sem ismételhető meg.

6.1 Miért maradnak külön a rétegek

Az alternatíva az, hogy keverjük össze mindkét titkot egyetlen beszélgetési kulcsba, és adjuk át a NIP-44-nek:

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

Ez a szerkezet úgy hangzik, mint a kriptográfia. Van egy strukturális probléma: szüksége van rá. ecdh_x, az ECDH kimeneti nyers x-koordinátája kulcsfontosságú anyagként - és a böngésző kiterjesztése (NIP-07) vagy egy távoli aláíró (NIP-46A hívó nevében végrehajtja a NIP-44-et, és visszaadja a titkosított szöveget, ami a kulcs tartásának teljes pontja, ahol az alkalmazás nem érheti el.

A titkok összekeverése tehát kizár minden olyan bejelentkezést, amely az azonosító kulcsot egy aláíróban tartja, vagyis a legelővigyázatosabb felhasználókat, és a kulcs származékán végzett munka nem változtathatja meg. A rétegezés eltávolítja a függőséget: az NIP-44 egész marad, és azt az előállítja, ami az azonosító kulcsot, az aláírót is magában foglalja, míg a KEM felét a kliens által közvetlenül tartott helyreállítási kódból számítják ki.

A költség a sávszélesség, és ez nem kicsi. Az ML-KEM titkosítószöveg 1,088 bájt, és minden üzenetre fut, base64url-kódolva 1,451 karakterre; a külső AEAD hozzáad egy 16 bájtos Poly1305 címkét, és egy harmadával bővíti az NIP-44 haszonterhelését. Egy 50 karakteres üzenet 176 bájtról 1,712-re nő, és egy 2000 karakteres egy 2,820-ról 5,238-ra.

6.2 Önállóan leírható payloads

A pq2. Az előtag fokozatosabbá teszi a telepítést: önmagát írja le, így az ügyfél kiválasztja a dekódolási utat azáltal, hogy megvizsgálja a hasznos terhelést, nem pedig úgy, hogy megbízik egy címkén, vagy emlékezik arra, amit a társa támogat.Az olvasó, aki nem ismeri fel az előtagot, nem tudja megnyitni azt a hasznos terhelést, hanem rosszul olvassa el, és a mindkét oldal előtt lezárt üzenetek a kvantum utáni üzeneteket a szokásos NIP-44-hez hasonlóan olvashatók lehetnek, migráció nélkül.

6.3 Az ajándékcsomag mindkét rétege

A NIP-17 A privát üzenet a NIP-59 ajándékcsomag: aláíratlan pletyka, amelyet a feladó személyazonossági kulcsa alá zárnak (13 típus), majd üzenetenként generált dobható kulcs alá csomagolnak (1059 típus). Egy olyan bejelentkezésen, amely közvetlenül a személyazonossági kulcsot tartja, a Nymchat hibridizálja mindkét réteget, mindegyik saját encapsulációval.

Az aláíró bejelentkezése csak a külső réteget kapja meg. A pecsétet az aláíró a szokásos NIP-44-ként állítja elő – az alkalmazás soha nem látja a kulcsot, amely ezt teszi – így nem hibridizálható a helyén. Ez nem kerül semmibe a szóban forgó támadás ellen: a pecsét csak a csomagoláson keresztül érhető el, és a csomagolás az, amit egy felvevő tárol. Az ellenfélnek, aki rögzített forgalmat tart, meg kell szakítania az ML-KEM-t, mielőtt a pecsét még láthatóvá válna a támadáshoz.

7Csoportos üzenetek és részleges lefedettség

A csoportüzenet nem egy titkosított szöveg. Ez ugyanaz az egyszerű szöveg, amelyet minden tagnak ki kell küldeni, minden másolat az adott tag saját ML-KEM kulcsa. Az a tag, aki közzétett egy kulcsot, hibrid csomagolást kap; az, aki nem kap klasszikus csomagolást.

Ez számviteli problémát okoz, hogy egy naiv végrehajtás hibás. Ha tíz tagból nyolc hibrid másolatot kap, az üzenet nem Az ellenfélnek szüksége van egy klasszikus példányára egy egyszerű szövegre, amely mind a tízben azonos, így az üzenet csak akkor védett, ha minden Ez a kopia.

A Nymchat ezért nyomon követi az üzenetenkénti lefedettséget a fan-out során - a szám csak akkor ismert, amikor a csomagolások épülnek - és a jelzőtábla jelentései “quantum-rezisztens 8 a 10 tagból” ahelyett, hogy azt állítaná, hogy az üzenet védett. Elfogadott csoportos üzenet (csak a feladó számít a rajongó), az interfész részleges, nem pedig teljes védelmet jelent.

7.1 Mit jelent a pajzs

A pajzs az igazságot mondja Üzenet, nem a szoftverről, amely elküldte:

• Teljes körű védelem: ennek a szövegnek minden példánya hibrid lett.
• Részleges: egy csoport üzenetének néhány példánya klasszikusan jött ki. A csoport üzenetének egy klasszikus példánya, amely mindegyikben azonos, degradált, nem pedig teljes, mivel mindegyiküknek szüksége van az ellenfélre.
• A klasszikus kifejezés közvetlenül jelenik meg, nem pedig jelölésként, mert egy hiányzó mutató kétértelmű a “nem védett”, “törött” és “Ez az építés nem rendelkezik a funkcióval”.

Az ítélet akkor kerül rögzítésre, amikor az üzenetet lezárják, nem pedig azt, amit a társa később reklámozik.A már létező titkos szöveget nem lehet jobban védeni, mint korábban volt, és egy olyan felület, amely a régi üzeneteket újragondolja egy új hirdetés erejével, hamisnak bizonyulna a relé bajtjairól.

A fenti csoportos szabályok a helyettesítés helyett a tetején vannak: a csoportos üzenet csak akkor teljes mértékben védett, ha minden tag másolata volt, és a beérkezett csoportos üzenet, amelynek nincs lefedettsége, részleges.

8Saját magadnak címzett másolatok

A kliens tárol több dolgot a felhasználó saját személyazonosságára titkosítva: a szinkronizált beállításokat, a beszélgetéslistát, a csoportbillentyűket és az üzenetarchívumot. Ezek többet hordoznak egy felhasználóról, mint a legtöbb egyedi üzenet, így hagyva őket klasszikusnak, a leggyengébb tárolt tárgyakká válnak, függetlenül attól, hogy az üzeneteket milyen óvatosan lezárták. nymchat-pq-root Olyan kulcsszó alatt nem lehet lezárni, amit csak ő tud előállítani.

A beállítások blob vagy archívum sor ül egy helyen éveken át, ami pontosan az a forma, amit egy termés-most-decrypt-később ellenfél gyűjt - sokkal több, mint bármely egyetlen üzenet, amely legalább a felhasználó saját elméjében.

Egy korlátozás szabályozza a formátumot itt, nem pedig a kulcsot. minden Az eszköz a fiókban van, így minden eszköz azt reklámozza, amit megnyithat a hirdetésében, és a fiók csak azt írja le, amit mindannyian el tudnak olvasni.

9rotáció

A epoch A származási számláló az, ami lehetővé teszi a forgást új kulcsanyag nélkül. A növekedés egy friss kulcspárt eredményez ugyanabból a gyökerből és egy újra közzétett bejelentésből; a társaik felveszi az új kulcsot a helyettesíthető rekordból.

9.1 A régi korszakok megmaradnak, és semmi sem re-titkolódik

Egy kliens létrehoz egy titkosítási jelöltet a jelenlegi korszakból a 3 korszakig, így egy üzenet, amelyet röviddel a forgatás előtt lezárt, még mindig megnyílik az aktuális kulcspár ellen, amikor elküldték.

Ez az ablak teszi a forgást teljesen biztonságossá: nélküle minden forgás elpusztítaná a repülést.Minden, ami már lezárt, olvasható marad az identitás életében, mert egy olyan üzenet, amelyet a felhasználó már nem tud megnyitni, szigorúan rosszabb számukra, mint az, amelynek védelmét nem lehet visszamenőleg javítani (10.5. szakasz).

10Amit ez nem védi

Egy papír, amely csak felsorolja, hogy mit ér el egy design, nem ír le egy rendszert, és egy biztonsági tulajdonság túlbecsülése egy interfészben rosszabb, mint kihagyni.

10.1 A gyökér egy második titok, és elveszíteni nem lehet.

Ez a tervezés valódi ára. A 2. szakaszban szereplő korlátozás, miszerint a felhasználónak pontosan egy dolgot kell megőriznie, nem teljesíthető: az nsec önmagában nem rekonstruálja a poszt-kvantum kulcsot, mert a lényeg az, hogy nincs nyilvános érték és nincs más titok, amely feltárná. Ha egyetlen eszköz sem tartja a gyökeret, és a 3.2. szakasz egyik borítóját sem lehet kinyitni, a gyökéralapú kulccsal lezárt anyag nem visszaszerezhető.

A kézi átvitel az egyetlen útvonal, ez élesebb, mint az első alkalommal olvasható. nympq1… A kódnak mindenhol pontosan egy példánya van, egy eszközön, és ha elveszíti ezt az eszközt, elveszíti az összes posztkvantum üzenetet, a beállításokat és az archívumsorokat. nsec nem segít; ez az a tulajdonság, amelyre az egész design támaszkodik.

A támadó a rendelkezésre álló legolcsóbb utat támadja meg, így egy rendszer megéri a leggyengébb helyreállítási útvonal értékét - például egy emlékezetes jelszó az egészet az adott jelszó értékére helyezi, és a csomagolt sor pontosan az a lelet, amelyet egy termés-most-decrypt-későbbi ellenfél összegyűjti és önt offline szabadidőben.

10.2 Hitelesítés, a titoktartástól eltérően

Minden aláírás a Nostr-ban Schnorr a secp256k1 felett van, és ez itt változatlan. A kvantumszámítógéppel rendelkező ellenfél aláírásokat hamisíthat és valós időben felhasználót ábrázolhat. Ami a hibrid kulcscserét legyőzi, az a betakarítás-most-decrypt-később: egy támadó, aki ma rögzíti a forgalmat, nem tudja később elolvasni. Ez nem teszi az üzenetet megbocsáthatatlanná egy olyan ellenfél ellen, aki már rendelkezik a géppel. Ezt a megkülönböztetést szándékosan hajtják végre az alkalmazásokban - a padlock indikátor hitelesítést jelent, a pajzs titoktartást jelent, és ezek különálló glyphek, mert egy üzenet egymás nélkül is

A kötődés egy npub és egy ML-KEM kulcs között egy secp256k1 aláírás, így az ellenfél, aki meg tudja hamisítani azokat, helyettesítheti a saját kulcsát.

10.3 Metadatok

Az ajándékcsomagolás elrejti a küldőt, a címzettet egy p A belső üzenet címkéje, típusa és időbélyege. Nem rejti el, hogy egy esemény létezik, annak mérete, vagy amikor egy közvetítő megkapta.

10.4 Az offline hálózat

A Nymchat Bluetooth Mesh Transport egy különálló protokoll, saját kézfogással, és nem tartozik ebbe a munkába.

10.5 Már elküldött üzenetek

Ciphertext rögzített míg mindkét oldalon még mindig klasszikus marad klasszikus állandóan. Ez már létezik, és nem lehet újra pecsételni. A védelem kezdődik az üzenet, ahol mindkét oldalon tartott poszt-kvantum kulcsok, nem abban a pillanatban a funkció bekapcsolták.

11Megvizsgált alternatívák

12Végrehajtási paritás

Nymchat szállít két független megvalósítások ezt a konstrukciót – az egyik a JavaScript a webes alkalmazás, egy Dart a mobil alkalmazások, beleértve a végétől származó ML-KEM-768 port. Két megvalósítások ugyanaz a primitív általában egy felelősség, így vannak kötve egymás ellen, ahelyett, hogy megbízható, hogy egyetértenek.

A Dart ML-KEM végrehajtása a hivatalos Az ACVP Hasonlóképpen, ha az MSZP-re vonatkozó követelményeknek megfelelően (ML-KEM-*-FIPS203) – 25 kulcsgeneráció, 25 encapsuláció és 10 decapsuláció esetek, saját csomagként futnak. Ezek azok a vektorok, amelyeket a NIST közzétesz egy végrehajtás érvényesítésére, így átadásuk bizonyíték arra, hogy a port helyes, nem pusztán bizonyíték arra, hogy a két ügyfél egyetért egymással. Ezen túlmenően a tesztvektorok közös rögzítése – a vetőmag-származás, az encapsuláció, mind a haszonterhelési formátumok, mind a teljes ajándékcsomagok – a JavaScript-referenciából származik, és mindkét tesztcsomag ellenőrzi őket. A gyökértitok kiterjeszti ezt a rögzítést ahelyett, hogy helyettesítené azt: gyökér a mag, gyök nympq1… Az eltérés mindkét megvalósításban meghiúsítja az építést, nem pedig olyan üzenetet hoz létre, amelyet a másik ügyfél nem tud megnyitni.

Az ujjlenyomatot érdemes megnevezni ezek között. Ez az, ami azt mondja, hogy egy eszköz “ez a gyökér, amit tartok” a “ez egy másik, és egy ügyfél, aki nem tudta reprodukálni egy másik ügyfél ujjlenyomatát, tökéletesen jó rekordot olvasna, mint egyáltalán nincs rekord - majd a 3.3. szakasz után, mint egy második gyökér és osztja meg az identitást.