Como Funciona a Encriptação Ponto-a-Ponto em Transferências

A encriptação ponta-a-ponto para transferência de ficheiros significa que os bytes que saem do seu dispositivo estão encriptados com uma chave que nunca toca o servidor — e apenas o destinatário pretendido os pode desencriptar. O RGPD e a CNPD reconhecem explicitamente a encriptação como uma medida técnica adequada para proteger dados pessoais em trânsito; o Considerando 83 do RGPD cita a encriptação como controlo exemplar. O servidor armazena texto cifrado, não vê nada com significado, e poderia ser violado sem expor o conteúdo dos seus ficheiros. A receita criptográfica usa quase sempre uma cifra simétrica como AES-256-GCM ou XChaCha20-Poly1305 para o ficheiro em si, envolvida com uma troca de chaves como X25519 ECDH ou RSA-OAEP para o material da chave.

O Modelo de Ameaça que a E2EE Realmente Defende

A E2EE defende especificamente contra: o fornecedor de transferência ser hackeado, intimado ou malicioso; atacantes de rede a interceptar tráfego TLS desencriptado em proxies; snapshots de backup do bucket de armazenamento a cair nas mãos erradas; e acesso interno por funcionários do serviço. Não defende contra malware no dispositivo do remetente ou destinatário, phishing que capture a ligação de desencriptação, ou contas de destinatário comprometidas. Compreender o modelo importa porque "encriptado" é frequentemente mal usado para significar "TLS em trânsito mais AES em repouso no servidor" — o que deixa o fornecedor com as chaves.

Encriptação Simétrica para o Payload do Ficheiro

Os ficheiros são encriptados com um algoritmo simétrico porque a criptografia de chave pública é demasiado lenta para dados em massa. A escolha moderna é AES-256-GCM, definido no NIST SP 800-38D, proporcionando confidencialidade e integridade autenticada numa única passagem. Uma chave aleatória de 256 bits e um nonce único de 96 bits (nunca reutilizado com a mesma chave) protegem cada ficheiro. XChaCha20-Poly1305, definido nos RFC 8439 e RFC 8103, é uma alternativa frequentemente mais rápida em dispositivos sem aceleração hardware AES-NI, como processadores ARM mais antigos. Ambos produzem texto cifrado mais uma etiqueta de autenticação de 128 bits que detecta qualquer adulteração.

Derivação de Chaves a Partir de Palavras-Passe

Quando a E2EE usa uma palavra-passe, a palavra-passe em si nunca é a chave de encriptação — seria demasiado fraca contra força bruta. Em vez disso, uma função de derivação de chaves como PBKDF2-HMAC-SHA256 com 600.000 ou mais iterações (orientação OWASP 2025), Argon2id com m=19 MiB e t=2 (RFC 9106), ou scrypt (RFC 7914) estica a palavra-passe numa chave forte. Um sal aleatório de 128 ou 256 bits evita ataques de rainbow table. A chave resultante encripta o ficheiro. O sal e o número de iterações são guardados com o texto cifrado para que o destinatário possa reconstruir a chave ao introduzir a palavra-passe.

Envolvimento de Chave Pública para Transferências Baseadas em Conta

Quando os destinatários têm contas com chaves públicas publicadas, não é necessária a introdução de palavra-passe. O remetente gera uma chave de encriptação de ficheiro (FEK) aleatória, encripta o ficheiro com AES-256-GCM usando a FEK, depois encripta a FEK para a chave pública de cada destinatário usando acordo de chaves X25519 ECDH conforme o RFC 7748 combinado com HKDF-SHA256 conforme o RFC 5869, ou RSA-OAEP conforme PKCS#1 v2.2 com SHA-256. A FEK envolvida fica ao lado do texto cifrado. Apenas o detentor da chave privada do destinatário pode desenvovler a FEK e desencriptar o ficheiro.

E2EE Baseada em Ligação Usando Fragmentos de URL

Um truque inteligente na transferência baseada em browser é guardar a chave de desencriptação no fragmento de URL (a parte após #). Os fragmentos nunca são enviados ao servidor num pedido HTTP. Uma ligação como https://example.com/d/abc123#k=B9kZtR... transporta o ID do ficheiro do lado do servidor e a chave do lado do cliente. O browser descarrega o texto cifrado, lê o fragmento em JavaScript, e desencripta localmente. O serviço nunca vê a chave. O aviso é que se a ligação vazar — em registos, capturas de ecrã, pré-visualizações de aplicações de mensagens — a chave vaza com ela.

Integridade com AEAD e Hashes

Os modos de Encriptação Autenticada com Dados Associados (AEAD) como GCM e ChaCha20-Poly1305 impedem adulteração. Um único flip de bit no texto cifrado faz a etiqueta de autenticação falhar a validação, e a função de desencriptação devolve um erro em vez de texto simples incorreto. Para além de AEAD, muitas implementações calculam um hash SHA-256 ou BLAKE3 do texto simples como entrada de manifesto para que o destinatário possa verificar após desencriptação que o ficheiro corresponde ao que o remetente pretendeu. Isto importa para ficheiros grandes transferidos em chunks, onde uma entrega parcial poderia de outra forma ter sucesso em partes e falhar silenciosamente num fragmento em falta.

Encriptação em Chunks para Ficheiros Grandes

Encriptar um ficheiro de 10 GB numa única operação AES-GCM requer manter 10 GB de estado, o que é impraticável em browsers. As implementações reais dividem o ficheiro em chunks — tipicamente 1 MB a 16 MB cada — e encriptam cada chunk independentemente com uma sub-chave derivada e um nonce baseado em contador. A ferramenta de encriptação age, definida em age-encryption.org, usa chunks de 64 KB com ChaCha20-Poly1305. Os limites de chunk também permitem aos browsers transmitir desencriptação via a Streams API, começando o descarregamento para disco antes de o ficheiro completo chegar, e suportam uploads retomáveis quando ocorrem interrupções de rede.

Segurança de Transporte por Cima da E2EE

O TLS 1.3 definido no RFC 8446 ainda importa por cima da E2EE — não para confidencialidade do payload (o payload já está encriptado) mas para privacidade de metadados: nomes de ficheiros, tamanhos e temporização. O TLS 1.3 com troca de chaves forward-secret como X25519 significa que mesmo que a chave de longa duração do servidor seja comprometida mais tarde, as sessões gravadas não podem ser desencriptadas. O pinning de certificado ou a pré-carga HSTS evitam ataques de downgrade. Em conjunto, E2EE mais TLS 1.3 protege tanto o conteúdo dos ficheiros como o padrão operacional de quem está a enviar o quê a quem.

Armadilhas Comuns de Implementação

Três erros repetem-se. Primeiro, reutilizar nonces com a mesma chave em AES-GCM quebra catastroficamente a confidencialidade — use sempre um nonce fresco aleatório ou um contador que nunca se repete. Segundo, implementar criptografia com rotinas caseiras em vez de bibliotecas auditadas como libsodium, Web Crypto API (SubtleCrypto) ou BoringSSL — as operações em tempo constante importam para prevenir ataques de temporização. Terceiro, não autenticar metadados de ficheiros juntamente com o conteúdo — se a identidade do remetente, o nome do ficheiro ou a lista de destinatários não estiver no AAD (Dados Associados Autenticados), um atacante pode trocar metadados sem ser detectado. O HexaTransfer aborda estes problemas usando primitivos Web Crypto padrão do lado do cliente com padrões revistos.

Verificar se um Serviço Realmente Faz E2EE

Leia as afirmações de marketing com cepticismo. A verdadeira E2EE significa que o fornecedor não consegue desencriptar ficheiros mesmo se obrigado por uma ordem judicial. Procure documentação técnica publicada descrevendo os algoritmos exactos (AES-256-GCM, X25519, HKDF, contagens de iteração PBKDF2), código cliente de fonte aberta que possa ser auditado, e um modelo de ameaça que reconhece o que a E2EE defende e não defende. Os serviços que oferecem recuperação de palavra-passe do lado do servidor em ficheiros encriptados não estão a fazer verdadeira E2EE — eles detêm as chaves. Os serviços que afirmam "conhecimento zero" devem suportá-lo com uma descrição de protocolo criptográfico, não apenas um slogan.

Experimente em https://hexatransfer.com — gratuito, sem conta, máximo de 10 GB.