Cero relleno en HMAC

7

La Sección 2 de RFC 2104 define que la clave utilizada en HMAC debe completarse con cero bytes hasta la longitud de bloque del algoritmo de hash subyacente. ¿No es esto una vulnerabilidad de seguridad potencial ya que cualquier clave que finalice en un byte cero produciría el mismo resultado que una clave sin ese último byte?

El siguiente código PHP ilustra el ejemplo:

$key = "key";
$message = "message";
var_dump(hash_hmac("SHA256", $message, $key));
var_dump(hash_hmac("SHA256", $message, $key.chr(0x00)));

y produce el siguiente resultado:

string(64) "6e9ef29b75fffc5b7abae527d58fdadb2fe42e7219011976917343065f58ed4a"
string(64) "6e9ef29b75fffc5b7abae527d58fdadb2fe42e7219011976917343065f58ed4a"

Soy consciente de que la sección 3 de la misma RFC recomienda claves de una longitud mínima, lo que eliminaría este problema, al igual que algún tipo de paso de generación de clave con hash. Sin embargo, me parece que esto podría ser un problema potencial, o ¿estoy siendo demasiado paranoico?

    
pregunta KennethJ 22.01.2012 - 17:49
fuente

2 respuestas

7

No, esto no es una vulnerabilidad de seguridad.

HMAC requiere una clave del tamaño de bloque del algoritmo hash subyacente. En general, debe proporcionar una clave que sea del tamaño de bloque del algoritmo hash subyacente.

Si olvida proporcionar una clave de este tamaño, hay dos opciones. La primera opción es que HMAC falle con dificultad y te informe de que tu clave es del tamaño incorrecto. La segunda opción es que HMAC simplemente asume que pretendías proporcionar una clave del tamaño correcto, pero que simplemente dejaste de lado todos los bytes cero finales por accidente que se suponía que estaban allí.

La segunda opción anterior concuerda con la política de ser liberal en las entradas que uno aceptará, pero que será estricta en las salidas que se generarán.

Así que HMAC no está perdiendo información con la segunda opción, porque una clave de un tamaño más pequeño no es una clave válida. Simplemente hay una política de tomar claves inválidas y hacerlas válidas para su conveniencia de una manera determinista y documentada.

    
respondido por el yfeldblum 22.01.2012 - 18:57
fuente
3

Con un algoritmo como HMAC, la fuerza de una clave se relaciona con el número de claves posibles, dentro del conjunto con el que eligió trabajar. Por ejemplo, es posible que desee trabajar con claves de 128 bits, en cuyo caso todas sus claves tendrán una longitud exactamente de 16 bytes.

Que dos claves distintas puedan producir el mismo comportamiento HMAC es un problema potencial solo si ambas claves son posibles en su sistema. Para el tema del que habla aquí, esto puede suceder solo si su sistema acepta claves de varias longitudes, lo cual no es una situación común. Si considera SSL / TLS , HMAC se usa con una clave generada desde el secreto maestro, con un determinado corregido longitud para una función hash dada (por ejemplo, si se usa SHA-256, la clave HMAC siempre tendrá una longitud de 32 bytes). Por lo tanto, no hay problema.

Si sus claves son cadenas C (es decir, cadenas que terminan con un byte de valor 0), entonces tampoco hay problema: por definición, una cadena C no contiene ningún byte de valor 0, por lo que no puede tener dos cadenas C distintas, a través del cero-relleno, dará la misma clave.

Si está realmente molesto por ello, una opción es marcar sistemáticamente la clave y usar la salida de hash como la clave real para HMAC (tenga en cuenta que la especificación HMAC en realidad exige un hash cuando la clave es más grande que el" tamaño de bloque "de la función de hash subyacente).

    
respondido por el Tom Leek 22.01.2012 - 22:31
fuente

Lea otras preguntas en las etiquetas