Jeff Johnson wrote:

Hi Jeff -

> I still have never figured out in my own mind whether compressing signed
> headers,
> or signing compressed headers, is what I need to implement in rpm.

The difference is fairly small but it is still there: basically data
whose authenticity you have no information on passes through the
decompressor if you "sign then compress" (decompress and check sig).
Whereas with "compress then sign" (check sig then decompress) an
attacker without a valid signature gets no opportunity to exploit a flaw
in the decompressor, even if the flaw is public, since his radioactive
bytes failed the sig check already.  (I think you saw all this)

> I'm maybe a month away from an implementation, the preliminaries
> to XAR package format are removing a rpmlead, and figuring a different
> way to include detached signatures. The next step is figuring the
> order of compression and signing for metadata headers.
> 
> Compressing signed headers permits changing the compression without
> resigning.
> OTOH, then the compression itself may be exploitable.

I think it's a bit confused because there are two separate issues
intertwined that can take two sigs to solve.

 sig 1: Is the decompressed content genuine?  Only the originator of the
decompressed content can sign to say that it is authentic, so the
decompressed content can be signed only with his key if sig 1 is present.

 sig 2: Is the compressed package messed with?  If you have this
recompression concept allowed, then there is a second compressor guy who
can sign to say that his compression is authentic by using his key on
the *compressed* data (he can be the same guy as 1).

In the degenerate case, there is no recompression allowed or performed.
 The originator signs only as 2 (to assert that the compressed blob is
authentic), and that serves as to sign that the decompressed content
must be genuine too.  The recipient just has to trust the originator key
in this case.  If anyone tries to recompress it, the result has no
signature from the originator that will still apply to it.

If the originator intends to allow recompression, he signs initially
both sig 1 and sig 2 separately.  Another guy can come and recompress
the content, keeping sig 1 from the originator inside proving the
decompressed content is unchanged, and he overwrites the now broken sig
2 from the originator with his sig to assert the compressed block is
authentic.  The recipient has to trust the resigner and originator key
(specificly in those roles so the resigner can't get away with making
fake decompressed content) in this case.

Note in both scenarios, the recipient gets to check the compressed blob
against a trusted sig 2 signer's signature first *without
decompression*.  If it was not recompressed, he can decompress and he is
done.  If it was recompressed, he decompresses and checks the result
against a trusted sig 1 signer's signature to confirm that the trusted
recompressor was not slipping him a mickey.



There is another cool thing to consider too, in any place where a sig
can be given allow the possibility to give either multiple actual sigs,
or a single signature on multiple hashes (maybe beecrypt does not make
this easy) for the same purpose.  The idea is if the originator wants a
very strong assurance of authenticity, he can hash the cleartext using
both MD5 AND SHA-1 for example and sign that.  Maybe someone can spend a
lot of effort to fuzz bad data to collide MD-5, but I'm pretty sure they
can't fuzz it to collide to the same MD5 AND SHA-1 as the original,
despite MD5 and SHA-1 may have their own weaknesses.  Only really
paranoid folks would bother to do this so it isn't much of a burden to
anyone else.

-Andy