Why must we generate the signature before any compression being done at PGP?

Question

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?

Answer 1

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.

Answer 2

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.