Il modo giusto per generare un IV per la modalità CBC è con un generatore casuale protetto crittograficamente. Ci sono casi in cui una IV non casuale è ok, ma se non hai analizzato attentamente il tuo sistema per essere sicuro di cadere in questi casi, dovresti andare con un IV casuale. Ci sono pochissime situazioni in cui l'utilizzo di un IV non casuale avrebbe comunque alcun vantaggio, quindi vai con un IV casuale.
Non ho familiarità con l'API C #, ma dato che documentazione di GenerateIV afferma che" genera un vettore di inizializzazione casuale (IV) da utilizzare per l'algoritmo ", sembra essere un modo valido per generare un IV per CBC (ma CreateEncryptor fa già lo stesso lavoro).
Prendere l'hash di questi byte casuali è strettamente un rischio, perché riduce l'entropia della IV: gli hash crittografici non sono noti per essere suriettivi. (Immagino tu intenda un hash crittografico come SHA-256, un hash non crittografico sarebbe sicuramente problematico.) Tuttavia, non penso che ci sia alcun problema concreto: in pratica, penso che sia innocuo.
Aggiungere ancora alcuni byte casuali e ripetere l'hashing ripetutamente dovrebbe essere ugualmente sicuro. Tuttavia, è la complessità inutile. La complessità inutile dovrebbe sollevare campanelli d'allarme in qualsiasi contesto di sicurezza. Ciò aumenta il rischio di un bug di implementazione, come la perdita di dati riservati (non è una grande preoccupazione qui, dato che l'IV non ha bisogno di essere riservato, ma sarebbe una considerazione definitiva se si stesse generando una chiave), sovrascrivendo i dati a causa di un overflow del buffer o di un calcolo errato del puntatore, ottenendo il conteggio iterativo a 0 quando è necessaria almeno un'iterazione, ecc.
Il secondo metodo che proponi non è sicuramente sicuro senza il passaggio hashing-a-random in più. Gli indirizzi MAC e il tempo sono prevedibili e CBC richiede una IV imprevedibile . Gli attacchi contro CBC con una IV prevedibile non si applicano a tutti i sistemi (si basano sull'avversario che è in grado di inviare messaggi per la crittografia), ma perché correre un rischio? Inoltre, gli indirizzi MAC e il tempo non sono necessariamente unici: pensa a macchine virtuali clonate, programmi multithread, processi veloci che servono due client nello stesso tick del clock, ecc.
Con la fase aggiuntiva di hashing-a-random, a partire dall'indirizzo MAC e il tempo dovrebbe essere indistinguibile da casuale, a condizione che vengano iniettati abbastanza dati casuali. Ma siamo tornati al problema della complessità: quanto sei sicuro di aver capito bene?
Se il motivo di questa complessità extra è "renderlo più casuale" ... random non funziona in questo modo. Non puoi rendere casuali più casuali semplicemente scherzando, c'è il serio rischio che tu possa rovinare tutto e renderlo meno casuale.
Fare qualcosa di diverso dal prendere una IV casuale (ad esempio con GenerateIV ) aumenta i costi di manutenzione (a partire dal momento in cui stai spendendo ora a preoccuparti), riduce le prestazioni e aumenta i rischi. Quindi usa solo un IV casuale.
Se la distribuzione di una versione aggiornata del codice è costosa, questo non è un problema critico. (Se l'IV era solo il tempo MAC +, potrebbe essere o meno critico a seconda del sistema generale.) Ma dovrebbe essere corretto nel codice di base e implementato con il successivo rilascio normale.