Ci sono diversi fattori che entrano in gioco. La prima è che la crittografia dovrebbe nascondere i pattern: se si ha un file che contiene lo stesso contenuto ripetuto più volte, la crittografia dovrebbe nascondere questo fatto. Se si dispone di uno schema di crittografia debole, che trapelano alcune informazioni sui pattern nel testo normale nei suoi testi cifrati, la compressione può aiutare a ridurre la quantità di informazioni trapelate. Almeno, questa è la teoria classica. Ogni schema di crittografia che è abbastanza buono per essere usato al giorno d'oggi dovrebbe occuparsi di schemi tutto da solo, però, compressione o nessuna compressione (suggerimento correlato: non utilizzare mai la modalità ECB direttamente). Quindi l'argomento classico per la compressione prima della crittografia non è più rilevante (e la compressione dopo la crittografia non ha senso in quasi tutti i casi).

Un altro argomento "classico" è che le probabilità di rompere un cifrario aumentano con la quantità di testo cifrato con cui si deve lavorare. Quindi se comprimi i tuoi messaggi prima di inviarli, dai a un intruso meno materiale con cui lavorare. Di nuovo, per qualsiasi cifra sicura secondo le nozioni moderne non dovresti preoccuparti di questo. Dovresti aggiornare i tuoi algoritmi e le dimensioni delle chiavi di tanto in tanto in base alle ultime raccomandazioni, ruotare le chiavi, ecc., Ma l'impatto della compressione su questo sarà minimo. Inoltre, se si cripta ogni messaggio sotto una chiave per messaggio e quindi si trasporta questa chiave, la si crittografa con una chiave-chiave di crittografia, che è una cosa abbastanza comune da fare (specialmente quando è implicata la crittografia a chiave pubblica), sei controllando la quantità di testo cifrato che viene inviato con una qualsiasi chiave molto meglio di quanto si possa fare con la compressione.

Il punto successivo è che si potrebbe desiderare che la crittografia nasconda anche la lunghezza del testo cifrato. Non è troppo difficile ottenere alcuni "metadati" su ciò che qualcuno sta facendo su una connessione TLS osservando le lunghezze e le frequenze dei pacchetti. La compressione prima della crittografia può aiutare a ridurre la forza del "segnale" in alcuni casi, ma se sei preoccupato dell'analisi del traffico, probabilmente dovresti fare altre cose come il padding a una lunghezza fissa - di nuovo, la compressione può rendere una brutta situazione un un po 'meno male, ma non trasformerà una brutta situazione in una buona.

Infine, potresti aver sentito che la compressione all'interno del protocollo TLS sarà abolita e bandita nella versione 1.3, o almeno lo è stato quando ho letto l'ultima bozza. Questo non ha a che fare con la compressione in generale, ma perché il modo specifico di crittografia, padding, MAC e compressione interagito in TLS 1.2 e precedenti ha avuto alcune vulnerabilità (CRIME, BEAST ecc.). Ciò non significa che non puoi comprimere a un livello (applicazione) superiore o che la compressione indebolisce la crittografia in generale, solo che non ha posto nel modulo di crittografia attuale, almeno non nel modo in cui è fatto in TLS al momento.

Modifica

In risposta ai commenti che fanno ulteriori domande, ecco due esempi di come la compressione può aiutarti o danneggiarti.

Esempio 1 Stai facendo domanda per un posto di lavoro e accetti di inviare al tuo migliore amico un messaggio crittografato che ti dice se ce l'hai o no. Poiché lavori in IT, un semplice "sì" o "no" non lo farai - deve essere una GIF animata, quindi prepari due file yes.gif e no.gif, e perché sei preoccupato per qualcuno che guarda alla dimensione del testo cifrato, li rendi entrambi esattamente 64 KB. Ma yes.gif è pieno di colori e pony e arcobaleni e, se compresso, di 60KB di grandi dimensioni, il no.gif è un'animazione in bianco e nero più demure e comprime fino a 4KB. Il tuo programma di crittografia applica automaticamente la compressione prima della crittografia. In questo caso, la compressione rovina completamente la tua sicurezza.

Esempio 2 Hai rinunciato alle GIF animate e sei d'accordo che la prossima volta che vorrai incontrare il tuo amico gli invierai una e-mail crittografata che ti dirà semplicemente "Incontriamoci il prossimo [giorno della settimana]". Il tuo programma di crittografia cripta in blocchi di 8 caratteri (64 bit). Se il tuo messaggio è "Incontriamoci il prossimo lunedì." si adatta bene in 3 blocchi, se è "Incontriamoci mercoledì prossimo". questo è 4 blocchi. Fallito di nuovo. In questo caso, "comprimere mentalmente" tutti i giorni nelle loro prime tre lettere ("Incontriamoci con il prossimo WED.") Ti avrebbe salvato.

In breve: la compressione non aiuta o danneggia la crittografia in modo generico; se in genere si ha a che fare con messaggi di lunghezze simili ma con livelli variabili di entropia / compressibilità, potrebbe causare più danni che benefici.

L'attacco CRIME funziona a causa di un insieme di circostanze molto specifiche che implicano la compressione come un ingrediente, ma non dovrebbe essere applicabile allo storage di file.

La compressione non è affatto la sicurezza. Potresti confondere la compressione con nascondere i dati sulla steganografia ma, a prescindere, non fornisce una vera sicurezza ma invece nasconde semplicemente delle cose. La crittografia ovviamente protegge i tuoi dati.

Da Wiki :

Brute-force attacks can be made less effective by obfuscating the data to be encoded, something that makes it more difficult for an attacker to recognize when he/she has cracked the code. One of the measures of the strength of an encryption system is how long it would theoretically take an attacker to mount a successful brute-force attack against it.

Questo potrebbe essere il punto in cui inizia la confusione. Potresti pensare che 'oh hey quando uso winzip e guardi i dati esadecimali sembra tutto diverso quindi io hai creato un piccolo strato di oscurità, giusto? ' Sbagliato! A meno che tu non stia usando un metodo univoco di oscurità, tutto quello che stai facendo sta rallentando il processo di controllando il tentativo di forza bruta da una quantità insanamente piccola di tempo.

Questo perché ogni file ha una cosiddetta firma del file (in modo che il sistema operativo possa dare un senso a tutti i dati) quindi, a meno che tu non crei la tua firma di file univoca o nascondi i tuoi dati all'interno di un'altra firma, non ci sono miglioramenti ottenuti cambiando solo una firma per un'altra.

Attacchi multipli con nomi molto evocativi hanno dimostrato che la compressione può indurre vulnerabilità facendo filtrare informazioni sul testo in chiaro:

• CRIME (Rapporto di compressione-perdita di informazioni semplificato)
• BREAK (Riconoscimento di browser ed esfiltrazione tramite Adaptive Compression of Hypertext)

In sostanza, se puoi controllare parte del testo in chiaro, puoi intuire altre parti del testo in chiaro osservando la dimensione del testo cifrato (perché la compressione sarà più efficace quando si abbinano pattern esistenti nel testo in chiaro).

Immagina che qualcuno stia tentando di forzare la decodifica di un file e, quando viene provata una determinata password, viene fuori un ovvio file di testo inglese.

Supponiamo di provare lo stesso esercizio, ma tutti i byte nel file di testo sono stati spostati di 79 posizioni prima della crittografia.

Il secondo approccio è più strong, anche se l'offuscamento (spostamento dei byte) NON è crittografia.

Lo stesso può valere per la compressione di un file prima di crittografarlo.