# Modos de cifra e protocolos

ECB, CBC, CTR, AEAD, repetição e acordo de chaves com Diffie-Hellman.

Página: https://resumos.rgo.pt/cadeiras/fsi/modos-protocolos/

AES transforma blocos de 16 bytes. A lista de preços da loja ocupa mais do que isso: é preciso proteger vários blocos com a mesma chave. Uma **cifra de bloco** define a transformação de um bloco; não define sozinha como proteger uma mensagem inteira. Para proteger uma mensagem maior, dividimos a mensagem em blocos e precisamos de uma regra, o **modo de operação**, que define a relação entre blocos e os valores adicionais usados na cifragem. O XOR compara bits e dá 1 quando são diferentes e 0 quando são iguais: $x\oplus x=0$ e $x\oplus0=x$; por exemplo, `1010 XOR 1100 = 0110`.

## ECB, CBC e CTR

| Modo | Relação entre blocos | Valor adicional | Limite importante |
| --- | --- | --- | --- |
| ECB | Cada bloco cifra independentemente | Nenhum | Blocos iguais com a mesma chave dão cifras iguais |
| CBC | Cada bloco combina-se com a cifra anterior | IV inicial imprevisível | Exige blocos completos; sozinho não autentica |
| CTR | XOR da mensagem com blocos de uma sequência cifrada de contadores | Contadores que não se repetem sob a mesma chave | Reutilização revela relações entre mensagens; sozinho não autentica |

Em ECB, cada bloco cifra de forma independente. Uma mensagem de blocos `A A B A` dá um padrão `X X Y X`. Um observador não precisa de descobrir A para reconhecer repetições, por isso “usar AES” sem dizer o modo não responde a este problema.

Em CBC, $C_i=E_K(P_i\oplus C_{i-1})$, com $C_0=IV$. Aqui $P_i$ é um bloco de texto em claro, $C_i$ um bloco cifrado e $K$ a chave. Com dois blocos: primeiro calcula-se $X_1=P_1\oplus IV$ e $C_1=E_K(X_1)$; depois $X_2=P_2\oplus C_1$ e $C_2=E_K(X_2)$. Para decifrar, inverte-se cada passo: $P_1=D_K(C_1)\oplus IV$ e $P_2=D_K(C_2)\oplus C_1$, como mostra o diagrama seguinte com estes dois blocos.

![Dois blocos CBC: cada texto em claro combina-se com a cifra anterior antes da cifra de bloco; a decifragem inverte cada passo.](https://resumos.rgo.pt/cadeiras/fsi/modos-protocolos/figura-1.svg)

Em CTR, $C_i=P_i\oplus E_K(\text{contador}_i)$. O IV de CBC e os contadores de CTR têm requisitos distintos. Em CTR, evita repetir qualquer bloco de contador, inclusive entre mensagens: inícios diferentes ainda podem gerar sequências sobrepostas.

CBC convencional recebe blocos completos. Com preenchimento PKCS#7 e blocos de 16 bytes, uma mensagem de 14 bytes recebe dois bytes `02 02`. Uma de 16 bytes recebe um bloco completo de dezasseis bytes de valor 16, para distinguir preenchimento de dados. Ao remover, o recetor lê o último byte $k$, exige $1\le k\le16$ e pelo menos $k$ bytes disponíveis, e verifica que os últimos $k$ bytes valem todos $k$. Se alguma condição falha, rejeita em vez de remover. O preenchimento não autentica a mensagem. CTR pode usar apenas os bytes necessários do último bloco e não precisa deste preenchimento.

### Alterar bits sem conhecer a chave

Em CTR sem autenticação, alterar um bit de $C_i$ altera exatamente o bit correspondente de $P_i$. O contador e a sequência cifrada mantêm-se. Se o atacante aplica uma máscara $\Delta$, o recetor obtém:

$$
C'_i=C_i\oplus\Delta.
$$

Ao retirar a mesma sequência $S_i$, fica:

$$
P'_i=P_i\oplus\Delta.
$$

Com $P_i=01000001$ e máscara `00000011`, os dois bits finais mudam e o resultado é `01000010`. Não há propagação automática aos restantes blocos. Confidencialidade não impede esta alteração; uma etiqueta de autenticação válida é uma condição adicional. AES real tem blocos de 128 bits, ou 16 bytes; um bloco menor num exercício representa apenas um modelo para seguir o XOR.

## Reutilizar uma sequência de XOR

Se duas mensagens usam a mesma sequência $S$, temos $C_1=P_1\oplus S$ e $C_2=P_2\oplus S$. Ao combinar as cifras:

$$
C_1\oplus C_2=P_1\oplus P_2,
$$

porque $S\oplus S=0$. Se uma mensagem é conhecida, a outra fica recuperável. Este problema aparece no one-time pad reutilizado e no CTR com contadores repetidos.

Para ver um byte, toma $P_1=01000001$ (A), $P_2=01000010$ (B) e $S=00110000$:

| Estado | Bits |
| --- | --- |
| $C_1=P_1\oplus S$ | `01110001` |
| $C_2=P_2\oplus S$ | `01110010` |
| $C_1\oplus C_2$ | `00000011` |
| $(C_1\oplus C_2)\oplus P_1$ | `01000010`, o B original |

O atacante conhece a primeira mensagem e as duas cifras. A última linha recupera a segunda mensagem sem conhecer previamente $S$.

Os bytes deste exemplo só mostram a identidade algébrica; não implementam uma cifra segura. O one-time pad só tem confidencialidade perfeita com chave uniformemente aleatória, tão longa como a mensagem, secreta e usada uma única vez.

## Cifragem autenticada

Um MAC autentica dados, mas não os esconde. Cifrar sem autenticar pode permitir alterações controladas ou ataques através das respostas a dados inválidos. **AEAD** protege a confidencialidade do conteúdo e a integridade do conteúdo e dos dados associados, como um número de sequência. Estes dados associados não ficam cifrados.

Usa construções estudadas, como AES-GCM ou ChaCha20-Poly1305, com os requisitos de nonce da construção. Para GCM, reutilizar um nonce com a mesma chave compromete a segurança. A aplicação deve rejeitar dados cuja etiqueta não verifica, antes de lhes dar significado. Usa uma construção analisada, em vez de combinar por conta própria uma cifra e um hash.

AEAD não elimina automaticamente a repetição. Uma mensagem válida antiga continua a ter uma etiqueta válida, porque a etiqueta prova que alguém com a chave protegeu aquele conteúdo e dados associados. Não prova que a mensagem é nova. A frescura precisa de mecanismo próprio, conforme o protocolo: por exemplo incluir um número de sequência nos dados associados e manter estado de receção com janela que tolera reordenação legítima, ou usar um desafio fresco por operação e rejeitar respostas fora do desafio pendente.

No esquema, o identificador 7 está autenticado com a mensagem. O atacante só copia os bytes; a segunda receção é recusada pelo estado da aplicação, não por uma falha da etiqueta.

![O recetor aceita a mensagem AEAD com id 7. O atacante reenvia os mesmos bytes: a etiqueta continua válida, mas o id usado impede uma segunda execução.](https://resumos.rgo.pt/cadeiras/fsi/modos-protocolos/figura-2.svg)

A verificação de unicidade e o efeito têm de ficar ligados atomicamente. Caso contrário, dois pedidos concorrentes podem observar o identificador como novo antes de qualquer um o registar. Este exemplo não define um protocolo completo.

### Ordem entre cifragem e MAC

Os nomes indicam que dados se autenticam e quando. Escrevemos $E$ para cifragem, $M$ para MAC e $\Vert$ para concatenação; $K_E$ e $K_M$ têm funções separadas.

*   **Encrypt-then-MAC:** calcula $c=E_{K_E}(m)$, depois $t=M_{K_M}(c)$, e envia $(c,t)$.
*   **MAC-then-Encrypt:** calcula $t=M_{K_M}(m)$, depois $c=E_{K_E}(m\Vert t)$, e envia $c$.
*   **Encrypt-and-MAC:** calcula separadamente $c=E_{K_E}(m)$ e $t=M_{K_M}(m)$, e envia $(c,t)$.

No primeiro caso, o recetor pode verificar a etiqueta antes de decifrar. No segundo, precisa de decifrar para chegar à etiqueta. Se diferenças de resposta revelarem erros de preenchimento antes da autenticação, essa ordem pode criar um oráculo: o atacante aprende algo pelas respostas a cifras alteradas. No terceiro, um MAC sobre o texto em claro pode revelar relações que a cifra pretendia esconder.

Estes esquemas distinguem composições, não provam segurança de qualquer implementação. É preciso proteger também IV/nonce e contexto conforme a construção, separar chaves e cumprir os requisitos das primitivas. Usar AEAD analisada evita inventar esse protocolo. Enviar só uma etiqueta MAC não envia a mensagem; enviar a chave MAC em claro permite ao observador criar etiquetas para mensagens alteradas.

## Diffie-Hellman em números pequenos

A conta usa a [aritmética modular](https://resumos.rgo.pt/cadeiras/fsi/criptografia/#aritm%C3%A9tica-modular), com números pequenos para permitir refazer as contas; não são parâmetros seguros.

Ana e Bruno publicam $p=23$ e $g=5$. Ana escolhe $a=6$ e envia $A=g^a\bmod p=8$. Bruno escolhe $b=15$ e envia $B=g^b\bmod p=19$. Ana calcula $B^a\bmod p=2$ e Bruno calcula $A^b\bmod p=2$.

![Ana publica 8 e Bruno publica 19. Com os seus expoentes privados 6 e 15, ambos calculam o segredo 2. Só os valores públicos atravessam a comunicação.](https://resumos.rgo.pt/cadeiras/fsi/modos-protocolos/figura-3.svg)

A igualdade vem de aplicar os dois expoentes à mesma base:

$$
B^a=(g^b)^a=g^{ab}=(g^a)^b=A^b\pmod p.
$$

Ana não precisa de conhecer $b$: usa o valor público $B$ e o seu $a$. Bruno faz a operação correspondente com $A$ e $b$.

Num protocolo real, os parâmetros e a validação dos valores recebidos têm requisitos de segurança, e uma função de derivação transforma o segredo em chaves adequadas. A igualdade anterior explica a coincidência dos resultados no grupo usado, não a autenticação dos participantes.

**Sem autenticação**, um intermediário pode substituir A e B pelos seus valores e estabelecer um segredo com cada lado. O acordo não prova com quem falamos. No diagrama seguinte, o intermediário combina um segredo com Ana e outro segredo com Bruno; Ana e Bruno veem trocas aparentemente normais, mas partilham segredos diferentes com o intermediário.

![Intermediário entre Ana e Bruno: estabelece um segredo com cada lado e retransmite mensagens.](https://resumos.rgo.pt/cadeiras/fsi/modos-protocolos/figura-4.svg)

Certificados e assinaturas sobre o contexto da troca, ou uma chave previamente partilhada, podem autenticar o acordo.

Chaves efémeras corretamente usadas e apagadas podem dar **sigilo futuro**: comprometer mais tarde a chave de autenticação de longo prazo não permite recuperar sessões antigas gravadas. Isso não protege uma sessão cujo próprio segredo efémero foi comprometido.

O vídeo acompanha a troca de valores públicos. Compara-a com os dois diagramas: obter um segredo comum e verificar a identidade do interlocutor continuam a ser problemas diferentes.

[Vídeo: Secret Key Exchange, Mike Pound, Computerphile](https://www.youtube.com/watch?v=NmM9HA2MQGI)

[Abrir no YouTube](https://www.youtube.com/watch?v=NmM9HA2MQGI)

## Exercícios

O segredo de Diffie-Hellman

Num acordo de brinquedo com $p=23,g=5$, Ana tem $a=4$ e recebe $B=19$. Qual segredo calcula Ana? Não uses estes parâmetros numa comunicação real.

Pista

Usa o valor público recebido com o expoente privado da Ana.

Solução

$19^2=361\equiv16\pmod{23}$. Logo $19^4\equiv16^2=256\equiv3\pmod{23}$. Ana calcula 3.

Erros frequentes

O valor B é público. Não o confundas com o expoente privado b.

[Voltar à explicação](https://resumos.rgo.pt/cadeiras/fsi/modos-protocolos/#diffie-hellman-em-n%C3%BAmeros-pequenos)

Uma transferência repetida

Uma aplicação usa AEAD corretamente, mas aceita a mesma mensagem válida de transferência várias vezes. A etiqueta verifica em todas. Explica a falha e propõe uma regra adicional.

Pista

O atacante mudou algum byte da mensagem?

Solução

A aplicação não verifica frescura ou unicidade da operação. Deve autenticar também o contexto relevante e recusar operações já usadas, por exemplo com identificador e estado transacional. AEAD sozinha não define essa política.

Confere a tua resposta:

*   Distingue autenticidade/integridade de frescura.
*   Explica que uma cifra e etiqueta antigas podem continuar válidas.
*   Propõe número de sequência/identificador de operação e rejeição de repetição com estado adequado.

Erros frequentes

Não alegues que a etiqueta tem de falhar: a mensagem repetida não foi alterada.

[Voltar à explicação](https://resumos.rgo.pt/cadeiras/fsi/modos-protocolos/#cifragem-autenticada)

Duas cifras, uma sequência

Temos $C_1=P_1\oplus S$ e $C_2=P_2\oplus S$. O atacante conhece $P_1$, $C_1$ e $C_2$. Deriva uma expressão para recuperar $P_2$.

Pista

XOR de um valor consigo próprio dá zero.

Mais uma pista

Combina a primeira cifra com a primeira mensagem conhecida.

Solução

$C_1\oplus P_1=S$. Assim, $C_2\oplus C_1\oplus P_1=P_2\oplus S\oplus S=P_2$. A defesa depende de não repetir a sequência sob a mesma chave.

Confere a tua resposta:

*   Usa C1 XOR P1 = S.
*   Obtém P2 = C2 XOR C1 XOR P1.
*   Explica que a repetição da sequência elimina o segredo na relação entre cifras.

Erros frequentes

Ter mensagens diferentes não evita o problema. O nonce pode ser público, mas tem de cumprir o requisito da construção.

[Voltar à explicação](https://resumos.rgo.pt/cadeiras/fsi/modos-protocolos/#reutilizar-uma-sequ%C3%AAncia-de-xor)

Inícios diferentes, blocos repetidos

Num CTR de brinquedo, a primeira mensagem usa os contadores 10, 11, 12 e 13; a segunda usa 12, 13 e 14, sob a mesma chave. A equipa afirma que não há reutilização porque os contadores iniciais são diferentes. Avalia a afirmação.

Pista

Compara todos os blocos de contador, não só os primeiros.

Solução

A afirmação é falsa. Os valores 12 e 13 geram a mesma sequência em duas posições de mensagens distintas, ou seja o XOR das cifras dessas posições revela o XOR dos textos em claro; conhecer um deles permite recuperar o outro. A regra precisa de impedir sobreposição de todos os contadores sob a chave, incluindo o retorno a valores antigos por overflow.

Confere a tua resposta:

*   Identifica os contadores 12 e 13 como repetidos.
*   Relaciona os blocos repetidos com a mesma sequência XOR sob a mesma chave.
*   Exige intervalos de contadores sem sobreposição e sem retorno ao início por overflow.

Erros frequentes

Inícios únicos não bastam quando as sequências podem sobrepor-se. Tornar os contadores secretos não corrige a reutilização.

[Voltar à explicação](https://resumos.rgo.pt/cadeiras/fsi/modos-protocolos/#ecb-cbc-e-ctr)

Decifrar dois blocos CBC

Com $C_0=IV$, $C_1$ e $C_2$ recebidos, escreve as expressões de $P_1$ e $P_2$ em CBC e explica a dependência entre blocos. Uma mensagem de 16 bytes com blocos de 16 bytes recebe quantos bytes de preenchimento PKCS#7 e com que valor?

Pista

Inverte cada passo da cifragem por ordem.

Mais uma pista

O preenchimento tem de distinguir dados de enchimento mesmo quando a mensagem já é múltipla do bloco.

Solução

$P_1=D_K(C_1)\oplus IV$ e $P_2=D_K(C_2)\oplus C_1$. A decifragem de $P_2$ precisa de $C_1$, porque a cifragem combinou $P_2$ com $C_1$ antes da cifra de bloco. Com 16 bytes em blocos de 16, acrescenta-se um bloco completo de dezasseis bytes de valor 16.

Confere a tua resposta:

*   Escreve P1=D(C1) XOR IV e P2=D(C2) XOR C1.
*   Explica que P2 precisa da cifra anterior.
*   Calcula o preenchimento PKCS#7 para 16 bytes em bloco de 16.

Erros frequentes

Não confundas o IV, que só entra no primeiro bloco, com a cifra anterior de cada bloco seguinte.

[Voltar à explicação](https://resumos.rgo.pt/cadeiras/fsi/modos-protocolos/#ecb-cbc-e-ctr)

A cifra mudou, a etiqueta ficou

Num modelo de um byte em CTR, o texto em claro é `00110000`. O atacante aplica XOR com `00000101` à cifra, mantendo o contador. Sem autenticação, que texto recebe o destinatário? O protocolo passa depois a enviar a cifra $c=E_{K_E}(m)$ e uma etiqueta MAC sobre o contador, o contexto e a cifra, nessa ordem. O contador e o contexto não precisam de ser secretos. O atacante muda a cifra e conserva a etiqueta antiga. Assume que não consegue forjar uma etiqueta válida. Identifica a composição e a decisão do recetor. Como mudaria a ordem se a etiqueta estivesse dentro da mensagem cifrada?

Solução

Retirar a sequência CTR deixa a mesma máscara aplicada ao texto: `00110000 XOR 00000101 = 00110101`. Mudam dois bits, sem necessidade de conhecer a chave. O novo protocolo é Encrypt-then-MAC: a etiqueta autentica a cifra e verifica-se antes de decifrar. A cifra alterada com etiqueta antiga falha, nas hipóteses dadas, e o recetor rejeita-a. Em MAC-then-Encrypt, calcula-se o MAC do texto em claro, concatena-se a etiqueta e cifra-se tudo; o recetor precisa de decifrar antes de obter essa etiqueta. A comparação das ordens não dispensa uma construção analisada.

Confere a tua resposta:

*   Obtive 00110101 ao aplicar a máscara ao texto em claro.
*   Identifiquei Encrypt-then-MAC e verificação antes da decifragem.
*   Distingui MAC-then-Encrypt pela etiqueta dentro do conteúdo cifrado.

[Voltar à explicação](https://resumos.rgo.pt/cadeiras/fsi/modos-protocolos/#ordem-entre-cifragem-e-mac)