6.1. Encryption Specifications

6.1. Encryption Specifications

The following ASN.1 definition describes all encrypted messages. The
enc-part field which appears in the unencrypted part of messages in
section 5 is a sequence consisting of an encryption type, an optional
key version number, and the ciphertext.

This field identifies which encryption algorithm was used
to encipher the cipher. Detailed specifications for
selected encryption types appear later in this section.

kvno

This field contains the version number of the key under
which data is encrypted. It is only present in messages
encrypted under long lasting keys, such as principals'
secret keys.

cipher

This field contains the enciphered text, encoded as an
OCTET STRING.

The cipher field is generated by applying the specified encryption
algorithm to data composed of the message and algorithm-specific
inputs. Encryption mechanisms defined for use with Kerberos must
take sufficient measures to guarantee the integrity of the plaintext,
and we recommend they also take measures to protect against
precomputed dictionary attacks. If the encryption algorithm is not
itself capable of doing so, the protections can often be enhanced by
adding a checksum and a confounder.

The suggested format for the data to be encrypted includes a
confounder, a checksum, the encoded plaintext, and any necessary
padding. The msg-seq field contains the part of the protocol message
described in section 5 which is to be encrypted. The confounder,
checksum, and padding are all untagged and untyped, and their length
is exactly sufficient to hold the appropriate item. The type and
length is implicit and specified by the particular encryption type
being used (etype). The format for the data to be encrypted is
described in the following diagram:

In the above specification, UNTAGGED OCTET STRING(length) is the
notation for an octet string with its tag and length removed. It is
not a valid ASN.1 type. The tag bits and length must be removed from
the confounder since the purpose of the confounder is so that the
message starts with random data, but the tag and its length are
fixed. For other fields, the length and tag would be redundant if
they were included because they are specified by the encryption type.

One generates a random confounder of the appropriate length, placing
it in confounder; zeroes out check; calculates the appropriate
checksum over confounder, check, and msg-seq, placing the result in
check; adds the necessary padding; then encrypts using the specified
encryption type and the appropriate key.

Unless otherwise specified, a definition of an encryption algorithm
that specifies a checksum, a length for the confounder field, or an
octet boundary for padding uses this ciphertext format (The ordering
of the fields in the CipherText is important. Additionally, messages
encoded in this format must include a length as part of the msg-seq
field. This allows the recipient to verify that the message has not
been truncated. Without a length, an attacker could use a chosen
plaintext attack to generate a message which could be truncated,
while leaving the checksum intact. Note that if the msg-seq is an
encoding of an ASN.1 SEQUENCE or OCTET STRING, then the length is
part of that encoding.). Those fields which are not specified will be
omitted.

In the interest of allowing all implementations using a particular
encryption type to communicate with all others using that type, the
specification of an encryption type defines any checksum that is
needed as part of the encryption process. If an alternative checksum
is to be used, a new encryption type must be defined.

Some cryptosystems require additional information beyond the key and
the data to be encrypted. For example, DES, when used in cipher-
block-chaining mode, requires an initialization vector. If required,
the description for each encryption type must specify the source of
such additional information.