Re: [Cfrg] OpenPGP security analysis

Jon Callas <jon@callas.org> Thu, 19 September 2002 03:33 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09223 for <cfrg-archive@odin.ietf.org>; Wed, 18 Sep 2002 23:33:21 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g8J3YlW30741 for cfrg-archive@odin.ietf.org; Wed, 18 Sep 2002 23:34:47 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8J3Ykv30738 for <cfrg-web-archive@optimus.ietf.org>; Wed, 18 Sep 2002 23:34:46 -0400
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09203 for <cfrg-web-archive@ietf.org>; Wed, 18 Sep 2002 23:32:51 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8J3XNv30640; Wed, 18 Sep 2002 23:33:23 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8J3WQv30583 for <cfrg@optimus.ietf.org>; Wed, 18 Sep 2002 23:32:26 -0400
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09113 for <cfrg@ietf.org>; Wed, 18 Sep 2002 23:30:30 -0400 (EDT)
Received: from [63.73.97.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Wed, 18 Sep 2002 20:32:08 -0700
User-Agent: Microsoft-Entourage/10.1.0.2006
Date: Wed, 18 Sep 2002 20:25:59 -0700
Subject: Re: [Cfrg] OpenPGP security analysis
From: Jon Callas <jon@callas.org>
To: Michael Young <mwy-opgp97@the-youngs.org>, Trevor Perrin <Tperrin@sigaba.com>, "'David Wagner'" <daw@cs.berkeley.edu>, OpenPGP <ietf-openpgp@imc.org>, <cfrg@ietf.org>
Message-ID: <B9AE91D7.93EC%jon@callas.org>
In-Reply-To: <003801c25e5d$b5e44280$f0c12609@transarc.ibm.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: cfrg-admin@ietf.org
Errors-To: cfrg-admin@ietf.org
X-BeenThere: cfrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

On 9/17/02 8:20 AM, "Michael Young" <mwy-opgp97@the-youngs.org> 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.

    Jon

_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg