Encerramos o Bloco IV reunindo num só lugar o fio condutor que atravessou o bloco inteiro: a criptografia moderna quase nunca é quebrada por força bruta matemática — ela é derrotada pelo que a cerca. Esta aula cataloga os erros de implementação, configuração e uso que transformam criptografia teoricamente sólida em vulnerabilidade explorável. É a aula que te dá o olhar para reconhecer, em campo, quando a "proteção" criptográfica de um alvo é, na verdade, uma porta aberta.

Algoritmos obsoletos ou já quebrados

A primeira e mais comum família de falhas é o uso de algoritmos obsoletos ou quebrados. Já vimos que MD5 e SHA-1 sucumbiram a colisões (aula Hashes e assinaturas digitais: a impressão digital dos dados) e que versões antigas de SSL/TLS são inseguras (aula TLS/SSL na prática: toda a criptografia trabalhando junta). Quando um pentester encontra um sistema usando MD5 para senhas, DES (uma cifra antiga com chave curta demais) para dados, ou TLS 1.0 para tráfego, ele encontrou uma fraqueza real — não porque precise quebrar a matemática na hora, mas porque esses algoritmos já foram quebrados pela comunidade, e ferramentas prontas exploram isso. A defesa é crypto-agility: manter-se atualizado e migrar para algoritmos modernos (AES, SHA-256+, TLS 1.3, Argon2) conforme os antigos envelhecem.

Chave descuidada anula a cifra mais forte

A segunda família é o gerenciamento de chaves malfeito, e talvez seja a mais frequente na prática. A criptografia mais forte do mundo é inútil se a chave é descuidada. Os pecados capitais incluem: chaves hardcoded no código-fonte (você abrirá o código de um app no Bloco XV e encontrará chaves e senhas escritas ali, um achado clássico); chaves fracas, derivadas de senhas curtas ou previsíveis; reutilização de chaves onde deveriam ser únicas; e chaves armazenadas sem proteção, num arquivo de configuração legível, num repositório Git público (tema da aula Segurança de CI/CD: protegendo a linha de montagem do software), num bucket de nuvem exposto. Um caso emblemático e recorrente: desenvolvedores que sobem para o GitHub, sem perceber, arquivos contendo chaves de API e credenciais — e existem ferramentas (e atacantes) que varrem repositórios públicos justamente atrás disso. A chave é o segredo; se o segredo vaza, toda a construção desaba.

IV repetido e aleatoriedade fraca

A terceira família são os erros de implementação e uso, mais sutis, que exigem entendimento para reconhecer. Já citamos o modo ECB, que vaza padrões (aula Criptografia simétrica: o segredo compartilhado). Some-se a isso a reutilização de IV/nonce (valores que deveriam ser únicos a cada operação e que, repetidos, abrem brechas), a geração de aleatoriedade fraca (criptografia depende de números verdadeiramente imprevisíveis; um gerador previsível torna chaves adivinháveis), e os padding oracle attacks (uma classe de ataque que explora como um sistema reage a dados malformados para, aos poucos, decifrar mensagens sem conhecer a chave). Você não precisa dominar a mecânica matemática de cada um agora, mas precisa saber que existem e que a implementação correta da criptografia é notoriamente difícil — razão pela qual a regra de ouro é nunca criar sua própria criptografia, e sim usar bibliotecas consagradas e bem mantidas, corretamente.

Contornar a cifra em vez de quebrá-la

Há ainda uma categoria que mistura criptografia com engano humano: os ataques que contornam a criptografia em vez de quebrá-la. O man-in-the-middle (aula Protocolos em ação: handshake TCP, DNS e inspeção real) não quebra o TLS — tenta fazer a vítima aceitar um certificado ilegítimo ou rebaixar a conexão para uma versão insegura (downgrade attack). O SSL stripping engana a vítima para usar HTTP em vez de HTTPS. Ataques de força bruta contra senhas (Bloco VII) não atacam o hash em si, mas adivinham a entrada. O tema comum: por que lutar contra matemática impecável quando se pode atacar o elo humano ou de configuração ao redor dela? É quase sempre o caminho de menor resistência — exatamente o raciocínio da attack tree da aula Threat modeling: STRIDE, DREAD, PASTA e attack trees.

Respeite a matemática, treine o olho no entorno

O que quero que você carregue deste bloco inteiro, cristalizado nesta aula, é uma postura profissional madura diante da criptografia. Respeite a matemática — não tente quebrar AES ou RSA na marra, você não vai conseguir e não é aí que está a falha. Em vez disso, treine o olho para o entorno: que algoritmo está em uso e ele está desatualizado? Como as chaves são geradas, armazenadas e distribuídas? A implementação usa modos e valores corretos? Há certificados válidos? A criptografia pode ser contornada por engano? É nesse perímetro que os achados vivem. Do lado defensivo, a contramedida espelha exatamente isso: use padrões modernos, gerencie chaves com rigor (idealmente com cofres de segredos dedicados), configure corretamente, mantenha-se atualizado, e nunca reinvente a roda criptográfica.

Fecha o Bloco IV e toda a fundação

Com esta aula encerramos o Bloco IV e toda a fundação teórica do curso. Você tem agora: a moldura ética e legal (I), as lentes de análise de ameaças (II), o domínio técnico de sistemas, redes e programação (III), e a compreensão da criptografia que protege tudo (IV). Daqui em diante tudo muda: abre o Bloco V — Reconhecimento, e o arco real de um ataque passa a ser percorrido fase por fase, contra alvos de laboratório. A teoria acabou. A caçada começa.

Fontes e leituras recomendadas

Exercícios

  1. Qual é a tese central desta aula (e do Bloco IV) sobre como a criptografia moderna costuma ser derrotada?

    ✓ Resposta:

    Que a criptografia moderna quase nunca é quebrada pela matemática (força bruta contra AES/RSA), mas sim derrotada pelo seu entorno: algoritmos obsoletos, gerenciamento de chaves ruim, erros de implementação/configuração e engano humano.

  2. Cite dois exemplos de "gerenciamento de chaves malfeito" e explique por que a força do algoritmo não protege contra eles.

    ✓ Resposta:

    Exemplos: chaves hardcoded no código-fonte e chaves armazenadas sem proteção (ex.: em repositório público ou bucket exposto). A força do algoritmo não protege porque, se a chave — o segredo do qual toda a segurança depende — é exposta, o atacante decifra tudo sem precisar atacar o algoritmo.

  3. Por que a regra "nunca crie sua própria criptografia" é tão enfatizada? Relacione com os erros de implementação.

    ✓ Resposta:

    Porque implementar criptografia corretamente é notoriamente difícil, sujeito a erros sutis (ECB, reutilização de IV, aleatoriedade fraca, padding oracles) que abrem brechas. Bibliotecas consagradas já foram escrutinadas e corrigidas; uma implementação caseira quase certamente conterá falhas exploráveis.

  4. Explique a diferença entre quebrar a criptografia e contornar a criptografia, dando um exemplo de cada.

    ✓ Resposta:

    Quebrar é derrotar a própria proteção criptográfica (ex.: explorar colisão em MD5). Contornar é evitar enfrentá-la, atacando o entorno — ex.: um man-in-the-middle com SSL stripping que força a vítima a usar HTTP, ou força bruta que adivinha a senha em vez de reverter o hash.

  5. Que postura profissional diante da criptografia a aula recomenda ao pentester, e onde ele deve concentrar a busca por falhas?

    ✓ Resposta:

    Respeitar a matemática (não tentar quebrar AES/RSA diretamente) e concentrar a busca no entorno: algoritmos desatualizados, geração/armazenamento/distribuição de chaves, correção da implementação, validade de certificados e possibilidade de contornar a criptografia por engano.