Ci sono conseguenze effettive degli attacchi degli oracoli imbottiti?
Sto scrivendo un programma che crittografa i dati in Python e ho sentito parlare di attacchi Oracle di riempimento , ma penso che siano sopravvalutati (voglio dire, quali sono gli usi nel mondo reale?) Anche per le vecchie implementazioni che sono vulnerabili (quelle che dicono se il riempimento è giusto o sbagliato come SSLv3).
Perché:
- Se tutto ciò di cui ho bisogno sono due testi cifrati $c(n-1)$, $c(n)$ quali sono gli ultimi due blocchi di messaggi crittografati e un server per dirmi se il riempimento di decrypted $c(n)$è corretto o qualsiasi altra cosa, non significa che il server decifra semplicemente tutto ciò che gli invii (voglio dire, invia l'intero messaggio crittografato come lo hai ricevuto e leggi l'output). Voglio dire, questo è il bug del server che non richiede una chiave in primo luogo e controlla se è corretto.
- Supponiamo che tutto ciò che dobbiamo fare sia inviare quei due messaggi cifrati per conoscere e decifrare l'ultimo blocco (il blocco di riempimento). Funziona solo poiché il riempimento del testo in chiaro è noto o almeno non casuale o per qualsiasi motivo.
Ma che dire, diciamo, c2 e c3 che sono al centro dell'intero messaggio? Conosciamo c3 e c2, ma non sappiamo e non sapremo mai né p3 né p2 (testo in chiaro), né lo stato intermedio IS3 ; cioè non possiamo XOR c2 con is3 per ottenere p3 , quindi questo attacco penso ci consenta solo di decifrare il blocco di riempimento con l'unica cosa nuova che sapevamo effettivamente è uno stato intermedio di blocco di riempimento.
Chiedo di sapere se questo attacco è solo un attacco senza implicazioni nel mondo reale e senza capacità di decrittografia dei dati reali (dati effettivi).
Risposte
Voglio dire che questo è il bug del server che non richiede una chiave in primo luogo e controlla se è corretto :)
Cosa intendi con questo? La chiave deve essere quella giusta e gli attacchi dell'oracolo di riempimento cambiano effettivamente il testo cifrato crittografato con quella chiave sull'altro lato per eseguire l'attacco.
ma che dire di c2, c3 che sono nel mezzo dell'intero messaggio, conosciamo c3 e c2 ma non lo sappiamo e non sapremo mai né p3 (testo in chiaro ovviamente) né lo stato intermedio IS3
No, un attacco oracolo di riempimento è in grado di decrittografare completamente un messaggio. Questo è precisamente perché lo XOR influenza il blocco successivo.
Nota che gli attacchi di oracoli di riempimento sono solo una forma di attacco di oracoli in chiaro . Ad esempio, puoi anche eseguire attacchi Oracle in testo normale su XML-enc, anche senza utilizzare il riempimento stesso.
Chiedo di sapere se questo attacco è solo un attacco senza implicazioni nel mondo reale e senza capacità di decrittografia dei dati reali (dati effettivi).
Sì, è completamente e completamente sbagliato. Un attacco oracolo di riempimento può decrittografare l'intero messaggio utilizzando 128 tentativi per byte e altri oracoli di testo in chiaro possono effettivamente essere ancora più efficaci.
Inoltre, il fatto che il destinatario accetti un testo in chiaro modificato è forse pericoloso quanto perdere la riservatezza. Per questo motivo è necessario utilizzare la crittografia autenticata, o meglio un protocollo che utilizza la crittografia autenticata invece di CBC non autenticato.
Chiedo di sapere se questo attacco è solo un attacco senza implicazioni nel mondo reale e senza capacità di decrittografia dei dati reali (dati effettivi).
L' attacco Lucky Thirteen è un attacco del mondo reale contro TLS. Era un grave attacco per le versioni allora attuali del protocollo TLS (TLS 1.0 all'epoca - TLS 1.1 e 1.2 esistevano ma avevano pochissima adozione). Quindi no, il riempimento degli attacchi oracolari funziona assolutamente nel mondo reale.
(quelli che dicono se il riempimento è giusto o sbagliato come sslv3).
Lucky Thirteen interessa le versioni fino a TLS 1.2, che è la versione utilizzata oggi per la maggior parte delle comunicazioni protette. Interessa solo le suite di crittografia che utilizzano CBC, che sono deprecate proprio a causa di questo attacco, ma la maggior parte degli endpoint lo consente ancora, anche se preferiranno le suite di crittografia AEAD. Molte ma non tutte le implementazioni TLS popolari hanno un codice che impedisce l'attacco Lucky Thirteen (a scapito delle prestazioni). Quindi no, il riempimento degli attacchi Oracle è rilevante per i protocolli che sono ancora ampiamente utilizzati.
Sto scrivendo un programma che crittografa i dati in Python e ho sentito parlare di attacchi Oracle di riempimento, ma penso che siano sopravvalutati
Bene, è vero che non dovresti preoccuparti di imbottire gli attacchi degli oracoli. Ma il motivo per cui non dovresti preoccuparti è che dal momento che sono conosciuti, sappiamo come difenderti da loro: non usare il padding. E nessuna modalità moderna di crittografia utilizza il riempimento. Usa una qualsiasi modalità AEAD comune, come GCM, CCM o ChaCha20 + Poly1305. O ancora meglio, usa una libreria di alto livello come NaCl / libsodium ( PyNaCl in Python): se stai digitando le lettere AES nel tuo codice, stai sbagliando .