Na Parte 2 colocamos dois competidores no ringue: clássico Diffie-Hellman / X25519 (minúsculo, rápido, condenado ao quantum) e pós-quântico ML-KEM-768 (seguro quântico, robusto, novo). Agora é hora do evento principal. Vamos colocá-los lado a lado de todos os ângulos que importam e então revelar por que a jogada mais inteligente não é coroar um vencedor.
Tudo aqui você reproduza-se no laboratório prático da Parte 4. Esses não são números nos quais estou pedindo que você confie; são números que você medirá.
Rodada 1: Tamanho no fio
É aqui que a diferença salta à vista:
| X25519 | ML-KEM-512 | ML-KEM-768 | ML-KEM-1024 | |
|---|---|---|---|---|
| Chave pública | 32B | 800 bilhões | 1184B | 1568 B |
| Resposta (texto cifrado) | 32B | 768B | 1088B | 1568 B |
| Segredo compartilhado | 32B | 32B | 32B | 32B |
| Cabe em uma mensagem IKE (≤1280 B)? | ✅ sim | ✅ sim | ❌ precisa de fragmentação | ❌ não |
As chaves de 32 bytes do X25519 são adoravelmente pequenas. ML-KEM são 25–50× maiorgrande o suficiente para que o ML-KEM-768 force o IKE fragmentação (dividindo uma mensagem lógica em vários pacotes). Guarde essa palavra: fragmentação é o fio que percorre todo este pilar, e você verá com seus próprios olhos nas capturas do pacote no próximo post.
Rodada 2: Latência (viagens de ida e volta)
| Modo | Viagens de ida e volta | Mensagens |
|---|---|---|
| Somente X25519 | 2 | IKE_SA_INIT → IKE_AUTH |
| Híbrido X25519 + ML-KEM | 3 | IKE_SA_INIT → IKE_INTERMEDIATE → IKE_AUTH |
Tornar-se híbrido adiciona uma viagem completa de ida e voltamensurável, mas pequeno na prática (normalmente alguns milissegundos em uma LAN). Como um aperto de mão acontece uma vez por túnel (com redigitação a cada poucas horas), não há motivo para perder o sono.
Rodada 3: custo de cálculo (a surpresa)
Um mito comum: “pós-quântico” significa “dolorosamente lento”. Para ML-KEM, o oposto está mais perto da verdade. Suas operações de rede são genuinamente rápidas, no mesmo nível e muitas vezes mais rápidas que uma multiplicação escalar de curva elíptica.
Custo aproximado por operação em x86 moderno (a partir de benchmarks eBACS/SUPERCOP publicados, não medidos em nosso laboratório):
| Operação | X25519 | ML-KEM-768 |
|---|---|---|
| Geração de chave | ~50–65 mil ciclos | ~30 mil ciclos |
| Derivar segredo/encapsulamento compartilhado | ~50–65k ciclos | ~45k ciclos |
| Decapsular | n / D | ~35 mil ciclos |
Some tudo e os totais ficam no mesmo intervalo. ML-KEM-768 não é o gargalonem perto. Quando cronometrarmos os apertos de mão reais na Parte 4, você verá que a versão híbrida custa cerca de 1 ms mais do que clássico, e essencialmente tudo isso é a viagem de ida e volta extra da rede, não a criptografia.
Rodada 4: Segurança
| X25519 | ML-KEM-768 | |
|---|---|---|
| Segurança clássica | ~128 bits | ~192 bits |
| Segurança quântica | ❌ quebrado pelo algoritmo de Shor | ✅ nenhum ataque quântico conhecido |
| Padronizado | RFC 7748 (2016) | FIPS 203 (2024) |
| Maturidade de implantação | Muito alto | Emergindo |
E aí está o problema. X25519 é testado em batalha, mas vulnerável quântica. ML-KEM é seguro quântico, mas novo e menos testado em campo. Cada um tem exatamente a fraqueza que o outro não tem.
O veredicto: por que não ambos?
Aqui está a piada que sugeri na Parte 2. Nenhum dos candidatos vence claramente hoje, então, em vez de escolher um campeão, nós os fazemos trabalhar juntos. UM híbrido execuções de troca de chaves ambos e combina seus segredos compartilhados na chave de sessão final. O resultado:
- Se o ML-KEM for quebrado por um ataque quântico futuro, o X25519 ainda fornecerá segurança clássica.
- Se o X25519 for quebrado por um computador quântico, o ML-KEM fornecerá resistência quântica.
- Um invasor deve quebrar ambos simultaneamenteo que se acredita ser inviável.
Você obtém segurança quântica sem apostar tudo em um algoritmo totalmente novo, tudo pelo preço de uma viagem de ida e volta extra e aproximadamente 2 KB por handshake.
A mágica que faz funcionar: RFC 9370
Então, como conectamos duas trocas de chaves em um handshake IKEv2? Digitar RFC 9370 (Múltiplas trocas de chaves em IKEv2, 2023). Ele define um mecanismo limpo para executar adicional trocas de chaves além da troca DH IKEv2 padrão, cada uma contribuindo com material de chaveamento para as chaves finais.
O esquema é elegante:
- X25519 continua sendo o primeiro troca, realizada no padrão
IKE_SA_INITmensagem: pequena e inalterada. - ML-KEM se junta como um adicional intercâmbioandando em um novo
IKE_INTERMEDIATEida e volta. - A chave de sessão final é derivada de ambos segredos compartilhados combinados.
E é compatível com versões anteriores: pares que não falam trocas de chaves adicionais simplesmente voltam para o DH base. Todo mundo está feliz. Este é o caminho prático de migração que o NIST e a maioria dos fornecedores de VPN recomendam: ativar o PQC sem redesenhando todo o protocolo.
Na configuração do StrongSwan, toda a história é explicada em uma sequência de proposta: x25519-ke1_mlkem768
x25519 é o principal grupo DH em IKE_SA_INIT; ke1_mlkem768 é a primeira troca de chaves adicional RFC 9370, montada em IKE_INTERMEDIATE. Lembre-se dessa string.
O aperto de mão, passo a passo
Aqui está toda a dança híbrida, que vamos assistir ao vivo:
Initiator Responder
| |
|--- IKE_SA_INIT (KE(x25519), Ni) -------------> |
| | (~1250 B, fragmented)
|Vê aquele desequilíbrio da Parte 2? O iniciador envia o grande ML-KEM chave pública (~1184 B) e recupera o texto cifrado (~1088 B): tamanhos diferentes, direções opostas, exatamente porque um KEM divide o trabalho. E essa mensagem de chave pública de aproximadamente 1250 B é exatamente o motivo fragmentation = yes é obrigatório no laboratório.
Chega de teoria: vamos executá-lo
Agora temos a imagem completa: por que a troca de chaves é o pilar urgente, Quem os contendores são, como eles comparam e por que híbrido é a resposta. É hora de parar de ler tabelas e começar a criá-las.
Em Parte 4 criamos um túnel híbrido real, capturamos os pacotes e executamos o clássico versus o híbrido consecutivamente, observando a viagem de ida e volta extra e a fragmentação aparecerem em todos os detalhes. Encontre-me lá!