Qual'è il miglior metodo di compressione personalizzato da usare quando ho SSL?

9

Supponiamo di avere un'applicazione che esegue la crittografia utilizzando SSL e che non è possibile controllare quale suite di crittografia viene negoziata e presupponendo di avere una compressione personalizzata sui dati prima che avvenga la crittografia. Quale sarebbe la migliore modalità di compressione da utilizzare? Se vado avanti e uso DEFLATE / GZIP sono paranoico, potrei espormi a un attacco in cui un utente malintenzionato può esporre dati crittografati utilizzando attacchi in chiaro. (qualcosa di simile all'attacco CRIME)

    
posta Cookies 01.08.2013 - 17:33
fonte

1 risposta

24

La crittografia nasconde dati ma perde dimensioni dei dati . Questa è una proprietà comune di tutti i sistemi di crittografia: i dati crittografati hanno (più o meno) le stesse dimensioni dei dati chiari.

La compressione altera la dimensione dei dati ma lo fa trovando "ridondanze" (in senso ampio) nei dati. Quindi il tasso di successo della compressione dipende dal contenuto dei dati . Pertanto, la compressione rende dimensione dei dati dipendente da contenuto di dati .

Prendi insieme i due, e questo ti porta alla conclusione inevitabile, ma triste: la compressione perde informazioni sui contenuti dei dati, anche attraverso la crittografia. L'unica conclusione generale è che tu non devi affatto comprimere .

Il attacco CRIME funziona semplicemente con questa nozione, in una configurazione specifica per il Web in cui l'utente malintenzionato può scegliere parte dei dati che è compresso e tenta di ottenere altri dati riservati che fanno anche parte del flusso compresso. Questo è un attacco di testo in chiaro scelto e rende l'attacco davvero efficiente. Tuttavia, in generale, una perdita è una perdita: anche in scenari di attacco puramente passivi, la compressione renderà la tua connessione "meno sicura".

Il principio non è specifico per Deflate ; cambiarlo in un algoritmo personalizzato non ti salverebbe. Deflate non è "particolarmente debole" o "particolarmente strong" a tale riguardo.

Tutto quanto sopra si applica a tutti gli algoritmi di compressione lossless . Non fa per gli algoritmi di compressione lossy che raggiungono una larghezza di banda dei dati fissi. Ad esempio, se si comprime la musica in un MP3 a esattamente 128 kbit / s (nessuna frequenza variabile), le dimensioni dei dati risultanti non dipenderanno dai contenuti musicali, ma solo dalla durata della musica originale. Ma, naturalmente, gli algoritmi di compressione con perdita di dati sono applicabili solo ai dati in cui la perdita può essere tollerata; per esempio. suono, non XML.

(La cosa su "lossy" è che non puoi garantire un tasso di compressione fisso senza avere una potenziale perdita di dati, a causa del pigeonhole principio , a meno che la tua "compressione" sia in realtà una mancanza di compressione, con i dati di input totalmente invariati.)

    
risposta data 01.08.2013 - 17:51
fonte

Leggi altre domande sui tag