To improve security to some extent, I use keyfile generation technique (to change an existing file into an actual keyfile).
Stai usando uno strumento esterno per farlo, o qualcosa di integrato in TrueCrypt? AFAIK è possibile utilizzare qualsiasi tipo di file come file di chiavi TC, ma il file viene utilizzato così com'è, non viene eseguita alcuna trasformazione. Da i documenti :
Note that TrueCrypt never modifies the keyfile contents. You can select more than one keyfile; the order does not matter. You can also let TrueCrypt generate a file with random content and use it as a keyfile. To do so, select Tools > Keyfile Generator.
Qualunque sia il metodo utilizzato per "trasformare un file normale in un file di chiavi", devi assicurarti che sia deterministico (ad esempio, genera sempre lo stesso file di chiavi dato lo stesso input), altrimenti non puoi gettare via dopo l'uso. E, naturalmente, se lo generi da una fonte casuale, devi mantenerlo per poterlo sbloccare più tardi.
If yes, then it could be safely overwritten and destroyed immediately after usage, further enhancing security associated with using truecrypt.
Non vedo come ciò migliorerà la sicurezza. Se il file originale è sufficiente per decodificare un volume, un utente malintenzionato che ha accesso ad esso può anche fare lo stesso, indipendentemente da quanti passaggi intermedi ci sono per trasformarlo nel file di chiavi risultante. Lo stesso con keyfile + password vs. file originale + password. Ciò significa che devi proteggere questo file come faresti con il file di chiavi.
Si potrebbe sostenere che l'uso di un file arbitrario è più sicuro rispetto all'utilizzo di un file di chiavi "standardizzato", poiché ce ne sono così tanti nel computer e l'utente malintenzionato deve sapere qual è la chiave. Un file a 64 byte con dati casuali "spicca tra la folla", quindi in linea di principio dovrebbero essere i primi a essere provati. È un po 'come "sicurezza per oscurità", ma se non hai un modo migliore per proteggere il tuo file di chiavi, questo dovrebbe darti un po' più di protezione.
Tuttavia, devo sottolineare che dal momento che TrueCrypt accetta molti keyfile contemporaneamente, e il suo hashing per combinarli insieme e con la password fornita, non è necessario eseguire personalmente il passaggio intermedio (che potenzialmente aumenta la superficie di attacco).
E per una ragione per avere molti file di chiavi: se il tuo supporto di archiviazione ha N file e K di essi saranno usati come file di chiavi, il numero totale di combinazioni che l'utente malintenzionato deve provare è N! / (K! * (N-K)!) . Scegliendo con cura questo numero, puoi renderlo molto più difficile da forzare, anche se l'autore dell'attacco ha accesso a tutti i tuoi file e un sacco di tempo e risorse per provarli. (Assicurati di sparpagliare i file di chiavi attraverso diverse cartelle ...) Sta a te decidere il compromesso tra sicurezza e convenienza, dal momento che fornire tutti quei file di chiavi ha anche il suo costo - nella pazienza dell'utente, che può essere molto limitata.
Aggiornamento: come da commento, stai utilizzando 20 file su 1000, che in linea di principio richiederebbero molto tempo per craccare ( 1.6 * 10^10 anni a 1000 tentativi / secondo). Tuttavia, hai detto che i file sono scelti in base all'input dell'utente, quindi devo sottolineare questo fatto:
Nonostante il gran numero di possibilità di scegliere quei 20 file ( 5.3 * 10^20 ~ 68 bit di entropia), non tutti sono ugualmente probabili da scegliere, poiché il processo non è casuale. Infatti, ogni sequenza di input dell'utente (che chiamiamo "password") determinerà deterministicamente una singola combinazione. Pertanto, l'entropia del tuo schema sarà al massimo uguale all'entropia della tua "password" (limitata a 68 bit). In altre parole, un utente malintenzionato che conosce il tuo processo ha bisogno solo di rifare lo stesso (contro un elenco di ipotesi "password") per ottenere una valida combinazione di file - un risultato migliore rispetto a provare tutti in modo casuale.
Inoltre, devi assicurarti che la logica per scegliere quei file non porti a troppe collisioni. Se due o più input portano allo stesso insieme di file, uno di essi può essere utilizzato in modo intercambiabile. Se ciò accade, l'entropia risultante può essere anche inferiore a quella che otterresti semplicemente usando quell'input dell'utente come password. E, inutile dire, l'uso di una password con più di 68 bit di entropia non avrà alcun effetto (ad esempio 11 caratteri o più), poiché a questo punto è garantito che le collisioni avvengano (contrasto con i 512 bit di entropia che è possibile ottenere utilizzando un file di chiavi casuali o circa 420 utilizzando una password casuale con 64 caratteri ASCII stampabili).
