Ci sono già un paio di domande su come confrontare Hash e MAC, ma ho cercato e non ho trovato risposta alla mia domanda.
Di solito inviamo "Encrypt (M, k) || MAC (M, K)" in modo che il ricevitore possa controllare l'integrità e l'autenticazione del messaggio.
Ma sembra che "Encrypt (M, k) || Hash (M)" funzioni allo stesso modo. Questo schema per l'autenticazione dei messaggi è vulnerabile?
Si noti che persino Enifypt-and-MAC (cioè Encrypt(M, k) || MAC(M, K) ) ha vulnerabilità. Se l'autore dell'attacco conosce un certo numero di possibili testi in chiaro che il messaggio potrebbe eventualmente contenere, allora può capire il contenuto di un messaggio confrontandolo con il MAC / hash di testo in chiaro noto. Anche Encrypt-and-Hash soffre della stessa vulnerabilità, ed è molto più semplice poiché l'attaccante può generare i propri hash calcolando l'hash di testi simili piuttosto che dover intercettare messaggi precedenti con contenuti identici.
Ad esempio, se sai che Alice invia sempre a Bob un messaggio ogni 6AM una delle tre possibili scelte di caffè: "Il caffè di oggi è Cappuccino / Nero / Moccacino", quindi se l'hash del messaggio corrisponde a uno di questi, si conosci la scelta del caffè di Alice.
Con MAC, dovrai abbinarlo a un testo in chiaro noto precedente oa un "oracle" (che può generare messaggi crittografati con il testo in chiaro scelto). Questo è chiamato attacco di testo normale scelto .
La best practice attualmente accettata è Encrypt-then-MAC (cioè Encrypt(M, k) || MAC(Encrypt(M, k), K) ).
Quindi la domanda diventa, perché non sostituirla con Encrypt-then-hash: Encrypt(M, k) || Hash(Encrypt(M, k)) è ovvio. Poiché chiunque può calcolare l'hash della parte crittografata, questo hash in realtà non fornisce l'autenticazione.
Bonus: un'altra possibile costruzione è MAC-then-Encrypt (cioè Encrypt(MAC(M, K), k) ), questo è vulnerabile agli attacchi che modificano il testo crittografato, che probabilmente produrrà spazzatura sul server e verrà rifiutato a causa dell'hash non corretto, ma può ancora fornire informazioni utili all'attaccante. Uno di questi attacchi è il riempimento di oracle attack . Hash-then-Encrypt è vulnerabile allo stesso attacco.
Suggerisco di leggere gli argomenti della crittografia autenticata o della crittografia autenticata con i dati associati.
Proprio come hai aggiunto il tag autenticazione alla tua domanda, questa è in realtà la risposta. Il MAC implica un'informazione che dovrebbe essere nota solo alle parti che stanno comunicando: la chiave. Se abbinati alla crittografia (come nelle tue domande), i MAC vengono utilizzati con la crittografia simmetrica, pertanto la chiave deve essere la stessa e conosciuta solo dalle due parti che comunicano.
Contrariamente a un semplice hash (che fornisce integrità ) un MAC fornisce anche autenticazione .
(Nella crittografia asimmetrica le firme digitali forniscono queste funzionalità.)
Questo non è estremamente importante quando si esegue la crittografia poiché un utente malintenzionato avrebbe comunque bisogno del messaggio decrittografato per generare l'hash. La parte autenticazione del MAC è molto più importante nella comunicazione non crittografata.
Inferno, supponendo che K sia la chiave di un blocco di cifratura e M il testo in chiaro quindi:
Encrypt(M, K) || MAC(M, K) Encrypt(M, K) || Hash(M || K) Sono equivalenti al significato di alto livello. Poiché un hash crittografico che riceve una chiave segreta come input è un modo valido per generare un MAC.
Leggi altre domande sui tag authentication cryptography hash