NAI has decided not to include Twofish in the next release so that we
can try to come to agreement on an MDC packet and use that.
Here is a concrete proposal which represents what we have been discussing
most recently.
I think the only thing I have changed is that I am using version 1.
It's going to be wasteful of version numbers if we keep having to leapfrog
them. If we made this one 5, then the next time we make a change to
a packet we have to use 6, etc. It will be more economical to start
new packets at v1 and increment them as we make new versions of them.
I know this practice was not always followed in the past but it will be
better for the future.
As I described earlier, I propose not to have any mechanism for turning
the MDC on and off, or for selecting a hash algorithm, because these would
leave openings for an attacker to possibly modify this selector. He might
be able to turn off the MDC, which would completely defeat the purpose.
Another attack I have considered is that the attacker could strip off
the MDC packet (by removing the last 22 bytes of ciphertext) and change
the packet tag to an old-style symmetrically encrypted data packet.
However because we are handling the CFB SYNC differently it will produce
completely garbled data, which I view as an acceptable failure mode.
What do you think?
Hal
=====
5.X. Symmetrically Encrypted Integrity Protected Data Packet (Tag 15)
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 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 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.)