¿Cuáles son los inconvenientes de usar un enfoque de estiramiento de claves trivialmente sencillo, como el ejemplo de Python a continuación, en comparación con algo como PBKDF2? El propósito es endurecer un archivo encriptado AES contra el uso de fuerza bruta.
¿Hay algún problema crítico con la forma trivial? No hay implementación de PBKDF2 disponible en el lenguaje con el que estoy programando.
for _ in range (100000):
key = hashlib.sha256(key).hexdigest()
El argumento de seguridad para PBKDF2 es mejor que para su propuesta. Esto no significa que su propuesta sea menos segura, solo que PBKDF2 es más fácil de justificar.
Esto se debe a que PBKDF2 incorpora tres ideas adicionales más allá de su propuesta de iteración. Primero, PBKDF2 incorpora explícitamente una sal, mientras que su ejemplo no lo hace. Incluso si asumiera implícitamente que key sería algo así como salt + password , un codificador de contraseñas realmente debería tomar la contraseña y la sal como argumentos separados.
En segundo lugar, PBKDF2 no itera una función hash pública como SHA-256, sino una función pseudorandom ("PRF") como HMAC-SHA-256, con la contraseña. Este es un punto teórico muy sutil, pero lo que esto significa es que PBKDF puede trabajar con funciones que son más débiles que una función hash en toda regla como SHA-256.
Tercero, PBKDF2 no solo encadena las salidas de la PRF, sino que también XORs sus salidas. Esta es una salvaguardia (quizás paranoica) contra PRF débiles que tienen ciclos cortos cuando se aplican a sus propios resultados.
PBKDF2 es en realidad bastante simple. Es bastante simple que es poco probable que los laicos puedan estropearlo. Si su idioma y biblioteca tienen SHA-256, es probable que también tengan HMAC-SHA-256, pero si no es así, también es fácil de implementar. Por lo tanto, realmente debería simplemente darle una oportunidad: es mejor atenerse a las técnicas estándar y bien probadas que a preparar las suyas.
Nota final: la salida de una función hash es datos binarios , y realmente debería tratarse como tal. Es decir, su uso de hexdigest en su ejemplo es inútil y no conduce a un código de buena calidad; Los datos deben ser procesados en su tipo nativo tanto como sea posible! (El uso de resúmenes hexadecimales también le daría una implementación PBKDF2 incorrecta).
De wikipedia: Estiramiento de las teclas :
... se utilizan para hacer que una clave posiblemente débil ... sea más segura contra un ataque de fuerza bruta al aumentar el tiempo que lleva probar cada clave posible
Debido a que los hashes como SHA-2 están diseñados para el estiramiento de la tecla simple de velocidad usando solo el hash, realmente no se ralentiza a un atacante que trata de forzar una fuerza bruta con una tecla basada en la entrada débil. Los KDF como PBKDF2 están diseñados para realmente ralentizar al atacante al ser ellos mismos lentos.
Si bien su ejemplo hace muchas iteraciones para ralentizar el cálculo, un atacante podría crear una vez una base de datos de todas las entradas débiles interesantes y sus salidas y utilizar estos valores precomputados más adelante en múltiples ataques de fuerza bruta en lugar de volver a calcular todos los valores en ese momento de ataque. Es por eso que los algoritmos como PBKDF2 usan adicionalmente un salt para aumentar enormemente la memoria Esta base de datos lo necesita y el tiempo para crearlo y, por lo tanto, hacerlo poco práctico.
No hay implementación de PBKDF2 disponible en el lenguaje con el que estoy programando.
Si el lenguaje ya ofrece una forma de calcular un hash y está dispuesto a crear algún KDF de todos modos, entonces implemente PBKDF2 u otro KDF bien diseñado. En lugar de tu propia idea no debería ser demasiado difícil.
Lea otras preguntas en las etiquetas brute-force key-stretching