Vorrei comprimere i dati prima di crittografarli e archiviarli in un database MySQL per ridurre in particolare i requisiti della larghezza di banda. In futuro, il DB potrebbe essere accessibile tramite un'interfaccia web.
Diversi commenti sull'insicurezza della compressione in testo semplice prima della crittografia, relativi a violazioni della sicurezza come CRIME o BREACH, mi rendono incerto su come farlo. Inoltre, alcuni sostengono che la compressione prima della crittografia sia in realtà una buona pratica di sicurezza. Mi rendo conto che gli attacchi come CRIME o BREACH sono scenari specifici, ma temo che la mia applicazione potrebbe essere troppo vicina (o alla fine avvicinarsi troppo) a uno scenario simile in cui la compressione potrebbe costituire un rischio per la sicurezza (il contenuto del DB può essere rubato, server compromesso ecc.). Inoltre, non sono abbastanza esperto per comprendere appieno tutti gli aspetti, i dettagli e le sfumature di CRIME o BREACH.
Dopo aver letto questa discussione sull'argomento, con la raccomandazione di riempire il testo in chiaro con un nonce casuale prima della compressione, mi chiedo se la seguente implementazione (in PHP) farà sicuramente il lavoro:
$plaintext = gzcompress ($plaintext . openssl_random_pseudo_bytes (64));
$cipher_text = openssl_encrypt ($plaintext, 'aes-256-cbc', $key, 0, $iv);
L'integrità dei dati è garantita da una procedura di firma / verifica HMAC sul testo e sulla chiave di crittografia.
È un'implementazione sicura?
Ci sarebbe qualche vantaggio nel fatto che il nonce sia di lunghezza casuale, e quindi aggiungendo le informazioni sulla lunghezza alla fine del padding per rimuovere il padding dopo la decrittazione? O dovrebbe la lunghezza del nonce essere in relazione alla lunghezza del testo in chiaro (che sarebbe in genere di almeno 512 byte)?
NOTA: per quanto posso dire, la mia applicazione specifica e la soluzione proposta non sembrano rispondere al possibile duplicato suggerito nei commenti.