Capítulo 36 — Segurança quântica e pós-quântica: desempenho e escala
Mapa da aula
Aula 36 publicada. Mapa, exemplo, EX071.
flowchart TD
N0["36.1 Orçamentos de bytes"]
N1["36.2 Atividade prática — Laboratório B"]
N2["36.3 Computação"]
N3["36.4 Medição"]
N4["Nota de engenharia"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX071"]
Desenho lógico
flowchart LR
N0["36.1 Orçamentos de bytes"]
N1["36.2 Atividade prática — Laboratório B"]
N2["36.3 Computação"]
N3["36.4 Medição"]
N4["Nota de engenharia"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX071"]
[36.1 Orçamentos de bytes]
|
v
[36.2 Atividade prática — Laboratório B]
|
v
[36.3 Computação]
|
v
[36.4 Medição]
|
v
[Nota de engenharia]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX071]
Objetivos de aprendizagem
Você vai (1) orçar bytes e computação para os handshakes pós-quânticos; (2) medir latência e vazão; (3) avaliar os efeitos do tamanho das cadeias de certificados; e (4) escalar os serviços de assinatura e verificação. O capítulo parte dos Capítulos 8, 11 e 29.
36.1 Orçamentos de bytes
O ML-KEM acrescenta cerca de 2,3 kB a um handshake TLS híbrido (compartilhamento de 1.216 bytes do cliente mais compartilhamento de 1.120 bytes do servidor). Os certificados pós-quânticos acrescentam muito mais: cada certificado ML-DSA-44 carrega uma chave de 1.312 bytes e uma assinatura de 2.420 bytes; uma cadeia mais as assinaturas do CertificateVerify e da Certificate Transparency pode passar de 15 kB — além da janela de congestionamento inicial do TCP em muitas configurações, o que custa uma ida e volta a mais.
A troca de chaves cabe em dois segmentos TCP, enquanto uma cadeia de certificados pós-quânticos pode precisar, sozinha, de uma ida e volta a mais. É por isso que a BPA migra primeiro a troca de chaves e trata os certificados como um projeto separado.
36.2 Atividade prática — Laboratório B
# Lab B (ch 36): bytes of authentication in a TLS handshake for different signature choices.
# Sizes in bytes: (public key, signature). ML-DSA from FIPS 204; SLH-DSA-128s from FIPS 205.
algs = {"ECDSA P-256": (65, 72), "RSA-2048": (270, 256), "ML-DSA-44": (1312, 2420),
"ML-DSA-65": (1952, 3309), "SLH-DSA-SHA2-128s": (32, 7856)}
def chain_bytes(alg, depth=2, scts=2):
pk, sig = algs[alg]
certs = depth * (pk + sig + 400) # leaf + intermediate: key + CA signature + ~400 B fields
return certs + sig + scts * sig # + CertificateVerify + embedded SCT signatures
for a in algs:
print(f"{a:20s} ~{chain_bytes(a):6d} bytes of certificates and signatures")
Saída esperada:
ECDSA P-256 ~ 1290 bytes of certificates and signatures
RSA-2048 ~ 2620 bytes of certificates and signatures
ML-DSA-44 ~ 15524 bytes of certificates and signatures
ML-DSA-65 ~ 21249 bytes of certificates and signatures
SLH-DSA-SHA2-128s ~ 40144 bytes of certificates and signatures
O acréscimo de ~400 bytes por certificado e as duas assinaturas SCT embutidas são hipóteses simplificadoras; os tamanhos reais variam. O resultado explica por que a migração da autenticação na web pública é mais difícil do que a da troca de chaves e por que as propostas para reduzir o tamanho das cadeias (como os certificados abreviados ou em árvore de Merkle) são temas ativos de pesquisa.
Lendo a saída, uma cadeia ML-DSA-44 tem cerca de doze vezes o tamanho da cadeia ECDSA, e a variante pequena do SLH-DSA é cerca de trinta vezes maior. Execute de novo com scts=0 para ver quanto as assinaturas de transparência contribuem.
36.3 Computação
As operações do ML-KEM são rápidas — muitas vezes mais rápidas que o X25519 em servidores com instruções vetoriais. A assinatura e a verificação do ML-DSA são rápidas; a assinatura do SLH-DSA é lenta (de milissegundos a segundos, conforme a variante). O planejamento da capacidade dos servidores, portanto, se concentra na largura de banda e nos serviços de assinatura, e não na CPU do KEM.
Para a BPA, isso desloca o planejamento para a largura de banda nos enlaces de satélite com os navios e para a vazão do serviço central de assinatura. A assinatura lenta do SLH-DSA é aceitável para uma raiz offline que assina raramente, mas não para assinar milhares de documentos por hora.
36.4 Medição
Meça os percentis da latência de handshake (p50, p95, p99) por tipo de cliente e caminho de rede, antes e depois; a vazão dos serviços de assinatura; as operações por segundo dos HSMs com os novos algoritmos. Relate distribuições, não médias.
As médias escondem a cauda, onde estão os usuários com enlaces ruins; um aumento de alguns milissegundos no p99 pode esconder algumas conexões que expiram por completo. A BPA registra a latência por tipo de cliente e caminho porque os navios em enlaces de satélite se comportam de forma muito diferente dos navegadores de escritório. As medições são feitas durante uma semana antes e outra depois de cada mudança, para que a variação diária normal não engane a comparação.
36.5 Exemplo resolvido
A BPA mede os handshakes de borda: latência p50 +0,4 ms e p99 +3 ms após ativar o X25519MLKEM768 (sintético); dentro do orçamento. Um teste de uma cadeia ML-DSA-65 num enlace de satélite com um navio mostra uma ida e volta a mais (+600 ms) — então as conexões dos navios mantêm certificados clássicos por mais tempo e recebem um ajuste da retomada de sessão.
O resultado da borda mostra que o custo do ML-KEM é pequeno em enlaces terrestres. O resultado do navio mostra que é a cadeia grande, e não a troca de chaves, que causa a ida e volta a mais, como o Laboratório B previa: mais de 15 kB de dados de autenticação excedem a janela de congestionamento inicial. A retomada de sessão evita reenviar a cadeia nas conexões repetidas.
36.6 Erros comuns e limites
- Medir apenas a CPU.
- Médias em vez da latência de cauda.
- Ignorar os efeitos das cadeias grandes sobre a janela de congestionamento.
Os benchmarks de CPU mostram o ML-KEM mais rápido que o X25519, mas não captam os custos de largura de banda que dominam nos enlaces lentos. As médias escondem as conexões lentas dos navios na cauda do p99. Cadeias grandes que excedem a janela de congestionamento acrescentam uma ida e volta inteira, o que num enlace de satélite de 600 milissegundos custa mais do que toda a computação somada. O plano da BPA mede cada classe de dispositivo e cada caminho de rede separadamente exatamente por esse motivo.
Nota de engenharia
O planejamento de capacidade deve incluir as pessoas que vão ler os números. Expresse os resultados como mudanças na latência visível ao usuário no percentil 99 por caminho e como bytes por conexão para a equipe de rede, e não apenas como operações por segundo. Uma mudança de dois milissegundos na mediana costuma ser invisível, enquanto uma ida e volta inteira a mais num enlace de alta latência com um navio não é; apresentar as duas lado a lado permite que as partes interessadas aceitem a mudança barata e planejem em torno da cara.
Exercícios
- EX071 — Orçamento da cadeia. Usando o Laboratório B, encontre o tamanho com profundidade 1 (apenas o certificado folha) para o ML-DSA-44 sem SCTs. Rubrica: 3 = valor correto e método.
- EX072 — Plano de medição. Escreva um plano de medição de latência para o enlace com os navios. Rubrica: 3 = percentis, caminhos, antes/depois, tamanho da amostra.
Síntese
O desempenho da PQC é sobretudo uma questão de bytes: a troca de chaves acrescenta kilobytes, os certificados acrescentam muitos mais; meça as caudas e os caminhos e planeje a capacidade de assinatura.
Continue estudando — capítulo 36 de 50
← Capítulo 35 · Índice de capítulos do curso · Capítulo 37 →
Siga para a próxima lição escrita.