ietf-openpgp
[Top] [All Lists]

Re: Packet length: header vs. context

2007-01-08 11:48:40

Levi Broderick wrote:
(resending, as the original message seems to be MIA)

Consider the following scenario:

An implementation is parsing a public-key packet.  The packet header
gives a body length of 600 bytes; this is then buffered into memory.
The software successfully parses all the data in the packet body -
everything from the packet version number to the final MPI that it was
expecting - and realizes that it has only read 400 bytes.

Even if the public key data was successfully parsed, should the
implementation consider the packet to be malformed and reject the key?
Or should the leftover data be considered optional and be ignored?  I
think it makes more sense to error out, but the RFC draft and mailing
list archives seem to be silent on this issue.

I can tell you that the PGP parser does not check for excess data on
public key packets, but does check on secret key packets.  Secret key
packets have a checksum at the end and we make sure the checksum (i.e.
the remaining data after parsing all the MPIs) is the expected size.
We had some attacks involving weak checksums in the past, so we take
some care in this area.  But for public key packets we are not so careful.

However I think you could error out on public key packets with excess
data, without running into incompatibility problems.  I have never
noticed such public keys in my various debugging and dumping efforts
over the years.

Hal