A pergunta útil sobre segurança não é se a criptografia parece forte, mas o que protege, quem detém as chaves e quais evidências sustentam a afirmação.
“Criptografia de nível militar” não é informação suficiente para avaliar um aplicativo de mensagens. A expressão não informa quem detém as chaves, quais conversas estão protegidas, se os backups expõem texto em claro ou o que acontece quando um dispositivo é comprometido.
A resposta útil não é descartar a criptografia. É substituir um rótulo impressionante por afirmações específicas que possam ser verificadas.
AES-256 é uma escolha de algoritmo, não um modelo de segurança completo
AES é um padrão público, não uma tecnologia militar secreta. O FIPS 197 do NIST especifica AES-128, AES-192 e AES-256; o sufixo identifica o tamanho da chave. O padrão recebeu uma atualização editorial em 2023, sem alteração do algoritmo.
Uma cifra forte ainda pode ser usada em um sistema que dá ao serviço acesso ao texto em claro. Pergunte quem pode descriptografar, não apenas qual é o tamanho da chave. Pergunte também como as chaves são geradas e armazenadas, como as identidades são autenticadas e quais condições de falha fazem o aplicativo parar em vez de continuar de forma insegura.
Quando um fornecedor menciona AES-GCM, isso é mais específico do que mencionar apenas AES: GCM combina criptografia com autenticação. O tratamento correto de nonces, a verificação de etiquetas de autenticação e outros requisitos de implementação continuam importantes. A especificação GCM do NIST é a referência técnica; um logotipo não demonstra que um aplicativo a implementa corretamente.
Quatro afirmações diferentes que o marketing costuma combinar
| Afirmação | O que aborda | O que não comprova |
|---|---|---|
| Criptografia de transporte | Proteção ao longo de uma conexão, como entre aplicativo e servidor | Que o servidor não consegue ler o conteúdo |
| Criptografia em repouso | Proteção dos dados armazenados sob determinado modelo de chaves e acesso | Que o operador não possui a chave de descriptografia |
| Criptografia de ponta a ponta | Proteção do conteúdo entre os pontos finais designados | Segurança de um ponto final comprometido ou honestidade de um destinatário |
| Estabelecimento de chaves pós-quântico | Resistência a ameaças quânticas especificadas no estabelecimento de chaves | Uma auditoria completa do aplicativo, anonimato ou garantia de segurança futura |
Criptografia de transporte não implica que todo banco de dados do provedor armazene texto em claro sem proteção. Um serviço também pode criptografar os dados armazenados. A distinção relevante é se o provedor controla as chaves ou tem, de outra forma, acesso a conteúdo legível. Seja preciso em vez de substituir um slogan por outro.
Para uma introdução mais ampla, consulte a explicação sobre o que a criptografia de ponta a ponta protege.
“Usa um padrão NIST” não significa “validado segundo FIPS”
O FIPS 203 define ML-KEM, um mecanismo de encapsulamento de chaves. Um mensageiro pode descrever o uso desse algoritmo sem que todo o aplicativo tenha sido certificado ou analisado de forma independente. Padrões, testes de algoritmos, validação de módulos criptográficos e auditorias de segurança de produtos são tipos diferentes de evidência.
O Programa de Validação de Módulos Criptográficos do NIST deixa claro que implementar funções aprovadas não basta para estabelecer a validação de um módulo segundo FIPS 140. Se um produto anuncia validação, solicite o certificado, o módulo e a versão exatos, o ambiente operacional e a configuração aprovada. Depois, determine qual parte do produto esse certificado realmente abrange.
É também por isso que “segurança de 256 bits” não deve ser usada como uma nota geral para todo um mensageiro. A composição dos protocolos, o gerenciamento de chaves e a implementação podem impor limites diferentes.
Autenticação por senha não é criptografia de mensagens
Um mecanismo de login responde se um usuário pode acessar uma conta. E2EE responde quem pode ler o conteúdo protegido das mensagens. Nenhum deles fornece automaticamente as propriedades do outro.
Por exemplo, SRP foi projetado para autenticar sem transmitir a própria senha. Isso não significa que o roubo de um banco de dados de autenticação seja inofensivo. A discussão sobre segurança de SRP no RFC 5054 explica que um verificador roubado permite ataques de adivinhação de senhas e outros riscos. Evite a conclusão “não há senhas para roubar, portanto uma invasão do servidor não pode importar”.
Para os leitores, o próximo passo prático é perguntar sobre recuperação de conta, sessões ativas e a relação entre acesso à conta e chaves de criptografia. Uma resposta que apenas repete “conhecimento zero” deixa as perguntas importantes sem solução.
Um teste de cinco perguntas para a página de segurança de um mensageiro
- Quais superfícies estão cobertas? Conversas diretas, grupos, arquivos, chamadas, publicações públicas e backups podem ter limites diferentes.
- Quem detém chaves utilizáveis? Inclua chaves de recuperação, dispositivos vinculados e modos de processamento no servidor.
- Como o outro ponto final é autenticado? Procure verificação de chaves, avisos de alteração relevantes e um modelo de confiança documentado.
- Quais evidências existem? Especificações, builds reproduzíveis, vetores de teste e auditorias independentes respondem a perguntas diferentes. Pergunte pela versão e pelo escopo de cada um.
- O que continua visível ou vulnerável? Metadados, dispositivos comprometidos, mensagens copiadas e conteúdo público não devem desaparecer da explicação.
Aplique o mesmo teste ao Livara. Sua documentação de segurança menciona LVR1 e LGS1 e publica os limites operacionais. Trate isso como afirmações sobre o produto a avaliar, não como certificação independente. O Proof Lab oferece demonstrações limitadas e verificações de artefatos, não uma prova de que toda funcionalidade ou versão é segura.
Como ler uma auditoria independente
Verifique a data, o auditor, a revisão do código, as plataformas incluídas e os componentes excluídos. Leia os achados e o estado das correções, não apenas o selo de resumo. Uma auditoria de uma biblioteca criptográfica não abrange automaticamente a recuperação de conta, o aplicativo web, as notificações ou a segurança operacional.
A ausência de auditoria é uma lacuna na garantia de segurança, não uma prova de uma vulnerabilidade específica. Por outro lado, uma auditoria não é uma garantia vitalícia. Uma comparação útil registra as evidências e seus limites em vez de declarar um vencedor universal como “o mais seguro”.
Perguntas frequentes
“Nível militar” é sempre outro nome para AES-256?
Não. Não deduza um algoritmo ou uma certificação específica dessa expressão. Peça ao fornecedor que diga exatamente o que ela significa.
Uma criptografia mais forte impede capturas de tela ou malware?
Ela não impede um destinatário de copiar conteúdo nem um dispositivo comprometido de expor dados aos quais tem acesso. Essas são ameaças diferentes.
O que é um sinal melhor do que um slogan de segurança?
Um escopo claro, um protocolo identificado, limites explícitos e evidências que possam ser analisadas sobre a implementação distribuída. A explicação deve ajudar você a decidir em que confiar — e o que ainda precisa ser verificado.
