No hay una respuesta absoluta, ya que depende del modelo de ataque . Al truncar el hash, facilita algunas operaciones; esto es malo si el atacante quiere realizar estas operaciones, y hacerlas más fáciles en realidad las hace factibles .
Hay tres características principales que las funciones de hash criptográficas intentan cumplir:
-
Resistencia a las imágenes previas: dado x , no debería ser posible encontrar m de manera que h (m) = x .
-
Resistencia a las segundas preimágenes: dado m , no debería ser factible encontrar m '≠ m tal que h (m) = h (m ') .
-
Resistencia a las colisiones: no debería ser factible encontrar m '≠ m de modo que h (m) = h (m') .
Para una función hash perfecta que tiene una salida de bits n , los costos de encontrar preimágenes, segundas preimágenes o colisiones serán, respectivamente, 2 n , 2 n y 2 n / 2 . Al truncar la salida de hash, reduce estos costos de manera correspondiente. Como regla general, un costo de 2 64 es muy difícil (posible, pero toma más de una docena de PC) y 2 80 no es factible.
En su caso, si una colisión es interesante para el atacante, y puede elegir qué hash, entonces el atacante intentará ingresar dos elementos de datos que implica una colisión de hash (en tu hash truncado). Truncar a 12 bytes hace que el ataque sea bastante factible, fácil si bajas a 8 bytes. Por otro lado, si todo lo que el atacante puede hacer es tratar de encontrar algún elemento de datos que coincida con un hash truncado dado (segundo preimagen), entonces con 10 o 12 bytes, esto todavía es demasiado difícil para ser factible, y con 8 bytes es simplemente "muy caro" (por lo que probablemente no valga la pena el esfuerzo).
Si no hay un atacante y solo estás luchando contra la mala suerte, el truncado a 8 bytes incurre en el riesgo de colisiones falsas; debe alcanzar su primera colisión después de (en promedio) ingresar unos cuantos miles de millones de entradas. Dependiendo de su situación, esto puede o no ser tolerable.