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.

Hacking Tips & Tricks....: DES and Its Variations

Hacking Tips & Tricks....: DES and Its Variations: Originally developed by IBM, DES stands for Data Encryption Standard, an encryption block cipher. The U.S. government defined and end...

DES and Its Variations

Originally developed by IBM, DES stands for Data Encryption Standard, an encryption block cipher. The U.S. government defined and endorsed it in 1977 as an official standard. The details can be found in the official FIPS (Federal Information Processing Standards) publication.

DES has been studied extensively over the past 18 years and is the most well-known and widely used encryption system in the world. DES is a secret-key, symmetric cryptosystem. When DES is used for communication, the sender and receiver both must know the same secret key, because it’s used to encrypt and decrypt the message. DES was designed to be implemented in hardware operates relatively fast (compared to other encryption systems) on 64-bit blocks with a 56-bit key. It works well for bulk encryption, that is, for encrypting a large set of data.

DES has been recertified as an official U.S. government encryption standard every five years. The government last recertified DES in 1993, but has indicated that it might not recertify it again.

As far as is known, DES never has been broken with a practical attack, despite the efforts of many researchers over many years. The obvious method of attack is a brute-force exhaustive search of the key space. This takes 255 steps on average. Early on, someone suggested that a rich and powerful enemy could build a special-purpose computer capable of breaking DES by exhaustive search in a reasonable amount of time. Wiener estimated the cost of a specialized computer to perform such an exhaustive search at one million dollars—a sum within the budget of a moderate-sized corporation, or a special interest group. Martin Hellman later showed a time-memory trade-off that provides improvement over exhaustive search if memory space is plentiful, after an exhaustive precomputation. These ideas have fostered doubts about the security of DES. Accusations also flew that the NSA had intentionally weakened DES.

The consensus is that DES, used properly, is secure against all but the most powerful enemies. Triple encryption DES might be secure against anyone at all. Biham and Shamir have stated that they consider DES secure. When using DES, several practical considerations can affect the security of the encrypted data.

One should change DES keys frequently, to prevent attacks that require sustained data analysis. In a communications context, the sender or receiver must find a secure way to communicate the DES key to the other.

DES can be used for encryption in several officially defined modes. The U.S. Department of Commerce Federal Information Processing Standard 81, published in 1980, defines the four standard modes of operation (and numerous nonstandard ones, as well). Some are more secure than others. The four standard modes are as follows:

• ECB (Electronic Codebook). Encrypts each 64-bit block of plaintext consecutively under the same 56-bit DES key. This is the least secure method of implementing DES.
• n CBC (Cipher Block Chaining). Each 64-bit plaintext block is XORed with the previous ciphertext block before being encrypted with the DES key. Thus, the encryption of each block depends on previous blocks and the same 64-bit plaintext block encrypts to different ciphertext, depending on its context in the overall message. CBC mode helps protect against certain attacks, although not against exhaustive search or differential cryptanalysis.
• CFB (Cipher Feedback). Allows DES with block lengths less than 64 bits. It uses the previously generated cyphertext as input to DES to create a randomizer to combine with the next block of plaintext. In practice, CBC is the most widely used mode of DES, specified in several standards, including Kerberos.
• OFB (Output Feedback Mode). Is the same as CFB except it does not re-encrypt the cypherblock before using it as a randomizer. OFB is not as secure as CFB.

FIPS 46-1 (the federal standard defining DES) says, “The algorithm specified in this standard is to be implemented using hardware (not software) technology. Software implementations in general purpose computers are not in compliance with this standard.” Despite this, software implementations abound, and are used by government agencies.