Encriptador/Desencriptador AES

AES (Advanced Encryption Standard) é o algoritmo de criptografia simétrica mais utilizado globalmente, aprovado pela NSA para proteção de informações TOP SECRET. AES foi desenvolvido a partir da cifra Rijndael, projetada pelos criptógrafos belgas Joan Daemen e Vincent Rijmen, e publicado oficialmente pelo NIST em 2001 como substituto do DES. AES usa criptografia em blocos com tamanho fixo de 128 bits (16 bytes) e suporta três comprimentos de chave: 128, 192 e 256 bits. Chaves mais longas oferecem maior segurança mas velocidade ligeiramente menor. Como algoritmo simétrico, AES usa a mesma chave para criptografar e descriptografar. AES tem amplas aplicações: TLS/SSL para web e e-mail, BitLocker/FileVault para criptografia de disco, criptografia de banco de dados e segurança IoT. Esta ferramenta suporta todos os 6 modos AES (ECB, CBC, CFB, OFB, CTR, GCM) e 5 esquemas de preenchimento.

AES (Advanced Encryption Standard) foi publicado pelo NIST como FIPS 197 em novembro de 2001, após uma competição pública de cinco anos iniciada em 1997 com 15 candidatos. O vencedor foi Rijndael, projetado pelos criptógrafos belgas Joan Daemen e Vincent Rijmen, superando finalistas como Twofish, Serpent, RC6 e Mars. AES substituiu DES (FIPS 46, retirado em 2005) e é hoje a cifra de bloco simétrica mais amplamente implementada no mundo: está presente no TLS 1.2/1.3, IPsec, BitLocker, FileVault, no padrão `aes-256-gcm` do OpenSSL, no dm-crypt do kernel Linux, no CryptoKit da Apple e no Keystore do Android. A NSA aprovou AES-256 para TOP SECRET em 2003 (suite A), tornando AES a primeira cifra publicamente disponível autorizada para o mais alto nível de classificação dos EUA. O tamanho do bloco é fixo em 128 bits (16 bytes); os tamanhos de chave são 128, 192 ou 256 bits, mapeados para 10, 12 ou 14 rodadas. Cada rodada (exceto a última) executa quatro operações em um estado de 4x4 bytes: SubBytes aplica uma S-Box fixa de 16x16 (0x63 = 01100011 está na linha 6, coluna 3 — a S-Box é construída como o inverso multiplicativo em GF(2^8) mais uma transformação afim para quebrar a estrutura algébrica); ShiftRows rotaciona a linha 0 por 0, linha 1 por 1, linha 2 por 2, linha 3 por 3 bytes; MixColumns multiplica cada coluna por uma matriz MDS circulante fixa sobre GF(2^8) (o polinômio 0x03 * x em forma matricial); AddRoundKey aplica XOR com a subchave da rodada. A rodada final omite MixColumns. As chaves de rodada vêm do key schedule de Rijndael: 11/13/15 chaves de rodada de 128 bits cada, geradas via RotWord (rotação à esquerda de 1 byte), SubWord (aplicar S-Box) e XOR com Rcon[i] = [0x01, 0x02, 0x04, ..., 0x80, 0x1b, 0x36] *2^(i-1) sobre GF(2^8). A biblioteca `aes-js` da página executa as quatro etapas em JavaScript puro e é compatível em nível de bytes com a libcrypto do OpenSSL. Cinco modos de bloco são expostos. ECB criptografa cada bloco de 16 bytes independentemente: blocos idênticos de texto claro produzem blocos idênticos de cifretexto, vazando estrutura (a famosa imagem do pinguim ECB sobrevive à criptografia porque o padrão de pixels sobrevive). CBC aplica XOR em cada bloco de texto claro com o bloco de cifretexto anterior antes da criptografia; o primeiro bloco aplica XOR com um IV. CTR transforma AES em uma cifra de fluxo criptografando um contador incremental (nonce || counter, ambos metades de 64 bits de um bloco de 128 bits) e aplicando XOR do keystream com o texto claro — suporta acesso aleatório e criptografia paralela. GCM é CTR mais GHASH (um autenticador de hash universal sobre GF(2^128)), produzindo uma tag de autenticação de 16 bytes concatenada após o cifretexto. GCM é o AEAD padrão no TLS 1.3 (RFC 8446) e na maioria das APIs modernas (Node `crypto.createCipheriv('aes-256-gcm', ...)`). CFB e OFB são modos de cifra de fluxo mais antigos mantidos por compatibilidade. O problema do IV é o bug de produção mais comum. GCM com IV de 96 bits (12 bytes) é a configuração recomendada pelo NIST (RFC 5288, NIST SP 800-38D §5.2.1.1): o IV de 12 bytes é tratado como um contador, e GHASH é calculado sobre J0 = IV || 0x00000001. Reutilizar um IV sob a mesma chave no modo CTR vazia o XOR do texto claro (C1 XOR C2 = P1 XOR P2 — um único ataque de texto claro escolhido recupera ambas as mensagens). Reutilizar um IV em GCM é pior: um atacante pode recuperar a subchave de autenticação H e forjar tags para mensagens arbitrárias (o ataque está em Joux 2006 e é o motivo pelo qual o NIST proibiu IVs aleatórios de 96 bits sem unicidade estrita). A página gera IVs de 12 bytes com `crypto.getRandomValues(new Uint8Array(12))` para GCM e IVs de 16 bytes para CBC/CFB/OFB, e o botão de chave aleatória usa o mesmo CSPRNG para que cada criptografia comece com material novo. Esta ferramenta executa a cifra e decifra AES inteiramente no navegador via aes-js (implementação AES em JavaScript puro). Não existe caminho alternativo por Web Crypto / SubtleCrypto — independentemente do tamanho da carga, todas as operações passam pelo aes-js.

• AES é FIPS 197 (2001), selecionado por uma competição aberta do NIST com 15 candidatos; Rijndael superou Twofish, Serpent, RC6 e Mars. O tamanho do bloco é sempre de 128 bits; os tamanhos de chave 128/192/256 bits executam 10/12/14 rodadas. A página suporta os três via construtores AES_128, AES_192 e AES_256 do aes-js.
• A função de rodada de quatro etapas: SubBytes (uma S-Box de 256 bytes que é o inverso em GF(2^8) mais afim), ShiftRows (linhas deslocadas em 0/1/2/3 bytes), MixColumns (multiplicação matricial MDS sobre GF(2^8) com o polinômio 0x03), AddRoundKey (XOR com chave de rodada). A rodada final omite MixColumns. Mesmo algoritmo, mesma chave = mesmo cifretexto — AES é determinístico.
• ECB é inseguro porque blocos idênticos de texto claro produzem blocos idênticos de cifretexto (a famosa imagem do 'pinguim ECB' preserva sua silhueta). CBC é o clássico seguro; CTR adiciona paralelismo; GCM adiciona autenticação e é o padrão do TLS 1.3 (RFC 8446). CFB e OFB são modos de cifra de fluxo mantidos por compatibilidade com sistemas legados.
• Preenchimento PKCS#7: 1 byte a menos → 15 bytes de 0x0f + 1 byte de 0x10; 2 bytes a menos → 14 de 0x0e + 2 de 0x0f, etc. O último byte indica o comprimento do preenchimento, então a remoção é inequívoca. Modos de fluxo (CTR/CFB/OFB/GCM) ignoram completamente o preenchimento. ZeroPadding é ambíguo quando os dados terminam com 0x00 — não o utilize.
• GCM é AEAD: cifretexto mais uma tag de autenticação de 16 bytes, calculada via GHASH sobre GF(2^128) usando H = AES_K(0^128). AAD (dados autenticados adicionais) cobre cabeçalhos sem criptografá-los. O IV de 96 bits (RFC 5288) é tratado como um contador; IVs de 128 bits passam por um GHASH para derivar J0 — mesma segurança, ligeiramente mais lento.
• A reutilização de IV é catastrófica. Reutilização de IV em CTR vazia P1 XOR P2 (two-time pad). Reutilização de IV em GCM (Joux 2006) permite que um atacante recupere H e forje tags. A página gera IVs com `crypto.getRandomValues` (um CSPRNG), nunca os reutiliza dentro de uma sessão e prefixa o IV ao cifretexto para que a parte de descriptografia possa recuperá-lo sem estado fora de banda.
• Geração da chave AES: o botão de chave aleatória usa `crypto.getRandomValues` (CSPRNG do navegador). O cálculo das rondas AES é feito via aes-js, implementação em JavaScript puro byte a byte compatível com a libcrypto do OpenSSL para os mesmos ajustes de chave, IV e padding.
• Realidade de canais laterais: AES em JS puro não é de tempo constante (indexação no array S-Box vazia tempo). O AES do Web Crypto executa em código nativo e é de tempo constante. Para workloads críticos (HSM, KDFs do lado do servidor), prefira o caminho nativo; para uma ferramenta de aprendizado no navegador, aes-js é adequado porque a entrada já está na memória da página. Caminho de migração: SHA-1 → SHA-256 para hashes, DES → AES para cifras, ECB → GCM para modos.