Criptografia AES para Desenvolvedores Quando Você Precisa e Como Funciona

Se você estiver armazenando dados sensíveis — informações pessoais dos usuários, chaves de API, registros financeiros — a criptografia AES é a ferramenta que você deve usar. É a norma da indústria para criptografia simétrica em repouso: rápida, comprovadamente segura e suportada nativamente em todas as principais linguagens.

Mas a AES mal implementada é pior que inútil. O modo ECB revela padrões. A reutilização de um IV com GCM rompe completamente a garantia de segurança. E armazenar sua chave ao lado do seu criptograma anula todo o propósito.

Aqui está o que você realmente precisa para usar a AES corretamente em produção.

O que é AES?

AES (Advanced Encryption Standard) é um cifrado simétrico em blocos. Simétrico significa que a mesma chave é usada para criptografar e descriptografar. Cifrado em blocos significa que ele opera em blocos fixos de 128 bits de dados.

Ele substituiu o DES em 2001 e hoje está em todos os lugares: TLS, criptografia de discos, gerenciadores de senhas, criptografia de campos de banco de dados. Diferentemente da criptografia assimétrica (RSA, ECDH), o AES é rápido o suficiente para criptografar grandes volumes de dados em tempo real. O custo: ambas as partes precisam da mesma chave, então a distribuição da chave torna-se o seu problema.

AES-128 versus AES-256: Qual tamanho de chave?

O AES vem em três tamanhos de chave: 128, 192 e 256 bits. Na prática, você escolherá entre 128 e 256.

	AES-128	AES-256
Tamanho da chave	128 bits	256 bits
Rodadas	10	14
Desempenho	Mais rápida	Aproximadamente 401 TP7T mais lenta
Segurança	Forte — não há ataque prático conhecido	Mais forte — protege contra futuros computadores quânticos
Veredito	Adequada para a maioria dos aplicativos	Use para dados de alta sensibilidade ou com longa retenção

O AES-128 não está quebrado. Não existe ataque prático. Mas se você estiver criptografando dados que precisam permanecer seguros por mais de 20 anos — ou se seu modelo de ameaça inclui computadores quânticos futuros — o AES-256 adiciona uma margem significativa. Para a maioria dos aplicativos que criptografam campos de banco de dados hoje, o AES-128 é suficiente. Quando houver dúvida, use o AES-256; a perda de desempenho é negligível para cargas típicas.

Modo de Operação: Por que GCM, e não ECB

O AES sozinho apenas criptografa um único bloco de 128 bits. Para dados reais, você precisa de um modo de operação que trate múltiplos blocos e os sequencie corretamente. Essa escolha é crucial.

Modo	Autenticado	IV necessário	Veredito
ECB	Não	Não	Nunca use — texto plano idêntico produz criptograma idêntico, revela padrões
CBC	Não	Sim	Desatualizado — não oferece autenticação, vulnerável a ataques de padding oracle
GCM	Sim (AEAD)	Sim (nonce)	Use isso — criptografa e autentica em uma passagem

Use GCM. O GCM (Galois/Counter Mode) é um cifrado AEAD — Criptografia Autenticada com Dados Associados. Ele faz duas coisas ao mesmo tempo:

1. Criptografa seus dados para torná-los ininteligíveis sem a chave
2. Produz uma etiqueta de autenticação para que qualquer alteração seja detectada imediatamente

Sem autenticação, um atacante pode inverter bits no criptograma e você descriptografará lixo sem saber. Com GCM, a descriptografia falha de forma evidente se o criptograma foi modificado — antes mesmo que o texto plano seja retornado.

O IV/Nonce: Aleatório, Nunca Reutilizado

O GCM exige um vetor de inicialização (IV), também chamado de nonce — "número usado uma vez". O IV não precisa ser secreto, mas deve ser:

• Aleatório — gerado com um gerador de números aleatórios criptograficamente seguro
• Exclusivo — nunca reutilizado com a mesma chave

A reutilização de um IV com a mesma chave no GCM é catastrófica. Um atacante que vê dois criptogramas criptografados com a mesma chave e IV pode XOR-los e recuperar ambos os textos brutos. Isso não é teórico — já aconteceu em sistemas em produção.

Use um IV aleatório de 96 bits (12 bytes) por operação de criptografia. Como você precisa dele para a descriptografia, armazene-o junto ao criptograma — o IV pré-fixado ao criptograma é a forma convencional.

Código Funcional: AES-256-GCM

Aqui estão trechos prontos para produção. Ambos armazenam o IV e a etiqueta de autenticação junto ao criptograma, para que a descriptografia seja autossuficiente.

Node.js

const crypto = require('crypto');

const ALGORITHM = 'aes-256-gcm';
const KEY_LENGTH = 32; // 256 bits
const IV_LENGTH  = 12; // 96 bits — recommended for GCM
const TAG_LENGTH = 16; // 128-bit auth tag

function encrypt(plaintext, key) {
  const iv = crypto.randomBytes(IV_LENGTH);
  const cipher = crypto.createCipheriv(ALGORITHM, key, iv);

  const encrypted = Buffer.concat([
    cipher.update(plaintext, 'utf8'),
    cipher.final(),
  ]);
  const tag = cipher.getAuthTag();

  // Layout: [iv (12)] + [tag (16)] + [ciphertext]
  return Buffer.concat([iv, tag, encrypted]).toString('base64');
}

function decrypt(ciphertextB64, key) {
  const data      = Buffer.from(ciphertextB64, 'base64');
  const iv        = data.subarray(0, IV_LENGTH);
  const tag       = data.subarray(IV_LENGTH, IV_LENGTH + TAG_LENGTH);
  const encrypted = data.subarray(IV_LENGTH + TAG_LENGTH);

  const decipher = crypto.createDecipheriv(ALGORITHM, key, iv);
  decipher.setAuthTag(tag);

  return Buffer.concat([decipher.update(encrypted), decipher.final()]).toString('utf8');
}

// Usage
const key        = crypto.randomBytes(KEY_LENGTH); // store this securely
const ciphertext = encrypt('sensitive data here', key);
const plaintext  = decrypt(ciphertext, key);

Pitão

import os, base64
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

IV_LENGTH = 12  # 96 bits

def encrypt(plaintext: str, key: bytes) -> str:
    iv = os.urandom(IV_LENGTH)
    aesgcm = AESGCM(key)
    # encrypt() appends the 16-byte auth tag automatically
    ciphertext = aesgcm.encrypt(iv, plaintext.encode(), None)
    return base64.b64encode(iv + ciphertext).decode()

def decrypt(ciphertext_b64: str, key: bytes) -> str:
    data       = base64.b64decode(ciphertext_b64)
    iv         = data[:IV_LENGTH]
    ciphertext = data[IV_LENGTH:]
    aesgcm = AESGCM(key)
    return aesgcm.decrypt(iv, ciphertext, None).decode()

# Usage
key        = AESGCM.generate_key(bit_length=256)  # store this securely
ciphertext = encrypt('sensitive data here', key)
plaintext  = decrypt(ciphertext, key)

Instale a dependência: pip install cryptography

Você pode testar criptografia e descriptografia de AES interativamente — sem nenhuma configuração — usando o IO Tools Ferramenta de Criptografia/Descriptografia de AES.

Gestão de Chaves: A Parte Difícil

Sua criptografia é tão forte quanto sua gestão de chaves. Os erros mais comuns:

• Chave armazenada no mesmo banco de dados que os dados criptografados — se um atacante obter o dump do banco de dados, ele obterá ambos.
• Chave armazenada no controle de versão — mesmo que ignorada pelo git .env, a rotação se torna difícil e o histórico persiste.
• Chave aparecendo em logs — os logs da aplicação são enviados para agregadores. As chaves nunca devem surgir lá.

Onde armazenar realmente as chaves de criptografia:

• AWS KMS / Google Cloud KMS / Azure Key Vault — armazenamento de chaves gerenciado com rastreamento e rotação automática
• HashiCorp Vault — autossuficiente, bom para ambientes multicloude
• Variáveis de ambiente — aceitável para cargas de trabalho de baixa sensibilidade com superfície de exposição limitada

Para criptografia de campos em bancos de dados, o padrão é a criptografia envolvente: gere uma chave de criptografia de dados (DEK) por registro ou coluna, depois criptografe a DEK com uma chave mestra armazenada em um KMS. Seu banco de dados contém apenas DEKs criptografados e criptogramas — a chave mestra nunca toca o banco de dados.

Quando usar AES — e quando não usar

O AES é a ferramenta certa para:

• Criptografar campos em um banco de dados — números de SSN, números de cartão, registros de saúde
• Criptografar arquivos em repouso antes do armazenamento na nuvem
• Compartilhar segredos entre serviços que compartilham uma chave pré-estabelecida

O AES não é a ferramenta certa quando:

• Você está transmitindo dados por uma rede — use TLS. Não crie seu próprio camada de transporte.
• Você precisa de criptografia assimétrica — se o remetente e o destinatário não conseguem compartilhar uma chave antecipadamente, use RSA ou ECDH para troca de chaves.
• Você está armazenando senhas — use bcrypt, scrypt ou Argon2. Senhas criptografadas podem ser descriptografadas; senhas corretamente hashadas não podem.
• Uma solução gerenciada se adapta — AWS Secrets Manager, Vault e similares lidam com rotação, controle de acesso e logs de auditoria de forma automática. Prefira isso ao uso manual de AES se ele cobrir seu caso de uso.

O erro mais comum que os desenvolvedores cometem é tratar o AES como uma solução completa de segurança. É um primitivo — um bloco de construção. Combine-o com modo autenticado (GCM), IVs únicos por operação e gestão de chaves adequada, e será extremamente eficaz. Pule qualquer um desses elementos e você criará algo que parece seguro, mas não é.

Você também pode gostar