This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
This paper is talking about the Implementation of International Data Encryption Algorithm (IDEA) in Cryptographic Message Syntax (CMS) which I specify on Secure/Multipurpose Internet Mail Extension (S/MIME). The reason why IDEA will categories in weak key and some limitation in security. There will be some criticize related about the security over the network.
International Data Encryption Algorithm (IDEA) is a symmetric block cipher designed by James Massey and Xuejia Lai in 1991. The algorithm was intended as a replacement for the Data Encryption Standard (DES). IDEA is a minor revision of Proposed Encryption Standard (PES) and was originally called as Improved PES (IPES).
Cryptographic Message Syntax (CMS) is the IETF's standard for cryptographically protected messages. It is use to describes an encapsulation syntax for data protection. It supports digital signatures, message authentication codes, and encryption . S/MIME is constructed as an open system. Its functionality for information security purposes can be flexibly extended to meet new requirements. At the same time it is assured that extended systems will be compatible with non-extended systems. The general functional capabilities and preferences of S/MIME are specified by the registered list of S/MIME object identifiers (OIDs). The set of S/MIME functions provided by a client is expressed by the S/MIME capabilities attribute. This attribute contains a list of OIDs of supported cryptographic functions. It specifies data formats and encryption processes without naming the cryptographic algorithm. Each algorithm which is used for encryption purposes must be specified by a unique algorithm identifier .
In this paper we are implement IDEA into CMS or S/MIME as an additional strong algorithm for symmetric encryption. It's providing two unique object identifiers. One OID defines content encryption and the other one key encryption. For content encryption the use of IDEA in cipher block chaining (CBC) mode is recommended. The key length is fixed to 128 bits. To implement cryptographic function in S/MIME is using public-key cryptography standard version 7 (PKCS 7) .
IDEA encryption algorithm provide high level security not base on keeping the algorithm a secret, but rather upon ignorance of the secret key. It's fully specified and easily understood and suitable for use in a wide range of application. So when it's implementing in CMS it will enhances the security and it was particularly strengthened to protect against differential cryptanalysis attacks. Using example is based on the internet MIME standard, S/MIME provides cryptographic services for authentication, message integrity and support privacy and data security by using encryption .
3.1.1 Key Generation
The 64-bit plaintext block is partitioned into four 16-bit sub-blocks, since all the algebraic operation used in the encryption process operate on 16-bit numbers. Another process produces for each of the encryption rounds, six 16- bit key sub-block from the 128-bit key. Another process produces for each of the encryption rounds, six 16- bit key sub-block from the 128-bit key. Since a further four 16- bit key sub block are required for the subsequent different 16-bit sub-block have to be generated from the 128-bit key.
The key sub-block used for the encryption and the decryption in the individual rounds are shown in table 1.
The 52 16-bit key sub-blocks which are generated from the 128-bit key are produced as follows:
First, the 128-bit key is partitioned into eight 16-bit sub-blocks which are then directly used as the first eight key sub-blocks.
The 128-bit key is then cyclically shifted to the left by 25 positions, after which the resulting 128-bit block is again partitioned into eight 16-bit sub-blocks to be directly used as the next eight key sub-blocks.
The cyclic shift procedure described above is repeated until all of the required 52 16-bit key sub-blocks have been generated .
Let the four quarters of the plaintext be called A, B, C, and D, and the 52 subkeys called K(1) through K(52). Before round 1, or as the first part of it, the following is done:
Multiply A by K(1). Add K(2) to B. Add K(3) to C. Multiply D by K(4).
Round 1 proper consists of the following:
Calculate A xor C (call it E) and B xor D (call it F).
Multiply E by K(5). Add the new value of E to F.
Multiply the new value of F by K(6). Add the result, which is also the new value of F, to E.
Change both A and C by XORing the current value of F with each of them
Change both B and D by XORing the current value of E with each of them.
Swap B and C.
Repeat all of this eight times, or seven more times, using K(7) through K(12) the second time, up to K(43) through K(48) the eighth time. Note that the swap of B and C isÂ notÂ performed after round 8.
Then multiply A by K(49). Add K(50) to B. Add K(51) to C. Multiply D by K(52).
The intricacies of IDEA encryption may be made somewhat clearer by examining the following diagrams:
Example of Mechanism IDEA
At first the first four 16-bit key sub-blocks are combined with two of the 16-bit plaintext block using addition modulo 216 and with the other plaintext using multiplication modulo 216 + 1. The result is then processed further as shown following:
Example of IDEA
In the first encryption round, the first four 16-bit key sub-blocks are combined with two of the 16-bit plaintext blocks using addition modulo 216, and with the other two plaintext blocks using multiplication modulo 216 + 1. The results are then processed further as shown in Figure 1, whereby two more 16-bit key sub-blocks enter the calculation and the third algebraic group operator, the bit-by-bit exclusive OR, is used. At the end of the first encryption round four 16-bit values are produced which are used as input to the second encryption round in a partially changed order. The process described above for round one is repeated in each of the subsequent 7 encryption rounds using different 16-bit key sub-blocks for each combination. During the subsequent output transformation, the four 16-bit values produced at the end of the 8th encryption round are combined with the last four of the 52 key sub-blocks using addition modulo 216 and multiplication modulo 216 + 1 to form the resulting four 16-bit Ciphertext blocks .
For reverse encryption, the trick to that is that A xor C isn't changed when both A and C are XORed by the same value, that value cancels out, no matter what that value might be. And the same applies to B xor D. And since the values used are functions of (A xor C) and (B xor D), they are still available.
This cross-footed round, rather than a Feistel round, is the most striking distinguishing factor of IDEA, although its use of multiplication, addition, and XOR to avoid the use of S-boxes is also important.
Those that are added are replaced by their two's complement. Those that are multiplied in are replaced by their multiplicative inverse, modulo 65,537, in IDEA notation when used to change blocks directly, but those used to calculate the cross-footed F-functions are not changed. Keys XORed in would not need to be changed, but there aren't any such keys in IDEA. Due to the placement of the swap, the first four keys for decryption are moved somewhat differently than the other keys used for the same operation between rounds.
The decryption key schedule is:
The first four subkeys for decryption are:
KD(1) = 1/K(49)
KD(2) = -K(50)
KD(3) = -K(51)
KD(4) = 1/K(52)
and they do not quite follow the same pattern as the remaining subkeys which follow.
The following is repeated eight times, adding 6 to every decryption key's index and subtracting 6 from every encryption key's index:
KD(5) = K(47)
KD(6) = K(48)
KD(7) = 1/K(43)
KD(8) = -K(45)
KD(9) = -K(44)
KD(10) = 1/K(46)
In this section, I'm using phpMyadmin as example and there will be some source code as reference in the end of this paper. It is provides cryptographic services for authentication for security purpose. User must log with their own ID and Password to authenticate their status. If not this software will deny the access of user. When the user submit the ID and Password, encryption will happen and encrypted both of it using a random generate key. When the ciphertext is sent to server, the decryption will execute to get back the plaintext. After that the server will verify the ID and Password to check whether the user is allowed to access it. In our daily life, this mechanism is using in most of the server to provide security.
When a sending agent creates an encrypted message, it has to decide which type of encryption algorithm to use. In general, the decision process involves using information obtained from the capabilities lists included in messages received from the recipient, as well as out-of-band information such as private agreements, user preferences and legal restrictions.
For example, in the broad field of electronic commerce weak encryption, as represented by RC2/40, is regarded to be unacceptable. Strong encryption can be enforced on the basis of a security policy. This policy SHOULD include an agreement on at least one desired strong encryption algorithms to be used in S/MIME. In this case it is required that S/MIME clients both at the sending and the receiving end MUST support the desired encryption algorithms. Thus, if IDEA-CBC is chosen to be used as encryption algorithm, it MUST be supported by the S/MIME clients and it MUST be set in the user preferences .
Since the key generate by IDEA is randomly, so sometime may be there are some weak key generated for encryption. Weak key will make the cipher behave in some undesirable way and usually it's represent a very small fraction of the overall key space. So a weak key will rise to a security problem. In 2002, they are a large number of IDEA weak key was found, so the Boomerang attack is the most dangerous threat to for IDEA. Boomerang is a method for the cryptanalysis of block ciphers based on differential cryptanalysis. In differential cryptanalysis, an attacker exploits how differences in the input to cipher can affect the resultant difference at the output. So the researcher trying to improve the IDEA base on Boomerang attack .
Sometime IDEA will overhead. The IDEA multiplication operation is highly nonlinear and has good avalanche properties every output bit depends on all the inputs. It is not nearly as cheap as addition or XOR, but it is reasonably fast on a modern 32-bit or larger CPU. In most environments it will be more expensive than S-box lookups but in some, such as an embedded processor with limited cache, it may be cheaper. In any case, IDEA uses only 8 rounds so it can afford a moderately expensive operation in the round function.
IDEA uses 128-bit secret key and encrypt one 64-bit block at a time. It was particularly strengthened to protect against differential cryptanalysis attacks. For the full 8-round IDEA there is no attack know which better than exhaustive search on the total 128-bit key space if there is no weak key generated .
 Internet Society 1999. Cryptographic Message Syntax, RFC 2630.
 Internet Society 2001, Use of the IDEA Encryption Algorithm in CMS, RFC 3058.
 B. Schneier, "Applied Cryptography," 2nd ed., John Wiley & Sons Inc. New York, 1996, pp. 319-325.
 Modugu, Rajashekhar, Kim, Yong-Bin, Choi, Minsu.Â Design and performance measurement of efficientIDEAÂ (InternationalÂ DataÂ EncryptionÂ Algorithm) crypto-hardware using novel modular arithmetic components, Instrumentation and Measurement Technology Conference (I2MTC), 2010 IEEEÂ
 Dr. Salah Elagooz Dr. Nabil Hamdy Dr. Khaled Shehata Eng. M. Helmy, Design and Implementation of High and Low Modulo (216 + 1) Multiplier used In IDEA Algorithm on FPGA. Twenteith National Radio Radio Science Conference, March 2003.
 Alex Biryukov, Jorge Nakahara Jr, Bart Preneel, Joos Vandewalle, New Weak-Key Classes of IDEA. Information and Communications Security, 4th International Conference, ICICS 2002
 Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998
 Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, l. and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.
 Dusse, S., Hoffman, P., Ramsdell, B. and J. Weinstein, "S/MIME Version 2 Certificate Handling", RFC 2312, March 1998.
 Dusse, S., Hoffman, P., Ramsdell, B. and J. Weinstein, "S/MIME Version 3 Certificate Handling", RFC 2632, March 1998.
 Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.