La crittografia simmetrica fornisce l'integrità dei dati?

La crittografia simmetrica non garantisce l'integrità. La quantità di controllo che un utente malintenzionato può avere sui dati crittografati dipende dal tipo di crittografia; e alcuni dettagli specifici di alcune modalità di crittografia possono rendere la vita un po 'più difficile per l'aggressore se vuole apportare modifiche chirurgiche. Con CBC, l'attaccante può capovolgere qualsiasi cosa desideri, a condizione che non gli importi di trasformare una dozzina di altri byte in cianfrusaglie casuali.

Esistono modalità di crittografia recenti che combinano la crittografia simmetrica e l'integrità verificata (con un MAC ). Queste modalità assicurano sia la riservatezza che l'integrità. AES-CBC è non uno di questi. Se desideri una modalità di crittografia con integrità, ti consiglio di EAX .

Aggiornamento: relativo all'esperimento: CBC è una modalità in cui la lunghezza dei dati di origine deve essere un multiplo della lunghezza del blocco dei codici a blocchi (16 byte, per AES). Poiché un messaggio di input arbitrario può avere una lunghezza qualsiasi, viene aggiunto un padding : alcuni byte, con contenuti specifici tali da poter essere rimossi in modo univoco alla decrittografia. Nel tuo caso, OpenSSL si lamenta che, al momento della decodifica, non trova una struttura di riempimento adeguata. Tuttavia, se l'attaccante non modifica gli ultimi 32 byte dei dati crittografati, il padding non sarà danneggiato, quindi le alterazioni di tutti gli ultimi 32 byte rimarranno non rilevati. E anche per gli ultimi 32 byte, ci sono modi per eludere il rilevamento con una probabilità non troppo piccola.

La crittografia CBC non fornisce l'integrità dei dati. Ecco perché:

Correggere qualche chiave k (sconosciuta all'attaccante). Lasciate che E (k, -) e D (k, -) siano le funzioni di crittografia e decrittografia di alcuni codici a blocchi. Sia p un singolo blocco di testo in chiaro. Denoterò XOR di +. Dopo aver corretto alcuni IV, criptiamo come segue:

c = E (k, p + IV).

Quindi, inviamo IV e c sul filo. Per decifrare, calcoliamo

p = D (k, c) + IV.

(Si noti che questo è equivalente all'istruzione D (k, c) = IV + p.)

Ora, supponiamo che un utente malintenzionato conosca una singola coppia di testo in chiaro / cifratura. Indichiamoli come p e (IV, c), come sopra. Supponiamo ora che l'aggressore voglia creare un testo cifrato che decrittografi in un altro blocco di testo in chiaro di sua scelta, ad esempio p '. Io sostengo che (IV + p + p ', c) decifra in p'. Perché?

Bene, seguiamo semplicemente la procedura di decrittografia sopra, sostituendo IV con IV + p + p '. Abbiamo

D (k, c) + (IV + p + p ') = (IV + p) + (IV + p + p') = p '.

In modo divertente, la modalità ECB non è vulnerabile a questo problema (anche se non approvo neanche il suo uso).

La crittografia AES-CBC non fornisce integrità. A seconda di come è implementato e utilizzato, potrebbe capitare di rilevare alcune modifiche accidentali al testo cifrato, ma non protegge non da manomissioni dannose con il testo cifrato.

La crittografia senza autenticazione è uno degli errori più comuni nell'uso della crittografia . Ha portato a gravi vulnerabilità in molti sistemi, tra cui ASP.NET, crittografia XML, Amazon EC2, JavaServer Faces, Ruby on Rails, OWASP ESAPI, IPSEC e WEP. Vedi il link precedente per maggiori informazioni.

La correzione: dovresti utilizzare uno schema di crittografia autenticato (non AES-CBC), come EAX, o dovresti usare un codice di autenticazione dei messaggi, come CMAC, in modalità encrypt-then-authenticate.

Se hai intenzione di implementare la crittografia da solo, ti incoraggio a leggere la domanda qui sotto intitolata Lezioni apprese e idee sbagliate sulla crittografia e crittologia per aiutarti ad evitare alcuni degli errori più comuni. L'uso della crittografia senza autenticazione è uno di questi.

Le crittografie simmetriche non forniscono di per sé l'integrità perché non rilevano modifiche dannose o accidentali al testo cifrato; la decodifica produrrà qualcosa di diverso dal testo in chiaro originale e, a meno che ciò non comporti una violazione del protocollo per il carico utile decrittografato, si avrà un problema di integrità.

La soluzione è racchiudere il testo in chiaro all'interno di pacchetti che includono dati che possono essere utilizzati per convalidare l'integrità del pacchetto, in genere un checksum basato su hash ( modifica: con chiave HMAC). Questo è ciò che viene fatto ad es. per Transport Layer Security.

Ecco un esempio di uno schema di protezione in chiaro utilizzato in un byte sicuro della piattaforma Versile protocollo di trasporto (disclaimer: sono coinvolto nello sviluppo di VP).

Modifica: ho realizzato che l'incapsulamento dei messaggi è eccessivo per il tuo scenario che coinvolge un file completo e quindi è meglio aggiungere semplicemente un MAC con chiave sul testo cifrato completo. Per i formati protetti da pacchetto, come D.W. indica i dettagli e "checksum" deve essere eseguito come MAC con chiave.

Se includi il testo in chiaro, allora direi di sì, usare una chiave simmetrica per crittografare qualcosa, dove il ricevente può decodificarlo e confrontarlo con il testo in chiaro, fornisce l'integrità dei dati.