¿Puede ser igual la sal IV +?

6

Durante mi aplicación de cifrado tengo el bit de creación de contraseña:

PBEKeySpec spec = new PBEKeySpec(password.toCharArray(), salt, 10000, keyLength);

y más adelante en la parte de cifrado real:

cipher.init(Cipher.ENCRYPT_MODE, secret, ivSpec);

El vector de inicialización necesita bytes aleatorios, la sal necesita bytes aleatorios, ¿puedo usar los mismos bytes aleatorios (criptográficamente seguros) para la sal y la IV o eso debilitaría el cifrado de alguna manera? - Haría un poco más fácil el almacenamiento si pudiera.

No estoy hablando de reutilizar el IV o el sal en múltiples mensajes, para cada mensaje separado se generaría una nueva matriz de bytes, pero podría duplicar cada mensaje individual y usar los mismos bytes recién generados para ambos mensajes. la sal + la IV?

EG:

Mensaje 1: bytes aleatorios = h6ds .... Salt = h6ds / IV = h6ds

Mensaje 2: bytes aleatorios = djs9 .... Salt = djs9 / IV = djs9

Mensaje 3: bytes aleatorios = 9sdf .... Salt = 9sdf / IV = 9sdf

... y así sucesivamente

    
pregunta Crizly 27.10.2014 - 22:32
fuente

2 respuestas

10

El IV debe ser único para cada mensaje cifrado, de modo que no, si tiene la intención de cifrar más de un secreto utilizando la clave que genera con esta contraseña, no puede reutilizar el salt como el IV. Reutilizar una IV en el mejor de los casos filtra información sobre el texto plano, y en el peor, puede destruir su esquema de cifrado por completo (según el modo que esté usando) y, por lo tanto, en cualquier caso, si se reutiliza, debilitará el cifrado.

Sin embargo, si no lo está reutilizando, y solo se usará una sola vez, entonces no, el hecho de que el mismo valor aleatorio sirva como una sal en otro lugar no debería tener ningún efecto sobre La fuerza del cifrado en absoluto.

Editado para agregar: hay una advertencia que no creo que se aplique en este caso específico, pero debería mencionar. Dado que está utilizando un KDF para generar la clave, la sal constituye una parte de la fuerza de la clave. Si la IV está siendo expuesta al atacante (dada la redacción de la pregunta, no creo que ese sea el caso aquí), usted facilita considerablemente el trabajo del atacante cuando se trata de poder calcular las claves candidatas y las claves generadas a partir de Las contraseñas débiles se vuelven susceptibles a los ataques de diccionario. Sin embargo, si la sal / IV simplemente se almacena, y se puede considerar razonablemente que el compromiso de uno compromete a ambos, entonces la premisa inicial de que la fuerza no se efectúa todavía se mantiene.

    
respondido por el Xander 27.10.2014 - 22:55
fuente
2

El uso de la sal para PBKDF2 como IV para una ejecución de encriptación que usa la clave obtenida de PBKDF2 se basa en el funcionamiento de PBKDF2 como un oráculo aleatorio, lo que "aísla" los dos usos entre sí, evitando que ocurran malas interacciones. Esta no es una propiedad muy estudiada, pero es plausible, dado que PBKDF2 es una gran cantidad de llamadas anidadas a HMAC, y HMAC es el candidato habitual para un oráculo aleatorio.

Sin embargo, es más fácil analizar otro diseño: simplemente haga que el KDF produzca suficientes bytes para la clave y la IV. Es decir, a partir de la sal y la contraseña, genere 32 bytes: 16 bytes para la clave de encriptación, y otros 16 bytes para la IV. De esa manera, mantendrá la factura de almacenamiento al mismo nivel (solo una sal, sin espacio adicional para la IV) y se vuelve algo obvio que no está haciendo negocios extravagantes con su IV. Como beneficio adicional, si cambia el KDF a otro con requisitos estrictos en cuanto al valor y tamaño de sal, aún puede obtener un IV de la longitud adecuada para su cifrado.

Se aplican las advertencias habituales:

  • PBKDF2 no es una muy buena función de derivación de clave basada en contraseña. En particular, su tiempo de ejecución aumenta proporcionalmente al tamaño de salida (con umbrales), lo que significa que obtener más de 20 bytes fuera de PBKDF2 puede obligarle a reducir a la mitad el número de iteraciones, lo que es perjudicial para la seguridad. Además, PBKDF2 es fácil de optimizar en una GPU. Bcrypt sería una mejor opción ; para la parte de "longitud de salida arbitraria", combine la función de hashing de contraseña con un KDF bueno (rápido) como HKDF .

  • Cuando realice el cifrado, probablemente también necesite un MAC . Esto puede ser un asunto complicado.

respondido por el Thomas Pornin 28.10.2014 - 00:22
fuente

Lea otras preguntas en las etiquetas