Definition - What does Triple DES mean?

Triple Data Encryption Standard (DES) is a type of computerized cryptography where block cipher algorithms are applied three times to each data block. The key size is increased in Triple DES to ensure additional security through encryption capabilities. Each block contains 64 bits of data. Three keys are referred to as bundle keys with 56 bits per key. There are three keying options in data encryption standards: 1. 2. 3. All keys being independent Key 1 and key 2 being independent keys All three keys being identical

Key option #3 is known as triple DES. The triple DES key length contains 168 bits but the key security falls to 112 bits. The three key variant has a block size of 8 bytes (64-bits) and uses a key with 24 bytes. The DES implementation in Crypto++ ignores the parity bits (the least significant bits of each byte) in the key. Triple DES is advantageous because it has a significantly sized key length, which is longer than most key lengths affiliated with other encryption modes. However, the DES algorithm was replaced by the Advanced Encryption Standard by the National Institute of Standards and Technology (NIST). Thus, the Triple DES is now considered to be obsolete. Yet, it is often used in conjunction with Triple DES. It derives from single DES but the technique is used in triplicate and involves three sub keys and key padding when necessary, such as instances where the keys must be increased to 64 bits in length. Known for its compatibility and flexibility, software can easily be converted for Triple DES inclusion. Therefore, it may not be nearly as obsolete as deemed by NIST. Triple DES encrypts input data three times. The three keys are referred to as k1, k2 and k3. This technology is contained within the standard of ANSIX9.52. Triple DES is backward compatible with regular DES. Definition - What does RC5 mean?RC5 is a fast block cipher developed based on RC4. Set elements are reordered in RC5 algorithms. A distinct data block size, usually consisting of 64 bits, is transformed into another distinct-size block. Key size, block size and the number of rounds are convertible and variable in RC5 ciphers. RC5 uses key encryption and decryption as well as key expansion. Techopedia explains RC5 In 1994, Ronald Rivest designed RC5 for RSA Security. RC5 has a variable number of rounds ranging from 0 to 255 with block size bits of 32, 64 or 128. Keys can range from 0 to 2040 bits. Users can choose between rounds, block sizes and keys. When the output and input blocks and the keys are all the same size, an RC5 block can match the same number of block sizes from permutations to integers. RC5 is known for its technical flexibility and the security it provides. IDEA:International Data Encryption Algorithm (IDEA) is a block cipher designed by Xuejia Lai and James L. Massey of ETH-Zrich and was first described in 1991. It is a minor revision of an earlier cipher, PES (Proposed Encryption Standard); IDEA was originally called IPES (Improved PES). IDEA was used as the symmetric cipher in early versions of the Pretty Good Privacy cryptosystem.IDEA was to develop a strong encryption algorithm, which would replace

the DES procedure developed in the U.S.A. in the seventies. It is also interesting in that it entirely avoids the use of any lookup tables or S-boxes. When the famous PGP email and file encryption product was designed by Phil Zimmermann, the developers were looking for maximum security. IDEA was their first choice for data encryption based on its proven design and its great reputation. The IDEA encryption algorithm provides high level security not based on keeping the algorithm a secret, but rather upon ignorance of the secret key is fully specified and easily understood is available to everybody is suitable for use in a wide range of applications can be economically implemented in electronic components (VLSI Chip) can be used efficiently may be exported world wide is patent protected to prevent fraud and piracy Description of IDEA

The block cipher IDEA operates with 64-bit plaintext and cipher text blocks and is controlled by a 128-bit key. The fundamental innovation in the design of this algorithm is the use of operations from three different algebraic groups. The substitution boxes and the associated table lookups used in the block ciphers available to-date have been completely avoided. The algorithm structure has been chosen such that, with the exception that different key sub-blocks are used, the encryption process is identical to the decryption process. CAST:In cryptography, CAST-128 (alternatively CAST5) is a symmetric-key block cipher used in a number of products, notably as the default cipher in some versions ofGPG and PGP. It has also been approved for Canadian government use by the Communications Security Establishment. The algorithm was created in 1996 byCarlisle Adams and Stafford Tavares using the CAST design [1] procedure. Another member of the CAST family of ciphers, CAST-256 (a former AES candidate) was derived from CAST-128. According to some sources, the CAST name is based on the initials of its inventors, though Bruce Schneier reports [2] the authors' claim that "the name should conjure up images of randomness". CAST-128 is a 12- or 16-round Feistel network with a 64-bit block size and a key size of between 40 to 128 bits (but [3] only in 8-bit increments). The full 16 rounds are used when the key size is longer than 80 bits. Components include large 832-bit S-boxes based on bent functions, key-dependent rotations, modular addition and subtraction, and XOR operations. There are three alternating types of round function, but they are similar in structure and differ only in the choice of the exact operation (addition, subtraction or XOR) at various points. Although Entrust holds a patent on the CAST design procedure, CAST-128 is available worldwide on a royalty-free basis for commercial and non-commercial uses. Blowfish is an encryption algorithm that can be used as a replacement for the DES or IDEAalgorithms. It is a symmetric (that is, a secret or private key) block cipher that uses a variable-length key, from 32 bits to 448 bits, making it useful for both domestic and exportable use. (The U. S. government forbids

the exportation of encryption software using keys larger than 40 bits except in special cases.) Blowfish was designed in 1993 by Bruce Schneier as an alternative to existing encryption algorithms. Designed with 32-bit instruction processors in mind, it is significantly faster than DES. Since its origin, it has been analyzed considerably. Blowfish is unpatented, license-free, and available free for all uses. Abstract This memo describes the use of the HMAC algorithm [RFC-2104] in conjunction with the MD5 algorithm [RFC-1321] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with MD5 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. 1. Introduction This memo specifies the use of MD5 [RFC-1321] combined with HMAC [RFC-2104] as a keyed authentication mechanism within the context of the Encapsulating Security Payload and the Authentication Header. The goal of HMAC-MD5-96 is to ensure that the packet is authentic and cannot be modified in transit. HMAC is a secret key authentication algorithm. Data integrity and data origin authentication as provided by HMAC are dependent upon the scope of the distribution of the secret key. If only the source and destination know the HMAC key, this provides both data origin authentication and data integrity for packets sent between the two parties; if the HMAC is correct, this proves that it must have been added by the source. HMAC-MD5-96 is a secret key algorithm. While no fixed key length is specified in [RFC-2104], for use with either ESP or AH a fixed key length of 128-bits MUST be supported. Key lengths other than 128bits MUST NOT be supported (i.e. only 128-bit keys are to be used by HMAC-MD5-96). A key length of 128-bits was chosen based on the recommendations in [RFC-2104] (i.e. key lengths less than the authenticator length decrease security strength and keys longer than the authenticator length do not significantly increase security strength). [RFC-2104] discusses requirements for key material, which includes a discussion on requirements for strong randomness. A strong pseudorandom function MUST be used to generate the required 128-bit key. At the time of this writing there are no specified weak keys for use with HMAC. This does not mean to imply that weak keys do not exist. If, at some point, a set of weak keys for HMAC are identified, the use of these weak keys must be rejected followed by a request for replacement keys or a newly negotiated Security Association. [ARCH] describes the general mechanism for obtaining keying material

when multiple keys are required for a single SA (e.g. when an ESP SA requires a key for confidentiality and a key for authentication). In order to provide data origin authentication, the key distribution mechanism must ensure that unique keys are allocated and that they are distributed only to the parties participating in the communication. [RFC-2104] makes the following recommendation with regard to rekeying. Current attacks do not indicate a specific recommended frequency for key changes as these attacks are practically infeasible. However, periodic key refreshment is a fundamental security practice that helps against potential weaknesses of the function and keys, reduces the information avaliable to a cryptanalyst, and limits the damage of an exposed key. Abstract This memo describes the use of the HMAC algorithm [RFC-2104] in conjunction with the SHA-1 algorithm [FIPS-180-1] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload [ESP] and the revised IPSEC Authentication Header [AH]. HMAC with SHA-1 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. 1. Introduction This memo specifies the use of SHA-1 [FIPS-180-1] combined with HMAC [RFC-2104] as a keyed authentication mechanism within the context of the Encapsulating Security Payload and the Authentication Header. The goal of HMAC-SHA-1-96 is to ensure that the packet is authentic and cannot be modified in transit. HMAC is a secret key authentication algorithm. Data integrity and data origin authentication as provided by HMAC are dependent upon the scope of the distribution of the secret key. If only the source and destination know the HMAC key, this provides both data origin

Madson & Glenn RFC 2404

Standards Track

[Page 1]

The Use of HMAC-SHA-1-96 within ESP and AH November 1998

authentication and data integrity for packets sent between the two parties; if the HMAC is correct, this proves that it must have been added by the source.

In this memo, HMAC-SHA-1-96 is used within the context of ESP and AH. For further information on how the various pieces of ESP - including the confidentiality mechanism -- fit together to provide security services HMAC-SHA-1-96 is a secret key algorithm. While no fixed key length is specified in [RFC-2104], for use with either ESP or AH a fixed key length of 160-bits MUST be supported. Key lengths other than 160bits MUST NOT be supported (i.e. only 160-bit keys are to be used by HMAC-SHA-1-96). A key length of 160-bits was chosen based on the recommendations in [RFC-2104] (i.e. key lengths less than the authenticator length decrease security strength and keys longer than the authenticator length do not significantly increase security strength). [RFC-2104] discusses requirements for key material, which includes a discussion on requirements for strong randomness. A strong pseudorandom function MUST be used to generate the required 160-bit key. At the time of this writing there are no specified weak keys for use with HMAC. This does not mean to imply that weak keys do not exist. If, at some point, a set of weak keys for HMAC are identified, the use of these weak keys must be rejected followed by a request for replacement keys or a newly negotiated Security Association. [ARCH] describes the general mechanism for obtaining keying material when multiple keys are required for a single SA (e.g. when an ESP SA requires a key for confidentiality and a key for authentication). In order to provide data origin authentication, the key distribution mechanism must ensure that unique keys are allocated and that they are distributed only to the parties participating in the communication. [RFC-2104] makes the following recommendation with regard to rekeying. Current attacks do not indicate a specific recommended frequency for key changes as these attacks are practically infeasible. However, periodic key refreshment is a fundamental security practice that helps against potential weaknesses of the function and keys, reduces the information avaliable to a cryptanalyst, and limits the damage of an exposed key.