tools / aes
aes/
Criptografia e descriptografia simétrica AES. Modo, preenchimento, formato da chave e do IV e codificação são configuráveis, os resultados batem com Java e CryptoJS, e sua chave nunca sai do navegador.
Texto simples
Texto cifrado
Histórico
Cada criptografia ou descriptografia bem-sucedida é salva automaticamente. Os últimos 20 registros ficam guardados apenas no navegador deste dispositivo. As chaves nunca são salvas, mas o IV e o texto simples descriptografado são; em um computador compartilhado, limpe o histórico ao terminar.
AES, DES e RSA: o que são e quais as diferenças
AES e DES são cifras simétricas: a mesma chave criptografa e descriptografa, como uma chave que tanto tranca quanto destranca a porta. São rápidas e servem para grandes volumes de dados; a dificuldade é entregar essa chave ao outro lado com segurança.
O DES é um padrão antigo, da década de 1970, com chave efetiva de apenas 56 bits, que hoje pode ser quebrada por força bruta com hardware dedicado ou clusters de computadores; só serve para se comunicar com sistemas legados que ainda o usam. O AES substituiu o DES como padrão. Usa chaves de 128, 192 ou 256 bits, não tem nenhum ataque prático conhecido hoje e é a escolha padrão para criptografar dados.
O RSA é assimétrico: existe um par de chaves. A chave pública pode ser dada a qualquer pessoa e serve para criptografar; a chave privada fica com você e serve para descriptografar, como uma caixa de correio em que qualquer um pode deixar cartas, mas só você consegue abrir. Não é preciso combinar uma chave antes, mas o RSA é lento e só criptografa algumas centenas de bytes por vez. Sistemas reais costumam combinar os dois: o RSA criptografa uma chave AES gerada aleatoriamente para o outro lado, e o AES criptografa os dados de fato.
O que é um modo de operação e qual usar?
O AES criptografa 16 bytes por vez; o modo define como dados maiores são divididos em blocos e como os blocos se relacionam. O ECB criptografa cada bloco separadamente, então conteúdos idênticos geram textos cifrados idênticos e vazam padrões; evite. O CBC mistura cada bloco com o bloco cifrado anterior antes de criptografar, e o primeiro bloco com o IV; é a escolha mais comum. CFB, OFB e CTR transformam o AES em um fluxo de chave que sofre XOR com os dados byte a byte, então não precisam de preenchimento. O GCM acrescenta uma tag de autenticação ao CTR, de modo que um texto cifrado adulterado falha ao descriptografar; é o modo recomendado hoje.
Para que servem o IV e o preenchimento?
O IV (vetor de inicialização) faz o mesmo conteúdo ser criptografado de forma diferente a cada vez. Ele não precisa ser secreto e pode seguir junto com o texto cifrado, mas nunca o reutilize com a mesma chave, principalmente no GCM. Todos os modos, exceto o ECB, precisam de IV: no GCM recomendam-se 12 bytes, e os demais modos exigem exatamente 16 bytes.
ECB e CBC exigem que o tamanho dos dados seja múltiplo de 16 bytes, então dados menores são completados conforme o preenchimento escolhido. PKCS5Padding e PKCS7Padding são idênticos para o AES e são os mais comuns. O ZeroPadding completa com zeros e remove todos os bytes zero finais ao descriptografar, então um texto simples que já termine em bytes zero os perde. O NoPadding não acrescenta nada, e você mesmo precisa acertar o tamanho. O GCM não usa preenchimento.
Equivalência com Java e CryptoJS
O Cipher.getInstance("AES/CBC/PKCS5Padding") do Java significa CBC com PKCS5Padding; apenas "AES" usa por padrão ECB com PKCS5Padding. No Java, CTR e GCM só funcionam com NoPadding, e a tag do GCM deve ter de 96 a 128 bits. O CryptoJS.pad.Pkcs7 do CryptoJS é o PKCS7Padding, e ZeroPadding, AnsiX923, Iso10126 e Iso97971 têm o mesmo nome. Se você passar uma senha em string para CryptoJS.AES.encrypt, ele deriva a chave sozinho e gera um resultado que começa com U2FsdGVkX1; esse uso não é suportado aqui, então informe uma chave de 16, 24 ou 32 bytes e um IV.
O que são a tag e o AAD do GCM?
A tag é o valor de verificação calculado pelo GCM; são os últimos bytes do texto cifrado (16 bytes para uma tag de 128 bits). O AAD são dados adicionais autenticados, como o cabeçalho de uma mensagem. Ele não é criptografado, mas entra na verificação, então você precisa informar o mesmo AAD ao descriptografar, senão a verificação falha.
Perguntas frequentes
O que fazer quando aparece "A chave tem N bytes" ou "O IV tem N bytes"?
Primeiro confira se o formato está certo: os mesmos 32 caracteres são 32 bytes no formato string, mas só 16 bytes em hex. A chave AES deve ter 16, 24 ou 32 bytes e, exceto em ECB e GCM, o IV deve ter exatamente 16 bytes; nada é completado com zeros nem cortado automaticamente, e a contagem atual de bytes aparece ao lado dos rótulos Chave e IV. No formato string, a contagem segue a codificação escolhida, então um caractere chinês ocupa 3 bytes em UTF-8. Se o seu back-end processa a senha antes, por exemplo completando com zeros ou aplicando um hash, calcule primeiro os bytes finais e informe-os em hex ou base64.
O que fazer quando a descriptografia diz que o preenchimento é inválido?
Significa que o último bloco descriptografado não segue a regra de preenchimento escolhida. Geralmente a chave, o IV, o modo ou o preenchimento é diferente do usado na criptografia, ou o texto cifrado foi copiado incompleto. Compare cada parâmetro com o lado que criptografou; um formato de chave ou de texto cifrado errado (hex em vez de base64, ou o contrário) causa o mesmo erro. ZeroPadding e NoPadding não verificam o preenchimento e, por isso, não geram esse erro, mas o resultado vira lixo se os parâmetros estiverem errados.
O início do texto descriptografado está ilegível, ou aparece que o resultado não é texto UTF-8 válido
Verifique o IV primeiro. Quando o texto cifrado tem mais de um bloco, um IV errado nos modos CBC e CFB estraga só o primeiro bloco de 16 bytes; o resto sai correto e nenhum erro de preenchimento aparece. Você vê caracteres ilegíveis no início e texto correto depois. Se a mensagem disser que o resultado não é texto válido, a codificação pode ser diferente da usada na criptografia, por exemplo, se o outro lado usou GBK. Definir o formato de saída como hex permite conferir primeiro os próprios bytes descriptografados.
O que fazer quando a descriptografia GCM diz que a verificação da tag falhou?
Significa que a chave, o IV, o AAD ou o comprimento da tag é diferente do usado na criptografia, ou que o texto cifrado foi alterado. Os últimos bytes da entrada são tratados como a tag, com o tamanho definido pela opção "Comprimento da tag" (128 bits por padrão, ou seja, 16 bytes), então o texto cifrado e a tag devem ser informados juntos; se o outro lado enviar a tag separada, anexe-a ao final do texto cifrado antes. O formato do AAD é hex por padrão, então mude-o ao informar conteúdo em string; se nenhum AAD foi usado na criptografia, deixe-o vazio ao descriptografar.
O resultado não bate com o de Java, Python ou outro back-end. Como investigar?
Confira nesta ordem: modo e preenchimento, formato e quantidade de bytes da chave e do IV, codificação e formatos de entrada e saída. O texto simples em formato string não é aparado, então uma quebra de linha extra no final gera outros dados. CTR, CFB e OFB também são completados conforme o preenchimento escolhido aqui, então com PKCS5Padding o texto cifrado fica maior que o texto simples; se o back-end usa NoPadding, escolha NoPadding aqui também. O CFB daqui é a variante de bloco completo de 128 bits, então não bate com um back-end que use CFB8.
O texto cifrado deve ser hex ou base64, e o que acontece se eu escolher errado?
Siga o que o outro lado produz: texto só com 0-9 e a-f é hex; texto com letras maiúsculas e minúsculas, +, / ou = no final é base64. Escolher errado ao descriptografar nem sempre falha na hora, porque todo caractere hex também é um caractere base64 válido; você só obtém os bytes errados, e isso aparece depois como "não é múltiplo de 16" ou preenchimento inválido. Base64 com - e _ (a forma segura para URL) ou sem o = final é aceito, e espaços, dois-pontos e prefixo 0x em hex são ignorados.
O que o histórico guarda e ele é enviado para algum lugar?
Fica só no localStorage do navegador deste dispositivo e nunca é enviado; o código da página não faz nenhuma requisição de rede. Um registro é adicionado a cada criptografia ou descriptografia bem-sucedida, até 20 são mantidos, e nada cuja entrada ou resultado passe de 20.000 caracteres é registrado. Cada registro guarda os parâmetros, o IV, o AAD, a entrada e o resultado, além de uma impressão digital de 8 caracteres derivada da chave (os caracteres depois do # em cada registro, que servem para saber se é a mesma chave), mas nunca a chave em si; por isso, depois de clicar em "Carregar", você precisa informar a chave de novo. Cada registro pode ser excluído individualmente e, em um computador compartilhado, clique em "Limpar histórico" ao terminar.
Ele pode gerar uma chave ou IV aleatório para mim?
Não. Não há botão de gerar, então você informa a chave e o IV por conta própria. O mesmo texto simples, a mesma chave, o mesmo IV e os mesmos parâmetros sempre dão o mesmo resultado; só o preenchimento ISO10126 mistura bytes aleatórios e muda o resultado. Quando precisar de valores aleatórios, gere-os por conta própria; por exemplo, openssl rand -hex 16 na linha de comando imprime 16 bytes, que você pode informar com o formato definido como hex.