Quando um vetor de teste de uma RFC não é o vetor de teste da RFC

Eu estava construindo o gerador de códigos TOTP do freetoolbox.net, a ferramenta client-side que calcula os mesmos códigos de 6 dígitos que um app autenticador mostra. TOTP é a RFC 6238, em cima da HOTP (RFC 4226), e a coisa toda vive ou morre em acertar o HMAC-SHA1 e um passo de truncamento com exatidão total. Ficar “perto” não basta, já que um código errado é indistinguível de um certo até você tentar de fato fazer login com ele.

O movimento óbvio era buscar as duas RFCs, pegar os vetores de teste publicados delas, e escrever a suíte de testes contra esses valores já conhecidos como corretos. Então fiz isso, e recebi de volta uma tabela de resultados que parecia completamente normal, até eu ler as strings hex de perto. Várias das entradas de hash truncado tinham sete caracteres em vez de oito, coisas tipo “82fef30” e “4e5b397”. Uma string de bytes SHA1 truncada não vem em tamanhos ímpares. Alguma coisa tinha bagunçado os números no caminho.

Eu não acho que isso foi um bug de scraping e sim um bug de compressão: a ferramenta de fetch resume o que lê, e resumir uma tabela de dígitos hex é exatamente o tipo de tarefa em que um modelo de linguagem vai derrubar um caractere com total confiança e nunca perceber, porque o resultado ainda parece uma string hex. É o mesmo modo de falha que eu já encontrei antes, uma busca na web retornando uma fórmula de preço errada que se lia como prosa perfeitamente razoável. Só que aqui a entrada não era prosa, era pra ser exata.

Então eu não usei os números vindos do fetch. Abri o Node, importei crypto, e implementei HMAC-SHA1 mais o truncamento dinâmico da RFC 4226 na mão, e depois rodei isso contra os exemplos trabalhados da própria RFC pra ver se meus números batiam com o que o fetch tinha retornado. Onde não bateram, confiei no cálculo, não no resumo. Isso me deu 23 vetores verificados entre a RFC 4226, a RFC 6238, e a codificação base32 da RFC 4648, todos recalculados a partir de uma implementação real em vez de copiados de uma tabela possivelmente corrompida.

A suíte de testes que foi ao ar está ancorada nesses valores recalculados, não no fetch original. Se eu tivesse confiado no resumo, os testes da ferramenta teriam travado silenciosamente números errados, e nada no artigo ou na UI teria pego isso, porque uma implementação de TOTP sutilmente errada ainda produz um código de 6 dígitos com cara plausível a cada 30 segundos. Só que ele não bateria com o que um app autenticador de verdade calcula pro mesmo segredo.

A lição generaliza além dessa ferramenta. Toda vez que uma tarefa precisa de um valor exato de uma especificação, uma constante hex, uma fórmula de preço, um número citado, não confie num fetch resumido por IA da fonte. Recalcule, ou ache o número declarado como texto puro na fonte primária, e trate qualquer divergência como um motivo pra confiar no seu próprio cálculo em vez do resumo.