Il codice di flusso / blocco aggiunge un semplice hash per garantire l'integrità

Perché non garantisce l'integrità è più facile da vedere nel caso di un codice di flusso come RC4, in cui la crittografia è un XOR bit-by-bit dei dati con un flusso dipendente dalla chiave. Fondamentalmente, la crittografia del messaggio m è: e = m XOR s _k , dove s _k è l'uscita RC4 (un lungo flusso di bit pseudocasuali prodotti dalla chiave k ). Supponiamo che applichi il metodo "aggiungi hash quindi crittografa". Inizi con il messaggio m e ottieni questo:

e = ( m || h ( m )) XOR s _k

Ora arriva un aggressore, ed è intelligente, e indovina il contenuto di m (ricorda: l'attaccante è dopo l'integrità, non la riservatezza, quindi assumiamo che conosce già il messaggio). Poiché una funzione hash non ha chiave, l'attaccante può ricalcolare m || h ( m ). Da ciò ottiene:

s _k = ( m || h ( m )) XOR e

Ora l'attaccante ha il flusso segreto dipendente dalla chiave s _k . Quindi procede a crittografare il suo falso messaggio m ' calcolando:

e ' = ( m' || h ( m ')) XOR s _k

Questo funziona quando m non è più lungo di m (potrebbe essere più breve). Al momento della decodifica, l'hash si abbina e l'integrità viene sconfitta. Curiosità: Conosco un sistema per l'online banking basato sul Web che utilizzava questa costruzione per l'integrità ed è stato ampiamente implementato. Fortunatamente, è stato corretto più di dieci anni fa.

Il problema è che l'hashing non fornisce nulla in termini di integrità nello scenario. Si sta facendo affidamento sulla sola crittografia per affermare l'integrità. Se ottengo una sospensione del messaggio e lo decrypt, posso modificare il messaggio, ricalcolare l'hash, crittografarlo di nuovo e trasmetterlo.

Se ritieni che la sola crittografia fornisca integrità, allora questo processo funziona, ma l'hashing non ha senso.