Mantener clave sensible entre solicitudes

La respuesta breve a su pregunta es que no saber la IV hace que AES, o en realidad cualquier cifrado de bloque en un modo de operación adecuado, sea mucho más imposible de fuerza bruta, básicamente haciendo que la IV sea una extensión de la clave. Para AES-256, la clave de 256 bits más una IV de 128 bits básicamente requiere que su atacante adivine correctamente una secuencia de 384 bits, lo que requiere un intento de 2 ^ 384 en el peor de los casos. Poniéndolo en perspectiva, una computadora que funcione a nivel de electrones con una eficiencia térmica del 100%, dado que cada fotón que producirá nuestro Sol en su vida útil restante, solo podría probar aproximadamente 2 ^ 218 teclas antes de que el Sol se vuelva enano negro. p>

Sin embargo, ambos lados necesitan el IV para cifrar / descifrar en cualquier modo que use uno, y así, al igual que otros detalles específicos sobre el esquema de cifrado, excepto la clave real que se compartiría entre las partes durante la negociación (como algoritmo, modo, tamaño de bloque, tamaño de clave) el IV se considera información pública. Es posible ocultarlo, de la misma manera que la clave se puede intercambiar de forma segura (fuera de línea, criptografía de clave pública), pero no es necesario.

Con esa pregunta respondida, debo decir que hay mucha información que no ha proporcionado, que hace imposible responder a la pregunta más amplia de "es seguro este esquema". Por ejemplo, ¿cómo se relaciona la contraseña del usuario con la clave (está utilizando un KDF u otro esquema de "extensión de clave")? ¿Qué modo de operación está utilizando para el cifrado AES (algunos modos son más seguros que otros y otros) se rompen efectivamente). EDITAR: el modo CBC no es una opción terrible (hay peores) pero se debe tener cuidado para garantizar que su código no se pueda usar como un "oráculo de relleno"; una "caja negra" que le dirá a un atacante si un mensaje de texto cifrado en particular, cuando se descifra, se rellena correctamente. Se puede usar para aplicar ingeniería inversa al mensaje de texto simple del texto cifrado conocido sin conocer la clave. Dado que este es únicamente un proceso del lado del servidor y, por lo tanto, no hay un código de cliente disponible para descifrar, un atacante tendría que penetrar bastante para poder convertir su código de servidor en un oráculo de relleno, pero nunca asumirá; si tiene una buena implementación disponible, elegiría un modo autenticado, como GCM o CCM, que resistirá los ataques de padding-oracle.

También diré que este esquema parece ser solo del lado del servidor; Si la clave y el IV se almacenan solo en el servidor, entonces todo el cifrado y descifrado debe ocurrir allí, lo que significaría que, a menos que esté utilizando otra cosa como SSL para enviar datos al cliente, la seguridad de esta pieza en particular es bastante discutible.

Sí, el IV configura el estado inicial de la secuencia que se utiliza para generar el texto cifrado. Sin el IV, obtendrías un flujo diferente y el descifrado fallaría. Dependiendo del modo de operación, la falla podría fallar. No estoy seguro, sin embargo, por qué preguntas por romperlo sin la IV. Parece que estás hablando de descifrado. Si bien la IV es necesaria, no es un secreto. Está bien que la IV sea conocida, solo evita ataques comparando mensajes similares encriptados con la misma clave. La clave es todo lo que necesita para permanecer en secreto.

Si la clave está comprometida, hay ataques que debilitan enormemente el cifrado en la mayoría de los modos de operación. Si bien el IV es secreto aumenta ligeramente la seguridad, revelarlo no es catastrófico para la seguridad del cifrado. Sin embargo, el secreto de la clave es primordial, ya que el secreto de la IV probablemente no protegerá un mensaje si se conoce la clave.

La mayoría de las inquietudes sobre el secuestro de sesiones y otras son válidas, pero no comprometen de inmediato los datos en el servidor. Mi recomendación sería cifrar la clave de usuario después de que se haya obtenido inicialmente con otra clave de sesión única, dividir la clave en tres partes (o cifrarla con 3 claves de sesión diferentes) y luego colocar una parte de la IV (o la correspondiente IV) y una parte de la clave (o 1 de las 3 claves) en cada uno de los 3 lugares como el token. Luego, cuando se proporcionan las tres piezas de información, la clave real se puede descifrar, pero cualquier pieza comprometida no tendría ningún beneficio fuera de la sesión y la clave de descifrado real solo estaría disponible para el servidor después de las 3 piezas de la clave de sesión Se proporcionan como una alternativa a la contraseña.

El uso de 3 claves de sesión separadas proporcionará más seguridad, pero también requiere más capacidad de procesamiento. Sin embargo, una simple división todavía proporcionará alguna protección adicional dependiendo del modo de operación del cifrado y es más económico de hacer.

Lo principal es que nunca desea revelar la clave de descifrado real o cualquier información sobre la clave de descifrado de datos al atacante (o cliente) y no quiere que esté en la base de datos (en reposo) sin protección. Eso significa que necesita almacenar la clave de datos de manera que esté protegida por la información que solo el cliente conoce y dividir la información en tres partes para comprometerla aumenta la dificultad ligeramente.