Email Encriptado vs Transferência Encriptada de Ficheiros
Compare email encriptado com transferência encriptada de ficheiros e descubra o melhor método para enviar documentos sensíveis e ficheiros grandes em segurança.
O email encriptado (PGP, S/MIME, ou serviços como o ProtonMail) funciona bem para mensagens sensíveis curtas e documentos até cerca de 25 MB — o limite de anexos do Gmail que a maioria dos servidores ainda impõe. A transferência encriptada de ficheiros (HexaTransfer, SwissTransfer, Tresorit Send) lida com payloads até 10 GB ou mais, gera links de download de utilização única, e desassocia o ficheiro da política de retenção da sua caixa de entrada. Ao abrigo do Artigo 5(1)(e) do RGPD — o princípio da minimização de dados — os links que expiram têm vantagem sobre as caixas de email com retenção permanente. Muitas vezes vai querer ambos.
O limite de tamanho no email
O SMTP foi concebido em 1982 para telegramas ASCII de 7 bits. Os anexos viajam via codificação MIME base64, que infla os dados binários em cerca de 33%. Um vídeo de 20 MB torna-se um email de 27 MB. O Gmail rejeita mensagens com mais de 25 MB, o Outlook.com limita a 20 MB, e a maioria dos servidores Exchange empresariais define limites entre 10 MB e 35 MB.
Quando atinge esse limite, as opções tornam-se inconvenientes: dividir o .zip em partes com volumes 7-Zip, fazer upload para um serviço na nuvem e colar um link (anulando a encriptação), ou mudar de ferramenta. Os serviços de transferência de ficheiros ignoram tudo isto — o HexaTransfer move um .psd de 10 GB diretamente, o WeTransfer lida com 2 GB no nível gratuito, e ferramentas empresariais dedicadas como o Signiant podem mover terabytes.
Como a encriptação realmente difere
O PGP (RFC 4880) encripta os corpos de mensagens com uma chave de sessão AES-256 aleatória, depois encapsula essa chave com a chave pública RSA-4096 ou Curve25519 do destinatário. O S/MIME (RFC 8551) faz o mesmo usando certificados X.509 emitidos por uma CA. Ambos são ponta-a-ponto — o seu fornecedor de email armazena texto cifrado.
A transferência encriptada de ficheiros usa tipicamente um modelo diferente. O ficheiro encripta do lado do cliente com AES-256-GCM, o servidor armazena apenas texto cifrado, e a chave de desencriptação viaja num fragmento de URL (#key=...) que nunca chega ao servidor. Sem PKI, sem teia de confiança, sem servidores de chaves. A contrapartida: a encriptação de email autentica criptograficamente o remetente; os links de ficheiros autenticam apenas quem detém o URL.
Comparação rápida
| Funcionalidade | Email encriptado (PGP/S-MIME) | Transferência encriptada de ficheiros | |---|---|---| | Limite de tamanho típico | 25 MB | 2 GB – 10 GB+ | | Autenticação do remetente | Forte (assinado) | Fraca (baseada em link) | | Configuração de chave do destinatário | Necessária antecipadamente | Não necessária | | Persistência | Para sempre na caixa de entrada | 7 dias típico | | Metadados expostos | Linha de assunto, cabeçalhos | Nome do ficheiro opcional | | Funciona com destinatários não técnicos | Raramente | Sempre | | Adequação regulatória | HIPAA email (com BAA) | RGPD Art. 32, HIPAA |
Persistência: caixas de email vs links que expiram
Um email encriptado fica em ~/Mail/INBOX.mbox ou nos servidores do Gmail durante anos. Se o dispositivo do destinatário for comprometido posteriormente ou a sua chave privada PGP for exfiltrada, todas as mensagens históricas são desencriptadas. A retenção longa é ótima para trilhas de auditoria e terrível para o raio de impacto de uma violação.
Os links de transferência de ficheiros geralmente expiram. O HexaTransfer elimina as transferências após 7 dias. O SwissTransfer limita a 30 dias. O SendGB oferece 24 horas a 30 dias. Uma vez expirado o prazo, o texto cifrado é eliminado e a chave de desencriptação torna-se inútil — mesmo que o URL vaze anos depois, não há nada para desbloquear. Isto mapeia perfeitamente os princípios de minimização de dados do Artigo 5(1)(e) do RGPD e é por isso que os fluxos de trabalho jurídicos e de saúde preferem cada vez mais os serviços de transferência para divulgações pontuais.
Atrito com o destinatário
O problema de usabilidade do PGP é lendário. Um estudo da Carnegie Mellon de 2015 concluiu que 10 em 10 participantes não conseguiram enviar um email encriptado corretamente na primeira tentativa. Duas décadas depois de Phil Zimmermann lançar o PGP, o destinatário ainda precisa de gerar um par de chaves, publicá-lo algures, verificar impressões digitais, e configurar o Thunderbird ou o GPG Suite. O S/MIME é marginalmente melhor em ambientes empresariais que distribuem certificados automaticamente via Active Directory.
As transferências de ficheiros reduzem isto a: clique num link, talvez escreva uma palavra-passe. O destinatário não precisa de nenhuma configuração prévia. É por isso que as ferramentas de transferência encriptada de ficheiros ganham em cenários com clientes — um contabilista a enviar declarações de IRS a um cliente, um radiologista a reencaminhar estudos DICOM para um médico de referência, um advogado a entregar pacotes de .pdf de descoberta.
Onde se sobrepõem: documentos sensíveis pequenos
Um contrato assinado, um passaporte digitalizado, um resultado de análise médica de 2 MB — estes situam-se na zona ambígua. Ambos os métodos funcionam. O email ganha se precisar de um registo duradouro associado a um fio de conversa ("conforme discutimos terça-feira..."). A transferência de ficheiros ganha se precisar que o documento desapareça após a entrega, se o destinatário estiver fora do círculo PGP, ou se quiser um recibo de download confirmando que o ficheiro foi efetivamente obtido.
Algumas equipas adotam um fluxo de trabalho dividido: ProtonMail ou Tutanota para trocas baseadas em fio de conversa abaixo dos 25 MB, e um serviço de transferência dedicado para tudo o que seja maior ou que deva expirar. Ambos deixam o fornecedor apenas com texto cifrado, o que satisfaz claramente o Artigo 32 do RGPD e o PCI DSS 4.0 Requisito 4.2.1 para dados em trânsito.
Conformidade e linhas de retenção
Os regulamentos raramente impõem uma ferramenta específica — impõem resultados. O Artigo 32 do RGPD exige "medidas técnicas adequadas" para dados pessoais. O PCI DSS 4.0 bloqueia o PAN não encriptado em canais de mensagens. Qualquer solução E2EE, seja email ou transferência de ficheiros, pode satisfazer estes requisitos se configurada corretamente e apoiada por um Acordo de Processamento de Dados (DPA) assinado para efeitos do RGPD.
A diferença prática é a postura de retenção. Os sistemas de email são omissos quanto ao armazenamento indefinido; os sistemas de transferência de ficheiros são omissos quanto à eliminação. Para pedidos de apagamento ao abrigo do Artigo 17 do RGPD, o modelo de transferência de ficheiros é estritamente mais fácil — os dados já desapareceram quando o pedido chega.
Escolher a ferramenta certa para o trabalho
Use email encriptado para conversas em curso com contactos conhecidos, anexos pequenos, e comunicações juridicamente significativas em que uma trilha de auditoria assinada é importante. Use transferência encriptada de ficheiros para envios pontuais de grande dimensão, documentos sensíveis para destinatários não técnicos, ficheiros que devem autodestruir-se, e qualquer coisa que de outra forma seria rejeitada por um limite de 25 MB. Os dois são complementos, não concorrentes.
Para o lado da transferência de ficheiros desse fluxo de trabalho: experimente em hexatransfer.com — gratuito, sem conta, máximo de 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