Criptografia de ponta a ponta, explicada de verdade Cuadernos Lacre · Conceito · 18 de maio de 2026 https://solo2.net/pt/cadernos/articulos/end-to-end-encryption-actually-explained.html O que os fornecedores dizem quando dizem E2EE, e o que não dizem. Uma explicação didática do mecanismo e dos seus limites, sem o invólucro publicitário. --- Para sermos claros: O WhatsApp diz que as tuas mensagens são criptografadas de ponta a ponta. É verdade — e não é suficiente. Se o backup for para o iCloud ou Google Drive sem criptografia adicional, a criptografia é quebrada no teu próprio telemóvel. A questão operacional não é se está criptografado, mas onde residem as chaves. --- O que criptografar significa, de verdade Criptografar uma mensagem significa transformá-la em algo que parece ruído para qualquer pessoa que não possua uma determinada informação chamada chave. A operação é feita no dispositivo de quem envia e, com a chave correta, é desfeita no dispositivo de quem recebe. No meio, a mensagem viaja como uma sucessão de bytes sem significado aparente. Essa é a ideia simples. O resto do artigo trata das nuances que a convertem, dependendo do caso, numa garantia real ou numa etiqueta de mercado. O adjetivo de ponta a ponta — em inglês end-to-end, abreviado E2EE — acrescenta uma precisão. A criptografia não é feita para que um servidor intermediário possa lê-la e entregá-la. É feita para que apenas as duas extremidades — o dispositivo de quem envia e o dispositivo de quem recebe — possuam a chave. Qualquer servidor pelo qual a mensagem passe vê o ruído, não a mensagem. Essa é a diferença técnica com a criptografia em trânsito, onde o conteúdo viaja criptografado de um servidor para o outro, mas cada servidor pelo qual passa o decifra para o reenviar, recuperando temporariamente o texto em claro. O paradoxo do segredo compartilhado Há um problema óbvio. Para que duas pessoas possam criptografar e decriptografar mensagens entre si, ambas precisam da mesma chave. Mas, como entram em acordo sobre essa chave se tudo o que enviam uma à outra, por definição, passa por um canal onde alguém poderia estar a ouvir? Acordar a chave no mesmo canal onde depois a usarão parece impossível: se o atacante a ouvir ao acordá-la, poderá decifrar tudo o que vier a seguir. Durante décadas, a criptografia clássica resolveu isso pela via dura: as chaves eram entregues em pessoa, antes de começarem a ser usadas, em encontros físicos. Os embaixadores carregavam maletas de chaves cosidas ao forro do sobretudo. No correio eletrónico contemporâneo, essa solução não escala. Se tivéssemos de ir fisicamente a casa de cada pessoa com quem pretendêssemos comunicar de forma criptografada, não chegaríamos a falar com ninguém. A pergunta colocada há cinquenta anos pela comunidade criptográfica foi esta: será possível que duas pessoas que não se conhecem e que apenas partilham um canal público acordem, nesse mesmo canal público, um segredo que ninguém que ouça o canal possa conhecer? A elegância de Diffie-Hellman Em 1976, dois matemáticos chamados Whitfield Diffie e Martin Hellman demonstraram algo aparentemente impossível: que duas pessoas, falando apenas por um canal público — um canal onde qualquer pessoa pode ouvir tudo o que dizem —, podem pôr-se de acordo numa palavra-passe secreta sem que nenhum ouvinte a possa descobrir. Soa a magia. Não é: é matemática. A troca de chaves Diffie-Hellman, como é conhecida desde então, é a base de praticamente toda a comunicação criptografada da internet, e meio século de uso intensivo e escrutínio académico mundial atestam a sua solidez. Quem quiser ver a intuição visual ou a matemática pode continuar a ler. Quem preferir confiar que funciona também pode continuar sem perder o fio do artigo. Para quem quiser intuir isso numa imagem, há uma analogia conhecida com cores. Imagine que a Alice e o Bruno acordam abertamente uma cor base — digamos amarelo — à vista da Eva, que os ouve. Cada um escolhe em privado uma segunda cor secreta e mistura o seu segredo com o amarelo. A Alice obtém um laranja particular; o Bruno obtém um verde particular. Trocam os resultados à vista da Eva. Agora cada um mistura a cor recebida com o seu próprio segredo, e ambos chegam à mesma cor final, porque a ordem das misturas não importa. A Eva viu o amarelo e as duas misturas intermédias, mas não os segredos; sem algum dos segredos não pode chegar à cor final. A matemática real troca as cores por exponenciações em grupos modulares ou curvas elípticas, mas a ideia é a mesma: o segredo compartilhado é construído em público sem que ninguém no canal o possa reconstruir. De Diffie-Hellman ao protocolo Signal A criptografia de ponta a ponta que as aplicações de mensagens profissionais usam hoje descansa, quase sem exceção, sobre uma versão elegante e endurecida da troca Diffie-Hellman. O protocolo Signal, desenhado por Trevor Perrin e Moxie Marlinspike entre 2013 e 2016, é a referência. Combina duas ideias-chave. A primeira, a troca de chaves em curvas elípticas (X25519), que produz o segredo compartilhado inicial entre dois dispositivos. A segunda, o chamado Double Ratchet — engrenagem dupla —, que renova as chaves automaticamente com cada mensagem, de modo que comprometer o dispositivo hoje não permite decifrar mensagens passadas, nem mensagens futuras uma vez que a engrenagem tenha rodado. O que a criptografia de ponta a ponta protege O que o E2EE protege bem, assumindo uma implementação correta, é o conteúdo da mensagem em trânsito. Um servidor intermediário que receba e reenvie os dados criptografados verá uma sucessão de bytes ininteligíveis. Um atacante com acesso ao cabo, ao router, ao ponto de acesso wifi, verá o mesmo. Um fornecedor do serviço que conserve cópias do tráfego não poderá lê-lo a posteriori. Um Governo que ordene ao operador do serviço a entrega do conteúdo receberá os mesmos bytes ininteligíveis que o servidor tinha em primeiro lugar. Isto, em termos práticos, é muito. É a diferença entre escrever uma carta dentro de um envelope opaco e escrevê-la num postal. As duas chegam. Apenas uma preserva o conteúdo perante o carteiro. O que a criptografia de ponta a ponta não protege Convém sabê-lo tão bem quanto. O E2EE não protege os metadados: o servidor continua a saber que o utilizador A envia dados ao utilizador B, a que horas, com que frequência e de onde, embora não saiba o que diz. Estes metadados, como já argumentámos em Criptografar não é ser privado, são muitas vezes mais reveladores do que o conteúdo. Saber que alguém ligou para um escritório de advogados especializado em divórcios numa sexta-feira às 22:00 durante trinta minutos conta uma história que o conteúdo da chamada nunca contou. É a mesma situação que ver uma pessoa entrar e sair várias vezes de uma clínica oncológica: não é preciso ouvir nada do que se fala lá dentro para imaginar o que está a acontecer. Um único metadado solto pode não significar nada; vários cruzados entre si desenham algo demasiado parecido com a verdade. O E2EE não protege as extremidades: se o dispositivo do recetor estiver comprometido por um programa malicioso, a mensagem é decifrada normalmente para esse recetor e o programa malicioso lê-a. O E2EE não protege contra a identidade do interlocutor em si: se a Alice acredita estar a falar com o Bruno mas um atacante se interpôs no início (um man in the middle) e o protocolo não inclui verificação independente, as duas partes acabam a falar com o intruso pensando que falam entre si. Há uma quarta coisa que convém formular sem ambiguidade. O E2EE não impede que um fornecedor que afirma oferecê-lo guarde, além disso, uma cópia da mensagem sem criptografar nos seus próprios sistemas. A afirmação «as minhas mensagens estão criptografadas de ponta a ponta» e a afirmação «o fornecedor não conserva o meu conteúdo» não são a mesma. Uma aplicação pode cumprir a primeira enquanto incumpre a segunda; vimo-lo em manchetes de imprensa repetidamente desde 2018. O utilizador, a menos que o código do cliente seja verificável, não tem forma técnica de distinguir um caso do outro sem investigação pericial. O caso mais conhecido no público em geral: o WhatsApp criptografa as mensagens de ponta a ponta em trânsito, mas se o utilizador ativar a cópia de segurança em iCloud ou Google Drive sem criptografia adicional, essa cópia é armazenada legível em infraestrutura de um terceiro, e a criptografia quebra-se na extremidade do próprio utilizador. A pergunta que o operador não quer ouvir Uma aplicação que afirma criptografar de ponta a ponta pode, tecnicamente, fazer uma de três coisas em relação às chaves: A pergunta operacional, portanto, não é se algo está criptografado, mas quem tem o controlo do dispositivo e do software que gere as chaves. No Solo2, as chaves residem unicamente na tua Bóveda (IndexedDB criptografada com a tua palavra-passe) e o software é código aberto verificável. Para o leitor profissional A criptografia de ponta a ponta é uma ferramenta de soberania digital. Mas, como toda a ferramenta, a sua eficácia depende da mão que a empunha e do solo em que se apoia. 1. Onde são geradas as chaves criptográficas e onde residem fisicamente? Se o operador puder aceder a elas (mesmo temporariamente, mesmo sob o pretexto de recuperação), o E2EE é apenas nominal. 2. Existe verificação independente do interlocutor (números de segurança, códigos QR, comparação out-of-band) que previna um ataque man-in-the-middle durante o estabelecimento da conversa? 3. O código do cliente é auditável — aberto, publicado, reprodutível — ou exige confiar na palavra do fornecedor sobre o que o cliente realmente faz? 4. Quais metadados o serviço gera e mantém, e por quanto tempo? Mesmo que o conteúdo seja opaco, os metadados podem reconstruir boa parte da informação sensível. Estas quatro perguntas não pedem informações técnicas avançadas; pedem informações às quais qualquer operador honesto pode responder na sua documentação pública. A qualidade e precisão da resposta diz tanto sobre o produto quanto a própria resposta. --- A criptografia de ponta a ponta, bem feita, é uma das construções mais finas que a criptografia contemporânea entregou à prática quotidiana. A ideia original — duas pessoas podem acordar um segredo num canal público — pertence a Whitfield Diffie e Martin Hellman, 1976; meio século depois continuamos a viver na sua consequência. Mas, como acontece com qualquer promessa técnica, o seu valor depende do cumprimento real, não da etiqueta. A pergunta do profissional honesto não é «está criptografado?», mas «quem tem as chaves?». As respostas têm consequências distintas. Convém sabê-las. Fontes e leitura adicional - Diffie, W.; Hellman, M. — New Directions in Cryptography, IEEE Transactions on Information Theory, novembro de 1976. Artigo fundamental da criptografia de chave pública. - Perrin, T.; Marlinspike, M. — The Double Ratchet Algorithm, especificação pública da Open Whisper Systems, revisão de 2016. Base do protocolo Signal e dos seus derivados industriais. - RFC 7748 — Elliptic Curves for Security (IETF, janeiro de 2016). Especificação normativa das curvas X25519 e X448 usadas nas trocas de chaves modernas. - Ferguson, N.; Schneier, B.; Kohno, T. — Cryptography Engineering: Design Principles and Practical Applications (Wiley, 2010). Capítulos sobre troca de chaves e protocolos de criptografia autenticados. - Regulamento (UE) 2024/1183 relativo a um quadro europeu para a identidade digital (eIDAS 2) — estabelece quadros onde a verificação independente do interlocutor ganha apoio institucional, e onde a distinção entre criptografia nominal e real tem consequências legais diferentes. --- Cuadernos Lacre · Uma publicação da Menzuri Gestión S.L. · escrita por R.Eugenio · editada pela equipa do Solo2. https://solo2.net/pt/cadernos/