Nymchat whitepaper técnico

Acordo clave post cuántico en Nymchat

Distribuír as claves públicas ML-KEM-768 sobre Nostr sen un directorio ou un rexistro, e sementalas dun segredo que ningún valor público expón.

Engadir un intercambio de chaves post cuántico a un mensaxeiro non é, na súa maioría, un problema de criptografía.Os primitivos están estandarizados e as bibliotecas existen. segundo Este artigo describe como Nymchat responde a iso - de onde vén a segunda clave, como chega ás persoas que a necesitan, e que a interface está autorizada a reclamar sobre o resultado - e, na última sección, o que ese resultado non protexe.

Esta páxina está traducida por máquina para maior comodidade. O orixinal en inglés é a versión que se aplica.

1O problema

As nosas mensaxes privadas están cifradas con NIP-44, que ten dúas metades separables. A metade que desliza o texto simple - ChaCha20 cunha etiqueta HMAC-SHA256, clave a través HKDF (RFC 5869 PáxinaNon está significativamente ameazado por unha computadora cuántica; o algoritmo de Grover custa unha aceleración de raíz cadrada contra unha clave simétrica, e 256 bits absorben iso. de acordo na clave está a curva elíptica Diffie-Hellman sobre Páxina 256K1Recuperar unha clave privada da súa contraparte pública retroactivamente expón cada segredo compartido que a clave xamais produciu.

A ameaza que isto crea non é adiada ata que exista tal máquina. Un adversario con almacenamento pode rexistrar o texto cifrado hoxe e descifralo sempre que chegue a capacidade. Calquera cousa enviada agora que aínda importa entón xa está comprometida. Este é o ataque específico que un intercambio de chaves post cuántico derrota, e é por iso que o traballo non pode esperar a que a máquina sexa construída.

1.1 A pregunta que este artigo responde

A súa función é a de facilitar a comunicación entre os usuarios, de forma que o usuario poida acceder a calquera tipo de información que poida acceder a través da páxina web do sitio web. (Páxina 203Isto xera inmediatamente un problema de distribución:

Un npub é auto-contenido.Podes escribilo en papel, le-lo en voz alta, ou escanealo desde unha pantalla, e é todo o que alguén precisa para cifrar para ti.Unha clave pública ML-KEM-768 é de 1.184 bytes.Non se pode ler en voz alta, non se encaixará nun nome de usuario, e non pertence a un código QR ademais dunha identidade que é só 32 bytes.

A parte máis difícil é que unha segunda clave trae tres problemas distintos, e o resto deste artigo é en gran medida unha resposta a eles:

• Pódese substituír. Unha clave que ninguén pode ler a unha ollada é exactamente o tipo de cousa que un atacante intercambia pola súa propia.
• Debe estar de acordo en todos os dispositivos dun usuario. A mesma conta nun teléfono e un portátil debe presentar a mesma clave, ou as mensaxes seladas nun non se poden abrir no outro.
• pódese perder. A clave pública é reeditada a partir dun segredo, polo que o que realmente ten que sobrevivir é ese segredo - e por construción nada máis a reconstrúe.

2Condicións de deseño

Catro restricións formaron a resposta, e excluíron a maioría dos deseños obvios antes de que se escribise calquera código.

1. O menos segredos posible. Cada segredo adicional é outra forma de perder o seu historial, e alguén que saiba facer copias de seguridade dun nsec non saberá facer copias de seguridade de nada máis. Sección 3.1 mostra que este non pode ser atendido directamente -unha clave post cuántica derivada do nsec non ofrece ningunha protección post cuántica en absoluto - polo que o deseño gasta exactamente un segredo e non máis: unha única peza de material clave, xerada unha vez por identidade, presentada na mesma forma que o nsec e no mesmo lugar, para que quen sabe como manter un saiba como manter o outro. Sección 10.1 é honesto sobre o que aínda custa.
2. Non ten autoridade. Non hai servidor que se poida confiar para dicir que clave pertence a quen.
3. Moitos dispositivos, unha única identidade. Calquera material clave que exista debe acabar sendo idéntico en todos eles, e os camiños que o levan alí non deben ser lidos polo adversario contra o que a característica está defendendo.
4. Non hai negociación. Calquera intercambio en banda de “que cifras apoias?” é unha superficie que un atacante pode cortar para forzar a opción máis débil.

3Un segredo raíz independente

A decisión de carga é que a clave de decapsulación ML-KEM está sementada a partir de material clave que ningún valor público expón.

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 raíz preséntase ao usuario da forma en que un nsec é: Beixín 32 O prefixo humanamente lexible nympqque se le como nympq1…, mostrado xunto ao nsec na pantalla de identidade detrás da mesma interacción de revelación, copiado co mesmo control, nunca rexistrado e nunca enviado en ningún lugar no claro.

O sal está separado de dominio con propósito, polo que ningún outro segredo pode derivar o mesmo par de teclas. epoch Conducir a rotación (Sección 9).

3.1 Por que a clave non se pode derivar da clave de identidade

O deseño obvio é sementar o par de teclas do segredo que o usuario xa ten:

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

É atractivo por catro razóns, todas elas reais: nada novo para copiar, porque o nsec xa é a copia de seguridade; cada dispositivo que acepta por construción, sen que o protocolo de sincronización vaia mal; un anuncio substituíble por identidade sendo obviamente correcto, porque os dispositivos non poden discordar sobre a clave; e a clave existente antes de que sexa publicada, para que un cliente poida selar algo para si mesmo en primeira instancia.

Todos os catro beneficios son inútiles, por unha razón. O algoritmo de Shor corre contra un npub publicado obtén o nsec. A derivación de sementes é un algoritmo público sobre o nsec. Entón, o adversario que rompe a metade clásica reconstrúe a metade pós-cuántica executando o mesmo HKDF que todos os outros executan. Contra a colleita-agora-descifrado-posteriormente -a única ameaza que existe a característica para parar- unha clave derivada deste xeito non engade nada.

Un segredo xerado de forma independente que se sincroniza entre os dispositivos dun usuario dentro dunha mensaxe NIP-44 ordinaria é o mesmo fracaso con pasos adicionais: un adversario rexistra esa mensaxe hoxe e recupera a súa clave clásica máis tarde, e a raíz cae fóra.

3.2 Obter a raíz para os outros dispositivos do usuario

A restrición 3 da Sección 2 -unha identidade, varios dispositivos- non pode ser satisfeita por aritmética aquí, porque todo o punto é que a clave non é unha función de nada que os dispositivos xa comparten. nympq1… O propio código.

A raíz aparece como nympq1… ao lado do nsec, e un segundo dispositivo acepta que estea inserido no mesmo panel.Este é o mecanismo enteiro.Un dispositivo que non recibiu o código non pode participar, que se describe na Sección 4.2.

A regra na Sección 3.1 di que a raíz pode nunca viaxar baixo cifrado clásico-só, e calquera mecanismo que faría isto automático - sincronizalo a través dun relé, envolvéndoo coa clave de identidade - viola exactamente iso.

O formato deixa espazo para un camiño envolto: un rexistro pode levar unha lista de envoltorios, cada un cun blob AEAD baixo unha clave que o usuario pode reproducir noutro dispositivo - unha saída PRF passkey, por exemplo. nympq1… O código é o único camiño a través. Sección 10.1 di o que custa.

O propio rexistro vive na súa propia categoría de configuración, nymchat-pq-rootMesmo cargando ningún envoltorio fai o traballo necesario: a súa presenza é como un segundo dispositivo aprende que esta identidade xa ten unha raíz, o que é o que lle impide mentar un rival (Sección 3.3).

3.3 Xeración e adopción

En boot, mantendo unha identidade duradeira, un cliente funciona nesta orde:

1. Buscar unha existente nymchat-pq-root O rexistro.
2. rexistro atopado, e este dispositivo pode desempaquetalo - Adopta-lo e anuncia esta identidade como poscuántico capaz.
3. Rexistro atopado, e este dispositivo non pode desembalalo - non xere unha nova raíz, e non publique ningún anuncio en absoluto. nympq1… dun dispositivo que xa o ten.
4. Non hai récord xerar unha raíz, publicar o rexistro, anunciar e amosar o nympq1… código ao usuario unha vez para que poidan gardalo.

O paso 3 é o paso que é fácil de equivocar, e é por iso que a orde é escrita en lugar de deixada a cada implementación.Dous dispositivos que cada un decide xerar unha raíz producen dúas raíces independentes baixo unha identidade, e que é o fracaso que esta orde existe para evitar.

4Anuncio de capacidade

A metade pública do par de teclas derivadas é publicada como unha Páxina 01 evento — tipo 30078, etiquetado 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 o relé mantén un evento por (kind, pubkey, d-tag), de xeito que unha república substitúe o anuncio anterior no lugar. Cada identidade, polo tanto, ten exactamente un rexistro actual, o que fai que “mirar a clave de Alice” un único achegamento inequívoco en vez dunha lista para reconciliar.

A sinatura é obrigatoria. O evento está asinado pola clave de identidade, polo que a afirmación “esta clave ML-KEM pertence a este npub” é exactamente tan forte como o propio npub. Substituír unha clave de encapsulación diferente require forxar unha sinatura secp256k1.

Os anuncios expiran. Sete días NIP-40 expiración, republicado cada 24 horas, mantén o rexistro unha declaración sobre un cliente que aínda está en execución en vez de un que antes era.

Un anuncio perdido é lido exactamente como un que nunca levou unha clave: os pares envían NIP-44 ordinario, que cada login pode ler, e o cliente retoma o intercambio post-cuántico na súa próxima conexión, cando se republica. Entón, permanecer en silencio durante máis dunha semana custa protección para as mensaxes enviadas durante a brecha - son clásicamente cifradas en vez de resistentes á cuántica - e non custa nada máis.

Sen un, un rexistro sobrevive á clave que chama: un dispositivo que se borra, reseta ou ten a súa raíz substituída deixa unha instrución de pé para encapsular a unha clave que ninguén ten máis, e as mensaxes enviadas baixo el pérdense sen erro en ningún lado.

O campo clave nomea o seu formato. O campo é pk2, e o díxito é parte do contrato en vez de decoración: nomea o formato de carga útil coa que se pode usar a clave. Un lector que non recoñece o campo conclúe o cliente “Nymchat, non hai clave post-cuántica” e envía o NIP-44 ordinario, que cada login pode ler. Que é a dirección correcta do fracaso, e vale a pena dicir como unha regra a numeración do formato existe para facer cumprir: unha reclamación de capacidade non recoñecida debe custar protección, nunca entrega. Unha clave que un compañeiro non pode usar é peor que ningunha clave en absoluto, porque a mensaxe que produce é perdida sen erro en ningún lado.

4.1 A ausencia é significativa e triplicada

Un detalle sutil pero importante: o anuncio é publicado por todos os clientes de Nymchat, non só os post-cuánticos, e o campo clave é opcional.

Un anuncio sen chave é unha declaración asinada que o remitente executa Nymchat, o que permite que o camiño de envío salte un envoltorio especulativo de protocolo cruzado que doutro xeito tería que incluír para calquera que non poida identificar.

Un dispositivo que non pode abrir a raíz permanece en silencio

O anuncio é substituíble: un evento por identidade, gaña a última gravación.Iso é o que fai que o deseño de rexistro único funcione, e tamén é o que fai que un dispositivo non vinculado sexa perigoso se publica.Un dispositivo que anunciou unha clave que se fixera para si mesmo bloquearía o rexistro real e enviaría a cada compañeiro a cifrar baixo unha clave que os outros dispositivos non poderían abrir.

Así que un dispositivo que coñece unha raíz existe pero non pode abri-la non publica ningún anuncio en absoluto.Non está roto e non está pechado da aplicación: aínda le cada mensaxe para a que ten as claves e aínda envía de xeito clásico, ao mesmo tempo que convida ao usuario a enlazar.

5Descubrimento e a decisión de enviar

Os clientes aprenden as claves dos compañeiros de dúas maneiras. Unha subscrición permanente cobre as persoas coas que un usuario realmente se corresponde -conversas abertas e membros do grupo- de xeito que os seus anuncios chegan como eventos ordinarios.Para un compañeiro que se reuniu por primeira vez, unha consulta única execútase no tempo de envío, limitado a 2,5 segundos; se non se resolve, a mensaxe pasa ao clásico, que é o comportamento que existía antes de que se engadise o post cuántico en lugar dun novo modo de fracaso.

Un usuario que conecta un novo dispositivo, ou que se move dun login de extensión de navegador a unha clave local, convértese en post-cuántico capaz de medio-conversa, e un permanentemente cached “no” mantería-los en cifrado clásico para a vida do anuncio.

5.1 Por que non hai un ataque de baixa

A decisión de rotación redúcese a unha única pregunta:

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

Non hai negociación de capacidade, ningunha lista de algoritmos soportados, e ningún campo que un atacante poida limpar para forzar un camiño máis débil. é O modo de fracaso dun anuncio retirado ou retido é que a mensaxe vaia clásica - o status quo antes desta característica - en vez de que unha mensaxe híbrida se degrade a algo falsificable.

O contrario tamén ten e importa máis: un cliente envía híbrido só cando posúe unha clave, e manter a clave é proba de que o receptor pode decapsularse.Non hai estado no que unha mensaxe sexa enviada post-cuántica a alguén que non pode lela.

6Construción híbrida

Un texto de cifrado NIP-44 non modificado é a capa interna, e ML-KEM tecla un AEAD externo ao seu redor:

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)

Ambos os segredos aínda deben ser recuperados para ler a mensaxe: a capa exterior só produce un texto cifrado NIP-44, e a apertura que necesita o clásico ECDH. Un adversario cuántico que rompe secp256k1 recibe a clave interna e aínda se enfronta a ML-KEM; unha ruptura de ML-KEM tira a capa exterior e deixa NIP-44 en pé.

• kem_ss nada nesta derivación toca a saída en bruto ECDH, que é o que Sección 6.1 xira en.
• kem_ct, recip_kem_pk e ambas as chaves de identidade están vinculadas como datos asociados, polo que a capa externa está comprometida coa transcrición exacta que a produciu.

A clave ML-KEM do destinatario é duradeira, pero cada mensaxe leva un texto de cifrado independente e, polo tanto, unha clave independente. kem_ssIsto é o que fai que derivar o nonce en vez de aleatoriamente soar: ChaCha20-Poly1305 Páxina é roto por reutilizar un par (chave, nonce), e aquí a clave en si é nova para cada mensaxe, polo que ningún par pode repetirse.

6.1 Por que as capas permanecen separadas

A alternativa é mesturar ambos os segredos nunha única clave de conversación e enviar iso a NIP-44:

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

Esa construción soa como criptografía. Ten un problema estrutural: necesita ecdh_x, o coordenado x bruto da saída ECDH, como material clave - e unha extensión do navegador (NIP-07) ou unha sinatura remota (NIP-46Realiza NIP-44 en nome do chamador e devolve un texto cifrado, que é todo o punto de manter a clave nalgún lugar onde a aplicación non poida chegar.

Misturar os segredos, polo tanto, exclúe cada login que mantén a clave de identidade nun asinante, que é dicir, os usuarios máis coidadosos, e ningunha cantidade de traballo sobre a derivación da clave pode cambialo.Laying elimina a dependencia: NIP-44 permanece enteiro e é producido por todo o que posúe a clave de identidade, asinante incluído, mentres que a metade KEM é calculada a partir do código de recuperación que o cliente posúe directamente.

O custo é ancho de banda, e non é pequeno. O texto cifrado ML-KEM é de 1.088 bytes e corre en cada mensaxe, base64url-codificado a 1.451 caracteres; o AEAD externo engade unha etiqueta de 16 bytes Poly1305 e expande a carga útil NIP-44 que envolve por un terceiro. Unha mensaxe de 50 caracteres medra de 176 bytes a 1.712, e unha de 2.000 caracteres de 2.820 a 5.238.

6.2 Auto-descrición de payloads

A súa pq2. O prefixo fai que a implantación sexa incremental: é auto-descrición, polo que un cliente elixe o camiño de descifrado inspeccionando a carga útil en lugar de confiar nunha etiqueta ou lembrar o que soporta un compañeiro.Un lector que non recoñece un prefixo non abre esa carga útil en lugar de malla lectura, e as mensaxes seladas antes de que ambos os dous lados poidan facer que o post-cuántico permaneza lexible como o NIP-44 ordinario sen migración.

6.3 As dúas capas do envoltorio do agasallo

A NIP-17 A mensaxe é unha NIP-59 Envase de agasallo: un rumor sen sinatura, selado baixo a clave de identidade do remitente (tipo 13), despois envolto baixo unha clave de lanzamento xerada por mensaxe (tipo 1059).

O selo é producido polo asinante como NIP-44 ordinario - a aplicación nunca ve a clave que o fai - polo que non pode ser híbrido no lugar. Isto non custa nada contra o ataque en cuestión: o selo só é accesible a través do envoltorio, e o envoltorio é o que almacena un gravador. Un adversario que mantén o tráfico rexistrado debe romper o ML-KEM antes de que un selo sexa aínda visible para atacar.

7Mensaxes de grupo e cobertura parcial

Unha mensaxe de grupo non é un só texto cifrado. É o mesmo texto simple enviado a cada membro, cada copia encapsulada á propia clave ML-KEM dese membro. Un membro que publicou unha clave recibe un envoltorio híbrido; un que non recibe un envoltorio clásico.

Isto crea un problema de contabilidade que unha implementación inxenuo se equivoca. Se oito de dez membros reciben unha copia híbrida, a mensaxe é non Un adversario necesita unha copia clásica dun texto simple que sexa idéntico en todos os dez, polo que a mensaxe só está protexida se cada A copia é.

Nymchat, polo tanto, rastrexa a cobertura por mensaxe durante o fan-out - a conta só é coñecible mentres se están construíndo os enchufes - e o badge informa “quantum-resistente a 8 de 10 membros” en vez de afirmar que a mensaxe está protexida. recibido mensaxe de grupo (só o remitente conta o fan-out), a interface informa de protección parcial en vez de completa.

7.1 O que informa o Escudo

O escudo di a verdade sobre a Mensaxe, non sobre o software que o enviou:

• Protección completa: cada copia deste texto simple saíu híbrida.
• Parcial: algunhas copias dunha mensaxe de grupo saíron de xeito clásico.Desenvolvido en vez de completo, porque unha copia clásica dun texto simple idéntica en todos eles é unha necesidade do adversario.
• Clásico é declarado directamente en vez de amosar como ningún badge, porque un indicador ausente é ambiguo entre “unprotected”, “broken”, e “esta construción carece do recurso”.

O veredicto rexístrase cando a mensaxe está selada en vez de recompilada a partir do que un compañeiro anuncia máis tarde.O texto de cifrado que xa existe non pode ser mellor protexido do que era, e unha interface que rediseña as vellas mensaxes sobre a forza dun novo anuncio estaría afirmando algo falso sobre bytes nun relay.

As regras de grupo sobre a pila enriba disto en vez de substituílo: unha mensaxe de grupo está totalmente protexida só cando a copia de cada membro foi, e unha mensaxe de grupo recibida sen conta de cobertura mostra parcial.

8Copias dirixidas a ti mesmo

Varias cousas que un cliente almacena están cifradas para a propia identidade do usuario: configuracións sincronizadas, a lista de conversacións, as chaves de grupo e o arquivo de mensaxes. Estes levan máis sobre un usuario que a maioría das mensaxes individuais, polo que deixalos clásicos farían deles o artefacto máis débil almacenado independentemente de como se selaran as propias mensaxes. nymchat-pq-root categoría mesma, que non pode ser selada baixo unha chave que só pode producir.

Un blob de configuracións ou unha liña de arquivo sitúase nun lugar durante anos, que é exactamente a forma de cousa que un adversario recolle - agora descifrado- máis tarde - moito máis que calquera mensaxe única, que é polo menos efémera na propia mente do usuario.

Unha restrición rexe o formato aquí en vez da clave. Unha copia auto-adxudicada debe ser lexible por cada cada dispositivo anuncia o que pode abrir na lista que leva o seu anuncio, e a conta escribe só o que todos eles poden ler. Escribir calquera outra cousa bloquearía un dispositivo fóra das súas propias configuracións - o mesmo fracaso silencioso Sección 3.2 evita por outros medios, chegando desde unha dirección diferente.

9Rotacións

A súa epoch O contador na derivación é o que fai posible a rotación sen novo material de chave. Incrementándoo obtén un novo par de chaves da mesma raíz e un anuncio reeditado; os pares recollen a nova clave do rexistro substituíble.

9.1 Consérvanse as antigas épocas e nada é reencriptado

Un cliente constrúe candidatos de descifrado desde a época actual ata a era − 3, polo que unha mensaxe selada pouco antes dunha rotación aínda se abre contra o par de teclas que era actual cando se enviou.

Esa fiestra é o que fai que a rotación sexa segura: sen ela, cada rotación estragaría o que fose en voo.Calquera cousa xa selada permanece lexible para a vida da identidade, porque unha mensaxe que o usuario xa non pode abrir é estritamente peor para eles que unha cuxa protección non pode ser mellorada retroactivamente (Sección 10.5).

10O que non protexe

Un documento que só enumera o que un deseño consegue non describe un sistema, e esaxerar unha propiedade de seguridade nunha interface é peor que omitila.

10.1 A raíz é un segundo segredo, e perdelo é irrecuperable

Este é o prezo real do deseño.A restrición na Sección 2 de que un usuario debe ter exactamente unha cousa para manter non pode ser cumprida: o nsec só non reconstrúe a clave post-cuántica, porque o punto é que ningún valor público e ningún outro segredo a expón. Se ningún dispositivo mantén a raíz e ningún dos envoltorios da Sección 3.2 pode ser aberto, o material selado á clave derivada da raíz non é recuperable.

Con transferencia manual o único camiño, este é máis agudo do que pode ler por primeira vez. nympq1… O código en calquera lugar ten exactamente unha copia del, nun dispositivo, e perdendo ese dispositivo perde cada mensaxe post-cuántica, configuración blob e liña de arquivo selada a el. nsec non axuda; esa é a propiedade sobre a que repousa todo o deseño.

Un atacante ataca o camiño máis barato dispoñible, polo que un esquema vale o que vale a súa ruta de recuperación máis débil - unha frase memorable, por exemplo, poñería toda a cousa en calquera cousa que a frase vale, e a liña envolta é exactamente o artefacto que un adversario recolle-agora-descifrado-posteriormente recolle e moedor offline no tempo libre.

10.2 Autenticación, como distinta á confidencialidade

Cada sinatura en Nostr é Schnorr sobre secp256k1, e iso non cambia aquí. Un adversario cun ordenador cuántico podería forxar sinaturas e fingir un usuario en tempo real. O que o intercambio de chaves híbrido derrota é a colleita-agora-descifrado-máis tarde: un atacante que rexistra o tráfico hoxe non o pode ler máis tarde. Non fai unha mensaxe inexcusable contra un adversario que xa ten a máquina. Esta distinción é levada a cabo nas aplicacións deliberadamente - o indicador de padlock informa de autenticación, o escudo informa de confidencialidade, e son glifos separados porque unha mensaxe pode ter unha sen a outra.

O vínculo entre un npub e unha clave ML-KEM é unha sinatura secp256k1, polo que un adversario que pode forxar estes pode substituír unha clave propia.

10.3 Metadatos

O envase de agasallo oculta o remitente, o receptor máis aló dun único p A etiqueta, o tipo e o timestamp da mensaxe interna. Non oculta que un evento existe, o seu tamaño ou cando un relé o recibiu.

10.4 O Mesh Offline

O transporte de rede Bluetooth de Nymchat é un protocolo separado co seu propio toque de man, e non está cuberto por este traballo.

10.5 Mensaxes xa enviadas

O texto de cifrado gravado mentres ambos os dous lados aínda eran clásicos permanece clásico permanentemente. Xa existe e non se pode selar de novo. A protección comeza na mensaxe onde ambos os lados mantiveron as teclas post cuánticas, non no momento en que se activou a característica.

11Alternativas consideradas

12Paridade de execución

Nymchat ofrece dúas implementacións independentes desta construción - unha en JavaScript para a aplicación web, unha en Dart para as aplicacións móbiles, incluíndo un porto ML-KEM-768 desde o principio.

A implementación de Dart ML-KEM é validada contra o oficial Xestión ACVP Xestión de residuos de alta produtividade (Xestión de residuos de alta produtividade)ML-KEM-*-FIPS203) — 25 chave-xeración, 25 encapsulación e 10 casos de decapsulación, executados como a súa propia suite. Estes son os vectores que publica NIST para validar unha implementación, así que pasalos é proba de que o porto é correcto, non só evidencia de que os dous clientes están de acordo entre si. Ademais, unha fixación compartida de vectores de proba — derivación de sementes, encapsulación, ambos os formatos de carga útil e enchufes de agasallos completos — xérase a partir da referencia de JavaScript e verifícase por ambas as suites de proba. O segredo raíz estende esa fixación en vez de substituíla: raíz a semente, raíz a clave, a pegada pública da raíz e os datos derivados, nonce e asociados da capa exterior son vectores propios, polo que os dous clientes nympq1… Unha diverxencia en ambas as implementacións falla a construción en vez de producir unha mensaxe que o outro cliente non pode abrir.

É o que di a un dispositivo “este é a raíz que teño” de “este é un outro ”, e un cliente que non puidese reproducir a pegada dixital doutro cliente lería un rexistro perfectamente bo como ningún rexistro en absoluto - e logo, seguindo a Sección 3.3, minar unha segunda raíz e dividir a identidade.