Métodos de Encriptação de Transferência Comparados
Comparação técnica dos métodos de encriptação em transferências de ficheiros incluindo AES-256, RSA, ChaCha20 e encriptação ponto-a-ponto vs servidor.
Os serviços de transferência de ficheiros usam cinco abordagens principais de encriptação em 2026: apenas TLS (dados encriptados em trânsito mas em texto simples no servidor), AES-256 em repouso do lado do servidor (o fornecedor guarda as chaves), AES-256-GCM do lado do cliente via Web Crypto API (ponto-a-ponto, chave no fragmento do URL), encriptação de fluxo XChaCha20-Poly1305 (nonce estendido, usado pela libsodium e Tresorit) e encriptação híbrida OpenPGP (ECC Curve25519 + chaves de sessão AES-256, usado pelo Proton). A escolha certa depende do modelo de ameaça, constrangimentos de desempenho e requisitos regulatórios. Esta comparação explica o que cada uma faz e onde cada uma falha.
Os Cinco Modelos de Encriptação
Modelo um: apenas TLS 1.3. O ficheiro encripta durante o trânsito de rede e depois fica no servidor em texto simples. Exemplos: FTP básico sobre TLS (FTPS), qualquer upload HTTP POST sem encriptação em repouso. Protege contra escuta passiva de rede, não protege contra mais nada.
Modelo dois: TLS + em repouso do lado do servidor. O AES-256 encripta o ficheiro guardado; o fornecedor guarda a chave mestra (frequentemente em AWS KMS, GCP Cloud KMS, ou equivalente). Exemplos: WeTransfer, SwissTransfer, Dropbox. Protege contra roubo de armazenamento a frio, não protege contra acesso interno, citação judicial ou compromisso de servidor em funcionamento.
Modelo três: E2EE do lado do cliente com chave simétrica. O browser ou cliente deriva uma chave de 256 bits, encripta com AES-256-GCM e coloca a chave num fragmento de URL ou canal fora de banda. Exemplos: HexaTransfer, descendentes do protocolo Firefox Send. O servidor vê apenas texto cifrado e não consegue desencriptar em nenhuma circunstância.
Modelo quatro: Cifras de fluxo autenticadas. O XChaCha20-Poly1305 usa nonces de 24 bytes (vs 12 bytes no ChaCha20-Poly1305), tornando as colisões de limite de aniversário inviáveis em ficheiros muito grandes. Exemplos: libsodium secretbox (Internxt), Tresorit Send. Escolhido quando a aceleração de hardware AES-NI não é universal (dispositivos Android mais antigos, IoT) porque o ChaCha20 corre rápido em software.
Modelo cinco: Chave pública híbrida + simétrica. O OpenPGP (RFC 9580, revisão de 2024) usa ECC Curve25519 ou RSA-4096 para encriptar uma chave de sessão AES-256 por ficheiro. Exemplos: Proton Drive, encriptação de ficheiros GPG tradicional. Permite gestão assimétrica de chaves; não é necessário segredo partilhado entre remetente e destinatário se tiver a chave pública do destinatário.
AES-256 vs ChaCha20: O Que Difere Realmente
Ambas são cifras simétricas de 256 bits. O AES-256 é o padrão NIST (FIPS 197) e tem aceleração de hardware (AES-NI em x86, ARM Cryptography Extensions em dispositivos móveis). Em hardware moderno, o AES-256-GCM corre a 2-4 GB/s por núcleo. O ChaCha20-Poly1305 corre a 1-2 GB/s por núcleo em software puro, mais rápido que o AES em hardware sem AES-NI. Para um computador de secretária a encriptar um ficheiro de 4 GB, ambos terminam em menos de dois segundos; a rede é o bottleneck. Criptograficamente, ambos são considerados igualmente seguros em 2026.
O RSA Está Maioritariamente Morto na Transferência de Ficheiros
O RSA-4096 encripta 512 bytes de texto simples por operação. Usar RSA diretamente para encriptar um ficheiro de 1 GB é absurdo; teria de fragmentar em milhões de blocos de 512 bytes. O padrão é sempre híbrido: o RSA envolve uma chave de sessão AES-256 por ficheiro, e o AES encripta o conteúdo. O ECC Curve25519 substituiu o RSA na maioria dos designs novos porque é mais rápido, tem chaves menores (ECC de 256 bits equivale a segurança RSA de 3072 bits) e é resistente a ataques de temporização. O OpenPGP em 2024 recomenda agora Curve25519 (X25519 para troca de chaves) em vez de RSA. Ainda verá RSA em implementações SFTP legadas.
Porque as Chaves no Fragmento do URL Importam
O HexaTransfer e a linhagem do protocolo Firefox Send colocam a chave de encriptação no fragmento do URL (a parte após #). Os browsers estão especificados (RFC 3986) para nunca transmitir fragmentos no pedido HTTP. Isso significa que o servidor recebe um pedido como GET /file/abc123 mas nunca vê o fragmento que contém a chave. Quando o utilizador cola ou clica no URL completo, o fragmento permanece na memória do browser e alimenta a desencriptação do lado do cliente. Esta é a forma arquiteturalmente elegante de entregar um link E2EE partilhável sem um canal secundário.
Ponto-a-Ponto vs Lado do Servidor: O Teste do Modelo de Ameaça
A encriptação do lado do servidor protege contra uma coisa: o roubo físico do dispositivo de armazenamento. Se o disco for roubado, a encriptação AES-256 em repouso mantém os dados opacos até alguém comprometer o KMS. A encriptação ponto-a-ponto protege contra tudo o que o servidor poderia fazer: citação judicial, acesso interno, ransomware que atinge dados em funcionamento ou coerção ao nível estatal. Se o seu modelo de ameaça é "disco roubado de um centro de dados", o lado do servidor está bem. Se é "governo, adversário ou concorrente obriga o serviço a entregar os dados", apenas o E2EE o protege.
A Encriptação Autenticada Não é Opcional
O AES-CBC simples sem um MAC permite ataques de oracle de preenchimento (BEAST, Lucky13) que conseguem desencriptar texto cifrado com consultas de texto cifrado escolhido. A transferência moderna de ficheiros deve usar AEAD: AES-256-GCM (NIST SP 800-38D) ou ChaCha20-Poly1305 (RFC 8439). A tag Poly1305 ou a tag GCM autentica o texto cifrado e quaisquer dados associados (tamanho do ficheiro, nonce, cabeçalho do nome de ficheiro). Se um bit mudar em trânsito, a desencriptação falha de forma ruidosa. Qualquer serviço que ainda use AES-CBC em 2026 sem um wrapper HMAC está a viver em 2010.
Derivação de Chaves para Transferências Protegidas por Palavra-passe
Quando um utilizador escreve uma palavra-passe para proteger uma transferência, não pode usar a palavra-passe diretamente como chave AES. É de baixa entropia e vulnerável a ataques de força bruta. Derivação moderna de chaves: PBKDF2-SHA-256 com 600 000 iterações (recomendação OWASP 2023), scrypt com N=2^17, ou Argon2id com 19 MiB de memória e 2 iterações. O HexaTransfer usa PBKDF2 com 600 000 iterações. O Tresorit usa Argon2id. Ambos resistem ao cracking de palavras-passe acelerado por GPU. Os fornecedores que ainda usam PBKDF2 com 10 000 iterações (orientação de 2015) estão sub-protegidos.
Tabela de Comparação
| Método | Confidencialidade | Autenticação | Servidor Vê Texto Simples | Preocupação Quântica | |---|---|---|---|---| | Apenas TLS 1.3 | Em trânsito | Sim (MAC na suite de cifra) | Sim | Troca de chaves em risco | | AES-256 lado servidor | Em repouso + em trânsito | Sim | Sim (tem a chave) | Baixa | | AES-256-GCM lado cliente | Caminho completo | Sim (tag GCM) | Não | Baixa | | XChaCha20-Poly1305 | Caminho completo | Sim (tag Poly1305) | Não | Baixa | | OpenPGP (Curve25519 + AES-256) | Caminho completo | Sim (MDC/OCB) | Não | Curve25519 em risco |
Considerações Pós-Quânticas
O algoritmo de Shor ameaça o Curve25519 e o RSA assim que existirem computadores quânticos grandes. As cifras simétricas (AES-256, ChaCha20) são enfraquecidas mas não quebradas pelo algoritmo de Grover; as chaves de 256 bits mantêm força pós-quântica de 128 bits, ainda inviável. O NIST normalizou o ML-KEM (Kyber) em 2024 para encapsulamento de chaves pós-quântico. O Signal migrou para PQXDH em 2023. Os serviços de transferência de ficheiros ainda não adoptaram amplamente o pós-quântico, mas a janela de risco ("colher agora, desencriptar depois") significa que os arquivos de longa retenção devem usar encriptação simétrica de 256 bits hoje.
Escolher um Método
Transferência sensível pontual, retenção curta: AES-256-GCM do lado do cliente com chaves no fragmento do URL. O HexaTransfer é a implementação. Fluxos de trabalho contínuos regulados por conformidade: XChaCha20-Poly1305 com registos de auditoria (Tresorit). Multi-destinatário com gestão de chaves: OpenPGP (Proton Drive, GPG). Grande distribuição descentralizada: libsodium secretbox mais erasure coding (Internxt no Storj). Não sensível de grande volume: TLS + em repouso é aceitável.
Experimente em hexatransfer.com — gratuito, sem conta, até 10 GB.
Envie arquivos grandes com segurança e criptografia de ponta a ponta
Transfira arquivos de até 10 GB gratuitamente com criptografia de ponta a ponta. Sem necessidade de conta. Seus arquivos são criptografados no navegador antes do envio — ninguém mais pode lê-los.
Enviar um arquivo