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 MUST support decrypting these packets and SHOULD prefer generating them to the older Symmetrically Encrypted Data packet when possible.
Since this data packet protects against modification attacks, this standard encourages its proliferation.
While blanket adoption of this data packet would create interoperability problems, rapid adoption is nevertheless important.
An implementation SHOULD specifically denote support for this packet, but it MAY infer it from other mechanisms.¶
For example, an implementation might infer from the use of a cipher such as Advanced Encryption Standard (AES) or Twofish that a user supports this feature.
It might place in the unhashed portion of another user's key signature a Features subpacket.
It might also present a user with an opportunity to regenerate their own self-signature with a Features subpacket.¶
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 a Literal Data packet or Compressed Data packet).
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, respectively.
Unlike the Symmetrically Encrypted Data Packet, no special CFB resynchronization is done after encrypting this prefix data.
See Section 13.9 for more details.¶
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.
The input to the hash function includes the prefix data described above; it includes all of the plaintext, and then also includes 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 (MDC) 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, including the prefix data as well as 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 failure of the MDC indicates that the message has been modified and MUST be treated as a security problem.
Failures include a difference in the hash values, but also the absence of an MDC packet, or an MDC packet in any position other than the end of the plaintext.
Any failure SHOULD be reported to the user.¶
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.¶
- NON-NORMATIVE EXPLANATION¶
- The MDC system, as packets 18 and 19 are called, were created to
provide an integrity mechanism that is less strong than a
signature, yet stronger than bare CFB encryption.¶
- It is a limitation of CFB encryption that damage to the ciphertext
will corrupt the affected cipher blocks and the block following.
Additionally, if data is removed from the end of a CFB-encrypted
block, that removal is undetectable. (Note also that CBC mode has
a similar limitation, but data removed from the front of the block
- The obvious way to protect or authenticate an encrypted block is
to digitally sign it. However, many people do not wish to
habitually sign data, for a large number of reasons beyond the
scope of this document. Suffice it to say that many people
consider properties such as deniability to be as valuable as
- OpenPGP addresses this desire to have more security than raw
encryption and yet preserve deniability with the MDC system. An
MDC is intentionally not a MAC. Its name was not selected by
accident. It is analogous to a checksum.¶
- Despite the fact that it is a relatively modest system, it has
proved itself in the real world. It is an effective defense to
several attacks that have surfaced since it has been created. It
has met its modest goals admirably.¶
- Consequently, because it is a modest security system, it has
modest requirements on the hash function(s) it employs. It does
not rely on a hash function being collision-free, it relies on a
hash function being one-way. If a forger, Frank, wishes to send
Alice a (digitally) unsigned message that says, "I've always
secretly loved you, signed Bob", it is far easier for him to
construct a new message than it is to modify anything intercepted
from Bob. (Note also that if Bob wishes to communicate secretly
with Alice, but without authentication or identification and with
a threat model that includes forgers, he has a problem that
transcends mere cryptography.)¶
- Note also that unlike nearly every other OpenPGP subsystem, there
are no parameters in the MDC system. It hard-defines SHA-1 as its
hash function. This is not an accident. It is an intentional
choice to avoid downgrade and cross-grade attacks while making a
simple, fast system. (A downgrade attack would be an attack that
replaced SHA-256 with SHA-1, for example. A cross-grade attack
would replace SHA-1 with another 160-bit hash, such as
RIPE-MD/160, for example.)¶
- However, given the present state of hash function cryptanalysis
and cryptography, it may be desirable to upgrade the MDC system to
a new hash function. See Section 13.11 for guidance.¶