Subject: Fixing the MDC language

From: Jon Callas <[email-masked]>
Date: Thu, 19 Sep 2002 23:30:09 -0700

Here's a proposed fix to the oops that Hal found:

-----

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; it
includes all of the plaintext, and then also includes two octets of values
0xD0, 0x14.  These represent the encoding of a Modification Detection Code
packet tag and length field of 20 octets.

The resulting hash value is stored in a Modification Detection Code packet
which MUST use the two octet encoding just given to represent its tag and
length field.  The body of the MDC packet is the 20 octet output of the
SHA-1 hash.

The Modification Detection Code packet is appended to the plaintext and
encrypted along with the plaintext using the same CFB context.

During decryption, the plaintext data should be hashed with SHA-1, including
the prefix data as well as the packet tag and length field of the
Modification Detection Code packet.  The body of the MDC packet, upon
decryption, is compared with the result of the SHA-1 hash.  Any difference
in hash values is an indication that the message has been modified and
SHOULD be reported to the user. Likewise, the absence of an MDC packet, or
an MDC packet in any position other than the end of the plaintext, also
represent message modifications and SHOULD also be reported.

-----

I can quickly (like in 30 minutes) pop off another draft if this is
acceptable. Comments ASAP.

    Jon

---

From: "Hal Finney" <[email-masked]>
Date: Thu, 19 Sep 2002 23:55:09 -0700

A couple of comments:

> 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 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

---

From: John Kane <[email-masked]>
Date: Sat, 21 Sep 2002 06:41:57 -0400

jc> contains a SHA-1 hash of plaintext data
  jc> The plaintext of the data to be encrypted

An ambiguity quibble.  This is meant to refer to the octets of the
compressed/encoded packet as seen by the CFB envelope, as opposed
to the uncompressed/decoded data as seen by the end users?
I see the hint buried in 5.14, but pleeease make it more explicit in 5.13...