¿Alguna razón para usar bcrypt, pbkdf2, scrpt para otras cosas que no sean contraseñas? [cerrado]

0

Digamos que quiero hacer un hash de algunos datos, usando SHA256, para probar que sé algo. Tal vez sea mi identificación secreta para algo.

En el real de las contraseñas que hemos movido del hashing - > hash + sal - > problemas difíciles de la CPU - > cpu + problemas difíciles de memoria. Sin embargo, la razón principal por la que hicimos todo esto es porque las contraseñas son (en el mundo real) muy bajas en entropía, ya que las personas usan "123456" como contraseña. Dado que los sitios web son pirateados todo el tiempo, hemos empezado a tratar de proteger estas contraseñas de baja entropía para que no sean crackeadas por la fuerza bruta.

Sin embargo, hay muchos otros casos en los que la entrada no es tan "mala". Digamos que, en cambio, quiero copiar mi ID secreta de sincronización de bittorrent, mi ID de billetera de bitcoin o cualquier otro tipo de identificación secreta. ¿No es suficiente una sola ronda de SHA256 aquí y en el futuro previsible? Incluso con la NSA construyendo el grupo de ASIC más grande del mundo para el SHA256 de fuerza bruta.

He visto gente que usa algoritmos como bcrypt / scrypt en muchos otros contextos que contraseñas, y por supuesto no me duele, pero ¿hay alguna razón por la que un solo hash de SHA no sea lo suficientemente bueno? (Suponiendo que sé que mi entrada tiene suficiente entropía)

    
pregunta Markus 07.02.2014 - 16:29
fuente

2 respuestas

2

Las contraseña -hashing funciones (y funciones de derivación de clave basadas en contraseña, en el caso de PBKDF2) están diseñadas para hacer frente a la baja entropía de las contraseñas: comienzan desde una mala situación (secreto inicial) es vulnerable a una búsqueda exhaustiva práctica) y aplique sales y lentitud (para evitar ataques paralelos / precomputación, y para hacer más lenta la búsqueda exhaustiva) de modo que esta maldad pueda ser tolerada en cierta medida.

Si su secreto inicial tiene suficiente entropía para soportar la búsqueda exhaustiva, entonces no es necesario usar una función de hashing de contraseña. Si tiene una clave secreta de 256 bits que se generó correctamente , a continuación, codifique o escríbase o Lo que no hará ningún bien adicional. Por otro lado, si su secreto inicial tiene una baja entropía, incluso si no es una "contraseña" per se (por ejemplo, algún valor derivado de la biométrica, suponiendo que pueda encontrar una que sea algo secreta y puede ser convertido de manera confiable en un valor que no se moverá demasiado para un individuo determinado), entonces las funciones de "contraseña" -hashing serán una herramienta adecuada.

La funcionalidad principal de las funciones de procesamiento de contraseñas como bcrypt es convertir un valor de entrada de baja entropía en un formato no regular en un buen valor de hash (para verificación) o clave simétrica (para criptografía simétrica) de una manera que mejore Resistencia práctica a la búsqueda exhaustiva (lo cual es factible debido a la baja entropía). Las "contraseñas" son solo un caso muy común de "secreto de baja entropía con un formato no regular".

    
respondido por el Thomas Pornin 07.02.2014 - 17:38
fuente
0

Digamos que quiero hacer un hash de algunos datos, usando SHA256, para probar que sé algo. ... Sin embargo, hay muchos otros casos en los que la entrada no es tan "mala".

Haga las siguientes preguntas, pero responda en el peor de los casos (desde su punto de vista) que existirá entre ahora y cuando en el futuro usted predice que ya no le importará en absoluto que un atacante encuentre y / o publique lo que te estas escondiendo En su caso, "lo que está escondiendo" puede ser su ID de billetera de bitcoin, etc .:

¿Cuál es el valor de un atacante al descubrir qué estás escondiendo?

¿Cuál es el espacio de teclas más grande que un atacante tendría que buscar para adivinar lo que estás escondiendo? Es decir. ataque de fuerza bruta.

¿Cuál es el espacio de teclas más pequeño que un atacante tendría que buscar para adivinar lo que estás ocultando? Es decir. Ataques de diccionario basados en reglas, debilidades en sus algoritmos de hash, no todos los bits son aleatorios, debilidades en el RNG que ayudaron con lo que está escondiendo, debilidades en otros algoritmos, etc.

¿El PBKDF2 (o HMAC, que incluye) aumenta el espacio de teclas más pequeño? ¿Scrypt? Bcrypt?

¿Cuáles son las posibilidades de que se descubra un defecto que no conoces ahora?

¿A qué velocidad podría un atacante mal financiado buscar en dichos espacios clave (suponiendo $ 5kish, por lo que quizás 8 GPU de gama alta o 10 CPU muy buenas - un adolescente con padres ricos, un aficionado, un miembro de StackExchange). ¿Un atacante moderadamente financiado? ¿Un atacante bien financiado? ¿Un megacorp o gobierno?

¿Qué nivel de atacante te interesa?

¿Cuánto tiempo extra de CPU / miembro para una de estas técnicas podría gastar sin incomodarlo en absoluto? ¿Te molesta solo un poco? ¿Te convence moderadamente? ¿Te molesta mucho?

¿Cuál es la posibilidad de que la técnica que elija ayude a un atacante en comparación con la técnica que estaba considerando antes? Por ejemplo, PBKDF2-HMAC-SHA-256 no es peor que SHA-256, ya que comparten el mismo hash de base, pero el primero tiene una protección considerablemente mayor contra ciertos tipos de ataques.

Tome estas respuestas y aplíquelas a un análisis de riesgo-costo. Ve con tu respuesta.

Por mi parte, utilizaría como mínimo, sin embargo, muchas rondas de cualquiera de las tres que me gustan no me molestan en absoluto, y probablemente más. Tiendo a pensar que 4-8 segundos de espera no son un problema cuando Yo, un humano, estoy buscando información secreta. Escale las iteraciones a lo largo del tiempo como mejor le parezca.

    
respondido por el Anti-weakpasswords 07.02.2014 - 17:09
fuente

Lea otras preguntas en las etiquetas