it-swarm.dev

Qual è la migliore modalità di cifratura e riempimento per la crittografia AES?

Secondo il requisito PCI-DSS 3.4:

Per l'archiviazione dei dati della carta di credito è necessario utilizzare la crittografia avanzata .

Ho deciso di utilizzare AES Encryption che è una crittografia forte e principalmente consigliata per crittografare i dettagli della carta di credito.

Ho visto che AES ha la modalità Cipher e la modalità di riempimento.

Quando ho cercato ho scoperto che secondo Pubblicazione speciale NIST 800-38A , specifica cinque modalità operative di riservatezza per l'algoritmo di crittografia a chiave simmetrica.

Quindi sono totalmente confuso se posso usare una qualsiasi delle cinque modalità di cifratura o c'è una delle cinque tra quelle elencate di seguito:

Modalità di cifratura:

  1. BCE
  2. CBC
  3. OFB
  4. CFB
  5. CTR

Qual è la migliore modalità di cifratura tra le cinque?

Qual è anche la migliore modalità di riempimento per la crittografia AES?

26
RajeshKannan

"Best" è piuttosto soggettivo, dipende dalle tue esigenze. Detto questo, ti darò una panoramica generale di ciascuna modalità.

[~ # ~] ecb [~ # ~] - Rubrica elettronica. Questa modalità è la più semplice e trasforma ciascun blocco separatamente. Ha solo bisogno di una chiave e di alcuni dati, senza extra aggiunti. Sfortunatamente fa schifo - per cominciare, blocchi di testo normale identici vengono crittografati in blocchi di testo cifrato identici quando vengono crittografati con la stessa chiave. L'articolo di Wikipedia ha una grande rappresentazione grafica di questo fallimento.

Aspetti positivi: molto semplice, la crittografia e la decrittografia possono essere eseguite in parallelo.

Aspetti negativi: orribilmente insicuro.

[~ # ~] cbc [~ # ~] - Cipher Block Chianing. Questa modalità è molto comune ed è considerata ragionevolmente sicura. Ogni blocco di testo in chiaro è xorato con il precedente blocco di testo cifrato prima di essere trasformato, assicurando che blocchi identici di testo normale non risultino in blocchi di testo cifrato identici quando in sequenza. Per il primo blocco di testo in chiaro (che non ha un blocco precedente) usiamo invece un vettore di inizializzazione. Questo valore deve essere univoco per messaggio per chiave, per garantire che messaggi identici non generino codici cifrati identici. CBC è utilizzato in molte suite di crittografia SSL/TLS.

Sfortunatamente, ci sono attacchi contro CBC quando non viene implementato insieme a una serie di forti controlli di integrità e autenticità. Una proprietà che possiede è la malleabilità a livello di blocco, il che significa che un utente malintenzionato può modificare il testo in chiaro del messaggio in modo significativo senza conoscere la chiave, se riesce a pasticciare con il testo cifrato. Pertanto, le implementazioni di solito includono un record di autenticità basato su HMAC. Questo è un argomento difficile, perché anche l'ordine in cui si esegue l'HMAC e la crittografia può causare problemi: cercare "MAC, quindi crittografare" per dettagli cruenti sull'argomento.

Aspetti positivi: sicuro se usato correttamente, decrittazione parallela.

Punti negativi: nessuna crittografia parallela, suscettibile agli attacchi di malleabilità quando i controlli di autenticità sono cattivi/mancanti. Ma una volta fatto bene, è molto buono.

[~ # ~] ofb [~ # ~] - Feedback sull'output. In questa modalità si crea essenzialmente un codice di flusso. Il IV (un valore univoco e casuale) è crittografato per formare il primo blocco di flusso di chiavi, quindi quell'output è xor'ed con il testo in chiaro per formare il testo cifrato. Per ottenere il blocco successivo di flusso di chiavi, il blocco precedente di flusso di chiavi viene nuovamente crittografato, con la stessa chiave. Questo viene ripetuto fino a quando non viene generato un flusso di chiavi sufficiente per l'intera lunghezza del messaggio. Questo va bene in teoria, ma in pratica ci sono domande sulla sua sicurezza. Le trasformazioni di blocco sono progettate per essere sicure quando eseguite una volta, ma non vi è alcuna garanzia che E (E (m, k), k) sia sicuro per ogni cifra di blocco indipendente in modo indipendente - potrebbe esserci strano interazioni tra primitivi interni che non sono stati studiati correttamente. Se implementato in modo da fornire un feedback parziale del blocco (ovvero solo una parte del blocco precedente viene acquistato in avanti, con un valore statico o debolmente casuale per l'altra metà), emergono altri problemi, come un breve ciclo di flusso chiave. In generale dovresti evitare OFB.

Aspetti positivi: Keystream può essere calcolato in anticipo, implementazioni hardware veloci disponibili

Aspetti negativi: il modello di sicurezza è discutibile, alcune configurazioni portano a brevi cicli di flusso di chiavi

[~ # ~] cfb [~ # ~] - Feedback cifrato. Un'altra modalità di cifratura del flusso, abbastanza simile a CBC eseguita al contrario. Il suo principale vantaggio è che è necessaria solo la trasformazione di crittografia, no la trasformazione di decrittografia, che consente di risparmiare spazio durante la scrittura di codice per dispositivi di piccole dimensioni. È un po 'strano e non lo vedo menzionato di frequente.

Aspetti positivi: ingombro ridotto, decodifica parallela.

Punti negativi: non comunemente implementati o utilizzati.

[~ # ~] ctr [~ # ~] - Modalità contatore. Ciò implica essenzialmente la crittografia di una sequenza di numeri incrementali con prefisso un nonce ( numero usato una volta) per produrre un flusso di chiavi, e di nuovo è una modalità di cifratura dello stream. Questa modalità elimina i problemi di eseguire ripetutamente trasformazioni l'una sull'altra, come abbiamo visto in modalità OFB. È generalmente considerata una buona modalità.

Aspetti positivi: sicurezza se eseguita correttamente, crittografia e decrittografia parallele.

Aspetti negativi: non molti. Alcuni mettono in dubbio la sicurezza del modello di "testo in chiaro correlato", ma è generalmente considerato sicuro.


Le modalità di riempimento possono essere complicate, ma in generale suggerirei sempre il riempimento PKCS # 7, che prevede l'aggiunta di byte che rappresentano ciascuno la lunghezza del riempimento, ad es. 04 04 04 04 per quattro byte di riempimento o 03 03 03 per tre. Il vantaggio rispetto ad altri meccanismi di imbottitura è che è facile dire se l'imbottitura è corrotta: più lunga è l'imbottitura, maggiore è la possibilità di danneggiamento casuale dei dati, ma aumenta anche il numero di copie della lunghezza dell'imbottitura che hai. È anche banale convalidare e rimuovere, senza alcuna reale possibilità di imbottitura rotta in qualche modo convalidando come corretto.


In generale, attenersi a CBC o CTR, con PKCS # 7 dove necessario (non è necessario riempire le modalità di cifratura dello stream) e utilizzare un controllo di autenticità (ad esempio HMAC-SHA256) sul testo cifrato. Sia CBC che CTR vengono raccomandati da Niels Ferguson e Bruce Schneier, entrambi rispettati crittografi.

Detto questo, ci sono novità modalità! [~ # ~] eax [~ # ~] e [~ # ~] gcm [~ # ~] sono stati recentemente dato molta attenzione. GCM è stato inserito nella suite TLS 1.2 e risolve molti problemi che esistevano in CBC e stream cipher. Il vantaggio principale è che entrambi sono modalità autenticate, in quanto incorporano i controlli di autenticità nella modalità di cifratura stessa, piuttosto che doverli applicare separatamente. Questo risolve alcuni problemi con il riempimento degli attacchi Oracle e vari altri trucchi. Queste modalità non sono così semplici da spiegare (per non parlare dell'attuazione) ma sono considerate molto forti.

53
Polynomial