











Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
An overview of the tiny encryption algorithm (tea), a fast and simple feistel-based block cipher designed for embedded and mobile systems. The basic operation of tea, its hardware and software requirements, and its vulnerabilities. It also discusses the xtea architecture as a solution to some of tea's weaknesses.
Typology: Summaries
1 / 19
This page cannot be seen from the preview
Don't miss anything!












Topic
In this age of viruses and hackers of electronic eavesdropping and electronic fraud, security is paramount. A cryptographic system (or a cipher system) is a method of hiding data so that only certain people can view it. A cryptographic system typically consists of algorithms, keys, and key management facilities. There are several algorithms to choose from that vary in the security they provide, their size, the time it takes to encrypt or decrypt a block of data. A cryptographic algorithm design called Tiny Encryption Algorithm (TEA) is proposed in order to minimize the memory footprint and maximize the speed. The design was targeted for embedded and mobile systems which concern more on speed and space. In TEA, the plaintext is encrypted and decrypted using the operations from mixed (orthogonal) algebraic groups and a huge number of rounds to achieve security with simplicity. INTRODUCTION Tiny Encryption Algorithm (TEA) is a notably fast, simple and Feistel-based block cipher designed to be one of the fastest and most efficient cryptographic algorithm compared to other algorithms such as IDEA and AES.TEA was introduced by Roger M. Needham and David J. Wheeler in 1994. TEA is designed to minimize the memory footprint and maximize speed by making the basic operations weak and very simple while high security is achieved by repeating these simple operations many times. Although TEA has a few weaknesses, most notably from equivalent keys and related-key attacks , TEA still provide good security for mobile systems such as RFID where hackers do not have the time necessary to sit down and work on security breaking. This project explores the
AVAILABILITY: The application should be available all the time. CORRECTNESS: A bug free software which fulfill the correct need/requirements of the patient. MAINTAINABILITY: The ability to maintain, modify patient and doctor information and update fix problems of the system. USABILITY: The application software can be used without any distortion. ACCESSIBILITY: Administrator and many other users can access the system, but the access level is controlled for each user according to their availability. ACCURACY: The reliability on the information/output. Can depend/be sure of the outcome. STABILITY: The system outcome/output won’t change time to time. Same output will be given always for a given input. RISK MANAGEMENT
1. Risk in requirement phases Risk ID Risk Description Mitigation Technique Consequ ence Likeliho od 1 Unclear Requirement - Not knowing the key Business meeting with the client and Brain storming session. Storing in secure place or write in some paper.
2 Inadequate estimation of proper Plain Text or cipher text. Their should be proper description about how to calculate encryption the plaintext and decryption of cipher text.
3 Improper documentation of the requirements- there is no proper description or discussion about the application. The features that are added to the application should be explained clearly so that there won’t be any further changes in the document, can be clearly submitted to design team.
2. Risk in Design Phase Risk ID Risk Description Mitigation Technique Consequence Likelihood 1 Requirement document not clear for developers- If Developers couldn’t save the key properly. The key must be saved properly can verified regularly.
High Level Description of TEA The Encryption of TEA: At first, the 64-bits plaintext is split into two inputs with 32bits each (which are y and z). There are four passkeys that can be defined as the passcode for the user. These passkeys are also assigned as inputs in the TEA architecture. The initial z input value is firstly being left-shifted with 4bits and the result is then being added up with the first passkey which is the K[0] and the result is then being kept aside in the memory named as z_2. The initial z input value is again being used to be added up with a Golden Ratio constant which is 2654435769 in decimal value and the result is being stored in the memory named as z_3. The following steps is to reuse again the initial z input value to undergo a right-shift of 5-bits and the result is then being saved in the memory named z_5. XOR operation is then being used for all the three values in z_2, z_ and also z_5. This carry the meaning of z_2 being XORed with z_3 and the result is being XORed again with z_5. This final result is then recorded in the memory named z_6. Furthermore, the value of z_6 must be added up with the initial y input value and the result is hence stored in the memory x_1. One TEA round (half a cycle) is considered as completed up to this point. By seeing diagram we can get the complete idea of TEA.
The decryption of TEA is basically almost the same as the encryption of TEA with the function is being reversed. The decryption process started with the encrypted text is now treated as the input of the algorithm in which the final_y is indicated as input_y and final_z is indicated as the input_z. The input_z is initially being left-shifted with 4-bits and the result is then being added up with the third passkey which si the K[2] and the result is then being kept aside in the memory with the name of z_2. The input_z is then being utilized to add up with the Golden Ratio constant and the result is being saved in the memory z_3. The following step is to reuse again the input_z value to undergo a right-shift of 5-bits and the result is being added up with the fourth
Brute Force Attack Dictionary Attack Solution: There are many notable fallbacks of TEA and it is considered broken. The first issue of note is that TEA uses “equivalent keys” thus weakening the effectiveness of its key length and requires only complexity O(2^32) using a related key attack to break. This is much less than the intended key brute force strength of 2^128.
After some weaknesses and vulnerabilities of TEA were Discovered and documented, Wheeler and Needham decided to present a new implementation of TEA and called it Extensions of TEA (XTEA). The vulnerabilities of TEA were discovered using differential related-key attacks. Therefore, XTEA attempts to correct the weaknesses by improving some aspects of the algorithm. The first change that was introduced in XTEA was a correction to the key schedule algorithm. In the updated XTEA, the introduction of subkeys is added more slowly. Also, the subkeys are selected by using two bits of the variable ‘sum’. In addition, a shift of 11 is also introduced in the key schedule to help create an irregular sequence of the subkeys. Some other changes introduced in XTEA is a rearrangement of the addition, shifts, and XOR operations. The following diagram shows XTEA. Instead of defined placement of the subkeys, now subkeys are introduced as subkey ‘A’ and subkey ‘B’
Functional testing is centered on the following items: Valid Input: identified classes of valid input must be accepted. Invalid Input: identified classes of invalid input must be rejected. Functions: identified functions must be exercised. Output: identified classes of application outputs must be exercised. Systems/Procedures: interfacing systems or procedures must be invoked. Organization and preparation of functional tests is focused on requirements, key functions, or special test cases. In addition, systematic coverage pertaining to identify Business process flows; data fields, predefined processes, and successive processes must be considered for testing. Before functional testing is complete, additional tests are identified and the effective value of current tests is determined.
System testing ensures that the entire integrated software system meets requirements. It tests a configuration to ensure known and predictable results. An example of system testing is the configuration-oriented system integration test. System testing is based on process descriptions and flows, emphasizing pre- driven process links and integration points.
Testing Screenshots :
Tiny encryption algorithm is one of the simplest algorithms to implement in hardware. It can be employed, where time is a constraint, i.e. a tradeoff can be made between the levels of security desired and the time to encrypt or decrypt, in terms of number of cycles. Testing the random numbers is very important in all cryptographic applications. In the absence of generally accepted norms to be used to measure and specify cryptographic strength, it is desirable to carry out a number of tests on different ciphers to get an exposure to their strength and weakness. With this objective, we carried out a variety of randomness and security strength tests which are presented in this paper. The strength of TEA and DES emerges quite significantly. Also as a heuristic technique to be used in cryptanalysis, Tabu search performs better than genetic algorithm and simulated annealing, based on the randomness of the numbers generated from these algorithms.
[1] John Kelsey, Bruce Schneier, and David Wagner, “Key-schedule cryptanalysis of IDEA, - DES, GOST, SAFER, and Triple-DES,” LNCS, Vol. 1109, pp. 237-251, Springer-Verlag 1996. [2] John Kelsey, Bruce Schneier, and David Wagner, “Related-key cryptanalysis of 3-Way, Biham-DES, CAST, DES-X NewDES, RC2, and TEA,” LNCS, Vol. 1334, pp. 233 - 246, Springer-Verlag 1997. [3] P. Israsena, “Securing Ubiquitous and Low-cost RFID using Tiny Encryption Algorithm”, Proc ICICS 2006, Dec 2006. [4] Jessie Grabowski and Jeff Keurian, “Tiny Encryption Algorithm.” Internet:http//people.rit.edujwg6168crypto TEA_Grabowski_Keurian.pdf, Sept. 05, 2010 [Dec. 08, 2011].