Um componente padronizado é um ponto de partida para revisão, não um certificado para todo o mensageiro.
ML-KEM-768 ajuda duas partes a estabelecer um segredo compartilhado que pode então ser usado para proteger mensagens. É um componente de um sistema de mensagens, não um protocolo de chat completo, uma cifra de mensagens ou um certificado de que um aplicativo é seguro.
O NIST publicou o FIPS 203 em 13 de agosto de 2024, padronizando ML-KEM e seus conjuntos de parâmetros 512, 768 e 1024. Sua segurança se baseia em problemas de reticulados considerados resistentes a ataques quânticos. “Considerados resistentes” é uma premissa de segurança sustentada por análise, não uma promessa de que nenhuma fragilidade futura seja possível. NIST FIPS 203.
Onde um KEM se encaixa em uma conversa criptografada
Uma forma útil de interpretar uma afirmação sobre criptografia é acompanhar o material de chave:
- Autentique o interlocutor pretendido. Uma troca de chaves com um impostor continua sendo uma troca de chaves com a pessoa errada.
- Estabeleça material secreto compartilhado. Um KEM contribui com um segredo por meio de encapsulamento e desencapsulamento.
- Derive chaves para suas finalidades específicas. Uma função de derivação de chaves separa o material usado pelas diferentes partes do protocolo.
- Criptografe e autentique as mensagens. Um esquema de criptografia autenticada protege o conteúdo e detecta modificações não autorizadas.
- Gerencie a sessão ao longo do tempo. Rotação e exclusão de chaves, mudanças de dispositivo e recuperação determinam o que um comprometimento posterior pode expor.
Essas etapas explicam por que um padrão para a segunda etapa não pode validar todo o aplicativo. As perguntas frequentes do NIST sobre criptografia pós-quântica fornecem contexto para implantar os novos padrões.
Por que combinar ML-KEM com acordo de chaves clássico?
Um projeto híbrido usa um componente pós-quântico junto com um componente clássico, como Diffie–Hellman em curvas elípticas. O benefício pretendido é evitar depender exclusivamente de qualquer um dos conjuntos de premissas durante uma transição.
A afirmação de segurança pertence ao combinador e ao protocolo completos, não apenas a uma lista de dois algoritmos. Os revisores precisam saber quais entradas são autenticadas, como são codificadas e combinadas, qual contexto é vinculado à derivação e o que acontece quando um componente falha. Concatenar segredos sem uma construção especificada não é um argumento de segurança.
Para os usuários, a pergunta prática não é “A página de configurações diz que é resistente a ataques quânticos?”. É “Quais conversas e versões realmente usam essa construção, e quais evidências sustentam essa afirmação?”.
O que o Livara documenta
A documentação de segurança do Livara descreve sessões LVR1 de conversas diretas usando material clássico P-256 e ML-KEM-768, com AES-256-GCM para o conteúdo. Ela descreve grupos privados LGS1 como cadeias de remetente distribuídas por sessões LVR1 entre pares. São camadas diferentes: uma mensagem de grupo comum não é necessariamente uma nova troca ML-KEM para cada destinatário.
Leia essa documentação como a descrição do desenvolvedor. Nomear primitivas padronizadas não demonstra que a composição própria do Livara tenha sido auditada de forma independente ou que toda versão instalada a implemente corretamente. O Proof Lab limita explicitamente sua demonstração no navegador: ela não executa os ratchets completos de LVR1/LGS1 nem constitui uma auditoria do protocolo.
O que a proteção pós-quântica não cobre
| Pergunta | Por que ML-KEM sozinho não a responde |
|---|---|
| Um destinatário pode copiar minha mensagem? | O destinatário recebe conteúdo legível. |
| Meu dispositivo está livre de spyware? | A integridade do dispositivo final é uma premissa de confiança separada. |
| Os backups estão protegidos? | As chaves de backup e as regras de recuperação precisam de um projeto próprio. |
| Mudanças nos membros do grupo são seguras? | As regras de autenticação, composição do grupo e renovação de chaves importam. |
| O serviço retém metadados? | A criptografia do conteúdo não oculta automaticamente roteamento ou horários. |
| Uma chamada é protegida da mesma forma que uma conversa de texto? | A sinalização e a mídia da chamada podem usar protocolos diferentes. |
O modelo de ameaças do Livara também distingue conversas privadas de canais públicos e reconhece a exposição no nível do dispositivo. Não estenda uma afirmação sobre conversas diretas a todas as superfícies do produto.
Lista de verificação para quem busca “mensagens FIPS 203”
Peça o conjunto exato de parâmetros e a versão do protocolo; uma descrição da autenticação dos interlocutores e da combinação de chaves; as versões de cliente compatíveis; o comportamento com clientes incompatíveis; e testes ou achados de revisão ligados à implementação distribuída. Se um fornecedor afirmar ter validação FIPS, peça o registro de validação relevante e seu escopo. Usar um algoritmo descrito em uma publicação FIPS não é, por si só, evidência de validação do produto ou módulo.
Não deduza duração da bateria, vazão ou responsividade do aplicativo a partir do nome do parâmetro. Essas características exigem medições com dispositivo, build e carga de trabalho documentados.
A mudança útil para mensagens é uma nova ferramenta para a confidencialidade de longo prazo. Seu valor depende da integração, da implementação e dos limites operacionais, não de substituir um rótulo de marketing por outro.
