ietf-openpgp
[Top] [All Lists]

MDC Excerpts

2000-10-02 15:44:08
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.


<Prev in Thread] Current Thread [Next in Thread>