La crittografia AES di un numero limitato di blocchi sarebbe meno sicura rispetto alla crittografia di un buffer imbottito di dimensioni fisse di grandi dimensioni?

Secondo NIST, l'algoritmo AES è in grado di utilizzare chiavi crittografiche di 128, 192 e 256 bit per crittografare e decrittografare i dati in blocchi di dimensioni di 128 bit (16 byte). significa che ogni blocco che va come input per l'algoritmo AES sarà 16 byte, quindi se il tuo BUF_SIZE è di 16 KB, quando vuole andare su AES, di nuovo sarà diviso in blocchi con dimensione di 16 byte e alla fine se ci sono dati con meno di 16 byte sarà riempito (per esempio si vuole cifrare 35 byte, (2 * 16) +3, i 3 byte rimanenti saranno riempiti con 13 byte imbottiti).

Tuttavia la tua modalità AES è importante, ad esempio se la tua modalità è CFB, OFB o CRT , non richiede alcuna imbottitura e può essere parallelizzato. Le modalità CFB, OFB e CTR non richiedono alcuna misura speciale per gestire i messaggi le cui lunghezze non sono multipli della dimensione del blocco, poiché le modalità funzionano con XORing del testo in chiaro con l'output del codice a blocchi. L'ultimo blocco parziale di testo in chiaro è XORed con i primi pochi byte dell'ultimo blocco di keystream, producendo un blocco di testo cifrato finale della stessa dimensione del blocco di testo in chiaro parziale finale. Questa caratteristica dei codici di flusso li rende adatti per le applicazioni che richiedono che i dati cifrati dei testi cifrati abbiano le stesse dimensioni dei dati di testo in chiaro originali.

Ma alcune modalità (vale a dire ECB e CBC) richiedono che il blocco finale venga riempito prima della crittografia.

anche tu hai bisogno di un IV (vettore iniziale) per produrre cifrari distinti anche se lo stesso testo in chiaro è criptato più volte.

quindi in base al tuo esempio:

BUF_SIZE = 16 KB == > 16 * 1024 = 16384 byte === > 16384 mod 16 = 0, significa che ogni BUF_SIZE non ha bisogno di riempimento. e uno rimane (14KB) == > 14 * 1024 = 14,336 byte == > 14,336 mod 16 = 0, quindi anche la fetta restante non ha bisogno di essere riempita e verrà divisa in blocco 896 come input per l'algoritmo AES, che crea la stessa dimensione di input come output.

O per esempio per 310 byte, non è necessario caricarlo su 16 KB, è necessario solo creare 19 blocchi con 16 byte e rimangono 6 byte e uno viene riempito con 10 byte. con insieme ci sono 20 blocchi.

310 = (19 * 16) +6.

Pertanto, devi preoccuparti della forza della chiave e della dimensione e della maniera di proteggerla e utilizzare anche AES standard non tuoi, perché se rimane solo 1 byte verrà riempito con un numero sufficiente di byte di riempimento.

Quindi in questa situazione non vi è alcuna differenza tra la crittografia di 1 byte o 1024000 byte, gli attacchi sono perpetui, la dimensione dei dati non è importante.

AES è una cifra di blocco , il che significa che l'operazione di base elabora solo un blocco (di esattamente 16 byte con AES). Quando si desidera "crittografare un file", è necessario decidere in che modo suddividere e mescolare i dati e ciò che si invia effettivamente al motore AES; questa è chiamata modalità di funzionamento .

Tutte le modalità di funzionamento non sono uguali. Inoltre, alcune modalità offrono anche alcuni controlli di integrità, mentre altre no. Nella maggior parte dei casi in cui è necessaria la crittografia, l'integrità è anche necessaria (poiché la maggior parte degli attacchi passivi può diventare anche aggressori attivi), quindi l'utilizzo di una modalità di crittografia che garantisce l'integrità è, in generale, una buona idea . Utilizzi GCM per l'intestazione; questo è buono. Non usi GCM per il resto del file; questo è meno buono. Dovresti utilizzare GCM ovunque.

Pensare all'integrità chiarisce le cose. L'integrità riguarda il rilevamento delle alterazioni. Ciò significa che, al momento della decodifica, non è possibile utilizzare i dati fino a quando non si sono completati i controlli di integrità (fino a quel momento, non si sa se è corretto o meno). Ad esempio, se si utilizza un semplice processo GCM-the-whole-file, si ottiene un sovraccarico di spazio molto basso (per un file sorgente di n byte, la versione crittografata con GCM avrà lunghezza n +16 byte, incluso il "tag di autenticazione" che incarna il controllo di integrità); tuttavia, ciò significa che è necessario decrittografare l'intero file prima di iniziare a utilizzarlo. Se si dispone, ad esempio, di un file video da 2 GB, è possibile decodificarlo "al volo" (anche solo per evitare di salvare il file decrittografato da qualche parte o mantenerlo intatto nella RAM), ad es. decrittazione completata.

Per supportare l'accesso "in streaming", devi quindi crittografare e decrittografare le cose per blocchi. Basta dividere il file di input in blocchi di k byte per un certo valore di k (tutti i blocchi non devono avere la stessa dimensione) e crittografarli separatamente (con GCM, ogni crittografia resa k +16 byte). Per impedire a un utente malintenzionato di mescolare maliziosamente blocchi, è necessario includere una sorta di sequenza. GCM è una modalità di crittografia autenticata con dati associati , il che significa che può proteggere all'integrità sia i dati che sono criptati e alcuni dati aggiuntivi. Un formato di crittografia di file sicuro utilizzerà quindi il numero di sequenza di blocco come "dati associati".

Usando CFB, non ottieni integrità, quindi hai le vulnerabilità corrispondenti. Inoltre, la modalità CTR è probabilmente migliore di CFB e GCM utilizza la modalità CTR internamente, quindi GCM è decisamente preferibile.