Como funcionam as chaves de encriptação: a base da segurança de ficheiros

Uma chave de encriptação é uma cadeia de bits aleatórios que bloqueia e desbloqueia dados. Para a transferência moderna de ficheiros, isso significa tipicamente uma chave AES de 256 bits — 32 bytes de dados aleatórios gerados por um gerador de números aleatórios criptograficamente seguro (CSPRNG). O mesmo algoritmo que transforma um vídeo de 10 GB em texto cifrado só consegue descifrá-lo se receber exatamente a mesma chave. A segurança das chaves é onde a encriptação vive ou morre: uma cifra AES-256 perfeita é inútil se a chave for fraca, previsível, ou exposta. Este artigo explica como as chaves são criadas, partilhadas, armazenadas, e destruídas em serviços reais como o HexaTransfer, o Tresorit, e o Proton Drive.

As chaves são apenas números aleatórios

Uma chave de 256 bits são 32 bytes. Se gerar uma no navegador, fica assim:

const key = crypto.getRandomValues(new Uint8Array(32));
// Uint8Array(32) [183, 45, 201, 77, ...]

O que a torna uma "chave" é a forma como um algoritmo a usa. O AES-256-GCM pega numa chave de 256 bits, expande-a através de um schedule de chaves em 15 chaves de ronda, e usa-as para misturar blocos de 128 bits ao longo de 14 rondas. A matemática não se importa com a origem dos bits — apenas exige que sejam secretos e imprevisíveis.

"Imprevisível" é a parte mais difícil. Se um atacante conseguir adivinhar o estado do seu PRNG, pode regenerar a sua chave. O bug do OpenSSL do Debian em 2006 reduziu a entropia das chaves a 15 bits durante dois anos antes de ser detetado — um exemplo paradigmático do que acontece quando a aleatoriedade falha.

Aleatoriedade criptograficamente segura

Os navegadores fornecem crypto.getRandomValues(), que extrai do CSPRNG do sistema operativo: /dev/urandom no Linux, BCryptGenRandom no Windows, SecRandomCopyBytes no macOS. Estes por sua vez misturam múltiplas fontes de entropia — tempos de interrupção, tempos de pesquisa em disco, chips de RNG de hardware como o RDRAND da Intel.

Não use Math.random() para chaves. É um Mersenne Twister previsível e o estado pode frequentemente ser recuperado a partir de alguns resultados.

No lado do servidor, crypto.randomBytes() em Node.js e secrets.token_bytes() em Python envolvem o CSPRNG do SO e são seguros. Os padrões NIST SP 800-90A e SP 800-90B definem os requisitos para CSPRNGs; o kernel Linux 5.17+ usa um design baseado em BLAKE2s que os cumpre.

Chaves simétricas: uma chave, duas direções

Os algoritmos simétricos como o AES usam uma chave para encriptar e desencriptar. As opções de tamanho de chave:

• 128 bits — 2^128 valores possíveis, seguro para a maioria dos fins, aprovado para SECRET pela NSA CNSSP-15.
• 192 bits — raro, usado em alguns contextos governamentais.
• 256 bits — 2^256 valores, aprovado para TOP SECRET, padrão atual para serviços de transferência de ficheiros.

Duplicar o tamanho da chave não duplica a dificuldade de força bruta — eleva-a ao quadrado. 2^128 já está fora de alcance (a idade do universo multiplicada por 10 mil milhões com todos os computadores da Terra). Os 256 bits são uma proteção contra computadores quânticos, onde o algoritmo de Grover reduz efetivamente a força das chaves simétricas para metade.

O problema difícil com chaves simétricas: como fazer chegar a mesma chave a ambas as partes sem ninguém a intercetar.

Chaves assimétricas: o truque do par

A criptografia de chave pública resolve a distribuição de chaves. Cada parte gera um par de chaves matematicamente ligadas: uma chave pública (partilhada abertamente) e uma chave privada (mantida em segredo). Tudo o que é encriptado com a chave pública só pode ser desencriptado com a chave privada.

Tipos comuns de chaves assimétricas:

• RSA-2048 — módulo de 2048 bits, amplamente suportado, lento. Usado em certificados TLS.
• RSA-4096 — mais forte, ainda mais lento.
• Curve25519 (X25519) — chave de curva elíptica de 256 bits, rápida, usada pelo Signal e WireGuard.
• Ed25519 — chave de assinatura de 256 bits, usada pelo SSH e assinatura de commits Git.

A chave privada tem 32–512 bytes dependendo do algoritmo. As chaves privadas RSA são maiores porque contêm múltiplos primos; as chaves privadas Curve25519 são apenas 32 bytes aleatórios.

Híbrido: combinar os dois em sistemas reais

Nenhum sistema prático encripta ficheiros grandes diretamente com RSA. Em vez disso, todos os protocolos reais — TLS, PGP, Age, Signal, todos os serviços sérios de transferência de ficheiros — usam encriptação híbrida:

1. Gerar uma chave AES aleatória de 256 bits ("chave de sessão" ou "chave de ficheiro").
2. Encriptar o ficheiro com AES-256-GCM.
3. Encriptar a chave de sessão com a chave pública do destinatário.
4. Enviar ambos.

O destinatário desencripta a chave de sessão com a sua chave privada, depois usa-a para desencriptar o ficheiro. Obtém-se a velocidade da encriptação simétrica e a conveniência de distribuição de chaves da encriptação assimétrica.

Para transferência de ficheiros baseada em navegador, a "chave pública" é frequentemente substituída pelo fragmento do URL: o remetente gera uma chave de sessão, incorpora-a no URL após #, e o navegador do destinatário lê-a localmente. Mais simples, e funciona sem exigir que os destinatários tenham um par de chaves.

Derivação de chaves a partir de palavras-passe

Os utilizadores escrevem palavras-passe; os algoritmos querem bits aleatórios uniformes. Uma função de derivação de chaves (KDF) faz a ponte:

• PBKDF2-HMAC-SHA-256 — itera uma função de hash. O OWASP 2023 recomenda 600 000 iterações. Disponível na Web Crypto API.
• scrypt — resistente à memória, resiste a ataques de GPU. Parâmetros: N=2^17, r=8, p=1.
• Argon2id — melhor prática atual, vencedor do Password Hashing Competition de 2015. Parâmetros: memória=64 MB, iterações=3, paralelismo=4.

Uma KDF adiciona um sal (aleatório, guardado junto ao texto cifrado) e um fator de trabalho (iterações) para tornar a força bruta mais lenta. Uma palavra-passe aleatória de 12 caracteres através do Argon2id com 64 MB de memória levaria uma fazenda de GPU milhares de anos a esgotar. Uma palavra-passe fraca como verao2024 cai em segundos independentemente da KDF — a KDF não consegue adicionar entropia que não estava lá.

Armazenamento de chaves: onde vivem as chaves?

As chaves precisam de existir algures, e esse lugar é uma decisão crítica de segurança:

• Memória do navegador (apenas sessão). O padrão para transferências efémeras de ficheiros. A chave é gerada, usada, e descartada dentro do carregamento da página.
• Fragmento do URL. Partilhado através do link, guardado no histórico do navegador do destinatário. O tempo de vida limitado é importante.
• Local storage / IndexedDB. Persistente mas acessível a qualquer JavaScript na origem. Arriscado a menos que encriptado com outra chave.
• Keychain do SO — macOS Keychain, Windows DPAPI, Linux libsecret. Suportado por hardware em algumas plataformas.
• Módulo de Segurança de Hardware (HSM) — YubiKey, HSM em nuvem (AWS CloudHSM, Azure Dedicated HSM). As chaves nunca saem do hardware.
• Key Management Service (KMS) — AWS KMS, Google Cloud KMS, HashiCorp Vault. Centralizado, auditável, com preço de cerca de 1 $/chave/mês.

Para transferência de ficheiros de conhecimento zero, a chave vive no fragmento do URL e no navegador do remetente. O servidor nunca a armazena.

Rotação e destruição de chaves

Chaves de longa duração acumulam risco. A boa prática é a rotação:

• Certificados TLS: rotação a 90 dias (padrão do Let's Encrypt), máximo de 398 dias para CAs públicas desde 2020.
• Chaves de encriptação de dados: tipicamente rotacionadas a cada 90 dias a 1 ano em sistemas conformes (PCI DSS 4.0 Requisito 3.6).
• Chaves mestras: rotacionadas anualmente ou com alterações de pessoal.

A destruição também é importante. Simplesmente eliminar ficheiros de chaves do disco é insuficiente — os SSDs podem reter dados em áreas de wear-leveling. A destruição segura requer sobrescrever os dados ou usar comandos de eliminação dedicados de HSM. O apagamento criptográfico — descartar a chave para que os dados encriptados fiquem permanentemente ilegíveis — é frequentemente a abordagem mais limpa para dados em massa.

Os serviços de transferência de ficheiros usam tipicamente chaves por ficheiro que existem apenas durante o tempo de vida da transferência (24 horas a 7 dias) e são descartadas juntamente com o texto cifrado na expiração.

Reconhecer práticas de chaves fracas

Três modos de falha comuns a vigiar:

• Chaves codificadas no código cliente. Se a chave for a mesma para todos os utilizadores, não é uma chave — é ofuscação.
• Chaves guardadas junto ao texto cifrado no mesmo servidor ou base de dados. Uma violação expõe ambos.
• Sem rotação de chaves. Sistemas legados com chaves de encriptação de uma década acumularam aproximadamente uma década de risco de violação.

Um serviço respeitável publica um whitepaper criptográfico cobrindo geração, armazenamento, rotação, e destruição de chaves — e submete-se a auditorias de terceiros por empresas como a Cure53 ou a Trail of Bits.

Colocar em perspetiva

Para partilha segura de ficheiros: escolha um serviço que gere chaves de 256 bits do lado do cliente via crypto.getRandomValues(), as incorpore apenas no fragmento do URL (nunca enviadas ao servidor), suporte chaves derivadas de palavras-passe via PBKDF2 ou Argon2id, e expire automaticamente tanto a chave como o texto cifrado em 24 horas.

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