Blocca le modalità di concatenamento da evitare

OFB e CTR trasformano il cifrario a blocchi in un codice di flusso. Ciò significa che è necessario prestare attenzione quando li si utilizza, come per RC4 ; riutilizzare lo stesso flusso per crittografare due messaggi distinti è un peccato mortale. OFB è più "delicato" in questa materia. Poiché OFB consiste nel crittografare ripetutamente lo stesso valore, è, in pratica, un'esplorazione di un ciclo di permutazione : l'IV seleziona un punto e OFB cammina i cicli che contengono questo punto. Per un codice a blocchi con bit n di blocco, la dimensione media di un ciclo dovrebbe essere intorno a 2 ^{n / 2} e se si cripta più di questo, si inizia a ripetere un segmento precedente del flusso e ciò è negativo. Questo può essere un grosso problema quando n = 64 (ad esempio, usi 3DES). Inoltre, questa è una media: puoi, per fortuna (cattiva), colpire un ciclo più piccolo; inoltre, se si cifrano due messaggi con la stessa chiave ma con IV distinta, è possibile (di nuovo se sfortunato) eseguire lo stesso ciclo rispetto a prima (solo in un punto diverso).

Il punto negativo di OFB è che è difficile verificare queste occorrenze (se l'implementazione include il codice necessario, può verificare se si verificano queste situazioni indesiderate, ma ciò non può essere fatto in anticipo , solo quando parte della crittografia è già stata eseguita). Per CTR, le cose sono più facili: CTR è la crittografia dei successivi valori di contatore; i problemi iniziano quando un valore contatore viene riutilizzato. Ma un comportamento da contatore è facile da prevedere (dopotutto è un contatore), quindi è molto più facile garantire che i successivi messaggi crittografati con la stessa chiave utilizzino intervalli distinti di valori contatore.

Inoltre, durante la crittografia con CTR, l'output inizia a distinguersi dal puro casuale dopo circa 2 ^{n / 2} , ma raramente è letale. È una preoccupazione ed è sufficiente per giustificare l'uso di codici a blocchi con blocchi grandi (ad es. AES con blocchi a 128 bit anziché 3DES e relativi blocchi a 64 bit), ma si tratta di un degrado di sicurezza più aggraziato rispetto a quanto avviene con OFB.

Per riassumere, non utilizzare OFB; usa CTR invece . Questo non rende il CTR facile da usare in sicurezza, solo più facile. Per evitare di comprometterlo, dovresti provare a usarne uno se usi le modalità di crittografia autenticate che fanno le cose correttamente e includono il controllo dell'integrità, una componente necessaria ma spesso trascurata. EAX e GCM sono le mie modalità AE preferite (EAX sarà più veloce su piccole architetture con cache L1 limitata, GCM sarà più veloce su x86 moderno, specialmente quelli con AES opcodes che sono stati definiti solo per quello).

A mia conoscenza, CFB non soffre tanto quanto OFB dai problemi di lunghezza del ciclo, ma la crittografia di una lunga sequenza di zeri con CFB è equivalente a OFB; pertanto, sembra più sicuro di preferire CTR su CFB .

Quasi tutti i modi operativi di cifratura a blocchi hanno problemi nel raggiungere la barriera 2 ^{n / 2} , quindi è saggio usare comunque blocchi a 128 bit.

Nota: CFB e OFB hanno una "lunghezza di feedback" opzionale. Di solito, utilizziamo il feedback a blocco completo, perché questo è ciò che garantisce le massime prestazioni (produzione di n bit di testo cifrato per invocazione del codice a blocchi). Sono state anche definite modalità con feedback più piccoli, ad es. CFB-8 che crittografa solo un byte alla volta (quindi è 8 volte più lento del blocco CFB completo quando si utilizza un codice a 64 bit a blocchi). Tali modalità non sono altrettanto supportate dalle librerie esistenti; inoltre, i piccoli anelli di feedback rendono le questioni OFB peggiori. Pertanto, non raccomando di utilizzare CFB o OFB sarà inferiore al feedback di blocco completo.

Come sottolineato da @Rook: modalità CBC, come ECB ma a differenza di CFB, OFB e CTR, elabora solo blocchi completi, quindi richiede padding . Il riempimento può implicare riempire gli attacchi di oracolo , il che è sbagliato (probabilmente, un attacco di oracle di riempimento è possibile solo se non viene utilizzato un MAC, o è applicato male, il modo corretto di essere crittografato-poi-MAC). Per questo motivo, le modalità senza padding sono preferibili su CBC.

Questo ci porta ad una chiara vittoria del CTR rispetto ad altre modalità, CFB al secondo posto, poi CBC e OFB in parità, poi ECB (questo è un po 'soggettivo, ovviamente). Ma, davvero, usa EAX o GCM.

La modalità di funzionamento dipende interamente da come vengono utilizzati i dati. Lascia che le tue minacce definiscano la soluzione.

Ad esempio, le modalità autenticate come GCM e CCM sono davvero eleganti e le uso nei miei progetti per evitare Oracoli crittografici. Ma non hai sempre bisogno di una modalità autenticata. Ad esempio se hai bisogno di memorizzare molti piccoli record nel database e la modifica del testo cifrato non è un problema, allora una modalità autenticata non è lo strumento giusto.

Molti database si basano sulla modalità ECB e questa non è sempre una vulnerabilità. Ad esempio, se si sta memorizzando solo un singolo blocco e tale blocco contiene sempre un valore casuale come un ID sessione o un token di reimpostazione password, gli attacchi alla modalità ECB non entrano in gioco. Utilizzando la modalità ECB, il database può effettuare ricerche molto più velocemente, perché sai che esiste sempre una relazione 1: 1 tra testo in chiaro e testo cifrato.

Nota anche che, usando la modalità ECB, non sei preda degli attacchi CBC-R e Padding Oracle che influenzano la modalità CBC! Usando la modalità CBC su ECB puoi rendere un meno sicuro di sistema. È proprio così che in molti casi la modalità ECB è probabilmente la scelta sbagliata.

Sì. La migliore risposta a questa domanda è rimuovere la domanda. Per la maggior parte delle situazioni, non dovresti usare la crittografia in un modo che ti obbliga a scegliere la tua modalità operativa; se lo fai, ci sono troppi modi in cui puoi rovinare . Ad esempio, molte persone che lo fanno si dimenticano di autenticare correttamente i dati, il che è un problema.

Al contrario, è generalmente meglio utilizzare uno strumento o una libreria di alto livello . Per citare la mia risposta altrove:

Your best case is to use a high-level well-vetted scheme: for communication security, use TLS (or SSL); for data at rest, use GPG (or PGP). If you can't do that, use a high-level crypto library, like cryptlib, GPGME, Keyczar, or NaCL, instead of a low-level one, like OpenSSL, CryptoAPI, JCE, etc.