Panoramica. La tua proposta non è sicura (vedi sotto per la crittanalisi). Ecco perché non è un'alternativa ragionevole alla crittografia autenticata.
Un po 'più di background. Perché abbiamo bisogno della crittografia autenticata? È perché la crittografia senza autenticazione non è sicura . Molti sviluppatori non lo sanno, quindi finiscono con un uso insicuro della crittografia.
È possibile utilizzare manualmente sia un algoritmo di crittografia che un algoritmo di autenticazione. Ad esempio, puoi utilizzare la struttura di crittografia e autenticazione () utilizzando uno schema di crittografia sicuro e un'autenticazione sicura dei messaggi ( Algoritmo MAC). Tuttavia, ciò richiede uno sforzo extra da parte dello sviluppatore.
La crittografia autenticata è stata concepita come una singola primitiva che è facile da usare per gli sviluppatori e che fornisce tutta l'autenticazione necessaria (quindi non devi fare qualcosa in più per fornire sicurezza). Pertanto, è utile per la sicurezza. Alcuni schemi di crittografia autenticati offrono anche il vantaggio di prestazioni migliori rispetto alla crittografia separata e all'autenticazione, ma questa è una considerazione secondaria.
Leggi Non utilizzare la crittografia senza autenticazione per ulteriori dettagli su questo argomento.
Crittografia del tuo schema. Hai proposto di aggiungere un hash del messaggio prima della crittografia: in altre parole, C = Encrypt ( K , M || H (M) ), dove || rappresenta la concatenazione di stringhe di bit. Questo schema non è sicuro contro gli attacchi con testo in chiaro, con molti algoritmi di crittografia. Ad esempio, mostrerò un attacco contro la tua proposta, se stai usando la crittografia in modalità CBC (sebbene l'attacco si applichi anche a molte altre modalità di crittografia).
Si noti che se un man-in-the-middle tronca un testo cifrato generato con modalità CBC (a un limite di blocco), il destinatario non noterà il troncamento e, dopo la decrittografia, riceverà una versione troncata del messaggio che il mittente stava cercando di inviare. Quindi, con questo background, ecco l'attacco. Lascia che Alice sia il mittente, Bob il destinatario e si assuma un'impostazione di testo in chiaro.
L'autore dell'attacco sceglie un messaggio M che desidera che Alice invii: ma Alice rifiuta di inviarlo (forse M dice "trasferisci $ 100 dal mio account e darlo a l'attaccante ", o qualcosa del genere). L'autore dell'attacco costruisce qualche altro valore X in modo che Alice voglia inviare M ' = M || H (M) || X (forse X dice "Sto solo scherzando, non osare"). L'hacker convince Alice a crittografare e inviare M '. Ciò significa che Alice trasmetterà il testo cifrato C ' = Encrypt ( K , M' || H (M ') ) = Encrypt ( K , M || H (M) || X || H (M ') ). L'attaccante suona man-in-the-middle, cattura C ' e lo tronca mentre è in volo. Chiamiamo C " il testo cifrato troncato. Bob riceverà C '' , lo decrittografa e quindi controllerà l'hash. Se l'attaccante sceglie correttamente il punto di troncamento, dopo la decifrazione, Bob ottiene M || H (M) , controlla l'hash, vede che l'hash è corretto e conclude che Alice deve aver inviato M .
In altre parole, alla conclusione di questo attacco, Bob conclude che Alice ha autorizzato la trasmissione del messaggio M - ma non l'ha mai fatto. (Ha autorizzato la trasmissione di qualche altro messaggio, ma non M .)
Indipendentemente dal fatto che si tratti di una grave vulnerabilità di sicurezza dipenderà dal contesto in cui viene utilizzata, come il formato del messaggio M . Ma, empiricamente, in almeno alcune applicazioni, questo tipo di attacco potrebbe rappresentare un serio pericolo per l'applicazione. Pertanto, i crittografi ritengono che questo non sia un buon schema per tutti gli scopi.
Dato che ci sono buoni schemi là fuori che sono stati attentamente controllati e dimostrati sicuri per un uso generico, i crittografi ti raccomanderebbero di usare uno di questi schemi generali (come crittografia autenticata o la costruzione di crittografia, quindi autenticare) e, in particolare, non utilizzare quella citata.