Capítulo 26 — Segurança quântica e pós-quântica: métodos II
Mapa da aula
Aula 26 publicada. Mapa, exemplo, EX051.
flowchart TD
N0["26.1 Combinando segredos"]
N1["26.2 Atividade prática — Laboratório C"]
N2["26.3 Assinaturas pós-quânticas"]
N3["26.4 Comparando as opções"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX051"]
Desenho lógico
flowchart LR
N0["26.1 Combinando segredos"]
N1["26.2 Atividade prática — Laboratório C"]
N2["26.3 Assinaturas pós-quânticas"]
N3["26.4 Comparando as opções"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX051"]
[26.1 Combinando segredos]
|
v
[26.2 Atividade prática — Laboratório C]
|
v
[26.3 Assinaturas pós-quânticas]
|
v
[26.4 Comparando as opções]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX051]
Objetivos de aprendizagem
Você vai (1) explicar como os segredos híbridos são combinados com uma função de derivação de chaves; (2) executar um combinador de brinquedo e interpretar as suas saídas; (3) descrever o ML-DSA e o SLH-DSA no nível conceitual; e (4) comparar as opções de assinatura por tamanho, velocidade e hipóteses.
26.1 Combinando segredos
Um KEM híbrido produz dois segredos compartilhados. Um combinador alimenta os dois, mais um contexto como a transcrição do handshake, numa função de derivação de chaves (KDF), de modo que a saída seja imprevisível se qualquer um dos segredos for. A concatenação seguida do HKDF-Extract, como no projeto híbrido do TLS, é uma abordagem padrão; a SP 800-56C Rev. 2 e a SP 800-227 descrevem os métodos aprovados de derivação e de combinação de chaves.
O combinador é pequeno, mas é nele que a segurança do híbrido de fato se decide.
26.2 Atividade prática — Laboratório C
# Lab C (ch 26): a hybrid key combiner. The session key depends on BOTH shared secrets.
import hashlib, hmac
def hkdf_extract(salt, ikm): return hmac.new(salt, ikm, hashlib.sha256).digest()
def combine(ss_pq, ss_trad, context):
# Concatenate secrets (PQ first, as in X25519MLKEM768), bind the transcript/context, then extract.
return hkdf_extract(b"\x00" * 32, ss_pq + ss_trad + context).hex()[:16]
pq, trad, ctx = b"P" * 32, b"T" * 32, b"handshake-transcript-hash"
print("baseline ", combine(pq, trad, ctx))
print("PQ secret changed ", combine(b"Q" * 32, trad, ctx))
print("traditional changed ", combine(pq, b"U" * 32, ctx))
print("context changed ", combine(pq, trad, b"other-transcript"))
Saída esperada:
baseline d48e982e8c06ca60
PQ secret changed d4c36ea2d90b2e9c
traditional changed 8dcefa12ded3d99c
context changed af06eca8abcd45a9
Mudar qualquer um dos segredos, ou o contexto, muda completamente a chave derivada. Vincular o contexto impede que um atacante reutilize segredos entre handshakes diferentes.
As quatro chaves não compartilham nenhum padrão visível, que é a propriedade que uma KDF deve dar. A ordem das entradas também importa: o laboratório põe o segredo pós-quântico primeiro, como no X25519MLKEM768, e as duas pontas precisam usar a mesma ordem, senão derivam chaves diferentes. Num protocolo real, o contexto é o hash da transcrição do handshake, e a saída é expandida em chaves separadas para cada direção, em vez de truncada como aqui para exibição.
26.3 Assinaturas pós-quânticas
O ML-DSA (FIPS 204) é uma assinatura baseada em reticulados que usa a técnica "Fiat–Shamir with aborts": quem assina amostra repetidamente até que a assinatura candidata não revele nada sobre a chave. Os conjuntos de parâmetros ML-DSA-44, -65 e -87 têm assinaturas de 2.420, 3.309 e 4.627 bytes. O SLH-DSA (FIPS 205) depende apenas de funções de hash; ele tem chaves públicas minúsculas (32–64 bytes), mas assinaturas grandes (de 7.856 a 49.856 bytes) e assinatura mais lenta. O LMS e o XMSS são menores e mais rápidos, mas têm estado. O FN-DSA, baseado no Falcon, promete assinaturas compactas e ainda está em desenvolvimento.
26.4 Comparando as opções
Compare as assinaturas quanto a: hipótese (reticulados versus hash), tamanhos, velocidade de assinatura e de verificação, existência de estado e suporte no ecossistema. Para os certificados TLS, a velocidade e o tamanho moderado do ML-DSA são o melhor encaixe. Para o firmware assinado raramente e verificado no boot, o conservadorismo do SLH-DSA ou as assinaturas pequenas do LMS podem ser preferidos. Para documentos que precisam de décadas de confiança, o conservadorismo pesa muito.
As escolhas da própria HCU seguem esse padrão: ML-DSA para os certificados do gateway, com a assinatura do firmware dos terminais de cartão ainda em análise. Cada escolha é registrada com o motivo, para que possa ser revista quando o suporte no ecossistema ou a criptoanálise mudarem.
26.5 Exemplo resolvido
A HCU compara opções para assinar os extratos dos associados, produzidos 500.000 vezes por mês: ML-DSA-65 (assinaturas de 3.309 bytes, assinatura rápida) versus SLH-DSA-SHA2-128s (assinaturas de 7.856 bytes, assinatura lenta). O volume e o tamanho dos PDFs favorecem o ML-DSA-65; a HCU registra o risco residual da hipótese e planeja manter os identificadores de algoritmo em cada documento, para que uma mudança futura seja possível.
A comparação é registrada no log de decisões junto com a taxa de assinatura medida nos servidores de extratos da HCU, para que possa ser revista se os volumes mudarem. As medições mostraram que o SLH-DSA teria precisado de hardware adicional para acompanhar.
26.6 Erros comuns e limites
- Combinar segredos por XOR sem vínculo com o contexto.
- Escolher o SLH-DSA para TLS de alto volume sem medir o custo.
- Usar assinaturas com estado onde o estado não pode ser protegido.
- Truncar a saída combinada abaixo da força necessária para a chave de sessão.
- Comparar esquemas de assinatura apenas pelo tamanho da assinatura, ignorando a chave pública levada em cada certificado.
- Deixar o identificador de algoritmo fora dos documentos assinados, o que dificulta uma migração posterior.
- Supor que um projeto híbrido é seguro porque cada componente é, sem verificar que o combinador vincula os dois segredos e o contexto.
Exercícios
- EX051 — Propriedade do combinador. Usando o Laboratório C, explique por que a chave de sessão continua imprevisível se o X25519 for quebrado, mas o ML-KEM não. Rubrica: 3 = falta ao atacante uma entrada da KDF.
- EX052 — Escolha da assinatura. Escolha uma assinatura para o firmware dos caixas eletrônicos, assinado quatro vezes por ano, e justifique. Rubrica: 3 = LMS/XMSS ou SLH-DSA com raciocínio sobre volume, estado e conservadorismo.
Síntese
Os segredos híbridos são combinados por uma KDF vinculada ao contexto. O ML-DSA serve para a assinatura de alto volume; o SLH-DSA e as assinaturas baseadas em hash com estado trocam tamanho ou estado por hipóteses conservadoras.
Continue estudando — capítulo 26 de 40
← Capítulo 25 · Índice de capítulos do curso · Capítulo 27 →
Siga para a próxima lição escrita.