Índice
- Os três sentidos de «e-mail cifrado»
- Cifragem de transporte: necessária, não suficiente
- Ponta a ponta: PGP vs S/MIME
- Cifragem de acesso zero do fornecedor
- O problema dos metadados que todos saltam
- Onde se situam de verdade os grandes fornecedores
- Um quadro de decisão
Os três sentidos de «e-mail cifrado»
«E-mail cifrado» é uma das expressões mais gastas do mercado da privacidade, porque quase todos os fornecedores a podem afirmar com honestidade significando coisas completamente diferentes. Há três camadas de cifragem distintas no e-mail, e defendem contra três adversários diferentes:
- Cifragem de transporte (TLS / STARTTLS) — a ligação entre dois servidores de correio está cifrada. Isto trava um bisbilhoteiro passivo no cabo. Hoje é quase universal e é o mínimo indispensável, não uma funcionalidade.
- Cifragem de ponta a ponta (PGP ou S/MIME) — o corpo da mensagem é cifrado no dispositivo do remetente com a chave pública do destinatário, de modo que só a chave privada do destinatário a possa abrir. Nenhum servidor do caminho a pode ler.
- Cifragem de acesso zero do fornecedor — o fornecedor armazena a tua caixa cifrada com chaves derivadas da tua palavra-passe, de modo que nem ele possa ler as mensagens presentes na tua conta.
Quando um fornecedor de consumo diz «o teu e-mail está cifrado», refere-se quase sempre à camada 1, por vezes à camada 1 mais a cifragem de disco em repouso. Quando um engenheiro atento à privacidade pede e-mail cifrado, refere-se quase sempre à camada 2 ou 3. Essa lacuna é todo o tema deste guia.
Cifragem de transporte: necessária, não suficiente
O TLS — normalmente negociado sobre SMTP com STARTTLS — cifra o salto entre dois servidores de correio. O seu valor é real: impede quem vigia a rede de ler o teu correio em voo, e a infraestrutura moderna usa-o quase por toda a parte.
Mas o TLS é salto a salto, não de ponta a ponta. Uma mensagem atravessa tipicamente vários servidores entre remetente e destinatário, e em cada salto é decifrada, processada e voltada a cifrar para a etapa seguinte. Isso significa que cada servidor da cadeia — o teu fornecedor, o do destinatário e qualquer relé intermédio — trata a mensagem em claro. A cifragem de transporte protege a mensagem dos estranhos no cabo; nada faz para a proteger dos próprios fornecedores.
Há um segundo truque: o STARTTLS é oportunista por predefinição. Se o servidor recetor não anunciar TLS, muitos remetentes recorrem silenciosamente à entrega em claro em vez de falhar. Por isso «usamos TLS» nem sequer garante que uma dada mensagem foi cifrada em todo o caminho. É por isto que a cifragem de transporte, por mais essencial que seja, é o chão e não o teto.
Ponta a ponta: PGP vs S/MIME
A cifragem de ponta a ponta (E2EE) move a cifragem para os extremos. O remetente cifra a mensagem com a chave pública do destinatário; só a chave privada do destinatário a pode decifrar. Como os servidores intermédios nunca detêm a chave privada, nenhum pode ler o corpo — nem o teu fornecedor, nem um relé, nem o fornecedor do destinatário. É o mesmo modelo de chave pública que sustenta os gestores de palavras-passe por CLI e a gestão de chaves que abordamos para programadores; a diferença está em quem gere a distribuição de chaves.
Dominam dois padrões, e a sua diferença resume-se inteiramente a confiança e distribuição de chaves:
PGP (OpenPGP). Uma «rede de confiança» descentralizada. Os utilizadores geram os seus próprios pares de chaves e trocam diretamente as chaves públicas, verificando-as fora de banda (uma impressão digital por telefone, uma chave assinada por um contacto comum). É de máxima flexibilidade e não exige autoridade central, mas a distribuição de chaves é manual, daí a fama de atrito do PGP. É o padrão entre particulares, jornalistas e comunidades de código aberto.
S/MIME. As chaves públicas são ligadas a identidades através de certificados emitidos por uma autoridade de certificação (AC) central. Isto simplifica muito a implementação numa organização gerida — a TI fornece os certificados de forma centralizada — mas prende a tua confiança a essa hierarquia de AC. O S/MIME é a escolha habitual em empresas e administrações, onde já existe uma PKI gerida.
Ambos oferecem a mesma garantia central: uma mensagem que nenhum servidor intermédio pode ler, mais uma assinatura digital que prova o remetente e a ausência de alteração. O custo, em ambos os casos, é que o destinatário também tem de participar. Não podes enviar de forma transparente uma mensagem E2EE a quem não tem chave.
Cifragem de acesso zero do fornecedor
Há um terceiro modelo que contorna a dor da distribuição de chaves para o caso comum de uma caixa privada: a cifragem de acesso zero no fornecedor.
Aqui o fornecedor cifra a tua caixa armazenada com chaves derivadas da tua palavra-passe, no teu dispositivo, de modo que o servidor só guarda texto cifrado da tua conta. Nem o fornecedor pode ler o correio em repouso. O Proton Mail é a implementação mais conhecida: as mensagens entre utilizadores Proton são cifradas de ponta a ponta por predefinição, e toda a caixa é mantida sob cifragem de acesso zero, de modo que o próprio Proton não a pode ler.
O limite honesto está na natureza do e-mail. Quando um utilizador Proton escreve a um utilizador Gmail, a mensagem não pode ser cifrada de ponta a ponta a menos que o utilizador Gmail também tenha PGP, porque o outro extremo não tem chave. O Proton resolve isto deixando-te enviar uma mensagem protegida por palavra-passe a um não utilizador: o destinatário abre-a através de um link e de uma palavra-passe que partilhas à parte. É uma ponte real, mas a palavra-passe tem de ser partilhada por outro canal — a mesma restrição de fundo do PGP, embalada de forma mais cómoda.
A cifragem de acesso zero atrai porque te dá uma caixa legível, pesquisável no dispositivo, sem configuração, que o fornecedor mesmo assim não pode ler — sem obrigar cada correspondente a gerir chaves.
O problema dos metadados que todos saltam
Este é o ponto mais importante e mais ignorado de qualquer discussão honesta sobre e-mail cifrado: a cifragem protege o conteúdo, não os metadados.
Mesmo com uma cifragem de ponta a ponta impecável, o seguinte geralmente viaja em claro e pode ser registado pelo teu fornecedor, pelo do destinatário e pela rede:
- quem enviou a mensagem e quem a recebeu,
- a marca temporal,
- o tamanho da mensagem,
- e, em muitas implementações, a linha de assunto.
Assim, a cifragem responde a «o que dizia a mensagem», mas não a «quem fala com quem, quando e com que frequência». Para um modelo de ameaça em que esconder os teus contactos importa — não só as tuas palavras — a cifragem do conteúdo por si só é insuficiente. Os fornecedores que minimizam a retenção de metadados, e as ferramentas ao nível da rede, abordam outra parte do problema. Trata o limite dos metadados como um facto de design do e-mail, não como um defeito de um fornecedor concreto, e planeia em conformidade.
Onde se situam de verdade os grandes fornecedores
| Fornecedor | Em trânsito | Em repouso | Ponta a ponta por predefinição | O fornecedor pode ler o teu correio |
|---|---|---|---|---|
| Gmail (consumo) | TLS | Sim (a Google detém as chaves) | Não | Sim |
| Outlook / Microsoft 365 (consumo) | TLS | Sim (a Microsoft detém as chaves) | Não | Sim |
| Gmail Workspace + CSE / S/MIME | TLS | Sim | Só se configurado | Reduzido com CSE |
| Proton Mail | TLS | Acesso zero (as chaves são tuas) | Sim, entre utilizadores Proton | Não |
O padrão é constante: os serviços de consumo cifram em trânsito e em repouso mas detêm as chaves, por isso podem — e para funcionalidades e pedidos legais, fazem-no — ler o conteúdo. Alcançar a ponta a ponta no Gmail ou no Outlook é possível mas exige configuração deliberada (S/MIME, ou cifragem do lado do cliente em planos pagos específicos). O Proton Mail é construído E2EE-e-acesso-zero por predefinição, o que o torna o fornecedor mais citado quando «e-mail cifrado» indica a camada 2 ou 3 em vez da camada 1.
Uma nota sobre verificação, no espírito da soberania de dados: uma afirmação de cifragem que não podes inspecionar é uma asserção, não uma garantia. Os clientes de código aberto — o Proton publica os seus — permitem que revisores independentes confirmem que as chaves são geradas no teu dispositivo e que o texto em claro nunca chega ao servidor. Prefere fornecedores cujas afirmações sejam auditáveis aos que apenas as enunciam.
Um quadro de decisão
Para de perguntar «qual e-mail está mais cifrado» e pergunta antes «quem não deve poder ler isto, e o destinatário está disposto a participar?»
A cifragem de transporte basta quando o conteúdo é corrente e a tua única preocupação é um bisbilhoteiro de rede. Todo fornecedor sério já ta dá; não há nada a configurar.
Usa ponta a ponta (PGP ou S/MIME) quando mensagens específicas tiverem de ser ilegíveis para todo servidor do caminho e o destinatário puder deter uma chave — um colega, a fonte de um jornalista, uma organização com S/MIME gerido. Aceita o passo de troca de chaves como o preço da garantia.
Usa um fornecedor de acesso zero como o Proton Mail quando quiseres toda a tua caixa ilegível para o fornecedor sem obrigar cada correspondente a usar PGP, com um recurso protegido por palavra-passe para a mensagem cifrada ocasional a um externo.
Escolhas o que escolheres, lembra-te de duas coisas. Primeiro, os metadados não estão cifrados — a cifragem esconde as palavras, não a relação. Segundo, verifica a afirmação: prefere clientes de código aberto e uma jurisdição respeitadora da privacidade, para que «não conseguimos ler o teu correio» seja algo que podes confirmar em vez de algo que tens de acreditar.
Para o lado do armazenamento da mesma configuração de privacidade, vê o nosso guia de armazenamento na cloud cifrado para programadores, e para a questão mais ampla de manter os dados fora dos serviços sob jurisdição norte-americana, o pilar sobre a soberania de dados.
