E2E vs zero-knowledge no armazenamento na cloud: o que o marketing esconde (2026)

O que é a cifragem zero-knowledge — e em que difere do end-to-end?

A cifragem zero-knowledge significa que o seu fornecedor de cloud nunca detém as suas chaves de decifragem. Os ficheiros são cifrados no seu dispositivo antes do carregamento; o servidor armazena apenas texto cifrado ilegível. O end-to-end (E2E) protege apenas os dados em trânsito. O zero-knowledge protege também contra o próprio servidor: mesmo sob coação legal, o fornecedor não consegue decifrar. Em 2026, apenas 3 dos 12 fornecedores comparados oferecem ambos por predefinição.

Quer saber quão exposta está a sua configuração atual? Faça o nosso quiz gratuito de pontuação de privacidade — algumas perguntas sobre a sua cloud e os seus hábitos, e obtém uma pontuação mais correções concretas.

O essencial

Se quer compreender o que está realmente por trás das promessas "cifrado end-to-end" e "zero-knowledge" do armazenamento na cloud em 2026, eis o que reter. Os dois termos não são sinónimos: o E2E protege a transmissão, o zero-knowledge protege também o servidor contra si próprio. Um serviço pode ser E2E sem ser zero-knowledge — é o caso da maioria dos fornecedores consumidores que cifram em repouso com as próprias chaves.

Dos 12 fornecedores comparados, apenas 3 atingem o verdadeiro nível E2E + zero-knowledge sem condições: Proton Drive (Suíça, OpenPGP, auditoria independente Securitum), Tresorit (auditorias independentes, ISO 27001) e Nextcloud self-host com módulo E2E ativado. Outros dois atingem-no mas com asteriscos significativos: o pCloud Crypto exige um add-on pago, e o MEGA baseia-se em código JavaScript entregue dinamicamente (segurança contestada por investigadores).

O resto — Dropbox, Google Drive, OneDrive, iCloud — são E2E no transporte (TLS) e AES-256 em repouso, mas com gestão de chaves do lado do servidor. Sob coação legal (CLOUD Act dos EUA vs RGPD, pedido judicial da UE), estes fornecedores podem e devem decifrar os seus dados. Esta exposição legal é o que leva os utilizadores sensíveis para a jurisdição suíça — veja a nossa comparação Proton Drive vs Tresorit vs pCloud Crypto para os três fornecedores fora dos 14 Eyes.

Por que "end-to-end" se tornou um termo de marketing em vez de técnico?

Quando a Apple escreve "cifrado end-to-end" sobre o iMessage, é criptograficamente verdadeiro: só o remetente e o destinatário têm chaves, a Apple não pode ler. Mas quando a Microsoft escreve "os seus dados estão cifrados end-to-end" sobre o OneDrive Personal Vault, o significado diverge: a transmissão está cifrada e o conteúdo em repouso também, mas a Microsoft detém as chaves de decifragem para o ajudar a recuperar a conta se perder a palavra-passe. A mesma expressão, modelos de confiança opostos.

Esta confusão convém aos serviços que querem capitalizar a perceção de privacidade mantendo a capacidade operacional de decifrar (recuperação de conta, indexação de pesquisas, conformidade legal). O termo zero-knowledge surgiu como reação para qualificar os serviços em que o fornecedor, por construção criptográfica, não pode decifrar mesmo que quisesse.

O que dizem os whitepapers técnicos

Para distinguir o marketing da técnica, o único indicador fiável é o whitepaper. A Proton publica o seu próprio (versões 2014, 2018, 2023) com o esquema exato de derivação de chaves a partir da palavra-passe do utilizador via Argon2id. A Tresorit faz o mesmo. Inversamente, a Dropbox publica um "encryption white paper" que descreve o AES-256 em repouso sem detalhar a gestão de chaves — precisamente porque as chaves são controladas do lado do servidor.

Quando um whitepaper evita a secção "gestão de chaves", é geralmente porque o modelo não resiste a um exame atento.

Quem vê o quê na sua cloud — a matriz real

Esta matriz torna a decisão concreta. Se armazena documentos fiscais, médicos, legais cuja confidencialidade tem de sobreviver a um pedido legal ao fornecedor, só a coluna da direita se sustenta. Se armazena fotos de família sem implicação legal, a coluna do meio é suficiente (com o custo do add-on Crypto no pCloud). Para o panorama mais amplo das jurisdições por trás destes pedidos legais, veja a nossa visão geral 5/9/14 Eyes e armazenamento na cloud.

Quais são as armadilhas de marketing zero-knowledge mais comuns a evitar?

Armadilha 1: recuperação de palavra-passe disponível

O verdadeiro zero-knowledge implica que esquecer a palavra-passe = perder os dados. Se um fornecedor oferece um procedimento de recuperação sem ter previamente armazenado uma chave de recuperação do lado do cliente (que imprimiu e que ele desconhece), então as chaves são geridas do lado do servidor e o zero-knowledge é enganador.

A Apple iCloud Advanced Data Protection é um bom contraexemplo: a Apple exige o registo ou de um contacto de recuperação, ou de uma chave de recuperação em papel (28 caracteres) na ativação. Esta chave nunca é transmitida à Apple. Se perder a palavra-passe E a chave, a Apple nada pode fazer. É o marcador operacional do verdadeiro zero-knowledge.

Armadilha 2: indexação de pesquisas do lado do servidor

Se um serviço oferece pesquisa full-text nos seus ficheiros a partir da interface web (caso Dropbox, Google Drive), é matematicamente incompatível com o zero-knowledge — o servidor tem de poder ler o conteúdo para indexar. O Proton Drive e o Tresorit limitam voluntariamente a sua pesquisa aos nomes dos ficheiros.

Armadilha 3: cifragem do lado do cliente via JavaScript entregue pelo servidor

O MEGA e muitos serviços web "zero-knowledge" baseiam-se em código JavaScript entregue pelo servidor a cada sessão. Se o servidor estiver comprometido ou legalmente coagido, pode entregar código JS subtilmente modificado que exfiltra a palavra-passe antes da cifragem, sem que o utilizador o veja. Este risco está documentado desde Mathias Bynens (2013) e mantém-se válido em 2026.

Mitigação: use clientes nativos (desktop, mobile) em vez de web, ou web apps com Subresource Integrity verificada nos bundles JS críticos (raro).

Armadilha 4: metadados não cifrados

Mesmo os melhores serviços zero-knowledge deixam passar alguns metadados:

• Tamanhos dos ficheiros (usados para faturação)
• Timestamps de criação / modificação
• Frequência de acesso (usada para caching)
• Endereço IP de ligação (registado por segurança)

Para casos de uso muito sensíveis (denunciante, jornalista que protege as fontes), estes metadados podem bastar para correlacionar a sua atividade com um evento. Mitigação: combine privacidade na cloud + VPN + horários de acesso irregulares, ou armazene cifrado + carregue numa cloud não zero-knowledge com nome de ficheiro ofuscado (modelo "blob storage").

Como verificar em 5 minutos que um serviço é realmente zero-knowledge

Sem ter de ler um whitepaper de 40 páginas, eis o procedimento rápido:

1. Pesquise "whitepaper" + nome do fornecedor no Google. Se não existir um whitepaper público, forte sinal negativo.
2. Pesquise "audit" + nome do fornecedor. Uma auditoria independente recente (≤ 2 anos) por uma empresa reconhecida (Cure53, SEC Consult, NCC Group, Trail of Bits) é obrigatória para o verdadeiro zero-knowledge.
3. Leia o procedimento de recuperação da palavra-passe. Se for possível sem chave de recuperação prévia, não é zero-knowledge.
4. Verifique se o código cliente é open source ou auditado. Sem isso, confia cegamente no binário que instala.
5. Leia a documentação dos metadados. O fornecedor tem de listar explicitamente o que permanece legível do lado do servidor — o que está em claro é o que sacrifica.

Se mesmo um só destes 5 pontos faltar, o serviço enquadra-se no marketing zero-knowledge, não no criptográfico. Isso não significa que seja mau — o Dropbox continua a ser uma excelente ferramenta de produtividade — mas não deve ser a sua escolha para dados cuja confidencialidade tem de sobreviver a um ator estatal ou a uma fuga do servidor.

O nosso veredito prático para 2026

Para a maioria dos utilizadores consumidores, um compromisso razoável é o uso diferenciado: serviços padrão (Google Drive, Dropbox) para ficheiros do dia a dia cuja fuga não teria consequências, e um serviço verdadeiramente zero-knowledge (Proton Drive por predefinição, pCloud Crypto se preferir a oferta lifetime) para documentos sensíveis. Antes de escolher, modele o custo total a 5 anos de cada opção com a nossa calculadora de custos de armazenamento na cloud. Esta segmentação é mais eficaz do que migrar tudo.

Para perfis de alto risco (jornalistas, advogados, médicos, ativistas), apenas o Proton Drive, o Tresorit ou o Nextcloud self-host com módulo E2E são defensáveis. E mesmo nestes casos, a cloud é apenas um elo: a segurança do dispositivo cliente, o VPN e a separação operacional entre identidade pública e identidade protegida contam tanto quanto.

O verdadeiro valor da Priviy nesta análise não é vender-lhe um serviço específico, mas dar-lhe as ferramentas para distinguir a retórica de marketing das verdadeiras garantias criptográficas. Por este critério, em 2026, o marketing infelizmente venceu em 75% dos casos — os utilizadores compram "privacidade" e recebem "cifragem em repouso".

Para uma referência concisa sobre todos os termos técnicos usados neste artigo (zero-knowledge, E2EE, AES-256, metadados, cifragem convergente, KDF, PFS e mais), veja o nosso glossário de cloud cifrada e privacidade.

Continuar a ler

• Análise pCloud 2026 — teste de 8 meses, oferta lifetime e add-on Crypto
• Melhores serviços de armazenamento na cloud cifrado 2026 — classificação de fornecedores por seis critérios — que serviços são criptograficamente zero-knowledge vs marketing zero-knowledge
• Proton Drive vs Tresorit vs pCloud Crypto — o duelo suíço 2026
• 5/9/14 Eyes e armazenamento na cloud — que jurisdições evitar
• CLOUD Act dos EUA vs RGPD — o que realmente acontece sob pressão legal
• A nossa metodologia de privacidade na cloud
• Priviy Wikidata Q140050544
• Referência académica: EFF Surveillance Self-Defense (https://ssd.eff.org/)
• RFC 8446 (TLS 1.3): https://datatracker.ietf.org/doc/html/rfc8446

Artigo publicado a 4 de junho de 2026. Metodologia: comparação editorial de 12 fornecedores de armazenamento na cloud (Proton Drive, Tresorit, pCloud, Sync.com, MEGA, Internxt, Cryptee, Filen, Icedrive, NordLocker, SpiderOak, Nextcloud self-host). Fontes: whitepapers públicos dos fornecedores, auditorias independentes publicadas, documentação oficial dos procedimentos de recuperação da palavra-passe, comportamento da pesquisa full-text e a forma como o JavaScript do lado do cliente é entregue.