Nymchat whitepaper técnico
Acordo de chave pós-quântica no Nymchat
Distribuir as chaves públicas ML-KEM-768 em Nostr sem um diretório ou um registro, e semeá-las de um segredo que nenhum valor público expõe.
Adicionar uma troca de chaves pós-quântica a um mensageiro não é, na maioria das vezes, um problema de criptografia.Os primitivos são padronizados e as bibliotecas existem. Segundo Este artigo descreve como o Nymchat responde a isso – de onde vem a segunda chave, como ela atinge as pessoas que precisam dela, e o que a interface pode reivindicar sobre o resultado – e, na última seção, o que esse resultado não protege.
Esta página foi traduzida automaticamente por conveniência. O original em inglês é a versão aplicável.
1O problema
Nossas mensagens privadas são criptografadas com NIP-44, que tem duas metades separáveis.A metade que scrambles o texto simples — ChaCha20 com uma tag HMAC-SHA256, chaveado através HKDF (RFC 5869) — não é significativamente ameaçada por um computador quântico; o algoritmo de Grover custa uma aceleração de raiz quadrada contra uma chave simétrica, e 256 bits absorvem isso. Concorda A curva elíptica de Diffie-Hellman Página 256K1Recuperar uma chave privada de sua contraparte pública retroativamente expõe cada segredo compartilhado que a chave já produziu.
A ameaça que isso cria não é adiada até que tal máquina exista. Um adversário com armazenamento pode gravar texto criptográfico hoje e descriptografá-lo sempre que a capacidade chegar. Qualquer coisa enviada agora que ainda importa então já está comprometida. Este é o ataque específico que uma troca de chaves pós-quântica derrota, e é por isso que o trabalho não pode esperar para a máquina ser construída.
1.1 A pergunta que este artigo responde
A atenuante é bem compreendida: execute um mecanismo de encapsulação de chave pós-quântica ao lado da troca clássica, de modo que um atacante tenha que quebrar ambos para ler qualquer coisa.Página 203Isso imediatamente levanta um problema de distribuição:
Adicione uma troca pós-quântica e você precisa de uma segunda – sua chave pública ML-KEM.
Um npub é autônomo. Você pode escrevê-lo em papel, lê-lo em voz alta, ou digitalizá-lo a partir de uma tela, e é tudo o que alguém precisa para criptografá-lo para você. Uma chave pública ML-KEM-768 é de 1.184 bytes. Não pode ser lido em voz alta, não vai caber em um nome de usuário, e não pertence a um código QR além de uma identidade que é apenas 32 bytes.
A parte mais difícil é que uma segunda chave traz três problemas distintos, e o resto deste artigo é em grande parte uma resposta a eles:
- pode ser substituído. Uma chave que ninguém pode ler de uma olhada é exatamente o tipo de coisa que um atacante troca por seu próprio.
- Ele deve concordar em todos os dispositivos de um usuário. A mesma conta em um telefone e um laptop deve apresentar a mesma chave, ou as mensagens seladas para um não podem ser abertas no outro.
- pode ser perdido. A chave pública é republicada a partir de um segredo, então o que realmente tem que sobreviver é esse segredo – e pela construção nada mais reconstrói.
2Design de restrições
Quatro restrições moldaram a resposta, e elas excluem a maioria dos desenhos óbvios antes de qualquer código ser escrito.
- O mínimo de segredos possível. Nossos usuários já carregam exatamente um segredo, o nsec. Cada segredo adicional é outra maneira de perder seu histórico, e alguém que sabe fazer backup de um nsec não saberá fazer backup de qualquer outra coisa. Secção 3.1 mostra que este não pode ser encontrado diretamente - uma chave pós-quântica derivada do nsec não fornece proteção pós-quântica em tudo - então o design gasta exatamente um segredo e não mais: um único pedaço de material chave, gerado uma vez por identidade, apresentado na mesma forma que o nsec e no mesmo lugar, de modo que quem sabe como manter um sabe como manter o outro. Secção 10.1 é honesto sobre o que isso ainda custa.
- Sem autoridade Não há servidor que possa ser confiável para dizer qual chave pertence a quem.
- Muitos aparelhos, uma única identidade. Qualquer material chave que exista deve acabar sendo idêntico em todos eles, e os caminhos que o levam lá não devem ser lidos pelo adversário contra o qual o recurso está defendendo.
- Nenhuma negociação . Qualquer troca na banda de “que cifras você suporta?” é uma superfície que um atacante pode cortar para forçar a opção mais fraca.
3Um segredo raiz independente
A decisão de carga é que a chave de decapsulação ML-KEM é semeada a partir de material chave que nenhum valor público expõe.
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 raiz é apresentada ao usuário da forma como um nsec é: Bexiga32 Com o prefixo humanamente legível
nympqAssim, lê-se como nympq1…, mostrado ao lado do nsec na tela de identidade por trás da mesma interação revelar, copiado com o mesmo controle, nunca logado e nunca enviado em qualquer lugar no claro.
O sal é separado de domínio com propósito, então nenhum outro segredo pode derivar o mesmo par de chaves. epoch A rotação dos motores contrários (Seção 9).
3.1 Por que a chave não pode ser derivada da chave de identidade
O design óbvio é semear o keypair do segredo que o usuário já tem:
seed = HKDF(salt = "…", IKM = nsec) // do not do this
É atraente por quatro razões, todas elas reais: nada de novo para fazer backup, porque o nsec já é o backup; cada dispositivo que concorda por construção, sem nenhum protocolo de sincronização para ir errado; um anúncio substituível por identidade sendo obviamente correto, porque os dispositivos não podem discordar sobre a chave; e a chave existente antes de ser publicada, para que um cliente possa selar algo para si mesmo em primeira mão.
Todos os quatro benefícios são inúteis, por uma razão. O algoritmo de Shor corre contra um npub publicado produz o nsec. A derivação de sementes é um algoritmo público sobre o nsec. Assim, o adversário que quebra a metade clássica reconstrói a metade pós-quântica executando o mesmo HKDF que todos os outros executam. Contra a colheita-agora-descript-mais tarde - a única ameaça que a função existe para parar - uma chave derivada desta forma não adiciona nada.
A chave de decapsulação ML-KEM deve vir da entropia que não é derivável do nsec nem jamais transmitida sob criptografia clássica-só.
A segunda cláusula dessa regra funciona tanto quanto a primeira.Um segredo gerado de forma independente que é então sincronizado entre os dispositivos de um usuário dentro de uma mensagem NIP-44 comum é o mesmo fracasso com passos adicionais: um adversário registra essa mensagem hoje e recupera sua chave clássica mais tarde, e a raiz cai.
3.2 Obter a raiz para os outros dispositivos do usuário
Constrangimento 3 da Seção 2 – uma identidade, vários dispositivos – não pode ser satisfeito por aritmética aqui, porque o ponto é que a chave não é uma função de qualquer coisa que os dispositivos já compartilham. nympq1… Código em si.
A raiz é exibida como nympq1… ao lado do nsec, e um segundo dispositivo aceita-o colado no mesmo painel. Isso é todo o mecanismo. Um dispositivo que não recebeu o código não pode participar, o que a Seção 4.2 descreve.
A regra na Seção 3.1 diz que a raiz nunca pode viajar sob criptografia clássica-só, e qualquer mecanismo que tornaria isso automático - sincronizando-o através de um relê, envolvendo-o com a chave de identidade - viola exatamente isso.
O formato deixa espaço para um caminho embrulhado: um registro pode carregar uma lista de embrulhos, cada um com um blob AEAD sob uma chave que o usuário pode reproduzir em outro dispositivo - uma saída PRF passkey, por exemplo. nympq1… O código é o único caminho a percorrer.A Seção 10.1 diz quanto custa.
O próprio registro vive em sua própria categoria de configurações, nymchat-pq-rootMesmo carregando nenhum envelopes faz o trabalho necessário: sua presença é como um segundo dispositivo aprende que essa identidade já tem uma raiz, o que é o que a impede de montar um rival (Seção 3.3).
O nymchat-pq-root Categoria deve não Essa linha carrega a única cópia da raiz, então selá-la sob uma chave derivada da raiz é uma fechadura cuja chave está dentro da caixa: nenhum dispositivo poderia nunca abri-la, incluindo aquele que a escreveu. É selada clássica - NIP-44 por si só - ou não em tudo. Este é o único lugar que o design aceita proteção clássica-só, e pode pagar: a linha não carrega raiz hoje, apenas o fato de que existe.
Todas as outras categorias de configurações podem e devem usar a chave derivada da raiz.Esta é a única exceção, e é uma exceção sobre circularidade, em vez de sobre força.
3.3 Geração e adoção
No boot, mantendo uma identidade duradoura, um cliente funciona nesta ordem:
- Procure por um existente
nymchat-pq-rootO recorde. - Recorde encontrado, e este dispositivo pode desbloqueá-lo - adotá-la e anunciar essa identidade como capaz pós-quântica.
- Recorde encontrado, e este dispositivo não pode desbloqueá-lo - não gerar uma nova raiz, e não publicar nenhum anúncio em tudo.
nympq1…de um dispositivo que já o possui. - Não há recorde - gerar uma raiz, publicar o registro, anunciar e mostrar o
nympq1…o código para o usuário uma vez para que eles possam salvá-lo.
Passo 3 é o passo que é fácil de errar, e é por isso que a ordem é escrita em vez de deixada para cada implementação. Dois dispositivos que cada um decide gerar uma raiz produzem duas raízes independentes sob uma identidade, e isso é o fracasso que esta ordem existe para impedir.
4Anúncio de Capacidade
A metade pública do par de chaves derivado é publicada como um endereçável
Página 01
evento — tipo 30078, marcado 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ém um evento por (kind, pubkey, d-tag), de modo que uma república substitui o anúncio anterior no lugar. Cada identidade, portanto, tem exatamente um registro atual, que é o que faz com que “ olhe para a chave de Alice” um único levantamento inequívoco em vez de uma lista para conciliar.
A assinatura é obrigatória. O evento é assinado pela chave de identidade, então a afirmação “esta chave ML-KEM pertence a este npub” é exatamente tão forte quanto o próprio npub. Substituir uma chave de encapsulação diferente requer forjar uma assinatura secp256k1. Um atacante que pode fazer isso não precisa se preocupar com o KEM.
Os anúncios expiram. Um dia de sete NIP-40 A expiração, republicada a cada 24 horas, mantém o registro de uma declaração sobre um cliente que ainda está em execução, em vez de uma que antes era.
Um anúncio perdido é lido exatamente como aquele que nunca carregou uma chave: os pares enviam um NIP-44 comum, que cada login pode ler, e o cliente retoma a troca pós-quântica em sua próxima conexão, quando republica.Então, ficar em silêncio por mais de uma semana custa proteção para as mensagens enviadas durante a lacuna - elas são classificadamente criptografadas em vez de resistentes a quantidades - e não custa nada mais.
Sem um, um registro sobrevive à chave que chama: um dispositivo que é apagado, redefinido ou tem sua raiz substituída deixa uma instrução de pé para encapsular a uma chave que ninguém mais detém, e as mensagens enviadas sob ele são perdidas sem erro em qualquer lado.
O campo chave nomeia seu formato. O campo é pk2, e o dígito é parte do contrato em vez de decoração: ele nomeia o formato de carga útil com o qual a chave pode ser usada. Um leitor que não reconhece o campo conclui o cliente “Nymchat, nenhuma chave pós-quântica” e envia o NIP-44 comum, que cada login pode ler. Isso é a direção de falha correta, e vale a pena dizer como uma regra a numeração do formato existe para fazer valer: uma reivindicação de capacidade não reconhecida deve custar proteção, nunca entrega. Uma chave que um colega não pode usar é pior do que nenhuma chave em tudo, porque a mensagem que produz é perdida sem erro em qualquer lado.
4.1 A ausência é significativa e triplicada
Um detalhe sutil, mas importante: o anúncio é publicado por todos os clientes do Nymchat, não apenas aqueles capazes de pós-quântico, e o campo chave é opcional.
| Observado | Significa | Envie um comportamento |
|---|---|---|
| Anúncio com uma chave | Nymchat, pós-quântico capaz | Híbrido |
| Anúncio, nenhuma chave | Nymchat, clássico apenas – pós-quântico, ou um dispositivo ainda não ligado à raiz da identidade | Classificação NIP-17 |
| Nenhum anúncio | Cliente desconhecido. Pode ser qualquer usuário do Nostr ou Bitchat | Clássico, mais um envelope de compatibilidade |
Um anúncio sem chave é uma declaração assinada de que o remetente executa o Nymchat, o que permite que o caminho de envio salte um envelope especulativo de protocolo cruzado que de outra forma teria que incluir para qualquer pessoa que não possa identificar.
4.2 Um dispositivo que não pode abrir a raiz permanece em silêncio
O anúncio é substituível: um evento por identidade, ganha a última gravação.Isso é o que faz com que o projeto de registro único funcione, e é também o que torna um dispositivo desligado perigoso se ele publica.Um dispositivo que anunciou uma chave que ele tinha criado para si mesmo iria esmagar o registro real e enviar todos os pares para criptografar sob uma chave que os outros dispositivos não podem abrir.
Assim, um dispositivo que conhece uma raiz existe, mas não pode abri-la, não publica nenhum anúncio.Não é quebrado e não está bloqueado do aplicativo: ainda lê cada mensagem para a qual tem as chaves e ainda envia de forma clássica, ao mesmo tempo em que convida o usuário a vinculá-la.
5Descoberta e decisão de envio
Os clientes aprendem as chaves dos pares de duas maneiras.Uma assinatura permanente cobre as pessoas com as quais um usuário realmente corresponde – conversas abertas e membros do grupo – de modo que seus anúncios chegam como eventos normais.Para um peer encontrado pela primeira vez, uma consulta única é executada no tempo de envio, limitada a 2,5 segundos; se não for resolvida, a mensagem passa a ser clássica, que é o comportamento que existia antes de o pós-quântico ter sido adicionado em vez de um novo modo de falha.
Um usuário que vincula um novo dispositivo, ou que se move de um login de extensão de navegador para uma chave local, torna-se pós-quântico capaz de meio-conversa, e um permanentemente cache “não” mantê-los em criptografia clássica para a vida do anúncio.
5.1 Por que não há ataque de depreciação
A decisão de roteamento reduz-se a uma única pergunta:
pq = (we hold a signed, unexpired ML-KEM key for this recipient)
Não há negociação de capacidade, nenhuma lista de algoritmos suportados, e nenhum campo um atacante pode limpar para forçar um caminho mais fraco. é O modo de falha de um anúncio retirado ou retido é que a mensagem vai clássica - o status quo antes deste recurso - em vez de que uma mensagem híbrida é reduzida a algo falsificável.
O contrário também detém e importa mais: um cliente envia híbrido Só quando detém uma chave, e detendo a chave é prova que o destinatário pode decapsular.Não há estado em que uma mensagem é enviada pós-quântico para alguém que não pode lê-la.
6Construção híbrida
Um texto de cifragem NIP-44 não modificado é a camada interna, e o ML-KEM chaves um AEAD externo ao redor dele:
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 ainda devem ser recuperados para ler a mensagem: a camada externa produz apenas um texto cifrado NIP-44, e a abertura que precisa do ECDH clássico. Um adversário quântico que quebra secp256k1 recebe a chave interna e ainda enfrenta o ML-KEM; uma ruptura do ML-KEM tira a camada externa e deixa o NIP-44 em pé.
kem_ssNada nesta derivação toca a saída ECDH crua, que é o que se transforma na Seção 6.1.kem_ct,recip_kem_pke ambas as chaves de identidade estão ligadas como dados associados, de modo que a camada externa está comprometida com a transcrição exata que a produziu.
A encapsulação é realizada fresca em cada mensagem.A chave ML-KEM do destinatário é duradoura, mas cada mensagem carrega um texto de encriptação independente e, portanto, uma chave independente.
kem_ssIsso é o que faz derivar o nonce em vez de randomizá-lo soar:
ChaCha20-Poly1305 Composição
é quebrado por reutilizar um par (chave, nonce), e aqui a chave em si é nova para cada mensagem, de modo que nenhum par pode repetir.
6.1 Por que as camadas permanecem separadas
A alternativa é misturar ambos os segredos em uma única chave de conversa e enviar isso para o NIP-44:
ck = HKDF-Extract(salt = "…",
IKM = ecdh_x || kem_ss || …) // do not do this
Essa construção soa como criptografia. tem um problema estrutural: ela precisa
ecdh_x, o coordenado x bruto da saída ECDH, como material-chave - e uma extensão do navegador (NIP-07) ou uma assinatura remota (NIP-46Ele executa NIP-44 em nome do chamador e devolve um texto cifrado, que é todo o ponto de segurar a chave em algum lugar onde o aplicativo não pode chegar.
Misturando os segredos, portanto, exclui cada login que mantém a chave de identidade em um signatário, ou seja, os usuários mais cuidadosos, e nenhuma quantidade de trabalho sobre a derivação da chave pode mudá-lo.Layering elimina a dependência: NIP-44 permanece inteiro e é produzido por qualquer coisa que detém a chave de identidade, signatário incluído, enquanto a metade KEM é calculada a partir do código de recuperação que o cliente detém diretamente.
O custo é largura de banda, e não é pequeno. O texto de cifragem ML-KEM é de 1.088 bytes e corre em cada mensagem, base64url-codificada para 1.451 caracteres; o AEAD externo adiciona uma tag Poly1305 de 16 bytes e expande a carga útil NIP-44 que envolve por um terço. Uma mensagem de 50 caracteres cresce de 176 bytes para 1.712, e uma de 2.000 caracteres de 2.820 para 5.238.
6.2 Auto-descrição de payloads
O pq2. O prefixo torna a implantação incremental: é auto-descrição, de modo que um cliente escolhe o caminho de descriptografia inspeccionando a carga útil em vez de confiar em uma tag ou lembrar o que um pares suporta. Um leitor que não reconhece um prefixo falha em abrir essa carga útil em vez de lê-la erradamente, e mensagens seladas antes de qualquer lado poderiam fazer o pós-quântico permanecer legível como o NIP-44 comum sem migração.
A decapsulação ML-KEM é projetada para nunca falhar: dado um texto de cifragem mal formado, a transformação Fujisaki-Okamoto retorna um segredo pseudo-acidental determinista em vez de um erro. Uma chave errada, portanto, não surge na camada KEM – ela surge como uma falha HMAC dentro do NIP-44, que é a mesma maneira que uma superfície de chave clássica errada. Os chamadores tratam ambos de forma idêntica, de modo que a falha não carrega nenhum sinal distintivo. É também o que torna a lista de candidatos da Seção 9.1 operável: um cliente tenta cada chave em turno e deixa o NIP-44 dizer qual era a correta.
6.3 As duas camadas do envelope de presente
A NIP-17 A mensagem pessoal é a NIP-59 Embalagem de presente: um rumor não assinado, selado sob a chave de identidade do remetente (tipo 13), em seguida, embalado sob uma chave lançável gerada por mensagem (tipo 1059). Em um login que detém a chave de identidade diretamente, o Nymchat hibridiza ambas as camadas, cada uma com sua própria encapsulação.
Um login de signatário recebe apenas a camada externa. O selo é produzido pelo signatário como NIP-44 comum – o aplicativo nunca vê a chave que o faz – por isso não pode ser híbrido no lugar. Isso não custa nada contra o ataque em questão: o selo é acessível apenas através do envelope, e o envelope é o que um gravador armazena. Um adversário que detém o tráfego registrado deve quebrar o ML-KEM antes que um selo seja mesmo visível para atacar.
7Mensagens de grupo e cobertura parcial
Uma mensagem de grupo não é um único texto cifrado. É o mesmo texto simples enviado a cada membro, cada cópia encapsulada na própria chave ML-KEM desse membro. Um membro que publicou uma chave recebe um envelope híbrido; um que não tem um envelope clássico.
Isso cria um problema de contabilidade que uma implementação ingênua fica errada. Se oito dos dez membros receberem uma cópia híbrida, a mensagem é não Um adversário precisa de uma cópia clássica de um texto simples que seja idêntico em todos os dez, então a mensagem é protegida apenas se todo A cópia é.
Nymchat, portanto, rastreia a cobertura por mensagem durante o fan-out – a contagem só é conhecível enquanto os envelopes estão sendo construídos – e o badge relata “resistente a quantidades a 8 de 10 membros” em vez de reivindicar que a mensagem é protegida. Recebido mensagem de grupo (só o remetente conta o fan-out), a interface relata proteção parcial em vez de completa.
7.1 O que o Escudo relata
O escudo diz a verdade sobre o mensageme não sobre o software que o enviou:
- Proteção completa: cada cópia deste texto simples saiu híbrida.
- Parcial: algumas cópias de uma mensagem de grupo saíram clássicas. desenhado degradado em vez de completo, porque uma cópia clássica de um texto simples idêntico em todos eles é uma necessidade adversária.
- O clássico é declarado direto em vez de exibido como nenhum badge, porque um indicador ausente é ambíguo entre “unprotected”, “broken”, e “esta construção carece do recurso”.
O veredicto é gravado quando a mensagem é selada em vez de recomputada a partir do que um colega anuncia mais tarde.Cyphertext que já existe não pode se tornar melhor protegido do que era, e uma interface que redreve mensagens antigas sobre a força de um novo anúncio seria afirmando algo falso sobre bytes em um relay.
As regras de grupo acima empilhar acima disso, em vez de substituí-lo: uma mensagem de grupo é totalmente protegida apenas quando a cópia de cada membro foi, e uma mensagem de grupo recebida sem contagem de cobertura mostra parcial.
8Cópia dirigida a si mesmo
Várias coisas que um cliente armazena são criptografadas para a própria identidade do usuário: configurações sincronizadas, a lista de conversas, chaves de grupo e o arquivo de mensagens. Estas carregam mais sobre um usuário do que a maioria das mensagens individuais, então deixá-las clássicas tornaria-as o artefato armazenado mais fraco, independentemente de quão cuidadosamente as próprias mensagens foram seladas. nymchat-pq-root categoria em si, que não pode ser selada sob uma chave que só ela pode produzir.
Um blob de configurações ou uma linha de arquivo fica em um lugar por anos, que é exatamente a forma de coisa que um adversário coleta - agora decriptado - mais tarde - muito mais do que qualquer mensagem única, que é pelo menos efêmera na própria mente do usuário.
Uma restrição rege o formato aqui, em vez da chave. todo cada dispositivo anuncia o que pode abrir na lista de anúncios, e a conta só escreve o que todos eles podem ler.Escrever qualquer outra coisa bloquearia um dispositivo fora de suas próprias configurações - a mesma falha silenciosa que a Seção 3.2 evita por outros meios, chegando de uma direção diferente.
Um dispositivo que detém a identidade, mas não a raiz, não pode abrir qualquer coisa selada para a chave derivada da raiz, incluindo suas próprias configurações.Isso é uma consequência deliberada, não uma supervisão, e é por isso que a Seção 3.3 tem um dispositivo para ligar em vez de mintar uma raiz fresca: uma segunda raiz não tornaria o blob legível, ele apenas dividiria o material chave da identidade em dois.Até que o usuário a conecte, o dispositivo continua funcionando – ele lê o que tem as chaves para e envia de forma clássica.
Um dispositivo que executa uma extensão do navegador ou um assinante remoto (NIP-46) não tem nenhum nsec a partir do qual derivar, mas ele detém o código de recuperação, e sob a construção estratificada da Seção 6.1 que é tudo o que a metade pós-quântica precisa: o assinante produz a camada NIP-44 como sempre tem, e o cliente chaves a camada externa em si.
9Rotação
O epoch O contador na derivação é o que torna a rotação possível sem novo material chave. Incrementando-o produz um novo par de chaves da mesma raiz e um anúncio republicado; os pares pegam a nova chave do registro substituível.
9.1 As velhas épocas são mantidas, e nada é re-encriptado
Um cliente constrói candidatos de descriptografia da era atual até a era − 3, de modo que uma mensagem selada pouco antes de uma rotação ainda se abre contra o par de chaves que era atual quando foi enviado.
Essa janela é o que torna a rotação segura de fazer: sem ela, cada rotação estragaria o que já estava em vôo.Tudo que já foi selado permanece legível para a vida da identidade, porque uma mensagem que o usuário não pode mais abrir é estritamente pior para eles do que uma cuja proteção não pode ser melhorada retroativamente (Seção 10.5).
10O que não protege
Um artigo que apenas lista o que um projeto consegue não é descrever um sistema, e exagerar uma propriedade de segurança em uma interface é pior do que omitê-lo.
A raiz é um segundo segredo, e perdê-lo é irrecuperável
Este é o preço real do projeto. A restrição na Seção 2 de que um usuário deve ter exatamente uma coisa para manter não pode ser cumprida: o nsec sozinho não reconstrói a chave pós-quântica, porque o ponto é que nenhum valor público e nenhum outro segredo a expõe. Se nenhum dispositivo detém a raiz e nenhum dos envelopes da Seção 3.2 pode ser aberto, o material selado para a chave derivada da raiz não é recuperável.
Com a transferência manual o único caminho, este é mais nítido do que pode ser lido pela primeira vez. nympq1… O código em qualquer lugar tem exatamente uma cópia dele, em um dispositivo, e perder esse dispositivo perde cada mensagem pós-quântica, configurações blob e linha de arquivo selada para ele.
nsec não ajuda; essa é a propriedade sobre a qual todo o design se baseia.
Um atacante ataca o caminho mais barato disponível, então um esquema vale o que sua rota de recuperação mais fraca vale - uma passsphrase memorável, por exemplo, colocaria toda a coisa em qualquer coisa que a passsphrase valha, e a linha embrulhada é exatamente o artefato que um adversário coleta e moe offline no tempo livre.
10.2 Autenticação, como distinta da confidencialidade
Cada assinatura em Nostr é Schnorr sobre secp256k1, e isso não muda aqui. Um adversário com um computador quântico poderia forjar assinaturas e fingir um usuário em tempo real. O que a troca de chaves híbrida derrota é colheita-agora-descriptografado-mais tarde: um atacante que registra o tráfego hoje não pode lê-lo mais tarde. Não torna uma mensagem imperdoável contra um adversário que já tem a máquina. Esta distinção é levada para os aplicativos deliberadamente - o indicador padlock relata autenticação, o escudo relata confidencialidade, e eles são glifos separados porque uma mensagem pode ter uma sem a outra.
O vínculo entre um npub e uma chave ML-KEM é uma assinatura secp256k1, de modo que um adversário que pode forjar esses pode substituir uma chave própria.
10.3 Metadados
A embalagem do presente esconde o remetente, o destinatário além de um único p A etiqueta, o tipo e o timestamp da mensagem interna. Não esconde que um evento existe, seu tamanho, ou quando um relê recebeu.
10.4 O Mesh Offline
O transporte de malha Bluetooth do Nymchat é um protocolo separado com seu próprio aperto de mão, e não é coberto por este trabalho.
10.5 Mensagens já enviadas
O texto de cifragem gravado enquanto ambos os lados ainda eram clássicos permanece clássico permanentemente. já existe e não pode ser selado novamente. A proteção começa na mensagem onde ambos os lados mantiveram chaves pós-quânticos, não no momento em que o recurso foi ligado.
11Alternativas consideradas
| Aproximação | Por que não |
|---|---|
| Derivando a chave pós-quântica da chave de identidade | A derivação é um algoritmo público sobre o nsec, e um adversário quântico recupera o nsec do npub publicado, então quebrando a metade clássica das mãos sobre a metade pós-quântica com ele. |
| Envie a raiz para outros dispositivos do usuário via NIP-44 | Uma raiz transmitida sob criptografia clássica-só é recuperável por qualquer pessoa que gravou essa mensagem e quebra sua chave mais tarde, que é o adversário que a raiz existe para parar. |
| Um par de teclas ML-KEM gerado separadamente em cada dispositivo | Rejeitado. Os dispositivos segurariam chaves de decapsulação diferentes, e um anúncio substituível por identidade não poderia carregá-los todos. Os pares criptografariam para qual chave foi publicada pela última vez, e todos os outros dispositivos não seriam capazes de ler o resultado. |
| Enrole a raiz sob um PIN | Rejeitado. Um PIN de quatro dígitos é de cerca de 13 bits contra um atacante off-line segurando a linha embrulhada. |
| Expanda o npub para carregar ambas as chaves | 1,184 bytes não é um identificador compartilhável, e isso quebraria toda análise de um endereço que é definido como 32 bytes pelo cliente Nostr existente. |
| Serviço de diretório chave | Reintroduzir a autoridade que a rede existe para evitar.Quem responde à pesquisa decide quem pode ler a mensagem. |
| Coloque a chave em cada mensagem | Não resolve nada: o remetente precisa do O receptor chave antes da primeira mensagem, o que é exatamente o caso com nenhuma mensagem anterior para carregá-la. |
| Capacidade de negociação em banda | Cria uma superfície de degradação. Um atacante que pode tirar uma bandeira de capacidade força o caminho clássico. |
| Apenas pós-quântico, sem perna clássica | Descarta décadas de análise de secp256k1 em troca de um primitivo muito mais jovem. ambos falha . |
12Paridade de Implementação
Nymchat fornece duas implementações independentes desta construção - uma em JavaScript para o aplicativo da web, uma em Dart para os aplicativos móveis, incluindo uma porta ML-KEM-768 do zero.
A implementação do Dart ML-KEM é validada contra o oficial
NÃO ACVP
Teste de resposta conhecida para ML-KEM-768 (ML-KEM-*-FIPS203) — 25 chave-geração, 25 encapsulação e 10 casos de decapsulação, executados como sua própria suíte. Esses são os vetores que o NIST publica para validar uma implementação, então passá-los é evidência de que a porta é correta, não apenas evidência de que os dois clientes estão de acordo uns com os outros. Além disso, uma fixação compartilhada de vetores de teste — derivação de sementes, encapsulação, ambos os formatos de carga útil e embalagens de presente completas — é gerada a partir da referência JavaScript e verificada por ambas as suítes de teste. O segredo raiz estende essa fixação em vez de substituí-la: raiz para semente, raiz para keypair, a impressão digital da raiz, e os dados derivados, nonce e associados da camada
nympq1… Uma divergência em qualquer implementação falha na construção em vez de produzir uma mensagem que o outro cliente não pode abrir.
É o que diz que um dispositivo “este é a raiz que eu tenho” de “este é um outro ”, e um cliente que não poderia reproduzir a impressão digital de outro cliente leria um registro perfeitamente bom como nenhum registro em tudo - e, em seguida, seguindo a Seção 3.3, minar uma segunda raiz e dividir a identidade.
O Nymchat é Fonte aberta AGPL-3.0. O núcleo criptográfico descrito aqui é
js/nym-crypto.js e js/modules/pq.js no site do cliente, e
lib/core/crypto/ com lib/features/identity/pq_registry.dart para os clientes móveis.
Para uma explicação mais curta e não técnica, veja Página da base de conhecimentos sobre criptografia quantum-resistente.