Texto simples

Usa AES-256-GCM via a Web Crypto API. Um IV aleatório de 96 bits e um salt de 128 bits são gerados a cada criptografia. A senha é derivada via PBKDF2 (100 000 iterações, SHA-256).

Como usar

1. Escolha o modo Criptografar ou Descriptografar.
2. Insira seu texto e uma senha.
3. Clique no botão de ação · o resultado aparece abaixo.
4. Para descriptografar, cole a saída criptografada e use a mesma senha.

Perguntas frequentes

Esta criptografia é segura ?

Sim. AES-256-GCM é uma cifra de qualidade militar. Combinada à derivação de chave PBKDF2 (100 k iterações), oferece proteção robusta. A segurança depende, no entanto, da força da sua senha.

Vocês podem recuperar minha senha ?

Não. Tudo é executado no seu navegador. Nunca vemos seu texto nem sua senha. Se você perder sua senha, o texto criptografado não pode ser recuperado.

Qual é o formato da saída ?

A saída criptografada é uma string Base64 que contém o salt, o IV e o texto cifrado. Basta colá-la de volta na ferramenta para descriptografar.

O que realmente acontece quando você clica em Criptografar

Cifras simétricas como o AES usam a mesma chave para criptografar e descriptografar. Isso significa que quem tem a chave pode tanto trancar quanto destrancar os dados, então todo o desafio de usar uma se reduz a uma única pergunta: como o remetente e o destinatário compartilham a chave sem vazá-la? A resposta desta ferramenta é «você cuida disso por conta própria»: combinem uma senha por um canal confiável separado e, depois, os dois colam a mesma string aqui.

Nos bastidores, a ferramenta executa quatro etapas por meio da Web Crypto API nativa do navegador:

1. Estique sua senha até virar uma chave. Uma senha é uma string curta e de baixa entropia; uma chave AES-256 são 32 bytes de dados aleatórios de alta entropia. A ferramenta passa sua senha por PBKDF2-HMAC-SHA-256 com 100.000 iterações (especificado na RFC 8018) mais um salt aleatório de 128 bits. O salt faz cada criptografia produzir uma chave diferente, mesmo que você reutilize a senha, eliminando os ataques de rainbow table. A contagem de iterações desacelera a adivinhação por força bruta a cada tentativa.
2. Gere um nonce novo. Um IV aleatório de 96 bits (o comprimento recomendado pelo NIST para o AES-GCM) é criado via crypto.getRandomValues: a mesma fonte de aleatoriedade criptograficamente segura que o navegador usa para o TLS.
3. Criptografe com AES-256-GCM. O texto em claro é codificado como bytes UTF-8 e passado pelo AES-256 no Galois/Counter Mode, que produz o texto cifrado mais uma tag de autenticação de 128 bits.
4. Empacote e codifique em Base64. O salt, o IV e o texto cifrado+tag são concatenados em um único blob binário e codificados em Base64 para que viaje com segurança por e-mail, chat ou qualquer outro lugar que espere ASCII.

Por que AES-256-GCM, especificamente

O AES (Advanced Encryption Standard) é a cifra simétrica que o NIST escolheu em 2000 a partir de uma competição pública com 15 candidatos. O projeto vencedor foi o Rijndael, dos criptógrafos belgas Joan Daemen e Vincent Rijmen, formalizado como FIPS PUB 197 em 26 de novembro de 2001. O NIST aprova três tamanhos de chave (128, 192, 256 bits) e a NSA aprova os três para dados SECRET, com o AES-256 também aprovado para TOP SECRET. Depois de mais de duas décadas de escrutínio público, ainda não há ataque prático contra um AES corretamente implementado: a cifra em si é essencialmente inquebrável, então o argumento de segurança se desloca inteiramente para o gerenciamento de chaves e a força da senha.

Uma cifra de bloco como o AES só criptografa um bloco de tamanho fixo de 128 bits, então qualquer mensagem real precisa de um modo de operação para colar os blocos uns aos outros. O modo importa tanto quanto a cifra. O notório padrão antigo, o ECB, criptografa cada bloco de forma independente, o que vaza padrões; a famosa imagem do «Pinguim ECB», o Tux ainda reconhecível depois da criptografia, é a ilustração de advertência padrão. Muitas ferramentas «AES» on-line mais antigas ainda expõem o ECB; esta não.

O GCM (Galois/Counter Mode), projetado por McGrew e Viega e padronizado pelo NIST na SP 800-38D (novembro de 2007), combina a criptografia em modo contador com uma tag de autenticação de campo de Galois. É um modo AEAD (Authenticated Encryption with Associated Data), o que significa que fornece confidencialidade e integridade em uma única operação. Se um único byte da saída criptografada for invertido, a descriptografia gera um erro em vez de retornar um texto em claro corrompido. É o mesmo modo que o TLS 1.2 e o TLS 1.3 usam. É genuinamente o modo cavalo de batalha da criptografia moderna da internet.

Uma senha não é uma chave

Uma chave AES-256 são 32 bytes de aleatoriedade uniforme. A senha de um usuário (mesmo uma forte) é curta, em sua maioria ASCII imprimível, e se agrupa em torno de padrões de dicionário. Você não pode alimentar o AES diretamente com uma senha sem ajuda. Essa ajuda é uma função de derivação de chave baseada em senha (KDF). PBKDF2, scrypt e Argon2 são as três que você verá em código moderno:

• PBKDF2 (RFC 8018), o original. Itera uma função pseudoaleatória HMAC muitas vezes. Rápido em uma CPU, mas não é memory-hard: GPUs e ASICs quebram hashes de PBKDF2 muito mais rápido do que a contagem de iterações sugeriria em um computador normal. Esta ferramenta usa o PBKDF2 porque é o único KDF de senha que a Web Crypto API expõe nativamente; Argon2 e scrypt exigiriam distribuir JavaScript ou WebAssembly extra.
• scrypt (RFC 7914, 2016, por Colin Percival) acrescentou a dureza de memória: força um atacante a alocar um grande bloco de RAM por tentativa, derrotando hardware paralelo barato.
• Argon2id (RFC 9106, 2021), vencedor da Password Hashing Competition de 2015; a recomendação de primeira escolha atual da OWASP. Memory-hard, resistente a canais laterais.

Ressalva honesta: 100.000 iterações de PBKDF2 está bem acima do piso original da RFC, de 1.000, mas abaixo da orientação atual da OWASP para 2026, de 600.000 para PBKDF2-SHA-256. O custo é o tempo de criptografia em celulares lentos: a 600.000 iterações, derivar uma chave em um aparelho Android básico começa a acrescentar uma pausa perceptível. Para segredos de longo prazo e alto risco, escolha uma senha mais longa para compensar, ou use um gerenciador de senhas dedicado, que normalmente usa o Argon2id com parâmetros mais fortes.

Salt e IV: parecem parecidos, fazem coisas diferentes

• O Salt é entrada para a derivação de chave. Ele torna o mapeamento senha→chave único por criptografia, de modo que um texto cifrado roubado não pode ser quebrado usando uma tabela pré-computada de chaves de senhas comuns. O salt não precisa ser secreto, apenas único e imprevisível.
• O IV / nonce é entrada para o modo da cifra. Para o AES-GCM especificamente, é o ponto de partida do contador de 96 bits. Ele deve ser único por par (chave, mensagem); reutilizar um é catastrófico no GCM, pois permite que um atacante recupere a chave GHASH e forje textos cifrados arbitrários. A ferramenta gera um IV aleatório novo a partir de crypto.getRandomValues a cada criptografia, o que evita esse risco.

Quando usar isto, e quando não

A ferramenta certa quando:

• Você precisa compartilhar uma única mensagem secreta por um canal não confiável (e-mail, Slack, SMS, um aplicativo de notas) e tem um canal confiável separado (uma ligação telefônica, um encontro presencial, uma conversa no Signal) por onde pode entregar a senha.
• Você quer criptografar um trecho localmente antes de colá-lo em um documento na nuvem ou em um aplicativo de anotações, para que, mesmo que o provedor seja invadido, o conteúdo fique ilegível.
• Você precisa de um «envelope lacrado» anexado a um fluxo de trabalho com um parceiro que combinou uma senha verbalmente.

A ferramenta errada quando:

• Você e seu destinatário não têm segredo pré-compartilhado nem canal fora de banda. Enviar a senha pelo mesmo canal que o texto cifrado é inútil: qualquer um que consiga ler o texto cifrado consegue ler a senha também. Esse é o clássico problema do ovo e da galinha na distribuição de chaves, que a criptografia de chave pública existe para resolver.
• Você precisa de forward secrecy. O Signal e o TLS 1.3 produzem uma chave efêmera diferente para cada sessão, então um vazamento hoje não expõe mensagens passadas. Uma única senha fixa dá a propriedade oposta: qualquer um que descubra a senha pode descriptografar todas as mensagens que você já criptografou com ela.
• Você precisa provar quem criptografou algo. O AES com uma senha compartilhada prova a posse da senha, não a autoria. Para assinaturas digitais, use PGP, age ou S/MIME.
• Você está criptografando em escala ou para muitos destinatários. Cada destinatário precisa de uma senha compartilhada separadamente e a rotação é dolorosa. Ferramentas assimétricas (age, PGP) e servidores de chaves no estilo do Signal lidam melhor com isso.

Um modelo mental útil: o AES com senha é o equivalente digital de um cadeado de mala combinado com uma ligação telefônica para compartilhar a combinação. Funciona perfeitamente se você puder confiar na ligação. Não é um substituto para mensagens criptografadas de ponta a ponta como o Signal, que automatiza a troca de chaves e fornece forward secrecy por meio de seu protocolo Double Ratchet.

Quão forte é «forte o suficiente» para a senha?

Como a cifra em si é inquebrável, toda a segurança do esquema se apoia na sua senha. A matemática relevante é a entropia: H = L × log₂(N), em que L é o comprimento e N é o tamanho do conjunto de caracteres do qual você sorteia ao acaso. Exemplos resolvidos:

• 8 letras minúsculas aleatórias → cerca de 37 bits. Quebrável em horas em uma GPU moderna.
• 8 caracteres de caixa mista com dígitos e símbolos → cerca de 52 bits. De horas a dias nas velocidades modernas.
• 12 caracteres de caixa mista com dígitos e símbolos → cerca de 79 bits. Além dos orçamentos práticos de ataque no futuro previsível.
• Seis palavras aleatórias de uma lista Diceware de 7.776 palavras → cerca de 78 bits. Praticamente a mesma segurança que 12 caracteres aleatórios, mas muito mais fácil de memorizar.

Senhas escolhidas por humanos são drasticamente mais fracas: pesquisas citadas nas orientações do NIST estimam a média em torno de 40 bits, e é por isso que os ataques de dicionário predominam sobre a força bruta pura. O conselho atual da NIST SP 800-63B para segredos memorizados: no mínimo 8 caracteres, permitir ao menos 64, não impor regras de composição (elas empurram os usuários para padrões previsíveis como Password1!), não exigir rotação periódica e filtrar em relação a listas de senhas sabidamente vazadas. Busque algo «longo, memorável, que nunca apareceu em um vazamento». Uma frase secreta aleatória de quatro a seis palavras que você realmente consiga lembrar vence uma senha «complexa» de 8 caracteres torturada toda vez.

Onde ela se posiciona em relação a outras ferramentas de criptografia

• TLS / HTTPS criptografa em trânsito entre você e um servidor. O próprio servidor pode ler tudo assim que chega. Resolve o problema do bisbilhoteiro, não o problema do servidor.
• Signal / WhatsApp / iMessage são criptografia completa de ponta a ponta, com troca automática de chaves e forward secrecy. Resolvem os dois, mas exigem que as duas partes usem o mesmo aplicativo.
• PGP / age são assimétricos: você criptografa para a chave pública publicada de alguém sem precisar de um segredo compartilhado antes. Resolve a distribuição de chaves, mas historicamente é doloroso de usar; o age é a alternativa minimalista moderna.
• A criptografia de disco no nível do SO (FileVault, BitLocker, LUKS) criptografa os dados em repouso em um único dispositivo usando AES-XTS. Modelo de ameaça diferente: protege contra o roubo do dispositivo, não contra a interceptação de rede.
• Os gerenciadores de senhas usam AES-GCM (ou similar) com KDFs fortes (normalmente Argon2id hoje) dentro de um cofre criptografado que sincroniza o texto cifrado por um backend do fornecedor que não consegue lê-lo.

Um criptografador de texto baseado em senha é o membro menos especializado desta família: criptografia pura, sem opinião sobre identidade, transporte ou armazenamento. Esse minimalismo é o atrativo: é a ferramenta certa quando você precisa especificamente apenas de AES-256 com uma senha e nada mais.

Mais perguntas

Isto é criptografado de ponta a ponta?

Em certo sentido, sim: a criptografia acontece inteiramente no seu navegador e o Absolutool nunca vê o texto em claro nem a senha. No sentido estrito que produtos de mensagens como o Signal usam, não: o Signal fornece adicionalmente a troca automática de chaves assimétricas e a vinculação de identidade, de modo que os usuários não precisam de um canal confiável separado para compartilhar uma senha. Esta ferramenta faz a metade da criptografia sem esses extras, o que é justamente o que torna a entrega da senha responsabilidade sua.

Existe uma recuperação de «esqueci a senha»?

Não, por design. A ferramenta nunca vê sua senha e nunca armazena nada. Se você perder a senha, o texto criptografado é irrecuperável. Salve a senha em um gerenciador de senhas ou anote-a em algum lugar físico.

Por que a saída criptografada parece um Base64 aleatório?

Porque é exatamente isso que ela é. O salt, o IV e o texto cifrado mais a tag de autenticação são concatenados em um único blob binário e codificados em Base64 para que o resultado viaje com segurança por sistemas que esperam ASCII imprimível (e-mail, JSON, query strings). Os três componentes são necessários no momento da descriptografia, e é por isso que são empacotados juntos; a ferramenta os reextrai quando você cola o blob de volta.

O AES-256 é ilegal em algum lugar?

A criptografia de mercado de massa é amplamente legal em essencialmente todo produto voltado ao consumidor no mundo, em 2026. As Crypto Wars dos EUA dos anos 1990 terminaram com a Ordem Executiva 13026 (1996) e o afrouxamento para o mercado de massa em 2000. Destinos específicos sob embargo (Irã, Coreia do Norte, Síria, Cuba) e um punhado de países com suas próprias restrições de importação ou uso de criptografia forte (China, Rússia, Vietnã e Arábia Saudita, entre eles) ainda valem a verificação em relação à lei local se você estiver usando a ferramenta nessas jurisdições.

Algo é enviado a um servidor?

Não. A Web Crypto API roda nativamente no navegador; o crypto.subtle chama a mesma biblioteca de criptografia que o navegador usa para o TLS (BoringSSL no Chrome, NSS no Firefox, CommonCrypto no Safari). Nada sai do seu dispositivo. A página também exige HTTPS, o que é imposto pelo navegador: a Web Crypto só está disponível em contextos seguros para impedir que um atacante de rede troque o JavaScript antes que ele rode.

Ferramentas relacionadas