3 AES — Estágios e Modos de Operação

Autor

João Pavão

Data de Publicação

14 de setembro de 2026

Introdução

O capítulo anterior terminou com uma conclusão incómoda: o DES, durante décadas o pilar da cifra simétrica, está obsoleto, e o 3DES, a solução de recurso, é lento e continua limitado pelo bloco de 64 bits herdado do original. Era necessário um sucessor desenhado de raiz, não remendado. Este capítulo apresenta esse sucessor: o AES (Advanced Encryption Standard), o algoritmo de cifra simétrica hoje universalmente adoptado, de aplicações bancárias a comunicações protegidas por TLS. A segunda parte do capítulo trata de uma questão distinta, mas igualmente prática: uma cifra de bloco só cifra um bloco de cada vez, então como se cifra uma mensagem real, quase sempre maior do que isso?

3.1 Do DES ao AES: um Novo Paradigma

Em 1997, o National Institute of Standards and Technology (NIST) dos Estados Unidos lançou um concurso público e aberto para escolher o sucessor do DES, ao contrário do processo fechado que tinha originado o próprio DES duas décadas antes. Qualquer equipa, de qualquer país, podia submeter um algoritmo, que seria depois escrutinado publicamente por toda a comunidade criptográfica mundial.

Quinze algoritmos foram submetidos. Cinco chegaram à fase final: MARS, RC6, Rijndael, Serpent e Twofish. Em Outubro de 2000, o NIST anunciou o vencedor: Rijndael, desenhado pelos criptógrafos belgas Joan Daemen e Vincent Rijmen. O algoritmo foi formalizado como norma federal em 2001, sob o nome AES (National Institute of Standards and Technology 2001).

A diferença estrutural mais importante em relação ao DES não é o tamanho da chave ou do bloco, é a arquitectura interna. O DES, como se viu, é uma rede de Feistel: em cada ronda, apenas metade do bloco atravessa a função não linear $F$, enquanto a outra metade passa praticamente incólume, apenas combinada por XOR. O AES abandona esta estrutura. É uma rede de substituição-permutação (substitution-permutation network, SPN): em cada ronda, o bloco inteiro é transformado, através de uma sequência de quatro operações distintas aplicadas a todos os seus bytes.

3.2 Estrutura Geral do AES

Ao contrário do DES, em que o tamanho do bloco (64 bits) e o da chave (56 bits efectivos) estão fixados pela norma, o AES separa estas duas dimensões:

Bloco: sempre 128 bits (16 bytes), independentemente do tamanho da chave.
Chave: 128, 192 ou 256 bits, dando origem a três variantes — AES-128, AES-192 e AES-256.
Número de rondas: depende do tamanho da chave — 10 rondas para AES-128, 12 para AES-192, 14 para AES-256. Chaves maiores implicam mais rondas, porque cada ronda adicional dificulta ainda mais qualquer tentativa de análise estatística ou algébrica do algoritmo.

Internamente, o bloco de 128 bits organiza-se numa matriz $4 \times 4$ de bytes, a que se chama estado (state), preenchida coluna a coluna: os primeiros 4 bytes do bloco ocupam a primeira coluna, os 4 seguintes a segunda, e assim sucessivamente. Todas as transformações de ronda operam sobre esta matriz.

Figura 3.1: O estado do AES: o bloco de 128 bits (16 bytes) organiza-se numa matriz $4\times4$, preenchida coluna a coluna (byte 0 a byte 3 na primeira coluna, byte 4 a byte 7 na segunda, e assim sucessivamente).

O AES puro é determinístico: o mesmo bloco de texto claro, com a mesma chave, produz sempre o mesmo bloco de texto cifrado. Esta previsibilidade é inaceitável na prática — é precisamente o problema que, como se verá adiante, obriga a recorrer a um modo de operação, que introduz aleatoriedade através de um vector de inicialização ou nonce.

3.3 As Quatro Transformações de Ronda

Cada ronda do AES (excepto a última) aplica, por esta ordem, quatro transformações à matriz de estado. Antes da primeira ronda, aplica-se ainda um AddRoundKey inicial, e a última ronda omite o MixColumns. O objectivo destas quatro operações não é apenas ocultar o texto original, mas fazê-lo de forma que uma alteração mínima, um único bit, na mensagem ou na chave, produza alterações significativas e imprevisíveis no texto cifrado — o chamado efeito avalanche.

3.3.1 SubBytes

SubBytes é a única operação não linear do AES, e é ela que fornece a confusão: cada byte do estado é substituído pelo byte correspondente numa tabela fixa de substituição, a S-box, construída a partir do inverso multiplicativo no corpo finito $GF(2^8)$ seguido de uma transformação afim. Ao contrário do DES, que usa oito S-boxes diferentes (uma por grupo de 6 bits), o AES usa uma única S-box, reaplicada byte a byte a toda a matriz de estado.

Figura 3.2: No passo SubBytes, cada byte do estado é substituído pelo byte correspondente numa S-box fixa. Fonte: Wikimedia Commons, domínio público.

3.3.2 ShiftRows

ShiftRows desloca ciclicamente cada linha da matriz de estado para a esquerda: a linha 0 não se altera, a linha 1 desloca-se 1 posição, a linha 2 desloca-se 2 posições, a linha 3 desloca-se 3 posições. Esta operação é simples, mas essencial: garante que os bytes de uma coluna deixam de pertencer todos à mesma coluna, espalhando a influência de cada byte por várias colunas nas rondas seguintes.

Figura 3.3: No passo ShiftRows, cada linha da matriz de estado é deslocada ciclicamente para a esquerda, um número de posições diferente por linha. Fonte: Wikimedia Commons, domínio público.

3.3.3 MixColumns

MixColumns opera sobre cada coluna da matriz de estado independentemente, tratando-a como um polinómio de grau 3 sobre $GF(2^8)$ e multiplicando-a por um polinómio fixo $c(x)$, módulo $x^4+1$. O efeito prático é que cada byte de saída de uma coluna passa a depender dos quatro bytes de entrada dessa mesma coluna. Combinado com o ShiftRows anterior, garante que, ao fim de poucas rondas, cada byte de saída depende de todos os bytes de entrada do bloco: é a difusão do AES. Esta transformação omite-se na última ronda.

Figura 3.4: No passo MixColumns, cada coluna da matriz de estado é multiplicada por um polinómio fixo $c(x)$, misturando os seus quatro bytes. Fonte: Wikimedia Commons, domínio público.

3.3.4 AddRoundKey

AddRoundKey é a única transformação que envolve a chave: cada byte do estado combina-se por XOR com o byte correspondente da subchave dessa ronda, derivada da chave principal pelo esquema de expansão de chave (key schedule). As outras três transformações não usam a chave: são públicas, e qualquer pessoa as consegue desfazer. Dão confusão, difusão e não-linearidade, mas, sozinhas, não dão segurança nenhuma. O AddRoundKey, por sua vez, é o único passo que não se desfaz sem a chave, mas, sozinho, também é fraco: é um XOR com uma chave fixa, uma espécie de cifra de Vernam, e basta conhecer um bloco de texto claro e o respectivo texto cifrado para obter a chave com um único XOR. A segurança do AES vem da alternância entre os dois: um XOR com a chave, seguido da baralhação pública das outras três transformações, seguido de novo XOR com a chave, e assim sucessivamente (Stallings 2020). É também por isso que o AES começa e acaba com um AddRoundKey: qualquer outro passo, colocado no início ou no fim, seria público e poderia ser desfeito sem conhecer a chave, pelo que não acrescentaria segurança nenhuma.

Figura 3.5: No passo AddRoundKey, cada byte do estado combina-se por XOR com o byte correspondente da subchave da ronda. Fonte: Wikimedia Commons, domínio público.

3.4 A Ronda Completa e a Expansão de Chave

Uma ronda intermédia do AES aplica, por esta ordem, SubBytes, ShiftRows, MixColumns e AddRoundKey. A última ronda omite o MixColumns, e há ainda um AddRoundKey inicial, antes de qualquer ronda, usando a própria chave original sem expansão.

Figura 3.6: A estrutura completa do AES: um `AddRoundKey` inicial, seguido de $N_r-1$ rondas intermédias (`SubBytes`, `ShiftRows`, `MixColumns`, `AddRoundKey`), e uma ronda final que omite o `MixColumns`.

Isto significa que um AES de $N_r$ rondas precisa de $N_r+1$ subchaves de 128 bits: uma para o AddRoundKey inicial, mais uma por ronda. Estas subchaves não são fragmentos independentes da chave original, mas são geradas por um esquema de expansão de chave, que trabalha com palavras de 32 bits (4 bytes). No AES-128, com 10 rondas, são precisas 11 subchaves de 4 palavras cada, ou seja, 44 palavras, $w_0$ a $w_{43}$; no AES-192 são 52 palavras, e no AES-256 são 60 (National Institute of Standards and Technology 2001). As quatro primeiras palavras são a própria chave, e é por isso que o AddRoundKey inicial usa a chave original. Cada palavra seguinte obtém-se por XOR entre a palavra anterior e a que está quatro posições atrás; de quatro em quatro palavras, a palavra anterior passa primeiro por uma rotação dos seus bytes, pela mesma S-box do SubBytes e por um XOR com uma constante de ronda fixa. A decifragem usa exactamente as mesmas subchaves, mas por ordem inversa, da última para a primeira, porque desfaz as rondas pela ordem contrária; o essencial é reter que todas as subchaves derivam de uma única chave secreta, e que a sua geração é determinística e pública, tal como toda a restante estrutura do algoritmo: a segurança do AES reside inteiramente na chave, nunca no segredo do desenho, tal como o princípio de Kerckhoffs exige.

3.5 Segurança do AES

Desde a sua normalização em 2001, o AES foi sujeito a um escrutínio criptanalítico intenso e contínuo, sem que se tenha encontrado qualquer ataque com utilidade prática. O melhor resultado conhecido, de 2011, recupera uma chave AES-128 com cerca de $2^{126}$ operações em vez de $2^{128}$, isto é, quatro vezes mais depressa do que a força bruta, mas exige uma quantidade absurda de pares de texto claro e texto cifrado, da ordem de $2^{88}$ bits (Aumasson 2017). O espaço de chaves mínimo, $2^{128}$, torna a força bruta pura astronomicamente inviável, muito além do que já era o caso para o DES.

Na prática, as vulnerabilidades reais associadas ao AES não são matemáticas, mas de implementação: ataques de canal lateral (side-channel), que exploram informação indirecta, como o tempo de execução ou o consumo energético de um dispositivo a cifrar, em vez de atacar o algoritmo em si. O exemplo clássico são os ataques de tempo de cache (cache-timing). As implementações do AES em software usam tabelas guardadas em memória, e o elemento da tabela que é lido em cada passo depende da chave. O tempo que esse acesso demora varia consoante o elemento já está ou não na memória cache do processador, pelo que medir tempos de execução revela informação sobre os elementos lidos e, através deles, sobre a chave (Aumasson 2017). É por esta razão que os processadores modernos incluem instruções dedicadas ao AES, como o conjunto AES-NI, que calculam uma ronda completa no próprio circuito, sem tabelas em memória, e resolvem assim os ataques de tempo de cache (Aumasson 2017). Não resolvem, por si sós, os ataques que medem o consumo energético do dispositivo.

Vale ainda a pena antecipar uma questão sobre computação quântica. O algoritmo de Grover, um algoritmo para computadores quânticos, permite encontrar um valor entre $n$ possíveis em tempo proporcional a $\sqrt{n}$, em vez de $n$. Aplicado à procura de uma chave AES-128, reduz o esforço de cerca de $2^{128}$ para cerca de $2^{64}$ passos (Aumasson 2017), um valor hoje considerado insuficiente. É por isso que o AES-256, apesar de mais lento, é a opção recomendada para dados que devam permanecer protegidos a muito longo prazo: mesmo com o algoritmo de Grover, o esforço continua a ser de cerca de $2^{128}$ passos.

3.6 Modos de Operação

Uma cifra de bloco, seja o AES ou o DES, cifra exactamente um bloco de cada vez. Uma mensagem real quase nunca tem exactamente o tamanho de um bloco (128 bits, no caso do AES) — normalmente é maior, por vezes muito maior. Um modo de operação define como aplicar repetidamente a mesma cifra de bloco a uma sequência de blocos, de forma a cifrar uma mensagem de qualquer tamanho.

3.6.1 ECB — Electronic Codebook

O modo mais simples divide a mensagem em blocos e cifra cada um independentemente, com a mesma chave: $C_i = E_K(P_i)$. É simples e paralelizável, mas tem um defeito grave: blocos de texto claro idênticos produzem sempre blocos de texto cifrado idênticos. Isto é exactamente o mesmo problema de fundo já visto na cifra monoalfabética, só que ao nível de blocos de 128 bits em vez de letras individuais: qualquer padrão ou repetição estrutural da mensagem original permanece visível no texto cifrado, mesmo sem se decifrar nada.

Figura 3.7: O modo ECB: cada bloco de texto claro é cifrado (ou decifrado) de forma completamente independente dos restantes, sempre com a mesma chave $K$ — daí a ausência de qualquer ligação entre blocos consecutivos.

Figura 3.8: Um texto claro organizado em blocos, com um padrão estrutural óbvio (moldura, cruz), cifrado em modo ECB e em modo CBC. Sob ECB, blocos de texto claro idênticos geram blocos de texto cifrado idênticos: o padrão original mantém-se perfeitamente visível, apenas com cores (valores) diferentes. Sob CBC, o mesmo padrão desaparece por completo.

3.6.2 CBC — Cipher Block Chaining

O CBC resolve este problema encadeando os blocos: antes de cifrar cada bloco de texto claro, combina-se por XOR com o bloco de texto cifrado anterior.

\[C_i = E_K(P_i \oplus C_{i-1})\]

Como não existe um “bloco anterior” para o primeiro bloco da mensagem, usa-se um vector de inicialização (initialization vector, IV): um bloco aleatório, gerado de novo em cada mensagem, que substitui $C_0$. O IV não precisa de ser secreto, apenas único e imprevisível, e é normalmente transmitido em claro junto com o texto cifrado.

Figura 3.9: O modo CBC: na cifragem (topo), cada bloco de texto claro combina-se por XOR com o bloco de texto cifrado anterior antes de entrar na cifra de bloco, com o IV a substituir esse bloco anterior para o primeiro bloco da mensagem. Na decifragem (baixo), o processo inverte-se: cada bloco de texto cifrado é decifrado e o resultado combina-se por XOR com o bloco de texto cifrado anterior (ou o IV) para recuperar o texto claro.

Como cada bloco cifrado depende de todos os blocos de texto claro anteriores (através da cadeia de XORs), blocos de texto claro idênticos deixam de produzir blocos de texto cifrado idênticos, como se vê na Figura 3.8: o padrão original desaparece completamente. A decifragem inverte exactamente este processo:

\[P_i = D_K(C_i) \oplus C_{i-1}\]

Note-se uma assimetria entre as duas direcções: a decifragem em CBC é paralelizável, porque cada bloco decifrado só depende do bloco de texto cifrado anterior, já disponível na totalidade; a cifragem, pelo contrário, não é, porque cada bloco só pode ser cifrado depois de o anterior estar pronto, uma vez que é o seu resultado que entra na cadeia seguinte.

3.6.3 CFB — Cipher Feedback Mode

O CFB consegue um efeito semelhante ao CBC, eliminar o padrão do ECB, mas por um caminho diferente: em vez de cifrar o texto claro directamente, cifra-se o bloco de texto cifrado anterior, e o resultado combina-se por XOR com o texto claro para produzir o bloco seguinte.

\[C_i = P_i \oplus E_K(C_{i-1})\]

com $C_0 = \text{IV}$. Tal como no CBC, o IV não pode ser reutilizado, mas pode ser público.

O modo CFB: em cada passo, cifra-se o bloco de texto cifrado anterior (ou o IV, no primeiro passo) — nunca o texto claro directamente — e o resultado combina-se por XOR com o texto claro (topo) ou o texto cifrado (baixo, na decifragem) para produzir o bloco seguinte. O CFB comporta-se, na prática, como uma cifra de pseudo-fluxo: em vez de cifrar blocos completos, pode operar sobre segmentos mais pequenos (por exemplo, byte a byte), o que o torna útil para fluxos de dados de comprimento variável. Tal como no CBC, a cifragem não é paralelizável, mas a decifragem é.

3.6.4 CTR — Counter Mode

O CTR segue uma abordagem diferente: em vez de cifrar o texto claro directamente, cifra-se um contador (combinado com um valor único por mensagem, o nonce), e o resultado combina-se por XOR com o texto claro:

\[C_i = P_i \oplus E_K(\text{nonce} \mathbin\Vert i)\]

Figura 3.10: O modo CTR: cada contador $T_i = \text{nonce} \Vert i$ é cifrado independentemente dos restantes, e o resultado combina-se por XOR com o bloco de texto claro (topo) ou de texto cifrado (baixo) correspondente — cifragem e decifragem usam exactamente a mesma operação, `Block Cipher Encryption`.

Isto transforma, na prática, uma cifra de bloco numa cifra de fluxo: cada bloco de saída de $E_K$ funciona como uma sequência de bits pseudo-aleatória, gerada independentemente do texto claro. A vantagem prática mais relevante é que, ao contrário do CBC e do CFB, tanto a cifragem como a decifragem em CTR são inteiramente paralelizáveis: o bloco $i$ não depende do bloco $i-1$, apenas do próprio contador, o que se traduz em desempenho significativamente superior em hardware moderno com múltiplos núcleos.

Este ganho de desempenho tem duas contrapartidas importantes. Primeiro, reutilizar o mesmo nonce é catastrófico: reutilizá-lo produz o mesmo fluxo pseudo-aleatório para duas mensagens diferentes, e um atacante que faça o XOR dos dois textos cifrados cancela esse fluxo e obtém o XOR dos dois textos claros, o que é muitas vezes suficiente para recuperar ambos. Segundo, o CTR é maleável: como a cifragem actua sobre o contador, não sobre o texto claro, a propriedade de difusão do AES nunca chega a actuar sobre a relação entre texto cifrado e texto claro. Um atacante que altere um bit do texto cifrado altera exactamente o bit correspondente do texto claro decifrado, de forma previsível, sem que nada no CTR o detecte.

Confidencialidade não é integridade

Nenhum dos modos apresentados até aqui, ECB, CBC, CFB ou CTR, protege a integridade da mensagem. A própria norma que os define chama-lhes modos de confidencialidade (Dworkin 2001): impedem que um atacante leia a mensagem, mas não que a altere. Um atacante que intercepte o texto cifrado pode modificá-lo, e o receptor decifra a versão adulterada sem dar por nada.

O CTR é o caso extremo. Trocar um bit do texto cifrado troca exactamente o mesmo bit do texto claro decifrado, e nenhum outro (Dworkin 2001, Apêndice D): o atacante escolhe, bit a bit, o efeito que quer produzir. É por isso que a norma do AES-CTR no IPsec considera trivial falsificar um texto cifrado AES-CTR e obriga a usá-lo com autenticação (Russell Housley 2004). O CBC também não está protegido: um bit trocado num bloco estraga esse bloco ao decifrar, mas troca de forma previsível o mesmo bit do bloco seguinte (Dworkin 2001, Apêndice D).

Para detectar alterações, é preciso juntar à mensagem uma marca de autenticação (tag): um valor curto, calculado a partir da mensagem e de uma chave secreta que só o emissor e o receptor conhecem. O algoritmo que calcula esta marca chama-se MAC (message authentication code, código de autenticação de mensagem). O receptor recalcula a marca sobre a mensagem que recebeu e compara-a com a que veio junto: se não coincidirem, a mensagem é rejeitada, e o atacante, sem a chave, não consegue calcular a marca certa para uma mensagem alterada.

Regra prática: um modo de confidencialidade nunca se usa sozinho. Tem de ser acompanhado de uma marca de autenticação, e a forma mais simples de o garantir é usar um modo que faça as duas coisas numa só construção, como o GCM, apresentado a seguir. Os protocolos actuais seguem esta regra: o TLS 1.3, por exemplo, só aceita modos deste tipo (Rescorla 2018).

3.6.5 GCM — Galois/Counter Mode

O GCM (Galois/Counter Mode) resolve o problema da integridade dentro do próprio modo de operação: estende o modo CTR, do qual herda a confidencialidade e a total paralelização, com um MAC próprio, o GHASH. O resultado é uma cifra autenticada, ou, em inglês, authenticated encryption with associated data (AEAD): produz, além do texto cifrado, uma marca de autenticação (tag) de 128 bits, calculada não só sobre o texto cifrado mas também sobre os dados adicionais autenticados (additional authenticated data, AAD). São partes da mensagem que têm de seguir em claro, mas que não podem ser alteradas, como os cabeçalhos de rede, que os equipamentos de rede precisam de ler para encaminhar a mensagem. Qualquer alteração, ao texto cifrado ou ao AAD, invalida a marca.

O nome GHASH vem de Galois hash. É a parte do GCM que calcula a marca, e funciona em cadeia: percorre o AAD, cada bloco de texto cifrado e, no fim, um bloco com os comprimentos de ambos; em cada passo, junta o bloco seguinte ao valor acumulado, por XOR, e multiplica o resultado por um valor $H$. Esse valor é $H = E_K(0^{128})$, o bloco de 128 zeros cifrado com a chave: como depende da chave, é secreto, e é isso que impede um atacante de calcular a marca de uma mensagem alterada. A multiplicação por $H$ tem dois propósitos. Como o valor acumulado volta a ser multiplicado por $H$ a cada passo, cada bloco acaba multiplicado por uma potência diferente de $H$ (o último por $H$, o penúltimo por $H^2$, e assim sucessivamente), pelo que a marca depende não só de todos os blocos mas também da posição de cada um; se os blocos fossem apenas combinados por XOR, trocar dois deles de lugar deixaria a marca igual. Além disso, só com XOR um atacante saberia prever o efeito de qualquer alteração sobre a marca; multiplicado por um valor secreto, deixa de saber (Dworkin 2007). “Galois” refere-se à aritmética usada nesta multiplicação, uma aritmética especial sobre blocos de 128 bits a que se chama corpo de Galois, $GF(2^{128})$, cujos detalhes não são necessários aqui; “hash” refere-se ao facto de o resultado resumir todos os blocos num único valor de 128 bits.

A Figura 3.11 mostra como as duas partes se articulam. Na parte de cima está o CTR já conhecido: os contadores $\text{nonce} \Vert 2$, $\text{nonce} \Vert 3$, … são cifrados com a chave $K$ e combinados por XOR com os blocos de texto claro. Na parte de baixo está a cadeia do GHASH. O primeiro contador, $J_0 = \text{nonce} \Vert 1$, não cifra dados: o resultado de o cifrar serve apenas para mascarar, por XOR, a saída do GHASH, e é daí que sai a tag.

Figura 3.11: O modo GCM (NIST SP 800-38D), para um *nonce* de 96 bits. Em cima, a cifragem em modo CTR a partir do contador 2; em baixo, a cadeia GHASH sobre o AAD, os blocos de texto cifrado e os respectivos comprimentos. A *tag* resulta do XOR entre a saída do GHASH e $E_K(J_0)$.

O que segue no canal são, assim, três componentes (Figura 3.12): o AAD, em claro mas autenticado; o texto cifrado, confidencial e autenticado; e a tag. O receptor, que conhece a chave, repete o cálculo do GHASH sobre o AAD e o texto cifrado recebidos e compara o resultado com a tag: se diferirem num único bit, a mensagem é rejeitada antes de ser decifrada.

Figura 3.12: O que segue no canal numa mensagem GCM: o AAD (visível, autenticado), o texto cifrado (confidencial, autenticado) e a *tag* de 128 bits.

Tal como no CTR, a reutilização do nonce (recomendado a 96 bits) em GCM é catastrófica, e já foi explorada em ataques práticos de falsificação contra implementações reais de TLS (Böck et al. 2016). Por combinar confidencialidade, integridade e paralelização total, o GCM é hoje o modo recomendado para a generalidade das aplicações novas, usado, entre outros, no TLS 1.3, no SSH, no IPsec e no QUIC.

3.6.6 Comparação dos modos de operação

Tabela 3.1: Comparação dos modos de operação apresentados neste capítulo (Dworkin 2001, 2007)

Modo	IV / nonce	Paralelizável (cifra / decifra)	Padding	Autenticação nativa	Uso recomendado
ECB	Nenhum	Sim / Sim	Sim	Não	Nunca (revela padrões)
CBC	IV aleatório	Não / Sim	Sim	Não	Uso legado; substituir por AEAD
CFB	IV aleatório	Não / Sim	Não	Não	Fluxos de dados de comprimento variável
CTR	Nonce único	Sim / Sim	Não	Não	Alto débito, sem necessidade de autenticação
GCM	Nonce único (96 bits)	Sim / Sim	Não	Sim (GHASH, 128 bits)	Recomendado (TLS 1.3, SSH, IPsec, QUIC)

3.7 Padding

Uma cifra de bloco, como o AES, cifra sempre um bloco de tamanho fixo, 128 bits (16 bytes). Nem todas as mensagens têm um comprimento múltiplo exacto desse tamanho: quando o último bloco de uma mensagem não está completo, o algoritmo de cifragem não tem bytes suficientes para o processar.

O padding resolve isto acrescentando bytes extra ao fim da mensagem, antes da cifragem, até completar esse último bloco. O esquema mais comum é o PKCS#7: se faltam $n$ bytes para completar o bloco, acrescentam-se $n$ bytes, todos com o valor $n$. Por exemplo, se faltam 10 bytes para completar o bloco, acrescentam-se dez bytes, todos com o valor 0x0A. Há uma regra que é fácil esquecer: se a mensagem já tiver um comprimento múltiplo exacto do bloco, acrescenta-se mesmo assim um bloco inteiro de padding, 16 bytes com o valor 0x10. É esta regra que permite à decifragem ler sempre o último byte recebido e saber exactamente quantos bytes remover, sem qualquer ambiguidade (Russ Housley 2009): sem ela, uma mensagem que terminasse por acaso no byte 0x01 perderia esse byte ao ser decifrada, confundido com padding.

Nem todos os modos apresentados neste capítulo precisam de padding: só os que cifram o texto claro directamente, bloco a bloco, como o ECB e o CBC (Tabela 3.1). O CTR e o GCM, por transformarem a cifra de bloco numa espécie de cifra de fluxo, combinando-a com o texto claro por XOR em vez de a aplicar directamente, dispensam-no inteiramente: podem cifrar mensagens de qualquer comprimento, byte a byte, sem nunca precisar de completar um bloco final.

Vale a pena assinalar desde já uma consequência de segurança importante: uma validação de padding mal implementada, que revele a um atacante, através de uma mensagem de erro ou de uma diferença de tempo de resposta, se o padding recebido era ou não válido, pode ser explorada para decifrar mensagens inteiras sem nunca conhecer a chave, byte a byte, através do chamado ataque de oráculo de padding (padding oracle attack). A lição de fundo é uma que se repete ao longo deste livro: um mecanismo matematicamente correcto pode ainda assim falhar por causa de como é implementado.

3.8 Síntese do Capítulo

Este capítulo apresentou o algoritmo que hoje ocupa o lugar do DES, e a forma como se aplica a mensagens de qualquer tamanho:

O AES resultou de um concurso público do NIST, vencido pelo algoritmo Rijndael, e normalizado em 2001
Ao contrário do DES, o AES não é uma rede de Feistel: é uma rede de substituição-permutação (SPN), em que cada ronda transforma o bloco inteiro
O bloco é sempre de 128 bits; a chave pode ser de 128, 192 ou 256 bits, com 10, 12 ou 14 rondas, respectivamente
Cada ronda aplica quatro transformações: SubBytes (confusão, via S-box não linear), ShiftRows e MixColumns (difusão, entre e dentro de colunas), e AddRoundKey, o único passo que usa a chave; a segurança do AES vem da alternância entre o XOR com a chave e a baralhação pública das outras três transformações
Não existe, até hoje, nenhum ataque criptanalítico com utilidade prática contra o AES (o melhor, de 2011, precisa de cerca de $2^{126}$ operações e de uma quantidade absurda de dados); as vulnerabilidades reais são de implementação, como os ataques de tempo de cache, que as instruções AES-NI resolvem
Um modo de operação define como aplicar uma cifra de bloco a mensagens maiores do que um bloco: o ECB é simples mas revela padrões estruturais; o CBC e o CFB encadeiam os blocos e eliminam-os, à custa da cifragem não ser paralelizável; o CTR cifra um contador e combina o resultado com o texto claro por XOR, o que o torna totalmente paralelizável, mas obriga a nunca reutilizar o nonce e permite alterar o texto claro bit a bit
Confidencialidade não é integridade: nenhum destes modos impede que o texto cifrado seja alterado sem detecção (no CTR, o atacante troca exactamente os bits que quer); por isso, um modo de confidencialidade nunca se usa sozinho, mas sempre acompanhado de um MAC, que calcula uma marca de autenticação
O GCM combina o CTR com o GHASH, um MAC que percorre o AAD e o texto cifrado multiplicando o valor acumulado por um valor secreto $H$, numa construção AEAD que é hoje o modo recomendado para a generalidade das aplicações novas
O padding (nomeadamente o esquema PKCS#7) permite aos modos que cifram directamente bloco a bloco, como o ECB e o CBC, processar mensagens de qualquer comprimento, acrescentando um bloco inteiro quando a mensagem já é múltipla do bloco; o CTR e o GCM dispensam-no. Uma implementação que revele se o padding recebido é válido abre a porta a ataques de oráculo de padding

3.9 Para Pensar

O DES combina confusão e difusão através de uma única função $F$, aplicada apenas a metade do bloco por ronda. O AES separa estas duas propriedades em transformações distintas (SubBytes para a confusão, ShiftRows/MixColumns para a difusão), aplicadas ao bloco inteiro. Que vantagens pode trazer esta separação explícita, tanto para a análise de segurança do algoritmo como para o seu desempenho em hardware?

Referências

--- title: "AES — Estágios e Modos de Operação" author: "João Pavão" date: 2026-09-14 lang: pt-PT --- ## Introdução {#sec-03-intro .unnumbered} O capítulo anterior terminou com uma conclusão incómoda: o DES, durante décadas o pilar da cifra simétrica, está obsoleto, e o 3DES, a solução de recurso, é lento e continua limitado pelo bloco de 64 bits herdado do original. Era necessário um sucessor desenhado de raiz, não remendado. Este capítulo apresenta esse sucessor: o **AES** (*Advanced Encryption Standard*), o algoritmo de cifra simétrica hoje universalmente adoptado, de aplicações bancárias a comunicações protegidas por TLS. A segunda parte do capítulo trata de uma questão distinta, mas igualmente prática: uma cifra de bloco só cifra um bloco de cada vez, então como se cifra uma mensagem real, quase sempre maior do que isso? ## Do DES ao AES: um Novo Paradigma {#sec-03-contexto} Em 1997, o *National Institute of Standards and Technology* (NIST) dos Estados Unidos lançou um concurso público e aberto para escolher o sucessor do DES, ao contrário do processo fechado que tinha originado o próprio DES duas décadas antes. Qualquer equipa, de qualquer país, podia submeter um algoritmo, que seria depois escrutinado publicamente por toda a comunidade criptográfica mundial. Quinze algoritmos foram submetidos. Cinco chegaram à fase final: MARS, RC6, Rijndael, Serpent e Twofish. Em Outubro de 2000, o NIST anunciou o vencedor: **Rijndael**, desenhado pelos criptógrafos belgas Joan Daemen e Vincent Rijmen. O algoritmo foi formalizado como norma federal em 2001, sob o nome AES [@FIPS197]. **A diferença estrutural mais importante em relação ao DES não é o tamanho da chave ou do bloco, é a arquitectura interna.** O DES, como se viu, é uma rede de Feistel: em cada ronda, apenas metade do bloco atravessa a função não linear $F$, enquanto a outra metade passa praticamente incólume, apenas combinada por XOR. O AES abandona esta estrutura. É uma **rede de substituição-permutação** (*substitution-permutation network*, SPN): em cada ronda, o **bloco inteiro** é transformado, através de uma sequência de quatro operações distintas aplicadas a todos os seus bytes. ## Estrutura Geral do AES {#sec-03-estrutura} Ao contrário do DES, em que o tamanho do bloco (64 bits) e o da chave (56 bits efectivos) estão fixados pela norma, o AES separa estas duas dimensões: - **Bloco**: sempre **128 bits** (16 bytes), independentemente do tamanho da chave. - **Chave**: **128, 192 ou 256 bits**, dando origem a três variantes — AES-128, AES-192 e AES-256. - **Número de rondas**: depende do tamanho da chave — **10 rondas** para AES-128, **12** para AES-192, **14** para AES-256. Chaves maiores implicam mais rondas, porque cada ronda adicional dificulta ainda mais qualquer tentativa de análise estatística ou algébrica do algoritmo. Internamente, o bloco de 128 bits organiza-se numa matriz $4 \times 4$ de bytes, a que se chama **estado** (*state*), preenchida coluna a coluna: os primeiros 4 bytes do bloco ocupam a primeira coluna, os 4 seguintes a segunda, e assim sucessivamente. Todas as transformações de ronda operam sobre esta matriz. ![O estado do AES: o bloco de 128 bits (16 bytes) organiza-se numa matriz $4\times4$, preenchida coluna a coluna (byte 0 a byte 3 na primeira coluna, byte 4 a byte 7 na segunda, e assim sucessivamente).](../assets/images/fig-03-aes-estado.png){#fig-03-aes-estado width=45%} O AES puro é **determinístico**: o mesmo bloco de texto claro, com a mesma chave, produz sempre o mesmo bloco de texto cifrado. Esta previsibilidade é inaceitável na prática — é precisamente o problema que, como se verá adiante, obriga a recorrer a um modo de operação, que introduz aleatoriedade através de um vector de inicialização ou *nonce*. ## As Quatro Transformações de Ronda {#sec-03-transformacoes} Cada ronda do AES (excepto a última) aplica, por esta ordem, quatro transformações à matriz de estado. Antes da primeira ronda, aplica-se ainda um `AddRoundKey` inicial, e a última ronda omite o `MixColumns`. O objectivo destas quatro operações não é apenas ocultar o texto original, mas fazê-lo de forma que uma alteração mínima, um único bit, na mensagem ou na chave, produza alterações significativas e imprevisíveis no texto cifrado — o chamado **efeito avalanche**. ### SubBytes {#sec-03-subbytes} `SubBytes` é a única operação não linear do AES, e é ela que fornece a **confusão**: cada byte do estado é substituído pelo byte correspondente numa tabela fixa de substituição, a **S-box**, construída a partir do inverso multiplicativo no corpo finito $GF(2^8)$ seguido de uma transformação afim. Ao contrário do DES, que usa oito S-boxes diferentes (uma por grupo de 6 bits), o AES usa uma **única S-box**, reaplicada byte a byte a toda a matriz de estado. ![No passo SubBytes, cada byte do estado é substituído pelo byte correspondente numa S-box fixa. Fonte: Wikimedia Commons, domínio público.](../assets/images/fig-03-AES-SubBytes.png){#fig-03-subbytes width=60%} ### ShiftRows {#sec-03-shiftrows} `ShiftRows` desloca ciclicamente cada linha da matriz de estado para a esquerda: a linha 0 não se altera, a linha 1 desloca-se 1 posição, a linha 2 desloca-se 2 posições, a linha 3 desloca-se 3 posições. Esta operação é simples, mas essencial: garante que os bytes de uma coluna deixam de pertencer todos à mesma coluna, espalhando a influência de cada byte por várias colunas nas rondas seguintes. ![No passo ShiftRows, cada linha da matriz de estado é deslocada ciclicamente para a esquerda, um número de posições diferente por linha. Fonte: Wikimedia Commons, domínio público.](../assets/images/fig-03-AES-ShiftRows.png){#fig-03-shiftrows width=75%} ### MixColumns {#sec-03-mixcolumns} `MixColumns` opera sobre cada coluna da matriz de estado independentemente, tratando-a como um polinómio de grau 3 sobre $GF(2^8)$ e multiplicando-a por um polinómio fixo $c(x)$, módulo $x^4+1$. O efeito prático é que cada byte de saída de uma coluna passa a depender dos quatro bytes de entrada dessa mesma coluna. Combinado com o `ShiftRows` anterior, garante que, ao fim de poucas rondas, cada byte de saída depende de todos os bytes de entrada do bloco: é a **difusão** do AES. Esta transformação omite-se na última ronda. ![No passo MixColumns, cada coluna da matriz de estado é multiplicada por um polinómio fixo $c(x)$, misturando os seus quatro bytes. Fonte: Wikimedia Commons, domínio público.](../assets/images/fig-03-AES-MixColumns.png){#fig-03-mixcolumns width=75%} ### AddRoundKey {#sec-03-addroundkey} `AddRoundKey` é a única transformação que envolve a chave: cada byte do estado combina-se por XOR com o byte correspondente da subchave dessa ronda, derivada da chave principal pelo **esquema de expansão de chave** (*key schedule*). As outras três transformações não usam a chave: são públicas, e qualquer pessoa as consegue desfazer. Dão confusão, difusão e não-linearidade, mas, sozinhas, não dão segurança nenhuma. O `AddRoundKey`, por sua vez, é o único passo que não se desfaz sem a chave, mas, sozinho, também é fraco: é um XOR com uma chave fixa, uma espécie de cifra de Vernam, e basta conhecer um bloco de texto claro e o respectivo texto cifrado para obter a chave com um único XOR. A segurança do AES vem da alternância entre os dois: um XOR com a chave, seguido da baralhação pública das outras três transformações, seguido de novo XOR com a chave, e assim sucessivamente [@Stallings2020]. É também por isso que o AES começa e acaba com um `AddRoundKey`: qualquer outro passo, colocado no início ou no fim, seria público e poderia ser desfeito sem conhecer a chave, pelo que não acrescentaria segurança nenhuma. ![No passo AddRoundKey, cada byte do estado combina-se por XOR com o byte correspondente da subchave da ronda. Fonte: Wikimedia Commons, domínio público.](../assets/images/fig-03-AES-AddRoundKey.png){#fig-03-addroundkey width=60%} ## A Ronda Completa e a Expansão de Chave {#sec-03-ronda-expansao} Uma ronda intermédia do AES aplica, por esta ordem, `SubBytes`, `ShiftRows`, `MixColumns` e `AddRoundKey`. A última ronda omite o `MixColumns`, e há ainda um `AddRoundKey` inicial, antes de qualquer ronda, usando a própria chave original sem expansão. ![A estrutura completa do AES: um `AddRoundKey` inicial, seguido de $N_r-1$ rondas intermédias (`SubBytes`, `ShiftRows`, `MixColumns`, `AddRoundKey`), e uma ronda final que omite o `MixColumns`.](../assets/images/fig-03-aes-rondas-estrutura.png){#fig-03-rondas-estrutura width=75%} Isto significa que um AES de $N_r$ rondas precisa de $N_r+1$ subchaves de 128 bits: uma para o `AddRoundKey` inicial, mais uma por ronda. Estas subchaves não são fragmentos independentes da chave original, mas são geradas por um **esquema de expansão de chave**, que trabalha com palavras de 32 bits (4 bytes). No AES-128, com 10 rondas, são precisas 11 subchaves de 4 palavras cada, ou seja, 44 palavras, $w_0$ a $w_{43}$; no AES-192 são 52 palavras, e no AES-256 são 60 [@FIPS197]. As quatro primeiras palavras são a própria chave, e é por isso que o `AddRoundKey` inicial usa a chave original. Cada palavra seguinte obtém-se por XOR entre a palavra anterior e a que está quatro posições atrás; de quatro em quatro palavras, a palavra anterior passa primeiro por uma rotação dos seus bytes, pela mesma S-box do `SubBytes` e por um XOR com uma constante de ronda fixa. A decifragem usa exactamente as mesmas subchaves, mas por ordem inversa, da última para a primeira, porque desfaz as rondas pela ordem contrária; o essencial é reter que todas as subchaves derivam de uma única chave secreta, e que a sua geração é determinística e pública, tal como toda a restante estrutura do algoritmo: a segurança do AES reside inteiramente na chave, nunca no segredo do desenho, tal como o princípio de Kerckhoffs exige. ## Segurança do AES {#sec-03-seguranca} Desde a sua normalização em 2001, o AES foi sujeito a um escrutínio criptanalítico intenso e contínuo, sem que se tenha encontrado qualquer ataque com utilidade prática. O melhor resultado conhecido, de 2011, recupera uma chave AES-128 com cerca de $2^{126}$ operações em vez de $2^{128}$, isto é, quatro vezes mais depressa do que a força bruta, mas exige uma quantidade absurda de pares de texto claro e texto cifrado, da ordem de $2^{88}$ bits [@Aumasson2017]. O espaço de chaves mínimo, $2^{128}$, torna a força bruta pura astronomicamente inviável, muito além do que já era o caso para o DES. Na prática, as vulnerabilidades reais associadas ao AES não são matemáticas, mas de implementação: **ataques de canal lateral** (*side-channel*), que exploram informação indirecta, como o tempo de execução ou o consumo energético de um dispositivo a cifrar, em vez de atacar o algoritmo em si. O exemplo clássico são os ataques de **tempo de cache** (*cache-timing*). As implementações do AES em software usam tabelas guardadas em memória, e o elemento da tabela que é lido em cada passo depende da chave. O tempo que esse acesso demora varia consoante o elemento já está ou não na memória *cache* do processador, pelo que medir tempos de execução revela informação sobre os elementos lidos e, através deles, sobre a chave [@Aumasson2017]. É por esta razão que os processadores modernos incluem instruções dedicadas ao AES, como o conjunto **AES-NI**, que calculam uma ronda completa no próprio circuito, sem tabelas em memória, e resolvem assim os ataques de tempo de cache [@Aumasson2017]. Não resolvem, por si sós, os ataques que medem o consumo energético do dispositivo. Vale ainda a pena antecipar uma questão sobre computação quântica. O **algoritmo de Grover**, um algoritmo para computadores quânticos, permite encontrar um valor entre $n$ possíveis em tempo proporcional a $\sqrt{n}$, em vez de $n$. Aplicado à procura de uma chave AES-128, reduz o esforço de cerca de $2^{128}$ para cerca de $2^{64}$ passos [@Aumasson2017], um valor hoje considerado insuficiente. É por isso que o AES-256, apesar de mais lento, é a opção recomendada para dados que devam permanecer protegidos a muito longo prazo: mesmo com o algoritmo de Grover, o esforço continua a ser de cerca de $2^{128}$ passos. ## Modos de Operação {#sec-03-modos} Uma cifra de bloco, seja o AES ou o DES, cifra exactamente um bloco de cada vez. Uma mensagem real quase nunca tem exactamente o tamanho de um bloco (128 bits, no caso do AES) — normalmente é maior, por vezes muito maior. Um **modo de operação** define como aplicar repetidamente a mesma cifra de bloco a uma sequência de blocos, de forma a cifrar uma mensagem de qualquer tamanho. ### ECB — Electronic Codebook {#sec-03-ecb} O modo mais simples divide a mensagem em blocos e cifra cada um independentemente, com a mesma chave: $C_i = E_K(P_i)$. É simples e paralelizável, mas tem um defeito grave: **blocos de texto claro idênticos produzem sempre blocos de texto cifrado idênticos**. Isto é exactamente o mesmo problema de fundo já visto na cifra monoalfabética, só que ao nível de blocos de 128 bits em vez de letras individuais: qualquer padrão ou repetição estrutural da mensagem original permanece visível no texto cifrado, mesmo sem se decifrar nada. ![O modo ECB: cada bloco de texto claro é cifrado (ou decifrado) de forma completamente independente dos restantes, sempre com a mesma chave $K$ — daí a ausência de qualquer ligação entre blocos consecutivos.](../assets/images/fig-03-modo-ecb.png){#fig-03-modo-ecb width=90%} ![Um texto claro organizado em blocos, com um padrão estrutural óbvio (moldura, cruz), cifrado em modo ECB e em modo CBC. Sob ECB, blocos de texto claro idênticos geram blocos de texto cifrado idênticos: o padrão original mantém-se perfeitamente visível, apenas com cores (valores) diferentes. Sob CBC, o mesmo padrão desaparece por completo.](../assets/images/fig-03-ecb-vs-cbc.png){#fig-03-ecb-cbc width=95%} ### CBC — Cipher Block Chaining {#sec-03-cbc} O **CBC** resolve este problema encadeando os blocos: antes de cifrar cada bloco de texto claro, combina-se por XOR com o bloco de texto cifrado anterior. $$C_i = E_K(P_i \oplus C_{i-1})$$ Como não existe um "bloco anterior" para o primeiro bloco da mensagem, usa-se um **vector de inicialização** (*initialization vector*, IV): um bloco aleatório, gerado de novo em cada mensagem, que substitui $C_0$. O IV não precisa de ser secreto, apenas único e imprevisível, e é normalmente transmitido em claro junto com o texto cifrado. ![O modo CBC: na cifragem (topo), cada bloco de texto claro combina-se por XOR com o bloco de texto cifrado anterior antes de entrar na cifra de bloco, com o IV a substituir esse bloco anterior para o primeiro bloco da mensagem. Na decifragem (baixo), o processo inverte-se: cada bloco de texto cifrado é decifrado e o resultado combina-se por XOR com o bloco de texto cifrado anterior (ou o IV) para recuperar o texto claro.](../assets/images/fig-03-modo-cbc.png){#fig-03-modo-cbc width=95%} Como cada bloco cifrado depende de todos os blocos de texto claro anteriores (através da cadeia de XORs), blocos de texto claro idênticos deixam de produzir blocos de texto cifrado idênticos, como se vê na Figura [-@fig-03-ecb-cbc]: o padrão original desaparece completamente. A decifragem inverte exactamente este processo: $$P_i = D_K(C_i) \oplus C_{i-1}$$ Note-se uma assimetria entre as duas direcções: a **decifragem** em CBC é paralelizável, porque cada bloco decifrado só depende do bloco de texto cifrado anterior, já disponível na totalidade; a **cifragem**, pelo contrário, não é, porque cada bloco só pode ser cifrado depois de o anterior estar pronto, uma vez que é o seu resultado que entra na cadeia seguinte. ### CFB — Cipher Feedback Mode {#sec-03-cfb} O **CFB** consegue um efeito semelhante ao CBC, eliminar o padrão do ECB, mas por um caminho diferente: em vez de cifrar o texto claro directamente, cifra-se o bloco de texto cifrado anterior, e o resultado combina-se por XOR com o texto claro para produzir o bloco seguinte. $$C_i = P_i \oplus E_K(C_{i-1})$$ com $C_0 = \text{IV}$. Tal como no CBC, o IV não pode ser reutilizado, mas pode ser público. ![O modo CFB: em cada passo, cifra-se o bloco de texto cifrado anterior (ou o IV, no primeiro passo) — nunca o texto claro directamente — e o resultado combina-se por XOR com o texto claro (topo) ou o texto cifrado (baixo, na decifragem) para produzir o bloco seguinte.](../assets/images/fig-03-modo-cfb.png){#fig-03-modo-cfb width=95%} O CFB comporta-se, na prática, como uma **cifra de pseudo-fluxo**: em vez de cifrar blocos completos, pode operar sobre segmentos mais pequenos (por exemplo, byte a byte), o que o torna útil para fluxos de dados de comprimento variável. Tal como no CBC, a cifragem não é paralelizável, mas a decifragem é. ### CTR — Counter Mode {#sec-03-ctr} O **CTR** segue uma abordagem diferente: em vez de cifrar o texto claro directamente, cifra-se um contador (combinado com um valor único por mensagem, o *nonce*), e o resultado combina-se por XOR com o texto claro: $$C_i = P_i \oplus E_K(\text{nonce} \mathbin\Vert i)$$ ![O modo CTR: cada contador $T_i = \text{nonce} \Vert i$ é cifrado independentemente dos restantes, e o resultado combina-se por XOR com o bloco de texto claro (topo) ou de texto cifrado (baixo) correspondente — cifragem e decifragem usam exactamente a mesma operação, `Block Cipher Encryption`.](../assets/images/fig-03-modo-ctr.png){#fig-03-modo-ctr width=95%} Isto transforma, na prática, uma cifra de bloco numa cifra de fluxo: cada bloco de saída de $E_K$ funciona como uma sequência de bits pseudo-aleatória, gerada independentemente do texto claro. A vantagem prática mais relevante é que, ao contrário do CBC e do CFB, tanto a cifragem como a decifragem em CTR são inteiramente **paralelizáveis**: o bloco $i$ não depende do bloco $i-1$, apenas do próprio contador, o que se traduz em desempenho significativamente superior em hardware moderno com múltiplos núcleos. Este ganho de desempenho tem duas contrapartidas importantes. Primeiro, **reutilizar o mesmo nonce é catastrófico**: reutilizá-lo produz o mesmo fluxo pseudo-aleatório para duas mensagens diferentes, e um atacante que faça o XOR dos dois textos cifrados cancela esse fluxo e obtém o XOR dos dois textos claros, o que é muitas vezes suficiente para recuperar ambos. Segundo, o CTR é **maleável**: como a cifragem actua sobre o contador, não sobre o texto claro, a propriedade de difusão do AES nunca chega a actuar sobre a relação entre texto cifrado e texto claro. Um atacante que altere um bit do texto cifrado altera exactamente o bit correspondente do texto claro decifrado, de forma previsível, sem que nada no CTR o detecte. ::: {.callout-important} ## Confidencialidade não é integridade Nenhum dos modos apresentados até aqui, ECB, CBC, CFB ou CTR, protege a **integridade** da mensagem. A própria norma que os define chama-lhes *modos de confidencialidade* [@NIST80038A]: impedem que um atacante leia a mensagem, mas não que a altere. Um atacante que intercepte o texto cifrado pode modificá-lo, e o receptor decifra a versão adulterada sem dar por nada. O CTR é o caso extremo. Trocar um bit do texto cifrado troca exactamente o mesmo bit do texto claro decifrado, e nenhum outro [@NIST80038A, Apêndice D]: o atacante escolhe, bit a bit, o efeito que quer produzir. É por isso que a norma do AES-CTR no IPsec considera trivial falsificar um texto cifrado AES-CTR e **obriga** a usá-lo com autenticação [@RFC3686]. O CBC também não está protegido: um bit trocado num bloco estraga esse bloco ao decifrar, mas troca de forma previsível o mesmo bit do bloco seguinte [@NIST80038A, Apêndice D]. Para detectar alterações, é preciso juntar à mensagem uma **marca de autenticação** (*tag*): um valor curto, calculado a partir da mensagem e de uma chave secreta que só o emissor e o receptor conhecem. O algoritmo que calcula esta marca chama-se **MAC** (*message authentication code*, código de autenticação de mensagem). O receptor recalcula a marca sobre a mensagem que recebeu e compara-a com a que veio junto: se não coincidirem, a mensagem é rejeitada, e o atacante, sem a chave, não consegue calcular a marca certa para uma mensagem alterada. **Regra prática: um modo de confidencialidade nunca se usa sozinho.** Tem de ser acompanhado de uma marca de autenticação, e a forma mais simples de o garantir é usar um modo que faça as duas coisas numa só construção, como o GCM, apresentado a seguir. Os protocolos actuais seguem esta regra: o TLS 1.3, por exemplo, só aceita modos deste tipo [@RFC8446]. ::: ### GCM — Galois/Counter Mode {#sec-03-gcm} O **GCM** (*Galois/Counter Mode*) resolve o problema da integridade dentro do próprio modo de operação: estende o modo CTR, do qual herda a confidencialidade e a total paralelização, com um MAC próprio, o **GHASH**. O resultado é uma **cifra autenticada**, ou, em inglês, *authenticated encryption with associated data* (AEAD): produz, além do texto cifrado, uma marca de autenticação (*tag*) de 128 bits, calculada não só sobre o texto cifrado mas também sobre os **dados adicionais autenticados** (*additional authenticated data*, AAD). São partes da mensagem que têm de seguir em claro, mas que não podem ser alteradas, como os cabeçalhos de rede, que os equipamentos de rede precisam de ler para encaminhar a mensagem. Qualquer alteração, ao texto cifrado ou ao AAD, invalida a marca. O nome **GHASH** vem de *Galois hash*. É a parte do GCM que calcula a marca, e funciona em cadeia: percorre o AAD, cada bloco de texto cifrado e, no fim, um bloco com os comprimentos de ambos; em cada passo, junta o bloco seguinte ao valor acumulado, por XOR, e multiplica o resultado por um valor $H$. Esse valor é $H = E_K(0^{128})$, o bloco de 128 zeros cifrado com a chave: como depende da chave, é secreto, e é isso que impede um atacante de calcular a marca de uma mensagem alterada. A multiplicação por $H$ tem dois propósitos. Como o valor acumulado volta a ser multiplicado por $H$ a cada passo, cada bloco acaba multiplicado por uma potência diferente de $H$ (o último por $H$, o penúltimo por $H^2$, e assim sucessivamente), pelo que a marca depende não só de todos os blocos mas também da posição de cada um; se os blocos fossem apenas combinados por XOR, trocar dois deles de lugar deixaria a marca igual. Além disso, só com XOR um atacante saberia prever o efeito de qualquer alteração sobre a marca; multiplicado por um valor secreto, deixa de saber [@NIST80038D]. "Galois" refere-se à aritmética usada nesta multiplicação, uma aritmética especial sobre blocos de 128 bits a que se chama corpo de Galois, $GF(2^{128})$, cujos detalhes não são necessários aqui; "*hash*" refere-se ao facto de o resultado resumir todos os blocos num único valor de 128 bits. A @fig-03-modo-gcm mostra como as duas partes se articulam. Na parte de cima está o CTR já conhecido: os contadores $\text{nonce} \Vert 2$, $\text{nonce} \Vert 3$, ... são cifrados com a chave $K$ e combinados por XOR com os blocos de texto claro. Na parte de baixo está a cadeia do GHASH. O primeiro contador, $J_0 = \text{nonce} \Vert 1$, não cifra dados: o resultado de o cifrar serve apenas para mascarar, por XOR, a saída do GHASH, e é daí que sai a *tag*. ![O modo GCM (NIST SP 800-38D), para um *nonce* de 96 bits. Em cima, a cifragem em modo CTR a partir do contador 2; em baixo, a cadeia GHASH sobre o AAD, os blocos de texto cifrado e os respectivos comprimentos. A *tag* resulta do XOR entre a saída do GHASH e $E_K(J_0)$.](../assets/images/fig-03-modo-gcm.png){#fig-03-modo-gcm width="100%"} O que segue no canal são, assim, três componentes (@fig-03-gcm-pacote): o AAD, em claro mas autenticado; o texto cifrado, confidencial e autenticado; e a *tag*. O receptor, que conhece a chave, repete o cálculo do GHASH sobre o AAD e o texto cifrado recebidos e compara o resultado com a *tag*: se diferirem num único bit, a mensagem é rejeitada antes de ser decifrada. ![O que segue no canal numa mensagem GCM: o AAD (visível, autenticado), o texto cifrado (confidencial, autenticado) e a *tag* de 128 bits.](../assets/images/fig-03-gcm-pacote.png){#fig-03-gcm-pacote width="85%"} Tal como no CTR, a reutilização do *nonce* (recomendado a 96 bits) em GCM é catastrófica, e já foi explorada em ataques práticos de falsificação contra implementações reais de TLS [@Bock2016]. Por combinar confidencialidade, integridade e paralelização total, o GCM é hoje o modo **recomendado** para a generalidade das aplicações novas, usado, entre outros, no TLS 1.3, no SSH, no IPsec e no QUIC. ### Comparação dos modos de operação {#sec-03-modos-comparacao} | Modo | IV / nonce | Paralelizável (cifra / decifra) | *Padding* | Autenticação nativa | Uso recomendado | |---|---|---|---|---|---| | ECB | Nenhum | Sim / Sim | Sim | Não | Nunca (revela padrões) | | CBC | IV aleatório | Não / Sim | Sim | Não | Uso legado; substituir por AEAD | | CFB | IV aleatório | Não / Sim | Não | Não | Fluxos de dados de comprimento variável | | CTR | Nonce único | Sim / Sim | Não | Não | Alto débito, sem necessidade de autenticação | | GCM | Nonce único (96 bits) | Sim / Sim | Não | Sim (GHASH, 128 bits) | Recomendado (TLS 1.3, SSH, IPsec, QUIC) | : Comparação dos modos de operação apresentados neste capítulo [@NIST80038A; @NIST80038D] {#tbl-03-modos} ## Padding {#sec-03-padding} Uma cifra de bloco, como o AES, cifra sempre um bloco de tamanho fixo, 128 bits (16 bytes). Nem todas as mensagens têm um comprimento múltiplo exacto desse tamanho: quando o último bloco de uma mensagem não está completo, o algoritmo de cifragem não tem bytes suficientes para o processar. O **padding** resolve isto acrescentando bytes extra ao fim da mensagem, antes da cifragem, até completar esse último bloco. O esquema mais comum é o **PKCS#7**: se faltam $n$ bytes para completar o bloco, acrescentam-se $n$ bytes, todos com o valor $n$. Por exemplo, se faltam 10 bytes para completar o bloco, acrescentam-se dez bytes, todos com o valor `0x0A`. Há uma regra que é fácil esquecer: se a mensagem já tiver um comprimento múltiplo exacto do bloco, acrescenta-se mesmo assim um bloco inteiro de *padding*, 16 bytes com o valor `0x10`. É esta regra que permite à decifragem ler sempre o último byte recebido e saber exactamente quantos bytes remover, sem qualquer ambiguidade [@RFC5652]: sem ela, uma mensagem que terminasse por acaso no byte `0x01` perderia esse byte ao ser decifrada, confundido com *padding*. Nem todos os modos apresentados neste capítulo precisam de *padding*: só os que cifram o texto claro directamente, bloco a bloco, como o **ECB** e o **CBC** (Tabela [-@tbl-03-modos]). O **CTR** e o **GCM**, por transformarem a cifra de bloco numa espécie de cifra de fluxo, combinando-a com o texto claro por XOR em vez de a aplicar directamente, dispensam-no inteiramente: podem cifrar mensagens de qualquer comprimento, byte a byte, sem nunca precisar de completar um bloco final. Vale a pena assinalar desde já uma consequência de segurança importante: uma validação de *padding* mal implementada, que revele a um atacante, através de uma mensagem de erro ou de uma diferença de tempo de resposta, se o *padding* recebido era ou não válido, pode ser explorada para decifrar mensagens inteiras sem nunca conhecer a chave, byte a byte, através do chamado **ataque de oráculo de padding** (*padding oracle attack*). A lição de fundo é uma que se repete ao longo deste livro: um mecanismo matematicamente correcto pode ainda assim falhar por causa de como é implementado. ## Síntese do Capítulo {#sec-03-sintese} Este capítulo apresentou o algoritmo que hoje ocupa o lugar do DES, e a forma como se aplica a mensagens de qualquer tamanho: 1. O **AES** resultou de um concurso público do NIST, vencido pelo algoritmo **Rijndael**, e normalizado em 2001 2. Ao contrário do DES, o AES **não é uma rede de Feistel**: é uma **rede de substituição-permutação** (SPN), em que cada ronda transforma o bloco inteiro 3. O bloco é sempre de **128 bits**; a chave pode ser de **128, 192 ou 256 bits**, com **10, 12 ou 14 rondas**, respectivamente 4. Cada ronda aplica quatro transformações: **SubBytes** (confusão, via S-box não linear), **ShiftRows** e **MixColumns** (difusão, entre e dentro de colunas), e **AddRoundKey**, o único passo que usa a chave; a segurança do AES vem da alternância entre o XOR com a chave e a baralhação pública das outras três transformações 5. Não existe, até hoje, nenhum ataque criptanalítico com utilidade prática contra o AES (o melhor, de 2011, precisa de cerca de $2^{126}$ operações e de uma quantidade absurda de dados); as vulnerabilidades reais são de implementação, como os ataques de tempo de cache, que as instruções AES-NI resolvem 6. Um **modo de operação** define como aplicar uma cifra de bloco a mensagens maiores do que um bloco: o **ECB** é simples mas revela padrões estruturais; o **CBC** e o **CFB** encadeiam os blocos e eliminam-os, à custa da cifragem não ser paralelizável; o **CTR** cifra um contador e combina o resultado com o texto claro por XOR, o que o torna totalmente paralelizável, mas obriga a nunca reutilizar o *nonce* e permite alterar o texto claro bit a bit 7. **Confidencialidade não é integridade:** nenhum destes modos impede que o texto cifrado seja alterado sem detecção (no CTR, o atacante troca exactamente os bits que quer); por isso, um modo de confidencialidade **nunca se usa sozinho**, mas sempre acompanhado de um MAC, que calcula uma marca de autenticação 8. O **GCM** combina o CTR com o **GHASH**, um MAC que percorre o AAD e o texto cifrado multiplicando o valor acumulado por um valor secreto $H$, numa construção **AEAD** que é hoje o modo recomendado para a generalidade das aplicações novas 9. O **padding** (nomeadamente o esquema PKCS#7) permite aos modos que cifram directamente bloco a bloco, como o ECB e o CBC, processar mensagens de qualquer comprimento, acrescentando um bloco inteiro quando a mensagem já é múltipla do bloco; o CTR e o GCM dispensam-no. Uma implementação que revele se o *padding* recebido é válido abre a porta a ataques de oráculo de *padding* ## Para Pensar {#sec-03-reflexao} O DES combina confusão e difusão através de uma única função $F$, aplicada apenas a metade do bloco por ronda. O AES separa estas duas propriedades em transformações distintas (`SubBytes` para a confusão, `ShiftRows`/`MixColumns` para a difusão), aplicadas ao bloco inteiro. Que vantagens pode trazer esta separação explícita, tanto para a análise de segurança do algoritmo como para o seu desempenho em hardware? ## Referências {#sec-03-referencias .unnumbered} ::: {#refs} :::