Capítulo 30 — Laboratório de verificação I
Mapa da aula
Aula 30 publicada. Mapa, exemplo, EX088.
flowchart TD
N0["30.1 Verificação e validação"]
N1["30.2 Vetores de teste"]
N2["Laboratório — vetores de teste"]
N3["30.3 Lendo o resultado"]
N4["30.4 Além dos vetores"]
N5["30.5 Registrando a execução"]
N6["30.6 Vetores que falham"]
N7["30.7 Repetição a cada lançamento"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX088"]
Desenho lógico
flowchart LR
N0["30.1 Verificação e validação"]
N1["30.2 Vetores de teste"]
N2["Laboratório — vetores de teste"]
N3["30.3 Lendo o resultado"]
N4["30.4 Além dos vetores"]
N5["30.5 Registrando a execução"]
N6["30.6 Vetores que falham"]
N7["30.7 Repetição a cada lançamento"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX088"]
[30.1 Verificação e validação]
|
v
[30.2 Vetores de teste]
|
v
[Laboratório — vetores de teste]
|
v
[30.3 Lendo o resultado]
|
v
[30.4 Além dos vetores]
|
v
[30.5 Registrando a execução]
|
v
[30.6 Vetores que falham]
|
v
[30.7 Repetição a cada lançamento]
|
v
[Exemplo resolvido] --> [Exercício EX088]
Objetivos de aprendizagem
Você vai (1) verificar um componente de hash contra vetores de teste publicados; (2) distinguir verificação de validação; (3) registrar uma execução de verificação; (4) lidar com um vetor que falha.
30.1 Verificação e validação
A verificação pergunta se o componente atende à sua especificação. A validação pergunta se o método inteiro é adequado à sua finalidade forense. A ISO/IEC 27041 trata da garantia de que os métodos são adequados e suficientes; a verificação dos componentes é uma das entradas. Uma rotina de hash pode passar em todos os testes de componente e o método ainda ser inadequado, por exemplo se o procedimento do laboratório permitir que os peritos pulem a verificação. A validação testa a cadeia inteira em condições realistas: hardware real, procedimentos reais e evidências realistas. O relatório de Priya mantém as duas separadas, listando primeiro os componentes verificados e depois as evidências de validação do método tal como é usado.
30.2 Vetores de teste
As normas das funções de hash publicam entradas de exemplo com os digests esperados. Os valores de exemplo do NIST para o SHA-256 incluem a mensagem "abc". A mensagem vazia também tem um digest SHA-256 amplamente publicado. Coincidir com eles mostra que a implementação calcula o algoritmo corretamente para essas entradas. Os vetores de teste são entradas pequenas e fixas com saídas conhecidas, então um resultado aprovado mostra que a implementação concorda com a norma nessas entradas. Eles não cobrem todas as entradas, mas um algoritmo implementado de forma errada quase sempre falha em pelo menos um deles. Priya copia os valores esperados do documento de origem para seu arquivo de teste e registra de onde vieram.
Laboratório — vetores de teste
"""Validate the hashing library against published test vectors."""
import hashlib
vec = {b"abc": "ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad",
b"": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"}
ok = 0
for m, d in vec.items():
r = hashlib.sha256(m).hexdigest() == d; ok += r
print(repr(m), "PASS" if r else "FAIL")
print(f"{ok}/{len(vec)} vectors passed")
Execute com python3 lab_vectors.py. Saída verificada:
b'abc' PASS
b'' PASS
2/2 vectors passed
30.3 Lendo o resultado
Os dois vetores passam: "abc" e a mensagem vazia produzem os digests esperados, 2/2. Uma única falha interromperia o lançamento até ser explicada. Dois vetores aprovados são uma amostra pequena, por isso Priya os trata como uma verificação básica de correção, e não como uma garantia completa. Uma falha seria grave o bastante para bloquear sozinha o lançamento, porque qualquer divergência num vetor publicado significa que o código ou o teste está errado, e o laboratório não pode usar o EvidenceDesk até saber qual dos dois.
30.4 Além dos vetores
Os vetores testam o algoritmo, não o código ao redor que lê os arquivos. Priya acrescenta testes que calculam o hash de arquivos sintéticos de conteúdo conhecido pelo próprio caminho de leitura do EvidenceDesk e comparam com o resultado da biblioteca. Um erro de leitura de arquivo pode pular o último bloco parcial, ler além do fim ou abrir os arquivos em modo texto, o que altera as terminações de linha em alguns sistemas. Testes com arquivos de 0 byte, 1 byte, exatamente um bloco e um bloco mais um byte conferem esses casos. Cada resultado do EvidenceDesk é comparado com uma chamada direta à biblioteca sobre os mesmos bytes.
30.5 Registrando a execução
O caderno do laboratório registra a data, o testador, a versão do código, a versão do Python, os vetores usados e os resultados. O registro é assinado e guardado com o lançamento. A assinatura é a do próprio testador, com a data. O registro é guardado com o lançamento, para que qualquer pessoa que examine um caso passado possa descobrir em quais testes a versão em uso tinha passado. Se mais tarde se descobrir que um teste tinha falhas, os registros mostram quais lançamentos dependiam dele, e esses lançamentos podem ser reavaliados. Registros sem assinatura não contam.
30.6 Vetores que falham
Se um vetor falhar, suspeite primeiro do teste (erro de digitação no valor esperado), depois do código. As duas conferências são registradas. Erros de digitação nos valores esperados são comuns: um dígito hexadecimal errado entre sessenta e quatro passa despercebido com facilidade. Priya confere o valor esperado contra uma segunda fonte independente antes de suspeitar de seu código. Se o teste está certo e o código está errado, o defeito é registrado, o lançamento é bloqueado, e a correção inclui um novo teste de regressão para o caso que falhou.
30.7 Repetição a cada lançamento
Os vetores rodam automaticamente a cada build, para que uma regressão seja pega na hora. O script de build executa os vetores antes do empacotamento e se recusa a produzir um artefato de lançamento se algum falhar. Os resultados são anexados ao registro do build. Executá-los a cada build, e não apenas antes dos lançamentos, significa que uma regressão introduzida numa terça-feira é notada na terça-feira, e não semanas depois, quando a mudança é mais difícil de rastrear. Os desenvolvedores também podem executar os vetores localmente, em segundos, antes de enviar uma mudança, então a maioria das falhas nunca chega ao build compartilhado.
Conferência independente
Priya também compara os digests do EvidenceDesk com os de uma segunda ferramenta, escrita de forma independente, em vinte arquivos sintéticos. A concordância entre as ferramentas acrescenta confiança além dos vetores.
Exemplo resolvido
A execução de um colega falha no vetor "abc". A investigação mostra que uma quebra de linha final entrou no hash — a entrada foi lida de um arquivo de texto. Corrigir a entrada do teste restaura a aprovação; o registro anota a causa.
Caso sintético. A execução do colega é inventada.
Erros e limites
Passar nos vetores não mostra que o tratamento de arquivos grandes ou o código de leitura de arquivos está correto; testes separados mostram.
Exercícios
- EX088 — V e V. Distinga verificação de validação. Rubrica: 3 = atende à especificação versus adequada à finalidade forense; 2 = parcial; 1 = iguais; 0 = nada.
- EX089 — Falha da quebra de linha. O que causou a falha do vetor? Rubrica: 3 = quebra de linha final vinda da entrada em texto; 2 = parcial; 1 = erro da biblioteca; 0 = nada.
- EX090 — Limites dos vetores. O que os vetores não testam? Rubrica: 3 = o caminho de leitura de arquivos, arquivos grandes; 2 = parcial; 1 = tudo é testado; 0 = nada.
Síntese
Os vetores verificam o algoritmo; os testes do caminho de arquivos e as execuções registradas estendem a confiança ao componente.
Continue estudando — capítulo 30 de 50
← Capítulo 29 (rascunho) · Índice de capítulos do curso · Capítulo 31 (rascunho) →