2011-02-09 11 views
7

da quello che so, la modalità CTR non utilizza un vettore iniziale. Richiede solo un contatore, lo crittografa con una determinata chiave e quindi XOR è il risultato con il testo in chiaro per ottenere il testo cifrato.uso modalità CTR di Initial Vector (IV)

Altre modalità di cifratura a blocco come CBC prima di eseguire la crittografia XOR il testo in chiaro con un vettore iniziale.

Quindi ecco il mio problema. Ho il seguente codice in Java (utilizzando la libreria bouncycastle):

Cipher cipher = Cipher.getInstance("AES/CTR/PKCS5Padding", "BC"); 

cipher.init(Cipher.ENCRYPT_MODE, key); 

byte[] result = cipher.doFinal("Some plaintext"); 

Ogni diversa chiamata del codice di cui sopra con la stessa chiave dà output diverso! Ma quando si fa:

byte[] IV = new byte[]{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}; 

Cipher cipher = Cipher.getInstance("AES/CTR/PKCS5Padding", "BC"); 

cipher.init(Cipher.ENCRYPT_MODE, key, IV); 

byte[] result = cipher.doFinal("Some plaintext"); 

Prendo lo stesso risultato in ogni chiamata del codice precedente. Ma perché è questo? Voglio dire, il CTR non ha bisogno di un IV, quindi perché quando non prendo una IV in ogni chiamata ottengo un risultato diverso e quando ho dato una IV restituisce lo stesso risultato? Se utilizzo sempre la IV precedente (tutti gli zeri) quando uso CTR, sarebbe sicuro?

Qualsiasi idea sarebbe molto utile. Grazie

+2

[Se stai digitando le lettere AES nel tuo codice, stai sbagliando.] (Http://chargen.matasano.com/chargen/2009/7/22/if-youre-typing-the -letters-aes-into-your-code-youre-doing.html) –

+0

Crypto è * veramente facile * rovinare. E rovinare in modi totalmente invisibili fino a quando qualcuno li sfrutta. Utilizzare invece una libreria consolidata con un'interfaccia hard-to-screw-up. –

+2

@Anon. Ho persino scelto la mia IV, per favore vieni e uccidimi ora. (Suggerimento: alcune persone sanno cosa stanno facendo, questo consiglio generale di non digitare AES nel codice è stupido.) – Luc

risposta

5

Il più importante avvertimento con la modalità CTR è che si mai, mai ri-utilizzare lo stesso valore del contatore con la stessa chiave. Se lo fai, hai effettivamente dato via il tuo testo in chiaro.

Per facilitare questo, in alcune implementazioni del modo CTR del mondo reale il blocco da passare al codice di blocco viene diviso in due parti, etichettate come un IV e un contatore (anziché chiamare il tutto come contatore). L'IV viene generato in modo casuale e il contatore inizia a 0.

Ciò consente di avviare la parte "contatore" a zero per più messaggi, purché non si riutilizzi mai la parte "IV".

Nota che questa è solo una convenzione di etichettatura. Matematicamente, è come chiamare tutto il "contatore" e avviare il contatore a un multiplo casuale di un numero intero per ogni messaggio.

Non sono sicuro di come l'implementazione di Bouncy Castle funzioni in modo specifico, è forse possibile impostare l'intero blocco iniziale, contatore e tutto, con il valore IV. Apparentemente sta generando un IV ragionevole per te se non ne fornisci uno, motivo per cui stai ricevendo output diversi con lo stesso input. La linea di fondo è che questo è buono, ed esattamente quello che vuoi - fornire tutti gli zeri è cattivo, e non quello che vuoi.

+0

Grazie :) Ora ho capito – Antonys

0

La modalità CTR utilizza qualcosa che è essenzialmente equivalente a una IV, e questo è il valore iniziale del contatore.

2

CTR funziona crittografando i valori successivi di un contatore. Il primo valore per quella sequenza è un IV (IV significa "valore iniziale" ...). Quindi CTR usa davvero una flebo.

Se si utilizza la modalità CTR, con la stessa chiave e si riutilizza un valore del contatore già utilizzato per un'altra crittografia (con la stessa chiave), si ottiene il famigerato doppio blocco e la sicurezza è andato in malora. In particolare, usare un IV fisso per tutti i messaggi è una ricetta sicura per il disastro.

Un modo "semplice" per evitare contatore di ripetizioni è selezionare sempre IV con un crittograficamente sicuro generatore di numeri casuali (pensare "java.security.SecureRandom") tra l'insieme di possibili IV, cioè tutte le sequenze di 16 byte. Quel spazio è sufficientemente grande che il rischio di riutilizzare un valore contatore a un certo punto può essere trascurato.

Giusto per essere completo, una IV fissa è tollerabile se ci si assicura di utilizzare una determinata chiave solo una volta. I problemi di sicurezza sorgono quando si riutilizza lo stesso valore contatore con la stessa chiave. Tuttavia, avere una nuova chiave per ogni messaggio è difficile almeno quanto avere una nuova IV per ogni messaggio.

Problemi correlati