No, non crittografare le IV. Devono essere mai, mai riutilizzati, ma questo è più o meno per i requisiti IV per la modalità CTR: non è assolutamente necessario mantenerli riservati. Inoltre, non dovresti decifrare il tuo IV con la chiave usata per crittografare il tuo messaggio - a seconda dello schema di padding, che può benissimo esporre uno dei blocchi del tuo messaggio. In nessun caso migliorerà la sicurezza; anche qualsiasi vulnerabilità in modalità CTR costituirà una vulnerabilità.
Ricorda come funziona la modalità CTR. In modalità CTR, i dati effettivi non vengono mai passati come input al codice di blocco. Invece, concatenate un IV più breve del blocco e un contatore più breve del blocco, criptate quello e XOR con i dati. Un utente malintenzionato che recupera la crittografia di IV||n può recuperare il n-esimo blocco.
Ora non puoi criptare l'IV da solo. In realtà è impossibile: l'IV è sotto-block-length, e AES non è in grado di crittografare tutto ciò che non è un multiplo esatto della lunghezza di un blocco. È necessario riempire il tuo IV per crittografarlo (il motivo per cui CTR normalmente non usa il padding è che non passa i dati ad AES; se lo facessi, avresti bisogno di un padding). Supponiamo che i pad di schema di padding con zeri e quindi assorba la lunghezza del messaggio alla fine (tutti gli schemi di padding comuni devono avere la lunghezza del messaggio mostrata da qualche parte , perché se hai appena completato lo zero allora "john0 "e" john "diventerebbero entrambi" john000 ... 000 "). Per il tuo IV a 64 bit, il padding trasformerebbe IV in IV||0x00...01000000 ; lo cripteresti e lo applicheresti all'inizio del tuo messaggio. Ma la crittografia di ciò è esattamente ciò che XOR con il 64 ° blocco del tuo messaggio. Quindi, crittografando il tuo IV qui, hai rivelato il 64 ° blocco del tuo messaggio, mentre con un IV non crittografato era sicuro.
(incidentalmente: quando la gente dice "non tirare la tua crittografia, è facile commettere errori sottili", questo è un errore così sottile. Se sei nuovo di crittografia, potrebbe sembrare più sicuro crittografare la tua IV Devi riempirlo, quindi potresti scegliere il padding zero apparentemente ragionevole con un tag di lunghezza, in modo che un utente malintenzionato possa leggere un blocco del testo cifrato.
L'unico modo per aggirare questo è di fare in modo che l'IV imbottito mai venga crittografato per generare materiale per le chiavi. Praticamente il modo migliore per ottenere questo è concordare su lunghezza IV o inviare un testo in chiaro di IV lunghezza, criptare tutti gli zeri per il primo blocco e poi non inviare l'IV (dall'altra parte, il primo blocco decrittografato dà IV|0x00...01 , che puoi prendere il primo mazzo di bit per ottenere la IV). Qualsiasi crittografia della IV, se lo schema di padding è "configura questa roba che è k in esadecimale, alla fine della IV", equivale a fare in modo che il blocco k sia costituito da tutti gli zeri. Se lo guardi in questo modo, puoi vedere che quasi tutte le vulnerabilità CTR influenzeranno anche il tuo schema. Le sole vulnerabilità legate all'attaccante che conoscono l'IV, d'altra parte, indicano un difetto grave in AES stesso, il che significa che qualsiasi schema che lo utilizza è immediatamente sospetto.
Quindi no, è una cattiva idea criptare la IV. Se devi farlo, il modo per farlo è rendere il primo blocco del tuo messaggio tutti gli zeri, non inviare l'IV, e dall'altra parte decrittografare il primo blocca e prendi i primi 64 bit (o per quanto tempo i tuoi IV sono) come IV; che non sarà meno sicuro rispetto al CTR regolare. Tuttavia, non sarà più sicuro, perché qualsiasi difetto in AES-CTR relativo all'IV rende presuntivamente non sicure tutte le modalità AES.