Criptografar e descriptografar texto com uma frase secreta

O que acontece quando você aperta Criptografar

Quatro etapas, todas dentro da implementação de Web Crypto do seu navegador e não em JavaScript:

• Dezesseis bytes aleatórios são gerados como sal, e mais doze como o IV — o nonce de que o AES-GCM precisa.
• Sua frase secreta é esticada até uma chave de 256 bits com PBKDF2-HMAC-SHA-256, 250.000 rodadas, usando esse sal.
• O texto é codificado em UTF-8 e criptografado com AES-256-GCM, que produz o texto cifrado mais uma tag de autenticação de 16 bytes.
• O sal, o IV, o número de rodadas e o texto cifrado são empacotados juntos e codificados em base64, então o conjunto inteiro aguenta um copiar e colar em um e-mail.

A descriptografia lê os parâmetros de volta de dentro do bloco, então você só precisa da frase secreta.

O formato de saída, byte a byte

Aqui não há nada proprietário, e um formato que você não consegue abrir em outro lugar não protege muita coisa. Depois de decodificar o bloco de base64 você tem:

• Byte 0 — a versão do formato, hoje 1.
• Bytes 1 a 4 — o número de rodadas do PBKDF2, inteiro de 32 bits big-endian.
• Bytes 5 a 20 — o sal de 16 bytes.
• Bytes 21 a 32 — o nonce GCM de 12 bytes.
• Do byte 33 em diante — o texto cifrado AES-256-GCM com a tag de 16 bytes no final, que é o layout que o Web Crypto produz.

O número de rodadas viaja junto com o bloco para que esse número possa ser aumentado mais tarde sem quebrar nada do que foi criptografado hoje. Na volta ele é conferido contra um intervalo aceitável, porque senão um bloco vindo de um estranho poderia pedir ao seu navegador um bilhão de rodadas e travar a aba.

Por que o mesmo texto gera um bloco diferente a cada vez

Um sal novo e um nonce novo são gerados para cada mensagem, então criptografar a mesma frase duas vezes com a mesma frase secreta produz dois blocos sem relação entre si. Esse é o comportamento correto. Uma saída idêntica contaria a um observador que duas mensagens são iguais sem que ele lesse nenhuma delas.

Também importa que o nonce nunca seja reutilizado com a mesma chave. O GCM é excepcionalmente frágil aqui: repita um nonce e um atacante consegue recuperar o XOR de dois textos claros e, pior, deduzir o valor usado para autenticar mensagens, o que permite forjar blocos. Nonces aleatórios por mensagem, com uma chave nova derivada de um sal novo, mantêm isto bem longe da zona de perigo.

Por que GCM e não CBC

A maioria das ferramentas de "criptografia AES" usa AES-CBC sem autenticação. A criptografia por si só esconde o conteúdo, mas não detecta alterações: inverta alguns bits em um texto cifrado com CBC e ele continua descriptografando, virando outra coisa, sem reclamar. É por essa porta que entram os ataques de padding oracle. O GCM produz uma tag de autenticação junto do texto cifrado, então um único byte alterado faz a descriptografia falhar de vez. Se você vir "Não foi possível descriptografar", o bloco realmente não passou na verificação.

Onde isto fica devendo

A frase secreta é tudo. PBKDF2 com 250.000 rodadas faz cada tentativa custar trabalho de verdade, mas um atacante com o bloco em mãos testa combinações offline, em paralelo, em hardware feito para isso, pelo tempo que quiser. Uma palavra de dicionário com um número atrás não sobrevive a isso. Quatro ou cinco palavras realmente aleatórias sobrevivem.

O PBKDF2 é a opção mais fraca entre as modernas. Argon2 e scrypt são memory-hard: exigem muita memória, o que corta a vantagem da GPU. O PBKDF2 não é, e contra ele um atacante com GPU leva muito mais vantagem. Os navegadores só expõem PBKDF2 pelo Web Crypto, e embutir uma build do Argon2 é exatamente o tipo de dependência que este site não inclui. Isso é uma limitação real, não uma preferência.

Prova integridade, não identidade. Um bloco que descriptografa não foi modificado por ninguém sem a frase secreta. Ele não prova quem o escreveu, porque qualquer pessoa com a frase secreta pode escrever um. Para mensagens entre pessoas, ferramentas feitas para isso — age, GPG, Signal — cobrem a parte que esta não cobre.

Só texto. Não existe modo de arquivo. Criptografar um arquivo significa lê-lo inteiro na memória e te entregar um download, e para qualquer coisa de tamanho razoável uma ferramenta de desktop faz isso melhor.

Duas notas práticas. Mandar a frase secreta pelo mesmo canal do bloco põe tudo a perder. E o resultado passa pela sua área de transferência, que outros aplicativos da máquina muitas vezes conseguem ler.

Perguntas frequentes

Isto é realmente seguro?

A criptografia é padrão e roda na implementação nativa do navegador: AES-256-GCM com uma chave esticada a partir da sua frase secreta pelo PBKDF2-HMAC-SHA-256 ao longo de 250.000 rodadas e com um sal aleatório. O ponto fraco nunca é o algoritmo, é a frase secreta. Uma frase curta ou previsível pode ser quebrada por força bruta offline por melhor que seja a cifra.

O que acontece se eu esquecer a frase secreta?

O texto fica irrecuperável. Não há custódia de chaves, não há redefinição e não há cópia de nada em lugar nenhum: a página não guarda estado e não existe servidor por trás. Anote a frase secreta em algum lugar antes de depender do bloco.

Por que criptografar o mesmo texto duas vezes gera uma saída diferente?

Porque um novo sal e um novo nonce aleatórios são gerados a cada vez. Um texto cifrado idêntico vazaria o fato de que duas mensagens são iguais, então isto é um recurso, não uma falha.

Dá para descriptografar isto com OpenSSL ou Python?

Não com um único comando do OpenSSL, porque o sal, o nonce e o número de rodadas ficam em um cabeçalho próprio. O layout está documentado acima, e umas dez linhas de Python com o pacote cryptography dão conta: extraia os campos, rode o PBKDF2 e depois abra o resto com AES-GCM.

Posso criptografar um arquivo em vez de texto?

Aqui não. Esta ferramenta lida só com texto. Para arquivos, use age ou GPG no desktop, ou um arquivo compactado protegido por senha se o destinatário não tiver mais nada instalado.

Última atualização 19 de setembro de 2026