Estoy generando una clave a partir de una contraseña para cifrar los datos con AES256. Dado que el hash generado no se almacena, ¿necesitaría usar una sal? Si utilizo un archivo Salt y se hace público, ¿mis datos cifrados son menos seguros?
No veo la necesidad de protegerme contra los ataques de arco iris ya que el hash generado nunca se guarda, sino que se usa solo como una clave de cifrado y no hay un depósito central para los datos cifrados.
Respuesta actualizada basada en nueva información:
Los humanos no son muy creativos cuando se trata de contraseñas. Esto hace que estas contraseñas sean una mala elección como semillas para generar claves de cifrado (que deberían tener una alta entropía). Cotización de un estudio :
Burnett hizo un análisis de 6 millones de combinaciones de nombre de usuario y contraseña el año pasado, y descubrió que el 91 por ciento de los usuarios había usado una de las 1,000 contraseñas más comunes, con el 99.8 por ciento usando una contraseña de las 10,000 más comunes. Y la "contraseña" fue el líder de todos ellos, en uso por el 4.7 por ciento de las cuentas de usuario.
Dadas las estadísticas anteriores, es probable que esté tratando con un subconjunto muy minúsculo de claves de cifrado totales posibles (¡un par de miles o millones!). Una clave AES de 256 bits tiene un espacio de dirección de 2 ^ 256. En tal caso, debería preocuparse por los ataques del diccionario.
Considere una función PBKD siguiente:
ElPBKDFanteriorutilizaciteracionesdeunafunciónhashHsobrelacombinación(contraseña||sal)
También,considereundiccionariodecontraseñasdecontraseñasde1Myquenuestraaplicacióntiene100usuarios
Sinsal
Cuandonohaysalporusuario,lafunciónPBKDFanteriorsereducea:
Todo lo que el atacante debe hacer es calcular un diccionario de claves AES de 1M correspondientes a cada contraseña en el diccionario.
The number of times a user needs to run the KDF function = 1M.
Con sal
Ahora que cada usuario tiene un salt, una lista genérica 1M de claves AES no funcionará . Ahora, un atacante deberá realizar operaciones de 1M KDF por usuario para crear un conjunto específico de posibles claves AES para ese usuario específico .
The number of times a user needs to run the KDF function = 100M.
PBKDF, como bcrypt y scrypt, son deliberadamente funciones lentas solo para evitar ataques de diccionario como estos.
Se recomienda usar un salt con funciones PBKDF para asegurarse de que las claves resultantes tengan más entropía y que un atacante necesite calcular un diccionario por usuario para realizar un ataque de fuerza bruta basado en un diccionario. Dado que las funciones PBKDF están diseñadas para ser lentas, la creación de una lista de diccionarios por usuario es una magnitud de orden más lenta que una sola lista.
Las sales serán útiles en el escenario donde dos usuarios diferentes tienen las mismas contraseñas y los mismos datos. Si se usa un cifrado determinista, los textos de cifrado resultantes serán los mismos (ya que las claves de cifrado derivadas utilizando PBKDF serán las mismas), lo que abre los vectores para el análisis de criptoanálisis. Si las contraseñas son saladas, el texto cifrado resultante será diferente en el caso mencionado anteriormente.
Las sales no son un secreto. No tienes que cifrar / esconder las sales. Sin embargo, deben ser únicos para cada usuario.
Además, si no tiene un concepto de usuarios / frases de contraseña, no necesita utilizar PBKDF para generar claves. Como mencionó Lucas, puede usar un generador de números aleatorios seguro para crear claves aleatorias directamente.
PBKDF2 se usa para derivar una clave de una frase de contraseña, si solo está generando claves sin usar una frase de contraseña, también puede usar un generador aleatorio seguro para generar un conjunto de bytes.
Una sal no hace que sus datos sean menos seguros, las sales no se consideran secretas.