Layered Performance Analysis of TLS 1.3 Handshakes: Classical, Hybrid, and Pure Post-Quantum Key Exchange

Este estudo de laboratório analisa o impacto dos algoritmos de criptografia pós-quântica (pura e híbrida) em comparação com os tradicionais em todas as camadas de transações HTTP sobre TLS 1.3, utilizando testes de carga para avaliar o desempenho em diferentes tamanhos de resposta.

O essencial

Imagine que a internet é uma grande cidade e os dados que você envia (como uma mensagem ou uma foto) são carros viajando por ela. Para que esses carros cheguem ao destino com segurança, eles precisam passar por um posto de segurança chamado TLS (o "cadeado" que você vê no navegador).

Atualmente, esse posto de segurança usa chaves matemáticas clássicas para trancar e destrancar os carros. Mas, no futuro, computadores superpoderosos (chamados computadores quânticos) poderão quebrar essas chaves clássicas como se fossem de papel. Para evitar isso, os cientistas criaram novas chaves, chamadas Pós-Quânticas (PQC), que são como cofres de aço indestrutíveis.

O problema? Ninguém sabia se trocar essas chaves clássicas por essas novas "cofres de aço" deixaria o trânsito lento demais.

Este artigo é como um laboratório de testes de trânsito onde os autores (David, Daniel e Ana) decidiram medir exatamente o que acontece quando trocamos as chaves, camada por camada. Eles não olharam apenas para o tempo total da viagem; eles dividiram a viagem em 5 etapas para ver onde o "engarrafamento" acontecia.

Aqui está a explicação simplificada do que eles descobriram:

1. A Analogia das 5 Camadas da Viagem

Para entender o impacto, eles dividiram a conexão em 5 partes, como se fosse uma viagem de carro:

1. O Acelerar (TCP Handshake): O momento em que o carro liga o motor e avisa "estou aqui".
2. A Chegada ao Portão (TCP para TLS): O tempo que o carro leva para chegar até o portão de segurança e o motorista pegar o formulário de entrada.
3. A Verificação no Portão (TLS Handshake): O momento em que o segurança verifica a identidade, troca as chaves e abre a cancela.
4. A Entrada na Estrada (TLS para App): O tempo que o carro leva para sair do portão e entrar na via principal.
5. A Entrega da Carga (Aplicação): O tempo que leva para o carro ir até o destino, pegar a encomenda e voltar.

2. O Grande Descoberta: Onde está o "Gargalo"?

Os autores testaram três tipos de chaves:

• Clássica: A chave normal de hoje.
• Híbrida: Uma chave normal + uma chave pós-quântica (segurança dupla).
• Pura Pós-Quântica: Apenas a nova chave super forte.

Eles descobriram algo surpreendente:

• O "Acelerar" (TCP) não mudou: A chave de segurança não afeta o momento em que o carro liga o motor. O trânsito aqui é igual para todos.
• O "Portão" (TLS Handshake) é neutro: Você poderia pensar que trocar por um cofre de aço deixaria a verificação no portão muito mais lenta. Mas não! O tempo de verificação no portão foi praticamente o mesmo para as chaves clássicas e as novas. O sistema é tão eficiente que a troca de chaves complexas não atrasou a cancela.
• O "Formulário de Entrada" (TCP para TLS) é o vilão: Aqui está a surpresa. O tempo que o motorista (o seu computador/celular) leva para preparar o formulário e chegar até o portão aumentou 6 vezes com as novas chaves.
  • Por que? Porque criar essas novas chaves matemáticas exige mais trabalho do cérebro do computador (CPU) antes mesmo de chegar ao servidor. É como se o motorista tivesse que preencher um formulário gigante antes de chegar ao portão.

3. O Impacto Real na Sua Vida

Você pode estar pensando: "Ok, mas isso vai deixar meu site lento?"

A resposta é: Não muito.

• O atraso total é pequeno: Mesmo com o formulário demorado, o tempo total da viagem (do clique até a página carregar) aumentou apenas 3 a 4 milissegundos. É menos do que o tempo que você leva para piscar os olhos.
• O tamanho da carga importa: Se você estiver enviando uma foto pequena (4 KB), o atraso parece maior em porcentagem. Mas se você estiver enviando um vídeo grande (40 KB), o tempo extra das chaves fica "diluído" no tempo de transferência do vídeo. É como se o atraso de 3 segundos em uma viagem de 10 minutos fosse irrelevante, mas em uma viagem de 30 segundos, pareceria mais.
• O Custo para o Computador: O lado do cliente (seu celular ou PC) teve que trabalhar o dobro para preparar essas chaves. Isso pode ser um problema para dispositivos muito fracos (como sensores de IoT ou celulares antigos), mas para servidores potentes, o impacto é pequeno.

4. Conclusão em Linguagem Comum

Imagine que você está mudando a fechadura da sua casa por uma mais segura.

• Antes: Você tirava a chave do bolso, abria a porta e entrava.
• Depois: Você precisa fazer uma pequena dança de 2 segundos antes de tirar a chave do bolso (preparar a chave nova), mas a porta abre na mesma velocidade.

A lição principal:
A migração para a criptografia pós-quântica não vai quebrar a internet. O atraso é real, mas é pequeno e concentrado apenas no momento em que o seu dispositivo se prepara para a conexão. A parte mais "pesada" da viagem (o servidor verificando e entregando os dados) continua rápida.

Os autores concluem que podemos fazer essa troca com segurança, mas devemos ficar atentos aos dispositivos mais fracos (celulares antigos, sensores) que podem ter dificuldade em fazer essa "dança preparatória" rápida.

Resumo da Ópera: A nova segurança é como um cofre de aço. Preparar o cofre leva um pouquinho mais de esforço no início, mas uma vez que você entra, a viagem é tão rápida quanto antes. A internet está segura e rápida!

Resumo técnico

Resumo Técnico: Análise de Desempenho em Camadas de Handshakes TLS 1.3 com Criptografia Pós-Quântica

1. Problema e Contexto

A emergência de computadores quânticos capazes de quebrar infraestruturas de chave pública atuais (como ECDH e RSA) exige uma migração para algoritmos de criptografia pós-quântica (PQC). O NIST finalizou seus primeiros padrões PQC em agosto de 2024 (FIPS 203, 204 e 205), incluindo o ML-KEM para troca de chaves.

Embora a migração seja urgente devido à ameaça de ataques "armazenar agora, descriptografar depois", há uma lacuna crítica em dados empíricos sobre o impacto de desempenho real desses algoritmos em ambientes de produção. Estudos anteriores focaram em tempos de handshake agregados, sem decompor onde exatamente a sobrecarga ocorre no protocolo. Este trabalho visa quantificar o impacto de desempenho da PQC no TLS 1.3, comparando configurações clássicas, híbridas e puras, sob condições de carga realistas.

2. Metodologia e Configuração Experimental

Arquitetura de Teste

Os autores desenvolveram um laboratório que emula um cenário de produção com um balanceador de carga e um servidor backend.

• Cliente: Gerador de tráfego stateful (Keysight CyPerf) simulando usuários virtuais concorrentes.
• Servidor: Nginx 1.27.3 atuando como proxy reverso e ponto de terminação TLS, compilado com OpenSSL 3.4.0 integrado à biblioteca liboqs (Open Quantum Safe) para suporte a PQC.
• Carga: Taxa sustentada de 100 transações por segundo (TPS) por 5 minutos, totalizando cerca de 30.000 requisições por teste e mais de 1 milhão de requisições no total.
• Variáveis: Tamanho da resposta do backend (vazio, 4 KB e 40 KB) e grupos de troca de chaves.

Configurações de Algoritmos

O estudo comparou três categorias principais de troca de chaves no TLS 1.3:

1. Clássico: x25519 (ECDH padrão).
2. Híbrido: x25519_MLKEM512 e x25519_MLKEM768 (combinação de ECDH clássico com ML-KEM).
3. Puro PQC: MLKEM512 e MLKEM1024 (apenas ML-KEM, conforme FIPS 203).

Decomposição em 5 Camadas

A principal inovação metodológica foi a decomposição da latência de ponta a ponta em cinco fases distintas para atribuir a sobrecarga a camadas específicas:

1. Handshake TCP: (SYN → SYN-ACK).
2. Atraso TCP para TLS: (SYN-ACK → ClientHello).
3. Handshake TLS: (ClientHello → Finished).
4. Atraso TLS para Aplicação: (Finished → HTTP GET).
5. Resposta da Aplicação: (HTTP GET → HTTP 200 OK).

Os dados foram coletados via capturas de pacotes (pcap) com chaves de sessão exportadas (SSLKEYLOGFILE) para permitir a descriptografia e análise granular de cada fluxo.

3. Principais Contribuições

1. Metodologia de Decomposição em 5 Camadas: Uma abordagem inédita para isolar a latência de inicialização do TLS, a negociação criptográfica e a transferência de dados, permitindo identificar exatamente onde a PQC impacta o sistema.
2. Comparação Abrangente: Avaliação empírica direta entre configurações clássicas, híbridas e puras PQC sob carga sustentada (100 TPS).
3. Descoberta de Neutralidade Algorítmica no Handshake TLS: Evidência estatística de que a camada de handshake do TLS é efetivamente neutra em relação ao algoritmo, com diferenças insignificantes entre PQC e clássico.
4. Ferramentas e Dados Públicos: Disponibilização de um script de redução de dados (pcap_layer_analysis.py) e um conjunto de dados completo de capturas de pacotes descriptografados para reprodutibilidade.

4. Resultados Chave

4.1. Sobrecarga Concentrada na Inicialização do Cliente

A análise revelou que a sobrecarga da PQC não é distribuída uniformemente.

• Handshake TCP: Totalmente independente do algoritmo criptográfico (latência mediana ~0.36–0.40 ms).
• Atraso TCP para TLS (Início do Handshake): Esta é a camada onde a sobrecarga é dominante e significativa. A latência mediana aumentou de 0.3 ms (clássico) para ~1.8–1.9 ms (PQC), representando um aumento de 6x. Isso é atribuído à geração de material de chave e construção do ClientHello no lado do cliente. O tamanho do efeito (Glass's ∆) é muito alto (7.7), indicando um impacto prático real.

4.2. Neutralidade da Camada de Handshake TLS

Contrariando a intuição de que algoritmos PQC seriam mais lentos na negociação, a fase de handshake propriamente dita (ClientHello → Finished) mostrou-se algoritmicamente neutra.

• As diferenças de latência entre clássico, híbrido e puro PQC foram de apenas 0.1 a 0.9 ms.
• O tamanho do efeito (Glass's ∆) foi de 0.03 a 0.33, classificado como "negligível" a "pequeno" segundo os limiares de Cohen.
• Configurações puras PQC (MLKEM) até mostraram latências ligeiramente menores que as híbridas, mas dentro da margem de erro de medição e ruído do sistema.

4.3. Impacto no Lado do Servidor e Rede

• CPU do Cliente: Aumentou aproximadamente o dobro (de ~3.7% para ~8.2–8.7%) nas configurações PQC, devido ao custo de inicialização.
• CPU do Servidor: Aumento relativo modesto (de ~14.6% para ~15.5% em híbridos, ou seja, ~5.8% de aumento relativo). Em cargas de produção mais altas, isso pode se tornar um gargalo.
• Tráfego de Rede: O tamanho das mensagens key_share aumentou drasticamente (de 32 bytes para até 1568 bytes), mas isso não causou impacto proporcional na latência de rede, indicando que a largura de banda adicional é gerenciável.

4.4. Efeito de Diluição pelo Tamanho da Resposta

Ao aumentar o tamanho da resposta do backend de 4 KB para 40 KB:

• A sobrecarga criptográfica absoluta permaneceu constante (~2.3 ms).
• No entanto, a sobrecarga relativa diminuiu significativamente, caindo de ~15% (para 4 KB) para ~8% (para 40 KB). Isso ocorre porque o tempo de transferência de dados da aplicação dilui o custo fixo de estabelecimento da conexão.

4.5. Visão de Ponta a Ponta

Em um cenário de 4 KB, a migração para PQC adiciona aproximadamente 3 a 4 ms ao tempo total de transação (de ~16.5 ms para ~19-20 ms). Embora existam atrasos, eles são considerados moderados e aceitáveis para a maioria das aplicações web, representando menos de 20% da latência total em cenários com balanceamento de carga.

5. Significado e Conclusões

Este estudo fornece uma visão granular crucial para a migração para PQC:

1. O Custo é Front-Loaded: A penalidade de desempenho da PQC ocorre quase inteiramente na fase de inicialização do cliente (geração de chaves), não na negociação do protocolo em si.
2. Handshake TLS é Eficiente: A implementação de ML-KEM no nível do protocolo TLS 1.3 é altamente eficiente, não introduzindo penalidades mensuráveis em comparação com o ECDH clássico durante a negociação.
3. Planejamento de Migração:
   • Dispositivos Confinados: O aumento de CPU no cliente (dobra) é um ponto de atenção crítico para dispositivos IoT ou móveis com recursos limitados.
   • Dispositivos de Rede (MiTM): Dispositivos que realizam inspeção de tráfego (Man-in-the-Middle) podem sofrer impactos significativos, pois atuam como cliente e servidor simultaneamente, dobrando a carga de CPU.
   • Cenários de Alta Carga: Embora 100 TPS não sature o servidor, a sobrecarga relativa de CPU sugere que em cargas de produção massivas, o dimensionamento de servidores precisará ser revisado.

Em suma, a migração para PQC no TLS 1.3 é viável com um custo de latência moderado e previsível, concentrado na inicialização do cliente, e não na negociação do protocolo ou na transferência de dados.