Criptografia Simétrica - Limitações e o Problema da Troca de Chaves

A criptografia simétrica é rápida, elegante e matematicamente robusta, mas depende de uma condição aparentemente simples e profundamente problemática: as duas partes precisam compartilhar previamente a mesma chave secreta. Essa é a sua maior limitação, e o motor histórico que levou à invenção da criptografia assimétrica e dos protocolos modernos de acordo de chaves.

Neste post destrincharemos o chamado problema da distribuição de chaves, veremos como ele foi tratado ao longo da história, entenderemos o engenhoso protocolo Diffie-Hellman, suas variantes modernas baseadas em curvas elípticas, o conceito de sigilo encaminhado perfeito (forward secrecy) e as implicações da computação quântica sobre esse cenário.

O problema em sua forma mais pura

Imagine que Alice e Bob queiram trocar mensagens cifradas pela internet. Eles concordam em usar AES-256, um algoritmo robusto. Mas, para funcionar, ambos precisam ter a mesma chave de 256 bits em mãos.

Como essa chave chega até Bob?

1. Se Alice enviar a chave pela mesma rede, qualquer atacante na rota pode capturá-la.
2. Se Alice cifrar a chave antes de enviá-la, precisará de outra chave para fazer isso, caindo no mesmo problema.
3. Se ambos tentarem usar um canal “fora de banda” (telefone, SMS, e-mail), haverá sempre risco de interceptação.

Esse é o paradoxo da distribuição de chaves: para enviar uma chave com segurança, parece ser necessário já ter algum tipo de criptografia funcionando, o que por sua vez exige outra chave previamente trocada.

Impactos práticos

• Escala quadrática: para N participantes se comunicarem dois a dois, são necessárias cerca de N × (N − 1) / 2 chaves distintas. Com 100 pessoas isso significa 4.950 chaves; com 1.000, quase meio milhão.
• Gestão operacional: cada chave precisa ser gerada, distribuída, armazenada, rotacionada e revogada em algum momento.
• Comprometimento concentrado: se uma chave vazar, todas as comunicações passadas e futuras cifradas com ela ficam vulneráveis.
• Dificuldade de iniciar comunicação com desconhecidos: só é possível se comunicar com quem já compartilha uma chave.

Soluções históricas (antes de 1976)

Antes da invenção da criptografia assimétrica, a distribuição de chaves era resolvida por meios físicos ou organizacionais.

Entrega presencial

Em contextos militares e diplomáticos, chaves eram trocadas pessoalmente em encontros programados, muitas vezes em cofres transportados por mensageiros autenticados.

Mala diplomática

Documentos e chaves eram transportados por servidores públicos com imunidade internacional, dentro de malas lacradas (a famosa “mala diplomática”).

Centros de distribuição de chaves (KDC)

Em sistemas computacionais corporativos, surgiram servidores centrais que mantinham chaves compartilhadas com todos os usuários. Kerberos, criado no MIT nos anos 1980, é o exemplo mais conhecido ainda em uso. Nele, cada usuário compartilha uma chave com o KDC, que atua como terceira parte confiável para intermediar a geração de chaves de sessão.

Chaves pré-compartilhadas (PSK)

Em alguns protocolos, as chaves são configuradas manualmente nos dois lados antes do início da comunicação. É o modelo usado em VPNs tradicionais com pre-shared key, no Wi-Fi WPA2-PSK e em algumas configurações de IPsec.

Essas abordagens funcionam bem em cenários controlados, com poucos participantes, mas são inviáveis para uma internet aberta com bilhões de usuários desconhecidos entre si.

A revolução de 1976: Diffie-Hellman

Em 1976, Whitfield Diffie e Martin Hellman publicaram um artigo intitulado New Directions in Cryptography, que apresentou pela primeira vez uma solução matemática elegante para o problema: um protocolo em que duas partes conseguem acordar uma chave secreta em comum pela rede, mesmo que toda a comunicação seja observada por um atacante.

A ideia central

O protocolo se baseia na dificuldade computacional de um problema matemático: o logaritmo discreto. Em termos simplificados, é fácil elevar um número a uma potência em aritmética modular, mas é extremamente difícil fazer o caminho inverso: dado o resultado, descobrir qual foi o expoente usado.

Passo a passo

Alice e Bob desejam combinar uma chave em comum. Eles seguem os passos abaixo, usando dois parâmetros públicos conhecidos:

• Um número primo grande p
• Um gerador g do grupo multiplicativo módulo p

Passo	Alice	Bob
1	Escolhe segredo a e calcula A = g^a mod p	Escolhe segredo b e calcula B = g^b mod p
2	Envia A para Bob	Envia B para Alice
3	Recebe B e calcula K = B^a mod p	Recebe A e calcula K = A^b mod p
4	Chave acordada: K	Chave acordada: K

Ao final, Alice e Bob chegam ao mesmo valor K, apesar de cada um ter feito cálculos diferentes. Um atacante que observe toda a comunicação verá apenas p, g, A e B, mas não conseguirá computar K em tempo viável, desde que p seja suficientemente grande.

Exemplo didático com números pequenos

Para ilustrar, considere p = 23 e g = 5.

• Alice escolhe a = 6. Calcula A = 5^6 mod 23 = 8.
• Bob escolhe b = 15. Calcula B = 5^15 mod 23 = 19.
• Alice calcula K = 19^6 mod 23 = 2.
• Bob calcula K = 8^15 mod 23 = 2.

Ambos chegaram a K = 2, apesar de nunca terem trocado nem a nem b pela rede.

Na prática, os números envolvidos têm milhares de bits, tornando o cálculo inverso inviável mesmo com supercomputadores modernos.

Reproduzindo o cálculo no Linux

É possível reproduzir o exemplo acima em um terminal com Python:

python3 -c "
p = 23
g = 5
a = 6
b = 15
A = pow(g, a, p)
B = pow(g, b, p)
K_alice = pow(B, a, p)
K_bob = pow(A, b, p)
print(f'A = {A}, B = {B}')
print(f'K (Alice) = {K_alice}, K (Bob) = {K_bob}')
"

Significado do comando:

• python3 -c "...": executa o código Python passado como argumento, sem precisar criar um arquivo
• pow(base, expoente, mod): calcula (base ^ expoente) mod mod de forma eficiente, usando exponenciação modular

A saída esperada:

A = 8, B = 19
K (Alice) = 2, K (Bob) = 2

A chave acordada vira chave simétrica

O valor K resultante do Diffie-Hellman geralmente passa por uma função de derivação de chave (como HKDF) antes de ser usado como chave simétrica para AES ou ChaCha20. Isso garante uniformidade estatística e permite derivar múltiplas subchaves a partir do mesmo segredo acordado.

Vulnerabilidade do Diffie-Hellman puro

O protocolo clássico é vulnerável a ataques de intermediário (man in the middle). Um atacante Mallory pode interceptar a troca e substituir A e B por valores próprios, acordando chaves diferentes com Alice e Bob, e repassando mensagens entre eles após decifrar e cifrar novamente.

Para evitar isso, o Diffie-Hellman deve ser autenticado, geralmente combinado com assinaturas digitais ou certificados. É isso que acontece em protocolos modernos como o TLS: o servidor assina os parâmetros Diffie-Hellman com sua chave privada, cujo certificado é validado pelo cliente.

Diffie-Hellman em curvas elípticas (ECDH)

A variante moderna do Diffie-Hellman utiliza curvas elípticas no lugar da aritmética modular tradicional. Isso oferece a mesma segurança com chaves muito menores e desempenho significativamente melhor.

Curvas mais comuns

• Curve25519 (via protocolo X25519), extremamente popular pela simplicidade e segurança
• P-256 (também conhecida como secp256r1), padronizada pelo NIST
• P-384 e P-521, variantes de maior segurança

A chave efetiva do ECDH com Curve25519 oferece 128 bits de segurança, com uma chave pública de apenas 32 bytes. Para comparação, obter o mesmo nível de segurança com Diffie-Hellman tradicional exigiria chaves de 3072 bits (384 bytes).

Onde o ECDH é usado hoje

• TLS 1.3 (base para o HTTPS moderno)
• OpenSSH (padrão em versões recentes)
• WireGuard (usa exclusivamente X25519)
• Signal e outros mensageiros ponta a ponta

Gerando parâmetros ECDH com OpenSSL

openssl genpkey -algorithm X25519 -out alice_privada.pem
openssl pkey -in alice_privada.pem -pubout -out alice_publica.pem

Significado de cada comando:

• genpkey: subcomando do openssl para geração de chaves privadas
• -algorithm X25519: especifica o algoritmo (Curve25519 em modo ECDH)
• -out alice_privada.pem: arquivo onde a chave privada será salva
• pkey -in <arquivo> -pubout -out <saída>: extrai a chave pública correspondente para distribuir ao outro participante

O processo seria repetido do lado de Bob, e depois cada um usaria sua chave privada combinada com a pública do outro para derivar o segredo compartilhado via openssl pkeyutl -derive.

Forward Secrecy (sigilo encaminhado perfeito)

Mesmo com uma troca de chaves segura, surge outro problema: o que acontece com as mensagens antigas se, no futuro, a chave privada de longo prazo de um dos participantes for comprometida?

Em um protocolo sem sigilo encaminhado perfeito (Forward Secrecy, ou PFS), um atacante que tenha armazenado tráfego cifrado no passado e obtenha a chave privada hoje poderá decifrar todo o histórico de comunicações.

A solução é usar chaves efêmeras no acordo: cada sessão gera um novo par Diffie-Hellman temporário, descartado ao final. Mesmo que a chave de longo prazo seja comprometida depois, as sessões antigas permanecem seguras, pois suas chaves efêmeras não existem mais.

Variantes com forward secrecy

• DHE: Diffie-Hellman efêmero clássico
• ECDHE: Diffie-Hellman efêmero sobre curvas elípticas

O TLS 1.3 obriga o uso de forward secrecy, eliminando as variantes antigas sem essa proteção.

Como garantir forward secrecy nos seus servidores

Verifique a configuração de HTTPS do seu servidor web e certifique-se de que apenas suítes com ECDHE (ou DHE) estejam habilitadas. No TLS 1.3 isso já é padrão. No TLS 1.2, remova explicitamente as cifras RSA sem ECDHE.

Alternativas e abordagens complementares

Encapsulamento de chaves (KEM)

Em vez de usar criptografia assimétrica diretamente para cifrar dados, protocolos modernos utilizam mecanismos de encapsulamento de chaves (Key Encapsulation Mechanism). O emissor cifra apenas uma chave simétrica aleatória com a chave pública do destinatário, enviando-a junto dos dados cifrados por essa chave. Esse é o princípio da criptografia híbrida.

KDC e Kerberos

Em redes corporativas, o Kerberos continua sendo uma solução sólida de distribuição centralizada de chaves, especialmente integrado ao Active Directory e ao FreeIPA.

Pre-Shared Keys (PSK)

Em cenários controlados, PSKs continuam úteis: VPNs ponto a ponto, dispositivos IoT, comunicação entre serviços internos. A chave pode ser gerada por administradores e distribuída via ferramentas seguras como HashiCorp Vault ou configuração automatizada com Ansible Vault.

A ameaça da computação quântica

O protocolo Diffie-Hellman (e sua variante elíptica) baseia-se em problemas matemáticos que o algoritmo de Shor quebraria eficientemente em um computador quântico suficientemente grande. Isso significa que todo o modelo atual de troca de chaves ficaria comprometido.

Em resposta, o NIST padronizou em 2024 um conjunto de algoritmos pós-quânticos, dos quais o principal para encapsulamento de chaves é o ML-KEM (anteriormente conhecido como CRYSTALS-Kyber).

Abordagem híbrida pós-quântica

Protocolos modernos como o TLS vêm adotando modos híbridos, nos quais o acordo de chaves usa simultaneamente um método clássico (X25519) e um pós-quântico (ML-KEM). Isso garante segurança mesmo que um dos dois venha a ser quebrado no futuro, incluindo contra a ameaça do “colete agora, decifre depois” (harvest now, decrypt later), em que atacantes armazenam tráfego cifrado hoje na expectativa de decifrá-lo quando computadores quânticos amadurecerem.

Práticas em servidores Linux

Agora que entendemos a teoria, vejamos como inspecionar e configurar algoritmos de troca de chaves em servidores reais.

Verificar algoritmos de troca de chaves disponíveis no SSH

ssh -Q kex

Significado do comando:

• ssh: cliente OpenSSH
• -Q <feature>: consulta os algoritmos suportados pela instalação local; kex lista algoritmos de troca de chaves (Key Exchange)

A saída traz nomes como curve25519-sha256, diffie-hellman-group14-sha256, etc.

Configurar o OpenSSH com forward secrecy e algoritmos modernos

Para que o servidor SSH negocie apenas algoritmos modernos (com forward secrecy e cifras autenticadas), vamos adicionar três diretivas ao arquivo de configuração do daemon: /etc/ssh/sshd_config.

1. Abrir o arquivo com privilégio administrativo

sudo nano /etc/ssh/sshd_config

Significado de cada opção:

• sudo: executa o comando com privilégios de superusuário (necessário para editar arquivos do sistema)
• nano: editor de texto de linha de comando (pode ser substituído por vim ou outro editor de sua preferência)
• /etc/ssh/sshd_config: arquivo de configuração do daemon SSH

2. Adicionar (ou substituir) as diretivas abaixo

Procure no arquivo as linhas KexAlgorithms, Ciphers e MACs. Se elas já existirem, substitua seus valores pelas listas abaixo. Se não existirem, adicione ao final do arquivo:

# Algoritmos de troca de chaves (handshake)
KexAlgorithms curve25519-sha256@libssh.org,curve25519-sha256,diffie-hellman-group16-sha512

# Cifras simétricas usadas na sessão (dados em trânsito)
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com

# Códigos de autenticação de mensagem (integridade)
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

Cada diretiva recebe uma lista de algoritmos em ordem de preferência: o servidor tentará negociar o primeiro algoritmo em comum com o cliente.

3. Entendendo cada diretiva e seus algoritmos

A diretiva KexAlgorithms define os algoritmos usados no acordo de chaves (Key Exchange). Todos aqui oferecem forward secrecy:

• curve25519-sha256@libssh.org: ECDH sobre Curve25519 (nome legado do OpenSSH); é a opção preferida pela segurança e desempenho
• curve25519-sha256: mesmo algoritmo acima, com o nome padronizado pela IETF; aceita servidores e clientes modernos
• diffie-hellman-group16-sha512: Diffie-Hellman clássico com grupo de 4096 bits e hash SHA-512; mantido como fallback para clientes antigos sem suporte a Curve25519

A diretiva Ciphers define as cifras simétricas que protegerão o conteúdo da sessão após o handshake. Ambas são AEAD (cifragem autenticada):

• chacha20-poly1305@openssh.com: cifra de fluxo ChaCha20 combinada com o MAC Poly1305; excelente desempenho em software, preferida em dispositivos sem AES-NI
• aes256-gcm@openssh.com: AES de 256 bits no modo GCM; muito rápida em CPUs com aceleração AES-NI

A diretiva MACs define algoritmos de autenticação de mensagem usados em combinação com cifras que não são AEAD. O sufixo -etm significa Encrypt-then-MAC (cifra primeiro, autentica depois), que é a abordagem segura. Como as duas cifras configuradas acima já são AEAD, essas MACs servem como fallback:

• hmac-sha2-512-etm@openssh.com: HMAC com SHA-512, aplicado após a cifragem
• hmac-sha2-256-etm@openssh.com: HMAC com SHA-256, aplicado após a cifragem

4. Validar a configuração antes de aplicar

Antes de reiniciar o serviço, teste se o arquivo está sintaticamente correto. Um erro aqui pode impedir o SSH de iniciar e deixar o servidor remoto inacessível:

sudo sshd -t

Significado de cada opção:

• sshd: executa o daemon SSH diretamente
• -t: modo de teste (do inglês test); apenas valida a sintaxe do arquivo de configuração, sem iniciar o serviço

Se não houver saída, está tudo correto. Se houver erro, a mensagem indicará a linha problemática.

5. Reiniciar o serviço

sudo systemctl restart sshd

Significado de cada opção:

• systemctl: utilitário de gerenciamento de serviços do systemd
• restart: reinicia o serviço especificado
• sshd: nome do serviço SSH (em algumas distribuições pode ser ssh)

6. Confirmar que a nova configuração está ativa

Abra uma nova sessão SSH no servidor com modo verboso para ver os algoritmos negociados:

ssh -v usuario@servidor

Significado de cada opção:

• -v: modo verboso; exibe detalhes do handshake, incluindo os algoritmos de KEX, cifra e MAC negociados
• usuario@servidor: credencial e endereço do servidor

Procure por linhas como kex: algorithm:, kex: server->client cipher: e kex: client->server cipher: na saída. Elas confirmam quais algoritmos foram efetivamente escolhidos na conexão.

Mantenha uma sessão aberta durante os testes

Em servidores remotos, nunca feche a sessão SSH ativa antes de confirmar que a nova configuração funciona. Se algo der errado, você pode editar o arquivo pela sessão existente e corrigir. Fechar sem testar pode deixar o servidor inacessível, exigindo acesso ao console físico ou ao console da VM para recuperar.

Verificar troca de chaves em uma conexão HTTPS

openssl s_client -connect exemplo.com:443 -tls1_3 </dev/null 2>/dev/null | \
  grep -E 'Server Temp Key|Cipher'

Significado de cada opção:

• openssl s_client: subcomando que atua como cliente TLS para testar servidores
• -connect exemplo.com:443: endereço e porta do servidor a conectar
• -tls1_3: força a negociação apenas em TLS 1.3
• </dev/null: envia entrada vazia, para que o cliente desconecte após o handshake
• 2>/dev/null: descarta mensagens de erro
• | grep -E 'Server Temp Key|Cipher': filtra apenas as linhas que indicam o algoritmo de troca de chaves temporário e a cifra simétrica negociada

WireGuard: Diffie-Hellman por padrão

O WireGuard usa X25519 obrigatoriamente, sem opções de configuração para algoritmos de troca de chaves. Isso simplifica radicalmente a configuração e reduz a superfície de erro:

wg genkey | tee privada | wg pubkey > publica

Significado de cada comando:

• wg genkey: gera uma chave privada X25519 em formato Base64
• | tee privada: grava a chave em privada e também encaminha para o próximo comando
• wg pubkey: deriva a chave pública correspondente a partir da privada recebida pela entrada padrão
• > publica: redireciona a saída para o arquivo publica

Após esse passo, você tem o par de chaves pronto para configurar peers no WireGuard.

Resumo das limitações e das soluções

Limitação da criptografia simétrica	Solução moderna
Distribuição segura da chave	Diffie-Hellman, ECDH, criptografia híbrida
Escala quadrática de chaves	Pares de chaves assimétricas por participante
Ausência de identidade intrínseca	Certificados digitais, assinaturas
Comprometimento de chave compromete passado	Forward Secrecy com chaves efêmeras
Ameaça da computação quântica	Algoritmos pós-quânticos (ML-KEM)

Considerações Finais

A principal limitação da criptografia simétrica, a necessidade de troca prévia de uma chave secreta, deixou de ser um impedimento graças a décadas de desenvolvimento criptográfico. Hoje, o acordo de chaves por Diffie-Hellman (em suas variantes modernas sobre curvas elípticas) resolve o problema de forma elegante, permitindo que duas partes acordem uma chave simétrica em comum em uma rede aberta sem jamais transmitir essa chave.

Combinado com forward secrecy e, cada vez mais, com algoritmos pós-quânticos, esse conjunto de mecanismos sustenta toda a segurança da internet moderna. Para o administrador Linux isso se traduz em escolhas simples: usar protocolos modernos (TLS 1.3, SSH recente, WireGuard), configurar apenas cifras e KEX contemporâneos e acompanhar a transição para o modelo pós-quântico que já começou.

Com este post encerramos o bloco de Criptografia Simétrica. No próximo iniciaremos o estudo da criptografia assimétrica, que resolve não apenas o problema da troca de chaves, mas também abre caminho para as assinaturas digitais e os certificados que serão explorados mais adiante na série.