Gli attacchi di oracle di riempimento si verificano quando l'utente malintenzionato è in grado di inviare messaggi crittografati e osservare il proprietario della chiave quando tenta di decrittografarli. L'utente malintenzionato fornisce quindi messaggi appositamente predisposti (basati su una parte dei dati crittografati che l'utente malintenzionato vorrebbe vedere decrittografati) che decifrano la posta indesiderata, ma a volte decodificano la posta indesiderata con il padding valido; in questi casi, l'utente malintenzionato scopre alcune informazioni sui dati che sta cercando.
Se ci si trova in un contesto in cui il defender è un server che calcola se stesso tutta la crittografia e la decrittografia, e i messaggi crittografati non possono essere alterati dagli attaccanti, la situazione sopra descritta non si presenta e gli attacchi oracle di riempimento sono irrilevanti. / p>
Quindi, nel tuo caso, dovresti essere al sicuro da questi attacchi, a condizione che le persone maligne anzi non possano mettere le mani sul tuo database pieno di messaggi crittografati. Ciò solleva la questione del perché si dovrebbero crittografare i dati - di solito, si crittografa i dati per ottenere una certa riservatezza che non è possibile ottenere in altro modo. Pertanto, la crittografia sul server ha senso solo se si presume che gli hacker siano in grado di dare almeno un'occhiata ai contenuti del database. In molte situazioni in cui gli utenti malintenzionati possono vedere dati, possono anche modificare i dati; e questo porterebbe indietro il problema degli attacchi di oracle di riempimento, o, più in generale, la necessità di integrità controllata.
Per dirla chiaramente, se si cifrano i dati ma non si fa alcuno sforzo per mantenere l'integrità (con una modalità di crittografia autenticata MAC o nifty), allora si scommette che i possibili attacchi di SQL iniezioni sul server saranno di sola lettura . Spetta a te decidere se ti senti abbastanza sicuro con quella scommessa.