Checksums

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.

Hacking Tips & Tricks....: Encryption Keys & Encryption Systems

Hacking Tips & Tricks....: Encryption Keys & Encryption Systems: Kerberos maintains a database of active encryption keys. The following structure shows the encoding of an encryption key: Encrypti...

Encryption Keys & Encryption Systems

Kerberos maintains a database of active encryption keys. The following structure shows the encoding of an encryption key:

EncryptionKey =

{

keytype[0] INTEGER,

keyvalue[1] BYTE STRING

}

• keytype. Specifies the type of encryption key that follows in the keyvalue field. It almost always corresponds to the encryption algorithm used to generate the encrypted data, though more than one algorithm may use the same type of key (the mapping is many to one). This might happen, for example, if the encryption algorithm uses an alternative checksum algorithm for an integrity check or a different chaining mechanism.
• keyvalue. Contains the key itself, encoded as a byte string.

All negative values for the encryption key type are reserved for local use. All non-negative values are reserved for officially assigned type fields and interpretations.

Encryption Systems

Kerberos defines a number of encryption systems that may be selected for use in a message. In addition, it also provides a mechanism for a developer to add his own encryption method. When a principal sends a message using an encryption method, the destination principal must also support the encryption method. If it doesn’t, an error message will be returned.

The NULL Encryption System (null)

If no encryption is in use, the encryption system is said to be a NULL encryption system. A NULL encryption system has no checksum, confounder, or padding. The ciphertext simply is the plaintext. The NULL encryption system uses the NULL key, which is zero bytes in length and has keytype zero (0).

DES in CBC Mode with a CRC-32 Checksum (des-cbc-crc)

The des-cbc-crc encryption mode encrypts information under the Data Encryption Standard using the Cipher Block Chaining (CBC) mode. A CRC-32 checksum is applied to the confounder and message sequence and placed in the checksum field. The details of the encryption of this data are identical to those for the des-cbc-md5 encryption mode.

Because the CRC-32 checksum is not collision-proof, different messages can be generated having the same checksum. An attacker could use a probabilistic chosen plaintext attack to generate a valid message, even in the face of a confounder. Using collision-proof checksums is recommended for environments in which such attacks represent a significant threat. Any time the message will pass through a hostile environment, such as the Internet, or any time the message has great value, as in financial transactions, a collision-proof checksum should be used.

Note:  Using the CRC-32 as the checksum for ticket or authenticator no longer is mandated as an interoperability requirement for Kerberos version 5 Specification 1.

DES in CBC Mode with an MD4 Checksum (des-cbc-md4)

The des-cbc-md4 encryption mode encrypts information under DES using the Cipher Block Chaining mode. An MD4 checksum is applied to the confounder and message sequence (msgseq) and placed in the cksum field. The details of the encryption of this data are identical to those for the des-cbc-md5 encryption mode.

DES in CBC Mode with an MD5 Checksum (des-cbc-md5)

The des-cbc-md5 encryption mode encrypts information under the Data Encryption Standard using the Cipher Block Chaining mode. An MD5 checksum is applied to the confounder and message sequence and placed in the cksum field.

Plaintext and DES ciphertext are encoded as 8-byte blocks that are concatenated to make the 64-bit inputs for the DES algorithms. As a result, the data to be encrypted must be padded to an 8-byte boundary before encryption. Encryption under DES using Cipher Block Chaining requires an additional input in the form of an initialization vector. Unless otherwise specified, zero should be used as the initialization vector. Kerberos’ use of DES requires an 8-byte confounder.

The DES specifications identify some weak and semi-weak keys. Those keys are not to be used for encrypting Kerberos messages. Because of the way that keys are derived for the encryption of checksums, keys shall not be used that yield weak or semi-weak keys when eXclusive-ORed with the constant F0F0F0F0F0F0F0F0.

A DES key is 8-bytes of data, with keytype one (1). This consists of 56 bits of key, and 8 parity bits (one per byte). To generate a DES key from a password, the password normally must have the Kerberos realm name and each component of the principal’s name appended, then padded with ASCII nulls to an 8-byte boundary. This string is then fan-folded and eXclusive-ORed with itself to form an 8-byte DES key. The parity is corrected on the key, and it is used to generate a DES-CBC checksum on the initial string (with the realm and name appended). Next, parity is corrected on the CBC checksum. If the result matches a “weak” or “semi-weak” key as described in the DES specification, it is eXclusive-ORed with the constant 00000000000000F0. Finally, the result is returned as the key.

Hacking Tips & Tricks....: Encryption Specifications

Hacking Tips & Tricks....: Encryption Specifications: The following structure describes all encrypted messages. The encrypted field that appears in the unencrypted part of messages is a se...

Encryption Specifications

The following structure describes all encrypted messages. The encrypted field that appears in the unencrypted part of messages is a sequence that consists of an encryption type, an optional key version number, and the ciphertext.

EncryptedData = 

{

etype[0] INTEGER -- Encryption Type

kvno[1] INTEGER OPTIONAL,

cipher[2] BYTE STRING -- ciphertext

}

• etype. Identifies the encryption algorithm used to encrypt the cipher.
• kvno. Contains the version number of the key under which data is encrypted. Present in messages encrypted under long-lasting keys, such as principals’ secret keys. Used to determine which key to use when a ticket is valid across a change in key, such as when a user changes his password.
• cipher. Contains the encrypted field(s).

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. The protections often can 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 that is to be encrypted. The format for the data to be encrypted is described in the following:

{

confounder[0] BYTE STRING(conf_length) OPTIONAL,

check[1] BYTE STRING(checksum_length) OPTIONAL,

msg-seq[2] MsgSequence,

pad BYTE STRING(pad_length) OPTIONAL

}

The first step is to create a confounder. The confounder is a random sequence the same length as the encryption blocking length. Its purpose is to confuse or confound certain types of brute force attacks. The second step is to zero out the checksum. Next, calculate the appropriate checksum over confounder, the zeroed checksum, and the message. Place the result in the checksum. Add the necessary padding to bring the total length to a multiple of the encryption blocking length. Encrypt using the specified encryption type and the appropriate key.

Unless otherwise specified, a definition of a Kerberos encryption algorithm 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 message field, to enable the recipient to verify that the message has not been truncated. Without a length, an attacker could generate a message that could be truncated, leaving the checksum intact.

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

Some encryption systems require additional information beyond the key and the data to be encrypted. When DES is used in Cipher Block Chaining mode, for example, it requires an initialization vector. If required, the description for each encryption type must specify the source of such additional information.

Hacking Tips & Tricks....: Encryption and Checksum Specifications

Hacking Tips & Tricks....: Encryption and Checksum Specifications: The Kerberos protocols described in the RFC are designed to use stream encryption ciphers, such as the Data Encryption Standard (DES),...

Encryption and Checksum Specifications

The Kerberos protocols described in the RFC are designed to use stream encryption ciphers, such as the Data Encryption Standard (DES), in conjunction with block chaining and checksum methods. Encryption is used to prove the identities of the network entities participating in message exchanges. The Key Distribution Center for each realm is trusted by all principals registered in that realm to store a secret key in confidence. Proof of knowledge of this secret key is used to verify the authenticity of a principal.

The Key Distribution Center uses the principal’s secret key (in the Authentication Server exchange) or a shared session key (in the Ticket Granting Server exchange) to encrypt responses to ticket requests. The capability to obtain the secret key or session key implies knowing the appropriate keys and the identity of the Key Distribution Center. The capability of a principal to decrypt the Key Distribution Center response and present a ticket and a properly formed authenticator (generated with the session key from the Key Distribution Center response) to a service verifies the identity of the principal. Likewise, the capability of the service to extract the session key from the ticket and prove its knowledge thereof in a response verifies the identity of the service.

The Kerberos protocols generally assume that the encryption used is secure from cryptanalysis. Sometimes, though, the order of fields in the encrypted portions of messages is arranged to minimize the effects of poorly chosen keys. Choosing good keys still is important. If keys are derived from user-typed passwords, those passwords need to be chosen well to make brute force attacks more difficult. Poorly chosen keys still make easy targets for intruders.

The following sections specify the encryption and checksum mechanisms currently defined for Kerberos and describe the encoding, chaining, and padding requirements for each. For encryption methods, placing random information (often referred to as a confounder) at the start of the message is often a good idea. The requirements for a confounder are specified along with each encryption mechanism.

Some encryption systems use a block-chaining method to improve the security characteristics of the ciphertext. These chaining methods often don’t provide an integrity check upon decryption. Such systems (such as DES in Cipher Block Chaining mode) must be augmented using a checksum of the plaintext that can be verified at decryption and used to detect any tampering or damage. Such checksums should be good at detecting burst errors in the input. If any damage is detected, the decryption routine is expected to return an error indicating the failure of an integrity check. Each encryption type is expected to provide and verify an appropriate checksum. The specification of each encryption method sets out its checksum requirements.

Finally, if a key is to be derived from a user’s password, an algorithm for converting the password to a key of the appropriate type is required. The string-to-key function ideally should be one-way and mapping should be different in different realms, because users registered in more than one realm often use the same password in each. An attacker compromising the Kerberos server in one realm should not be able to just obtain or derive the user’s key in another realm.

Hacking Tips & Tricks....: Encryption Export Issues

Hacking Tips & Tricks....: Encryption Export Issues: All cryptographic products need export licenses from the State Department, acting under authority of the International Traffic in Arms...

Encryption Export Issues

All cryptographic products need export licenses from the State Department, acting under authority of the International Traffic in Arms Regulation (ITAR). ITAR defines cryptographic devices, including software, as munitions. The U.S. government has historically been reluctant to grant export licenses for encryption products it sees as stronger than a certain non-publicly assigned level. Under current regulations, a vendor seeking to export a product using cryptography first submits a request to the State Department’s Defense Trade Control office. Export jurisdiction then can be passed to the Department of Commerce, whose export procedures generally are simple and efficient. If jurisdiction remains with the State Department, then further (perhaps lengthy) review must occur before export can be approved or denied. The NSA sometimes becomes directly involved at this point. The details of the export approval process change frequently.

The NSA has de facto control over export of cryptographic products. The State Department does not grant licenses without NSA approval and routinely grants them whenever NSA does approve. Therefore, policy decisions concerning exporting cryptography ultimately rest with the NSA.

The NSA’s stated policy is not to restrict export of cryptography for authentication. Its concern lies only with the use of cryptography for privacy. A vendor seeking to export a product for authentication is granted an export license only so long as it can demonstrate that the product cannot be easily modified for encryption. This is true even for very strong systems, such as RSA with large key sizes. Furthermore, the bureaucratic procedures are simpler for authentication products than for privacy products. An authentication product needs NSA and State Department approval only once, whereas an encryption product could need approval for every sale or every product revision.

The U.S. State Department and the NSA strictly regulates export of DES, in hardware or software. The government rarely approves export of DES, although DES is widely available overseas. Software developers in many countries have produced DES products from the published specifications. These products are functionally compatible with U.S. products. Financial institutions and foreign subsidiaries of U.S. companies are exceptions.

Export policy currently is a matter of great controversy. Many software and hardware vendors consider current export regulations overly restrictive and burdensome. The Software Publishers Association (SPA), a software industry group, has recently been negotiating with the government to get export license restrictions eased. One agreement was reached that allows simplified procedures for export of two bulk encryption ciphers, RC2 and RC4, when the key size is limited. Also, export policy is less restrictive for foreign subsidiaries and overseas offices of U.S. companies.

In March 1992, the Computer Security and Privacy Advisory Board voted unanimously to recommend a national review of cryptography policy, including export policy. The Board is an official advisory board whose members are drawn from the government and the private sector.

The Board stated that a public debate is the only way to reach a consensus policy to best satisfy competing interests. National security and law enforcement agencies like restrictions on cryptography, especially for export, whereas other government agencies and private industry want greater freedom for using and exporting cryptography. Export policy has traditionally been decided solely by agencies concerned with national security, without much input from those who want to encourage commerce in cryptography. U.S. export policy could undergo significant changes in the next few years.

Note: The legal status of encryption in many countries has been placed on the World Wide Web. You can access it using the following URL:     

http://web.cnam.fr/Network/Crypto/

In much of the civilized world, encryption is legal or at least tolerated. In some countries, however, such activities can land you before a firing squad! Check with the laws in your country before you use any encryption product. Some countries in which encryption is illegal are Russia, France, Iran, and Iraq.