- O Signal introduziu a Sparse Post Quantum Ratchet (SPQR, catraca pós-quântica esparsa), elevando significativamente a segurança do protocolo Signal e reforçando a resiliência contra futuras ameaças da computação quântica, ao mesmo tempo em que mantém as garantias existentes de Forward Secrecy (FS) e Post-Compromise Security (PCS)
- O protocolo Signal é um conjunto de especificações criptográficas que fornece criptografia de ponta a ponta para comunicações privadas trocadas diariamente por bilhões de pessoas no mundo todo e, desde seu anúncio em 2013, foi adotado não apenas pelo app Signal, mas também por outros grandes produtos de mensagens
- O PQXDH, anunciado anteriormente, protegeu contra ataques de harvest-now-decrypt-later ao incorporar segredos criptográficos resistentes a quântica na configuração da sessão de chat, mas o SPQR alcança as garantias de FS e PCS de forma segura para o mundo quântico, minimizando danos e permitindo recuperação à medida que a conversa continua
- O SPQR é combinado com a Double Ratchet já existente do Signal, formando uma composição chamada Triple Ratchet; a experiência do usuário não muda, todas as conversas migram automaticamente para o novo protocolo, e tanto as comunicações atuais quanto as futuras ficam protegidas
- Por meio de pesquisa acadêmica (artigos da Eurocrypt 25 e USENIX 25), chunking baseado em erasure code e verificação formal (ProVerif, hax/F*), a correção do protocolo e suas propriedades de segurança são verificadas mecanicamente, com revalidação a cada mudança no pipeline de CI para manter isso como parte dinâmica do processo de desenvolvimento
Visão geral
- O Signal elevou a segurança do Signal Protocol com a introdução do Sparse Post Quantum Ratchet (SPQR)
- Com base na forte segurança já existente, o SPQR reforça ainda mais a estrutura de garantias de sigilo futuro (Forward Secrecy, FS) e segurança pós-comprometimento (Post-Compromise Security, PCS), ao mesmo tempo em que responde a futuras ameaças da computação quântica
- A aplicação é integrada de forma natural em todo o sistema, a ponto de o usuário praticamente não perceber a mudança, garantindo um ambiente em que o conteúdo das conversas permanece protegido mesmo quando computadores quânticos se tornarem realidade
Situação atual do Signal Protocol
- O Signal Protocol é um padrão de mensagens com criptografia de ponta a ponta usado no dia a dia
- No protocolo existente, a estrutura de double ratchet implementa o sigilo futuro com funções hash (seguras contra ameaças quânticas) e a segurança pós-comprometimento com Elliptic Curve Diffie-Hellman (ECDH)
- O ECDH é altamente seguro hoje, mas há o risco de se tornar vulnerável no futuro por causa de computadores quânticos
- “Ratchet” é a técnica de gerar novas chaves secretas ao longo da conversa para impedir a exposição do conteúdo de mensagens anteriores ou posteriores
- Alice e Bob atualizam periodicamente a sessão ao concordarem sobre novas informações secretas de ECDH
Necessidade de combinar elementos de segurança quântica
- Computadores quânticos podem neutralizar métodos tradicionais de criptografia assimétrica como o ECDH
- Para se preparar para isso, a primeira abordagem adotada, chamada PQXDH, mistura informações secretas seguras contra quântica no início da sessão
- Ao longo da conversa, ganhou destaque a necessidade de troca contínua de chaves usando Key Encapsulation Mechanism (KEM) baseado em algoritmos seguros contra quântica
- O KEM cria um segredo compartilhado como o Diffie-Hellman, mas exige a troca de mensagens assimétricas ordenadas
- KEMs padronizados como o ML-KEM são usados para gerar segredos contínuos, seguros contra quântica, durante a sessão
Máquina de estados e otimização de largura de banda
- Como o método KEM tem dados de troca de chaves grandes (cerca de 1000 bytes), a otimização da largura de banda de comunicação é uma questão importante
- Usa-se a lógica de máquina de estados (State Machine) para gerenciar quais dados (Encapsulation Key, Ciphertext etc.) Alice e Bob trocam entre si e em que momento
- Com o uso de fragmentação em chunks e erasure codes, dados grandes são divididos em partes menores para facilitar a recuperação em caso de perda ou descarte de mensagens
- O protocolo também foi projetado para dificultar que um atacante descarte seletivamente apenas chunks da troca de chaves para interromper o protocolo
- Isso permite lidar de forma eficaz com perda de mensagens, reordenação e atrasos em ambientes móveis reais
Trade-off entre eficiência e segurança, e otimização
- Se a geração de segredo compartilhado (Shared Secret) for acelerada sem critério, aumenta o risco de que todas as informações secretas de um determinado momento sejam expostas em caso de ataque
- O Signal executou várias simulações de máquina de estados para encontrar o ponto de equilíbrio entre segurança e eficiência no envio paralelo e serial
- Ao analisar o processo detalhado do ML-KEM e usar técnicas como dividir e transmitir chunks simultaneamente, a utilização da largura de banda é maximizada
- Esse processo foi batizado de ML-KEM Braid e é usado como um módulo do próprio protocolo
Estrutura Triple Ratchet
- A Double Ratchet (existente) e o SPQR (novo, seguro contra quântica) operam juntas, e suas chaves são combinadas para gerar chaves de criptografia em um formato híbrido
- No modelo Triple Ratchet, o risco de exposição de mensagens só existe se os dois algoritmos forem quebrados, elevando drasticamente o nível de segurança
- Na implementação real, as chaves vindas da Double Ratchet e do SPQR são combinadas mais uma vez por uma função de derivação de chaves
- A estrutura Triple Ratchet garante tanto a segurança tradicional quanto a segurança quântica para mensagens passadas e futuras
Adoção heterogênea e tratamento de compatibilidade
- Como a atualização é aplicada gradualmente, podem surgir problemas de compatibilidade com usuários que ainda não adotaram o SPQR
- Durante o processo inicial de negociação de mensagens, o design permite temporariamente um downgrade para que os dois usuários possam se comunicar por um método compatível entre si
- Quando dados de SPQR são anexados a mensagens, eles são protegidos por um código de autenticação para impedir que um atacante force um downgrade
- Depois que ambos os lados concluem a negociação de compatibilidade, a decisão de usar SPQR fica fixa ao longo de toda a sessão
- Quando todos os usuários estiverem em versões com suporte a SPQR, as sessões antigas serão arquivadas ou encerradas, e novas sessões passarão a usar SPQR por completo
Verificação da segurança do protocolo e ferramentas de validação
- Desde a fase de projeto do protocolo, houve colaboração ativa com pesquisadores acadêmicos, PQShield, AIST e NYU
- Artigos apresentados em conferências como Eurocrypt 25 e USENIX 25 demonstram teoricamente que o protocolo atende aos requisitos de segurança quântica e às garantias tradicionais
- Entre os seis protocolos de ratchet pós-quântico propostos, sobreviveram o SPQR e o Katana (novo protocolo baseado em KEM)
- A verificação formal (Formal Verification) é gerenciada de forma contínua e automatizada com ferramentas como Cryspen, ProVerif, hax e F* no pipeline de CI
- A sincronização entre a implementação em Rust e o modelo de verificação garante consistência entre o projeto e o código real
- Durante a implementação, invariantes (
assertion) também são incorporadas ativamente ao código, de modo que, se ocorrer um erro, o app é interrompido para evitar preventivamente vulnerabilidades potenciais
Verificação e desenvolvimento contínuo em paralelo
- O processo de verificação formal não é um trabalho pontual; ele é executado automaticamente sempre que há mudanças na base de código
- Se a validação falhar ao mesclar novo código, o build também não pode prosseguir
- Na prática, a experiência mostra que, se erros de limite e pré/pós-condições forem gerenciados com clareza, a manutenção se torna mais fácil e a completude do protocolo pode ser maximizada
Resumo final
- O Signal busca oferecer segurança resistente a quântica para todas as mensagens ao introduzir a confiável estrutura Triple Ratchet (Double Ratchet + SPQR)
- A transição de protocolo ocorrerá gradualmente, sem interrupção do serviço nem inconveniência para o usuário
- O aumento no volume de dados transmitidos é mínimo, então praticamente não há custo adicional no ambiente móvel
- Como um atacante precisaria induzir um estado de negação de serviço ao tentar manipular o protocolo, ele também é forte contra ataques man-in-the-middle (MITM)
- O código e o projeto passam por verificação formal sistemática e continuarão mantendo a segurança no futuro
- Para usuários do Signal, a expectativa é de um ambiente protegido em que mudanças de protocolo e ameaças de computadores quânticos permaneçam invisíveis no dia a dia
1 comentários
Opiniões no Hacker News
O Signal continua publicando artigos de criptografia realmente excelentes, mas, do ponto de vista de produto, passa a impressão de estar tentando várias coisas sem saber o que vai dar certo. Está tentando novidades como handshake pós-quântico, stories, transferências de dinheiro etc., mas ainda faltam SDK, API e suporte a bots. As bibliotecas oficiais também estão incompletas e não têm documentação. Muitas funcionalidades ainda ficam escondidas no cliente. Eles até publicaram a especificação do protocolo, mas dizer para cada um implementar a própria biblioteca a partir disso é uma postura irresponsável e totalmente desconectada de como se opera um produto real. É um absurdo faltar esse básico em uma plataforma usada por milhões. Apps como WhatsApp e iMessage ao menos abrem alguma coisa para desenvolvedores, mas o Signal parece excluir completamente qualquer coisa relacionada a desenvolvedores. É difícil enxergar uma estratégia clara, a ponto de parecer que nem existe alguém de produto por trás. Como usuário antigo do Signal e alguém que sempre o promoveu ativamente, hoje ele me parece um mensageiro cheio de tecnologias de criptografia da moda coladas umas nas outras, e ainda mais fechado para desenvolvedores do que o ecossistema da Apple. Mesmo assim, sou grato a quem construiu o produto
Concordo. Especialmente a função de "stories" passou muito a sensação de que foi só jogada ali para ver no que dava. Acho que o Signal, por vir de uma organização sem fins lucrativos com inclinações anarquistas, tem objetivos diferentes dos de uma empresa comum. O app continua cumprindo bem sua missão principal, então tudo bem, mas seria ótimo ter um SDK
Fico me perguntando se recursos como API ou bots de negócios são mesmo tão importantes. WhatsApp e iMessage têm APIs para empresas, mas como usuário comum eu nunca interagi de fato com empresas por esse caminho. Em compensação, já passei pela experiência de bots me incomodando de vez em quando. O problema real no Signal é que, se o app silenciosamente fica desatualizado ou para de atualizar, ele não avisa e você simplesmente perde mensagens por completo. Isso é a missão central de um mensageiro, e ele falha nisso
Para mim, a ausência de API e bots é justamente uma vantagem
Eu preferiria que eles se concentrassem em fazer um mensageiro seguro e útil como o atual, sem esse tipo de recurso
O que realmente me irrita no Signal é que o som de chamada que o remetente escuta toca mesmo quando o telefone do destinatário não está tocando de verdade. Isso é uma política oficial que eles defendem deliberadamente há tempos. Continuam assim desde que removeram aquele antigo som de submarino
Fiquei surpreso ao ver que o nome do protocolo do Signal é SPQR. SPQR é a sigla em latim de "Senatus Populusque Romanus" veja na Wikipédia. Muito bom
Usar SPQR para um protocolo futurista dá uma vibe meio Ozymandias
Nome extremamente esperto. Eu já conhecia bem por aparecer com frequência como tatuagem de legionários romanos na minissérie da BBC "Rome" Wikipédia de Rome
Strength and Honor
Acho que esse tipo de humor só aparece no Hacker News. Lembrei daquela tirinha sobre "como um matemático memoriza o número do próprio armário". ("1975? Ora, essa é a raiz quadrada de 3.900.625!")
Será que não deram esse nome só porque "SPQR" soa como "Speaker" e combina com um app de chat? Nem tudo precisa ser ligado a Roma
A maior fraqueza do Signal é distinguir identidade por número de telefone. Não só hackers, mas também governos autoritários podem tomar posse de um número a qualquer momento. Pensar em ameaças futuras é importante, mas as prioridades precisam ser revistas
Compartilhando para quem ainda não souber: Signal apresenta nomes de usuário para ocultar números de telefone (fevereiro de 2024)
Muitos mensageiros seguros funcionam sem número de telefone e ainda oferecem proteção forte de metadados. Em países onde o número de telefone e o SIM ficam vinculados à identidade real, a abordagem do Signal vira uma barreira de entrada
Exigir número de telefone também é uma forma simples e confiável de prevenir spam
Não me parece que verificar identidade por número de telefone seja, por si só, um problema fatal. Mesmo que um governo autoritário roube o número, isso não significa obter o histórico de mensagens. O usuário alvo já receberá um aviso. O Signal não é isento de problemas, e crítica com critérios claros é necessária, mas ele ainda é o único mensageiro com criptografia ponta a ponta completa e proteção de metadados que uma pessoa comum consegue usar. Existem serviços mais fortes em segurança e privacidade, mas o fato de até a minha avó conseguir usar é realmente importante. Acho que o Signal já consolidou bastante a segurança e agora deveria focar mais em privacidade. Mesmo criticando, continuo recomendando fortemente e incentivando meus amigos a usá-lo. Também já fiz várias doações veja o relatório de transparência do Signal
O Signal tem um recurso chamado "bloqueio de registro", que pode impedir o sequestro da conta por troca de SIM se você configurar uma senha
Fiquei curioso para saber onde o Signal se posiciona agora em comparação com o PQ3 do iMessage, depois de aplicar o SPQR (catraca resistente a quantum). Também gostaria de ouvir reflexões sobre as tentativas anteriores de mensageria resistente a quantum da Cyph e da Simplex. Apresentação do PQ3 do iMessage / Cyph - Post-Quantum Castle / Simplex - recurso resistente a quantum
O SPQR do Signal é parecido com o PQ3 por usar uma estrutura de catraca baseada em ML-KEM, mas a forma de transportar as chaves é diferente. Como as chaves ML-KEM são grandes, o PQ3 as envia apenas ocasionalmente, de forma periódica, enquanto o Signal as divide e envia junto com as mensagens. A ideia é que chunking, em termos de banda oculta e segurança, pode ser mais seguro e eficiente. A largura de banda total pode aumentar por causa de códigos de correção de erros, mas o tamanho de cada mensagem fica estável. A Apple provavelmente consegue se defender melhor contra trocas agressivas de chaves porque tem mais controle sobre a rede
Fico em dúvida se o iMessage faz tanta diferença no ambiente real atual, porque a maioria dos usuários de iPhone usa backup do iCloud sem E2E, e backup totalmente criptografado é opcional. Ou seja, se houver uma requisição da polícia, a Apple pode descriptografar tudo; nem precisa esperar computador quântico para já haver fragilidade suficiente
Ao ver o nome SPQR (Sparse Post-Quantum Ratchet), fiquei com a impressão de que há algum fã de história romana na equipe do Signal
Com que frequência vocês pensam no Império Romano?
Talvez seja só uma variação da palavra ideal para um app de chat: "Speaker"
A maior fraqueza do Signal é a autenticação de identidade baseada em número de telefone. Não apenas hackers, mas também governos autoritários correm o risco de tomar posse do número a qualquer momento. Pensar em ameaças futuras é válido, mas as prioridades precisam mudar
Eu gostaria que o Signal virasse uma camada de transporte de mensagens, uma espécie de "barramento de transporte". Por exemplo, se eu pudesse pedir e compartilhar minha localização com segurança com um contato específico (minha esposa, por exemplo), já não precisaria passar pelo Google. Como a autenticação de identidade já está resolvida, acho que agora o Signal deveria incentivar a criação de apps por cima dele. Acho até que 2FA via Signal seria mais seguro do que por SMS
Eu realmente gostaria de ver também uma comparação entre o protocolo moderno do Signal e coisas como Matrix e MLS. Está tudo evoluindo tão rápido que é difícil acompanhar, então queria entender como essas peças se relacionam hoje
O Matrix é um padrão aberto que usa a combinação Olm + Megolm (Double Ratchet + ratchet de chave de grupo), mas os metadados ficam expostos ao servidor por design (estrutura de grupo visível ao servidor, valores de atributos armazenados em texto claro etc., embora existam melhorias em andamento: blog do Element - plano para criptografar metadados de salas). Como é descentralizado, qualquer pessoa pode criar um servidor.
Por fim, o MLS (RFC 9420) é um protocolo de associação de grupo e troca de chaves, capaz de substituir o Double Ratchet, e recentemente também surgiram propostas para incorporar resistência pós-quântica. Seu desempenho é eficiente, com custo O(log N) por grupo. Ainda não está maduro e é mais complexo que o Double Ratchet. A adoção é lenta, mas, por ser um padrão IETF, o Google o usa no RCS, e há adoção em Discord/Webex VoIP etc. Ele não oferece ocultação de metadados nem negabilidade criptográfica
Este texto é um dos melhores que já li sobre criptografia. Eu achava que tinha um nível razoável de compreensão do tema, mas em outros textos parecidos acabei ficando genuinamente cansado no meio do caminho; neste, mesmo tratando de um assunto totalmente novo para mim, consegui acompanhar o raciocínio inteiro sem dificuldade
Alguém que entenda bem de ameaça criptográfica quântica consegue explicar de forma simples por que o protocolo mais recente do Signal ficou mais seguro agora? Mesmo lendo, não entendi exatamente por que ele ficou mais seguro. Também queria saber se há alguma perda perceptível de desempenho
Explicando de forma simples: o cenário clássico de ameaça é o inimigo pensar "não consigo descriptografar isso agora, mas quando computadores quânticos forem viáveis no futuro, vou pegar todo o material cifrado que coletei hoje e quebrar tudo de uma vez". É o modelo de "harvest and decrypt". Se o Signal precisa manter segredos por muito tempo a partir de agora, então acordos de chave pós-quânticos já são necessários hoje. É por isso que novos protocolos como o PQXDH são necessários.
O ratchet pós-quântico é importante porque existe uma ameaça muito real de que, além de coletar ciphertexts por muito tempo, o atacante um dia consiga comprometer o dispositivo ou extrair chaves por alguma falha de implementação. Você precisa de defesa em duas camadas: forward secrecy e post-compromise security. Se as chaves continuam sendo renovadas a cada momento, uma exposição pontual não coloca em risco nem as mensagens passadas nem as futuras. Para que essa defesa continue funcionando direito em um ambiente de criptografia pós-quântica, a estrutura inteira do ratchet também precisa ser pós-quântica. Caso contrário, o atacante passa a mirar justamente a parte do ratchet, e toda a segurança desmorona
A implementação anterior de criptografia resistente a quantum do Signal não tinha PCS (segurança pós-comprometimento). Agora tem. Foi bom finalmente entender o que significava PCS. Eu esperava que fosse um conceito totalmente novo, mas fiquei um pouco decepcionado ao descobrir que já era algo usado até no protocolo OTR (off-the-record). Essa troca de chaves não acontece com frequência, então o impacto real de desempenho é praticamente inexistente
Resumo do blog oficial:
Sono pazzi, questi Romani (esses romanos são malucos)