Subject: Re: Return to MDC packet discussion

From: [email-masked]
Date: Tue, 4 Apr 2000 11:29:13 -0700

Werner Koch wrote:
> > 5.X. Symmetrically Encrypted Integrity Protected Data Packet (Tag 15)
>
> >    Unlike the Symmetrically Encrypted Data Packet, no special CFB
> >    resynchronization is done after encrypting this prefix data.
>
> Good.
>
> This proposal is fine with me.  To implement this we have to add
> feature flags to the public keys or choose an implicit way to decide
> when a tag-15 packet should be used or is expected.  Using cipher
> algorithms with a blocklength other the 64 bit should still work 
> as an implicit criteria.

Due to our long corporate lead times for testing and quality assurance I
would like to incorporate this feature on at least a read-only basis for
the next release of PGP, which will be in mid to late summer.  By making
sure we can read the integrity protected packets in our next version,
which will be v7.0, we will be able to start using them that much sooner.

In implementing this I realized that the proposed tag numbers were already
being used in earlier versions of PGP.  I would like to use packet tag
numbers 18 and 19 for the integrity protected encrypted packet, and the
MDC packet, respectively.  The suggested draft language below is the
same as in my previous message, but with the tag numbers updated.

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 does not include the prefix data described above;
   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,
   not including the prefix data but including 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: Wed, 5 Apr 2000 16:39:16 +0200

> the next release of PGP, which will be in mid to late summer.  By making

Okay, I'll implement the read-write in GnuPG within the next few weeks. 

> numbers 18 and 19 for the integrity protected encrypted packet, and the

No problem.

  Werner

-- 
Werner Koch				OpenPGP key 621CC013
OpenIT GmbH                             tel   +49 211 465357
Birkenstr. 12                           email [email-masked]
D-40233 Düsseldorf                      http://www.openit.de

---

From: Jon Callas <[email-masked]>
Date: Sun, 9 Apr 2000 14:22:04 -0700

I have a question. Why not use one of the packet numbers reserved for
experimental use? That's why they're there. This use is experimental.

If no one's going to use them, then why don't I just remove them from the
standard?

	Jon

---

From: Werner Koch <[email-masked]>
Date: Mon, 10 Apr 2000 11:44:14 +0200

> experimental use? That's why they're there. This use is experimental.

I thought we agreed on the the MAC extension so why not use regular
packet numbers.  We did this for Twofish as well.

However it is fine for me to use the experimental numbers.  But then we
should add some magic numbers to those packets, so that we don't run
into problems when another implemenation uses them for another
purpose.

> If no one's going to use them, then why don't I just remove them from the

Please, don't do that.

  Werner

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