Subject: MDC Excerpts

From: Jon Callas <[email-masked]>
Date: Mon, 2 Oct 2000 15:36:23 -0700

5.12. Sym. Encrypted Integrity Protected Data Packet (Tag 15)

   The Symmetrically Encrypted Integrity Protected Data Packet is a
   variant of the Symmetrically Encrypted Data Packet. It is a new
   feature created for OpenPGP that addresses the problem of detecting
   a modification to encrypted data. It is used in combination with a
   Modification Detection Code Packet.

   There is a corresponding feature in the features signature subpacket
   that denotes that an implementation can properly use this packet
   type. An implementation SHOULD NOT use this packet when encrypting
   to a recipient that does not state it can use this packet, and
   SHOULD prefer this to older Symmetrically Encrypted Data Packet when
   possible.

   This 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
   decrypted packet in this packet's payload 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, 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.

   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.13. Modification Detection Code Packet (Tag 16)

   The Modification Detection Code packet contains a SHA-1 hash of
   plaintext data which is used to detect message modification.  It is
   only used with 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. The reason for this is that the hashing rules for
   modification detection include a one-octet tag and one-octet length
   in the data hash. While this is a bit restrictive, it reduces
   complexity.

[...]
[Yes, I know this is earlier in the document.]

5.2.3.24. Features

   (array of one-octet values)

   The features subpacket denotes which advanced OpenPGP features a
   user's implementation supports. This is so that as features are
   added to OpenPGP that cannot be backwards-compatible, a user can
   state that they can use that feature.

   This subpacket is similar to a preferences subpacket, and only
   appears in a self-signature.

   An implementation SHOULD NOT use a feature listed when sending to a
   user who does not state that they can use it.

   Defined features are:

       1 - Modification Detection (packets 15 and 16)

   If an implementation implements any of the defined features, it
   SHOULD implement the features subpacket, too.

---

From: Werner Koch <[email-masked]>
Date: Wed, 4 Oct 2000 10:55:49 +0200

>    (array of one-octet values)

We need a number for this signature sub packet.

>    SHOULD implement the features subpacket, too.

I have a problem with this.  Currently PGP 7 and GnuPG 1.0.2
implement this feature and use packets 15 and 16 when Twofish is
used.  A year back or so we had a long discussion about this MDC
packets and the use of Twofish.  I suggested that we should wait
with using Twofish until we had figured out how to do this MDC and
the require implementations to use the MDC packet if they use a
cipher with a blocklength not equal to 64 bits.

Requiring to use the MDC only if the feature packet is present
makes the code more complicated because an implementation has to
check the cipher preferences and the MDC feature.

The feature packet is a good thing because it enables us to use the
MDC even with with CAST5 or 3DES.  It should however say that this
feature is implictly assumed when a symmetrical cipher algorithm
with ablocklength different from 64 bits is used (or explitly
enumerate algorithms). I'd also appreciate if we can say that the
use of the MDC is a SHOULD for such algorithms.

  Werner

-- 
Werner Koch				GnuPG key:  621CC013
OpenIT GmbH                             http://www.OpenIT.de