Capítulo 25 — Laboratório I | Graduação Segurança quântica e pós-quântica

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 25 publicada. Mapa, exemplo, EX049.

flowchart TD
  N0["25.1 Por que testar as implementações"]
  N1["25.2 Atividade prática — Laboratório V"]
  N2["25.3 Registros de laboratório"]
  N3["25.4 Interpretando os resultados"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX049"]

Desenho lógico

flowchart LR
  N0["25.1 Por que testar as implementações"]
  N1["25.2 Atividade prática — Laboratório V"]
  N2["25.3 Registros de laboratório"]
  N3["25.4 Interpretando os resultados"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX049"]

[25.1 Por que testar as implementações]
    |
    v
[25.2 Atividade prática — Laboratório V]
    |
    v
[25.3 Registros de laboratório]
    |
    v
[25.4 Interpretando os resultados]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX049]

Objetivos de aprendizagem

Você vai (1) executar testes de resposta conhecida (KATs) e testes negativos; (2) explicar por que os programas de validação testam implementações; (3) construir um registro de laboratório reprodutível; e (4) interpretar corretamente os resultados de aprovação e reprovação.

25.1 Por que testar as implementações

As normas definem algoritmos; as implementações ainda podem estar erradas. Os testes de resposta conhecida rodam uma implementação sobre entradas fixas e comparam com as saídas publicadas; os testes negativos fornecem entradas malformadas e esperam a rejeição. O Cryptographic Algorithm Validation Program do NIST aplica esses testes às implementações das FIPS 203, 204 e 205. Os estudantes não conseguem validar uma biblioteca de produção, mas podem aprender o hábito com as primitivas da biblioteca padrão.

O objetivo do exercício é separar duas afirmações fáceis de confundir: que um algoritmo é sólido, e que um determinado código o calcula corretamente. Os desenvolvedores da HCU confiam na primeira a partir do processo de normalização e precisam estabelecer a segunda por conta própria para cada biblioteca que implantam.

25.2 Atividade prática — Laboratório V

# Lab V (ch 25): known-answer and negative tests - the habit behind validating PQC libraries.
import hashlib
KATS = [  # (function, input, expected hex prefix) - published test values for SHA-3 / SHAKE on empty input
    ("sha3_256", b"", "a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a"),
    ("shake_128/32", b"", "7f9c2ba4e88f827d616045507605853ed73b8093f6efbc88eb1a6eacfa66ef26"),
]
def run(name, data):
    if name == "sha3_256": return hashlib.sha3_256(data).hexdigest()
    return hashlib.shake_128(data).hexdigest(32)
for name, data, want in KATS:
    print(f"KAT {name:13s}", "PASS" if run(name, data) == want else "FAIL")
SIZES = {"ML-KEM-512": 800, "ML-KEM-768": 1184, "ML-KEM-1024": 1568}   # encapsulation-key bytes, FIPS 203
def validate_ek(param, ek):
    if len(ek) != SIZES[param]: raise ValueError(f"{param}: expected {SIZES[param]} bytes, got {len(ek)}")
    return True
for param, n in [("ML-KEM-768", 1184), ("ML-KEM-768", 1183), ("ML-KEM-512", 1184)]:
    try: validate_ek(param, bytes(n)); print(f"negative/positive test {param} len {n}: accepted")
    except ValueError as e: print(f"negative/positive test {param} len {n}: rejected ({e})")

Saída esperada:

KAT sha3_256      PASS
KAT shake_128/32  PASS
negative/positive test ML-KEM-768 len 1184: accepted
negative/positive test ML-KEM-768 len 1183: rejected (ML-KEM-768: expected 1184 bytes, got 1183)
negative/positive test ML-KEM-512 len 1184: rejected (ML-KEM-512: expected 800 bytes, got 1184)

Os KATs de hash passam porque o SHA-3 do Python coincide com os valores publicados; as verificações de comprimento mostram uma aceitação e duas rejeições. Um decodificador ML-KEM real também verifica os intervalos dos coeficientes, como a FIPS 203 exige.

Os dois tipos de teste são necessários. Os KATs confirmam que as entradas corretas dão as saídas publicadas; os testes negativos confirmam que as entradas de tamanho errado são recusadas, e não processadas. Observe o terceiro caso: uma chave com o comprimento certo para o ML-KEM-768 ainda é rejeitada quando quem chama alega ML-KEM-512, porque o conjunto de parâmetros precisa coincidir. Muitos bugs reais de interoperabilidade vêm exatamente desse tipo de descompasso entre um rótulo e os bytes que o acompanham.

25.3 Registros de laboratório

Um registro de laboratório declara a pergunta, o ambiente (versões do sistema operacional, do Python e das bibliotecas), as entradas, os comandos exatos, as saídas e a interpretação. Guarde-o junto com o código para que qualquer pessoa possa rodá-lo de novo. Se uma atualização de biblioteca mudar um resultado, o registro mostra o que mudou.

Os bons registros também anotam o que não foi testado, para que um leitor posterior não suponha uma cobertura que nunca existiu. Na HCU, o registro de laboratório de cada biblioteca criptográfica fica ao lado da sua configuração no controle de versão, e o chamado de mudança de qualquer atualização de biblioteca aponta para o registro da nova execução. Um auditor consegue então rastrear uma versão de produção até a evidência de que ela foi aprovada.

25.4 Interpretando os resultados

Um KAT aprovado mostra que a implementação coincide com a referência naquelas entradas; ele não mostra comportamento de tempo constante, tratamento correto das chaves nem integração segura. Um teste reprovado pode revelar um bug na implementação, no vetor de teste ou no harness. Inclua um controle negativo — uma implementação deliberadamente errada que o teste precisa pegar — para confirmar que o harness consegue reprovar.

No Laboratório V, os comprimentos de chave rejeitados funcionam como uma versão simples desse controle. Se o controle passar, o próprio harness está quebrado e todos os resultados anteriores ficam em dúvida.

25.5 Exemplo resolvido

Uma desenvolvedora da HCU integra uma nova biblioteca de PQC. O seu registro de laboratório: a versão da biblioteca, os vetores de teste dos arquivos de KAT publicados pelo fornecedor, um harness que compara as saídas e um controle negativo que inverte um byte de uma saída esperada para verificar que o harness relata a reprovação. Todos os KATs passam; o controle negativo reprova, como esperado. O registro anota que o comportamento quanto a canais laterais não foi testado e está coberto pela avaliação da própria biblioteca.

A desenvolvedora também registra de onde vieram os vetores e quando foram baixados, para que uma atualização posterior dos arquivos do fornecedor possa ser conferida com a versão usada.

25.6 Erros comuns e limites

Tratar o sucesso nos KATs como prova de segurança.
Harnesses que não conseguem reprovar.
Versões não registradas, o que torna os resultados irreprodutíveis.
Rodar apenas testes positivos, de modo que as entradas malformadas nunca são exercitadas.
Baixar vetores de teste de um espelho não oficial sem verificar a sua origem.
Não rodar nada de novo depois de uma atualização de biblioteca porque a execução anterior passou.
Testar uma biblioteca isoladamente e supor que a integração se comporta igual, quando o código que a chama pode passar o conjunto de parâmetros errado ou tratar mal os erros.

Cada um desses deixa uma lacuna que o registro de laboratório deveria tornar visível, e não esconder.

Exercícios

EX049 — Controle negativo. Descreva um controle negativo para o KAT de SHA3-256 do Laboratório V. Rubrica: 3 = entrada ou valor esperado deliberadamente errado que precisa produzir FAIL.
EX050 — Limites. Liste três propriedades que um KAT aprovado não estabelece. Rubrica: 3 = canais laterais, gestão de chaves, integração/uso no protocolo (ou equivalentes).

Síntese

Os testes de resposta conhecida e os negativos, registrados de forma reprodutível e conferidos com controles negativos, são a evidência básica de que uma implementação coincide com a sua norma — e nada mais.