Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Message Encryption using TEA Algorithm: An Overview of Tiny Encryption Algorithm (TEA), Summaries of Computer Security

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

2018/2019

Uploaded on 10/18/2019

dinesh-kumar-6
dinesh-kumar-6 🇮🇳

3 documents

1 / 19

Toggle sidebar

Related documents


Partial preview of the text

Download Message Encryption using TEA Algorithm: An Overview of Tiny Encryption Algorithm (TEA) and more Summaries Computer Security in PDF only on Docsity! School of Information Technology & Engineering M.Tech Software Engineering SOFTWARE SECURITY (SWE2012) REVIEW - III Topic MESSAGE ENCYPTION USING TEA Submitted by T R THEJESH REDDY (16MIS0246) K RAMAKRISHNA (16MIS0137) YASWANTH (16MIS0415) Guided By Faculty: Prof. USHA DEVI G Slot: B1 ABSTRACT 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 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. 4 5 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. 4 3 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. 5 4 2 Improper Architecture Design Method choice- Key can’t be changed once its applied. Developer should remember the key because for decryption also we are using the same key. 3 5 3 The no.of rounds should be 64rounds or else 32 cycles. If we change it won’t work. As per the research paper we studied the no.of rounds should be 64 rounds. 4 3 4 Incomplete design document, inconsistent documentation- Changes that made in requirements stage are not updated. The documentation should not have any duplication and should be made accurate by verification by the senior and experienced team members. 3 3 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_3 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. ATTACKS:  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. XTEA ARCHITECTURE: 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’ Left[i] Right [i] Delta, toad >> 5 kt SCREEN SHOTS: ENCRYPTION: SAMPLE CODE i File Eat Vie Project Build Debug Fontan vaSmith Tools Took~ Phigins DonBlocks Setings Help SBEA) ey B\2aforseo > 2 y <tbba> oe o|P BBR B Elmer ‘ few: Curent es smb 1B Symbot 5 9 Global functions 6 ° i a ae ficteee o #inctuae a a tgs otis x 4) Hcwetods x) Qseachreats x) A cex Buldog | $ Bukd messages | /\concheck | Concheckmessoges Jicsape Deane x _J}oone > [ANsemesten 5 REVIEWCOD \CODE.CPPitesEncode. cpp Windows (CR+LA)__WINDOWS-1252 Line 1 Column inset eu EXECUTION: ene Cr Pees Th TESTING Unit testing: Unit testing involves the design of test cases that validate that the internal program logic is functioning properly, and that program inputs produce valid outputs. All decision branches and internal code flow should be validated. It is the testing of individual software units of the application .it is done after the completion of an individual unit before integration. This is a structural testing, that relies on knowledge of its construction and is invasive. Unit tests perform basic tests at component level and test a specific business process, application, and/or system configuration. Unit tests ensure that each unique path of a business process performs accurately to the documented specifications and contains clearly defined inputs and expected results. Integration testing: Integration tests are designed to test integrated software components to determine if they run as one program. Testing is event driven and is more concerned with the basic outcome of screens or fields. Integration tests demonstrate that although the components were individually satisfaction, as shown by successfully unit testing, the combination of components is correct and consistent. Integration testing is specifically aimed at exposing the problems that arise from the combination of components. Functional test: Functional tests provide systematic demonstrations that functions tested are available as specified by the business and technical requirements, system documentation, and user manuals. 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 Test: 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 SSEG/ er xmalQaiorson om i % @ l/s BS ¢ bED Weolda. oa|==—m RQ wml) = Gotlee _%|tesbeodecre | mamaceay —% Si neceree Ti ering manaapace at i heed (ad M cout << "Teapecrumtss™ < 17 Glvotd decodetzes ansigned int | leptons x | Aicoeoss x] senses x) Jicaz x] @Qoaden_x| # oudmessenes x fiGpOer x] cwOetmemas x) ficnape x] @oenon x] oone? -semesn1 SEMESTER--COURSE PAGE PROECTO.SOFIWARE SECURIT TEAC: <\CODECPP ead Windows CRLF) WNDOWS2S2 Une Calumet et Renate dla SSEG er xmealQagiorson oon < asain varepeiet nue’ C € a 2s | me<lil Side hE errr es aal==em Ra Ja. 3) | (ed irons | smbor [Ree bf} ' few fametniomiae |? 2 Sic : @ ccttvncio ‘ 1B cota ese ; 8 in : i] nin, 10 ae tae fom er Hp _———— eee > tate x i Acids x | hsewcents x] Aicex x] Qdib x] # taldmeses x] AGrtied x] JGvdudremoe x) Acewe Xx] Q oben x] home? Windows (CRLF) WNOOWS-252 Line 20, Coun 18 rset ResaWite delat =
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved