¿Hay un umbral de bits de entropía debajo del cual el hash no tiene sentido?

Question

¿Hay un umbral de bits de entropía debajo del cual el hash no tiene sentido?

#1 de SilverlightFox (3 votos)
#2 de ztk (0 votos)

8

Acabo de leer una página de ayuda de un proveedor de correo en el que dicen que todos los números de teléfonos móviles serán almacenado como un hash salado. Esto me parece interesante, ya que los números de teléfono no contienen mucha entropía: alrededor de 31 bits según mis cálculos.

Dependiendo de la función de hashing, generar 2 hash ³¹ debería ser bastante rápido. Las funciones hash adaptativas como bcrypt permiten aumentar el número de iteraciones. Dividir un hash de este tipo tomaría considerablemente más tiempo, pero usar demasiadas iteraciones de hash ralentizará la aplicación en su totalidad.

En pocas palabras, ¿existe una cosa como la cantidad más baja de entropía debajo de la cual el hash se vuelve inútil o perjudicial?

hash entropy

pregunta tarleb 03.02.2016 - 22:04

fuente

2 respuestas

0

No hay una línea mágica más allá de la cual el hashing sea inútil. Más bien, a medida que reduce la entropía de la entrada, la salida se vuelve más fácil de adivinar.

En el caso de este proveedor de correo, pueden agregar entropía usando la sal. Cuanto mayor sea la sal, más entropía agregará.

respondido por el ztk 03.02.2016 - 23:59

fuente

Lea otras preguntas en las etiquetas hash entropy

¿Respuesta a un escaneo no autorizado por una compañía legítima? [cerrado] Casos donde DBAN ha ganado

score 3 · Accepted Answer

Para una función de inicio de sesión, debe intentar que el proceso de hash tome alrededor de un segundo.

Si toma esta publicación como guía, 1170ms requiere alrededor de 8,192 iteraciones de bcrypt (costo de 13) .

Esto significa que sus iteraciones agregan alrededor de 13 bits de entropía efectiva.

Si solo tiene 31 bits de entropía en un valor secreto y hash, esta configuración de bcrypt le dará 44 bits de entropía.

Como guía, 47 bits de entropía tardarían 0.223 horas como máximo por craqueo por número de teléfono (suponiendo que sean 350 mil millones adivina / seg). Incluso si el atacante no tuviera este tipo de recursos y adivinara 2 billones de suposiciones por segundo con una sola PC doméstica, esto demoraría 39 horas por cada número de teléfono.

Entonces, para responder a su pregunta, no tiene sentido cuando necesita aumentar el tiempo de hashing a un nivel inaceptable (un costo de 16 para agregar 16 bits sería más de 9 segundos, lo que describiría como dañino a su aplicación), o que el tiempo de descifrado por secreto está por debajo de su objetivo en cuanto a la sensibilidad de la información que protege y los recursos de su atacante percibido.

Si es aceptable que cada número de teléfono demore 39 horas en ser descifrado por un atacante ocasional, entonces no hay problema con bcrypt a un costo de 13. Esto es asumiendo que están usando bcrypt con dicho costo y no simplemente almacenando SHA1 (número de sal +).