Um aplicativo de mensagens pode exibir um cadeado, dizer que é privado e ainda deixar perguntas importantes sem resposta.
Quais conversas são criptografadas? Os anexos estão protegidos? Onde as chaves são armazenadas? Quais informações o servidor mantém? O que acontece quando você perde um dispositivo? As chaves de criptografia podem mudar sem aviso?
Esses detalhes ajudam a identificar tanto proteções úteis quanto as evidências que ainda faltam. Nenhuma lista de verificação, sozinha, certifica que um produto é seguro.
Este guia apresenta 12 perguntas práticas a fazer antes de confiar a um aplicativo de mensagens criptografadas suas conversas pessoais, arquivos confidenciais ou trabalho sensível.
O que é um aplicativo de mensagens seguro?
Um aplicativo de mensagens seguro é um serviço de comunicação projetado para proteger conversas contra acesso não autorizado, interceptação, comprometimento de contas e exposição involuntária de dados.
No mínimo, um aplicativo sério de mensagens privadas deve usar transporte de rede seguro, autenticação forte de contas, controles de acesso cuidadosos e práticas claras de tratamento de dados.
Para conversas altamente privadas, também deve oferecer criptografia de ponta a ponta.
A criptografia de ponta a ponta, ou E2EE, protege o conteúdo compatível ao criptografá-lo no dispositivo do remetente e descriptografá-lo no dispositivo de um destinatário autorizado. O serviço pode entregar os dados criptografados sem precisar do corpo legível da mensagem.
No entanto, a criptografia é apenas uma parte da segurança das mensagens.
Uma avaliação completa também deve considerar:
- Quais conversas são criptografadas
- Se fotos e arquivos recebem a mesma proteção
- Onde as chaves privadas são armazenadas
- Como os contatos podem verificar as chaves
- Quais metadados continuam visíveis
- Como funcionam a recuperação da conta e das chaves
- O que acontece quando um dispositivo é comprometido
- Como o serviço documenta suas limitações
Para uma introdução mais detalhada, leia o artigo que explica a criptografia de ponta a ponta.
Por que a palavra “criptografado” não basta
Quase todo serviço moderno de mensagens criptografa o tráfego de rede com HTTPS, TLS ou outro transporte protegido.
Essa proteção importa, mas não significa necessariamente que a conversa tenha criptografia de ponta a ponta.
Na criptografia de transporte, os dados são protegidos enquanto trafegam entre seu dispositivo e o serviço. O serviço ainda pode receber o conteúdo legível antes de entregá-lo por outra conexão protegida.
Com E2EE, o conteúdo compatível das mensagens é criptografado para os participantes antes de chegar ao serviço de mensagens.
Essa distinção afeta quem pode, tecnicamente, acessar o corpo da mensagem.
É também por isso que você deve fazer perguntas precisas em vez de aceitar um rótulo genérico de “criptografado”.
| Afirmação | A pergunta que você deve fazer |
|---|---|
| “Suas conversas são criptografadas” | São criptografadas apenas em trânsito ou de ponta a ponta? |
| “Seus dados estão seguros” | Quais dados, contra quais ameaças e por quanto tempo? |
| “Não podemos ler suas mensagens” | Isso abrange conversas diretas, grupos, mídias, chamadas e backups? |
| “Privacidade desde a concepção” | Quais metadados e informações operacionais continuam disponíveis? |
| “Recuperação segura” | Quem pode restaurar as chaves de criptografia e qual segredo é necessário? |
1. Quais conversas têm criptografia de ponta a ponta?
Não presuma que uma declaração sobre criptografia se aplica a todas as partes de um aplicativo.
Um serviço de mensagens pode oferecer proteções diferentes para:
- Conversas diretas entre duas pessoas
- Grupos privados
- Grupos públicos
- Canais de transmissão
- Chamadas de voz e vídeo
- Stories ou publicações temporárias
- Bots e contas automatizadas
- Histórico sincronizado de conversas
Peça ao provedor que identifique o limite exato.
Uma resposta forte soa assim:
O corpo e as mídias das mensagens diretas são criptografados nos dispositivos dos participantes. Grupos privados compatíveis têm criptografia de ponta a ponta com LGS1, com rotação automática das chaves de remetente quando há mudanças de membros. Os canais usam uma arquitetura separada, legível pelo servidor, e não são descritos como E2EE.
Uma resposta fraca soa assim:
Sua comunicação é protegida com criptografia de nível militar.
A primeira resposta fornece informações que você pode avaliar. A segunda usa linguagem impressionante sem definir o conteúdo protegido ou o modelo de ameaças.
2. Fotos, vídeos e anexos também são criptografados?
Um aplicativo pode criptografar texto e tratar as mídias enviadas por meio de outro sistema.
Isso cria uma pergunta importante: uma foto recebe criptografia no cliente antes do envio ou é protegida apenas por permissões no servidor e criptografia de transporte?
Pergunte sobre:
- Fotos e vídeos
- Documentos
- Mensagens de voz
- Prévias de links
- Miniaturas
- Arquivos temporários de envio
- Mídias em cache
- Autorização de download
A proteção das mídias deve ser descrita separadamente, em vez de ficar escondida em uma afirmação ampla sobre “mensagens”.
Pergunte separadamente sobre o acesso aos bytes criptografados e à chave de descriptografia. Alguns projetos distribuem anexos criptografados por armazenamento com menos restrições; isso não representa automaticamente exposição de texto simples. A questão fundamental é se uma parte não autorizada consegue obter a mídia legível ou sua chave e quais metadados o caminho de armazenamento revela.
3. Onde as chaves de criptografia são geradas e armazenadas?
A criptografia só é tão confiável quanto o tratamento de suas chaves.
Na E2EE do lado do cliente, o material de chaves privadas deve permanecer sob controle dos dispositivos dos participantes. As chaves públicas podem ser compartilhadas para que os contatos estabeleçam comunicação criptografada, mas as chaves privadas exigem proteção maior.
Procure respostas claras para estas perguntas:
- A chave privada é gerada no dispositivo?
- Ela é enviada alguma vez sem criptografia?
- O provedor consegue derivá-la ou substituí-la?
- Outro dispositivo conectado à conta consegue obtê-la automaticamente?
- O armazenamento local das chaves é protegido?
- O que acontece após uma redefinição de chave?
- Reinstalar o aplicativo cria uma nova chave de identidade?
A documentação não precisa expor todos os detalhes de implementação. Deve, porém, explicar quem controla as chaves privadas e qual é seu ciclo de vida.
4. Os contatos podem verificar as chaves uns dos outros?
A criptografia de ponta a ponta só protege uma conversa quando as chaves pertencem aos participantes pretendidos.
Muitos sistemas seguros de mensagens representam uma chave pública por uma impressão digital, um número de segurança, um código QR ou outro valor de verificação.
Dois contatos podem comparar esse valor por um canal confiável, como:
- Um encontro presencial
- Uma chamada de voz verificada
- Uma conta previamente autenticada
- Um diretório corporativo confiável
A verificação de chaves aumenta a confiança de que as chaves esperadas estão sendo usadas; por si só, não comprova a identidade de uma pessoa. Alguns produtos também oferecem verificações de transparência de chaves, como a verificação automática do Signal. Confira as condições de conta e versão compatíveis, em vez de exigir um fluxo exclusivamente manual de todos os produtos.
Pergunte também o que acontece quando uma impressão digital muda.
Uma chave alterada pode ter uma explicação inofensiva, como uma redefinição, troca de dispositivo ou recuperação. Mas a mudança deve ser visível. A substituição silenciosa dificulta detectar uma alteração inesperada da chave de identidade.
5. Quais metadados o serviço mantém?
O conteúdo das mensagens e seus metadados são categorias diferentes.
Um serviço pode ser incapaz de ler o corpo de uma mensagem E2EE e ainda processar informações necessárias para encaminhar, sincronizar e exibir a conversa.
Dependendo do sistema, isso pode incluir:
- Identificadores das contas do remetente e do destinatário
- Participação na conversa
- Registros de data e hora das mensagens
- Confirmações de entrega e leitura
- Tamanho das mensagens
- Eventos de reação e edição
- Sessões de dispositivos
- Cursores de sincronização
- Material de chaves públicas
- Tokens de notificações push
- Registros de prevenção de abuso e segurança
A existência de metadados operacionais não torna automaticamente um serviço inseguro.
As perguntas importantes são:
- O que é coletado?
- Por que é necessário?
- Por quanto tempo é mantido?
- Quem pode acessar?
- O usuário pode exportar ou excluir?
- É usado para publicidade ou criação de perfis sem relação com a finalidade do serviço?
Tenha cautela quando um provedor afirma armazenar “nenhum metadado” sem definir o que considera metadado.
6. Como sua conta é autenticada?
Uma criptografia forte das mensagens não compensa uma segurança fraca da conta.
Um invasor que assume o controle de uma conta pode conseguir se passar pelo usuário, registrar uma nova chave, acessar conteúdo legível pelo servidor ou interferir na recuperação.
Avalie se o serviço oferece proteções como:
- Tratamento seguro de senhas
- Limitação da taxa de solicitações
- Revogação de sessões
- Gerenciamento claro de dispositivos ou sessões
- Proteção contra reutilização de credenciais interceptadas
- Procedimentos seguros de redefinição de senha
- Autenticação multifator quando apropriado
- Notificações sobre mudanças importantes na conta
Diferencie também a autenticação da conta da criptografia das mensagens.
Entrar na conta prova que alguém possui a credencial da conta. Isso não prova necessariamente que o dispositivo possui a chave privada original de criptografia.
7. Como funciona a recuperação criptografada?
A recuperação cria um dos equilíbrios mais difíceis nas mensagens privadas.
É compreensível que os usuários queiram acesso ao histórico de conversas depois de trocar de dispositivo. Mas, se um provedor consegue restaurar silenciosamente todas as chaves privadas, ele pode ter mais capacidade de descriptografia do que os usuários esperam.
Um projeto protegido de recuperação pode criptografar um backup no cliente e exigir um segredo de recuperação, uma chave de acesso ou a aprovação de um dispositivo confiável. Primeiro identifique o que o backup contém: identidade da conta, contatos e histórico de mensagens são coisas diferentes.
Pergunte:
- O backup é criptografado antes do envio?
- A senha da conta basta para restaurá-lo?
- O provedor conhece o segredo de recuperação?
- A equipe de suporte pode redefinir o segredo?
- O que acontece se o segredo for perdido?
- A restauração preserva a mesma impressão digital da chave pública?
- A recuperação pode ser desativada?
Uma resposta confiável pode incluir uma limitação desconfortável: perder tanto a chave privada quanto o segredo de recuperação pode tornar o conteúdo antigo criptografado irrecuperável.
Essa consequência pode ser evidência de um limite real de segurança, em vez de um defeito do produto.
8. O que acontece quando a conexão cai?
Segurança e confiabilidade precisam trabalhar juntas.
Conexões móveis desaparecem. Navegadores entram em repouso. Dispositivos trocam de rede. Um mensageiro bem projetado deve lidar com desconexões temporárias sem duplicar mensagens, perder a ordem ou enfraquecer a criptografia.
Procure um modelo offline e de sincronização que consiga:
- Preparar localmente uma ação de saída.
- Atribuir a ela um identificador estável.
- Tentar novamente com segurança após a reconexão.
- Evitar envios duplicados.
- Conciliar o estado com a confirmação do servidor.
- Recuperar as alterações perdidas durante o período offline.
Pergunte separadamente como o aplicativo protege os dados transmitidos pela rede e a caixa de saída local enquanto uma mensagem espera. A E2EE não prova automaticamente que a fila local é criptografada em repouso.
Uma nova tentativa de envio pela rede não deve exigir entregar ao serviço de entrega uma cópia em texto simples de uma mensagem que, fora isso, tem criptografia de ponta a ponta.
9. Como o acesso a uploads e objetos armazenados é autorizado?
A segurança das mídias envolve mais do que criptografia.
Um serviço pode lidar com avatares, anexos de mensagens, papéis de parede, stories, uploads temporários e miniaturas geradas. Cada objeto precisa de uma política de acesso.
Verifique se o aplicativo:
- Exige autenticação para recuperar mídias privadas
- Confirma que a conta solicitante pertence à conversa correspondente
- Separa recursos públicos de objetos de mensagens privadas
- Limpa uploads sem associação
- Remove objetos temporários expirados
- Impede o uso de cache entre contas diferentes
- Usa identificadores imprevisíveis sem tratar a imprevisibilidade como autorização
Um arquivo privado em texto simples não pode se tornar legível apenas porque alguém adivinhou sua URL. Para objetos criptografados, examine como chaves e permissões de acesso são distribuídas e revogadas. As orientações de autorização da OWASP recomendam aplicar decisões de acesso de forma consistente, inclusive a recursos estáticos; um identificador imprevisível, sozinho, não é uma política completa de autorização.
10. As conversas em grupo são protegidas de forma diferente?
A criptografia de grupos e os controles de participação trazem perguntas diferentes das relacionadas à criptografia de conversas diretas.
Mudanças de membros, múltiplos dispositivos, histórico de mensagens, funções de administrador, convites, remoções e rotação de chaves criam requisitos adicionais de projeto.
Alguns serviços oferecem E2EE tanto para conversas diretas quanto para grupos. Outros oferecem E2EE apenas para conversas diretas e protegem os grupos com TLS, armazenamento autenticado e controles de acesso no servidor.
O segundo modelo ainda pode oferecer segurança significativa, mas estabelece um limite de confiança diferente.
Pergunte se o servidor pode processar o conteúdo do grupo e se a proteção muda quando:
- Um membro entra
- Um membro sai
- Um administrador remove alguém
- Uma mensagem é editada
- O histórico é sincronizado com um novo dispositivo
- Um bot ou uma integração entra no grupo
Nunca presuma que um cadeado exibido em um tipo de conversa se aplica automaticamente a todos os outros.
11. Quais controles de privacidade o usuário tem?
Privacidade também diz respeito ao controle depois que as informações chegam ao serviço.
Procure controles práticos de conta e conversa, como:
- Exportar dados da conta
- Excluir uma conta
- Revogar sessões
- Limpar o histórico local ou sincronizado
- Excluir mensagens enviadas quando permitido
- Gerenciar confirmações de leitura
- Controlar a visibilidade do perfil
- Bloquear contatos indesejados
- Gerenciar prévias de notificações
- Desativar ou excluir backups de chaves
O provedor deve explicar se a exclusão remove apenas sua cópia, a cópia de todos os participantes ou o próprio registro no servidor.
Um destinatário já pode ter baixado, copiado, encaminhado ou fotografado uma mensagem. Nenhum recurso de exclusão pode garantir a remoção de todos os dispositivos finais.
12. As afirmações de segurança são específicas e verificáveis?
A documentação de segurança mais sólida define limites.
Procure declarações específicas sobre:
- Algoritmos e tamanhos de chave
- Operações no cliente em comparação com operações no servidor
- Tipos de conversa cobertos pela E2EE
- Criptografia de mídias
- Informações armazenadas
- Autenticação
- Recuperação
- Mudanças de chave
- Controles de acesso
- Limitações conhecidas
- A data da última atualização da documentação
Trate expressões vagas com cautela:
- Criptografia inquebrável
- Privacidade absoluta
- Segurança de nível militar
- Completamente anônimo
- Zero metadados
- Impossível de invadir
- Criptografia à prova do futuro
Nenhum sistema complexo de comunicação deve ser avaliado apenas por um slogan.
Auditorias independentes, documentação técnica pública, clientes reproduzíveis, avaliações profissionais e relatórios de segurança com escopo claro podem oferecer confiança adicional. Eles não têm todos o mesmo nível de evidência, mas são mais úteis do que superlativos sem comprovação.
Mensagens seguras: sinais fortes e sinais de alerta
| Sinal forte | Sinal de alerta |
|---|---|
| O provedor informa quais conversas têm E2EE | Todos os recursos são descritos apenas como “criptografados” |
| O controle das chaves privadas é explicado | O tratamento das chaves nunca é discutido |
| Mudanças de chave são visíveis | As chaves podem mudar silenciosamente |
| As limitações da recuperação são documentadas | O suporte pode restaurar tudo sem explicar como |
| As categorias de metadados são listadas | O provedor afirma ter “zero metadados” sem definições |
| A proteção das mídias é descrita separadamente | Apenas mensagens de texto são mencionadas |
| Os grupos têm um limite de confiança definido | Dá-se a entender que as afirmações sobre conversas diretas abrangem grupos |
| As páginas de segurança incluem detalhes atuais de implementação | A linguagem de marketing contradiz a documentação técnica |
| As limitações são declaradas com clareza | O serviço promete proteção absoluta ou inquebrável |
Aplicando a lista de verificação às afirmações públicas da Livara
A página de segurança da Livara fornece documentação do produto, não uma certificação independente. Seus limites atuais distinguem:
- Mensagens diretas: o LVR1 usa acordo híbrido de chaves P-256 e ML-KEM-768 e criptografia autenticada para o conteúdo compatível.
- Grupos privados compatíveis: proteção por chaves de remetente LGS1; participação e funções continuam em um limite separado de autoridade do servidor. Grupos antigos incompatíveis não devem herdar um rótulo de E2EE.
- Canais públicos: conteúdo legível pelo servidor, sem E2EE.
- Recuperação: o material de identidade é protegido antes do envio; restaurá-lo não equivale a restaurar o histórico de conversas.
- Metadados e dispositivos: registros de roteamento e dispositivos finais comprometidos permanecem fora da promessa de criptografia do conteúdo.
Use essas declarações como afirmações a verificar em relação à versão instalada e ao modelo de ameaças. Uma especificação de protocolo, um vetor de teste local, uma auditoria de determinada versão e a observação do serviço em funcionamento são formas diferentes de evidência. Não substitua evidências ausentes pela suposição de segurança perfeita nem pela de uma vulnerabilidade comprovada.
Uma lista de verificação de mensagens seguras em 60 segundos
Antes de criar uma conta, verifique se você consegue responder a cada pergunta:
- Quais tipos de conversa têm criptografia de ponta a ponta?
- Imagens, vídeos, documentos e mensagens de voz estão cobertos?
- As chaves privadas são geradas e mantidas nos dispositivos dos participantes?
- Os contatos podem comparar impressões digitais de chaves ou números de segurança?
- As mudanças de chave são visíveis?
- A política de privacidade identifica os metadados armazenados?
- A autenticação da conta é explicada?
- O processo de recuperação de chaves é separado do login comum?
- As solicitações de mídias privadas são autenticadas e autorizadas?
- A criptografia permanece ativa durante a espera na fila offline?
- Grupos e canais têm um limite de segurança preciso?
- As limitações são documentadas sem promessas exageradas?
Marque os itens sem resposta como “desconhecido”, não automaticamente como “seguro” ou “inseguro”. Um provedor não precisa usar a mesma arquitetura de todos os concorrentes.
Mas precisa dar respostas precisas o suficiente para que os usuários entendam em que estão confiando.
A escolha mais segura depende do seu modelo de ameaças
Não existe um aplicativo de mensagens universal que seja automaticamente o melhor para todas as pessoas e situações.
Um grupo familiar, um ambiente de trabalho, um jornalista e sua fonte, uma equipe de saúde e uma comunidade pública podem precisar de combinações diferentes de:
- Confidencialidade
- Verificação de identidade
- Anonimato
- Administração de grupos
- Retenção de mensagens
- Conformidade regulatória
- Recuperação
- Suporte a múltiplos dispositivos
- Código aberto
- Auditoria independente
- Facilidade de uso
Comece perguntando o que você está protegendo e de quem.
Na comunicação pessoal comum, os principais riscos podem ser roubo de conta, uma rede insegura, um dispositivo perdido ou coleta excessiva de dados.
Para comunicação de maior risco, você também pode precisar de identidades verificadas, políticas de mensagens temporárias, dispositivos reforçados, procedimentos operacionais rigorosos e avaliação independente de segurança.
A criptografia não pode reparar um dispositivo final comprometido nem impedir que um destinatário de confiança compartilhe uma mensagem.
A privacidade começa com expectativas corretas
Um mensageiro confiável não pede aos usuários que acreditem que todos os riscos desapareceram.
Ele explica:
- O que é protegido
- Quais dispositivos mantêm as chaves
- O que o servidor processa
- Quais metadados permanecem
- Como funciona a recuperação
- Onde a E2EE começa e termina
- Quais proteções ainda não foram implementadas
Essa clareza permite que os usuários tomem decisões informadas.
Documentação clara é necessária para a avaliação, mas não basta para identificar o aplicativo mais seguro. A qualidade da implementação, atualizações oportunas, conclusões independentes e os riscos do uso real também importam. O guia da EFF para escolher ferramentas também recomenda começar pelas suas ameaças e tratar a abertura como uma oportunidade de análise, não como garantia.
Como próximo passo, faça um teste inofensivo: verifique um contato, envie um anexo de exemplo, revise os dispositivos vinculados, examine o escopo do backup e confirme que os dois participantes conseguem usar as configurações de forma confiável. Não teste com o material confidencial que você está tentando proteger.
Perguntas frequentes
O que torna um aplicativo de mensagens seguro?
Um aplicativo seguro combina transporte de rede protegido, autenticação forte, controles de acesso cuidadosos, gerenciamento seguro de chaves, tratamento responsável de dados e limites de privacidade claramente documentados. Para o conteúdo de mensagens privadas, a criptografia de ponta a ponta oferece uma camada adicional importante.
Um aplicativo de mensagens criptografadas é automaticamente privado?
Não. Um aplicativo pode criptografar o conteúdo das mensagens e ainda processar informações da conta, registros de data e hora, participação, confirmações, informações do dispositivo ou outros metadados. A privacidade depende tanto da criptografia quanto das práticas mais amplas do serviço sobre dados.
A criptografia de ponta a ponta esconde com quem eu converso?
Não necessariamente. A E2EE protege principalmente o conteúdo compatível das mensagens. O serviço ainda pode precisar de informações sobre remetente, destinatário, participação, horários e roteamento para entregar e sincronizar as conversas.
Um provedor de mensagens pode recuperar mensagens E2EE?
Isso depende do projeto das chaves e dos backups. Um provedor pode armazenar o histórico criptografado sem ter a chave privada necessária para abri-lo. Um sistema de recuperação pode restaurar a chave somente quando o usuário fornece um segredo de recuperação separado.
É seguro trocar mensagens pelo navegador?
Um navegador pode executar criptografia forte no cliente, mas a segurança ainda depende da implementação do aplicativo, integridade do navegador, segurança do dispositivo, armazenamento das chaves, entrega do código do aplicativo pelo servidor e extensões e sistema operacional do usuário.
As conversas em grupo sempre têm criptografia de ponta a ponta?
Não. Alguns serviços oferecem E2EE para grupos, enquanto outros a aplicam apenas a conversas diretas. Confira a documentação do provedor para saber o limite exato.
O que acontece se minha chave de criptografia mudar?
Uma mudança de chave pode resultar de um novo dispositivo, reinstalação, redefinição de chave ou processo de recuperação. Um mensageiro seguro deve tornar a mudança visível e permitir que os contatos verifiquem a nova impressão digital.
A E2EE basta para comunicações altamente sensíveis?
A E2EE protege o conteúdo entre dispositivos finais compatíveis, mas não protege um dispositivo infectado ou desbloqueado, não garante o comportamento de um destinatário nem esconde automaticamente os metadados. Usuários de maior risco também precisam de forte segurança de dispositivos e procedimentos operacionais seguros.
