Come usare ESSIV per evitare di vedere ripetizioni?

Naviga le tue risposte
1

Sto cercando di implementare un sistema di file crittografato.

Il file system è costituito da settori da 512 byte. Cifrare / decifrare il contenuto di un settore come segue:

  1. Calcola la somma SHA256 della password dell'utente. Questo risulta in una chiave utente di 32 byte.

  2. Calcola l'ESSIV per un settore calcolando la somma SHA256 della chiave utente e il numero di settore. Ciò si traduce in una chiave di settore a 32 byte.

  3. XOR Settore Chiave con i dati di settore semplici per ottenere i dati di crittografia come segue: 

sector[0] = sector[0] ^ key[0]
sector[1] = sector[1] ^ key[1]
...
sector[31] = sector[31] ^ key[31]

sector[32] = sector[32] ^ key[0]
sector[33] = sector[33] ^ key[1]
...
sector[63] = sector[63] ^ key[31]

...
sector[511] = sector[511] ^ key[31]

Quando leggo il settore più tardi, I XOR la chiave del settore con i dati cifrati per recuperare i dati del settore normale indietro.

Ora, l'approccio ESSIV dovrebbe impedire attacchi con filigrana. Tuttavia, quando esamino i settori cifrati corrispondenti a un file molto grande (> > 512-byte) pieno di soli zero ( 0x00 ) ...

  • Vedo che non esistono due settori cifrati di questo grande file identici, il che è fantastico!
  • Vedo schemi ripetuti (ogni pattern lungo 32 byte) all'interno dello stesso settore, che non è così eccezionale! Questi sono ovviamente derivanti dal passo XOR sopra.

La mia domanda è doppia:

  1. È possibile che un avversario interrompa la suddetta crittografia del file system copiando file attentamente costruiti in questo file system? Oppure, lo schema sopra è abbastanza buono?

  2. Quando copio il file sopra in un volume TrueCrypt, non vedo pattern ripetuti. (Ho usato AES e RIPEMD-160 come algoritmi di crittografia e hashing, rispettivamente.) Quindi, oltre all'utilizzo di AES, cosa posso fare per ottenere un risultato simile a TrueCrypt tramite un'operazione semplice e leggera simile a XOR?

posta Harry 23.02.2014 - 15:33
fonte

2 risposte

1

Il tuo approccio è corretto (anche se dovremmo sempre ricordare la prima legge della crittografia: " non eseguire il rollover "). Se posso suggerire qualche leggera svolta:

  1. Calcola il checksum SHA256 di alcune sale fisse (meglio se dipende dal file system, ad esempio una sequenza casuale memorizzata in esso) e la password dell'utente. Ciò impedisce a un utente malintenzionato di avere un database di checksum SHA256 di password comuni. Il sale verrà generato casualmente quando (sempre) il file system viene formattato e memorizzato nella struttura del file system (Password Salt). L'attaccante deve quindi rigenerare nuovamente il suo database SHA256 dopo per ottenere l'accesso al file system (il che significa che è bruteforcing con vantaggio zero).

  2. Non utilizzare la chiave utente per crittografare il disco. È meglio utilizzare una chiave casuale a 32 byte e crittografare questa chiave utilizzando la password con hash. La sicurezza è la stessa, ma in questo modo, se l'utente cambia la sua password, non è necessario decodificare e ricodificare l'intero file system, decodificare e crittografare nuovamente la chiave.

  3. Invece di utilizzare quella che è effettivamente la modalità ECB per la codifica del settore, usa il CTR più lento ma più sicuro, usando la tua chiave di settore come IV:

    SHA256 (SectorNumber, DiskKey) = > IV per questo settore

    SHA256 (IV, 0) = > Chiave XOR per byte 0..31

    SHA256 (IV, 1) = > Chiave XOR per byte 32..63

    ...

    SHA256 (IV, 15) = > Chiave XOR per byte 480..511

risposta data 24.02.2014 - 21:44
fonte
0

Ho ottenuto un vantaggio con XEX .

PS: Non esitare a condividere risposte o approfondimenti migliori e selezionerò i tuoi come finali.

    
risposta data 23.02.2014 - 16:50
fonte

Leggi altre domande sui tag

Gestione delle chiavi nei proxy di intercettazione? Posso utilizzare un CDN per contenuti statici senza sacrificare le chiavi SSL?