Encriptação de ponta a ponta explicada: guia para principiantes

A encriptação de ponta a ponta (E2EE) significa que o seu ficheiro é cifrado no seu dispositivo com uma chave que só o destinatário consegue reconstruir. O serviço de transferência move texto cifrado mas nunca tem a chave de desencriptação, pelo que funcionários, atacantes e mandados judiciais não conseguem ler o conteúdo. Na prática, o seu navegador gera uma chave AES aleatória de 256 bits, encripta o ficheiro localmente, carrega o texto cifrado e coloca a chave na ligação de partilha após o fragmento # — que os navegadores nunca enviam ao servidor. Este é o mecanismo na íntegra, e é o que distingue a privacidade real do marketing.

O que "ponta a ponta" realmente significa

As duas "pontas" são você e o seu destinatário. Tudo no meio — routers do ISP, nodos CDN, os servidores da empresa de transferência, o ISP do destinatário — fica no meio. Com E2EE, esses saltos intermédios veem apenas bytes cifrados. Compare com a encriptação apenas de transporte (TLS): o TLS protege os dados do seu navegador até ao servidor, depois o servidor desencripta, guarda em texto simples e volta a encriptar quando o destinatário descarrega. O nível padrão do WeTransfer funciona assim. A empresa pode — e pela legislação da UE por vezes é obrigada — entregar ficheiros a pedido.

Com E2EE, mesmo que um juiz emita um mandado ao fornecedor, o fornecedor não tem nada a entregar além de bytes com aspeto aleatório. Esta propriedade é a razão pela qual jornalistas, advogados e médicos insistem cada vez mais nela.

Por que o TLS sozinho não chega

O TLS 1.3 é excelente no que faz: impedir que um atacante numa rede pública ou um ISP desonesto espreite a ligação. Mas o TLS termina no servidor. Quando o túnel encriptado acaba, o servidor processa o ficheiro em texto simples. Se esse servidor for comprometido — como aconteceu com o Dropbox em 2022, quando código-fonte e alguns dados de clientes foram expostos — o TLS não oferece proteção alguma para os ficheiros em armazenamento.

A E2EE acrescenta uma segunda camada que sobrevive ao comprometimento do servidor. O ficheiro é encriptado antes de sair do dispositivo e permanece encriptado até o navegador do destinatário o desencriptar. Mesmo um dump completo da base de dados revela apenas texto cifrado e metadados.

O problema da troca de chaves, resolvido

A parte difícil da E2EE é fazer a chave chegar ao destinatário sem que o servidor a veja. Os serviços modernos baseados em navegador resolvem isto com o truque do fragmento de URL. Uma ligação de partilha tem o seguinte aspeto:

https://hexatransfer.com/download/abc123#k=base64-encoded-256-bit-key

Os navegadores tratam tudo após o # como um fragmento do lado do cliente. Quando clica na ligação, o servidor recebe apenas /download/abc123 no pedido HTTP — o fragmento nunca sai do seu navegador. O JavaScript lê então a chave do fragmento, obtém o texto cifrado e desencripta-o localmente usando crypto.subtle.decrypt() da Web Crypto API.

Isto é mais simples do que a troca de chaves RSA ou Diffie-Hellman e funciona para qualquer pessoa com um navegador. O compromisso: quem tiver a ligação tem o ficheiro, pelo que ainda precisa de partilhar as ligações por um canal seguro (Signal, pessoalmente, um e-mail encriptado).

O que o servidor vê e o que não consegue ver

Com E2EE bem implementada, os registos do servidor contêm tipicamente: um ID de ficheiro aleatório, tamanho do texto cifrado, IP de carregamento, timestamp de carregamento e o hash SHA-256 do texto cifrado para deduplicação. O servidor não vê: o nome do ficheiro, o conteúdo, a identidade do destinatário, nem a chave de desencriptação. Os nomes de ficheiro são frequentemente encriptados juntamente com o conteúdo e armazenados como parte do cabeçalho do texto cifrado.

Um teste útil: pergunte ao fornecedor o que entregaria sob mandado. Um serviço E2EE honesto dirá "blobs encriptados e registos de IP". Se conseguir produzir ficheiros em texto simples, a encriptação não é de ponta a ponta.

Os algoritmos sob o capô

As implementações reais de E2EE convergem numa lista curta de primitivas bem auditadas:

• AES-256-GCM para encriptação de ficheiros em volume. O GCM proporciona confidencialidade e autenticação, pelo que o texto cifrado adulterado falha na desencriptação em vez de produzir lixo.
• PBKDF2 com pelo menos 100 000 iterações, ou Argon2id, para derivar chaves de palavras-passe de utilizador quando se adiciona proteção por palavra-passe.
• SHA-256 para hashes de integridade.
• TLS 1.3 como transporte exterior, porque a redundância tem pouco custo.

Evite serviços que ainda usam AES-CBC sem HMAC (maleável), MD5 ou SHA-1 (quebrados), ou PBKDF2 com menos de 10 000 iterações (passível de força bruta em GPUs modernas).

E2EE para transferência de ficheiros vs. mensagens

O Signal popularizou a E2EE para chat usando o protocolo Double Ratchet, que roda as chaves a cada mensagem para garantir forward secrecy. A transferência de ficheiros não precisa desta complexidade porque é uma operação única — não está a manter uma conversa contínua. Uma única chave simétrica por ficheiro, gerada de novo a cada carregamento, é mais simples e mais fácil de auditar.

O que a transferência de ficheiros precisa e a troca de mensagens não: carregamentos retomáveis em chunks (os ficheiros podem ter 10 GB), verificação de integridade entre chunks, e ligações que funcionem sem o destinatário ter uma conta. Tresorit, Proton Drive, SwissTransfer e HexaTransfer seguem todos esta abordagem com pequenas variações.

Como verificar se um serviço é realmente de ponta a ponta

Quatro testes práticos antes de confiar num fornecedor:

1. Abra o DevTools → Rede enquanto carrega um ficheiro pequeno. Se vir o texto simples no corpo do pedido, não está a ser encriptado no cliente.
2. Procure a chave no fragmento do URL (após o #). Sem chave no fragmento, geralmente o servidor tem a chave.
3. Leia a política de privacidade à procura de linguagem como "não conseguimos aceder aos seus ficheiros" acompanhada de uma descrição técnica do porquê.
4. Verifique se o código do cliente é auditável — código aberto ou pelo menos documentado. Os binários fechados com alegações de E2EE são um sinal de alerta.

Os serviços que passam nos quatro: SwissTransfer (nível de encriptação no cliente), Tresorit Send, ligações de partilha do Proton Drive e HexaTransfer.

Contra o que a E2EE não protege

A E2EE não é uma solução mágica. Não protege contra:

• Um endpoint comprometido. Se o seu portátil tiver malware, o atacante lê os ficheiros antes da encriptação.
• Ligações de partilha expostas. Quem tiver a ligação consegue descarregar e desencriptar.
• Palavras-passe fracas em transferências protegidas. O PBKDF2 atrasa os ataques de força bruta, mas "verao2024" cede em segundos.
• Correlação de metadados. Timestamps, tamanhos de ficheiro e endereços IP ainda contam uma história.

Combine a E2EE com ligações com prazo de validade (24 horas é um valor razoável), limites de descarregamento (tipicamente 1 a 10 descarregamentos) e palavras-passe fortes para transferências sensíveis.

Como verificar na prática

Para uma verificação rápida: carregue um ficheiro de teste de 5 MB, abra a ligação de partilha numa janela privada sem o fragmento (elimine tudo após o #) e tente descarregar. Um serviço E2EE genuíno falhará na desencriptação. Se o ficheiro abrir na mesma, o servidor tinha sempre a chave.

Experimente em hexatransfer.com — gratuito, sem conta, até 10 GB.