Quali di questi sono preferiti in quali circostanze?

Mi piacerebbe vedere l'elenco dei criteri di valutazione per le varie modalità e forse una discussione sull'applicabilità di ciascun criterio.

Ad esempio, penso che uno dei criteri sia la "dimensione del codice" per la crittografia e la decrittografia, che è importante per i sistemi integrati con microcodice, come gli adattatori di rete 802.11. Se il codice richiesto per implementare CBC è molto più piccolo di quello richiesto per CTR (non so che sia vero, è solo un esempio), allora potrei capire perché la modalità con il codice più piccolo sarebbe preferita. Ma se sto scrivendo un'app che gira su un server e la libreria AES che sto utilizzando implementa sia CBC che CTR, allora questo criterio è irrilevante.

Vedi cosa intendo per "elenco di criteri di valutazione e applicabilità di ciascun criterio" ??

Questo non è realmente legato alla programmazione ma è legato all'algoritmo.

• La BCE non deve essere utilizzata se si crittografa più di un blocco di dati con la stessa chiave.

• CBC, OFB e CFB sono simili, tuttavia OFB / CFB è migliore perché è necessaria solo la crittografia e non la decrittografia, che può risparmiare spazio di codice.

• Il CTR viene utilizzato se si desidera una buona parallelizzazione (ovvero velocità), anziché CBC / OFB / CFB.

• La modalità XTS è la più comune se si codifica un dato accessibile in modo casuale (come un disco rigido o una RAM).

• OCB è di gran lunga la modalità migliore, in quanto consente la crittografia e l'autenticazione in un unico passaggio. Tuttavia ci sono brevetti su di esso negli Stati Uniti.

L'unica cosa che devi davvero sapere è che la BCE non deve essere utilizzata se non stai crittografando solo 1 blocco. XTS dovrebbe essere usato se si sta crittografando dati a accesso casuale e non uno stream.

• Dovresti SEMPRE usare IV unici ogni volta che esegui la crittografia e dovrebbero essere casuali . Se non puoi garantire che siano casuali , usa OCB poiché richiede solo un nonce , non un IV , e c'è una differenza netta. Un nonce non elimina la sicurezza se le persone possono indovinare il successivo, un IV può causare questo problema.

Ti preghiamo di considerare a lungo e se non riesci ad aggirare l'implementazione della tua crittografia

La brutta verità della questione è che se stai ponendo questa domanda probabilmente non sarai in grado di progettare e implementare un sistema sicuro.

Consentitemi di illustrare il mio punto: immaginate di creare un'applicazione Web e di archiviare alcuni dati della sessione. È possibile assegnare a ciascun utente un ID sessione e archiviare i dati della sessione sul server in un ID sessione mappatura mappa hash ai dati della sessione. Ma poi devi affrontare questo fastidioso stato sul server e se ad un certo punto hai bisogno di più di un server le cose diventeranno confuse. Quindi invece hai l'idea di memorizzare i dati della sessione in un cookie sul lato client. Lo crittograferai ovviamente in modo che l'utente non possa leggere e manipolare i dati. Quindi quale modalità dovresti usare? Venendo qui leggi la risposta migliore (scusami per averti scelto myforwik). Il primo coperto - BCE - non fa per te, vuoi crittografare più di un blocco, il successivo - CBC - suona bene e non hai bisogno del parallelismo del CTR, non hai bisogno di un accesso casuale, quindi nessun XTS e brevetti sono un PITA, quindi nessun OCB. Usando la tua libreria crittografica ti rendi conto che hai bisogno di un po 'di riempimento perché puoi solo crittografare multipli della dimensione del blocco. Tu scegliPKCS7 perché è stato definito in alcuni seri standard di crittografia. Dopo aver letto da qualche parte che CBC è decisamente sicuro se usato con un IV casuale e un codice di blocco sicuro, ti riposi a tuo agio anche se stai memorizzando i tuoi dati sensibili sul lato client.

Anni dopo che il tuo servizio è diventato veramente significativo, uno specialista della sicurezza IT ti contatta in una divulgazione responsabile. Ti sta dicendo che può decifrare tutti i tuoi biscotti usando un attacco oracolo imbottito , perché il tuo codice produce una pagina di errore se il riempimento è in qualche modo rotto.

Questo non è uno scenario ipotetico: Microsoft aveva questo esatto difetto in ASP.NET fino a pochi anni fa.

Il problema è che ci sono molte insidie ​​riguardo alla crittografia ed è estremamente facile costruire un sistema che sembra sicuro per il profano ma è banale rompere per un aggressore esperto.

Cosa fare se è necessario crittografare i dati

Per le connessioni in tempo reale utilizzare TLS (assicurarsi di controllare il nome host del certificato e la catena dell'emittente). Se non puoi utilizzare TLS, cerca l'API di livello più alto che il tuo sistema ha da offrire per la tua attività e assicurati di comprendere le garanzie che offre e più importante ciò che non garantisce. Nell'esempio sopra, un framework come Play offre funzionalità di archiviazione lato client , tuttavia non invalida i dati memorizzati dopo qualche tempo e, se si modifica lo stato lato client, un utente malintenzionato può ripristinare uno stato precedente senza che l'utente se ne accorga.

Se non è disponibile alcuna astrazione di alto livello, utilizzare una libreria di crittografia di alto livello. Un esempio importante è NaCl e un'implementazione portatile con molti collegamenti linguistici è il sodio . Usando una libreria del genere non devi preoccuparti delle modalità di crittografia ecc. Ma devi essere ancora più attento ai dettagli di utilizzo che con un'astrazione di livello superiore, come non usare mai un nonce due volte.

Se per qualche motivo non è possibile utilizzare una libreria di crittografia di alto livello, ad esempio perché è necessario interagire con il sistema esistente in un modo specifico, non è possibile educare a fondo. Consiglio di leggere Ingegneria della crittografia di Ferguson, Kohno e Schneier . Per favore, non illuderti nel credere di poter costruire un sistema sicuro senza lo sfondo necessario. La crittografia è estremamente sottile ed è quasi impossibile testare la sicurezza di un sistema.

Confronto delle modalità

Solo crittografia:

• Modalità che richiedono il riempimento : Come nell'esempio, il riempimento può essere generalmente pericoloso perché apre la possibilità di attacchi di riempimento. La difesa più semplice è autenticare ogni messaggio prima della decrittazione. Vedi sotto.
  • La BCE crittografa ogni blocco di dati in modo indipendente e lo stesso blocco di testo normale comporterà lo stesso blocco di testo cifrato. Dai un'occhiata all'immagine Tux crittografata della BCE sulla pagina Wikipedia della BCE per capire perché si tratta di un problema serio. Non conosco alcun caso d'uso in cui la BCE sarebbe accettabile.
  • CBC ha un IV e quindi ha bisogno di casualità ogni volta che un messaggio viene crittografato, cambiare una parte del messaggio richiede una nuova crittografia di tutto dopo la modifica, gli errori di trasmissione in un blocco di testo cifrato distruggono completamente il testo in chiaro e cambiano la decrittazione del blocco successivo, la decrittazione può essere parallelizzato / la crittografia no, il testo in chiaro è malleabile in una certa misura - questo può essere un problema .
• Modalità di cifratura in streaming : queste modalità generano un flusso di dati pseudo casuale che può o meno dipendere dal testo in chiaro. Analogamente ai codici di flusso in generale, il flusso pseudo casuale generato è XORed con il testo in chiaro per generare il testo in codice. Poiché puoi utilizzare tutti i bit del flusso casuale che desideri, non è necessario alcun riempimento. Lo svantaggio di questa semplicità è che la crittografia è completamente malleabile, il che significa che la decrittazione può essere modificata da un utente malintenzionato in qualsiasi modo gli piaccia come per un testo in chiaro p1, un testo cifrato c1 e un flusso pseudo casuale r e un utente malintenzionato possono scegliere una differenza d tale che la decrittazione di un testo cifrato c2 = c1⊕d è p2 = p1⊕d, come p2 = c2⊕r = (c1 ⊕ d) ⊕ r = d ⊕ (c1 ⊕ r). Inoltre, lo stesso flusso pseudo casuale non deve mai essere usato due volte rispetto a due cifrari c1 = p1⊕r e c2 = p2⊕r, un attaccante può calcolare lo xor dei due caratteri semplici come c1⊕c2 = p1⊕r⊕p2⊕r = p1⊕p2. Ciò significa anche che la modifica del messaggio richiede la completa re-crittografia, se il messaggio originale avrebbe potuto essere ottenuto da un utente malintenzionato. Tutte le seguenti modalità di cifratura a vapore necessitano solo dell'operazione di crittografia della cifratura a blocchi, quindi a seconda della cifratura ciò potrebbe risparmiare spazio (silicio o codice macchina) in ambienti estremamente ristretti.
  • Il CTR è semplice, crea un flusso pseudo casuale che è indipendente dal testo in chiaro, si ottengono diversi flussi pseudo casuali contando da diversi nonces / IV che vengono moltiplicati per una lunghezza massima del messaggio in modo da prevenire la sovrapposizione, utilizzando la crittografia dei messaggi nonces possibile senza casualità, decodifica e crittografia per messaggio sono completate parallelamente, gli errori di trasmissione influiscono solo sui bit sbagliati e niente di più
  • OFB crea anche un flusso pseudo casuale indipendente dal testo in chiaro, si ottengono diversi flussi pseudo casuali a partire da un diverso nonce o IV casuale per ogni messaggio, né la crittografia né la decrittazione sono parallelizzabili, poiché con CTR è possibile utilizzare la crittografia dei messaggi nonces senza per messaggio la casualità, come nel caso degli errori di trasmissione CTR, influisce solo sui bit sbagliati e niente di più
  • Lo stream pseudo casuale di CFB dipende dal testo in chiaro, è necessario un diverso nonce o random IV per ogni messaggio, come con CTR e OFB è possibile utilizzare la crittografia dei messaggi nonces senza la casualità per messaggio, la decrittazione è parallelizzabile / la crittografia no, gli errori di trasmissione completamente distruggere il blocco seguente, ma influisce solo sui bit errati nel blocco corrente
• Modalità di crittografia del disco : queste modalità sono specializzate per crittografare i dati al di sotto dell'astrazione del file system. Per motivi di efficienza, la modifica di alcuni dati sul disco deve richiedere solo la riscrittura di un massimo di un blocco disco (512 byte o 4kib). Esse non rientrano nell'ambito di questa risposta in quanto presentano scenari di utilizzo molto diversi dall'altro. Non utilizzarli per nulla tranne la crittografia del disco a livello di blocco . Alcuni membri: XEX, XTS, LRW.

Crittografia autenticata:

Per prevenire attacchi di padding oracle e modifiche al testo cifrato, è possibile calcolare un codice di autenticazione dei messaggi (MAC) sul testo cifrato e decrittografarlo solo se non è stato manomesso. Questo si chiama encrypt-then-mac e dovrebbe essere preferito a qualsiasi altro ordine . Fatta eccezione per pochissimi casi d'uso, l'autenticità è importante quanto la riservatezza (quest'ultima è l'obiettivo della crittografia). Gli schemi di crittografia autenticata (con dati associati (AEAD)) combinano il processo in due parti di crittografia e autenticazione in una modalità di cifratura a blocchi che produce anche un tag di autenticazione nel processo. Nella maggior parte dei casi ciò si traduce in un miglioramento della velocità.

• CCM è una semplice combinazione di modalità CTR e CBC-MAC. Utilizzando due crittografie a blocchi di codice per blocco è molto lento.
• OCB è più veloce ma gravato da brevetti. Tuttavia, gratuitamente (come in libertà) o software non militare il titolare del brevetto ha concesso una licenza gratuita .
• GCM è una combinazione molto veloce ma probabilmente complessa di modalità CTR e GHASH, un MAC sul campo Galois con 2 ^ 128 elementi. Il suo ampio utilizzo in importanti standard di rete come TLS 1.2 è riflesso da un'istruzione speciale che Intel ha introdotto per accelerare il calcolo di GHASH.

Raccomandazione:

Considerando l'importanza dell'autenticazione, raccomanderei le seguenti due modalità di cifratura a blocchi per la maggior parte dei casi d'uso (tranne per scopi di crittografia del disco): Se i dati sono autenticati da una firma asimmetrica, usare CBC, altrimenti usare GCM.

Un'analisi formale è stata fatta da Phil Rogaway nel 2011, qui . La sezione 1.6 fornisce un riepilogo che trascrivo qui, aggiungendo la mia enfasi in grassetto (se sei impaziente, allora la sua raccomandazione è utilizzare la modalità CTR, ma ti suggerisco di leggere i miei paragrafi sull'integrità del messaggio rispetto alla crittografia di seguito).

Si noti che la maggior parte di questi richiede che l'IV sia casuale, il che significa che non è prevedibile e quindi dovrebbe essere generato con sicurezza crittografica. Tuttavia, alcuni richiedono solo un "nonce", che non richiede tale proprietà ma richiede solo che non venga riutilizzato. Pertanto, i progetti che si basano su un nonce sono meno soggetti a errori rispetto ai progetti che non lo fanno (e credetemi, ho visto molti casi in cui CBC non è implementato con una corretta selezione IV). Quindi vedrai che ho aggiunto grassetto quando Rogaway dice qualcosa come "la riservatezza non è raggiunta quando il IV è un nonce", significa che se scegli il tuo IV crittograficamente sicuro (imprevedibile), allora nessun problema. Ma se non lo fai, allora stai perdendo le buone proprietà di sicurezza. Non riutilizzare mai un IV per nessuna di queste modalità.

Inoltre, è importante comprendere la differenza tra integrità del messaggio e crittografia. La crittografia nasconde i dati, ma un utente malintenzionato potrebbe essere in grado di modificare i dati crittografati e i risultati possono essere potenzialmente accettati dal software se non si controlla l'integrità del messaggio. Mentre lo sviluppatore dirà "ma i dati modificati torneranno come spazzatura dopo la decrittazione", un buon ingegnere della sicurezza troverà la probabilità che la spazzatura causi comportamenti avversi nel software, e poi trasformerà quell'analisi in un vero attacco. Ho visto molti casi in cui è stata utilizzata la crittografia, ma l'integrità del messaggio era davvero necessaria più della crittografia. Comprendi di cosa hai bisogno.

Dovrei dire che sebbene GCM abbia sia la crittografia che l'integrità del messaggio, è un design molto fragile: se riutilizzi un IV, sei fregato: l'attaccante può recuperare la tua chiave. Altri progetti sono meno fragili, quindi ho personalmente paura di raccomandare GCM in base alla quantità di codice di crittografia scadente che ho visto in pratica.

Se hai bisogno di entrambi, l'integrità dei messaggi e la crittografia, puoi combinare due algoritmi: di solito vediamo CBC con HMAC, ma nessun motivo per legarti a CBC. La cosa importante da sapere è crittografare prima, quindi MAC il contenuto crittografato , non viceversa. Inoltre, il IV deve far parte del calcolo MAC.

Non sono a conoscenza di problemi di PI.

Ora alle cose buone del professor Rogaway:

Blocca le modalità di crittografia, crittografia ma non integrità del messaggio

BCE : un blockcipher, la modalità codifica i messaggi che sono un multiplo di n bit codificando separatamente ogni pezzo n-bit. Le proprietà di sicurezza sono deboli , il metodo perde l'uguaglianza dei blocchi in entrambe le posizioni e il tempo del blocco. Di notevole valore legacy e di valore come elemento costitutivo di altri schemi, ma la modalità non raggiunge alcun obiettivo di sicurezza generalmente desiderabile a sé stante e deve essere utilizzata con notevole cautela; La BCE non dovrebbe essere considerata una modalità di riservatezza "per scopi generici" .

CBC : uno schema di crittografia basato su IV, la modalità è sicura come uno schema di crittografia probabilistico, ottenendo l'indistinguibilità dai bit casuali, assumendo un IV casuale. La riservatezza non si ottiene se l'IV è semplicemente un nonce , né se è un nonce codificato con la stessa chiave utilizzata dallo schema, come lo standard suggerisce erroneamente di fare. I ciphertexts sono altamente malleabili. Nessuna sicurezza di attacco cifrato (CCA) scelta. La riservatezza è perduta in presenza di un oracolo di imbottitura corretta per molti metodi di imbottitura. Crittografia inefficiente per essere intrinsecamente seriale. Ampiamente usato, le proprietà di sicurezza della sola privacy della modalità comportano un uso improprio frequente. Può essere utilizzato come blocco predefinito per algoritmi CBC-MAC. Non riesco a identificare alcun vantaggio importante rispetto alla modalità CTR.

CFB : uno schema di crittografia basato su IV, la modalità è sicura come uno schema di crittografia probabilistico, ottenendo l'indistinguibilità dai bit casuali, assumendo un IV casuale. La riservatezza non viene raggiunta se l'IV è prevedibile , né se viene creato da un nonce codificato con la stessa chiave utilizzata dallo schema, come lo standard suggerisce erroneamente di fare. I cifrati sono malleabili. Nessuna sicurezza CCA. Crittografia inefficiente per essere intrinsecamente seriale. Lo schema dipende da un parametro s, 1 ≤ s ≤ n, in genere s = 1 o s = 8. Inefficace per la necessità di una chiamata a blocchi di blocchi per elaborare solo i bit. La modalità raggiunge un'interessante proprietà di "auto-sincronizzazione"; l'inserimento o la cancellazione di qualsiasi numero di caratteri s-bit nel testo cifrato interrompe temporaneamente solo la decrittografia corretta.

OFB : uno schema di crittografia basato su IV, la modalità è sicura come uno schema di crittografia probabilistico, che consente di ottenere l'indistinguibilità dai bit casuali, assumendo un IV casuale. La riservatezza non viene raggiunta se l'IV è un nonce, sebbene una sequenza fissa di IV (ad es. Un contatore) funzioni correttamente. I ciphertexts sono altamente malleabili. Nessuna sicurezza CCA. La crittografia e la decrittografia sono inefficienti dall'essere intrinsecamente seriali. Crittografa nativamente stringhe di qualsiasi lunghezza di bit (nessuna imbottitura necessaria). Non riesco a identificare alcun vantaggio importante rispetto alla modalità CTR.

CTR : uno schema di crittografia basato su IV, la modalità raggiunge l'indistinguibilità dai bit casuali assumendo un nonce IV. Come uno schema sicuro non-based, la modalità può anche essere utilizzata come uno schema di crittografia probabilistico, con un IV casuale. Completo fallimento della privacy se un nonce viene riutilizzato per crittografia o decrittografia. La parallelizzabilità della modalità spesso la rende più veloce, in alcune impostazioni molto più velocemente, rispetto ad altre modalità di riservatezza. Un elemento importante per gli schemi di crittografia autenticata. Nel complesso, di solito è il modo migliore e più moderno per ottenere la crittografia solo della privacy.

XTS : uno schema di crittografia basato su IV, la modalità funziona applicando una blockcipher ottimizzabile (sicura come un PRP forte) a ogni blocco n-bit. Per i messaggi con lunghezze non divisibili per n, gli ultimi due blocchi vengono trattati in modo speciale. L'unico utilizzo consentito della modalità è la crittografia dei dati su un dispositivo di archiviazione strutturato a blocchi. La larghezza ridotta del PRP sottostante e il cattivo trattamento dei blocchi finali frazionari sono problemi. Sarebbe più efficiente ma meno desiderabile di una blockcipher protetta da PRP (a blocco largo).

MAC (integrità del messaggio ma non crittografia)

ALG1–6 : una raccolta di MAC, tutti basati sul CBC-MAC. Troppi schemi. Alcuni sono dimostrabili come PRF VIL, altri come PRF FIL e altri non hanno una sicurezza dimostrabile. Alcuni schemi ammettono attacchi dannosi. Alcune delle modalità sono datate. La separazione delle chiavi è inadeguatamente gestita per le modalità che lo hanno. Non dovrebbe essere adottato in massa, ma è possibile scegliere selettivamente i "migliori" schemi. Sarebbe anche bene adottare nessuna di queste modalità, a favore del CMAC. Alcuni dei MAC ISO 9797-1 sono ampiamente standardizzati e utilizzati, specialmente nel settore bancario. Una versione rivista dello standard (ISO / IEC FDIS 9797-1: 2010) sarà presto rilasciata [93].

CMAC : un MAC basato sul CBC-MAC, la modalità è decisamente sicura (fino al limite del compleanno) come PRF (VIL) (supponendo che il blockcipher sottostante sia un buon PRP). Spese generali sostanzialmente minime per uno schema basato su CBCMAC. La natura intrinsecamente seriale di un problema in alcuni domini applicativi e l'uso con una blockcipher a 64 bit richiederebbe occasionalmente una nuova codifica. Più pulito della raccolta ISO 9797-1 di MAC.

HMAC : un MAC basato su una funzione hash crittografica piuttosto che su una blockcipher (sebbene la maggior parte delle funzioni hash crittografiche siano esse stesse basate su blockcipher). Il meccanismo gode di forti limiti di sicurezza dimostrabile, sebbene non da ipotesi preferite. Molteplici varianti strettamente correlate in letteratura complicano la comprensione di ciò che è noto. Non sono mai stati suggeriti attacchi dannosi. Ampiamente standardizzato e usato.

GMAC : un MAC non-based che è un caso speciale di GCM. Eredita molte delle caratteristiche buone e cattive di GCM. Ma un non-requisito non è necessario per un MAC, e qui offre pochi vantaggi. Attacchi pratici se i tag vengono troncati a ≤ 64 bit e l'estensione della decrittazione non viene monitorata e ridotta. Errore completo in caso di non riutilizzo. L'uso è implicito comunque se viene adottato GCM. Non raccomandato per la standardizzazione separata.

crittografia autenticata (sia crittografia che integrità del messaggio)

CCM : uno schema AEAD basato su nonce che combina la crittografia in modalità CTR e il CBC-MAC non elaborato. Inerentemente seriale, limitando la velocità in alcuni contesti. Sicuro, con buoni limiti, supponendo che la blockcipher sottostante sia un buon PRP. Costruzione sgraziata che dimostra chiaramente il lavoro. Più semplice da implementare rispetto a GCM. Può essere utilizzato come MAC non basato suce. Ampiamente standardizzato e usato.

GCM : uno schema AEAD basato su nonce che combina la crittografia in modalità CTR e una funzione hash universale basata su GF (2128). Buone caratteristiche di efficienza per alcuni ambienti di implementazione. Buoni risultati provabili e sicuri che presuppongono il minimo troncamento dei tag. Attacchi e scarsi limiti di sicurezza dimostrabili in presenza di sostanziali troncamenti dei tag. Può essere utilizzato come MAC non basato suce, che viene quindi chiamato GMAC. Scelta discutibile per consentire nonces diversi da 96 bit. Consiglia di limitare i nonces a 96 bit e i tag ad almeno 96 bit. Ampiamente standardizzato e usato.

1. Tutto tranne la BCE.
2. Se si utilizza CTR, è indispensabile utilizzare un IV diverso per ciascun messaggio, altrimenti si finisce con l'attaccante in grado di prendere due cifrari e derivare un testo in chiaro non crittografato combinato. Il motivo è che la modalità CTR essenzialmente trasforma una cifra di blocco in una cifra di flusso e la prima regola delle cifre di flusso è di non usare mai la stessa chiave + IV due volte.
3. Non c'è davvero molta differenza nella difficoltà delle modalità di implementazione. Alcune modalità richiedono solo che il codice a blocchi funzioni nella direzione di crittografia. Tuttavia, la maggior parte dei cifrari a blocchi, incluso AES, non richiede molto più codice per implementare la decrittazione.
4. Per tutte le modalità di cifratura, è importante utilizzare IV diversi per ciascun messaggio se i messaggi potrebbero essere identici nei primi byte diversi e non si desidera che un utente malintenzionato lo sappia.

Hai iniziato leggendo le informazioni su questo su Wikipedia - Blocca le modalità di funzionamento della crittografia ? Quindi seguire il link di riferimento su Wikipedia a NIST: Raccomandazione per le modalità operative di Block Cipher .

Potresti voler scegliere in base a ciò che è ampiamente disponibile. Ho avuto la stessa domanda e qui ci sono i risultati della mia ricerca limitata.

Limitazioni hardware

STM32L (low energy ARM cores) from ST Micro support ECB, CBC,CTR GCM
CC2541 (Bluetooth Low Energy) from TI supports ECB, CBC, CFB, OFB, CTR, and CBC-MAC

Limitazioni dell'open source

Original rijndael-api source  - ECB, CBC, CFB1
OpenSSL - command line CBC, CFB, CFB1, CFB8, ECB, OFB
OpenSSL - C/C++ API    CBC, CFB, CFB1, CFB8, ECB, OFB and CTR
EFAES lib [1] - ECB, CBC, PCBC, OFB, CFB, CRT ([sic] CTR mispelled)  
OpenAES [2] - ECB, CBC 

[1] http://www.codeproject.com/Articles/57478/A-Fast-and-Easy-to-Use-AES-Library

[2] https://openaes.googlecode.com/files/OpenAES-0.8.0.zip

Conosco un aspetto: sebbene CBC offra una migliore sicurezza modificando il IV per ciascun blocco, non è applicabile ai contenuti crittografati a accesso casuale (come un disco rigido crittografato).

Quindi, utilizzare CBC (e le altre modalità sequenziali) per flussi sequenziali ed ECB per l'accesso casuale.