Um navegador pode executar criptografia forte; o código entregue ao navegador ainda precisa ser confiável.
Um navegador pode realizar criptografia de ponta a ponta localmente, incluindo o estabelecimento pós-quântico de chaves, sem instalar um aplicativo de mensagens nativo. A questão difícil não é saber se a matemática pode funcionar em uma aba. É saber se o aplicativo entregue, o tratamento das chaves e o caminho de atualização merecem a confiança exigida pela conversa.
O acesso pela web pode ser conveniente quando a instalação não está disponível. Isso não torna o aplicativo imune à censura, à hospedagem comprometida, a extensões maliciosas ou a um dispositivo comprometido.
Os componentes criptográficos do navegador
O WebCrypto expõe operações de baixo nível para criptografia, derivação de chaves, assinatura e gerenciamento de chaves. Implementações comuns oferecem primitivas como AES-GCM e ECDH. Essas operações são componentes, não um protocolo completo de mensagens autenticadas.
Uma aplicação web pode adicionar uma implementação de ML-KEM revisada, usando JavaScript ou WebAssembly, quando a API nativa necessária não está disponível. O suporte dos navegadores muda, portanto os desenvolvedores devem testar a disponibilidade dos recursos nas versões exatas de destino, em vez de presumir que todos os navegadores oferecem os mesmos algoritmos.
Um fluxo híbrido conceitual é:
- Gerar chaves apropriadas com aleatoriedade criptograficamente segura.
- Autenticar o material de chaves do interlocutor usando o mecanismo de identidade do protocolo.
- Obter contribuições clássicas e pós-quânticas para o segredo compartilhado.
- Combiná-las usando o esquema de derivação de chaves especificado e o contexto da conversa.
- Usar as chaves derivadas para criptografia autenticada, com tratamento correto de nonces e estado.
Esse é um esboço explicativo, não uma receita de implementação. O FIPS 203 padroniza o ML-KEM; não certifica uma aplicação específica de navegador nem define todas as etapas de um protocolo de chat.
A entrega por HTTPS faz parte do modelo de confiança
O servidor normalmente fornece o JavaScript e o WebAssembly que processarão o texto em claro. Um aplicativo alterado maliciosamente pode ler uma mensagem antes da criptografia ou depois da descriptografia, mesmo que sua biblioteca criptográfica use algoritmos sólidos.
O HTTPS ajuda a autenticar e proteger a entrega contra interferências da rede. Não prova que o operador da origem, seu sistema de implantação ou suas dependências estejam livres de comprometimento. Uma página HTTPS comum não é automaticamente um pacote de aplicativo assinado de forma independente.
As considerações de segurança do WebCrypto do W3C discutem a injeção de scripts e a necessidade de proteger a integridade da aplicação. Content Security Policy, o gerenciamento cuidadoso de dependências e outros controles de segurança web reduzem riscos, mas nenhum transforma um script arbitrário da mesma origem em um observador não confiável incapaz de acessar os dados da aplicação.
O WebAssembly também compartilha o limite de segurança da aplicação. Sua sandbox limita o acesso ao ambiente hospedeiro por interfaces definidas; não torna a página que o chama confiável. Compilar C para Wasm não torna a linguagem de origem segura em termos de memória.
As chaves não necessariamente existem apenas na RAM
Um mensageiro de navegador pode persistir chaves ou estado criptografado para que o usuário retorne à mesma identidade. Também pode oferecer vinculação de dispositivos ou recuperação criptografada. Esses comportamentos precisam ser documentados, em vez de se presumir sua ausência.
Vale perguntar:
- Quais chaves são persistidas, e em qual armazenamento do navegador?
- O que acontece quando os dados do site são apagados ou uma sessão de navegação privada termina?
- Uma chave não extraível ainda pode ser usada por código malicioso executado no contexto da aplicação?
- Uma atualização recém-entregue pode acessar o estado local antigo?
- A recuperação restaura a identidade, o histórico de mensagens ou ambos?
Uma chave não extraível do WebCrypto restringe a exportação pela API. Por si só, não impede que código hostil da aplicação solicite operações permitidas ou colete texto em claro.
Clientes web e nativos têm diferentes compromissos
| Aspecto | Cliente de navegador | Cliente nativo |
|---|---|---|
| Distribuição | Origem, hospedagem e fluxo de atualizações web | Loja de aplicativos ou distribuição de pacotes e fluxo de assinatura |
| Persistência local | Armazenamento do navegador e comportamento do perfil | Armazenamento de aplicativos do sistema operacional e ciclo de vida da aplicação |
| Exposição | Scripts da mesma origem, extensões e vulnerabilidades do navegador | Dependências da aplicação e vulnerabilidades do sistema/aplicativo |
| Disponibilidade | Domínio acessível e serviços de rede necessários | O aplicativo instalado ainda precisa de seus serviços de rede necessários |
Nenhuma coluna estabelece um vencedor sem examinar a implementação. Uma aplicação web pode continuar acessível após ser removida de uma loja, mas um domínio bloqueado ou a falta de uma rota de rede ainda podem impedir o acesso.
Meça o desempenho em vez de prometê-lo
O ML-KEM-768 usa uma chave de encapsulamento de 1.184 bytes e um texto cifrado de 1.088 bytes segundo o FIPS 203. Esses tamanhos ajudam a explicar por que protocolos podem programar atualizações de KEM em vez de anexar material novo a cada mensagem curta. Não são medições da largura de banda ou da velocidade de uma aplicação inteira.
Um benchmark útil informa o navegador, o dispositivo, a compilação, o método de aquecimento, a operação medida e a distribuição dos tempos. Inclua a inicialização da página, o carregamento de módulos, o uso de memória, dispositivos de baixo desempenho e a sobrecarga de rede. Afirmações como “menos de dois milissegundos em todos os celulares modernos” exigem medições publicadas; este artigo não as fornece.
Aplicando isso à Livara
A visão geral de segurança da Livara documenta o LVR1 e seus limites de recuperação. Seu Proof Lab demonstra operações locais selecionadas de P-256, HKDF e AES-GCM; a página coloca explicitamente a composição completa de LVR1/LGS1 fora dessa bancada. Portanto, uma demonstração bem-sucedida não comprova a segurança de todo o código web distribuído.
Antes de uma conversa sensível no navegador, use um cliente autêntico e mantido, revise o modelo de ameaças atual, proteja o perfil do navegador e verifique o interlocutor pelo processo de conferência de chaves suportado. Conveniência e criptografia útil podem coexistir, desde que o limite da entrega web permaneça parte da avaliação.
