La forma correcta de generar un IV para el modo CBC es con un generador aleatorio criptográficamente seguro. Hay casos en los que un IV no aleatorio está bien, pero a menos que haya analizado cuidadosamente su sistema para asegurarse de que se encuentra en estos casos, debe ir con un IV aleatorio. Hay muy pocas situaciones en las que el uso de un IV no aleatorio tendría algún beneficio de todos modos, así que vaya con un IV aleatorio.
No estoy familiarizado con la API de C #, pero dado que documentación de GenerateIV afirma que" genera un vector de inicialización aleatorio (IV) para usar para el algoritmo ", parece ser una forma válida de generar un IV para CBC (pero CreateEncryptor ya realiza el mismo trabajo).
Tomar el hash de estos bytes aleatorios es estrictamente hablando un riesgo, porque reduce la entropía de la IV: no se sabe que los hashes criptográficos sean supuestos. (Supongo que te refieres a un hash criptográfico como SHA-256; un hash no criptográfico definitivamente sería problemático). Sin embargo, no creo que haya ningún problema concreto con eso: en la práctica, creo que es inofensivo. p>
La adición de algunos bytes aleatorios y el hashing repetidamente debería ser igualmente seguro. Sin embargo, es una complejidad innecesaria. La complejidad innecesaria debe activar las alarmas en cualquier contexto de seguridad. Esto aumenta el riesgo de un error de implementación, como filtrar datos confidenciales (aunque no es un gran problema, ya que la IV no tiene que ser confidencial, pero sería una consideración definitiva si estuviera generando una clave), sobrescribiendo los datos debido a un desbordamiento del búfer o un cálculo de puntero incorrecto, el recuento de iteraciones es 0 cuando se necesita al menos una iteración, etc.
El segundo método que propones definitivamente no es seguro sin el paso adicional de hashing-with-random. Las direcciones MAC y el tiempo son predecibles, y CBC requiere un IV impredecible . Los ataques contra CBC con un IV predecible no se aplican a todos los sistemas (confían en que el adversario pueda enviar mensajes para cifrar), pero ¿por qué arriesgarse? Además, las direcciones MAC y el tiempo no son necesariamente únicos: piense en máquinas virtuales clonadas, programas multiproceso, proceso rápido que sirve a dos clientes en el mismo reloj, etc.
Con el paso de hashing-with-random adicional, comenzar desde la dirección MAC y el tiempo no debe distinguirse de la aleatoria, siempre que se inyecten suficientes datos aleatorios. Pero volvemos al problema de la complejidad: ¿qué tan seguro está de que lo está haciendo bien?
Si la razón de esta complejidad adicional es "hacerlo más aleatorio" ... el azar no funciona de esa manera. No puedes hacer que el azar sea más aleatorio simplemente jugando con él, existe un grave riesgo de que lo arruines y lo hagas menos aleatorio.
Hacer algo más que tomar un IV al azar (por ejemplo, con GenerateIV ) aumenta el costo de mantenimiento (comenzando con el tiempo que dedica a preocuparse), reduce el rendimiento y aumenta el riesgo. Así que solo usa un IV aleatorio.
Si la implementación de una versión actualizada del código es costosa, este no es un problema crítico. (Si el IV fue solo el tiempo de MAC +, puede ser crítico o no, dependiendo del sistema en general). Pero debe fijarse en el código base y desplegarse con la próxima versión normal.