Criptografia Autenticada: AES-GCM e ChaCha20-Poly1305

A Criptografia autenticada (AE) resolve um problema fundamental: a criptografia tradicional fornece apenas confidencialidade — mantém os dados em segredo —, mas não verifica se o texto cifrado foi adulterado. Um invasor poderia inverter bits no texto cifrado, e o receptor decifraria dados inválidos sem saber que foram modificados. A Criptografia autenticada com dados associados (AEAD) acrescenta simultaneamente uma garantia de integridade e autenticidade, produzindo tanto o texto cifrado quanto uma etiqueta de autenticação que detecta qualquer modificação.

O AES-GCM (modo Galois/contador) combina dois componentes: o AES-CTR (modo contador) para criptografia e o GMAC (código de autenticação de mensagens Galois) para integridade. O AES-CTR gera um fluxo de chaves criptografando um valor contador e aplicando XOR a ele com o texto claro — isso torna a criptografia paralelizável, ao contrário do modo CBC. O GMAC calcula uma etiqueta de autenticação sobre o texto cifrado e quaisquer dados associados. A etiqueta resultante (128 bits) é transmitida junto ao texto cifrado; uma única alteração de bit invalida a etiqueta.

O AES-GCM exige um nonce (número usado uma única vez), geralmente de 96 bits (12 bytes). O nonce deve ser exclusivo para cada operação de criptografia com a mesma chave — não precisa ser secreto, mas nunca deve se repetir. A reutilização do nonce no AES-GCM é catastrófica: se duas mensagens forem criptografadas com a mesma chave e o mesmo nonce, um invasor poderá aplicar XOR aos textos cifrados para cancelar o fluxo de chaves e, potencialmente, recuperar os dois textos simples. Essa vulnerabilidade às vezes é chamada de “uso indevido do nonce” e já causou ataques reais de recuperação de chaves.

Quando os nonces do AES-GCM são reutilizados, o invasor pode calcular C1 XOR C2 = P1 XOR P2 (o XOR dos dois textos simples), pois o mesmo fluxo de chaves foi usado para ambos. Além disso, a reutilização do nonce permite recuperar a chave de autenticação H, o que significa que o invasor pode forjar tags de autenticação válidas para mensagens arbitrárias — comprometendo completamente a confidencialidade e a integridade. Sistemas como o Sony PS3 sofreram exatamente esse ataque. A defesa consiste em nonces aleatórios (gerados com um CSPRNG) ou em um contador determinístico que nunca seja reiniciado.

ChaCha20-Poly1305 é a outra cifra AEAD exigida pelo TLS 1.3. ChaCha20 é uma cifra de fluxo projetada por Daniel Bernstein que gera um fluxo de chaves usando operações de adição, rotação e XOR (ARX) — sem tabelas de consulta, em tempo constante e extremamente rápida em CPUs sem aceleração de hardware para AES. Poly1305 é um MAC de uso único (código de autenticação de mensagem) que calcula a tag de autenticação sobre o texto cifrado. Juntas, essas primitivas oferecem segurança equivalente à do AES-GCM, mas são significativamente mais rápidas em dispositivos móveis e de IoT.

Os processadores modernos x86 e ARM64 para computadores e servidores incluem instruções de hardware AES-NI que tornam o AES-GCM extremamente rápido. No entanto, muitos processadores de dispositivos móveis e de IoT não têm AES-NI, o que torna o AES-GCM implementado em software relativamente lento. O ChaCha20-Poly1305 foi projetado para ser rápido em software, usando operações aritméticas simples e oferecendo aos dispositivos móveis um desempenho comparável sem aceleração de hardware. O Google adicionou o ChaCha20-Poly1305 ao TLS como alternativa especificamente para dispositivos Android, e ele agora é um conjunto de cifras de primeira classe no TLS 1.3.

O “AD” em AEAD significa Dados associados — metadados em texto simples que são autenticados, mas não criptografados. Isso permite autenticar dados que precisam permanecer legíveis (como cabeçalhos de pacotes ou campos de tipo de registro) e, ao mesmo tempo, protegê-los contra adulteração. No TLS 1.3, os bytes do cabeçalho do registro são incluídos como dados associados no cálculo do AEAD. Se um invasor modificar o cabeçalho (por exemplo, alterar o tamanho do registro), a verificação da tag de autenticação falhará e a conexão será encerrada.

Antes de o AEAD se tornar padrão, os criptógrafos recomendavam o Encrypt-then-MAC (EtM): criptografar o texto simples e, em seguida, calcular um MAC sobre o texto cifrado. Essa abordagem é segura, mas exige duas operações separadas com duas chaves separadas. Esquemas AEAD, como o AES-GCM, combinam as duas operações usando uma única chave, reduzindo a complexidade da implementação e eliminando toda uma classe de ataques de oráculo de preenchimento que afetava o MAC-then-Encrypt (MtE) — a ordem usada nas versões antigas do TLS (CBC + HMAC). O TLS 1.3, ao usar AEAD, evita completamente esses problemas.

Tanto o AES-128-GCM quanto o AES-256-GCM são aprovados pelo NIST e considerados seguros contra computadores clássicos. O AES-128 oferece segurança de 128 bits com desempenho ligeiramente superior; o AES-256 oferece segurança de 256 bits, proporcionando uma margem maior contra futuras análises criptográficas e ameaças quânticas. Para a maioria das aplicações atuais, o AES-128-GCM é suficiente, mas sistemas governamentais classificados (NSA Suite B) exigem AES-256. O TLS 1.3 oferece ambos, e os servidores podem priorizá-los de acordo com sua política de segurança.

Ao descriptografar um texto cifrado AEAD, o receptor deve verificar a tag de autenticação antes de descriptografar. O processo é o seguinte: recalcular a tag esperada a partir do texto cifrado recebido, da chave e do nonce; compará-la com a tag recebida usando uma função de comparação em tempo constante; somente se forem iguais, prosseguir com a descriptografia. A comparação em tempo constante é essencial — se a comparação for interrompida no primeiro byte diferente, um invasor poderá realizar um ataque de canal lateral baseado em tempo para forjar tags válidas byte a byte. Qualquer biblioteca AEAD que use uma comparação com saída antecipada estará vulnerável.

Os algoritmos AEAD são onipresentes na segurança moderna: o TLS 1.3 usa AES-GCM e ChaCha20-Poly1305 para criptografar todos os registros; a VPN WireGuard usa exclusivamente ChaCha20-Poly1305; o Signal Protocol usa essa cifra para criptografar mensagens; o protocolo QUIC (base do HTTP/3) usa AES-GCM. Quando você vê um conjunto de cifras como TLS_AES_256_GCM_SHA384, SHA384 se refere à função hash HKDF usada para derivação de chaves, não ao mecanismo de integridade — a tag GCM cuida da integridade.

Teste sua compreensão dos conceitos de CompTIA Security+ (SY0-701) apresentados nesta lição.

Nesta lição, você aprendeu que: os algoritmos AEAD fornecem confidencialidade e integridade simultaneamente por meio de uma tag de autenticação que detecta qualquer modificação no texto cifrado; a reutilização do nonce no AES-GCM é catastrófica — permitindo recuperar o fluxo de chaves e forjar a chave de autenticação —, portanto, os nonces devem ser exclusivos para cada criptografia; e ChaCha20-Poly1305 é a alternativa eficiente em desempenho ao AES-GCM para dispositivos sem aceleração de hardware para AES. A seguir, exploraremos funções de derivação de chaves para proteger senhas.