Qual è il vantaggio dell'uso di un codice simmetrico come AES per generare un keystream?

AES, di per sé, è una cifra a blocchi : accetta come input un "blocco" di 16 byte, e produce un blocco di 16 byte. Ma vogliamo usarlo per crittografare "dati", in genere lunghe sequenze di byte, molto più lunghi di 16 byte, quindi è necessario qualcos'altro; questa è la modalità di funzionamento . La modalità operativa definisce come vengono elaborati i dati di input e, in particolare, cosa esattamente va inserito nel codice di blocco corretto.

Il metodo più semplice consiste nel suddividere i dati in blocchi da 16 byte e elaborarli indipendentemente l'uno dall'altro. Questo è chiamato ECB. La solita immagine del pinguino (vedi la risposta di @ drjimbob) è una chiara dimostrazione che c'è qualcosa di sbagliato in ECB, quando si elaborano "dati normali". È necessaria una migliore modalità di crittografia. Storicamente, OFB, CFB e CBC hanno guadagnato popolarità, poi in seguito è stato definito il CTR. Tutte queste modalità fanno cose diverse con i dati e invocano il codice a blocchi su blocchi diversi. In CBC e CFB, AES è invocato di blocchi che sono un XOR di un blocco di dati con alcuni prodotti di elaborazione passata; con OFB e CTR, AES viene invocato su qualcosa che dipende dall'IV, dalla chiave e dalla posizione del blocco, ma non dai dati stessi.

Con molto sventolio di mani, possiamo affermare che in una buona modalità di funzionamento, i dati grezzi non dovrebbero inserire il codice a blocchi "così com'è" . Il motivo è il seguente: i dati normali hanno ridondanza, quindi puoi aspettarti che i blocchi di origine abbiano ripetizioni (ad esempio, pensi all'XML). Tuttavia, il codice a blocchi stesso è deterministico, quindi se lo chiamate due volte sullo stesso output, otterrete il doppio dello stesso output. Questo è il tipo di perdita di informazioni che un buon sistema di crittografia dovrebbe nascondere. In una modalità operativa, il "potere nascosto" sta nel codice a blocchi; il resto è semplice instradamento di dati; pertanto, al fine di nascondere le ripetizioni e altri elementi strutturali dei dati di origine, la modalità dovrebbe essere tale che nessuna delle due invocazioni del codice a blocchi debba inviare lo stesso blocco al codice a blocchi. E questo implica almeno un'elaborazione di pre-cifratura.

Ora CFB e CBC ancora "combinano" il blocco di dati con l'input di cifrario a blocchi, mentre OFB e CTR fanno questa combinazione solo sull'uscita. Potremmo argomentare che quest'ultimo metodo è superiore perché consente precomputazioni: con OFB e CTR, si può "preparare" la stringa pseudo-casuale prima di avere accesso ai dati effettivi. Tuttavia, questo è raramente fatto, perché il buffering ha i suoi costi. Una caratteristica molto più importante del CTR, che CFB, OFB e CBC non hanno, è parallelizzazione : dato, ad esempio, un messaggio da 160 byte per crittografare, le 10 invocazioni AES sottostanti possono essere eseguite simultaneamente, a condizione di avere abbastanza circuiti per questo. Non è possibile farlo con CBC, perché è necessario attendere il risultato della crittografia di un blocco per iniziare l'elaborazione del blocco successivo (tuttavia è possibile avere decrittazione CBC in parallelo). I creatori di circuiti a larghezza di banda elevata amano la modalità CTR (che si adatta bene alle implementazioni AES non allineate, con tubazioni).

Per riassumere:

• C'è bisogno di una modalità di funzionamento più complessa di ECB.
• La modalità dovrebbe includere alcuni pre-elaborazione dei dati in modo che i dati non vengano immessi "così come sono" il codice a blocchi. Se la modalità "crittografa direttamente il testo in chiaro" (vale a dire applica il codice di blocco su blocchi di dati sorgente non modificati) allora avrà problemi a nascondere le ripetizioni, e questo è un problema con i normali dati strutturati.
• Non vi è alcuna necessità formale che i dati di origine inseriscano il codice di blocco; i dati di origine possono entrare nel mix come una fase di post-elaborazione. Ciò offre alcuni vantaggi minori, ad es. la possibilità di precomporre la maggior parte delle operazioni; se la post-elaborazione è un semplice XOR, rende anche la decrittazione identica alla crittografia, il che è utile quando un sistema deve fare entrambe le cose (salva spazio di codice e / o area di silicio).
• Una caratteristica importante delle buone modalità è la possibilità di accelerare le cose con la parallelizzazione. Accade così che l'unica modalità popolare che è suscettibile di parallelizzazione sia per la crittografia sia per la decrittazione (cioè CTR) è anche una modalità "solo post-elaborazione". Questa è una coincidenza; per quanto ne so, non c'è una strong ragione per cui dovrebbe essere così. Ma è comunque bello (come detto sopra) quindi non ci lamenteremo.

L'operazione che hai descritto è solo modalità CTR, una delle modalità di cifratura a blocchi standard . Devi scegliere una modalità di cifratura a blocchi; non è possibile scegliere una quantità per la modalità ECB (Electronic Code Book) quando è necessario crittografare più di un blocco di dati. È risaputo che si dovrebbe evitare la modalità ECB poiché è abbastanza comune essere in grado di rilevare i pattern nei dati crittografati. Vedi ad esempio l'esempio di wikipedia di crittografia di un'immagine di un pinguino in modalità ECB:

CBC(CipherBlockChaining)èunbuonsistemadisicurezzadellamodalità;garantitononèpossibileparallelizzarelacrittografia-nonèpossibilecrittografareilblocco2finoaquandononsiècrittografatoilblocco1.Questoperchél'N-esimobloccodeltestocifrato(C_N)ègeneratodallacrittografiaXORdell'N-esimobloccoditestoinchiaroeil(N-1)-thbloccoditestocifrato:C_N=Encrypt(P_NXORC_N-1).

LamodalitàCTRèunaltrobuonsistemadisicurezza.IlvantaggioprincipalesuCBCèchepuoiparallelizzaresialacrittografiacheladecrittografia.

C'èancheunaltropiccolovantaggiodellamodalitàCTRsumodalitàcomeCBCsesistannocrittografandoenormiquantitàdidati.PerunAES-128,incuiognibloccoèa128bitconlamodalitàCTR,nonsiesegueunciclofinchénonsicriptapiùdi2¹²⁸blocchi(eogniilbloccoè128bit=16byte-questo5070602400912917605986812821504GBdidatiprimadiripristinarelamodalitàCTRperesseresicuri).PerlamodalitàCBC,haiilparadossodelcompleannoinazioneinmododagenerareunacollisioneogni2^128/2blocchicrittografati-ogni274877906944GBdidati,primadevipreoccupartidiciòchedovresticambiarelatuachiave.

Vedianche La grande risposta di Thomas Pornin su questo piccolo vantaggio .