Cifrar um ficheiro e enviar a chave por outra via
Publicado a 06/08/2026 · 12 min de leitura · Ferramentas para programadores
Daniel Okonkwo — Programador front-end e redator de Tecnologia na OneKitly
Desempenho web · Formatos de ficheiro
Verificado a partir de 4 fontes
A ferramenta de cifragem de ficheiros corre inteiramente no seu navegador e usa AES-256-GCM através da API WebCrypto. Lendo o código publicado e executando-o: a sua frase-passe é esticada com PBKDF2-HMAC-SHA256 ao longo de 150 000 iterações até uma chave de 256 bits; em cada cifragem são gerados um sal aleatório de 16 bytes e um nonce aleatório de 12 bytes; ambos são escritos em claro à cabeça do ficheiro .enc, seguidos do texto cifrado e de uma etiqueta de autenticação de 128 bits. A sobrecarga medida é constante: 44 bytes, de um ficheiro de 1 MB a um de 1 GB. Cifrar duas vezes o mesmo ficheiro com a mesma frase dá duas saídas diferentes. Inverter um bit do texto cifrado, ou um bit do nonce, faz a decifragem falhar em vez de devolver dados danificados em silêncio. É uma construção sólida, e não é aí que as pessoas erram. O erro está na entrega: o ficheiro cifrado e a frase-passe seguem o mesmo caminho. Um anexo cifrado mais «a palavra-passe é Marseille2019» no mesmo fio não é cifragem, é um adiamento — quem ler a caixa de correio tem as duas metades. Um segundo canal é outro meio, idealmente noutro aparelho e noutra conta: o ficheiro por e-mail, a frase dita em voz alta ao telefone. E como o contentor .enc não tem cabeçalho nenhum — os primeiros bytes são o sal em bruto —, nada de padrão o abre: quem o recebe precisa da mesma ferramenta. Se a frase-passe se perder, o ficheiro perde-se com ela. É o desenho a funcionar, não uma falha.
A cifragem é a metade fácil. Eis exatamente o que a ferramenta faz ao seu ficheiro — cifra, derivação de chave, sal, nonce — e porque é que um anexo cifrado com a palavra-passe no mesmo fio não protege nada.
O que a ferramenta faz realmente ao seu ficheiro
Vale a pena ser preciso, porque «AES-256» num botão não diz quase nada — as mesmas três letras cobrem construções excelentes e construções partidas. Esta chama a implementação WebCrypto do próprio navegador em modo AES-GCM, ou seja, cifragem autenticada: não esconde apenas o conteúdo, prova também que o conteúdo não foi alterado. A chave tem 256 bits. A etiqueta de autenticação tem 128 bits, e pode confirmá-lo sem ler uma linha de código: um texto simples de 71 bytes deu um cifrado de 87 bytes, exatamente os dezasseis bytes extra que a RFC 5116 fixa para AES-256-GCM.
Uma frase-passe não é uma chave: é preciso transformá-la numa. A ferramenta usa PBKDF2-HMAC-SHA256 ao longo de 150 000 iterações, com um sal de 16 bytes tirado da fonte aleatória criptográfica do navegador. O sal é novo em cada cifragem, o que impede que uma tabela pré-calculada cubra vários ficheiros de uma vez. O nonce tem 12 bytes e também muda de cada vez — confirmado cifrando duas vezes o mesmo ficheiro com a mesma frase e comparando: sal diferente, nonce diferente, cifrado diferente. Ambos ficam guardados em claro à cabeça da saída, e isso está certo, não é desleixo. Um sal e um nonce não são segredos; só têm de ser únicos, e quem decifra precisa deles para reconstruir a chave.
A metade de autenticação não é enfeite. Inverta um único bit em qualquer ponto do cifrado e a decifragem recusa; inverta um único bit do nonce guardado e também recusa; dê-lhe uma frase-passe que difira numa maiúscula e recusa. Em todos os casos recebe um erro, nunca um ficheiro cheio de lixo com aspeto plausível. Essa distinção conta mais do que parece: um modo sem autenticação, como AES-CBC sem um controlo de integridade à parte, devolve dados danificados sem se queixar, e um atacante capaz de alterar o ficheiro em trânsito consegue por vezes orientar esse dano.
O erro que toda a gente comete: a chave viaja com o ficheiro
A forma é esta. Cifra a folha de salários, anexa o ficheiro .enc a um e-mail e — porque o destinatário obviamente precisa dela — escreve a frase-passe na mesma mensagem. Ou numa mensagem seguinte, o que parece mais prudente e não é. Ou numa resposta no mesmo fio, o que é pior, porque agora as duas metades estão numa só conversa que qualquer pesquisa trará junta. Seja qual for a variante, pôs uma fechadura e colou a chave na porta.
Se «mando numa segunda mensagem» não resulta, é porque não muda quem pode ler. A cifragem em trânsito não é o modelo de ameaça aqui — o correio entre grandes fornecedores já vai cifrado no fio. Aquilo de que se está realmente a defender é de alguém que lê a caixa: uma conta comprometida, um telemóvel deixado desbloqueado, um endereço de família partilhado, uma entidade patronal com acesso legal ao arquivo, uma cópia de segurança fugida, um fio reencaminhado que apanhou um destinatário a mais. Cada um desses casos expõe a segunda mensagem exatamente como a primeira. Duas mensagens na mesma caixa são um único canal usado duas vezes.
O que é realmente um segundo canal
Um segundo canal tem de diferir naquilo que realmente falha. Vale a pena separar três eixos. Um meio diferente — e-mail contra voz contra papel — para que um protocolo comprometido não entregue as duas metades. Uma conta diferente — a sua caixa profissional contra uma mensagem pessoal — para que uma única credencial não abra ambas. E um aparelho diferente, para que um telemóvel roubado ou infetado não guarde o ficheiro e a frase-passe lado a lado. Envie o ficheiro de um portátil e a frase pela aplicação de mensagens do mesmo portátil, e terá movido a chave para o outro lado da secretária, não para fora da sala.
É por isso que uma frase-passe ditada ao telefone é realmente melhor, e não apenas antiquada. Não deixa cópia: nenhuma mensagem para pesquisar mais tarde, nenhuma cópia de segurança que fuja, nenhum fio reencaminhado por engano, nenhum arquivo que um administrador possa abrir daqui a dois anos. Intercetá-la exige estar na linha no momento exato em que é dita, um ataque muito mais estreito e muito mais caro do que ler uma caixa de correio com calma. Traz ainda algo que nenhum canal dá sozinho: reconhece a voz, portanto sabe quem recebeu. Dite devagar, use o alfabeto NATO para o que for ambíguo e peça que lha repitam.
O que se esquece: quem recebe tem de conseguir abri-lo
Um ficheiro cifrado que ninguém consegue decifrar do outro lado não é segurança, é uma entrega falhada — e a reparação habitual é pior do que o problema original, porque acaba com alguém a reenviar o ficheiro sem cifra «só desta vez». Verifique portanto a outra ponta antes de enviar. O ficheiro .enc que esta ferramenta produz não tem cabeçalho nenhum: os primeiros bytes são o sal aleatório em bruto, sem número mágico, sem versão, sem nome de algoritmo e sem o nome do ficheiro original. É uma disposição feita à medida. Não é um ZIP, nem uma mensagem OpenPGP, nem um ficheiro age, nem a saída do openssl enc — e nenhum deles o abrirá.
A consequência prática é boa, no entanto: como a ferramenta corre inteiramente no navegador, quem recebe não tem de instalar nada, criar conta nem confiar o ficheiro a um servidor. Abre a mesma página, carrega o ficheiro .enc, escreve a frase-passe e carrega em decifrar, e o texto simples aterra nas suas transferências. Nada é enviado, em nenhum sentido. Portanto a frase a juntar ao ficheiro não é a pista da palavra-passe — é que página abrir. E essa frase mande-a pelo mesmo canal do ficheiro, já que não é segredo; só a frase-passe muda de via.
Quando a frase-passe se perde
Nada pode ser feito. Nem pelo sítio, nem por um apoio, nem por si. Não existe conta que guarde uma cópia, nem chave de recuperação, nem depósito, nem porta das traseiras — a chave nunca existiu fora da memória do separador que a fabricou, e era derivada da frase-passe no momento. Perca a frase e o ficheiro é um bloco de ruído que continuará ruído. Vale a pena dizê-lo com clareza, porque se assume por omissão que existe um caminho de recuperação, como para a palavra-passe de um webmail.
E isso é o desenho a funcionar, não a falhar. Um caminho de recuperação é por definição uma segunda entrada, e uma segunda entrada é algo por onde um atacante também pode passar — ou que um tribunal pode obrigar alguém a abrir. A resposta certa não é desejar uma porta das traseiras, mas guardar a frase-passe algures duradouro antes de precisar dela: uma ficha do gestor de palavras-passe ligada ao nome do ficheiro, ou papel numa gaveta se o ficheiro ainda contar daqui a cinco anos. Escolha uma frase que consiga ditar, porque provavelmente terá de o fazer. Quatro ou cinco palavras sem relação ganham a uma única palavra torcida nos dois planos: é mais forte e sobrevive a ser lida em voz alta.
Uma fraqueza honesta: o número de iterações
Não é a cifra o elo mais fino aqui, é a derivação de chave. O PBKDF2 existe para encarecer a adivinhação, e o seu custo é fixado pelo número de iterações. Esta ferramenta usa 150 000. A OWASP Password Storage Cheat Sheet, a referência de onde parte a maioria dos defensores, recomenda hoje 600 000 para PBKDF2-HMAC-SHA256. O número publicado é um quarto disso, o que multiplica por quatro o débito de um atacante que adivinha fora de linha. Medido num núcleo, 150 000 iterações levam cerca de 36 milissegundos por tentativa: um núcleo comum experimenta aproximadamente 28 frases por segundo; hardware especializado vai muito mais longe, e o PBKDF2 é-lhe mais favorável do que uma função exigente em memória como o Argon2id.
Isto não torna a ferramenta insegura, e não muda nada na cifra, no sal nem no nonce, que estão certos. Desloca a origem da segurança: com uma derivação mais leve, o peso recai mais sobre a própria frase-passe. Uma frase de quatro palavras tiradas ao acaso de uma lista grande fica fora de alcance nos dois casos; uma palavra do dicionário com um número no fim nunca esteve protegida pelo número de iterações. Escolha a frase como se não houvesse esticamento nenhum, e a diferença entre 150 000 e 600 000 deixa de lhe dizer respeito.
| O ficheiro vai por | A frase-passe vai por | Realmente separado? | O que um atacante precisa |
|---|---|---|---|
| Anexo de e-mail | A mesma mensagem | Não | Ler a caixa de correio uma vez |
| Anexo de e-mail | Segunda mensagem, mesmo endereço | Não | Ler a caixa de correio uma vez |
| Ligação partilhada na nuvem | Comentário no mesmo ficheiro | Não | A conta na nuvem |
| Anexo de e-mail | Mensagem escrita para um telemóvel | Em parte | A caixa de correio e o telemóvel — mas uma cópia do telemóvel pode ter ambos |
| Anexo de e-mail | Dita em voz alta ao telefone | Sim | A caixa de correio mais estar na linha nesse momento |
| Ligação partilhada na nuvem | Mensagens cifradas ponta a ponta, outra conta | Sim | Duas contas distintas em dois serviços |
| Entregue numa pen USB | Dita em pessoa, nada escrito | Sim | Acesso físico a ambos, ao mesmo tempo |
Perguntas frequentes
- AES-256-GCM basta por si só?
- Para a cifragem em si, sim — é um modo autenticado padrão e a implementação do navegador é a mesma que serve o HTTPS. Mas uma cifra só protege o que a chave protege. Aqui a chave deriva da sua frase-passe, portanto o verdadeiro tecto de solidez é a frase, e a verdadeira falha é enviá-la pelo mesmo canal do ficheiro. O AES-256-GCM não pode nada por nenhuma das duas.
- Porque está o sal à vista no início do ficheiro?
- Porque não é segredo e nunca teve de o ser. Um sal existe para que a mesma frase-passe produza uma chave diferente de cada vez, o que impede que uma tabela pré-calculada ataque muitos ficheiros de uma vez. Só tem de ser único, não escondido. O mesmo vale para o nonce. Quem decifra precisa dos dois para reconstruir a chave, portanto têm de viajar com o cifrado — escondê-los significaria cifrá-los, o que exigiria uma chave, e voltamos ao início.
- Posso enviar a frase-passe numa segunda mensagem?
- Não, e é a versão mais comum do erro. Duas mensagens para o mesmo endereço caem na mesma caixa, no mesmo arquivo e na mesma cópia de segurança. Quem puder ler uma pode ler a outra, e uma pesquisa pelo nome do remetente traz as duas lado a lado. Não é um segundo canal, é o mesmo canal usado duas vezes. Mude de meio — a voz, ou uma aplicação de mensagens noutra conta — ou a cifragem só compra o tempo de rolar o ecrã.
- Quem recebe pode abrir o .enc com o 7-Zip, o GPG ou o openssl?
- Não. O contentor é uma disposição feita à medida — 16 bytes de sal, 12 de nonce, depois o cifrado e a etiqueta — sem número mágico, sem byte de versão e sem identificador de algoritmo, portanto nenhuma ferramenta padrão o consegue sequer reconhecer. Quem recebe abre a mesma página no seu navegador, carrega o ficheiro, escreve a frase-passe e carrega em decifrar; nada se instala e nada se envia. Diga-lhe que página abrir na mesma mensagem do ficheiro. Essa parte não é segredo.
- Perdi a frase-passe — não há mesmo nada a fazer?
- Mesmo nada. A chave existiu apenas dentro do separador que a criou, derivada da frase-passe no momento da cifragem; não fica cópia em lado nenhum, com ninguém. Não há chave de recuperação, nem depósito, nem via de apoio, e essa ausência é deliberada: qualquer caminho de recuperação é uma segunda entrada, que um atacante também poderia usar. Se se lembra da frase por alto, tentar variantes à mão é a sua única hipótese, e cada tentativa custa cerca de um vigésimo de segundo.
Artigos que podem interessar-lhe
Todos os guias →Ferramentas relacionadas
A cifra, a derivação de chave, o sal, o nonce e a estrutura do contentor aqui descritos foram lidos no código da ferramenta e confirmados executando-a em agosto de 2026; o software muda, por isso confirme antes de se apoiar num número concreto. Isto é orientação geral para gerir os seus próprios ficheiros, não uma auditoria de segurança da sua organização, e os dados regulados ou classificados regem-se por regras que nenhuma ferramenta de navegador consegue satisfazer sozinha.
Fontes
- IETF — RFC 5116 — An Interface and Algorithms for Authenticated Encryption (AEAD_AES_256_GCM: 12-byte nonce, 16-byte tag)
- NIST — SP 800-38D — Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC
- OWASP — Password Storage Cheat Sheet — PBKDF2-HMAC-SHA256 iteration guidance
- W3C — Web Cryptography API — AES-GCM and PBKDF2
Detetaste um erro neste artigo?