RE: [Cfrg] OpenPGP security analysis

Trevor Perrin <Tperrin@sigaba.com> Tue, 17 September 2002 17:29 UTC

Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22675 for <openpgp-archive@lists.ietf.org>; Tue, 17 Sep 2002 13:29:40 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8HHOpO26319 for ietf-openpgp-bks; Tue, 17 Sep 2002 10:24:51 -0700 (PDT)
Received: from bulwinkle.sigaba.com (bulwinkle.sigaba.com [67.113.238.132]) by above.proper.com (8.11.6/8.11.3) with SMTP id g8HHOok26315 for <ietf-openpgp@imc.org>; Tue, 17 Sep 2002 10:24:50 -0700 (PDT)
Received: from bsd.sigaba.com (67.113.238.131) by bulwinkle.sigaba.com (Sigaba Gateway v3.5) with SMTP; Tue, 17 Sep 2002 10:18:16 -0700
Received: from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g8HHOhE3004191; Tue, 17 Sep 2002 10:24:43 -0700
Received: by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <TA7Z6C78>; Tue, 17 Sep 2002 10:24:40 -0700
Message-id: <2129B7848043D411881A00B0D0627EFEBFB18A@exchange.sigaba.com>
From: Trevor Perrin <Tperrin@sigaba.com>
To: "'Michael Young'" <mwy-opgp97@the-youngs.org>, Trevor Perrin <Tperrin@sigaba.com>, "'David Wagner'" <daw@cs.berkeley.edu>, ietf-openpgp@imc.org, cfrg@ietf.org
Subject: RE: [Cfrg] OpenPGP security analysis
Date: Tue, 17 Sep 2002 10:24:39 -0700
MIME-Version: 1.0
X-mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit


>From: Michael Young [mailto:mwy-opgp97@the-youngs.org]
>
>But if this is the scenario, then two facts complicate the attack:
>    M and M' must be formatted as OpenPGP packets; and,

you're right, this does complicate the attack - it means that in the simple
truncation attack (where the evil message ciphertext is just a truncation of
the innocuous message ciphertext) the decrypted literal packet data length
will be wrong.

Unless there's a way to get around that, the only attack I see, then,
requires the attacker to inject make-believe check bytes and OpenPGP packet
formatting, and thus will succeed with probability only 2^-16 cause the
check bytes will probably turn out wrong. 

Trevor