Perché un hash crittografico all'interno di un crittogramma non può fungere da MAC? [duplicare]

Question

Perché un hash crittografico all'interno di un crittogramma non può fungere da MAC? [duplicare]

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

5

La mia domanda è strettamente correlata a Perché hai bisogno dell'autenticazione dei messaggi oltre alla crittografia?

In particolare sono interessato alla crittografia a chiave simmetrica. Comprendo che gli autori di attacchi possono modificare i messaggi crittografici e la decrittografia risultante sarà un messaggio alterato, i MAC sono progettati per risolvere questo problema. I leggi che uno dovrebbe crea il crittogramma, quindi genera un MAC dal crittogramma e invialo insieme.

La mia domanda è: perché non è possibile semplicemente aggiungere il messaggio originale non crittografato con un hash crittografico del messaggio originale e quindi crittografarlo insieme? Quindi il ricevitore potrebbe decifrare entrambi e verificare l'hash. Se il crittogramma è stato modificato, l'hash interno non corrisponderebbe più e non sarebbe difficile modificare il messaggio e / o l'hash interno in modo tale che rimangano coerenti poiché sono entrambi crittografati?

hmac

posta satur9nine 03.10.2014 - 07:53

fonte

3 risposte

Leggi altre domande sui tag hmac

In che misura Google può accedere ai dati nelle posizioni di archiviazione Android standard senza limitazioni? Come controllo se uno script è sicuro da eseguire?

score 1 · Answer 1

Aggiungere l'hash e quindi crittografare l'intero lotto non è necessariamente sicuro. In realtà, a seconda del sistema di crittografia, potrebbe essere terribilmente debole. Ad esempio, supponiamo che la crittografia venga eseguita con un codice di flusso come RC4: la crittografia viene eseguita da XORing con un flusso pseudocasuale dipendente dalla chiave. Quindi, l'attaccante vede questo:

E = ( m || h ( m )) XOR S ( K )

dove m è il messaggio, h è la funzione di hash, e S ( K ) è il flusso pseudocasuale generato dalla chiave K . Se l'attaccante indovina il valore di m (dal contesto), allora può ricalcolare h ( m ), e quindi ottenere:

S ( K ) = ( m || h ( m )) XOR E

Quindi, l'attaccante sceglie il proprio messaggio m ', con contenuti arbitrari, e invia:

E ' = ( m' || h ( m ')) XOR S ( K )

e voilà! L'integrità è stata sconfitta.

score 0 · Answer 2

Ho appena preso confidenza con l'attacco Oracle di Padding descritto nell'articolo che hai collegato, e credo che tu abbia risposto alla tua stessa domanda. Se l'attacco di Padding Oracle può portare alla scoperta completa del testo in chiaro, crittografando il messaggio di messaggio non crittografato E l'hash richiederebbe ancora il riempimento e quindi renderlo vulnerabile alla scoperta.

Per implementare entrambi, probabilmente vorresti hash il messaggio originale, aggiungerli insieme, crittografarlo e quindi eseguire l'hashing del testo cifrato risultante e aggiungerlo alla tua combinazione crittografata. Ciò otterrebbe ciò che desideri, ma sembra che funzioni molto quando la soluzione originale sembra perfettamente accettabile.

score 0 · Answer 3

Da un lato, è inefficiente. Il ricevitore dovrebbe passare tutto il lavoro di ricerca della chiave, decifrare il messaggio prima di apprendere se valesse la pena decifrarlo.

Allo stesso modo, aumenta il rischio. Se il MAC non calcola, il ricevitore non recupererebbe mai nemmeno le chiavi necessarie per decrittografare il messaggio, e il ricevitore non avrebbe mai il proprio carico utile. Questo potrebbe essere fondamentale se il carico utile fosse dannoso.

Considera questo scenario. Supponiamo che la tua applicazione sia un servizio web che accetta nuovi disegni di artisti di tutto il mondo che lavorano per te. Tutti i tuoi artisti hanno ricevuto le chiavi per firmare il loro lavoro e usano la tua chiave pubblica per crittografarli per inviarli a te. E diciamo che il tuo server era vulnerabile a file WMF dannosi.

Sono un utente malintenzionato, quindi realizzo un WMF dannoso, creo alcuni byte casuali per il MAC, crittografa il file e lo carica sul tuo server. Il server decrittografa il file WMF e lo salva per calcolare il MAC. Ma lo strumento di indicizzazione del tuo server legge il WMF intermedio ed esegue il malware contenuto nell'anteprima, e quindi ti viene comunque violato. * Nota che questo succede anche se non hai ancora verificato il MAC.

Se prima hai controllato il MAC, non avresti decodificato il payload e non ti saresti esposto al malware nel file WMF.

* Sì, l'indicizzatore che veniva compromesso dai file WMF era una vera vulnerabilità su Windows. È assurdo presumere che un sistema sia perfettamente privo di tutte le vulnerabilità.