There has been much discussion on the net of a GnuPG bug reported by
Werner Koch on Thursday:
http://lists.gnupg.org/pipermail/gnupg-announce/2006q1/000216.html
The problem is that a sequence of OpenPGP packets, some signed and some
unsigned, was being output with the different types of data concatenated
and no indication of what part was signed and what part wasn't.
(This is my understanding from reading the report, apologies if I am
misstating it.)
Ironically I described a similar problem last month when we were talking
about packet formats for exchanging public keys. I mentioned that I was
not sure our PGP software would always work well with arbitrary sequences
of OpenPGP packets, and that such messages raise difficult issues.
Here is what I wrote on Feb 7, replying to Ben Laurie:
Hmm. My implementation will eat _any_ sequence of packets.
So what do you do if you decrypt a file and find a sequence of encrypted
packets? Or perhaps some packets signed, some encrypted, some both, all
concatenated? Do you concatenate the results into a single output file
(erasing the boundaries between the plaintexts, as well as information
about what was signed and what wasn't); do you concatenate them along
with some header information to identify where each piece starts and ends
(which won't be reliable due to spoofing); do you output each piece to
separate output files? Or ask the user what he wants to do?
It appears that this was a case of exactly what I described as the first
possibility, concatenating the results, with the problem of losing the
information about what was signed and what wasn't.
As usual the GnuPG guys have done a good job of publicizing this problem
and quickly getting a bug fix out. It appears that the new version
will only allow signed messages that have a simple format and will
intentionally _not_ eat any sequence of packets.
This is a good lesson for other implementors, to be aware of user
information issues when dealing with complex cryptographic operations.
Our OpenPGP packet format is extremely flexible, but that flexibility
may not be appropriate for exposure directly to end users. Here is how
I concluded my Feb 7 message:
This kind of operation introduces considerable complexity in terms of
providing a reasonable interface. We generally assume we are dealing
with a single message consisting of one or more PKESK/SKESK packets with
an encrypted packet, or a similar signed message. Once you go beyond
this and try to deal with arbitrary sequences of packets it becomes
highly problematic to make sure the user is getting the full benefit
from the cryptography. If you have a custom program which is using this
for internal, program-to-program communication, then go ahead and knock
yourself out, use the data structures as you wish. But for person to
person communication I think it is difficult and often unwise to try to
deal with arbitrary sequences.
Hal Finney