Nymchat whitepaper tècnic

Acord clau postquàntic a Nymchat

Distribuir les claus públiques ML-KEM-768 a través de Nostr sense un directori o un registre, i sembrar-les d'un secret que cap valor públic exposa.

Afegir un intercanvi de claus post-quantum a un missatger no és en gran part un problema de criptografia. Els primitius estan estandarditzats i les biblioteques existeixen. Segona Aquest document descriu com Nymchat respon a això —d’on prové la segona clau, com arriba a les persones que la necessiten, i què es permet a la interfície reclamar sobre el resultat— i, en l’última secció, què no protegeix aquest resultat.

Aquesta pàgina està traduïda automàticament per comoditat. L'original en anglès és la versió que s'aplica.

1El problema

Els nostres missatges privats són xifrats amb NIP-44, que té dues meitats separables. La meitat que escurça el text pla — ChaCha20 amb una etiqueta HMAC-SHA256, clau a través HKDF (RGPD 5869) — no està significativament amenaçat per un ordinador quàntic; l'algorisme de Grover costa una acceleració quadrada-arrel contra una clau simètrica, i 256 bits absorbeixen això. Acceptació sobre la clau és el·líptica-curva Diffie-Hellman sobre Càtedra 256K1Recuperar una clau privada de la seva contrapart pública retroactiva exposarà cada secret compartit que la clau hagi produït.

L'amenaça que això crea no és posposada fins que existeixi una màquina com aquesta. Un oponent amb emmagatzematge pot enregistrar text xifrat avui i desxifrar-lo quan arribi la capacitat. Tot el que s'envia ara que encara importa llavors ja està compromès. Aquest és l'atac específic que un intercanvi de claus post-quantum derrota, i és per això que el treball no pot esperar que la màquina es construeixi.

1.1 La pregunta que respon aquest document

La mitigació és ben entesa: executeu un mecanisme d'encapsulació de clau postquàntica al costat de l'intercanvi clàssic, de manera que un atacant ha de trencar els dos per llegir qualsevol cosa.Càmping 203Això planteja immediatament un problema de distribució:

Un npub és autònom.Pots escriure'l en paper, llegir-lo en veu alta, o escanejar-lo des d'una pantalla, i és tot el que tothom necessita per xifrar-te.Una clau pública ML-KEM-768 és de 1.184 bytes.No es pot llegir en veu alta, no encaixarà en un nom d'usuari, i no pertany a un codi QR a més d'una identitat que només té 32 bytes.

La part més difícil és que una segona clau porta tres problemes diferents, i la resta d'aquest paper és en gran mesura una resposta a ells:

• Es pot substituir. Una clau que ningú pot llegir a simple vista és exactament el tipus de cosa que un atacant intercanvia per la seva pròpia.
• Ha de coincidir a través dels dispositius d'un usuari. El mateix compte en un telèfon i un ordinador portàtil ha de presentar la mateixa clau, o els missatges segellats a un no es poden obrir a l'altre.
• Es pot perdre. La clau pública es republica d'un secret, de manera que el que realment ha de sobreviure és aquest secret - i per construcció res més la reconstrueix. Secció 10.1 estableix clarament el que costa, perquè aquest no es resol tant com pagat per.

2Condicions de disseny

Quatre restriccions van donar forma a la resposta, i exclouen la majoria dels dissenys evidents abans que es escrigués qualsevol codi.

1. El mínim possible de secrets. Els nostres usuaris ja porten exactament un secret, el nsec. Cada secret addicional és una altra manera de perdre el seu historial, i algú que sap fer backup d'un nsec no sabrà fer backup de res més. Secció 3.1 mostra que aquest no es pot complir directament -una clau post quàntica derivada del nsec no proporciona cap protecció post quàntica en absolut - de manera que el disseny gasta exactament un secret i no més: una sola peça de material clau, generada una vegada per identitat, presentada en la mateixa forma que el nsec i en el mateix lloc, de manera que qui sap com mantenir una sap com mantenir l'altra. Secció 10.1 és honest sobre el que encara costa.
2. Sense cap autoritat. No hi ha cap servidor que es pugui confiar per dir quina clau pertany a qui.
3. Múltiples eines, una sola identitat. Qualsevol material clau que existeixi ha de ser idèntic en tots ells, i els camins que el porten no han de ser legibles per l'oponent contra el qual la funció està defensant.
4. No hi ha negociació. Qualsevol intercanvi en banda de “quins xifres donen suport?” és una superfície que un atacant pot retallar per forçar l'opció més feble.

3Un secret arrel independent

La decisió de càrrega és que la clau de decapsulació ML-KEM està sembrada a partir de material clau que cap valor públic exposa.

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)

L'arrel es presenta a l'usuari de la manera en què un nsec és: Bàsquet 32 Amb el prefix humà llegible nympqPer això es llegeix com nympq1…, mostrat al costat del nsec a la pantalla d'identitat darrere de la mateixa interacció revelar, copiat amb el mateix control, mai connectat i mai enviat enlloc en el clar.

La sal està separada del domini amb propòsit, de manera que cap altre secret mai pot derivar el mateix parell de claus. epoch Conducció de la rotació (secció 9).

3.1 Per què la clau no es pot derivar de la clau d'identitat

El disseny òbvi és sembrar el teclatparell del secret que l'usuari ja té:

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

És atractiu per quatre raons, totes reals: res de nou per fer backup, perquè el nsec ja és el backup; cada dispositiu que accepta per construcció, sense protocol de sincronització per anar malament; un anunci reemplaçable per identitat sent òbviament correcte, perquè els dispositius no poden discrepar sobre la clau; i la clau existent abans que mai es publiqui, de manera que un client pot segellar alguna cosa a si mateix en primera instància.

Tots els quatre beneficis són inútils, per una raó. L'algorisme de Shor que s'executa contra un npub publicat dóna el nsec. La derivació de llavors és un algorisme públic sobre el nsec. Així que l'adversari que trenca la meitat clàssica reconstrueix la meitat post-quàntica executant el mateix HKDF que tothom fa. Contra la collita-ara-desxifrat-després -l'única amenaça que existeix la funció per aturar- una clau derivada d'aquesta manera no afegeix res.

Una secreció independentment generada que després es sincronitza entre els dispositius d'un usuari dins d'un missatge NIP-44 ordinari és el mateix error amb passos addicionals: un oponent registra aquest missatge avui i recupera la seva clau clàssica més tard, i la arrel cau fora.

3.2 Obtenir l'arrel als altres dispositius de l'usuari

El límit 3 de la Secció 2 -una identitat, diversos dispositius- no pot ser satisfet per aritmètica aquí, perquè tot el punt és que la clau no és una funció de res que els dispositius ja comparteixen. nympq1… Codificació pròpia.

Les arrels es mostren com nympq1… al costat del nsec, i un segon dispositiu l'accepta col·locat en el mateix panell. Això és tot el mecanisme. Un dispositiu que no ha rebut el codi no pot participar, que Secció 4.2 descriu.

La regla de la Secció 3.1 diu que l'arrel mai pot viatjar sota xifratge només clàssic, i qualsevol mecanisme que ho faci automàtic - sincronitzant-lo a través d'un relai, embolcallant-lo amb la clau d'identitat - viola exactament això.

El format deixa espai per a un camí embolicat: un registre pot portar una llista d'envasos, cadascun un blob AEAD sota una clau que l'usuari pot reproduir en un altre dispositiu - una sortida PRF passkey, per exemple. nympq1… El codi és l'únic camí a través. Secció 10.1 explica el que costa.

El mateix registre viu en la seva pròpia categoria de configuració, nymchat-pq-rootFins i tot portant cap embolcall fa el treball necessari: la seva presència és com un segon dispositiu aprèn que aquesta identitat ja té una arrel, que és el que li impedeix de fer un rival (secció 3.3).

3.3 Generació i adopció

En boot, mantenint una identitat duradora, un client funciona en aquest ordre:

1. Busca un existent nymchat-pq-root El record.
2. Record trobat, i aquest dispositiu pot desembolicar-lo - Adoptar-la i anunciar aquesta identitat com a post-quantum capaç.
3. Record trobat, i aquest dispositiu no pot desembolicar-lo — no generi una nova arrel, i no publiqui cap anunci en absolut. Instar a l'usuari a enllaçar aquest dispositiu introduint la nympq1… d’un dispositiu que ja en té.
4. Sense record generar una arrel, publicar el registre, anunciar i mostrar el nympq1… un codi a l'usuari una vegada perquè puguin guardar-lo.

El pas 3 és el pas que és fàcil d'equivocar, i és per això que l'ordre s'escriu en comptes de deixar a cada implementació.Dos dispositius que cadascun decideix generar una arrel produeixen dues arrels independents sota una identitat, i això és el fracàs que aquest ordenament existeix per evitar.

4Anunci de capacitat

La meitat pública del parell de claus derivat es publica com a adreçable Nivell 01 esdeveniment — tipus 30078, etiquetat 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 significa que el relai manté un esdeveniment per (kind, pubkey, d-tag), de manera que una república reemplaça l'anunci anterior en el seu lloc. Cada identitat, per tant, té exactament un registre actual, que és el que fa que la clau d'Alice ” una única recollida inequívoca en lloc d'una llista per reconciliar.

La signatura és vinculant. L'esdeveniment està signat per la clau d'identitat, de manera que la afirmació “aquesta clau ML-KEM pertany a aquest npub” és exactament tan fort com el npub mateix. Substituir una clau d'encapsulació diferent requereix forjar una signatura secp256k1.

Els anuncis expiren. El setè dia NIP-40 L'expiració, republicada cada 24 hores, manté en el registre una declaració sobre un client que encara s'està executant en comptes d'un que abans era.

Un anunci perdut es llegeix exactament com un que mai va portar una clau: els pares envien NIP-44 ordinari, que cada login pot llegir, i el client reprèn l'intercanvi post-quàntic en la seva propera connexió, quan es republica.

Sense una, un registre sobreviu a la clau que anomena: un dispositiu que s'esborra, reset, o té la seva arrel reemplaçada deixa una instrucció de peu per encapsular a una clau que ningú ja no té, i els missatges enviats sota ella es perden sense cap error en cap dels dos costats.

El camp clau denomina el seu format. El camp és pk2, i la xifra és part del contracte en lloc de la decoració: es denomina el format de càrrega útil amb el qual es pot utilitzar la clau. Un lector que no reconeix el camp conclou el client “Nymchat, no hi ha clau post-quàntica” i envia l'ordinari NIP-44, que cada login pot llegir. Això és la direcció correcta d'error, i val la pena assenyalar com a regla el format de numeració existeix per fer complir: una reclamació de capacitat no reconeguda ha de costar protecció, mai lliurament. Una clau que un col·laborador no pot utilitzar és pitjor que cap clau en absolut, perquè el missatge que produeix es perd sense error en cap costat.

4.1 L'absència és significativa i triplicada

Un detall subtil però important: l'anunci és publicat per tots els clients de Nymchat, no només els que són capaços de post-quantum, i el camp clau és opcional.

Un anunci sense clau és una declaració signada que l'enviador executa Nymchat, que permet que el camí d'enviament salti un embolcall especulatiu de protocols creuats que en cas contrari hauria d'incloure per a qualsevol persona que no pugui identificar.

4.2 Un dispositiu que no pot obrir l'arrel es manté en silenci

L'anunci és reemplaçable: un esdeveniment per identitat, guanya l'última escriptura. Això és el que fa que el disseny de registre únic funcioni, i també és el que fa que un dispositiu desconnectat sigui perillós si es publica.

Així que un dispositiu que coneix una arrel existeix però no pot obrir-la no publica cap anunci en absolut.No està trencat i no està bloquejat de l'aplicació: encara llegeix cada missatge per al qual té les claus i encara envia clàssicament, mentre demana a l'usuari que l'enllaci.

5Descobriment i la decisió d'enviar

Els clients aprenen les claus dels seus col·legues de dues maneres.Una subscripció permanent cobreix les persones amb les quals l'usuari realment es correspon -converses obertes i membres del grup- de manera que els seus anuncis arriben com a esdeveniments ordinaris.Per a un col·legiat que es va reunir per primera vegada, una consulta d'un sol cop s'executa en el temps d'enviament, limitat a 2,5 segons; si no es resol, el missatge passa a ser clàssic, que és el comportament que existia abans d'afegir post-quantum en comptes d'un nou mode d'error.

Un usuari que connecta un nou dispositiu, o que passa d'una connexió d'extensió de navegador a una clau local, es converteix en post-quantum capaç de mitja conversa, i una permanentment cached “no” els mantindria en xifrat clàssic per a la vida de l'anunci.

5.1 Per què no hi ha atacs de baixada

La decisió de rotar es redueix a una única pregunta:

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

No hi ha cap negociació de capacitats, cap llista d'algoritmes recolzats, i cap camp que un atacant pugui netejar per forçar un camí més feble. és El mode d'error d'un anunci retingut o retingut és que el missatge va a ser clàssic - l'estat del quo abans d'aquesta característica - en lloc que un missatge híbrid es redueixi a alguna cosa falsificable.

La inversa també té i importa més: un client envia híbrid Només Quan posseeix una clau, i mantenir la clau és la prova que el receptor pot decapsular.No hi ha estat en què un missatge s'envia post-quantum a algú que no pot llegir-lo.

6Construcció híbrida

Un text de xifratge NIP-44 no modificat és la capa interna, i ML-KEM clau un AEAD extern al seu voltant:

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)

Ambdós secrets encara han de ser recuperats per llegir el missatge: la capa exterior només produeix un text de xifrat NIP-44, i l'obertura que necessita el clàssic ECDH. Un adversari quàntic que trenca secp256k1 rep la clau interna i encara s'enfronta a ML-KEM; una ruptura de ML-KEM retira la capa exterior i deixa NIP-44 de peu.

• kem_ss res en aquesta derivació toca la sortida crua ECDH, que és el que es converteix en Secció 6.1.
• kem_ct, recip_kem_pk i ambdues claus d'identitat estan lligades com a dades associades, de manera que la capa exterior es compromet a la transcripció exacta que la va produir.

La clau ML-KEM del receptor és de llarga durada, però cada missatge porta un text xifrat independent i, per tant, un text xifrat independent. kem_ssAixò és el que fa que la derivació de la nonce en lloc de l'atzarització sona: ChaCha20-Poly1305 en línia es trenca reutilitzant un parell (key, nonce), i aquí la clau mateixa és nova per a cada missatge, de manera que cap parell pot repetir-se.

6.1 Per què les capes es mantenen separades

L'alternativa és barrejar ambdós secrets en una única clau de conversa i transmetre-ho a NIP-44:

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

Aquesta construcció sona com la criptografia. té un problema estructural: necessita ecdh_x, la coordenada crua x de la sortida ECDH, com a material clau - i una extensió del navegador (NIP-07) o un signatari remot (NIP-46Realitza NIP-44 en nom de l'anunciant i retorna un text xifrat, que és tot el punt de mantenir la clau en algun lloc on l'aplicació no pugui arribar.

Mesclar els secrets exclou, per tant, cada login que manté la clau d'identitat en un signant, és a dir, els usuaris més acurats, i cap quantitat de treball sobre la derivació de la clau pot canviar-la. El Layering elimina la dependència: NIP-44 es manté sencer i es produeix per tot el que té la clau d'identitat, signatari inclòs, mentre que la meitat KEM es computa del codi de recuperació que el client manté directament.

El cost és l'amplada de banda, i no és petit. El text de xifratge ML-KEM és de 1.088 bytes i va sobre cada missatge, base64url-codificat a 1.451 caràcters; l'AEAD extern afegeix una etiqueta de 16 bytes Poly1305 i amplia la càrrega útil NIP-44 que envolta per un terç. Un missatge de 50 caràcters creix de 176 bytes a 1.712, i un de 2.000 caràcters de 2.820 a 5.238.

6.2 Descripcions autònomes de payloads

El pq2. El prefix fa que el desplegament sigui incremental: és auto-descriptiu, de manera que un client tria el camí de desxifratge inspeccionant la càrrega útil en lloc de confiar en una etiqueta o recordant el que un col·laborador dóna suport. Un lector que no reconeix un prefix no obre aquesta càrrega útil en lloc de llegir-la malament, i els missatges segellats abans de qualsevol costat podrien fer que el post-quantum es mantingui llegible com el NIP-44 ordinari sense migració.

6.3 Les dues capes de l'envàs regal

A NIP-17 El missatge és a NIP-59 Envàs de regal: un rumor sense signatura, segellat sota la clau d'identitat de l'enviador (tipus 13), després embolicat sota una clau llançada generada per missatge (tipus 1059).

El segell és produït pel signatari com a NIP-44 ordinari - l'aplicació mai veu la clau que el fa - de manera que no es pot híbriditzar en el lloc. Això no costa res contra l'atac en qüestió: el segell només és accessible a través de l'envàs, i l'envàs és el que un enregistrador emmagatzema. Un oponent que manté el trànsit registrat ha de trencar ML-KEM abans que un segell sigui fins i tot visible per atacar.

7Missatges de grup i cobertura parcial

Un missatge de grup no és un text de xifrat. És el mateix text senzill enviat a cada membre, cada còpia encapsulada a la pròpia clau ML-KEM d'aquest membre. Un membre que ha publicat una clau rep un embolcall híbrid; un que no té un embolcall clàssic.

Això crea un problema de comptabilitat que una implementació ingènua s'equivoca. Si vuit de cada deu membres reben una còpia híbrida, el missatge és no Un oponent necessita una còpia clàssica d'un text clar que sigui idèntic en tots els deu, de manera que el missatge només està protegit si cada És una còpia.

Nymchat, per tant, rastreja la cobertura per missatge durant el fan-out - el recompte només es coneix mentre s'estan construint els envasos - i el segell informa “quantum-resistent a 8 de 10 membres” en comptes de reclamar que el missatge està protegit. Rebuda missatge de grup (només l'enviador compta el fan-out), la interfície informa de protecció parcial en lloc de completa.

7.1 Què informa l'escut

L'escut diu la veritat sobre el Missatge, no sobre el programari que l'ha enviat:

• Protecció completa: cada còpia d'aquest text simple va sortir híbrid.
• Parcial: algunes còpies d'un missatge de grup van sortir clàssicament.Degradat en lloc de complet, perquè una còpia clàssica d'un text clar idèntic en tots ells és una necessitat de l'adversari.
• El clàssic es declara directament en comptes de mostrar-se com a no badge, perquè un indicador absent és ambigu entre “unprotected”, “broken”, i “aquesta construcció manca de la característica”.

El veredicte es registra quan el missatge és segellat en comptes de recomputar el que anuncia un company més tard. El text de xifrat que ja existeix no pot ser millor protegit del que era, i una interfície que reescriu els vells missatges sobre la força d'un nou anunci seria afirmar alguna cosa falsa sobre els bytes en un relai.

Les regles del grup sobre l'estaca sobre això en lloc de reemplaçar-lo: un missatge de grup és totalment protegit només quan la còpia de cada membre va ser, i un missatge de grup rebut sense comptar la cobertura mostra parcial.

8Còpies adreçades a tu mateix

Diverses coses que un client emmagatzema estan encriptades per a la pròpia identitat de l'usuari: configuracions sincronitzades, la llista de conversa, les claus de grup i l'arxiu de missatges. Aquestes porten més sobre un usuari que la majoria dels missatges individuals, de manera que deixar-los clàssics els convertiria en l'artefacte emmagatzemat més feble independentment de com es van segellar els mateixos missatges. nymchat-pq-root categoria mateixa, que no pot ser segellada sota una clau que només pot produir.

Un bloc de configuracions o una fila d'arxius es troba en un lloc durant anys, que és exactament la forma de la cosa que un adversari de la collita-ara-desxifrat-després recull -molt més que qualsevol missatge únic, que és almenys efímer en la pròpia ment de l'usuari.

Una restricció governa el format aquí en comptes de la clau. Una còpia auto-adreçada ha de ser llegible per cada El dispositiu està en el compte, de manera que cada dispositiu anuncia el que pot obrir en el llistat que porta el seu anunci, i el compte només escriu el que tots ells poden llegir.

9Rotació

El epoch El comptador en la derivació és el que fa possible la rotació sense nou material clau. Incrementar-la dóna un nou parell de claus de la mateixa arrel i un anunci republicat; els pares agafen la nova clau del registre substituïble.

9.1 Es conserven les antigues èpoques i no es reencripta res

Un client construeix candidats de desxifratge de l'època actual fins a l'època − 3, de manera que un missatge segellat poc abans d'una rotació encara s'obre contra la parella de claus que era actual quan es va enviar.

Aquesta finestra és el que fa que la rotació sigui segura de fer en absolut: sense ella, cada rotació es trencaria tot el que estava en vol. Tot allò ja segellat es manté llegible per a la vida de la identitat, perquè un missatge que l'usuari ja no pot obrir és estrictament pitjor per a ells que aquell la protecció del qual no es pot millorar retroactivament (Secció 10.5).

10Què no protegeix

Un paper que només enumera el que aconsegueix un disseny no descriu un sistema, i exagerar una propietat de seguretat en una interfície és pitjor que ometre-la.

10.1 La arrel és un segon secret, i perdre-la és irrecuperable

Aquest és el preu real del disseny. La restricció de la Secció 2 que un usuari ha de tenir exactament una cosa per mantenir no es pot complir: el nsec sol no reconstrueix la clau post-quantum, perquè el punt és que cap valor públic ni cap altre secret l'exposa. Si cap dispositiu manté la arrel i cap dels envasos de la Secció 3.2 es pot obrir, el material segellat a la clau derivada de l'arrel no és recuperable.

Amb la transferència manual de l'únic camí, això és més clar del que es pot llegir primer. nympq1… El codi en qualsevol lloc té exactament una còpia d'ella, en un dispositiu, i perdre aquest dispositiu perd cada missatge post-quàntic, configuracions blob i filferro d'arxiu segellat a ell. nsec no ajuda; aquesta és la propietat sobre la qual es basa tot el disseny.

Un atacant ataca el camí més barat disponible, de manera que un esquema val el que val la seva ruta de recuperació més feble - una frase memorable, per exemple, posaria tot el que val la frase, i la línia embolicada és exactament l'artefacte que un adversari recol·lecte-ara-desxifrat-posterior recull i tritura fora de línia en el seu temps lliure.

10.2 Autenticació, com a diferent de la confidencialitat

Cada signatura en Nostr és Schnorr sobre secp256k1, i això no canvia aquí. Un oponent amb un ordinador quàntic podria forjar signatures i fingir un usuari en temps real. El que l'intercanvi de claus híbrides derrota és la collita-ara-desxifrar-després: un atacant que registra el trànsit avui no pot llegir-lo més tard. No fa que un missatge sigui inexcusable contra un oponent que ja té la màquina. Aquesta distinció es porta a les aplicacions deliberadament - l'indicador de padlock informa d'autenticació, l'escut informa de confidencialitat, i són glifs separats perquè un missatge pot tenir un sense l'altre.

El vincle entre un npub i una clau ML-KEM és una signatura secp256k1, de manera que un oponent que pugui falsificar aquestes pot substituir una clau pròpia.

10.3 Metadades

L'envàs de regal amaga l'enviador, el receptor més enllà d'un únic p La etiqueta, el tipus i el timestamp del missatge intern. No oculta que un esdeveniment existeix, la seva grandària, o quan un remitent el va rebre.

10.4 La xarxa offline

El transport de xarxa Bluetooth de Nymchat és un protocol separat amb el seu propi toc de mà, i no està cobert per aquesta feina.

10.5 Missatges ja enviats

El text digitalitzat gravat mentre ambdós costats encara eren clàssics roman clàssic permanentment. ja existeix i no es pot tornar a segellar. La protecció comença en el missatge on ambdós costats mantenen les claus post-quàntiques, no en el moment en què es va activar la funció.

11Alternatives considerades

12Paritat d’aplicació

Nymchat ofereix dues implementacions independents d'aquesta construcció: una en JavaScript per a l'aplicació web, una en Dart per a les aplicacions mòbils, incloent-hi un port ML-KEM-768 des de zero.

La implementació de Dart ML-KEM està validada contra l'oficial Nivell ACVP Projecte d'avaluació de la qualitat de l'alimentació per a l'alimentació per a l'alimentació per a l'alimentació per a l'alimentació per a l'alimentació per a l'alimentació per a l'alimentació per a l'alimentació per a l'alimentació per a l'alimentació (ML-KEM-*-FIPS203) - 25 claus de generació, 25 encapsulacions i 10 casos de decapsulació, executats com a suite pròpia. Aquests són els vectors que publica NIST per validar una implementació, de manera que passar-los és la prova que el port és correcte, no només la prova que els dos clients estan d'acord entre si. A més, una fixació compartida de vectors de prova - derivació de llavors, encapsulació, formats de càrrega útil i envasos de regals complets - es genera a partir de la referència de JavaScript i es comprova per ambdues suites de proves. El secret arrel estén aquesta fixació en lloc de substituir-la: arrel a llavors, arrel a claus, empremta pública de l'arrel, i les claus derivades, noces i dades associ nympq1… Una divergència en ambdues implementacions fracassa la construcció en comptes de produir un missatge que l'altre client no pot obrir.

És el que diu a un dispositiu “això és l'arrel que tinc” de “això és una altra, i un client que no pogués reproduir l'empremta d'un altre client llegiria un registre perfectament bo com no hi ha cap registre en absolut - i després, seguint Secció 3.3, minta una segona arrel i divideix la identitat.