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
| Ator | Cloud padrão (Dropbox, GDrive, iCloud) | pCloud Crypto / MEGA | Proton Drive / Tresorit / Nextcloud E2E |
|---|---|---|---|
| Fornecedor (funcionário interno) | Conteúdo legível com privilégio interno | Não (pasta Crypto apenas no pCloud) | Não |
| Fornecedor (pedido legal) | Tem de decifrar se exigido | Tecnicamente impossível | Tecnicamente impossível |
| Atacante que viola o servidor | Lê os ficheiros decifrados em memória | Bloqueado (Crypto apenas no pCloud) | Bloqueado |
| Você (dispositivo cliente comprometido) | Lê tudo | Lê a pasta Crypto + acede à chave | Lê tudo |
| Metadados (nome, tamanho, data) | Visíveis no servidor | Nome cifrado, tamanho visível | Tudo cifrado exceto o tamanho (Proton) |
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:
- Pesquise "whitepaper" + nome do fornecedor no Google. Se não existir um whitepaper público, forte sinal negativo.
- 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.
- Leia o procedimento de recuperação da palavra-passe. Se for possível sem chave de recuperação prévia, não é zero-knowledge.
- Verifique se o código cliente é open source ou auditado. Sem isso, confia cegamente no binário que instala.
- 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. Um caso limite que vale a leitura completa: Backblaze oferece uma chave de encriptação privada real e, ainda assim, o seu restauro pela web pede para escrever essa chave no servidor deles. O ponto 3 acima apanha-o, e é exatamente para isso que serve a lista.
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.
Guias relacionados
Para aprofundar, consulte como funciona a cifragem do lado do cliente, como o zero-knowledge lida com os metadados na nuvem, as aplicações de mensagens mais seguras, o que são os metadados e o que é a cifragem zero-knowledge.
Perguntas frequentes
- O que é a cifragem zero-knowledge no armazenamento na cloud?
- A cifragem zero-knowledge significa que o fornecedor da cloud nunca possui as suas chaves de decifragem. Os ficheiros são cifrados no seu dispositivo antes do carregamento usando uma chave derivada da sua palavra-passe; o servidor armazena apenas o texto cifrado. Mesmo com uma ordem judicial, o fornecedor não consegue decifrar os seus dados. Em 2026, apenas o Proton Drive, o Tresorit e o Nextcloud self-host com módulo E2E conseguem isto por predefinição, em todos os ficheiros, sem custos adicionais.
- Qual é a diferença entre E2E e zero-knowledge?
- End-to-end (E2E) significa que os dados são cifrados do dispositivo do remetente ao dispositivo do destinatário - nenhum intermediário (ISP, anfitrião) pode ler. O zero-knowledge vai mais longe: o servidor nunca armazena as chaves em claro, por isso nem o seu operador (fornecedor) consegue decifrar, mesmo sob coação legal. Um serviço pode ser E2E sem ser zero-knowledge se as chaves forem geridas do lado do servidor. Inversamente, um serviço zero-knowledge é necessariamente E2E para o conteúdo protegido.
- O pCloud é mesmo zero-knowledge?
- O pCloud padrão NÃO é zero-knowledge: os seus ficheiros são cifrados em repouso com AES-256 mas com chaves geridas pelo fornecedor. O verdadeiro zero-knowledge exige o add-on pCloud Crypto (49,99 $/ano ou 125 $ lifetime), que cifra do lado do cliente com uma chave derivada da sua palavra-passe - o pCloud não consegue decifrar nem com um mandado. Se perder esta palavra-passe, os ficheiros ficam perdidos permanentemente.
- O Proton Drive é zero-knowledge por predefinição?
- Sim - todos os dados armazenados no Proton Drive são cifrados do lado do cliente com OpenPGP antes do carregamento. O Proton não vê nem o conteúdo nem os nomes dos ficheiros (cifrados separadamente). O mecanismo está documentado no seu whitepaper público e foi submetido a uma auditoria independente (Securitum). Únicos metadados não cifrados: os tamanhos dos ficheiros e os timestamps técnicos.
- Que fornecedores de cloud são realmente E2E + zero-knowledge?
- Dos 12 fornecedores comparados (pCloud, Proton Drive, Tresorit, Sync.com, MEGA, Internxt, Cryptee, Filen, Icedrive, NordLocker, SpiderOak, Nextcloud self-host), apenas 3 são E2E + zero-knowledge por predefinição sem sobretaxa: Proton Drive, Tresorit e Nextcloud self-host com módulo E2E ativado. O pCloud Crypto e o MEGA atingem este nível mas em modo degradado (add-on pago para o pCloud, revisão limitada do código JS para o MEGA).
- O zero-knowledge protege contra tudo?
- Não. O zero-knowledge protege contra a leitura pelo fornecedor, contra atacantes do servidor ou pedidos legais. Mas NÃO protege contra: (1) dispositivo cliente comprometido (keylogger, malware), (2) perda da palavra-passe (recuperação impossível), (3) metadados não cifrados (tamanho, timing, frequência de acesso), (4) ataques JS dinâmicos se o código da web app estiver comprometido. Necessário mas não suficiente.
- Como posso verificar que um serviço é realmente zero-knowledge?
- Cinco indicadores: (1) whitepaper público que detalha o esquema de gestão de chaves; (2) auditoria independente recente (Cure53, SEC Consult, NCC Group, Trail of Bits); (3) código cliente open source ou inspecionável; (4) procedimento de recuperação da palavra-passe documentado e impossível (= bom sinal); (5) documentação explícita dos metadados não cifrados. Se algum destes 5 pontos faltar, o serviço faz marketing de zero-knowledge, não zero-knowledge criptográfico.
Guarda os teus ficheiros em privado → pCloud
Privacidade suíça · 10 GB grátis · Crypto zero-knowledge opcional
