A criptografia indica quais chaves abrem a mensagem; é preciso verificar separadamente quem recebeu essas chaves.
Não: a criptografia de ponta a ponta do grupo, por si só, não impede um membro oculto. A resposta à pergunta “O servidor pode adicionar um membro ao grupo?” depende do mecanismo de participação e de verificação dos membros, não apenas da criptografia das mensagens. Segundo a documentação da Livara, o LGS1 criptografa o conteúdo em grupos privados compatíveis que realmente estejam no modo E2EE. A rotação de chaves após mudanças de participação foi concebida para limitar o acesso futuro e exige que as atualizações de participação e de chaves sejam aplicadas nos dispositivos; ela não recupera cópias já recebidas.
Pontos principais
- A criptografia de ponta a ponta busca a confidencialidade das mensagens, mas a segurança da lista de membros exige um mecanismo separado.
- Em um grupo privado compatível da Livara com estado E2EE confirmado, o LGS1 cobre mensagens, edições e chaves de anexos; não estenda essa afirmação a grupos antigos incompatíveis.
- Comparar Signal, WhatsApp, SimpleX e Element apenas pelo rótulo “criptografado” não basta; é preciso avaliar notificações de mudanças de participação, o papel do administrador e o método de verificação de identidade.
- A interface não consegue detectar, em todas as condições, a entrada de uma conta autorizada controlada por um invasor; os membros devem verificar identidades e mudanças sensíveis por uma via independente.
- O Proof Lab da Livara oferece demonstrações locais de P-256, HKDF e AES-GCM e verificação de hash de arquivos; não é uma implementação completa nem uma auditoria independente de LVR1/LGS1.
A criptografia do grupo impede um membro oculto?
Não, a menos que o protocolo também coordene o estado de participação entre os membros de forma criptográfica e verificável, além do conteúdo. Neste artigo, “membro oculto” significa uma conta com acesso às mensagens futuras cuja entrada as pessoas não viram ou cuja identidade não reconheceram corretamente.
Criptografia de ponta a ponta significa que somente os dispositivos das partes da conversa devem poder ler o conteúdo; mas esses dispositivos também precisam saber para quem enviam a chave. Se o servidor puder mudar a lista de destinatários, a criptografia pode funcionar corretamente e, ainda assim, a mensagem ser criptografada para um membro indesejado. Para distinguir conteúdo de metadados, consulte o guia sobre criptografia de ponta a ponta e seus limites.
Assim, um “ataque do servidor ao grupo criptografado” não significa necessariamente quebrar o AES ou resolver um problema matemático. Controlando a participação, o servidor pode incluir uma conta válida entre os futuros destinatários. O histórico de mensagens cujas chaves essa conta não possuía é outra questão; o principal risco é o acesso após a entrada.
O que sabemos sobre a participação em grupos na Livara?
A documentação de segurança da Livara separa o controle de membros e funções pelo servidor da criptografia do conteúdo. É uma fronteira importante para a avaliação, mas, por si só, não comprova um ataque prático bem-sucedido nem uma entrada completamente invisível. Para essa afirmação, seria necessário testar o comportamento do cliente, a distribuição de chaves, as notificações de mudanças de participação e as condições do ataque.
A pergunta correta é: os dispositivos validam as mudanças na lista de forma independente e o que mostram ao usuário antes de enviar uma chave a um novo membro? Este artigo não apresenta resultados de auditoria nem de teste de invasão da Livara.
Como a segurança da lista de membros difere entre cinco aplicativos?
A principal diferença é quem autoriza as mudanças de participação, como os membros ficam sabendo e se conseguem verificar de forma independente a identidade da nova conta. A mera existência de criptografia de ponta a ponta não responde completamente à questão da confiança no servidor de um mensageiro.
| Mensageiro | Conteúdo do grupo | Participação e confiança prática | Conclusão cautelosa |
|---|---|---|---|
| Livara | Em um grupo privado compatível com E2EE, o LGS1 cobre texto, edições e chaves de anexos. | As chaves dos remetentes são regeneradas e redistribuídas automaticamente quando os membros mudam. | Segundo a documentação do produto, o conteúdo do grupo privado compatível e as chaves de mídia são protegidos antes da entrega; verifique o estado daquele grupo. |
| Signal | O suporte do Signal sobre grupos afirma que o serviço não registra a participação, o título, a imagem e os atributos do grupo. | A mesma fonte diz que o administrador pode definir quem adiciona membros e ativar a aprovação administrativa para o link do grupo; os membros ainda precisam observar as mudanças de participação. | O desenho limita o conhecimento do serviço, mas os usuários devem verificar mudanças de participação e identidades das contas. |
| A visão geral da criptografia do WhatsApp afirma que mensagens pessoais e de grupo são criptografadas de ponta a ponta. | A fonte de ajuda do WhatsApp explica o compartilhamento opcional de parte do histórico com um novo membro e o poder do administrador de limitar esse compartilhamento. | O conteúdo do grupo é criptografado, mas a correção da participação deve ser avaliada pelos controles do administrador e pelas notificações do aplicativo. | |
| SimpleX | A documentação de grupos do SimpleX diz que cada membro tem uma conexão separada com os demais. | A especificação descreve os grupos como conjuntos de conexões entre membros com funções e mensagens de mudança de participação; isso não contradiz a existência de um administrador humano. | Um grupo sem identificador global não elimina todos os riscos de participação ou de dispositivos comprometidos. |
| Element / Matrix | A especificação de criptografia de ponta a ponta do Matrix define o evento m.room.encryption e os algoritmos de criptografia da sala. |
A especificação de participação do Matrix modela a participação por eventos m.room.member no estado da sala, distribuídos pelos servidores de origem. |
A criptografia da sala e o estado de participação são camadas separadas; os membros devem verificar dispositivos e mudanças na sala. |
Esta tabela não é um ranking absoluto. Cada sistema tem um modelo de ameaças diferente, e o aplicativo, o dispositivo, a administração do grupo e o comportamento dos membros podem mudar o resultado. Para uma escolha prática, use as 12 perguntas da lista de verificação de mensageiros seguros junto com a documentação oficial de cada produto.
Como comparar a confiança no servidor de um mensageiro?
Não reduza a confiança a um rótulo de sim ou não: pergunte exatamente o que o servidor vê e o que pode mudar. Um servidor que não lê o texto ainda pode controlar os horários de comunicação, os membros do grupo ou a distribuição das chaves iniciais.
Primeiro, separe a confidencialidade do conteúdo
Examine onde exatamente são criptografados a mensagem, a edição, a reação, o título, o anexo e a chave do anexo. Segundo a documentação da Livara, o LGS1 cobre texto, edições e chaves de anexos de grupos privados compatíveis com E2EE; essa afirmação não inclui canais.
Segundo, identifique a autoridade sobre a participação
Determine quem pode convidar membros, quem aprova os pedidos e como o cliente mostra as mudanças. Se o servidor impõe o estado do grupo, a ameaça de comprometimento do servidor precisa constar explicitamente no modelo de ameaças.
Terceiro, separe identidade de participação
Um nome conhecido não prova que a chave pertence àquela pessoa. Na Livara, o safety number permite comparar a impressão digital da chave fora do aplicativo; a existência dessa ferramenta, sozinha, não significa verificar a lista inteira de membros. Também só atribua transparência de chaves a um produto quando ela estiver documentada.
Quarto, separe evidências de alegações
Documentação do produto, relatório de auditoria e teste independente não são a mesma coisa. Um relatório confiável deve esclarecer versão, escopo, descobertas e correções. O nome do algoritmo ou a concordância entre duas implementações não prova, por si só, a segurança da gestão de membros.
Como verificar os membros de uma conversa em grupo?
Os membros devem revisar imediatamente as mudanças na lista e verificar por um canal independente a identidade de pessoas em posições sensíveis. Em uma conversa de alto risco, ver apenas nome, foto ou número de conta não basta, pois esses sinais podem estar errados, ter sido reutilizados ou estar sob controle de um invasor.
Na Livara, duas pessoas podem comparar o safety number pessoalmente, em uma chamada conhecida ou por uma via independente. Isso pode revelar uma mudança de chave inesperada; contudo, uma comparação entre duas pessoas não cobre, por si só, todos os membros de um grupo grande de uma vez. O guia de verificação de conversas com safety number explica as etapas práticas.
Para grupos sensíveis, este procedimento curto é útil:
- Restrinja ao máximo a autorização de adicionar membros aos administradores.
- Revise cada notificação de entrada, saída ou mudança de função assim que ocorrer.
- Verifique a identidade do novo membro fora daquele mesmo grupo.
- Após uma mudança suspeita, pare de enviar informações sensíveis e crie um novo grupo com membros verificados.
- Revise periodicamente os dispositivos e as sessões conectados a cada conta.
Essas medidas reduzem o risco, mas não corrigem falhas na arquitetura de participação. Se o servidor ou a conta do administrador estiver comprometido e a interface não mostrar bem a mudança, o usuário ainda pode não perceber a entrada.
Perguntas frequentes
O servidor pode adicionar um membro sem quebrar a criptografia?
Sim, se a arquitetura do mensageiro entregar ao servidor o controle da lista de membros. Nesse caso, o servidor não precisa quebrar a criptografia: pode incluir uma conta entre os futuros destinatários para que os clientes também criptografem as mensagens para ela. A possibilidade e a forma disso dependem do protocolo de participação de cada produto.
Como o protocolo LGS1 funciona nos grupos da Livara?
Segundo a documentação do produto, nos grupos privados compatíveis com E2EE, o LGS1 usa uma cadeia de chaves e a assinatura do remetente para proteger conteúdo e chaves de anexos. Limitar o acesso futuro após a saída de um membro depende de aplicar a mudança de participação e distribuir uma chave nova. O Proof Lab oferece apenas demonstrações locais de alguns componentes criptográficos e verificação de hash; não é uma implementação completa de LGS1, uma auditoria do protocolo nem prova da segurança da gestão de membros.
Comparar o safety number comprova a entrada de um membro oculto?
Não. A comparação do safety number verifica a identidade da chave entre duas pessoas por uma via independente e pode revelar uma mudança inesperada. Mas não prova que nenhum outro membro entrou no grupo; os membros também devem verificar separadamente a lista, as notificações de participação e as identidades das contas sensíveis.
Qual mensageiro tem a lista de membros mais segura?
Essas fontes não permitem apontar um vencedor absoluto, pois Signal, WhatsApp, SimpleX, Element e Livara têm modelos de participação e de ameaças diferentes. A escolha correta depende do seu risco: examine quem controla a participação, como as mudanças são anunciadas e se as identidades dos membros podem ser verificadas fora do servidor.
