1. Introduction
In this tutorial, we’re going to explore what encrypting, digitally signing briefly, and compressing content mean for us. We are then going to see what the effect is of performing these operations in different orders, depending on our exact needs.
2. What the Actions Mean
Before we’re able to explore the effect of performing these actions in different orders, we need to understand what the actions are and why we would use them.
2.1. Digitally Signing Content
Various different methods can be used for digitally signing content, but typically they involve public/private key cryptography. This generates a signature by combining the original content and the signer’s private key:
It’s then possible, by combining the content and signature with the public key, to prove that this is the key that was used to generate the signature. The only way to successfully validate the signature is if the correct public key is used, as well as the correct content and the correct signature. If any of those three is incorrect then validation will fail:
By ensuring that the private key is indeed kept private, it can then be known that only someone with access to that key could have generated that signature and that the content must have been exactly the same at the time the signature was generated. If not, then the signature wouldn’t validate.
2.2. Encrypting Content
Encryption is another cryptographic construct that serves to ensure unauthorized people aren’t able to consume the encrypted content. If a malicious party has the encrypted content but doesn’t have the ability to decrypt it, then they are unable to do anything with it.
Encryption works by taking the original content and performing some processes on it to produce encrypted content. Ideally, it should be impossible to tell from the encrypted content anything significant about the original content. For example, some attacks on encryption schemes work by detecting details about the original content from patterns present in the encrypted version.
In some cases, encryption works by having a shared secret that both the sender and receiver know. In other cases, it works with public/private key cryptography, where the sender will use the public key of the receiver to encrypt the content, and then only someone with the appropriate private key can decrypt it:
Ideally, it shouldn’t be possible to tell any of this from the encrypted content alone.
2.3. Compressing Content
Compression is a technique that allows us to encode some amount of content into a smaller amount of space. For example, the ebook of War And Peace is 3.2MB in size, but we can compress it using bzip2 down to 0.8MB in size – only 26% of the original size.
Often, but not always, compression will be lossless. This means that it’s possible to convert the compressed content back into the exact uncompressed content with zero defects. However, sometimes it can be beneficial to use lossy compression instead, trading data loss for a higher compression rate. For example, JPEG files are significantly better compressed than many other image formats, but this is achieved by a – hopefully imperceptible – data loss in the image.
Compression generally works by finding patterns in the original content and replacing all occurrences of those patterns with significantly shorter strings. This works best when we can find many very long patterns and replace them all with the shortest string possible. However, if the input data is highly random, then compression may not be able to achieve much, if anything.
3. Combining Actions
Now that we know what the possible actions are, why would we want to combine them? And, if we do want to combine them, are there any benefits or drawbacks to doing so, or the order in which we do so?
3.1. Combining Encryption and Compression
Compression exists to make the payload smaller, which can then make it easier to store or transmit. So it seems reasonable to want to combine this with other actions to be able to maintain that benefit. However, compression works by identifying patterns and replacing them with other patterns. This actually means that combining it with encryption may not be beneficial.
If we decide that we want to encrypt our data first, the end result of this should seem as random as possible – that is, it will have as few patterns as possible in it. This means that encrypted content will be especially difficult to compress. For example, our War And Peace file encrypted with AES-256-CBC is still about 3.2MB, but compressing this results in a file that is actually fractionally larger!
Conversely, we could compress the data first. This will work, and we will get a smaller result whilst still being encrypted. However, this potentially opens us up to more risks around the encryption since the compression might actually emphasise any patterns that originally existed in the content and thus make them harder to hide in the encrypted output. For example, the CRIME and BREACH exploits are real-world examples where compression inside encryption made the attacks possible.
3.2. Combining Encryption and Signing
Encryption and Signing of our content go well together. They work in complementary but not exactly the same way. Signing proves that the content received is exactly the content that was sent and that it was signed by the person who we expected, and encryption works by making sure that no unauthorized parties can consume the content.
But in what order should we do these actions?
If we encrypt the content before signing it, then the receiving party will know that the received payload is as expected without having to decrypt it. This can be important in some cases where the payload is being forwarded from one system to another – the intermediate systems are incapable of decrypting the content but can still ensure it’s correct.
However, it does open up the risk that the signing party themselves didn’t know what the original content was. All it really guarantees is that the encrypted payload hasn’t been tampered with, and it says nothing about the original data. This could, in turn, lead to the receiver trusting the content when they shouldn’t have done so.
For example, a malicious payload could be encrypted and substituted for the original one before it gets signed. The recipient would have no way of knowing this had happened, and the signature would imply that the payload exactly matches what it was at the time it was signed. Worse, the system signing the content may have no way of knowing this had happened either if they aren’t the ones responsible for encrypting it in the first place.
Conversely, if we sign the content before we encrypt it, then it demonstrates that the signer knew what the original content was, but only someone who can decrypt the content will be able to access the signature. This gives us a stronger guarantee, but only to those who can decrypt the data. Intermediate systems wouldn’t be able to rely on this system as proof that the content was correct and would have to employ other means.
3.3. Combining Compression and Signing
The third pair of actions that we can combine our compression and signing. Since neither signing nor compressing our content doesn’t hing to obscure the content from malicious eyes, there is no risk involved with combining these from that point of view. However, depending on exactly how our compression algorithm works, this might not always be beneficial.
As with encryption, if you sign before compressing the content, then only systems that are able or willing to decompress the content can verify the signature. Since decompressing the content will take both time and resources, it’s highly possible that intermediate systems won’t do this and so won’t be able to verify the signature. However, the final recipient is still able to do this and still able to benefit from the signature as normal.
There is also an additional risk that, if the compression is lossy, the result of compressing it will have corrupted the content and/or the signature, thus leaving them useless. Lossy compression algorithms are unusual for this kind of scenario, so this is an unlikely risk, but we still need to consider it.
If we instead sign the compressed content, then we don’t have this risk. However, we are again in a situation where the signature is for the compressed payload and gives no guarantee that the signer knew what the original payload was. As before, a malicious party could substitute the payload before it’s signed, and the recipient would have no way of knowing. In this case, the signer can at least decompress the payload first and verify it since there are no restrictions on being able to do that.
4. Summary
Here we’ve looked at what digitally signing, encrypting and compressing our content can do and some of the potential benefits and drawbacks of using these in combination. In particular, we’ve seen how combining compression and encryption is potentially not beneficial, but combining either of those with digital signatures does have benefits if done right.