Modos de Criptografia AES Explicados Por que GCM supera o CBC em maioria das situações (e quando não)

Quando a documentação diz para "usar AES-256", essa é uma orientação incompleta. O AES é um cifrado por blocos — ele criptografa exatamente um bloco de 128 bits de cada vez. O modo de operação é o que determina como o AES trata dados reais com mais de 16 bytes e quão bem protege você contra atacantes que podem observar ou manipular o texto criptografado. Errar nisso é como acabar com dados "criptografados" que revelam a estrutura dos seus arquivos ou um sistema vulnerável a ataques de flip de bits.

A especificação completa do algoritmo parece AES-256-GCM ou AES-128-CBC — tamanho da chave seguido pelo modo. Este artigo aborda o que cada modo realmente faz, por que o GCM é a escolha padrão e em que situações você pode usar algo diferente.

Primeiro, por que o ECB é um meme e não apenas uma piada

ECB (Electronic Codebook) é o modo básico. Cada bloco de 16 bytes de texto claro é criptografado independentemente com a mesma chave. Isso significa que blocos de texto claro idênticos produzem blocos de texto criptografado idênticos.

A demonstração clássica é o pinguim Linux (Tux) criptografado com ECB. A imagem é criptografada bloco por bloco, mas porque grandes áreas da imagem têm cores uniformes, a versão criptografada ainda mostra claramente a forma de um pinguim. A criptografia é matematicamente válida — os dados estão embaralhados — mas a padrão é preservada.

Na prática, isso importa sempre que seu texto claro tiver repetições: linhas de banco com prefixo comum, cabeçalhos de arquivos, campos preenchidos. O ECB revela a estrutura. Não há caso legítimo de uso do ECB em código novo. Se você estiver mantendo código que usa ECB: substitua-o.

Os modos que vale a pena conhecer

CBC — o modo mais usado em códigos legados

Cipher Block Chaining XORa cada bloco de texto claro com o bloco de ciphertext anterior antes de criptografar. Isso resolve o problema do padrão do ECB — blocos de texto claro idênticos produzem blocos de ciphertext diferentes porque a cadeia faz com que cada bloco dependa do que veio antes.

O CBC exige um vetor de inicialização (IV) — um valor aleatório de 16 bytes que inicia a cadeia para o primeiro bloco. O IV não precisa ser secreto, mas deve ser aleatório e deve ser transmitido junto com o ciphertext.

O problema com o CBC: oferece confidentialidade mas não integridade. Um atacante que pode modificar o ciphertext em trânsito pode inverter bits específicos no resultado descodificado de maneira previsível. Isso é a base dos ataques de padding oracle, que já quebraram sistemas reais (POODLE, BEAST, Lucky Thirteen). Se você usar CBC sem um MAC (Message Authentication Code) para verificar integridade, estará vulnerável. O padrão é chamado de encrypt-then-MAC — criptografe primeiro, depois HMAC o ciphertext e verifique o MAC antes de descodificar. Errar nesta ordem é um erro clássico.

O CBC também é sequencial — você não pode paralelizar a criptografia (cada bloco depende do ciphertext anterior) e a descodificação é apenas parcialmente paralelizável.

CTR — comportamento de cifra de fluxo de um cifrado por blocos

O modo Counter transforma o AES em uma cifra de fluxo. Em vez de criptografar o texto claro diretamente, ele criptografa valores sucessivos de contador e XORa o resultado com o texto claro. Isso significa que o modo CTR não precisa de preenchimento (funciona com dados de qualquer comprimento), é totalmente paralelizável em ambas as direções e permite acesso aleatório a qualquer posição no ciphertext para descodificação.

O CTR usa um nonce (número usado uma vez) em vez de um IV completo. O nonce deve ser único por mensagem para uma chave dada — reutilizar um nonce com a mesma chave revela o XOR dos dois textos claros, o que é catastrófico. Diferentemente do CBC, o CTR também não oferece proteção de integridade. A mesma história: precisa de encrypt-then-MAC se deseja resistência a ataques de manipulação.

O CTR faz sentido quando você precisa de propriedades de cifra de fluxo — arquivos grandes, descodificação com acesso aleatório, cenários de alto throughput onde a paralelização importa — e você está lidando com a camada de MAC separadamente.

GCM — criptografia autenticada, em um passo

Galois/Counter Mode é o modo CTR mais um rótulo de autenticação integrado (GHASH). Você obtém confidencialidade e integridade em uma única operação. O rótulo de autenticação — tipicamente de 128 bits — permite que o receptor verifique se o ciphertext não foi manipulado antes de descodificar. Sem etapa separada de HMAC, sem chance de errar a ordem encrypt-then-MAC.

O GCM também suporta Dados Autenticados Adicionais (AAD) — dados que são autenticados mas não criptografados. Isso é útil para cabeçalhos, metadados ou qualquer dado que precise de proteção de integridade mas não precisa ser confidencial. O AAD é verificado junto com o ciphertext no rótulo de autenticação.

O nonce para o GCM é de 96 bits (12 bytes) por padrão. Como o CTR, o uso repetido do nonce é fatais — reutilizar um nonce com a mesma chave sob o GCM revela tanto o texto claro quanto a chave de autenticação (H), quebrando completamente a segurança. Sempre gere nonces com um gerador de números aleatórios criptograficamente seguro; nunca derive-os de contadores sequenciais a menos que você tenha um esquema cuidadoso de contador distribuído.

O GCM é paralelizável e não exige preenchimento. É a recomendação padrão em TLS 1.3, Signal Protocol e na maioria das bibliotecas criptográficas modernas. Se você estiver escrevendo código novo, o GCM é sua escolha padrão.

Comparação de modos

Modo	Autenticado	Paralelizável	Precisa de preenchimento	Risco de reutilização de nonce/IV	Veredito
ECB	Não	Sim	Sim	N/A (sem IV)	Nunca use
CBC	Não (adicionar MAC)	Criptografar: Não / Descodificar: Sim	Sim	Moderado	Uso legado apenas
CTR	Não (adicionar MAC)	Sim	Não	Crítico — reutilização = vazamento de texto claro	Uso nicho
GCM	Sim (integrado)	Sim	Não	Crítico — reutilização = quebra total	Escolha padrão

AES-256-GCM no Node.js

Aqui está uma implementação completa de criptografia/descodificação usando o módulo integrado do Node.js — sem dependências necessárias: crypto Umas coisas importantes a notar sobre este código:

const crypto = require('crypto');

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

function encrypt(plaintext, key) {
  const nonce = crypto.randomBytes(NONCE_LENGTH);
  const cipher = crypto.createCipheriv(ALGORITHM, key, nonce, {
    authTagLength: TAG_LENGTH,
  });

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

  // Prepend nonce + tag to ciphertext for storage/transmission
  return Buffer.concat([nonce, tag, encrypted]);
}

function decrypt(ciphertext, key) {
  const nonce = ciphertext.subarray(0, NONCE_LENGTH);
  const tag = ciphertext.subarray(NONCE_LENGTH, NONCE_LENGTH + TAG_LENGTH);
  const data = ciphertext.subarray(NONCE_LENGTH + TAG_LENGTH);

  const decipher = crypto.createDecipheriv(ALGORITHM, key, nonce, {
    authTagLength: TAG_LENGTH,
  });
  decipher.setAuthTag(tag);

  // Throws if auth tag doesn't match — do not catch this silently
  return Buffer.concat([decipher.update(data), decipher.final()]).toString('utf8');
}

// Generate a key (do this once; store it securely)
const key = crypto.randomBytes(KEY_LENGTH);

const message = 'Hello, authenticated encryption.';
const ciphertext = encrypt(message, key);
console.log('Encrypted:', ciphertext.toString('hex'));

const plaintext = decrypt(ciphertext, key);
console.log('Decrypted:', plaintext); // Hello, authenticated encryption.

O nonce é gerado de forma nova em cada chamada de criptografia

• é criptograficamente seguro. Não substitua isso por um contador a menos que você entenda o problema de unicidade distribuída. — crypto.randomBytes O nonce e o rótulo de autenticação são armazenados com o ciphertext
• — eles precisam viajar junto com os dados criptografados. O nonce é público; o rótulo é público. Apenas a chave é secreta. lança erro em caso de falha de autenticação
• decipher.final() — esse é o comportamento correto. Não capture silenciosamente e retorne um texto parcial. A falha de autenticação significa que os dados foram manipulados ou a chave está errada. A gestão de chaves é a parte difícil
• dá um bom chave, mas onde você armazena e rota a chave importa mais do que a escolha do algoritmo. Use um gerenciador de segredos, não uma constante hardcoded. — crypto.randomBytes(32) Quer testar modos de criptografia interativamente?

IO Tools’ ferramenta de criptografia/descodificação de AES permite criptografar e descodificar com modos CBC e GCM no navegador — útil para verificar interoperabilidade ou depurar uma integração. Para gerar uma chave criptograficamente segura de 256 bits, use o Gerador de Chaves de AES IV e nonce: as regras que realmente importam.

A utilização incorreta de nonces/IVs causa mais quebras no mundo real do que a escolha do algoritmo. As regras:

Sempre gere nonces/IVs com um CSPRNG

• no Node, — crypto.randomBytes() no Java. Não os.urandom() em Python, SecureRandom . Não uma marcação de tempo. Não um contador incrementando a menos que seja um contador global cuidadosamente gerenciado com garantias de unicidade rígidas. Math.random()A reutilização do nonce no GCM quebra completamente a autenticação
• — com a mesma chave e nonce, o GCM revela a chave de autenticação H. Um atacante então pode falsificar rótulos de autenticação para ciphertexts arbitrários. Isso não é teórico: o Ataque Forbidden explora isso e já foi usado contra implementações reais. A reutilização do IV no CBC é menos catastrófica, mas ainda ruim
• — ataques com texto claro escolhido tornam-se viáveis. Na prática, gere sempre um IV novo por mensagem. Nunca derive um nonce a partir do conteúdo da mensagem
• — nonces determinísticos que dependem de dados previsíveis criam padrões previsíveis. Use aleatoriedade. Quando o CBC ou o CTR ainda são a escolha certa

O GCM não é sempre a resposta:

Interoperabilidade com sistemas legados

• — se você estiver integrando com um sistema que só fala AES-CBC, está usando CBC. Documente claramente a exigência de MAC e implemente corretamente (encrypt-then-MAC com HMAC-SHA256). Ambientes restritos sem aceleração de GHASH no hardware
• — o passo de autenticação do GCM usa GHASH, que é mais pesado computacionalmente do que uma operação básica de cifra por bloco em hardware sem aceleração dedicada. Alguns dispositivos embarcados onde o CTR+CMAC está disponível mas o GHASH não está podem justificar o uso do modo CTR. Criptografia de fluxo de arquivos muito grandes onde é necessário acesso aleatório na descodificação
• — a propriedade de acesso aleatório do CTR é útil quando você precisa descodificar a posição N sem ler as posições de 0 até N-1. O GCM tecnicamente permite isso, mas a verificação do rótulo de autenticação exige processar todo o ciphertext primeiro, o que anula o propósito. Criptografia de disco
• — a criptografia de disco inteiro usa o modo XTS (não abordado aqui), não o GCM, porque o XTS é projetado para setores de tamanho fixo e acesso aleatório. O GCM é para criptografia de mensagens, não para criptografia de setores. AES-256-GCM

A versão curta

Use o para código novo. Gere um nonce aleatório de 12 bytes por chamada de criptografia. Armazene o nonce e o rótulo de autenticação com o ciphertext. Trate as falhas de verificação do rótulo de autenticação como erros, não como avisos — nunca retorne um texto parcial quando o GCM diz que os dados são inválidos. Se você estiver auditando código existente de CBC: verifique se o encrypt-then-MAC é implementado corretamente, confirme que os IVs são aleatórios (não reutilizados, não sequenciais) e planeje uma rota de migração para o GCM quando a janela de manutenção permitir. O CBC com HMAC correto não está quebrado — é apenas mais armadilhas do que o GCM.

ECB: simplesmente substitua. Não há caminho de auditoria que termine com “o ECB está bem aqui”.

ECB: basta substituí-lo. Não há um caminho de auditoria que termine com "o ECB está bem aqui".

Você também pode gostar