Hay algunas referencias por ahí que dicen que HMAC-SHA2 debe usarse sobre HMAC-SHA1.
Si estoy usando un enlace IPsec con HMAC-SHA1, ¿qué tan vulnerable es ser interceptado y resquebrajado?
Hay algunas referencias por ahí que dicen que HMAC-SHA2 debe usarse sobre HMAC-SHA1.
Si estoy usando un enlace IPsec con HMAC-SHA1, ¿qué tan vulnerable es ser interceptado y resquebrajado?
Para evitar la intercepción y la lectura del contenido secreto, se utilizan algoritmos de cifrado como AES. HMACs no importan en absoluto para esta parte.
Suponiendo que AES (CBC, etc.) sea seguro, un atacante podría interceptar lo que está enviando o recibiendo, pero no puede leerlo. Lo que podría hacer, sin embargo, es cambiar los datos a otra cosa. Una vez más, asumiendo que AES es seguro, no hay forma de que el atacante le brinde algunos datos que, al descifrarlos, sean significativos, pero sigue siendo un problema, porque no siempre es posible detectar automáticamente que tiene basura.
Ese es el propósito de HMAC (con cualquiera de los algoritmos hash) en IpSec: permite verificar si el contenido se ha modificado durante la transmisión.
Si bien el SHA1 en bruto no es tan seguro como se pensaba, los problemas conocidos no se aplican a los HMAC con SHA1. Esencialmente, el riesgo se reduce a la posibilidad de que un atacante adivine la clave correcta o el hash para un mensaje, para hacerle creer que un mensaje incorrecto con contenido basura es el verdadero (y nada más):
Para SHA1 en IpSec, la clave puede tener 2 ^ 160 valores posibles (si el atacante tiene la clave, puede generar HMACs para todos los mensajes recibidos, es decir, darle tanta basura como quiera), o 2 ^ 96 valores posibles para el hash en sí (si el atacante logra obtener eso, solo se puede cambiar un bloque). Si bien podría ser mejor, no es tan malo, especialmente porque es muy poco probable que encuentre el valor correcto antes de que finalice la transmisión.
Para SHA256, los valores correspondientes son 2 ^ 256 y 2 ^ 128.
(Ver también RFCs 6071, 2404, 4868)