I have done some research on PGP and I found out there are of two reasons why we must generate the signature before doing any compression. Yet, I am not sure I really understand them both.

One reason states that the message must be compressed first and signed later because if we need to do any future validation, we only need to store the signature – but what I think is if we do the signature first and compression later, we also need to store the signature and compression value. So it will be same as we do the signature first, followed by the compression. Either way, we also need to store the signature and compression value for future validation.

And then there is the second reason… which I do not understand at all:

Even if one were willing to generate dynamically a recompressed message for verification, PGP's compression algorithm presents a difficulty. The algorithm is not deterministic; various implementations of the algorithm achieve different tradeoffs in running speed versus compression ratio and, as a result, produce different compressed forms. However, these different compression algorithms are interoperable because any version of the algorithm can correctly decompress the output of any other version. Applying the hash function and signature after compression would constrain all PGP implementations to the same version of the compression algorithm

(This 2nd reason is from William Stalling’s book “Cryptography and Network Security”, 4th edition.)

Can anyone help me understand both reasons (especially the later), and/or can you explain to me why PGP expects us to generate the signature before compressing?

  • 1
    $\begingroup$ Your second paragraph says "must be compressed first". Was that a mistake? $\endgroup$
    – otus
    Aug 16, 2015 at 7:53
  • $\begingroup$ I just wanna know why ? There must have the logic behind this .Otherwise the algorithm will not look like this $\endgroup$ Aug 16, 2015 at 9:42

2 Answers 2


As for the first reason: in the future you probably need the decompressed form of the message. There won't be much you can do with the compressed message. But PGP is application level; you may want to verify that message at any time. Now you may want to verify the signature over that decompressed data without compressing it first. E.g. it's a good use case to allow compression over the network and then store the uncompressed message on disk.

As for the second reason: compression works with heuristics and levels of compression. Those levels are hints to the system how much work (CPU cycles mostly) it needs to put in to compress data. Different implementations may make different choices. The compressed format itself will indicate how the compression took place - otherwise you wouldn't be able to decompress of course. So if you decompress on system 2 (using the stored methodology of system 1) and compress it again (using the heuristics of system 2) you are likely to get a different result. Different outputs will result in different signatures, so it makes more sense to sign the uncompressed plaintext.

Semantically it also makes slightly more sense; you wanted to sign the message, right? Not some special compressed representation of it.

Obviously the compression should be completely loss-less for this to work; one bit wrong in the resulting message or a different order of the plaintext and the signature won't verify.

  • $\begingroup$ Good answer! I was wondering about the meaning of PGP being "application level" and thus the message being verified at any time. These two things just don't connect in my mind automatically. $\endgroup$
    – Mooncrater
    Dec 9, 2018 at 12:42
  • $\begingroup$ @Mooncrater I think I wrote this to compare it with transport level security, e.g. TLS, where the message authentication is only required during transport and may be disposed of afterwards - you protect the transport of the message rather than the message itself. PGP signatures may be useful later on. $\endgroup$
    – Maarten Bodewes
    Dec 9, 2018 at 12:46
  • $\begingroup$ I still do not understand the first reason. Why would I want to check the signature of an email that I sent and that is stored locally on my disk? Authenticity is obviously not an issue as I know I sent the email. Integrity is not an issue either as the email was not sent via the network and therefore there has been no opportunity of tampering. Or is that use case for the receiver checking the signature in his/her disk? If that's the case, why verify the signature more than once, when the email is received? $\endgroup$ Jul 7, 2021 at 0:08

Both reasons are basically the same. The issue here is the following: Often you only want to compress for transportation (e.g. for sending an email) and decompress for storage (e.g. when storing the email in you local email client) to more efficiently offer features like text search. Because the compression algorithm is non-deterministic you would have to store both the plaintext as well as the compressed format to verify the signature later. Because that's inconvenient and a waste of storage, you just sign the plaintext instead of the compressed value.


Your Answer

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

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