Re: Fixing the MDC language

"Hal Finney" <hal@finney.org> Fri, 20 September 2002 07:03 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 DAA14929 for <openpgp-archive@lists.ietf.org>; Fri, 20 Sep 2002 03:03:22 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g8K6tfS01782 for ietf-openpgp-bks; Thu, 19 Sep 2002 23:55:41 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8K6tek01776 for <ietf-openpgp@imc.org>; Thu, 19 Sep 2002 23:55:40 -0700 (PDT)
Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id g8K6t9k17770; Thu, 19 Sep 2002 23:55:09 -0700
Date: Thu, 19 Sep 2002 23:55:09 -0700
From: Hal Finney <hal@finney.org>
Message-Id: <200209200655.g8K6t9k17770@finney.org>
To: ietf-openpgp@imc.org, jon@callas.org
Subject: Re: Fixing the MDC language
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>

A couple of comments:

First, there is another typo I forgot to mention:

> includes all of the plaintext, and then also includes two octets of values
> 0xD0, 0x14.  These represent the encoding of a Modification Detection Code

The D0 was from an older version of the draft when we were going to
use tag 16 for the MDC packet.  In fact we chose tag 19, so 0xD0 should
be 0xD3.

The other point:

> The plaintext of the data to be encrypted is passed through the SHA-1 hash
> function, and the result of the hash is appended to the plaintext in a
> Modification Detection Code packet.  The input to the hash function includes
> the prefix data described above which acts as a weakly keyed hash;

This last sentence is not quite correct, the prefix data per se does not
act as a weakly keyed hash.  It acts as the key to a sort of keyed hash.
But it's not really a normal keyed hash, because the key is usually kept
a lot more secret than our pseudo-IV.

In any case I don't really think we ought to mention this keyed-hash
stuff.  It's not necessary to an implementor, and as a shorthand for
some kind of security analysis it is too brief to be meaningful.  I'd
suggest removing the "which acts as..." clause entirely.

Hal