Aclaración sobre IV en PBKDF2 para generar clave de cifrado

La sal está aquí para evitar que los atacantes compartan los costos. Si dos contraseñas tienen un hash con el mismo valor de sal, entonces un atacante podría hacer una contraseña potencial utilizando ese valor de sal y comparar la salida con las versiones de hash de las dos contraseñas; en otras palabras, el atacante puede atacar las dos contraseñas con hash por el costo de atacar una. Esto se amplía: si hay 1000 contraseñas con hash, todas con la misma sal, entonces el atacante obtiene 999 de ellas "gratis".

Este tipo de costo compartido puede tomar varias formas, una de ellas son tablas precalculadas (y una clase específica de tabla se llama "tabla arco iris"). En general, el costo compartido es una instancia de paralelismo (con la distorsión adecuada de espacio-tiempo).

Debe esforzarse por reutilizar los valores de sal tan raramente como sea posible; si es posible, nunca. En su caso, almacenaría la sal junto con el archivo cifrado; y cada archivo tendría su propio valor de sal (incluso si dos archivos usan la misma contraseña, cada uno debería tener su propio valor de sal).

Si cada archivo tiene su propio valor de sal, puede hacer lo siguiente para la IV:

• Seleccione un IV aleatorio y agréguelo al encabezado del archivo (junto con el salt).
• Use PBKDF2 para generar la clave y la IV de una sola vez (por ejemplo, solicite 256 bits de salida, 128 para la clave y 128 para la IV).
• Use un IV fijo.

La segunda y tercera opción son seguras solo si realmente está generando un nuevo salt para cada archivo, en un espacio lo suficientemente grande como para que no ocurran colisiones en la práctica. De lo contrario, puede terminar con la reutilización IV, que es un pecado. Específicamente, lo que es realmente malo ^TM está utilizando dos veces el mismo IV con la misma clave . Si cada archivo tiene su propia clave (porque la clave proviene del procesamiento de la contraseña con el salt y cada archivo tiene su propio salt), entonces un IV fijo está bien.

De todos modos, si necesita cifrado, es probable que también necesite verificar su integridad, lo que requiere un MAC . Ensamblar el cifrado y un MAC correctamente es complicado . La forma correcta es utilizar un modo de cifrado que ya haga el trabajo de una manera que haga felices a los criptógrafos. En la práctica, use 'aes-192-gcm' , no 'aes-192-cbc' (o 'aes-128-gcm' : 128 bits ya son suficientemente buenos, y será un poco más rápido).

Tenga en cuenta que la longitud IV real para GCM es de 12 bytes.

El propósito principal de la sal es proteger contra los ataques de la mesa del arco iris. Hay diferentes escenarios:

1. Si no usa sales, un atacante ya podría tener una tabla arco iris lista para comenzar a atacar sus contraseñas.
2. Si usa la misma sal para cada entrada, el atacante tendría que generar una nueva tabla de arco iris basada en su sal, que luego podría usar para atacar sus contraseñas.
3. Si usa sales diferentes para cada contraseña, un atacante tendría que generar una tabla arco iris por cada contraseña que quiera descifrar, lo que no es factible.

Por lo tanto, se recomienda usar siempre un salt diferente para cada contraseña.

Por lo general, la sal no se considera un recurso secreto y, por lo tanto, se puede guardar sin cifrar en la base de datos. Su único propósito es hacer que el uso de Rainbow Tables no sea factible. No soy un experto en IV, pero hasta donde sé, los IV deben ser secretos, y probablemente no sea una buena idea si los IV se almacenan en la base de datos sin cifrar. Por lo tanto, no recomendaría usar el IV como la sal.