Cuando se usan AES y CBC, ¿puede el IV ser un hash del texto plano?

Un hash computado sobre el texto simple tendría las características correctas para una IV, en lo que se refiere a la "aleatoriedad uniforme". Esto es para una función hash criptográficamente segura , no un CRC. Más bien, algo como SHA-256. Un CRC no es de ninguna manera lo suficientemente seguro para la criptografía.

Sin embargo , el IV debe ser conocido por quien descifre, por lo que debe almacenarse a lo largo del mensaje cifrado. Si la IV se calcula con una función de hash del texto sin formato, esto permite realizar un ataque de diccionario en el texto sin formato (intente con el posible texto sin formato hasta que se encuentre uno que coincida con el hash). Derrotar los ataques de diccionario ya es bastante difícil para las contraseñas, que están destinadas a ser seguras y de apariencia aleatoria; por lo tanto, para algo tan completamente no aleatorio como un nombre de visualización, realmente debería usar un IV generado a partir de un generador de números aleatorios criptográficos adecuadamente seguro, no un hash calculado a partir del texto simple. No cambiará sus costos de almacenamiento, ya que el IV debe almacenarse de todas formas, independientemente de cómo lo genere.

Respuesta corta: IV debe ser aleatorio y enviado en claro.

Debe tener cuidado de no filtrar información sobre el texto sin formato en su hash. no debe ser posible llegar al texto sin formato con una tabla de arco iris de su hash. Por lo tanto, un valor de sal, almacenado en un archivo de configuración, no en la base de datos, está en orden.

Dicho esto, sugiero esto:

• Usa un IV aleatorio, almacenado como lo haces ahora
• almacene un hash con sal de los datos de texto sin formato en otra columna
• busque el hash salado para recuperar el IV aleatorio y el texto cifrado

Entonces en tu ejemplo, tendrías esto:

NC_DISPLAY_NAME                                            | ENC_TABLE_NAME
-----------------------------------------------------------+------------------
hash(salt+"Darren's projects"), [IV5]{Darren's projects}   | [IV6]{TABLE_2823}

Por supuesto, el hachís salado no está exento de riesgos. Es más bajo de lo que intentabas evitar, pero todavía está presente. Si ese riesgo es demasiado alto, puede cifrar el hash de texto sin formato (con otra clave AES) en el modo ECB y buscarlo. Así tu mesa se verá así:

NC_DISPLAY_NAME                                               | ENC_TABLE_NAME
--------------------------------------------------------------+------------------
{k1 hash("Darren's projects")}, [IV5]{k2 Darren's projects}   | [IV6]{TABLE_2823}

Hacer el hash te da la entropía (blanqueo de entrada) equivalente a usar un IV (pero no tengo el poder matemático para confirmarlo). El cifrado le brinda protección contra las tablas y diccionarios de arco iris.

Sabes que tendrás una compensación de seguridad de velocidad cuando forzar brutalmente tu índice de búsqueda llevará más tiempo que la fuerza bruta del texto cifrado aleatorio IV.

Si va a poner el hash del contenido allí mismo, entonces se dará cuenta de que su cifrado solo le dará otra copia de los datos. Si todo lo que está usando es una búsqueda, entonces todo lo que necesita es el hash (salvo colisiones, de todos modos). Por lo tanto, cualquier atacante que busque una fila específica basada en su nombre puede encontrarla sin saber la clave simplemente ignorando la parte cifrada de los datos y buscando el hash de lo que está buscando.

Ahora, si el resumen que está utilizando es un HMAC, y no solo CRC o un hash, podría estar bien. Pero tenga en cuenta que debe tener cuidado de no divulgar información adicional con él.