GnuPG does not detect injection of unsigned data

[[e-mail] ("Hal Finney")]

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