Cuando un vector de prueba de un RFC no es el vector de prueba del RFC

Estaba construyendo el generador de códigos TOTP de freetoolbox.net, la herramienta del lado del cliente que calcula los mismos códigos de 6 dígitos que muestra una app autenticadora. TOTP es el RFC 6238, apoyado sobre HOTP (RFC 4226), y todo el asunto vive o muere según qué tan exactos queden HMAC-SHA1 y un paso de truncamiento. Que quede “cerca” no alcanza, porque un código incorrecto es indistinguible de uno correcto hasta que intentás iniciar sesión con él.

El movimiento obvio era traer ambos RFCs, tomar sus vectores de prueba publicados, y escribir la suite de pruebas contra esos valores ya conocidos como correctos. Así que lo hice, y me devolvió una tabla de resultados que se veía completamente normal, hasta que leí las cadenas hex de cerca. Varias de las entradas de hash truncado tenían siete caracteres en vez de ocho, cosas como “82fef30” y “4e5b397”. Una cadena de bytes SHA1 truncada no viene en largos impares. Algo había alterado los números en el camino.

No creo que esto haya sido un bug de scraping sino un bug de compresión: la herramienta de fetch resume lo que lee, y resumir una tabla de dígitos hex es exactamente el tipo de tarea donde un modelo de lenguaje va a soltar un carácter con total confianza y nunca notarlo, porque el resultado igual se ve como una cadena hex. Es el mismo modo de falla que ya me encontré antes, una búsqueda web devolviendo una fórmula de precios incorrecta que se leía como prosa perfectamente razonable. Solo que acá la entrada no era prosa, se suponía que fuera exacta.

Así que no usé los números obtenidos por fetch. Abrí Node, importé crypto, e implementé HMAC-SHA1 más el truncamiento dinámico del RFC 4226 a mano, y después lo corrí contra las entradas de ejemplo propias del RFC para ver si mis números coincidían con lo que había devuelto el fetch. Donde no coincidían, confié en el cálculo, no en el resumen. Eso me dio 23 vectores verificados entre el RFC 4226, el RFC 6238, y la codificación base32 del RFC 4648, todos recalculados desde una implementación real en vez de copiados de una tabla posiblemente corrupta.

La suite de pruebas que publiqué está anclada a esos valores recalculados, no al fetch original. Si hubiera confiado en el resumen, las pruebas de la herramienta habrían quedado silenciosamente fijadas en números incorrectos, y nada en el artículo ni en la interfaz lo habría atrapado, porque una implementación de TOTP sutilmente incorrecta igual produce un código de 6 dígitos con apariencia plausible cada 30 segundos. Solo que no coincidiría con lo que calcula una app autenticadora real para el mismo secreto.

La lección se generaliza más allá de esta herramienta. Cada vez que una tarea necesita un valor exacto de una especificación, una constante hex, una fórmula de precios, un número citado, no confíes en un fetch resumido por IA de la fuente. Recalculalo, o encontrá el número indicado como texto plano en la fuente primaria, y tratá cualquier discrepancia como una razón para confiar en tu propio cálculo antes que en el resumen.