Subject: Revised MDC packet spec

From: [email-masked]
Date: Thu, 15 Jun 2000 15:28:08 -0700

Based on internal discussions we would like to make a small change to
the Symmetrically Encrypted Integrity Protected Data Packet format.
We would like to include the random bytes which precede the plaintext
in the hash.  This will make the hash value less predictable and would
make an attacker's job harder.  It is also somewhat simpler conceptually
because now the material which is hashed is the same as the material
which is encrypted, except for the last 20 bytes.

Also Werner pointed out a typo in the previous draft, the 0xD0 value
should be 0xD3 to match the MDC packet CTB.  The revised draft follows.

Hal Finney
PGP.COM

============

5.X. Symmetrically Encrypted Integrity Protected Data Packet (Tag 18)

   The Symmetrically Encrypted Integrity Protected Data packet contains
   data encrypted with a symmetric-key algorithm and protected against
   modification by the SHA-1 hash algorithm. When it has been decrypted,
   it will typically contain other packets (often literal data packets
   or compressed data packets).  The last such decrypted packet must be
   a Modification Detection Code packet.

   The body of this packet consists of:

     - A one-octet version number.  The only currently defined value is 1.

     - Encrypted data, the output of the selected symmetric-key cipher
       operating in Cipher Feedback mode with shift amount equal to the
       block size of the cipher (CFB-n where n is the block size).

   The symmetric cipher used MUST be specified in a Public-Key or
   Symmetric-Key Encrypted Session Key packet that precedes the
   Symmetrically Encrypted Data Packet.  In either case, the cipher
   algorithm octet is prefixed to the session key before it is
   encrypted.

   The data is encrypted in CFB mode, with a CFB shift size equal to
   the cipher's block size.  The Initial Vector (IV) is specified as
   all zeros.  Instead of using an IV, OpenPGP prefixes an octet string
   to the data before it is encrypted.  The length of the octet string
   equals the block size of the cipher in octets, plus two.  The first
   octets in the group, of length equal to the block size of the cipher,
   are random; the last two octets are each copies of their 2nd preceding
   octet.  For example, with a cipher whose block size is 128 bits or 16
   octets, the prefix data will contain 16 random octets, then two more
   octets, which are copies of the 15th and 16th octets, respectivelly.
   Unlike the Symmetrically Encrypted Data Packet, no special CFB
   resynchronization is done after encrypting this prefix data.

   The repetition of 16 bits in the random data prefixed to the message
   allows the receiver to immediately check whether the session key
   is incorrect.

   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.  Specifically, the input to
   the hash function includes the prefix octet string described above
   (equal in length to the cipher block size, plus two octets), followed
   by all of the plaintext, and then also two octets of values 0xD3, 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 decrypted data should be hashed with SHA-1,
   including the prefix octet string, the plaintext itself and also the
   packet tag and length field of the Modification Detection Code packet.
   The body of the MDC packet, upon decryption, should be 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.

   Note: future designs of new versions of this packet should consider
   rollback attacks since it will be possible for an attacker to change
   the version back to 1.

5.Y Modification Detection Code Packet (Tag 19)

   The Modification Detection Code packet contains a SHA-1 hash of
   plaintext data which is used to detect message modification.  It is
   only used in the context of a Symmetrically Encrypted Integrity
   Protected Data packet.  The Modification Detection Code packet MUST
   be the last packet in the plaintext data which is encrypted in the
   Symmetrically Encrypted Integrity Protected Data packet, and MUST
   appear in no other place.

   A Modification Detection Code packet MUST have a length of 20 octets.

   The body of this packet consists of:

     - A 20-octet SHA-1 hash of the preceding plaintext data of the
       Symmetrically Encrypted Integrity Protected Data packet, not
       including prefix data but including the tag and length byte of
       the Modification Detection Code packet.

   Note that the Modification Detection Code packet MUST always use a
   new-format encoding of the packet tag, and a one-octet encoding of
   the packet length.  (These requirements are already imposed by the
   rules for tag and length encoding.)

---

From: Werner Koch <[email-masked]>
Date: Fri, 16 Jun 2000 09:42:34 +0200

Hi, 

> the Symmetrically Encrypted Integrity Protected Data Packet format.

This is fine with me.  

One suggestion:  Add a note that the old PGP sync mode is not used with
the wew packet 18.  

  Werner
  
-- 
Werner Koch				OpenPGP key 621CC013
OpenIT GmbH                             tel +49 211 239577-0
Birkenstr. 12                           email   [email-masked]
D-40233 Duesseldorf                     http://www.OpenIT.de

---

From: Tom Zerucha <[email-masked]>
Date: Fri, 16 Jun 2000 16:53:09 -0400

> One suggestion:  Add a note that the old PGP sync mode is not used with

Did I miss something?  The description of the new type 18 packet
indicates a prefix that looks like the PGP-sync prefix used elsewhere.

But I didn't see the resync operation that is done everywhere else (I
didn't read that carefully).

So if I understand correctly, we are going to use the prefix but NOT
going to do the resync?