Re: Packet length: header vs. context

hal@finney.org ("Hal Finney") Mon, 08 January 2007 18:48 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3zXn-0000MA-A6 for openpgp-archive@lists.ietf.org; Mon, 08 Jan 2007 13:48:27 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3zXl-00062T-S0 for openpgp-archive@lists.ietf.org; Mon, 08 Jan 2007 13:48:27 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l08ILX1H060650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jan 2007 11:21:33 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l08ILXhd060649; Mon, 8 Jan 2007 11:21:33 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l08ILVHs060643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-openpgp@imc.org>; Mon, 8 Jan 2007 11:21:32 -0700 (MST) (envelope-from hal@finney.org)
Received: by finney.org (Postfix, from userid 500) id B7C9A14F6BC; Mon, 8 Jan 2007 10:10:08 -0800 (PST)
To: ietf-openpgp@imc.org
Subject: Re: Packet length: header vs. context
Message-Id: <20070108181008.B7C9A14F6BC@finney.org>
Date: Mon, 8 Jan 2007 10:10:08 -0800 (PST)
From: hal@finney.org ("Hal Finney")
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464

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