crittografia accesso casuale con AES in modalità contatore utilizzando Fortuna PRNG:

Question

Sto costruendo file crittografia basata su AES che devono essere in grado di funzionare in modalità ad accesso casuale (accesing qualsiasi parte del file). AES a contatore per esempio possono essere utilizzati, ma è ben noto che abbiamo bisogno di una sequenza unica mai usato due volte. E 'ok per utilizzare un semplificata Fortuna PRNG in questo caso (la crittografia di un contatore con un scelto a caso specifica chiave unica per la particolare file)? Ci sono punti deboli in questo approccio?

Quindi, la crittografia / decrittografia può assomigliare a questo

La crittografia di un blocco a Offset:

rndsubseq = AESEnc(Offset, FileUniqueKey)
xoredplaintext = plaintext xor rndsubseq
ciphertext = AESEnc(xoredplaintext, PasswordBasedKey)

decrittografia di un blocco a Offset:

rndsubseq = AESEnc(Offset, FileUniqueKey)
xoredplaintext = AESDec(ciphertext, PasswordBasedKey)
plaintext = xoredplaintext xor rndsubseq

Una sola osservazione. Sono venuto a l'idea utilizzata in Fortuna di me e sicuramente scoperto più tardi che è già inventato. Ma, come ho letto in tutto il mondo il punto chiave su di esso è la sicurezza, ma c'è un altro buon punto: si tratta di un ottimo accesso casuale pseudo generatore di numeri casuali per così dire (in forma semplificata). Così il PRNG che non solo produce molto buona sequenza (ho provato con Ent e Die Hard), ma anche permettere di accedere a qualsiasi sotto-sequenza se si conosce il numero di passo. Quindi è generalmente ok per utilizzare Fortuna come un PRNG "ad accesso casuale" in applicazioni di sicurezza?

EDIT:

In altre parole, ciò che io propongo è quello di utilizzare Fortuna PRNG come un tweak per formare un tweakable AES Cipher con la capacità ad accesso casuale. Ho letto il lavoro di Liskov, Rivest e Wagner, ma non riuscivo a capire quale fosse la differenza principale tra un cifrario in una modalità di funzionamento e di un cifrario tweakable. Hanno detto che hanno suggerito di portare questo approccio da alto livello all'interno della cifra in sé, ma per esempio nel mio caso XOR il testo con il tweak, è presente un tweak o no?

Answer 1

Credo che si potrebbe voler cercare come "cifrari a blocchi modificabili" lavoro e hanno uno sguardo a come il problema della crittografia del disco è risolto: teoria di cifratura del disco . La crittografia dell'intero disco è simile al vostro problema: la crittografia di ciascun settore deve essere fatto in modo indipendente (si desidera la crittografia indipendente dei dati a diversi offset) e tuttavia il tutto deve essere sicuro. C'è un sacco di lavoro svolto su questo. Wikipedia sembra dare una buona panoramica.

A cura di aggiungere: Re tua modifica: Sì, si sta cercando di fare un cifrario a blocchi tweakable di AES da XOR il tweak con il testo in chiaro. Più concretamente, si dispone di Enc (T, K, M) = AES (K, F (T) XOR M) dove AES (K, ...) significa la crittografia AES con la chiave K e F (T) è una funzione di il tweak (nel tuo caso credo che sia Fortuna). Ho avuto un breve sguardo al giornale che lei ha citato e, per quanto posso vedere che sia possibile dimostrare che questo metodo non non produrre una sicura cifratura a blocchi tweakable. L'idea (sulla base di definizioni di sezione 2 della Liskov, Rivest, carta Wagner) è il seguente. Abbiamo accesso a uno l'oracolo crittografia o una permutazione casuale e vogliamo dire quale stiamo interagendo con. Siamo in grado di impostare il T Tweak e il testo in chiaro M e abbiamo tornare il testo cifrato corrispondente ma non conoscere la chiave che viene utilizzato. Ecco come capire se si usa la costruzione AES (K, f (T) xor M). Scegliere qualsiasi due diversi valori T, T 'calcolare f (T), f (T'). Scegliere qualsiasi messaggio M e quindi calcolare il secondo messaggio come M '= M xor f (T) xor f (T'). Ora chiedo l'oracolo di crittografia per cifrare M utilizzando Tweak T e M 'utilizzando Tweak T'. Se ci occupiamo della costruzione considerato, le uscite saranno identici. Se abbiamo a che fare con permutazioni casuali, le uscite saranno quasi certamente (con probabilità 1-2 ^ -128) diverso. Questo perché entrambi gli ingressi verso le cifrature AES sarà lo stesso, in modo che i testi cifrati saranno identici. Questo non sarebbe il caso quando usiamo permutazioni casuali, perché la probabilità che le due uscite sono identici è 2 ^ -128. La linea di fondo è che XOR tweak per l'ingresso non è probabilmente un metodo sicuro.

Il documento fornisce alcuni esempi di ciò che può dimostrare di essere una costruzione sicura. Il più semplice sembra essere Enc (T, K, M) = AES (K, T xor AES (K, M)). Hai bisogno di due crittografie per blocco, ma dimostrare la sicurezza di questa costruzione. Essi citano anche le varianti più veloci, ma richiedono ulteriori (famiglie di funzioni quasi-XOR-universale) primitivi.

Answer 2

Anche se penso che il tuo approccio è abbastanza sicura, non vedo alcun beneficio oltre CTR. Avete lo stesso identico problema, che è non si inietta vera casualità al testo cifrato. L'offset è un ingresso sistematico nota. Anche se è criptato con una chiave, è ancora non è casuale.

Un altro problema è come si fa a mantenere il FileUniqueKey è sicuro? Criptata con password? Un intero mazzo problemi vengono introdotte quando si utilizzano più chiavi.

Modalità contatore è accettata la pratica per crittografare i file ad accesso casuale. Anche se ha tutti i tipi di vulnerabilità, è tutto ben studiato in modo che il rischio è misurabile.