Compare o custo de uma operação definida e as evidências para uma ameaça definida — não apenas um diagrama de árvore com um diagrama de chaves de remetente.
Messaging Layer Security (MLS) e LGS1 do Livara não são dois certificados intercambiáveis de segurança de conversas em grupo. MLS é um padrão de protocolo do IETF; LGS1 é o projeto documentado específico do produto Livara. Compará-los de forma justa significa separar arquitetura, evidências da implementação e o comportamento que os usuários realmente vivenciam.
A principal distinção é o estado compartilhado do grupo baseado em árvore versus chaves de remetente distribuídas por sessões entre pares. Nenhum dos rótulos, sozinho, informa se determinado aplicativo lida corretamente com um membro removido, dispositivo desatualizado ou chave comprometida.
A diferença de arquitetura
O RFC 9420 especifica MLS para estabelecimento assíncrono de chaves de grupo. Ele usa uma árvore ratchet e épocas de grupo, com sigilo futuro e segurança pós-comprometimento sob condições declaradas. Sua estrutura em árvore reduz certos custos de atualização de chaves conforme o grupo cresce.
A documentação de segurança do Livara descreve LGS1 como uma cadeia de remetente assinada para cada membro, distribuída por sessões LVR1 entre pares e rotacionada em mudanças de membros. Isso é uma afirmação sobre o produto, não evidência de que LGS1 esteja em conformidade com MLS ou tenha a mesma análise.
| Questão | MLS | Documentação do Livara LGS1 |
|---|---|---|
| Estrutura compartilhada | Árvore ratchet e épocas | Cadeias por remetente |
| Atualizações de chaves | Mudanças no estado do grupo consolidadas em uma nova época | Novas chaves de remetente distribuídas aos membros |
| Status da especificação | Padrão IETF, RFC9420 | Descrição publicada específica do produto |
| O que ainda exige avaliação | Integração no aplicativo e implementação | Especificação completa, implementação e evidências independentes |
Esta tabela descreve categorias de projeto. Não é um benchmark nem um ranking de segurança.
O que “logarítmico” significa — e o que não significa
Uma atualização criptográfica pode usar um número logarítmico de componentes criptografados do caminho da árvore sem tornar todo o trabalho do sistema logarítmico. As mensagens ainda precisam ser distribuídas, os clientes mantêm estado e o comportamento depende da estrutura do grupo e das operações. A antiga comparação “MLS precisa de O(log N) mensagens enquanto tudo no LGS1 é mais rápido” misturava custos diferentes e não apresentava medições.
A arquitetura MLS, RFC 9750, trata o serviço de entrega separadamente do estabelecimento criptográfico de chaves. Ela discute a distribuição de mensagens e a ordenação das mudanças no grupo. Essa separação importa: computação do cliente, bytes em um commit, distribuição total pelo servidor e tráfego de reconexão são métricas diferentes.
Um relatório de desempenho significativo deve informar:
- tamanho do grupo e número de dispositivos por pessoa;
- se a operação é uma mensagem normal, remoção de membro, atualização de chave ou reconexão;
- bytes enviados pelo cliente iniciador versus tráfego total de entrega;
- tempo decorrido, modelo do dispositivo, versão da implementação e condições de rede;
- custo de atualizações perdidas e de mudanças repetidas nos membros.
Sem esses detalhes, não estão estabelecidas afirmações de “milissegundos”, “baixa sobrecarga de estado” ou superioridade em determinado tamanho de grupo.
Remover um membro é um teste de ciclo de vida
Um administrador remover uma conta é apenas uma parte da questão de segurança. Os clientes precisam concordar com o novo estado dos membros, usar novas chaves adequadas e evitar fornecê-las a dispositivos excluídos. Uma pessoa que já possua texto em claro antigo ou chaves antigas pode manter acesso ao conteúdo anterior; a remoção não faz suas cópias desaparecerem.
Para qualquer sistema, um teste útil pergunta: depois de concluída a remoção, o dispositivo removido consegue descriptografar uma nova mensagem de teste sem dados sensíveis? Um membro que estava offline consegue se atualizar com segurança? Todos os dispositivos da conta são considerados? A interface torna visíveis as falhas ou mudanças nos membros?
Essas são perguntas de avaliação propostas, não resultados de testes realizados aqui. Uma comparação de produtos deve publicar o resultado observado e a versão testada, em vez de igualar um clique bem-sucedido do administrador à exclusão criptográfica.
Sigilo futuro e recuperação são condicionais
Manter mensagens antigas protegidas após um comprometimento posterior depende da retirada de material secreto antigo. Recuperar a proteção de mensagens futuras depende de incorporar novos segredos depois que o atacante perde o acesso relevante. Em MLS, processar atualizações do grupo faz parte dessa recuperação; simplesmente enviar uma atualização não é o mesmo que todos os membros a terem aplicado. Veja as considerações de segurança no RFC 9420.
Em um projeto com chaves de remetente, pergunte como o estado comprometido de cada remetente é substituído e redistribuído. Uma cadeia unidirecional, sozinha, não deve ser descrita como capaz de se recuperar automaticamente de um atacante que conhece seu estado atual. A proteção entre pares usada na redistribuição é relevante, mas não substitui uma análise completa no nível do grupo.
Afirmações pós-quânticas exigem um conjunto criptográfico e um escopo específicos
Os conjuntos criptográficos definidos no RFC9420 básico usam mecanismos clássicos de chave pública. MLS é extensível; portanto, uma afirmação sobre uma implementação específica deve identificar seu conjunto e suas extensões reais, em vez de declarar que todas as implantações MLS são permanentemente clássicas.
O uso documentado de distribuição LVR1 híbrida em LGS1 é uma afirmação diferente de uma garantia pós-quântica analisada de forma independente para cada operação de grupo. O FIPS 203 padroniza ML-KEM; não certifica o protocolo de grupo completo que o incorpora. Avalie em conjunto autenticação, mudanças nos membros, comprometimento de chaves e implementação, não apenas o nome do KEM.
O que solicitar antes de decidir por um produto
Peça a especificação atual do protocolo, vetores de teste e uma revisão independente específica da versão, incluindo achados não resolvidos. Depois, compare os requisitos comuns do produto: dispositivos compatíveis, comportamento das atualizações, recuperação, funções de moderação e dados retidos pelos servidores.
A arquitetura MLS considera explicitamente os serviços do aplicativo e suas premissas de confiança. Da mesma forma, o modelo de ameaças do Livara deve ser lido junto com suas afirmações sobre o produto. A criptografia não torna participantes autorizados confiáveis, não impede capturas de tela nem elimina todas as formas de metadados.
Se faltarem evidências, registre “não estabelecido” em vez de automaticamente classificar um projeto como inseguro ou superior. A decisão deve refletir os riscos do seu grupo e a qualidade das evidências disponíveis.
Perguntas frequentes
LGS1 é uma implementação de MLS?
As descrições publicadas mostram arquiteturas diferentes. Este artigo não identifica LGS1 como uma implementação de MLS nem afirma interoperabilidade.
MLS exige que todos os membros estejam online ao mesmo tempo?
Não. O uso assíncrono faz parte do projeto. Os aplicativos ainda precisam de políticas para atualizações atrasadas, estado desatualizado e membros que ficam offline por muito tempo.
A distribuição pós-quântica de chaves resolve a segurança do grupo?
Não. Ela aborda parte do estabelecimento de chaves. Identidade, composição do grupo, ciclo de vida das chaves, segurança dos dispositivos finais e implementação ainda exigem evidências.
Qual projeto é mais rápido?
Não há neste artigo um benchmark que estabeleça um vencedor. Meça as operações e a implantação que importam para seu grupo.
