Mensagens criptografadas on Arpokrat

Aplicações de mensagens encriptadas 2026: a encriptação já não chega

Thu, 10 Sep 2026 00:00:00 +0000

Abra o WhatsApp, o Telegram, o Signal, o Messenger, o Google Messages. Todas estas aplicações apresentam hoje a mesma promessa algures na sua interface: encriptação ponta a ponta. A fórmula tornou-se um argumento comercial padrão, tal como o «sem fidelização» de um operador móvel. Já não distingue nada, precisamente porque se tornou verdadeira em quase todo o lado.

E, no entanto, estas aplicações não se parecem em nada. Uma exige o seu número de telemóvel e entrega à justiça a lista das pessoas que o têm nos contactos. Outra não sabe literalmente nada sobre si, nem sequer que existe uma conta. Entre as duas, uma quinzena de projetos faz opções muito diferentes, e nenhum as explica com clareza na sua página inicial.

A encriptação ponta a ponta significa que o conteúdo das suas mensagens é ilegível para o intermediário que as transporta. É uma conquista importante, e seria absurdo desvalorizá-la. Mas nada diz sobre aquilo que esse mesmo intermediário fica a saber fora do conteúdo: que escreveu, a quem, a que horas, a partir de que endereço IP, com que frequência, em que grupos, com que número de telemóvel associado à sua identidade civil.

A encriptação protege aquilo que diz. Não protege o facto de o ter dito, nem a quem, nem quando, nem de onde.

Este artigo não estabelece uma classificação. Não existe a melhor aplicação de mensagens em absoluto, porque não existe um adversário genérico. O que este trabalho propõe é, primeiro, uma grelha de sete critérios que permite avaliar qualquer aplicação, incluindo as que ainda não existem; depois, uma ficha honesta sobre cada uma das catorze aplicações escolhidas; e, por fim, recomendações consoante o perfil de ameaça. Cada ficha inclui uma rubrica dedicada àquilo que a aplicação não protege, sem exceção, incluindo a nossa.

Índice

Os sete critérios que substituem a encriptação

Esta secção é a mais importante do artigo. Se ler apenas uma, leia esta: permitir-lhe-á avaliar por si próprio qualquer aplicação de mensagens, incluindo as que surjam depois da publicação deste texto.

A encriptação ponta a ponta, uma conquista que já não distingue

O protocolo Signal, publicado em 2013 e analisado formalmente por investigadores de criptografia desde então, tornou-se o padrão de facto. O WhatsApp usa-o desde 2016, o Google Messages usa-o, o Messenger usa-o. O debate criptográfico está em grande medida encerrado quanto ao conteúdo das conversas a dois.

As perguntas que continuam úteis já não incidem sobre a presença da encriptação, mas sobre as suas modalidades. Está ativada por omissão ou é preciso pedi-la? Cobre os grupos ou apenas as trocas a dois? Cobre as cópias de segurança, ou vão estas em claro para a Google e a Apple? Existe confidencialidade persistente, isto é, uma rotação regular de chaves que garanta que o comprometimento de uma chave hoje não dá acesso às mensagens de ontem?

Estas perguntas ainda distinguem. A presença da palavra «encriptado» numa página de marketing, não.

Os metadados, o que o serviço sabe sem ler as suas mensagens

Em maio de 2014, num debate público na Universidade Johns Hopkins frente ao jurista David Cole, o antigo diretor da NSA e da CIA Michael Hayden proferiu uma frase que se tornou célebre. Cole acabara de citar o antigo consultor jurídico da NSA Stewart Baker, segundo o qual «os metadados dizem-lhe absolutamente tudo sobre a vida de alguém e, se tiver metadados suficientes, não precisa mesmo do conteúdo». Hayden respondeu, concordando: «Matamos pessoas com base em metadados.» Acrescentou de imediato que não era isso que os programas norte-americanos de recolha interna faziam, precisão que importa restituir por honestidade. Nada muda no essencial: o mais alto responsável dos serviços secretos norte-americanos confirmou publicamente que os metadados bastam para decisões letais.

Um metadado, numa aplicação de mensagens, é tudo o que não é o conteúdo: quem escreve a quem, a que horas, a partir de que endereço IP, com que frequência, em que grupos, com que tamanho de ficheiro. Reconstituir uma ligação entre um jornalista e uma fonte não exige ler as suas trocas. Basta constatar que começaram a escrever-se três dias antes da publicação de uma investigação. O mesmo raciocínio vale para um advogado e o seu cliente, um médico e o seu doente, um trabalhador e um sindicato, duas pessoas que não querem que a sua relação seja conhecida.

Um serviço pode, portanto, ser irrepreensível na encriptação do conteúdo e perfeitamente transparente quanto ao resto. É até a situação mais frequente. Detalhámos noutro lugar como este mesmo raciocínio se aplica a outros sinais passivos do quotidiano, nomeadamente no nosso artigo sobre a geolocalização permanente do telemóvel e na nossa análise do sistema SignalTrace da Leonardo, que reconstitui trajetos e relações apenas a partir dos identificadores Bluetooth captados de passagem.

Boa pergunta a fazer a qualquer editor: o que sobra nos vossos servidores se um juiz os apreender amanhã de manhã?

O identificador exigido, um número, um endereço ou nada

É o critério mais concreto e o mais subestimado. Coexistem três modelos.

O número de telemóvel. Na maioria dos países está associado a um documento de identificação. É único, duradouro, e já está presente nos contactos de centenas de pessoas. Exigir um número é ligar cada conta a uma identidade civil e tornar trivial a descoberta do grafo social: basta comparar as listas de contactos. O número é também o ponto fraco bem conhecido da autenticação, como mostrámos no nosso artigo sobre a autenticação de dois fatores por SMS: um SIM swap bem sucedido não rouba apenas um código, rouba uma identidade de mensagens.

O endereço de correio eletrónico ou um identificador aleatório. Melhor, porque um endereço descartável custa alguns segundos e um identificador aleatório nada diz. Continua, porém, a ser um identificador duradouro do lado do servidor, logo um ponto de apoio para correlacionar sessões ao longo do tempo.

Nenhum identificador. É o modelo mais recente e mais raro. Não existe conta alguma, nem diretório, nem endereço permanente. Existe como um conjunto de chaves criptográficas no seu aparelho, e é contactado através de uma hiperligação de convite de utilização única. Nada a introduzir, nada a fugir, nada a correlacionar.

Código aberto e auditoria independente, duas noções que importa deixar de confundir

São duas coisas diferentes e é preciso parar de as apresentar em conjunto.

Código aberto significa que o código é legível. É uma condição necessária da confiança, não uma prova de segurança. Ninguém lê o código, salvo por acidente. Falhas graves sobreviveram durante anos em projetos livres muito observados.

Auditoria independente significa que um terceiro pago para procurar falhas as procurou e publicou o que encontrou. É infinitamente mais forte e infinitamente mais raro, porque é caro.

Depois há que distinguir duas naturezas de auditoria. Uma revisão da conceção criptográfica examina se o protocolo está bem pensado no papel. Uma auditoria de implementação examina se o código faz de facto aquilo que o protocolo afirma. Ambas são úteis, não provam a mesma coisa, e um projeto pode ter a primeira sem a segunda.

O caso da Threema ilustra na perfeição o interesse desta abordagem. Em 2022, três investigadores da ETH de Zurique encontraram sete ataques contra o seu protocolo, em três modelos de ameaça diferentes, e comunicaram-nos ao editor. A Threema respondeu com um novo protocolo, o Ibex, publicado no final de novembro de 2022. Uma aplicação fechada e não auditada nunca teria conhecido este episódio, o que não significaria que fosse mais segura.

A jurisdição e o CLOUD Act

O local de estabelecimento de uma empresa determina que governos a podem obrigar. É um critério jurídico, não técnico, e é decisivo.

O CLOUD Act, aprovado nos Estados Unidos em 2018, resolve uma questão levantada pelo caso Microsoft Ireland: pode uma empresa norte-americana recusar entregar mensagens de correio guardadas num servidor irlandês? A resposta do legislador é não. O texto obriga os fornecedores sob jurisdição norte-americana a comunicar os dados que controlam, independentemente do local de armazenamento. Um servidor em Frankfurt explorado por uma sociedade norte-americana continua ao alcance de uma requisição norte-americana. O fornecedor pode opor-se se o pedido colidir com o direito estrangeiro, mas a oposição é um procedimento, não um escudo.

A consequência prática é simples: alojar na Europa não chega se o alojador, a empresa-mãe ou a holding dependerem do direito norte-americano. A pergunta a fazer não é «onde estão os vossos servidores», mas «quem vos pode obrigar legalmente, e com que base».

Importa acrescentar duas nuances. Primeiro, uma jurisdição protetora de nada serve se o serviço detiver ainda assim dados exploráveis: a melhor defesa continua a ser não ter nada para entregar. Depois, uma jurisdição hostil não condena um serviço que, estruturalmente, nada sabe. O Signal é norte-americano e nunca conseguiu entregar mais do que duas marcas temporais.

A continuidade do projeto, o critério que ninguém observa

Uma aplicação de mensagens muito bem concebida que desaparece em dezoito meses deixa-o com uma lista de contactos inutilizável e, muitas vezes, um histórico perdido. Este critério nunca aparece nos comparativos. O ano de 2026 tornou-o incontornável.

Em abril de 2026, a Session Technology Foundation anunciou publicamente que apenas reunira cerca de 65 000 dólares em donativos, que precisava de aproximadamente um milhão de dólares por ano para funcionar, e que a sua tesouraria não aguentaria para além de julho. Todos os trabalhadores foram dispensados e o desenvolvimento parou. O Session tem mais de um milhão de utilizadores ativos por mês. Em junho, a fundação anunciou que o projeto tinha sido salvo por donativos de milhares de utilizadores, na sua maioria de pequeno montante, e que recomeçava com uma equipa de três programadores conduzida pelo arquiteto de software Jason Rhinelander.

Três semanas mais tarde, a 9 de julho de 2026, o projeto Briar publicava uma mensagem semelhante: depois de ter equacionado o encerramento, passa a modo de manutenção, ou seja, apenas correções de segurança e de erros, sem desenvolvimento de novas funcionalidades, por falta de financiamento duradouro.

Dois projetos emblemáticos, dois modelos económicos diferentes, o mesmo ano, o mesmo impasse. A pergunta a fazer antes de adotar uma aplicação de mensagens passou, portanto, a ser: quem paga, quanto e durante quanto tempo? Uma fundação que vive de donativos, uma empresa que vende licenças, um projeto universitário subsidiado e um programa comunitário voluntário não têm a mesma esperança de vida, e isso nada tem a ver com a qualidade da sua criptografia.

O lado prático, um critério de segurança de pleno direito

Este último critério é muitas vezes tratado com desprezo pelos puristas. É um erro.

Uma aplicação de mensagens que os seus interlocutores recusam instalar não protege ninguém, porque a conversa acontecerá noutro sítio, em claro. Uma aplicação cujas notificações não chegam empurra os utilizadores de volta para o WhatsApp nas trocas urgentes. Uma aplicação que exige que ambas as pessoas estejam ligadas no mesmo instante não serve para uma correspondência normal entre dois fusos horários.

A segurança real de um sistema é a do seu uso real, não a da sua ficha técnica. Um modelo um pouco menos puro que os seus contactos usam efetivamente protege mais do que um modelo perfeito que só você usa.

As aplicações de grande público

O WhatsApp é a aplicação de mensagens mais usada no mundo. Pertence à Meta, é gratuita, e o seu modelo económico assenta no ecossistema publicitário do grupo e nos serviços a empresas.

O que protege realmente. O conteúdo das mensagens, com o protocolo Signal, desde 2016. Esta implementação é séria e importa dizê-lo com clareza: o conteúdo das suas conversas no WhatsApp não é legível pela Meta. As cópias de segurança encriptadas ponta a ponta existem e merecem ser ativadas, pois não o estão por omissão. A aplicação é extremamente fiável, está disponível em todo o lado, e os seus contactos já a têm.

O que não protege. Todo o resto. Mediante simples requisição, a Meta comunica os dados de assinante: nome da conta, data de criação, última ligação, endereço IP, endereço de correio eletrónico. Mediante mandado de busca, a empresa fornece a lista de contactos da pessoa visada e também a lista dos outros utilizadores do WhatsApp que têm essa pessoa nos seus contactos. Por outras palavras, o grafo social é entregável nos dois sentidos. Os metadados conservados incluem as marcas temporais, os identificadores de remetente e de destinatário, os estados de entrega, a composição dos grupos e as suas alterações. Segundo um documento do FBI tornado público, o WhatsApp é capaz de produzir certos metadados de um utilizador visado a cada quinze minutos no âmbito de uma vigilância em tempo real. Por fim, o número de telemóvel é obrigatório, e a Meta está sujeita ao CLOUD Act.

Para quem é feita. Para toda a gente, como canal de comunicação corrente em que se aceita que o grafo relacional seja conhecido pela Meta e comunicável a uma autoridade judicial.

O Telegram é muitas vezes arrumado entre as aplicações de mensagens seguras. É um mal-entendido que importa desfazer sem agressividade, porque o Telegram é excelente naquilo que realmente faz.

O que protege realmente. Nada mais do que um serviço em linha clássico, para o uso corrente. As conversas normais, chamadas conversas na nuvem, são encriptadas entre o cliente e o servidor, sendo depois guardadas encriptadas do lado do Telegram, que detém os meios para as ler. A encriptação ponta a ponta só está disponível nas conversas secretas, que não estão ativadas por omissão, se limitam às trocas a dois, permanecem ligadas ao aparelho de origem e não se sincronizam. O que o Telegram faz excelentemente, em contrapartida, é o grupo massivo, o canal de difusão, a partilha de ficheiros volumosos e a presença em vários aparelhos. É uma formidável rede de publicação, e é assim que deve ser avaliado.

O que não protege. O conteúdo das conversas normais face ao editor, o número de telemóvel, o endereço IP. A posição da empresa mudou em setembro de 2024, após a detenção de Pavel Durov em França: o Telegram comunica agora os números e endereços IP dos utilizadores denunciados, em resposta a pedidos legais válidos, quando o compromisso anterior limitava essas transmissões aos casos de terrorismo. Os números publicados para 2024 traduzem a mudança de escala: cerca de 900 pedidos satisfeitos nos Estados Unidos para 2253 utilizadores, 14 641 na Índia para 23 535 utilizadores, 142 no Reino Unido. O grupo está, além disso, registado nas Ilhas Virgens Britânicas e é dirigido a partir do Dubai, uma estrutura cuja opacidade é, em si mesma, um dado de análise.

Para quem é feito. Para a difusão pública, as comunidades alargadas, o acompanhamento noticioso. Não para uma conversa que deva permanecer confidencial face ao editor.

O padrão de facto

Signal

O Signal é a referência, e este artigo trata-o como tal. É editado pela Signal Foundation, uma organização sem fins lucrativos norte-americana financiada por donativos e por uma dotação inicial de Brian Acton.

O que protege realmente. O conteúdo, com o protocolo que inventou e que serve de referência ao setor. Mas sobretudo, e é isso que o distingue, o resto: descoberta confidencial de contactos, remetente selado, minimização sistemática dos dados conservados. A prova não é declarativa, é judicial. O Signal publica as suas respostas às requisições numa página dedicada, e essas respostas parecem-se todas: a organização só pode fornecer a marca temporal de criação da conta e a data da última ligação. Num processo levado ao tribunal do Distrito de Columbia, a justiça pediu as informações de assinante de trinta e sete números de telemóvel. A resposta foi a mesma. É o único histórico público de resistência a requisições com esta qualidade em todo este comparativo, e vale mais do que qualquer promessa de marketing.

O que não protege. O número de telemóvel continua obrigatório na inscrição em 2026. Os nomes de utilizador, introduzidos em 2024, permitem deixar de comunicar o número aos contactos, o que é um progresso real, mas não suprimem a exigência na criação da conta. Trabalhos públicos indicam que o Signal estuda uma inscrição sem número, possivelmente apoiada num pagamento único para limitar os abusos, mas no momento em que escrevemos não está disponível. O Signal está, além disso, sujeito ao direito norte-americano, logo ao CLOUD Act: a proteção não vem da jurisdição, vem do facto de não haver nada para entregar. Por fim, a infraestrutura é centralizada e o ecossistema está fechado a clientes de terceiros, ponto ao qual voltamos mais adiante.

Para quem é feito. Para praticamente toda a gente. É a melhor relação entre proteção e adoção real do mercado, e é a recomendação por omissão quando o número de telemóvel não é um problema no seu modelo de ameaça.

Molly

O Molly é uma bifurcação endurecida do Signal para Android. Não muda nem o protocolo, nem a rede, nem o modelo de identificador: endurece o cliente.

O que protege realmente. Aquilo que o Signal não protege do lado do aparelho. O Molly encripta a base de dados local atrás de uma frase-passe, o que tranca a aplicação inteira, e apaga a memória viva com dados aleatórios ao trancar, para resistir a uma análise forense após apreensão. Permite também encaminhar o tráfego através de um proxy SOCKS ou do Tor. Uma variante Molly-FOSS suprime os componentes proprietários da Google. Tudo coisas que o cliente oficial não faz.

O que não protege. Tudo o que depende do servidor. O Molly usa os servidores do Signal, exige portanto um número de telemóvel e herda exatamente o mesmo perfil de metadados e a mesma jurisdição. Só existe em Android. E funciona na rede do Signal com a tolerância da fundação, não com a sua autorização formal, o que se mantém sem incidentes há anos.

Para quem é feito. Para um utilizador do Signal em Android cujo modelo de ameaça inclua a apreensão física do telemóvel: jornalista em deslocação, ativista, advogado que atravessa uma fronteira.

As aplicações sem número de telemóvel

Session

O Session fez uma aposta radical: suprimir o número e o correio eletrónico. Na inscrição, a aplicação gera um identificador de conta aleatório, e nada mais é pedido. O projeto é conduzido pela Session Technology Foundation, uma fundação de direito suíço.

O que protege realmente. A identidade na inscrição, e o endereço IP. As mensagens transitam por uma rede descentralizada de nós em encaminhamento em cebola, de modo que nenhum servidor conhece ao mesmo tempo a origem e o destino. O código dos clientes Android, iOS e computador foi objeto de uma auditoria publicada pela empresa francesa Quarkslab, que assinalou sete problemas em Android, sete em iOS e dois no cliente de computador, na maioria já corrigidos. A aplicação está disponível em todas as plataformas e parece-se com uma aplicação de mensagens comum, o que não é pouco nesta categoria.

O que não protege. O Session retirou a confidencialidade persistente em 2021, invocando problemas de estabilidade com a sua arquitetura descentralizada. Em concreto, o comprometimento de uma chave de longa duração expõe as mensagens passadas. A fundação anunciou em dezembro de 2025 um protocolo V2 que reintroduz a confidencialidade persistente e acrescenta uma troca de chaves pós-quântica baseada em ML-KEM, mas esse protocolo não estava finalizado no momento em que escrevemos. E sobretudo, o critério da continuidade pesa muito aqui: o projeto esteve a algumas semanas do encerramento em 2026 e funciona agora com três programadores para mais de um milhão de utilizadores.

Para quem é feito. Para quem quer dispensar o número de telemóvel sem mudar os seus hábitos de utilização, e aceita a ausência atual de confidencialidade persistente.

Threema

A Threema é uma empresa suíça que vende a sua aplicação. É o único ator pago deste comparativo, e é precisamente isso que torna o seu modelo legível.

O que protege realmente. A identidade e a jurisdição. Na instalação, a aplicação gera um Threema ID aleatório. O número de telemóvel e o endereço de correio eletrónico são facultativos e servem apenas para ser encontrado pelos seus contactos, algo que nada obriga a ativar. Os servidores pertencem à empresa e encontram-se num centro de dados certificado ISO 27001 em Zurique, sob direito suíço, fora do CLOUD Act. O código-fonte está publicado e as compilações reproduzíveis estão disponíveis em Android, o que permite verificar que a aplicação distribuída corresponde ao código. A Threema mandou auditar as suas aplicações móveis pela Cure53 em outubro de 2020, e depois a sua aplicação de computador em janeiro de 2024. O protocolo Ibex, adotado no final de 2022, foi objeto de uma prova de segurança formal publicada por investigadores alemães em 2023.

O que não protege. O preço, cerca de seis euros em compra única, é um obstáculo real à adoção pelos seus próximos, e é o principal travão prático. O episódio da ETH de Zurique em 2022 recorda, além disso, que mesmo um ator sério pode ter um protocolo vulnerável durante anos: sete ataques encontrados, um protocolo inteiramente refeito. Por fim, o identificador Threema continua a ser um identificador duradouro do lado do servidor, o que não é o modelo sem qualquer identificador.

Para quem é feita. Para uma empresa europeia, um escritório de advogados, uma administração, ou um particular que prefira pagar por um produto a depender de donativos, e que queira uma jurisdição suíça clara.

Wire

A Wire mudou muito de natureza. Nascida como aplicação de mensagens de grande público, reposicionou-se nas organizações, nas empresas e no setor público.

O que protege realmente. O conteúdo, com o protocolo Proteus e depois com o MLS, o padrão de mensagens de grupo do IETF de que a Wire foi um dos primeiros implementadores sérios. A inscrição faz-se por correio eletrónico, o que evita o número de telemóvel. As auditorias são públicas: a Kudelski Security e a X41 D-Sec publicaram uma revisão da implementação do protocolo em 2017, e depois auditorias aplicacionais dos clientes iOS, Android e web em 2018.

O que não protege. Os metadados, que a Wire conserva em claro do lado do servidor, um ponto que o editor nunca escondeu e que tem sido criticado com regularidade. A estrutura jurídica é também complexa: as operações dependem da Wire Swiss GmbH na Suíça, a holding do grupo está estabelecida em Berlim e o editor afirma que mais de 90 % do capital é detido por investidores institucionais europeus, mas foi criada uma entidade norte-americana no Delaware em 2019. Esta complexidade merece ser compreendida antes de escolher a Wire para um uso sensível.

Para quem é feita. Para uma organização que precise de colaboração encriptada conforme, com apoio comercial e administração centralizada, mais do que para um indivíduo à procura de anonimato.

Element e o protocolo Matrix

O Element é o cliente principal do Matrix, um protocolo aberto e federado. O modelo é diferente de todos os outros deste comparativo: qualquer pessoa pode alojar o seu próprio servidor, e os servidores comunicam entre si como o fazem os servidores de correio eletrónico.

O que protege realmente. A autonomia. Uma organização pode alojar o seu servidor, controlar a sua infraestrutura, não depender de nenhum editor e manter-se contactável a partir do resto da rede. É o único modelo deste comparativo que oferece esta combinação, e é a razão pela qual várias administrações europeias o escolheram. A encriptação ponta a ponta das mensagens está implementada.

O que não protege. Os metadados, e isso é estrutural. O administrador do seu servidor vê quem fala com quem, quando, e em que salas. Os metadados de sala, nome, tema e outros eventos de estado, são guardados em claro no servidor. O Element trabalha na encriptação destes eventos de estado, mas a funcionalidade ainda era experimental e reservada às opções de laboratório em setembro de 2025. A federação agrava o problema: o histórico de uma sala é replicado nos servidores participantes, que o conservam. O editor comercializa, aliás, uma passagem destinada a filtrar a federação para limitar estas fugas, o que é uma confissão útil.

Para quem é feito. Para uma organização que queira soberania sobre a sua infraestrutura e cujo adversário não seja o seu próprio administrador de sistemas. Não para um indivíduo que procure dissimular as suas relações.

As aplicações sem qualquer identificador

É a categoria mais recente. O princípio não é esconder um identificador, mas não criar nenhum.

SimpleX Chat

O SimpleX Chat é a primeira rede de mensagens sem identificador de utilizador, incluindo aleatório. É um avanço concetual real e importa apresentá-lo como tal.

O que protege realmente. O grafo social, por construção. Não há conta, nem diretório, nem endereço permanente. Cada conversa assenta em filas de espera unidirecionais alojadas em retransmissores diferentes: o que envia passa por uma fila num retransmissor, as respostas voltam por outra fila noutro retransmissor, de modo que nenhum retransmissor vê as duas extremidades. Os retransmissores são cegos, não conhecem nem quem deposita nem o destinatário. O projeto publicou duas auditorias independentes realizadas pela Trail of Bits: uma avaliação de segurança da implementação em novembro de 2022, e depois uma revisão da conceção criptográfica dos protocolos em outubro de 2024, incluindo uma verificação formal do protocolo de negociação das filas e concluindo por três problemas de gravidade média e um de gravidade baixa, todos de exploração difícil. O protocolo acrescenta uma camada pós-quântica ao duplo roquete. Os retransmissores podem ser autoalojados, existem clientes em Android, iOS e computador, e o editor, SimpleX Chat Ltd, é uma sociedade britânica registada desde outubro de 2021.

O que não protege. Duas coisas merecem ser ditas. Primeiro, o alojamento por omissão: os retransmissores operados pelo projeto correm num único fornecedor, a Linode, filial da norte-americana Akamai, nos seus centros europeus de Londres, Frankfurt e Estocolmo. Um utilizador que não ative o Tor e não mude de retransmissor depende, portanto, de uma infraestrutura explorada por uma sociedade norte-americana, o que repõe o CLOUD Act no quadro. O assunto está documentado publicamente no repositório do projeto. Depois, a experiência de utilização continua exigente: estabelecer uma ligação implica uma troca de hiperligação ou de código QR, a fiabilidade das notificações em iOS foi durante muito tempo um ponto fraco e a escala dos grandes grupos ainda é um trabalho em curso. O financiamento, por fim, assenta agora num financiamento colaborativo em capital lançado em agosto de 2026.

Para quem é feito. Para quem quer o modelo sem identificador com o melhor nível de verificação externa disponível hoje, e aceita uma utilização mais técnica.

Arpokrat Messenger

O Arpokrat Messenger é o nosso produto, e esta ficha segue a mesma grelha que as outras. Importa começar por dizê-lo sem rodeios: o Arpokrat Messenger é uma bifurcação do SimpleX. A arquitetura descrita acima, ausência de identificadores, filas unidirecionais, retransmissores cegos, não é nossa, é a do SimpleX. Não pretendemos tê-la melhorado no plano criptográfico, damos-lhe crédito, exatamente como a nossa página de protocolo faz de forma explícita. É a mesma posição que mantemos para o ArpokratOS face ao GrapheneOS.

O que protege realmente. Aquilo que o SimpleX protege, mais uma série de opções de exploração e de produto. Os retransmissores que operamos estão repartidos por cinco jurisdições escolhidas pelo seu direito, a Suíça, a Islândia, o Panamá, a Malásia e a Maurícia, nenhuma norte-americana, e a infraestrutura não assenta em nenhum hiperescalador norte-americano, nem Amazon Web Services, nem Google Cloud, nem Microsoft Azure, nem Cloudflare. As mensagens em espera vivem apenas na memória viva, a memória virtual está desativada, um corte de energia apaga tudo, e os manifestos de publicação são assinados numa máquina Qubes OS isolada da rede. O Tor ativa-se com um único botão, sem aplicação de terceiros, e permanece desativado por omissão. O modo incógnito atribui um perfil diferente por contacto, nome visível e retransmissor incluídos, o que impede ligar uma vida profissional a uma vida privada. Os retransmissores podem ser autoalojados por qualquer pessoa, sendo o software aberto. Os clientes são publicados sob licença AGPLv3. A carteira não custodial gere Bitcoin, Ethereum, Monero, Polygon, Solana e Tron, sem que as chaves saiam do aparelho, e o suporte do Zcash está anunciado sem estar disponível até à data. O Swap integrado é um agregador que compara as ofertas de fornecedores independentes, classificando cada um de A a D consoante o nível de verificação de identidade exigido, de A para nenhum KYC a D para KYC obrigatório, transitando os fundos diretamente entre o utilizador e o fornecedor escolhido. Tanto quanto sabemos, nenhuma outra aplicação de mensagens propõe esta classificação. O editor é, por fim, uma entidade comercial identificável, a Arpokrat GmbH, domiciliada em Zug, na Suíça, com endereço postal público, um warrant canary assinado em PGP, renovado segundo uma janela de validade de sessenta dias, e um compromisso de resposta do apoio em menos de 24 horas. A aplicação é gratuita, sem publicidade.

O que não protege. E é aqui que é preciso ser preciso, porque é o único modo de ser credível quanto ao resto.

O Arpokrat Messenger não dispõe até à data de nenhuma auditoria criptográfica independente publicada em seu nome. O SimpleX tem duas. O protocolo subjacente está, portanto, auditado; a nossa implementação e a nossa exploração não estão, e não é a mesma coisa, como explicado atrás neste artigo.

A Arpokrat não tem qualquer histórico público de resistência a requisições judiciais. O Signal tem um, verificável, estendido por anos. Um warrant canary é um compromisso sério, não é um precedente judicial.

A aplicação hoje só existe em Android. As versões iOS, Linux, macOS e Windows estão anunciadas, não disponíveis. Para quem troca mensagens com utilizadores de iPhone, é um obstáculo imediato e não há forma de o contornar.

A rede é, por fim, jovem e pequena. O número de utilizadores não faz a segurança, mas faz a disponibilidade dos seus correspondentes, e é um critério legítimo que nós próprios defendemos atrás.

Para quem é feito. Para quem quer uma arquitetura sem identificador sem renunciar ao uso corrente, e prefere uma entidade comercial identificável a um projeto comunitário cujo financiamento pode interromper-se. O posicionamento que defendemos não é «a mais privada», é mais estreito e mais honesto: a mais utilizável entre as arquiteturas sem identificador, com um modelo assíncrono que as arquiteturas ponto a ponto não oferecem, um ecossistema e um apoio comercial.

Briar

O Briar é provavelmente o projeto mais intransigente desta lista. Não há servidor algum: as mensagens passam diretamente de um aparelho para outro através do Tor e, na falta de ligação, por Wi-Fi ou Bluetooth entre aparelhos próximos.

O que protege realmente. Tudo o que depende de uma infraestrutura, uma vez que não existe nenhuma. Nada para apreender, nada para requisitar, nenhum operador para obrigar. O modo em malha fora de linha funciona realmente em caso de corte da Internet, o que faz do Briar a ferramenta de referência para apagões e manifestações. O código foi auditado pela Cure53 em março de 2017, com doze problemas assinalados e corrigidos. O projeto é livre e a sua conceção faz autoridade. O Briar Mailbox, uma aplicação distinta a instalar num aparelho Android de reserva deixado ligado, permite receber mensagens enquanto o telemóvel principal está fora de linha, o que responde parcialmente ao principal limite do modelo ponto a ponto.

O que não protege. O conforto de utilização, e agora a trajetória do projeto. O consumo de bateria é elevado, o funcionamento em segundo plano em Android é irregular, faltam a cópia de segurança da conta e os anexos, e adicionar um contacto é trabalhoso. Não existe versão iOS. A versão para computador continua em beta, sendo a última a 0.6.5-beta publicada a 20 de fevereiro de 2026. E sobretudo, o anúncio de 9 de julho de 2026 coloca o projeto em modo de manutenção: correções de segurança e de erros, sem desenvolvimento de funcionalidades. O projeto esclarece que os rumores de encerramento completo estão ultrapassados, mas a ambição está claramente suspensa.

Para quem é feito. Para uma zona de corte da Internet, uma manifestação, um contexto de censura, ou um grupo reduzido que aceite o constrangimento em troca da ausência total de infraestrutura.

Cwtch

O Cwtch é desenvolvido pela Open Privacy Research Society, uma associação sem fins lucrativos canadiana estabelecida em Vancouver. O projeto visa explicitamente as mensagens de grupo resistentes aos metadados.

O que protege realmente. Os metadados, incluindo em grupo, que é o problema difícil. As ligações passam por serviços onion Tor v3, e os servidores que retransmitem as conversas de grupo são concebidos para não serem fiáveis por princípio: nada devem aprender. A versão 1.13, publicada em setembro de 2023, marcou a saída da longa fase alfa e beta, e o projeto prosseguiu até à 1.15.

O que não protege. A continuidade, mais uma vez. A organização vive essencialmente de donativos individuais e repetiu-o publicamente em várias ocasiões. Não existe versão iOS. O ritmo de desenvolvimento é o de uma equipa pequena, e o ecossistema de utilizadores é muito restrito. Não encontrámos auditoria externa publicada equivalente às do SimpleX ou do Briar.

Para quem é feito. Para um grupo ativista ou de investigação que precise de conversas coletivas resistentes aos metadados e cujos membros estejam tecnicamente à vontade.

A convergência de 2026, a aplicação de mensagens torna-se carteira

Eis a observação mais interessante deste ano, e tanto quanto sabemos ninguém a formulou ainda assim.

Em 2026, três bifurcações de três protocolos diferentes, desenvolvidas por três equipas sem ligação entre si, tiveram a mesma intuição no mesmo momento: integrar uma carteira não custodial numa aplicação de mensagens encriptadas. O Radar é uma bifurcação do Signal com Bitcoin na Lightning. O Zerion é um derivado do Briar com Bitcoin e Monero. O Arpokrat Messenger é uma bifurcação do SimpleX com uma carteira multicadeia e um agregador de swap.

Três bases técnicas opostas, uma mesma conclusão. Não é acaso, é o sinal de que duas necessidades que eram tratadas separadamente se juntam. Enviar dinheiro e enviar uma mensagem colocam o mesmo problema: um intermediário que conhece as duas extremidades. A resposta construída para as mensagens, encriptação do conteúdo e minimização dos metadados, é exatamente aquela que os utilizadores de criptomoedas procuram. E a aplicação de mensagens é o único sítio onde já se conhece o destinatário.

As três abordagens são, contudo, muito diferentes, e a comparação é instrutiva.

Radar

O Radar foi lançado a 7 de julho de 2026 pela equipa da Cake Wallet, sob uma entidade distinta, a Radar Chat, Inc., dirigida pelo seu fundador Vikrant Sharma. É uma bifurcação do Signal, gratuita, de código aberto, disponível em iOS e Android. A carteira é não custodial, com uma frase de recuperação de doze palavras e cópias de segurança encriptadas. A camada de pagamento merece uma precisão, porque as fontes não dizem a mesma coisa. O sítio do Radar descreve uma carteira Bitcoin apoiada na rede Lightning, atribui um endereço Lightning a cada conta, e nada mais menciona. Vários artigos publicados em julho de 2026 indicam, em contrapartida, que a mecânica subjacente assenta em Spark, uma rede Bitcoin de camada 2 integrada através do SDK Breez, liquidando-se então uma transferência entre dois utilizadores do Radar de Spark para Spark em menos de um segundo. As duas versões não se excluem, uma vez que a documentação da Breez descreve um SDK que suporta Spark e Lightning em conjunto, endereços Lightning e faturas bolt11 incluídos. Na falta de confirmação pública pelo próprio editor, ficamo-nos por aquilo que é verificável no seu próprio sítio: pagamentos Bitcoin não custodiais alcançáveis pela rede Lightning.

A escolha mais marcante está noutro lugar. O Radar não é uma rede separada: liga-se com a sua conta Signal existente, e os contactos, conversas, grupos e nome de utilizador acompanham-no. É a vantagem competitiva do Radar, e é também a sua principal questão em aberto.

Esta interoperabilidade implica, com efeito, que o Radar herde integralmente o modelo do Signal: o número de telemóvel continua a ser o identificador, o código PIN do Signal comanda a recuperação da conta e, portanto, por omissão, o acesso às chaves da carteira que o Radar encripta na conta Signal, e a infraestrutura solicitada é a da Signal Foundation, sob jurisdição norte-americana.

Importa depois colocar a questão da continuidade desta montagem, sem a afirmar como um facto. O Signal recusou historicamente que clientes de terceiros usem os seus servidores: em 2016, o projeto LibreSignal foi abandonado depois de Moxie Marlinspike ter feito saber que não queria nem o nome nem os servidores do Signal usados por uma bifurcação, e excluiu além disso qualquer federação futura. A fundação mantém a capacidade técnica de bloquear um cliente de terceiros pela sua assinatura. Até hoje não o fez, e o Molly usa a rede há anos sem incidentes, precedente que a equipa do Radar invoca explicitamente. O Radar paga, aliás, uma contribuição mensal à Signal Foundation e prevê aumentá-la com o seu crescimento. Nada indica, portanto, que o Radar venha a ser bloqueado. Mas um produto cujo acesso à rede depende da tolerância continuada de um terceiro comporta um risco estrutural que nem o SimpleX nem o Briar comportam, e o utilizador merece sabê-lo antes de aí colocar fundos.

Zerion

O Zerion é um derivado do Briar, construído sobre o protocolo de transporte Bramble, publicado sob GPL v3, e o projeto indica claramente que não é filiado nem aprovado pelo projeto Briar. Só existe em Android.

Importa fazer-lhe justiça, porque faz várias coisas notavelmente bem. Todo o tráfego passa pelo Tor, sem exceção: o seu aparelho constrói um circuito de três saltos, o do seu correspondente constrói outro, e os dois encontram-se num retransmissor de encontro, ou seja seis saltos no total e nenhuma exposição de endereço IP. Cada mensagem é protegida por uma troca de chaves pós-quântica baseada em ML-KEM-768. A versão 3.0 acrescentou uma malha fora de linha por Bluetooth que retransmite mensagens individuais e de grupo pelos telemóveis vizinhos, transportando cada retransmissor apenas material encriptado, bem como um transporte I2P opcional. Um modo endurecido recusa arrancar num aparelho comprometido, sob depurador ou com estruturas de interceção. Desde a versão 3.0.4, um cofre encriptado pode conter carteiras Bitcoin e Monero não custodiais, cujas chaves são geradas no aparelho, protegidas pela sua própria palavra-passe, com compilações reproduzíveis a partir de fontes fixadas e impressões digitais publicadas.

O limite é estrutural e o projeto não o esconde: a sua documentação indica preto no branco que uma mensagem só é entregue quando ambos os aparelhos estão em linha e ligados ao Tor, e que nenhum servidor a conserva entretanto durante longos períodos fora de linha. Por outras palavras, não existe equivalente do Briar Mailbox. É o ponto técnico decisivo, e é o que separa um modelo ponto a ponto de um modelo store and forward no qual um retransmissor cego conserva a mensagem encriptada até que o destinatário a venha buscar. Para uma correspondência normal entre duas pessoas que não estão ligadas ao mesmo tempo, a diferença não é teórica, decide a utilização.

Uma segunda questão fica em aberto, e formulamo-la como pergunta uma vez que não encontrámos qualquer medição pública: qual é a qualidade real das chamadas de áudio e vídeo ponto a ponto numa arquitetura de seis saltos Tor? As opções técnicas anunciadas são sérias, Opus, H.264, encriptação AES-256-GCM e tramas preenchidas, e as chamadas estão desativadas por omissão. Mas o Tor não foi concebido para a latência baixa e, na ausência de medições publicadas, nem o editor nem nós podemos afirmar que a experiência é comparável a uma chamada clássica.

Por fim, não encontrámos auditoria independente publicada para o Zerion.

Comparadas, as três abordagens desenham três compromissos nítidos. O Radar escolhe a adoção imediata ao preço de uma dependência de um terceiro e da manutenção do número de telemóvel. O Zerion escolhe o máximo de resistência de rede ao preço da entregabilidade e da disponibilidade em iPhone. A Arpokrat escolhe o modelo assíncrono e a repartição jurisdicional ao preço de um histórico e de uma auditoria que ainda não existem. Nenhum destes três compromissos é absurdo, e nenhum é gratuito.

Quadro-resumo

Aplicação	Identificador exigido	Jurisdição e alojamento	Metadados do lado do servidor	Auditoria externa publicada	Entrega fora de linha	Código
WhatsApp	Número de telemóvel	Estados Unidos (Meta), CLOUD Act	Extensos, grafo de contactos entregável por mandado	Não para o serviço	Sim	Cliente fechado
Telegram	Número de telemóvel	Ilhas Virgens Britânicas, direção no Dubai	Extensos, conversas na nuvem legíveis pelo editor	Não	Sim	Cliente aberto, servidor fechado
Signal	Número de telemóvel	Estados Unidos, CLOUD Act	Duas marcas temporais, histórico judicial público	Protocolo analisado formalmente	Sim	Aberto
Molly	Número (conta Signal)	Servidores Signal, Estados Unidos	Idênticos ao Signal	Herdada do Signal	Sim	Aberto
Session	Nenhum, identificador aleatório	Suíça, rede de nós descentralizada	Mínimos, sem confidencialidade persistente até à data	Sim, Quarkslab	Sim	Aberto
Threema	Nenhum, Threema ID	Suíça, servidores em Zurique	Mínimos	Sim, Cure53 e ETH de Zurique	Sim	Aberto, pago
Wire	Correio eletrónico ou número	Suíça e Alemanha, entidade norte-americana no Delaware	Conservados em claro	Sim, Kudelski e X41	Sim	Aberto
Element / Matrix	Consoante o servidor, muitas vezes correio	A do seu alojador	Visíveis para o servidor, estado das salas em claro	Auditorias publicadas sobre o protocolo	Sim	Aberto
SimpleX Chat	Nenhum, sem identificador	Reino Unido, retransmissores por omissão na Linode e Akamai	Nenhuma correlação possível por um retransmissor único	Sim, duas auditorias Trail of Bits	Sim	Aberto
Arpokrat Messenger	Nenhum, sem identificador	Suíça (Zug), retransmissores em cinco jurisdições fora dos Estados Unidos	Retransmissores cegos, apenas memória viva	Não até à data	Sim	Aberto, AGPLv3
Briar	Nenhum, sem identificador	Nenhuma, sem servidor	Nenhuns, nada para apreender	Sim, Cure53 em 2017	Via Briar Mailbox	Aberto
Cwtch	Nenhum, sem identificador	Canadá para a associação, servidores não fiáveis por conceção	Resistência aos metadados de grupo	Não identificada	Parcial	Aberto
Radar	Número (conta Signal)	Servidores Signal, Estados Unidos	Idênticos ao Signal	Não identificada	Sim	Aberto
Zerion	Nenhum, sem identificador	Nenhuma, sem servidor	Nenhuns, tudo passa pelo Tor	Não identificada	Não, os dois aparelhos devem estar em linha	Aberto, GPL v3

Que aplicação para que perfil

Não há um vencedor, há situações.

Para a família e os próximos. Signal, sem hesitação. É a única escolha que combina uma proteção séria com uma hipótese real de os seus interlocutores a instalarem. Se o número de telemóvel o incomoda, ative um nome de utilizador para não o comunicar. Se os seus próximos recusam absolutamente mudar, ative pelo menos as cópias de segurança encriptadas ponta a ponta no WhatsApp: não é a mesma proteção, mas é um progresso real e gratuito.

Para um jornalista com fontes. O problema não é o conteúdo, é a ligação. Uma arquitetura sem identificador é aqui a única resposta coerente: SimpleX Chat ou Arpokrat Messenger, com o Tor ativado e um perfil diferente por fonte. Se a sua fonte já usa o Signal e recusa instalar outra coisa, use o Signal em vez de nada, com um número dedicado que não o identifique, e o Molly em Android para proteger o próprio aparelho em caso de apreensão.

Para um dirigente ou um consultor jurídico. O critério dominante é a jurisdição, não o anonimato. Threema para um escritório ou uma estrutura pequena, com faturação clara e servidores suíços. Element autoalojado para uma organização que tenha equipa técnica e queira soberania sobre a sua infraestrutura, tendo presente que o administrador do servidor vê os metadados. Wire para uma organização que queira um produto comercial de colaboração, depois de examinada a sua estrutura acionista.

Para uma zona de corte da Internet ou de censura. Briar, porque o modo em malha por Bluetooth e Wi-Fi funciona sem infraestrutura alguma, e Zerion pelas mesmas razões com uma malha fora de linha mais recente. São as duas únicas respostas reais quando a própria rede é o adversário. Preveja o Briar Mailbox se a sua correspondência tiver de sobreviver a períodos prolongados fora de linha.

Para quem lida com cripto no dia a dia. É o único perfil em que a convergência de 2026 muda alguma coisa. Radar se o seu uso é o Bitcoin e a sua rede já está no Signal, aceitando a dependência da infraestrutura Signal e o número de telemóvel. Zerion se quiser Bitcoin e Monero com o máximo de resistência de rede, e os seus correspondentes estiverem em Android e frequentemente em linha. Arpokrat Messenger se quiser várias cadeias, a disponibilidade assíncrona e a possibilidade de comparar os fornecedores de swap consoante a sua exigência de KYC.

Para quem quer o máximo sem compromisso de utilização. Esta categoria não existe, e é a conclusão honesta deste comparativo. O máximo teórico é o Briar ou o Zerion, e paga-se em entregabilidade, em bateria e na ausência de iPhone. O compromisso mais favorável hoje, se os seus correspondentes estiverem em Android, é uma arquitetura sem identificador em modo store and forward, SimpleX Chat ou Arpokrat Messenger, com o Tor ativado. Se tiver de incluir utilizadores de iPhone, o SimpleX Chat é hoje o único desta família a cobrir as duas plataformas. O Arpokrat Messenger, disponível em Android, está em desenvolvimento para iOS e para as plataformas de computador, sem data de disponibilidade anunciada.

O que escolhemos na Arpokrat e porquê

Esta secção não é um argumentário, é uma explicação de compromissos, incluindo aqueles que não fizemos.

Partimos do SimpleX em vez de escrever um protocolo. A razão é simples: um protocolo de mensagens seguras só tem valor quando foi inspecionado, e um protocolo novo não tem, por definição, qualquer inspeção atrás de si. O SimpleX tem uma especificação pública, um código público e duas auditorias da Trail of Bits. Inventar a nossa criptografia ter-nos-ia permitido fazer uma melhor página de marketing e uma pior aplicação de mensagens.

Escolhemos o modelo store and forward em vez do ponto a ponto. É um compromisso explícito contra o máximo teórico. Um retransmissor cego que conserva uma mensagem encriptada até à sua recolha é mais uma peça de infraestrutura, logo mais uma superfície. Em troca, uma mensagem parte quando a escreve e chega quando o seu correspondente se liga, o que é a condição de uma correspondência normal. O critério do lado prático, defendido no início deste artigo, não é uma cláusula de estilo: aplicámo-lo a nós próprios.

Repartimos os retransmissores por cinco jurisdições fora dos Estados Unidos e excluímos os hiperescaladores norte-americanos, não por postura mas porque o CLOUD Act funciona obrigando um fornecedor norte-americano quanto aos dados que controla. Um retransmissor cego que nada conserva em disco tem pouco para entregar; um retransmissor cego que nenhuma injunção norte-americana pode alcançar tem ainda menos. As duas medidas somam-se, nenhuma substitui a outra.

Integrámos uma carteira e um agregador de swap porque a mesma pessoa que recusa que um intermediário conheça os seus interlocutores recusa geralmente que um intermediário conheça as suas transações. A classificação de A a D dos fornecedores de swap segundo a sua exigência de verificação de identidade vem da mesma lógica: não decidimos em lugar do utilizador o nível de confidencialidade que ele quer pagar, damos-lhe a informação para decidir.

O que ainda não fizemos merece, por fim, ser dito na mesma secção. Não temos auditoria independente publicada em nosso nome. Não temos histórico de requisições judiciais publicadas, apenas um warrant canary. Ainda não estamos em iOS. Estas três lacunas são reais, estão documentadas na nossa ficha atrás, e nenhuma se preenche com um comunicado.

Conclusão

A boa pergunta não é «qual é a melhor aplicação de mensagens». Não tem resposta, porque está mal colocada. A boa pergunta é: contra quem se protege?

Contra um anunciante que quer traçar o perfil dos seus interesses, praticamente todas as aplicações deste comparativo servem. Contra um companheiro violento que tem acesso ao seu telemóvel, a questão é o bloqueio local e o apagamento da memória, e o Molly responde melhor do que a Threema. Contra uma requisição judicial no seu país, a questão é a jurisdição e aquilo que o serviço detém. Contra um adversário que procura estabelecer que falou com alguém, a única resposta é uma arquitetura que não cria essa informação. E contra um adversário capaz de cortar a rede, a única resposta é não depender dela.

Nenhuma aplicação responde a todas estas ameaças ao mesmo tempo, e as que o afirmam merecem a sua desconfiança em primeiro lugar. O que 2026 demonstrou é que a encriptação se tornou a parte fácil. O que continua difícil são os metadados, a jurisdição, e a capacidade de um projeto de ainda existir daqui a dois anos. O Session esteve a algumas semanas de desaparecer, o Briar reduziu as suas ambições, e estes dois acontecimentos dizem mais sobre o estado real do setor do que qualquer comparação de primitivas criptográficas.

Escolha, portanto, em função do seu adversário, não em função de uma classificação. E tenha presente que a melhor ferramenta do mundo nada vale se a conversa acabar noutro sítio porque o seu interlocutor não a quis instalar.

Fontes

A Bomba-Relógio: Colete agora, descriptografe depois e o Imperativo Zero-Knowledge

Tue, 26 May 2026 00:00:00 +0000

A dependência dos governos europeus da infraestrutura em nuvem americana representa mais do que apenas um problema de interceptação imediata. A ameaça mais devastadora para as próximas décadas é a estratégia HNDL: “Harvest Now, Decrypt Later”.

Isso não é uma intrusão frontal, mas um roubo silencioso. Agências de inteligência interceptam e armazenam imensas quantidades de dados criptografados hoje, simplesmente porque o custo de armazenamento se tornou insignificante.

Eles esperam pacientemente pelo momento em que os saltos tecnológicos tornarão obsoletas as chaves criptográficas atuais. Um segredo de Estado protegido em 2026 pode se tornar um livro aberto em quinze anos.

Responsabilidade Retroativa e Risco Temporal

O modelo HNDL introduz um conceito novo: dano legal adiado. Com a coleta maciça de dados para descriptografia futura, a confidencialidade torna-se uma variável dependente do tempo.

O modelo científico HNDL define que a confidencialidade falha inevitavelmente quando a vida útil exigida do segredo excede o horizonte de descriptografia do adversário.

Se um Estado não garante a soberania absoluta de sua infraestrutura de hardware, está praticamente assinando uma renúncia de confidencialidade de longo prazo para seus cidadãos.

A interceptação de hoje é o comprometimento de amanhã. Transformar a dependência da nuvem em uma dívida de segurança nacional é uma aposta impossível de pagar.

A Antítese Arpokrat: Impossibilidade Legal por Código

A indústria responde criando ecossistemas radicais de soberania digital. O modelo Arpokrat opera em uma rede descentralizada, protegida pela rigorosa Lei Federal Suíça de Proteção de Dados (FADP).

A lógica central é o Privacy by Design absoluto. Ao remover a necessidade de um número de telefone, o usuário torna-se uma simples chave criptográfica.

Legalmente, se a arquitetura é fundamentalmente Zero-Knowledge, a empresa enfrenta uma impossibilidade técnica de cumprir mandados estrangeiros.

Trata-se de uma salvaguarda matemática e legal imparável: o que você não possui não pode ser divulgado.

Além da Criptografia: Desvalorizando os Dados Alvo

A verdadeira resposta no aplicativo Arpokrat não é apostar na matemática eterna, mas desvalorizar os próprios dados.

Sem metadados centrais para vincular uma mensagem a um indivíduo físico, o conteúdo criptografado perde seu valor estratégico porque se torna inatribuível.

No entanto, o software sozinho não pode fazer nada se o hardware o trair.

A segurança no século XXI exige a independência da própria máquina. A implantação de um SO soberano sem Google tornou-se um requisito absoluto de sobrevivência para quem lida com segredos de Estado.

A Ilusão da Soberania: O Caso Olvid e a Armadilha do CLOUD Act

Thu, 21 May 2026 00:00:00 +0000

O anúncio ressoou como um verdadeiro “grito de independência” nos corredores de Paris: a primeira-ministra ordenou que o governo abandonasse o WhatsApp e o Signal em favor do Olvid, um aplicativo de mensagens apresentado como “nativo”. O objetivo era claro: proteger segredos de Estado de agências de inteligência estrangeiras.

No entanto, surgiu rapidamente uma ironia amarga: o coração do Olvid — sua infraestrutura de servidores — bate dentro da Amazon Web Services (AWS), uma gigante americana.

Para o público em geral, isso parece uma simples questão técnica de hospedagem. Mas para os arquitetos da segurança cibernética soberana, é uma vulnerabilidade política de primeira ordem.

Extraterritorialidade e Conflito de Soberanias

Ao depender da infraestrutura da Amazon, o Olvid entra automaticamente na órbita do CLOUD Act dos EUA.

A análise jurídica deste caso revela um cenário de insegurança jurisdicional que a simples adoção de um “aplicativo” nacional não resolve. O ponto de inflexão reside no conceito de “controle” versus “localização”.

O CLOUD Act mudou radicalmente o paradigma jurídico ao estipular que a localização física do servidor não importa. A obrigação de cooperação do provedor (aqui, a AWS) decorre exclusivamente do seu vínculo jurisdicional com os EUA.

Legalmente, isso cria um conflito frontal com o RGPD. O Tribunal de Justiça da UE já estabeleceu que as leis de vigilância dos EUA não oferecem um nível de proteção equivalente ao da Europa.

A soberania digital não é um atributo do software, mas uma propriedade da integridade da cadeia de custódia.

O Espectro do FISA e a Falsa Promessa da Criptografia

Pior ainda, essa dependência da infraestrutura americana coloca esses dados sob a sombra do Foreign Intelligence Surveillance Act (FISA).

Diante dessas ameaças, o Olvid afirma que sua criptografia de ponta a ponta constitui um escudo suficiente. Da perspectiva da engenharia de privacidade, essa defesa é perigosamente parcial.

Mesmo que o conteúdo seja criptografado, a infraestrutura centralizada da AWS expõe os metadados. Saber quem fala com quem, quando, com que frequência e de onde costuma ser muito mais valioso para a inteligência do que a própria mensagem.

A criptografia protege o texto, mas o servidor centralizado trai a rede de contatos.

O Verdadeiro Perigo Ainda Está Por Vir

Enquanto a infraestrutura europeia depender de entidades sujeitas a estatutos extraterritoriais, a segurança das nossas comunicações continuará a ser ilusória.

A segurança nacional no século XXI exige total independência de infraestrutura e hardware. A estratégia “Colete agora, descriptografe depois” é a ameaça mais devastadora da próxima década.

Um segredo de Estado interceptado hoje não passa de uma bomba-relógio matemática.

(Leia o restante da nossa análise na Parte 2: A Bomba-Relógio e o Imperativo Zero-Knowledge)