Se vogliamo sia la crittografia che la compressione durante la trasmissione, allora quale sarà l'ordine più preferibile.
- Cripta quindi comprimi
- Comprimi quindi cripta
Devi comprimere prima di crittografare.
La crittografia trasforma i dati in dati ad alta entropia, solitamente indistinguibili da un flusso casuale. La compressione si basa su schemi per ottenere una riduzione delle dimensioni. Poiché la crittografia distrugge tali schemi, l'algoritmo di compressione non sarebbe in grado di darti una riduzione (se del caso) di dimensioni se lo applichi ai dati crittografati.
La compressione prima della crittografia aumenta anche leggermente la resistenza pratica contro la crittanalisi differenziale (e alcuni altri attacchi) se l'utente malintenzionato può controllare solo il testo in chiaro non compresso, poiché l'output risultante può essere difficile da dedurre.
EDIT: sto modificando questo anno più tardi perché questo consiglio è davvero scarso in un caso interattivo. Non dovresti comprimere i dati prima di crittografarli nella maggior parte dei casi. Un metodo di attacco del canale laterale noto come "oracle di compressione" può essere utilizzato per dedurre i dati in testo normale nei casi in cui l'autore dell'attacco può causare in modo interattivo le stringhe in un flusso di dati in chiaro in chiaro altrimenti sconosciuto. Gli attacchi su SSL / TLS come CRIME e BREACH sono esempi di questo.
Se comprimi dopo la crittografia e la compressione non fa alcun bene (cioè riduce la lunghezza di un importo non trascurabile), puoi eliminare la crittografia, è terribilmente debole. Il testo cifrato dovrebbe essere indistinguibile dalla casualità; In genere, anche i dati crittografati male non possono essere compressi.
Pertanto, comprimi prima della crittografia. Questo è il motivo per cui i protocolli che trattano la crittografia di solito includono un supporto per la compressione, ad es. OpenPGP (sezione 5.6) e SSL / TLS . In alcuni scenari, la compressione può perdere informazioni sui dati riservati (poiché la compressione riduce la lunghezza a seconda dei dati e la lunghezza crittografata corrisponde più o meno alla lunghezza del testo normale); questa è l'idea alla base del nuovo attacco CRIME su SSL / TLS .
Eccezione marginale: se si cripta un messaggio con OpenPGP e quindi "ACSII armor" il risultato, ovvero lo si codifica in Base64, questa codifica ingrandisce i dati del 34%: 3 byte diventano 4 caratteri (più la nuova riga dispari). La compressione con DEFLATE sarà efficace per annullare questo ingrandimento (grazie ai codici Huffman). Questo è un caso di utilità di compressione dopo la crittografia - ma, in realtà, è più compressione su Base64, piuttosto che compressione su crittografia.
Consiglierei di comprimere prima i dati e di crittografarli.
L'algoritmo di compressione potrebbe trarre vantaggio dalla conoscenza della struttura dei dati e quella struttura sarebbe camuffata dalla crittografia. Un esempio potrebbe essere l'mp3 che può solo comprimere i dati audio.
dovresti crittografare meno dati. Mentre la prima volta che si cripta e poi si comprime, non si otterrebbe alcuna accelerazione.
Leggi altre domande sui tag encryption compression