¿Se necesitan hashing de sales y contraseñas para las claves aleatorias?

Pareces estar mezclando diferentes casos de uso aquí. Un caso de uso es obtener una clave de cifrado de un secreto. El otro es almacenar datos de inicio de sesión.

Si necesita obtener una clave de cifrado de bits n para un cifrado simétrico, como sugiere su ejemplo AES, lo mejor que puede esperar son los bits n o la entropía. Si tiene una verdadera fuente aleatoria y la utiliza para generar todos los bits n de forma independiente, esa es la máxima entropía posible. El mejor uso de los datos no reducirá la entropía.

Si su entrada es una frase de paso proporcionada por el usuario, una función de derivación de claves debe usarse para condensar la entropía de la cadena de longitud arbitraria en el número de bits esperado por el cifrado. Una función hash simple se puede usar como una función de derivación de claves, pero no será muy segura. Las frases de paso del usuario a menudo tienen una entropía muy pobre. El objetivo es hacer que la evaluación de la función de derivación de claves sea tan costosa que atacar la frase de contraseña no sea más eficiente que forzar directamente los bits de clave. Sin embargo, en su caso, la función de identidad ya proporciona esta propiedad.

Un caso de uso diferente es el almacenamiento de datos de inicio de sesión en una base de datos. En este caso, el hashing y el salado no se utilizan para "hacer que las contraseñas sean más seguras", sino para que sea difícil adivinar la contraseña real, incluso en el caso de que el atacante se apodere de la base de datos. Si la base de datos contiene las contraseñas en texto sin formato, no importa cuán larga y aleatoria sea la contraseña. El atacante siempre puede leerlo directamente.

Deberías tomar en serio el siguiente lema: las contraseñas y las claves criptográficas no son lo mismo . Algunos contrastes:

• Las contraseñas son elegidas por los seres humanos con sus cerebros, pero las claves se generan aleatoriamente con un generador seguro.
• Las contraseñas son alfanuméricas, pero las claves son binarias.
• Las contraseñas son de longitud variable, y los humanos eligen la longitud de forma individual. Pero las claves son de longitud fija, y el sistema elige las longitudes.
• Las contraseñas son fáciles de recordar, pero las claves no deben ser así, y en su lugar se almacenan de forma segura.
• Las contraseñas son un factor "algo que sabes", pero las claves son un factor "algo que tienes".

  

¿Pero realmente se necesitan sales y hashes si tiene una clave verdaderamente aleatoria y no una contraseña ingresada por un usuario? Por ejemplo, supongamos que la contraseña es una cadena "ridículamente" de caracteres imprimibles aleatorios (o, mejor aún, simplemente binarios), por ejemplo, 256 bytes aleatorios para un cifrado AES256.

La respuesta breve a tu pregunta es que las claves no necesitan el hashing de contraseñas, pero el problema aquí es que estás hablando de contraseñas y claves como si fueran intercambiables, y eso es una bandera roja. Si su programa de encriptación le permite al usuario escribir las contraseñas alfanuméricas de longitud variable de su elección, entonces ese programa realmente necesita aplicar una función de derivación de clave de uso intensivo de recursos a la contraseña elegida por el usuario. Si el usuario eligiera una contraseña realmente segura, no sería necesario hacer ese hashing lento, pero un programa de cifrado basado en contraseña debe asumir que la contraseña es débil.

A la inversa, si el programa está diseñado para usar claves criptográficas sólidas, entonces no debería permitir que el usuario los elija con su cerebro o los ingrese con la mano. Debería soportar estas opciones:

1. Genere una clave segura y escríbala en un archivo.
2. Use una clave almacenada dentro de dicho archivo.
3. Utilice tarjetas inteligentes criptográficas en lugar de archivos.