Nymchat whitepaper técnico

Acuerdo de clave post cuántica en Nymchat

Distribuir las claves públicas de ML-KEM-768 a través de Nostr sin un directorio o un registro, y sembrarlas de un secreto que ningún valor público expone.

Añadir un intercambio de claves post cuántico a un mensaje no es en su mayoría un problema de criptografía.Los primitivos se estandarizan y las bibliotecas existen. segundo Este artículo describe cómo Nymchat responde a eso —de dónde viene la segunda clave, cómo llega a las personas que la necesitan, y qué se permite a la interfaz reclamar sobre el resultado— y, en la última sección, qué ese resultado no protege.

Esta página está traducida automáticamente para mayor comodidad. La versión original en inglés es la que se aplica.

1El problema

Nuestros mensajes privados están cifrados con PNI-44, que tiene dos mitades separables. La mitad que scrambles el texto simple — ChaCha20 con una etiqueta HMAC-SHA256, clave a través HKDF (RFC 5869) — no está significativamente amenazado por una computadora cuántica; el algoritmo de Grover cuesta una aceleración de raíz cuadrada contra una clave simétrica, y 256 bits absorben eso. Acuerdo La curva elíptica Diffie-Hellman Página 256K1Recuperar una clave privada de su contraparte pública retroactivamente expone cada secreto compartido que la clave jamás produjo.

La amenaza que esto crea no se retrasa hasta que exista tal máquina. Un oponente con almacenamiento puede grabar texto cifrado hoy y descifrarlo siempre que llegue la capacidad. Cualquier cosa enviada ahora que todavía importa entonces ya está comprometida. Este es el ataque específico que un intercambio de claves post cuántico derrota, y es por eso que el trabajo no puede esperar a que la máquina sea construida.

1.1 La pregunta a la que responde este artículo

La mitigación es bien entendida: ejecute un mecanismo de encapsulación de clave post cuántica junto al intercambio clásico, por lo que un atacante tiene que romper ambos para leer cualquier cosa.Página 203Esto plantea inmediatamente un problema de distribución:

Un npub es auto-contenido. Puedes escribirlo en papel, leerlo en voz alta, o escanearlo desde una pantalla, y es todo lo que alguien necesita cifrar para ti. Una clave pública ML-KEM-768 es de 1,184 bytes. No se puede leer en voz alta, no se encajará en un nombre de usuario, y no pertenece a un código QR aparte de una identidad que es sólo de 32 bytes.

La parte más difícil es que una segunda clave trae tres problemas distintos, y el resto de este artículo es en gran medida una respuesta a ellos:

• puede ser sustituido. Una clave que nadie puede leer a simple vista es exactamente el tipo de cosa que un atacante intercambia por su propia.
• Debe estar de acuerdo en todos los dispositivos de un usuario. La misma cuenta en un teléfono y un portátil debe presentar la misma clave, o los mensajes sellados a uno no pueden ser abiertos en el otro.
• Puede ser perdido. La clave pública se republica de un secreto, por lo que lo que realmente tiene que sobrevivir es ese secreto - y por construcción nada más la reconstruye. Sección 10.1 establece claramente cuánto cuesta, porque este no se resuelve tanto como se paga.

2Condiciones de diseño

Cuatro restricciones formaron la respuesta, y excluyen la mayoría de los diseños obvios antes de que se escriba cualquier código.

1. tan pocos secretos como sea posible. Cada secreto adicional es otra forma de perder su historia, y alguien que sabe copiar un nsec no sabrá copiar nada más. Sección 3.1 muestra que este no se puede cumplir directamente -una clave post cuántica derivada del nsec no proporciona protección post cuántica en absoluto - por lo que el diseño gasta exactamente un secreto y no más: una única pieza de material clave, generada una vez por identidad, presentada en la misma forma que el nsec y en el mismo lugar, de modo que quien sabe cómo mantener uno sabe cómo mantener el otro.
2. Sin autoridad No hay un servidor que se pueda confiar para decir qué clave pertenece a quién.
3. Muchos dispositivos, una sola identidad. Cualquier material clave que exista debe terminar idéntico en todos ellos, y los caminos que lo llevan allí no deben ser legibles por el oponente contra el cual la característica está defendiendo.
4. No hay negociación. Cualquier intercambio en banda de “¿qué cifras apoya?” es una superficie que un atacante puede cortar para forzar la opción más débil.

3Un secreto de raíz independiente

La decisión de carga es que la clave de decapsulación ML-KEM se siembra de material clave que ningún valor público expone.

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)

La raíz se presenta al usuario de la manera en que un nsec es: Bech32 Con el prefixo humano-legible nympqPor lo tanto, se lee como nympq1…, mostrado junto al nsec en la pantalla de identidad detrás de la misma interacción revelar, copiado con el mismo control, nunca logado y nunca enviado en ningún lugar en el claro. no es una contraseña y no es un login.

La sal está separada del dominio con propósito, por lo que ningún otro secreto puede derivar el mismo par de teclas. epoch Conductores de contrarreloj de rotación (Sección 9).

3.1 Por qué la clave no puede derivarse de la clave de identidad

El diseño obvio es sembrar el par de teclas del secreto que el usuario ya tiene:

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

Es atractivo por cuatro razones, todas ellas reales: nada nuevo para copiar, porque el nsec ya es la copia de seguridad; cada dispositivo que acepta por construcción, sin que el protocolo de sincronización vaya mal; un anuncio reemplazable por identidad siendo obviamente correcto, porque los dispositivos no pueden discrepar sobre la clave; y la clave existente antes de que se publique, para que un cliente pueda sellar algo para sí mismo en primera instancia.

Todos los cuatro beneficios son inútiles, por una razón. El algoritmo de Shor que corre contra un npub publicado da el nsec. La derivación de semillas es un algoritmo público sobre el nsec. Por lo tanto, el oponente que rompe la mitad clásica reconstruye la mitad post cuántica ejecutando el mismo HKDF que todos los demás ejecutan. Contra la cosecha-ahora-descifrado-más tarde -la única amenaza que existe la característica para detener- una clave derivada de esta manera no agrega nada.

La segunda cláusula de esa regla funciona tanto como la primera.Un secreto generado de forma independiente que luego se sincroniza entre los dispositivos de un usuario dentro de un mensaje NIP-44 ordinario es el mismo fracaso con pasos adicionales: un oponente registra ese mensaje hoy y recupera su clave clásica más tarde, y la raíz cae fuera.

3.2 Obtener la raíz a los otros dispositivos del usuario

Contenido 3 de la Sección 2 – una identidad, varios dispositivos – no puede ser satisfecho por aritmética aquí, porque todo el punto es que la clave no es una función de nada que los dispositivos ya comparten. nympq1… El propio código.

La raíz se muestra como nympq1… al lado del nsec, y un segundo dispositivo lo acepta colado en el mismo panel. Eso es todo el mecanismo. Un dispositivo que no ha recibido el código no puede participar, lo que se describe en la Sección 4.2.

La regla en la Sección 3.1 dice que la raíz nunca puede viajar bajo la encriptación clásica-sólo, y cualquier mecanismo que haría esto automático - sincronizándolo a través de un relay, envuelto a la clave de identidad - viola exactamente eso.

El formato deja espacio para un camino envuelto: un registro puede llevar una lista de envueltos, cada uno un blob AEAD bajo una clave que el usuario puede reproducir en otro dispositivo - una salida PRF passkey, por ejemplo. nympq1… El código es el único camino a través.El apartado 10.1 establece cuánto cuesta.

El propio registro vive en su propia categoría de configuración, nymchat-pq-rootIncluso cargando ningún envoltorio hace el trabajo necesario: su presencia es cómo un segundo dispositivo aprende que esta identidad ya tiene una raíz, lo que lo detiene de llamar a un rival (Sección 3.3).

3.3 Generación y adopción

En el boot, manteniendo una identidad duradera, un cliente funciona en este orden:

1. Buscar una existente nymchat-pq-root El record.
2. Record encontrado, y este dispositivo puede desembocarlo - Adoptarla y anunciar esta identidad como capaz post-cuántica.
3. Record encontrado, y este dispositivo no puede desendolcarlo - no genere una nueva raíz, y no publique ningún anuncio en absoluto. nympq1… código de un dispositivo que ya lo tiene.
4. No hay record generar una raíz, publicar el registro, anunciar y mostrar el nympq1… el código al usuario una vez para que puedan guardarlo.

Paso 3 es el paso que es fácil de equivocarse, y es por eso que el orden se escribe en lugar de dejar a cada implementación.Dos dispositivos que cada uno decide generar una raíz producen dos raíces independientes bajo una identidad, y eso es el fracaso que este orden existe para evitar.

4Anuncio de Capacidad

La mitad pública del par de teclas derivadas se publica como un Niño-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 el relay mantiene un evento por (kind, pubkey, d-tag), por lo que una república reemplaza el anuncio anterior en su lugar. Cada identidad, por lo tanto, tiene exactamente un registro actual, que es lo que hace que la clave de Alice ” una única recogida inequívoca en lugar de una lista para reconciliar.

La firma es obligatoria. El evento está firmado por la clave de identidad, por lo que la afirmación “esta clave ML-KEM pertenece a este npub” es exactamente tan fuerte como el propio npub. Sustituir una clave de encapsulación diferente requiere forjar una firma secp256k1.

Los anuncios expiran. Séptimo día PNI-40 Expiration, reeditado cada 24 horas, mantiene en el registro una declaración sobre un cliente que todavía está en ejecución en lugar de una que antes era.

Un anuncio perdido se lee exactamente como uno que nunca llevó una llave: los pares envían NIP-44 ordinario, que cada login puede leer, y el cliente retoma el intercambio post-cuántico en su próxima conexión, cuando se republica. Así que estar en silencio durante más de una semana cuesta protección para los mensajes enviados durante la brecha - son clásicamente cifrados en lugar de resistentes a los cuánticos - y no cuesta nada más.

Sin uno, un registro sobrevive a la clave que denomina: un dispositivo que es borrado, resetado, o tiene su raíz reemplazada deja una instrucción de pie para encapsular a una clave que nadie tiene más, y los mensajes enviados bajo él se pierden sin error en ambos lados.

El campo clave denomina su formato. El campo es pk2, y el dígito es parte del contrato en lugar de la decoración: denomina el formato de carga útil con el que se puede usar la clave. Un lector que no reconoce el campo concluye el cliente “Nymchat, sin clave post-cuántica” y envía la NIP-44 ordinaria, que cada login puede leer. Esa es la dirección correcta de error, y vale la pena afirmar como regla la numeración del formato existe para hacer cumplir: una reclamación de capacidad no reconocida debe costar protección, nunca entrega. Una clave que un compañero no puede usar es peor que ninguna clave en absoluto, porque el mensaje que produce se pierde sin error en ambos lados.

4.1 La ausencia es significativa y triplicada

Un detalle sutil pero importante: el anuncio es publicado por todos los clientes de Nymchat, no sólo los que son capaces de post-cuántico, y el campo clave es opcional.

Un anuncio sin llave es una declaración firmada de que el remitente ejecuta Nymchat, lo que permite al sending path saltar un envoltorio especulativo de protocolo cruzado que de lo contrario tendría que incluir para cualquier persona que no pueda identificar.

4.2 Un dispositivo que no puede abrir la raíz permanece en silencio

El anuncio es reemplazable: un evento por identidad, el último registro gana.Eso es lo que hace que el diseño de un solo registro funcione, y es también lo que hace que un dispositivo sin conexión sea peligroso si publica.Un dispositivo que anunció una llave que había creado para sí mismo bloquearía el registro real y enviaría a cada compañero a cifrar bajo una llave que los otros dispositivos no pueden abrir.

Así que un dispositivo que conoce una raíz existe pero no puede abrirla no publica ningún anuncio en absoluto.No está roto y no está bloqueado de la aplicación: todavía lee cada mensaje para el que tiene las claves y todavía envía de forma clásica, al tiempo que invita al usuario a vincularlo.El silencio es el comportamiento correcto para un dispositivo que no puede hablar por la identidad.

5Descubrimiento y la decisión de enviar

Los clientes aprenden las claves de los pares de dos maneras.Una suscripción permanente cubre a las personas con las que un usuario realmente se corresponde -conversaciones abiertas y miembros del grupo- por lo que sus anuncios llegan como eventos ordinarios.Para un compañero se reunió por primera vez, una consulta de un solo golpe se ejecuta en el tiempo de envío, limitado a 2,5 segundos; si no se resuelve, el mensaje se vuelve clásico, que es el comportamiento que existió antes de que se añadiera el post-cuántico en lugar de un nuevo modo de fracaso.

Un usuario que conecta un nuevo dispositivo, o que se desplaza de una extensión de navegador de inicio de sesión a una clave local, se convierte en post-cuántico capaz de medio-conversación, y un permanentemente caché “no” los mantendría en la encriptación clásica para la vida del anuncio.

5.1 ¿Por qué no hay un ataque de descenso?

La decisión de enrutamiento se reduce a una sola pregunta:

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

No hay negociación de capacidades, no hay lista de algoritmos respaldados, y no hay campo que un atacante pueda limpiar para forzar un camino más débil. es El modo de fracaso de un anuncio retirado o retenido es que el mensaje va a ser clásico - el status quo antes de esta característica - en lugar de que un mensaje híbrido se reduzca a algo falsificable.

La inversa también mantiene y importa más: un cliente envía híbrido Sólo Cuando posee una llave, y mantener la llave es prueba de que el destinatario puede decapsular.No hay estado en el que un mensaje se envía post-cuántico a alguien que no puede leerlo.

6La construcción híbrida

Un texto de cifrado NIP-44 no modificado es la capa interna, y ML-KEM tecla un AEAD externo alrededor de ella:

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 secretos aún deben ser recuperados para leer el mensaje: la capa exterior sólo produce un texto cifrado NIP-44, y la apertura que necesita el clásico ECDH. Un adversario cuántico que rompe secp256k1 obtiene la clave interna y todavía se enfrenta a ML-KEM; una ruptura de ML-KEM corta la capa exterior y deja NIP-44 en pie.

• kem_ss nada en esta derivación toca la salida cruda ECDH, que es lo que Sección 6.1 gira en.
• kem_ct, recip_kem_pk y ambas claves de identidad están vinculadas como datos asociados, por lo que la capa externa está comprometida con la transcripción exacta que la produjo.

La clave ML-KEM del destinatario es duradera, pero cada mensaje lleva un texto de cifrado independiente y, por lo tanto, una clave independiente. kem_ssEsto es lo que hace que la derivación del nonce en lugar de aleatoriar suene: ChaCha20-Poly1305 se rompe por reutilización de un par (chave, noce), y aquí la clave misma es nueva para cada mensaje, por lo que ningún par puede repetirse.

6.1 Por qué las capas se mantienen separadas

La alternativa es mezclar ambos secretos en una sola clave de conversación y enviarla a NIP-44:

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

Esa construcción suena como la criptografía.Tiene un problema estructural: necesita ecdh_x, la coordenada cruda x de la salida ECDH, como material clave - y una extensión del navegador (PNI-07) o un firmante remoto (PNI-46Realiza NIP-44 en nombre del llamador y devuelve un texto cifrado, que es todo el punto de mantener la clave en algún lugar donde la aplicación no puede llegar.

La mezcla de los secretos, por lo tanto, excluye cada login que mantiene la clave de identidad en un signatario, es decir, los usuarios más cuidadosos, y ninguna cantidad de trabajo en la derivación de la clave puede cambiarla.Layering elimina la dependencia: NIP-44 permanece entero y es producido por lo que mantiene la clave de identidad, signatario incluido, mientras que la mitad KEM se calcula a partir del código de recuperación que el cliente mantiene directamente.

El costo es ancho de banda, y no es pequeño. El texto cifrado de ML-KEM es de 1.088 bytes y corre en cada mensaje, base64url-codificado a 1.451 caracteres; el AEAD externo añade una etiqueta de 16 bytes Poly1305 y expande la carga útil de NIP-44 que envuelve por un tercero. Un mensaje de 50 caracteres crece de 176 bytes a 1.712, y un mensaje de 2.000 caracteres de 2.820 a 5.238. El piso es aproximadamente 1,5 KB por mensaje independientemente de cuán corto sea el mensaje, que es el precio de encapsular fresco cada vez en lugar de reutilizar un secreto compartido.

6.2 Cargas auto-descriptivas

El pq2. El prefixo hace que la implementación sea incremental: es auto-descriptiva, por lo que un cliente elige el camino de descifrado inspeccionando la carga útil en lugar de confiar en una etiqueta o recordando lo que apoya un compañero.Un lector que no reconoce un prefixo no abre esa carga útil en lugar de leerla mal, y los mensajes sellados antes de cada lado podrían hacer que el post-cuántico permanezca legible como el NIP-44 ordinario sin migración.

6.3 Ambas capas del envoltorio de regalo

A PNI-17 El mensaje personal es un PNI-59 Envase de regalo: un rumor sin firmar, sellado bajo la clave de identidad del remitente (tipo 13), luego envuelto bajo una llave de lanzamiento generada por mensaje (tipo 1059). En un login que mantiene la clave de identidad directamente, Nymchat híbrida ambas capas, cada una con su propia encapsulación.

El sello es producido por el firmante como NIP-44 ordinario – la aplicación nunca ve la clave que lo hace – por lo que no puede ser híbrido en su lugar. Esto no cuesta nada contra el ataque en cuestión: el sello es accesible sólo a través del envoltorio, y el sello es lo que almacena un grabador. Un oponente que mantiene el tráfico registrado debe romper el ML-KEM antes de que un sello sea incluso visible para atacar.

7Mensajes de grupo y cobertura parcial

Un mensaje de grupo no es un solo texto cifrado. Es el mismo texto simple enviado a cada miembro, cada copia encapsulada a la propia clave ML-KEM de ese miembro. Un miembro que ha publicado una clave recibe un envoltorio híbrido; uno que no tiene un envoltorio clásico.

Esto crea un problema de contabilidad que una implementación ingenua se equivoca. Si ocho de los diez miembros reciben una copia híbrida, el mensaje es no Un oponente necesita una copia clásica de un texto simple que es idéntico en todos los diez, por lo que el mensaje es protegido sólo si cada La copia es.

Nymchat, por lo tanto, rastrea la cobertura por mensaje durante el fan-out - el recuento solo es conocido mientras se están construyendo los envases - y el badge informa de que es resistente a los cuánticos a 8 de los 10 miembros, en lugar de reclamar que el mensaje está protegido. recibido mensaje de grupo (sólo el remitente cuenta el fan-out), la interfaz reporta protección parcial en lugar de completa.

7.1 Lo que informa el escudo

El escudo dice la verdad sobre el Mensaje, no sobre el software que lo envió:

• Protección completa: cada copia de este texto simple salió híbrida.
• Parcial: algunas copias de un mensaje de grupo salieron de forma clásica. dibujado degradado en lugar de completo, porque una copia clásica de un texto simple idéntico en todos ellos es una necesidad del adversario.
• El clásico se declara de forma directa en lugar de mostrarse como sin badge, porque un indicador ausente es ambiguo entre “unprotected”, “broken”, y “esta construcción carece de la característica”.

El veredicto se registra cuando el mensaje es sellado en lugar de recompilado de lo que anuncia un compañero más tarde.El texto de cifrado que ya existe no puede ser mejor protegido de lo que era, y una interfaz que rediseña los antiguos mensajes sobre la fuerza de un nuevo anuncio estaría afirmando algo falso sobre los bytes en un relay.

Las reglas de grupo de arriba pila en la parte superior de esto en lugar de reemplazarlo: un mensaje de grupo está completamente protegido sólo cuando la copia de cada miembro fue, y un mensaje de grupo recibido sin cuenta de cobertura muestra parcial.

8Copias dirigidas a ti mismo

Varias cosas que un cliente almacena se encriptan para la identidad del usuario: configuraciones sincronizadas, la lista de conversaciones, las claves de grupo y el archivo de mensajes. Estas cargan más acerca de un usuario que la mayoría de los mensajes individuales, por lo que dejarlos clásicos los convertiría en el artefacto más débil almacenado independientemente de cuán cuidadosamente los mensajes mismos fueron sellados. Utilizan el mismo híbrido, encapsulado en la propia clave derivada de la raíz del usuario, con una excepción descrita en la Sección 3.2, la nymchat-pq-root categoría misma, que no puede ser sellada bajo una llave que sólo puede producir.

Un blob de configuración o una fila de archivos se sienta en un lugar durante años, que es exactamente la forma de lo que un adversario de la cosecha-ahora-descifrado-posteriormente recoge -mucho más que cualquier mensaje único, que es al menos efímero en la propia mente del usuario.

Una restricción rige el formato aquí en lugar de la clave. Una copia auto-adrezada debe ser legible por cada dispositivo en la cuenta, por lo que cada dispositivo anuncia lo que puede abrir en el listado que lleva su anuncio, y la cuenta sólo escribe lo que todos ellos pueden leer. Escribir cualquier otra cosa bloquearía un dispositivo fuera de sus propias configuraciones - el mismo fracaso silencioso Sección 3.2 evita por otros medios, llegando de una dirección diferente.

9Rotación

El epoch El contador en la derivación es lo que hace posible la rotación sin nuevo material clave. Incrementarlo produce un nuevo par de teclas de la misma raíz y un anuncio reeditado; los pares toman la nueva clave del registro reemplazable.

9.1 Se conservan las antiguas épocas, y nada es reencriptado

Un cliente construye candidatos de descifrado desde la época actual hasta la época − 3, por lo que un mensaje sellado poco antes de una rotación todavía se abre contra el par de teclas que era actual cuando se envió.

Esa ventana es lo que hace que la rotación sea segura: sin ella, cada rotación estropearía lo que estuviera en vuelo.Todo lo ya sellado permanece legible para la vida de la identidad, porque un mensaje que el usuario ya no puede abrir es estrictamente peor para ellos que uno cuya protección no puede mejorarse retroactivamente (Sección 10.5).

10Lo que no protege

Un documento que solo enumera lo que un diseño logra no describe un sistema, y sobreestimar una propiedad de seguridad en una interfaz es peor que omitirlo.

10.1 La raíz es un segundo secreto, y perderla es irrecuperable

Este es el precio real del diseño. La restricción en la Sección 2 de que un usuario debe tener exactamente una cosa para mantener no puede ser cumplida: el nsec solo no reconstruye la clave post-cuántica, porque el punto es que ningún valor público y ningún otro secreto la expone. Si ningún dispositivo tiene la raíz y ninguno de los envoltorios de la Sección 3.2 se puede abrir, el material sellado a la clave derivada de la raíz no es recuperable.

Con la transferencia manual el único camino, esto es más agudo de lo que puede leer por primera vez. nympq1… El código en cualquier lugar tiene exactamente una copia de él, en un dispositivo, y la pérdida de ese dispositivo pierde cada mensaje post-cuántico, configuración blob y línea de archivo sellada a él. nsec no ayuda; esa es la propiedad en la que se basa todo el diseño.

Un atacante ataca el camino más barato disponible, por lo que un esquema vale lo que su ruta de recuperación más débil vale - una frase memorable, por ejemplo, pondría la cosa entera en lo que valga la frase, y la línea envuelta es exactamente el artefacto que un adversario recogido-ahora-descifrado-posteriormente recoge y moldea offline en el tiempo libre.

10.2 Autenticación, como distinta a la confidencialidad

Cada firma en Nostr es Schnorr sobre secp256k1, y eso no cambia aquí. Un oponente con una computadora cuántica podría forjar firmas e impersonar a un usuario en tiempo real. Lo que el intercambio de claves híbridos derrota es la cosecha-ahora-descifrado-más tarde: un atacante que registra el tráfico hoy no puede leerlo más adelante. No hace que un mensaje sea inexcusable contra un oponente que ya tiene la máquina. Esta distinción se transporta a las aplicaciones deliberadamente: el indicador de padlock informa de la autenticación, el escudo informa de la confidencialidad, y son glifos separados porque un mensaje puede tener uno sin el otro.

El vínculo entre un npub y una clave ML-KEM es una firma secp256k1, por lo que un oponente que pueda forjarlas puede sustituir una clave propia.

10.3 Metadatos

El envase de regalo oculta al remitente, al destinatario más allá de un único p La etiqueta, el tipo y el timestamp del mensaje interno. No oculta que un evento existe, su tamaño, o cuando un relay lo recibió.

10.4 La red offline

El transporte de redes Bluetooth de Nymchat es un protocolo separado con su propio toque de mano, y no está cubierto por este trabajo.

10.5 Mensajes ya enviados

El texto de cifrado registrado mientras ambos lados todavía eran clásicos permanece clásico permanentemente. Ya existe y no puede ser sellado de nuevo. La protección comienza en el mensaje donde ambos lados tenían las claves post cuánticas, no en el momento en que la función se encendía.

11Alternativas consideradas

12Paridad de Implementación

Nymchat ofrece dos implementaciones independientes de esta construcción: una en JavaScript para la aplicación web, una en Dart para las aplicaciones móviles, incluyendo un puerto ML-KEM-768 desde el principio.

La implementación de Dart ML-KEM es validada contra el oficial NIST ACVP Teste de respuestas conocidas para ML-KEM-768 (ML-KEM-*-FIPS203) — 25 claves de generación, 25 encapsulaciones y 10 casos de decapsulación, ejecutados como su propia suite. Estos son los vectores que NIST publica para validar una implementación, por lo que pasarlos es evidencia de que el puerto es correcto, no sólo evidencia de que los dos clientes están de acuerdo entre sí. Más allá de eso, una fijación compartida de vectores de prueba — derivación de semillas, encapsulación, ambos formatos de carga útil y envases de regalos completos — se genera a partir de la referencia de JavaScript y se verifica por ambas suites de pruebas. El secreto raíz extiende esa fijación en lugar de reemplazarla: raíz a semilla, raíz a clave, huella pública de la raíz, y la clave derivada, noce y los datos asociados de la nympq1… Una divergencia en cualquiera de las implementaciones falla el build en lugar de producir un mensaje que el otro cliente no puede abrir.

Es lo que dice a un dispositivo “esto es la raíz que tengo” de “esto es otro”, y un cliente que no podía reproducir la huella digital de otro cliente leería un registro perfectamente bueno como ningún registro en absoluto - y luego, siguiendo la Sección 3.3, minar una segunda raíz y dividir la identidad.