Ciao, ho appena iniziato a conoscere cifrari e padding, e volevo solo sapere perché è necessario il padding nella crittografia in modalità CBC, è che i blocchi siano tutti della stessa lunghezza di n bit? E perché è probabile che questa implementazione della modalità CBC utilizzando il padding fornisca un oracle di riempimento a un utente malintenzionato? Come funziona?
why is padding needed in CBC mode encryption, is it to get the blocks to all be of the same n-bit length?
Sì. I codici a blocchi (come AES) richiedono che il blocco di input sia di una certa lunghezza (128 bit nel caso di AES) e CBC utilizza blocchi di testo in chiaro come input per il codice a blocchi (dopo un passo XOR). I codici a blocchi non sono progettati per funzionare su un blocco parziale.
why is it likely that this implementation of CBC mode using padding provides a padding oracle to an attacker?
Tutti i moderni progetti di crittografia includono un "codice di autenticazione dei messaggi" (MAC) per impedire a un utente malintenzionato di manomettere il testo cifrato e IV. I MAC sono come le firme digitali sui dati - se qualcuno cerca di cambiare il testo cifrato in qualche modo, il codice di decrittografia può rilevare che è stato manomesso perché la firma non sarà più valida.
Sfortunatamente, alcune implementazioni usano MAC in modo improprio (o non del tutto). Ciò consente a un utente malintenzionato di manomettere il testo cifrato in vari modi e di osservare il suo effetto sul codice di decodifica. Crolla? Dà un errore specifico? Ecc.
Un particolare tipo di errore che è possibile osservare è un errore di riempimento. Ciò si verifica quando il testo cifrato viene decifrato e il codice di decrittografia scopre che non è stato riempito correttamente (ad esempio non è valido Padding PKCS7 ). Ciò consente a un utente malintenzionato di inviare testi cifrati modificati e scoprire se il testo in chiaro corrispondente è completato correttamente.
Ad esempio, supponiamo che l'autore dell'attacco voglia decrittografare il terzo blocco di un testo cifrato a quattro blocchi. Se l'autore dell'attacco invia un testo cifrato modificato contenente solo i primi tre blocchi, il codice di decrittografia prevede che il terzo blocco contenga il riempimento. Il codice di decifrazione ora rivelerà all'utente malintenzionato se il terzo blocco è considerato adeguatamente riempito (poiché se non lo è, restituirà un errore di riempimento). Si noti come l'autore dell'attacco ha appena appreso informazioni sul testo in chiaro! Questa potrebbe essere una piccola informazione, ma il codice di decodifica non dovrebbe mai rivelare informazioni come questa a un utente malintenzionato.
L'attacker può continuare, tuttavia, e in realtà "decifrare" il blocco byte per byte. Durante la decrittografia, il terzo blocco viene calcolato come AES-decrypt(key, ciphertext-block-3) XOR ciphertext-block-2 . Apportando modifiche al blocco secondo , l'attaccante può effettivamente influire su ciò che il terzo blocco decrittografa in!
L'attaccante inizia modificando l'ultimo byte del secondo blocco, provando diversi valori fino a quando la decrittografia non si traduce più in un errore di riempimento. Una volta che l'attaccante ne trova uno che funziona, l'attaccante può dedurre (con buona probabilità) che ciò ha causato la decodifica del terzo blocco a qualcosa che termina con 01 . Perché? Poiché ogni blocco che termina con 01 è considerato correttamente riempito, secondo PKCS7 .
Ora per la matematica: sappiamo che l'ultimo byte di AES-decrypt(key, ciphertext-block-3) XOR'd con il byte trovato = 01 . Pertanto, 01 XOR'd con l'ultimo byte trovato ci darà l'ultimo byte di AES-decrypt(key, ciphertext-block-3) . Dato che ricordiamo l'ultimo byte originale del secondo blocco, possiamo XOR con l'ultimo byte di AES-decrypt(key, ciphertext-block-3) , e questo ci darà l'ultimo byte del testo in chiaro del terzo blocco.
Con questa conoscenza, l'attaccante può procedere in modo simile per ogni byte precedente del terzo blocco, crackando ogni byte uno alla volta.
Leggi altre domande sui tag cryptography