Quindi questa è probabilmente una domanda stupida, ma sto cercando di capire perché non viene fatto quanto segue per i file a riposo crittografati tramite password:
- genera una chiave AES-256 / sale / iv
- prendi il messaggio in chiaro (ad esempio un file da 50 MB) e crittografalo con le credenziali del passaggio 1
- aggiungi le credenziali al messaggio crittografato
- consente all'utente di scegliere una password e convertirla in una chiave AES-256 utilizzando un metodo standard
- crittografare i risultati del passaggio 3 utilizzando la chiave del passaggio 4, utilizzando AES come crittografia a flusso sincrono con una forma modificata di modalità di feedback di uscita in cui:
- invece di usare il testo in chiaro per alimentare il prossimo blocco, una funzione di hashing di memoria elevata (come Argon2i) viene applicata al testo in chiaro, e i risultati di tale operazione vengono inseriti nel blocco successivo
- detta funzione di hashing utilizza parametri di costo coerenti derivati dalla dimensione dei dati in 3. (e quindi il numero di blocchi necessari), oltre alla quantità di memoria necessaria per decrittografare l'intero file (quindi il programma di crittografia ti conosce vuoi che richieda di scrivere un totale di 1 GB di memoria per decrittografare questo file)
A meno che AES-256 stesso non sia stato compromesso, sembrerebbe che per attaccare questo file, dovresti:
- scegli una probabile password e converti il corrispondente tasto AES-256
- usa questo tasto per decodificare l'intero file, ad ogni blocco calcolando l'hash Argon2i del blocco precedente (che richiede una quantità predeterminata di memoria)
- quando raggiungi la fine del file, usa i bit alla fine (che potrebbe essere la chiave che ti serve) per decodificare il primo blocco (già decrittografato una volta) e vedere se sei corretta
Dal momento che non è stato possibile parallelizzare facilmente il cracking a causa della cifratura a flusso sincrono (ogni tentativo richiede la decifrazione di messaggi completi), oltre al fatto che ogni blocco richiede di scrivere una quantità arbitraria di memoria (riducendo la minaccia di GPU veloci / futuri computer quantistici / ecc.), un metodo come questo non fornisce una sicurezza aggiuntiva in un modo che il passaggio da AES-256 a un AES-512 teorico non lo farebbe (dal momento che ogni password relativamente breve genererà comunque una chiave AES-512 completa, e puoi verificare se tale ipotesi è corretta senza decrittografare l'intero messaggio, quindi non c'è davvero nulla di guadagnato).
Regolando i parametri sulla tua funzione di hashing (in base alla dimensione del file), dovresti essere in grado di dire che "il tentativo di decodificare questo file da 1 KB richiede la scrittura di 500 MB di memoria ... e il tentativo di decifrare questo file da 3 GB richiederà anche la scrittura di 500 MB di memoria ". Quindi non sarebbe necessariamente proibitivo per i file di grandi dimensioni.
So che ci deve essere una ragione per cui non è stato fatto, e mi piacerebbe capire dove sto andando male!