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