Come generare correttamente i vettori di Initalizzazione

Question

Come generare correttamente i vettori di Initalizzazione

#1 da (1 voti)

1

Sto lavorando a un progetto che divide file di grandi dimensioni in diversi blocchi crittografati a dimensione fissa (ad esempio 4KiB). Questi blocchi devono essere utilizzati per essere memorizzati in modo persistente su un dispositivo di archiviazione.

I blocchi sono crittografati simmetricamente e ogni blocco ha il proprio vettore di inizializzazione. Sfortunatamente non sono sicuro di come "generare" correttamente i vettori di inizializzazione:

Come spiegato qui e qui ci sono diversi algoritmi di generazione del vettore di inizializzazione. Ovviamente, deve essere distinto tra quelli privati (ad esempio ESSIV) e quelli pubblici (ad esempio Plain). Ho anche letto che gli algoritmi IV come Plain non devono essere combinati con la modalità operativa CBC.

Quale algoritmo di generazione IV dovrei usare? O in altre parole: cosa NON dovrei assolutamente fare?

Non voglio usare nonce casuali per ogni blocco, dato che questi non dovrebbero essere memorizzati da qualche parte - un algoritmo di generazione IV sarebbe molto più comodo per me.

cryptography encryption file-encryption initialisation-vector

posta rralf 08.01.2014 - 22:43

fonte

1 risposta

Leggi altre domande sui tag cryptography encryption file-encryption initialisation-vector

crittografia SAML2 Qual è il migliore DPAPI o HSM?

score 1 · Answer 1

TL; DR, i requisiti specifici delle IV dipendono dalla modalità di crittografia che stai utilizzando. L'unico attributo comune è che tutti gli IV devono essere unici.

In modalità come CTR e GCM, l'unicità è l'unico requisito. La IV in questo caso viene anche comunemente chiamata nonce (cioè, un "numero usato una volta"). Anche un semplice contatore sarebbe sufficiente, purché sia garantito non generare mai un duplicato (anche su più macchine o in caso di errore del software).

In modalità come CBC, l'IV deve essere indistinguibile da un avversario casuale.

Per gli IV con una dimensione abbastanza grande (ad es. almeno 128 bit), un generatore di numeri casuali crittograficamente sicuro (CSPRNG) è generalmente considerato sufficiente. Per gli algoritmi che coinvolgono IVs che sono abbastanza piccoli tali che le collisioni casuali siano probabili (ad esempio, Salsa20 ha un nonce a 64 bit), un CSPRNG non è appropriato poiché genererebbe collisioni. Un altro scenario in cui un CSPRNG potrebbe non essere utilizzabile è nei dispositivi embedded, che potrebbero non avere la capacità di generare numeri sufficientemente casuali in hardware.