The following structure is used for a checksum:
Checksum = {
cksumtype[0] INTEGER,
checksum[1] BYTE STRING
}
·
- cksumtype. Indicates the algorithm used to generate the accompanying checksum.
- checksum. Contains the checksum itself, encoded as byte string.
Negative values for the checksum type are reserved for local
use. All non-negative values are reserved for officially assigned type fields
and interpretations.
Kerberos supports a variety of checksums. In addition,
specific implementations may also support implementation-specific checksums.
The following sections describe the standard checksums supported by Kerberos.
Selection of a specific checksum is up to the application providing the
information.
Note Kerberos uses checksums that can be classified by two
properties: whether they’re collision-proof and whether they’re keyed. A
checksum is said to be collision-proof if finding two plaintexts that enerate the same checksum value is infeasible.
This means that it is not possible for someone to change a message in a manner
that leaves the checksum unchanged. Any change to the message makes an
unpredictable change to the checksum.
A keyed checksum requires a key to perturb or initialize the
algorithm. Keyed checksums are usually cryptographically based. This makes them
collision-proof, because the randomizing effect of the encryption makes it
impossible to predict the change to the checksum of any change in the message.
To prevent message-stream modification by an active
attacker, unkeyed checksums should be used only when the checksum and message
will be subsequently encrypted. For example, the checksums defined as part of
the encryption algorithms covered earlier in this section are encrypted.
Collision-proof checksums can be made tamperproof as well if
the checksum value is encrypted before inclusion in a message. In such cases,
combining the checksum and the encryption algorithm is considered a separate
checksum algorithm. RSA-MD5 encrypted using DES is a new checksum algorithm of
type RSA-MD5-DES. For most keyed checksums, as well as for the encrypted forms
of collision-proof checksums, Kerberos prepends a confounder before calculating
the checksum.
The CRC-32 Checksum
(crc32)
The CRC-32 checksum calculates a checksum based on a cyclic
redundancy check as described in ISO 3309. The resulting checksum is four bytes
long. The CRC-32 is neither keyed nor collision-proof. Using this checksum is
not recommended, because an attacker might be able to generate an alternative
message that satisfies the checksum. Use collision-proof checksums for
environments in which such attacks represent a significant threat such as the
Internet, or an application with high value information.
