Re: [Cfrg] OpenPGP security analysis

Jon Callas <> Thu, 19 September 2002 03:47 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id XAA09455 for <>; Wed, 18 Sep 2002 23:47:11 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by (8.11.6/8.11.3) id g8J3WDm05214 for ietf-openpgp-bks; Wed, 18 Sep 2002 20:32:13 -0700 (PDT)
Received: from ( []) by (8.11.6/8.11.3) with ESMTP id g8J3WCk05210 for <>; Wed, 18 Sep 2002 20:32:12 -0700 (PDT)
Received: from [] ( by with ESMTP (Eudora Internet Mail Server 3.1.2); Wed, 18 Sep 2002 20:32:08 -0700
User-Agent: Microsoft-Entourage/
Date: Wed, 18 Sep 2002 20:25:59 -0700
Subject: Re: [Cfrg] OpenPGP security analysis
From: Jon Callas <>
To: Michael Young <>, Trevor Perrin <>, 'David Wagner' <>, OpenPGP <>,
Message-ID: <>
In-Reply-To: <003801c25e5d$b5e44280$>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>
Content-Transfer-Encoding: 7bit

On 9/17/02 8:20 AM, "Michael Young" <> wrote:

> The MDC in OpenPGP is really no more than a checksum, intended to
> detect accidental damage.  (In fact, during the discussion, I believe
> that some folks suggested that it be just a checksum.)  Before the
> MDC, there was little ability to detect *any* sort of accident -- not
> just truncation, but fairly arbitrary internal damage as well.  (When
> the payload is a compressed packet, the decompression might discover
> damage, but then again, it might not.)  There was discussion of a
> stronger MAC, but I think this was dropped given that OpenPGP has a
> strong signature mechanism.

Yes, and no. The MDC is supposed to detect intentional damage as well as
accidental damage. While a checksum was suggested, it was rejected because
it's pretty obvious that would not have the desired characteristics.

It *is* true that the MDC is not and was never intended to be a MAC. The
goal of the MDC is to reliably detect modification of the data in the
envelope, whether by insertion, deletion, or changing it. If an attacker can
do that, then then MDC has failed and we need a new mechanism.

Also note that the MDC's hash is weakly keyed, as there is an "IV" for it
inside the envelope.

If we need to, there are ways we could turn this into a MAC, including a
function over the key, or key+hashkey, or even including an extra MAC key
inside the ESK.

I think there are a number of separate questions around this that include:

(1) Is there a security problem in the MDC as in bis-06?

(2) Should we change it regardless?

Each of those is important. If the answer to (1) is yes, then we need
something. (2) needs to balance existing deployment and so on.