Vamos a explicar, sin código ni jerga dura, cómo algunas formas de calcular un hash permiten el ataque de extensión de longitud. Veremos qué pasa en un banco que firma mensajes con una clave pegada al texto y cómo evitarlo.
Imaginemos dos bancos. El primero crea una transacción, le añade una clave secreta al principio del mensaje y calcula un hash con SHA doscientos cincuenta y seis. El segundo recibe el mensaje con su hash y lo valida del mismo modo. Hasta aquí todo parece correcto, pero hay un matiz técnico importante: la función procesa el mensaje por bloques y aplica un relleno automático según la longitud.
Ese detalle abre una puerta a quien escuche. Sin conocer la clave, puede inferir cómo quedaría el relleno del mensaje original y continuar el cálculo del hash como si fuese el sistema. En la práctica, aprovecha el estado interno del algoritmo para añadir texto al final y obtener un hash válido del mensaje extendido. Resultado: el verificador da por bueno algo que nunca firmó el primer banco.
Este fallo no rompe la función hash en sí, sino el método de autenticación. Concatenar clave y mensaje y luego sacar un hash no es un mecanismo de autenticación confiable. Si alguien puede extender el texto, podría, por ejemplo, introducir condiciones nuevas o un importe mayor y seguir pasando el control del segundo banco sin conocer la clave.
La solución es simple de escribir y difícil de improvisar, así que conviene usar recetas probadas. Para autenticar mensajes, HMAC con SHA doscientos cincuenta y seis es el estándar: combina la clave de forma robusta y neutraliza el problema del relleno y del encadenamiento. Si necesitamos no repudio, mejor firmas digitales como EdDSA o RSA con PSS. Y si ciframos además, esquemas con autenticación integrada como AEAD evitan atajos peligrosos. En resumen, nada de inventar criptografía ni de pegar clave y texto tal cual.
Buenas prácticas rápidas para nuestro código del día a día. Uno, usar librerías serias y versiones actuales. Dos, preferir primitivas de alto nivel como HMAC antes que ensamblar piezas. Tres, revisar cómo se construye la autenticación en cualquier API que consumamos. Cuatro, testear casos de mensajes largos y formatos reales, no solo ejemplos de juguete.
Propuesta de juego rápida: preparamos tarjetas con distintos esquemas de autenticación y, en un minuto por ronda, clasificamos cada uno como seguro o arriesgado y decimos por qué. Sumamos puntos si acertamos y si proponemos una alternativa mejor.
Si queremos aprender más con ideas claras y juegos que despejan dudas, visitemos JeiJoLand.