O que é encriptação do lado do cliente? O seu navegador faz o trabalho

A encriptação do lado do cliente significa que o seu navegador ou aplicação encripta os ficheiros no seu dispositivo antes de qualquer dado tocar na rede. O servidor recebe apenas texto cifrado — saída AES-256-GCM indistinguível de ruído aleatório — e a chave de desencriptação nunca abandona o cliente. É o oposto da encriptação do lado do servidor, onde o fornecedor guarda as chaves e pode tecnicamente ler os seus ficheiros. A Web Crypto API (window.crypto.subtle) torna isto possível em qualquer navegador moderno sem plugins, a cerca de 2–3 GB/s em hardware com AES-NI. Serviços como HexaTransfer, SwissTransfer, Tresorit Send, e Proton Drive usam este modelo para garantir que os ficheiros permanecem privados mesmo que o próprio serviço seja comprometido.

O navegador como motor criptográfico

Há cinco anos, a encriptação real exigia instalar uma aplicação de ambiente de trabalho ou usar PGP na linha de comandos. A Web Crypto API, padronizada pelo W3C em 2017, mudou isso. Expõe AES-GCM, RSA-OAEP, ECDH, HMAC, PBKDF2, e SHA-256 diretamente ao JavaScript em qualquer navegador moderno — Chrome, Firefox, Safari, Edge.

O desempenho já não é o obstáculo. As instruções Intel AES-NI atingem 3–5 GB/s por núcleo para AES-256-GCM. As Cryptography Extensions da ARM nos chips Apple M-series e Qualcomm Snapdragon oferecem débito semelhante. Encriptar um ficheiro de 1 GB no navegador demora cerca de 300–500 ms num portátil de gama média.

O desafio restante é lidar com ficheiros maiores do que a memória do navegador. A Streams API e o ReadableStream permitem processar ficheiros em blocos de 4 MB, encriptando cada bloco independentemente com um IV de modo contador único. É assim que os serviços elevam o limite para 10 GB ou mais.

Um fluxo mínimo de encriptação do lado do cliente

Eis a sequência que um serviço típico baseado em navegador executa:

// 1. Gerar uma chave AES aleatória de 256 bits
const key = await crypto.subtle.generateKey(
  { name: "AES-GCM", length: 256 }, true, ["encrypt", "decrypt"]
);

// 2. Ler o ficheiro em blocos
const file = fileInput.files[0];
const chunkSize = 4 * 1024 * 1024;

// 3. Encriptar cada bloco com um IV único de 12 bytes
for (let offset = 0; offset < file.size; offset += chunkSize) {
  const chunk = file.slice(offset, offset + chunkSize);
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const ciphertext = await crypto.subtle.encrypt(
    { name: "AES-GCM", iv }, key, await chunk.arrayBuffer()
  );
  // 4. Carregar [iv || ciphertext] para o servidor
}

// 5. Exportar a chave e incorporá-la no fragmento do URL de partilha
const keyBytes = await crypto.subtle.exportKey("raw", key);
const shareUrl = `https://exemplo.com/d/${fileId}#k=${base64url(keyBytes)}`;

O servidor vê bytes de aparência aleatória, um ID de ficheiro, e nada mais. A chave existe apenas na memória do navegador do utilizador e no fragmento do URL.

Por que supera a encriptação do lado do servidor

A encriptação do lado do servidor significa que o fornecedor desencripta a pedido — para gerar miniaturas, executar análises antivírus, processar pesquisas, ou responder a pedidos legais. Uma divulgação da Apple em 2023 revelou que as cópias de segurança do iCloud (que não eram encriptadas ponta a ponta até ao lançamento da Proteção Avançada de Dados) eram acessíveis pela Apple e portanto pelas autoridades norte-americanas mediante pedidos válidos.

A encriptação do lado do cliente inverte esta situação. Como a chave nunca chega ao fornecedor:

• Funcionários desonestos não veem nada. O engenheiro com acesso à base de dados obtém texto cifrado.
• As intimações produzem texto cifrado. O fornecedor pode cumprir mandados entregando o blob encriptado, que é inútil sem a chave.
• As violações vazam texto cifrado. O incidente LastPass de 2021 demonstrou a importância disto — os cofres roubados estavam encriptados, e apenas os utilizadores com palavras-passe mestras fracas correram risco real.
• As paragens do fornecedor não comprometem os dados. Mesmo que a empresa desapareça, a sua cópia local da chave (o URL) ainda desencripta o ficheiro.

O que o servidor ainda consegue ver

A encriptação do lado do cliente protege o conteúdo dos ficheiros, mas não tudo. O servidor observa tipicamente:

• Tamanho do ficheiro — o comprimento do texto cifrado aproxima o comprimento do texto simples (AES-GCM adiciona 16 bytes por encriptação, mais o IV de 12 bytes).
• Endereços IP de carregamento e descarregamento com timestamps.
• Metadados de sessão dos handshakes TLS, incluindo a impressão digital TLS do cliente.
• Nomes de ficheiros encriptados — a menos que sejam incluídos no payload encriptado, podem vazar.

Os melhores serviços do lado do cliente encriptam os nomes de ficheiros como parte do cabeçalho do texto cifrado e aplicam padding a tamanhos em intervalos (1 MB, 10 MB, 100 MB) para ocultar o tamanho. O Tresorit e o Proton Drive documentam explicitamente a sua exposição de metadados.

Encriptação do lado do cliente protegida por palavra-passe

Muitos serviços permitem aos utilizadores adicionar uma palavra-passe por cima do fragmento do URL. O fluxo:

1. O navegador gera um sal aleatório de 128 bits e deriva uma chave usando PBKDF2-HMAC-SHA-256 com 600 000 iterações (recomendação OWASP 2023) ou Argon2id com memória=64 MB, iterações=3.
2. O ficheiro é encriptado com a chave derivada.
3. O sal vai no fragmento do URL; a palavra-passe é comunicada fora de banda.
4. O destinatário escreve a palavra-passe, que deriva novamente a chave localmente.

Isto transforma uma partilha de canal único (o URL é suficiente) em dois fatores: o atacante precisa do link e da palavra-passe, idealmente enviados por canais diferentes. O PBKDF2 com 600 000 iterações torna o ataque de força bruta offline cerca de 10 segundos por tentativa num GPU moderno, pelo que as palavras-passe precisam de mais de 40 bits de entropia para resistir a atacantes determinados — pense em 10+ caracteres de um alfabeto diversificado.

A mudança de confiança: do serviço para o código cliente

A encriptação do lado do cliente move a fronteira de confiança. Antes, confiava que o serviço tratasse bem o seu texto simples. Agora, confia no JavaScript que o serviço envia ao seu navegador em cada carregamento de página. Uma atualização maliciosa poderia extravasar a chave antes ou durante a encriptação.

Existem três mitigações, com diferentes graus de rigor:

• Subresource Integrity (SRI) nas tags de script garante que o hash do JS corresponde a um valor conhecido.
• Auditorias de código por empresas como Cure53, NCC Group, ou Trail of Bits verificam que a lógica de encriptação é sólida.
• Builds reprodutíveis permitem que partes independentes confirmem que o código enviado corresponde ao código-fonte publicado.
• Cabeçalhos Content Security Policy (CSP) bloqueiam scripts de terceiros que possam interferir com a encriptação.

A abordagem mais rigorosa, usada pelo pmcrypto do Proton Mail e por alguns clientes baseados em Electron, distribui binários assinados em vez de JavaScript novo a cada visita. Os serviços baseados em navegador trocam algum deste rigor pela conveniência de não precisar de instalação.

Casos de uso onde o lado do cliente brilha

Alguns cenários onde a encriptação do lado do cliente vale o primeiro carregamento ligeiramente mais lento:

• Documentos legais e médicos. O HIPAA 45 CFR § 164.312 e o sigilo advogado-cliente beneficiam muito de arquiteturas cegas ao fornecedor.
• Jornalismo e proteção de fontes. Envio de documentos não redatados onde mesmo a exposição de metadados acarreta risco.
• Propriedade intelectual empresarial. Documentos de conselho de administração, modelos financeiros, materiais de fusões e aquisições onde ameaças internas ao fornecedor de transferência de ficheiros são uma preocupação realista.
• Registos pessoais. Documentos fiscais, passaportes, testes médicos — ficheiros com que ficaria desconfortável de ver no título de uma violação de dados do fornecedor.

Para ficheiros de baixa sensibilidade (uma fotografia de reunião, uma receita), a encriptação tradicional do lado do servidor é adequada.

Como reconhecer encriptação genuína do lado do cliente

Quatro sinais de que um serviço realmente faz encriptação do lado do cliente:

1. O fragmento do URL contém uma chave. O URL de partilha tem texto após # que parece bytes aleatórios codificados em base64.
2. Os carregamentos são texto cifrado. Abra as DevTools → Rede durante o carregamento; o corpo do pedido deve parecer bytes aleatórios, não o nome do seu ficheiro.
3. Ficheiros grandes ainda funcionam rapidamente. Um fluxo genuíno do lado do cliente processa blocos; não recarrega para um gateway de encriptação do lado do servidor.
4. A política de privacidade diz "não conseguimos desencriptar os seus ficheiros." Acompanhada de um whitepaper técnico, não apenas texto de marketing.

Serviços que passam: SwissTransfer E2EE, Tresorit Send, ligações partilhadas do Proton Drive, Mega.nz, e HexaTransfer. Serviços que não passam: WeTransfer (standard), Google Drive, ligações de partilha do Dropbox.

Como colocar isto em prática

Se quiser experimentar a encriptação do lado do cliente hoje, abra as DevTools e observe o separador Rede enquanto carrega um ficheiro. Deve ver um blob encriptado a ir para o servidor e uma chave na sua barra de endereços que nunca aparece em nenhum pedido. Essa é toda a promessa.

Experimente em hexatransfer.com — gratuito, sem conta, até 10 GB.