I understand that compressing encrypted data and compressing digital signatures are not efficient because they are most likely incompressible. But in my application encrypted data and digital signatures (post quantum crypto) are stored in a sqlite database along with metadata like crypto algorithm name , iv . If LZMA compression is applied, the sqlite database itself is compressible. Actually i use sqlite database like a file format and transfer it across hostile network. I am wondering if compressing encrypted data or digital signatures would be a security disaster.

  • $\begingroup$ Whether compressing encrypted data or digital signatures can be a security disaster $\endgroup$
    – cce
    Feb 17 at 13:36

2 Answers 2


Applying lossless compression (like LZMA) to a database with encrypted or/and signed data is mostly neutral from a security standpoint: it's neither good, nor necessarily bad (but see second point below).

  • It provides no serious protection when the database is transferred across an hostile network. Argument: an attack working with the database not compressed can most likely be adapted to be carried with the database compressed, by decompressing, performing the attack, and re-compressing the database if it was modified by the attack.
  • If compression introduces a vulnerability that did not exist without compression, and under the assumption that the hostile network has full access to the data (rather than e.g. limited to the data length), said vulnerability can only be due to an error in the decompression code. These can lead to denial of service, or even code injection. That has happened many tines to many decompression code, see e.g. Security and Crash Bugs there, because decompression code is complex. Depending on your taste, that can be mitigated by one or more of:
    • Using a language or/and execution environment less likely to lead to exploitable bugs than bare C/C++ code is.
    • Reviewing the decompression code, perhaps even proving it correct.
    • Testing, perhaps by fuzzing, coverage analysis…
    • Authentication (including authenticated encryption) of the compressed data.

From a functional standpoint, the main drawback of compressing a database is that the database in unusable while compressed, and decompressing/re-compressing is costly in CPU and to some degree space and SSD/disk wear. But this is justifiable during transit, to reduce the amount of data transferred.

A simple approach to insuring database security while in transit in an hostile network is to send it PGP/GPG encrypted. This has built-in compression, and can give both confidentiality and integrity, if keys can be safely stored. As pointed in the question, what's stored encrypted in the database won't compressed (unless it's re-encoded to e.g. Base64). I don't know an alternative with post-quantum crypto. But then Cryptographically Relevant Quantum Computers remain highly hypothetical.

  • 1
    $\begingroup$ I very much like the point that vulnerabilities in the code are dangerous especially if the encrypted data has not been authenticated. This happens a lot with security, e.g. there were serious vulnerabilities in the ASN.1 decoder that Microsoft used before it was even able to authenticate signatures. The larger the attack surface before a message can be authenticated the higher the chance that code vulnerabilities can exist. $\endgroup$
    – Maarten Bodewes
    Feb 17 at 17:21

Compression algorithms have exactly the same security property as identity functions in terms of confidentiality. So the only security disaster would be that if you don't apply checksums or error-resilient redundancy.

  • $\begingroup$ do you mean i should checksum the compressed sqlite database with digital signature or encrypted data using hash function like sha512? $\endgroup$ Jan 29 at 7:58
  • $\begingroup$ That's totally up to you, these are all possible options. Doing them have both benefits and hassle, and what fits for one may not necessarily fit for others. $\endgroup$
    – DannyNiu
    Jan 29 at 10:40
  • $\begingroup$ The answer's first sentence is about lossless compression algorithms, which includes correct implementations of LZMA of the question. About the second sentence: in a crypto context "checksums or error-resilient redundancy" applied to a whole database containing encrypted or/and signed data are not to be considered helpful against manipulations by adversaries. $\endgroup$
    – fgrieu
    Jan 31 at 13:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.