Você está na página 1de 73

A PROJECT STAGE -I REPORT AES ALGORITHM USING 512 BIT KEY IMPLEMENTATION FOR SECURE COMMUNICATION

Submitted By Rishabh Jain Someshwar Vaidya Mahesh Sanap


Under the guidance of

Rahul Jejurkar Shrikrishna Chopade

Prof. Ghule S. J.
In partial fullment of

B. E. Computer Engineering
2013-14 AT

DEPARTMENT OF COMPUTER ENGINEERING

Shri Chhatrapati Shivaji College of Engineering,


Shrishivajinagar(Rahuri Factory),Tal-Rahuri, District-Ahmednagar Aliated to

University of Pune

Shri Chhatrapati Shivaji College of Engineering,


Shrishivajinagar(Rahuri Factory),Tal-Rahuri, District-Ahmednagar DEPARTMENT OF COMPUTER ENGINEERING

CERTIFICATE
This is to certify that the Project Stage -I report entitled

AES Algorithm Using 512 Bit Key Implementation For Secure Communication
submitted by

Rishabh Jain Someshwar Vaidya Mahesh Sanap

Rahul Jejurkar Shrikrishna Chopade

is a record of bonade work carried out by them, under our guidance, in partial fulllment of the requirement for the award of Degree of Bachelor of Engineering(Computer) at Shri Chhatrapati Shivaji College of Engineering, Shrishivajinagar under the University of Pune. This work is done during July 2013- Dec 2013.

Date: Project Guide [Prof. S. J. Ghule] HOD, Computer Engg. [Prof. D. P. Gade] Project Coordinator [Prof. H. B. Jadhav] Principal, SCSCOE[Dr. P. R. Wani]

Examination
Examiner 1........................................ Examiner 2........................................

Acknowledgements
We are profoundly grateful to Prof. Ghule S. J. for her expert guidance and continuous encouragement throughout to see that this project rights its target since its commencement to its completion. We are also grateful to Prof. Jadhav H. B.(Coordinator) for his support and guidance that have helped us to expand our horizons of thought and expression. We would like to express our deepest appreciation towards Dr. Wani P. R., Principal,SCSCOE, Shrishivajinagar, Prof. Gade D. P., HOD Computer Engineering Department, whose invaluable guidance supported us in completing this project. At last we must express our sincere heartfelt gratitude to all friends and sta members of Computer Engineering Department who helped us directly or indirectly during this course of work. Rishabh Jain Rahul Jejurkar Someshwar Vaidya Shrikrishna Chopade Mahesh Sanap

INDEX
ABSTRACT LIST OF TABLES LIST OF FIGURES 1 INTRODUCTION 1.1 1.2 1.3 1.4 1.5 PROBLEM DEFINITION . . . . . . . . . . . . . . . . . . . . . . . . OBJECTIVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PROJECT SCOPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . HYPOTHESIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DEPENDENCY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I II III 1 1 2 2 3 3 4 10 10 12 13 14 14 14 15 15 15 16

2 LITERATURE SURVEY 2.1 2.2 2.3 2.4 TABLE OF RELATED PAPERS . . . . . . . . . . . . . . . . . . . . EXISTING SYSTEM . . . . . . . . . . . . . . . . . . . . . . . . . . . DRAWBACKS OF EXISTING SYSTEM . . . . . . . . . . . . . . .

FUTURE WORK IN EXISTING SYSTEM . . . . . . . . . . . . . .

3 REQUIREMENT ANALYSIS 3.1 3.2 3.3 3.4 REQUIRED FEATURES OF THE SYSTEM . . . . . . . . . . . . . HARDWARE REQUIREMENT . . . . . . . . . . . . . . . . . . . . . SOFTWARE REQUIREMENT . . . . . . . . . . . . . . . . . . . . . EXTERNAL INTERFACE REQUIREMENT . . . . . . . . . . . . . 3.4.1 3.4.2 User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . Hardware Interfaces . . . . . . . . . . . . . . . . . . . . . . .

3.4.3 3.4.4 3.5

Software Interfaces . . . . . . . . . . . . . . . . . . . . . . . . Communication Interfaces . . . . . . . . . . . . . . . . . . . .

16 16 16 16 16 17 17 18 18 18 18 19 20 20 21 21 21 21 21 22 22 22 22 22 23 24 24 24 24 25 25

NONFUNCTIONAL REQUIREMNETS . . . . . . . . . . . . . . . . 3.5.1 3.5.2 3.5.3 3.5.4 3.5.5 3.5.6 3.5.7 3.5.8 Performance Requirements . . . . . . . . . . . . . . . . . . . Safety Requirements . . . . . . . . . . . . . . . . . . . . . . . Security Requirements . . . . . . . . . . . . . . . . . . . . . . Software Quality Attribute . . . . . . . . . . . . . . . . . . . Requirement for reuse of code . . . . . . . . . . . . . . . . . . User Classes and Characteristics . . . . . . . . . . . . . . . . . Operating Environment . . . . . . . . . . . . . . . . . . . . . Design and Implementation Constraints . . . . . . . . . . . .

4 SYSTEM ARCHITECTURE 4.1 4.2 4.3 4.4 PROPOSED SYSTEM . . . . . . . . . . . . . . . . . . . . . . . . . . SYSTEM ARCHITECTURE . . . . . . . . . . . . . . . . . . . . . . SYSTEM WORKING . . . . . . . . . . . . . . . . . . . . . . . . . . MODULES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 4.4.2 4.4.3 Sender module . . . . . . . . . . . . . . . . . . . . . . . . . . Receiver module . . . . . . . . . . . . . . . . . . . . . . . . .

AES module . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 ALGORITHMIC STUDY 5.1 AES ENCRYPT ALGORITHM . . . . . . . . . . . . . . . . . . . . . 5.1.1 5.1.2 5.1.3 5.1.4 5.2 Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . .

AES DECRYPTION ALGORITHM . . . . . . . . . . . . . . . . . . 5.2.1 5.2.2 5.2.3 5.2.4 Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.3

MATHEMATICAL MODEL . . . . . . . . . . . . . . . . . . . . . . .

5.4

FEASIBILITY STUDY . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 NP Hard Study . . . . . . . . . . . . . . . . . . . . . . . . . .

29 29 31 31 32 33 33 34 35 36 36 38 41 43 45 46 47 48 49 51 52 52 52 52 52 52 53 54 56 58

6 SYSTEM DESIGN 6.1 DFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 6.1.2 6.1.3 6.2 6.3 6.4 DFD level 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . DFD level 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . DFD level 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CFD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ER DIAGRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UML DIAGRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.1 6.4.2 6.4.3 6.4.4 6.4.5 6.4.6 6.4.7 6.4.8 6.4.9 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . Class Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . State-transition Diagrams . . . . . . . . . . . . . . . . . . . . Object Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . Communication Diagram . . . . . . . . . . . . . . . . . . . . . Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . Component Diagram . . . . . . . . . . . . . . . . . . . . . . . Package Diagram . . . . . . . . . . . . . . . . . . . . . . . . .

6.4.10 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . 7 SYSTEM IMPLEMENTATION 7.1 TECHNICAL SPECIFICATION . . . . . . . . . . . . . . . . . . . . 7.1.1 7.1.2 7.1.3 7.1.4 7.1.5 7.2 7.3 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Programming Language . . . . . . . . . . . . . . . . . . . . . Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Development tools . . . . . . . . . . . . . . . . . . . . . . . . Other tools . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SOFTWARE DEVELOPEMENT LIFE CYCLE . . . . . . . . . . . . SYSTEM IMPLEMENTATION PLAN . . . . . . . . . . . . . . . . . 7.3.1 Risk Management . . . . . . . . . . . . . . . . . . . . . . . . .

8 EXPECTED RESULT 8.1 EXPERIMENT NEEDED TO CONDUCT FOR ANALYSIS . . . . . 8.1.1 8.1.2 8.2 Expected Output . . . . . . . . . . . . . . . . . . . . . . . . . Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59 59 59 59 59 60 60 60 60 61

FINAL ANALYSIS . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9 APPLICATIONS 9.1 9.2 9.3 ADVANTAGES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LIMITATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . APPLICATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10 CONCLUSIONS

ABSTRACT

The main aim of this project is to provide stronger security for communication over the Internet by enhancing the strength of the AES algorithm. Rijndaelas algorithm was selected as the Advanced Encryption Standard. The AES algorithm was believed to provide much more security without any limitations. But, recently some breaking methods on the AES have been found by cryptanalysts. In AES algorithm, the number of rounds involved in the encryption and decryption depends on the length of the key and the number of block columns. So, the number of rounds is increased to improve the strength of the AES. The strength of the AES algorithm is enhanced by increasing the key length to 512 bit and thereby the number of rounds is increased in order to provide a stronger encryption method for secure communication. Code optimization is done in order to improve the speed of encryption and decryption using the 512 bit AES. Keywords:AES,Encryption,Decryption

List of Tables
2.1 Table of related papers . . . . . . . . . . . . . . . . . . . . . . . . . . 10

II

List of Figures
4.1 5.1 5.2 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . Encryption procedure of AES 512 . . . . . . . . . . . . . . . . . . . . Decryption procedure of AES 512 . . . . . . . . . . . . . . . . . . . . Dfd level 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dfd level 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dfd level 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Control ow diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . E-R diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . State-transition Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 20 27 29 32 33 33 34 36 38 40 42 44 45 46 47 49 51 51 55

6.10 Object Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.11 Communication Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 6.12 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.13 Component Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.14 Package Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.15 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1 Waterfall model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

III

CHAPTER - 1 INTRODUCTION

Network security is becoming more and more important as people spend more and more time connected in a network. It involves all activities that organizations, enterprises, and institutions undertake to protect the value and ongoing usability of assets and the integrity and continuity of operations. Security attacks include unauthorized reading of a message of le, trac analysis, modication of messages or les and denial of service. One of the most publicized types of attack on information systems is the computer virus. An eective network security strategy requires identifying threats and then choosing the most eective set of tools to combat them. Security involving communications and networks is not as simple as it might rst appear to the novice. The expansion of the connectivity of computers makes ways of protecting data and messages from tampering or reading important. Intruders may reveal the information to others, modify it to misrepresent an individual or organization, or use it to launch an attack. One of the primary reasons that intruders can be successful is that most of the information they acquire from a system is in a form that they can read and comprehend. One solution to this problem is, through the use of cryptography. Cryptography ensures that the messages cannot be intercepted or read by anyone other than the authorized recipient. It prevents intruders from being able to use the information that they capture. Cryptography secures information by protecting its condentiality and can also be used to protect information about the integrity and authenticity of data.

1.1

PROBLEM DEFINITION

The Advanced Encryption Standards algorithm was originally proposed by Rijmen and Daemen (Rijndael algorithm) in June 1998. This algorithm is widely accepted

due to its strong encryption, complex processing and its resistance to Brute-force attack. The proposed modications are implemented on the rounds of the algorithm. These modications enhance the complexity of the encryption process, thereby making it dicult for the attacker to predict a pattern in the algorithm. In this project we are going to develope android based GSM messenger with secured encryption and decryption with 512 bit key AES Algorithm.

1.2

OBJECTIVE

In this project we are going to develop the android based secure messenger which uses the Advanced encryption standard algorithm.

1.3

PROJECT SCOPE

Network security is becoming more and more important as people spend more and more time connected in a network. It involves all activities that organizations, enterprises, and institutions undertake to protect the value and ongoing usability of assets and the integrity and continuity of operations. Security attacks include unauthorized reading of a message of le, trac analysis, modication of messages or les and denial of service. One of the most publicized types of attack on information systems is the computer virus.

An eective network security strategy requires identifying threats and then choosing the most eective set of tools to combat them. Security involving communications and networks is not as simple as it might rst appear to the novice. The expansion of the connectivity of computers makes ways of protecting data and messages from tampering or reading important. Intruders may reveal the information to others, modify it to misrepresent an individual or organization, or use it to launch an attack. One of the primary reasons that intruders can be successful is that most of the information they acquire from a system is in a form that they can read and comprehend. One solution to this problem is, through the use of cryptography. Cryptography ensures that the messages cannot be intercepted or read by anyone 2

other than the authorized recipient. It prevents intruders from being able to use the information that they capture. Cryptography secures information by protecting its condentiality and can also be used to protect information about the integrity and authenticity of data.

1.4

HYPOTHESIS

512 bit key Messenger is dependent on the system having an active mobile GSM connection on both side that is at sender and receiver side.

1.5

DEPENDENCY

(a) ANDRIOD SDK and ADT: The application is dependent on ANDRIOD SDK updates for particular Android version i.e. 2.1 clair to 4.2 Jelly bean. The Android SDK provides the API libraries and developer tools necessary to build, test, and debug apps for Android. If youre a new Android developer, we recommend you download the ADT Bundle to quickly start developing apps. It includes the essential Android SDK components and a version of the Eclipse IDE with built-in ADT (Android Developer Tools) to streamline your Android app development.

CHAPTER - 2 LITERATURE SURVEY

The rst open encryption algorithm, Data Encryption Standard (DES) was adopted by the National Institute of Standards and Technology(NIST) to protect the sensitive information as Federal Information Processing Standard 46 (FIPS PUB 46) in 1977. However, the shorter length of key, the complementary property and existence of weak and semi-weak keys reduce the security of DES [2]. Dierential cryptanalysis attack is capable of breaking DES in less than 255 complexities. The linear cryptanalysis method can nd a DES key given 243 known plaintexts, as compared to 247 chosen plaintexts for dierential cryptanalysis. So, it was more essential to nd a stronger encryption algorithm to substitute the DES.In spite of the vulnerability of DES to a brute-force attack, there has been considerable interest in nding an alternative.

One approach is to design a completely new algorithm and another alternative would be the one that preserves the existing one by using multiple encryption with DES and multiple keys. Three other algorithms were found to solve the problems of DES. They are Double DES, Triple DES with two keys and Triple DES with three keys. The principal drawback of Triple DES is that it has three times as many rounds as DES and hence it is much slower. Triple DES uses a 64 bit block size which is another drawback because for both eciency and security, a larger block size is desirable. Because of these drawbacks, Triple DES is not favorable for long term use.The Rijndael algorithm was adopted as an encryption standard, the Advanced Encryption System (AES) by the NIST as FIPS PUB 197 (FIPS 197) on November 2001. The AES algorithm was believed to provide more security than the DES. The AES algorithm was designed to have resistance against all known attacks, speed and code compactness on a wide range of platforms and design simplicity. AES has three variable key lengths but block length is xed to 128 bits. The three key sizes of AES

are 128, 192 and 256 bits. Their number of possible keys is 3.4x1038 , 6.2x1057 and 1.1x1077 respectively. There are on the order of 1021 times more AES 128-bit keys than DES 56-bit keys. AES with 128-bit keys has stronger resistance to an exhaustive key search than DES.

Rijndael has very strong resistance against the dierential cryptanalysis and linear cryptanalysis attacks since it used Wide Trail Strategy in its design. Although these linear attacks are invalid for the AES, they have been extended in several ways for recent years and new attacks have been published that are relative to them. The newest attack combined boomerang and the rectangle attack with related-key dierentials was introduced by E. Biham, et al. in 2005. It uses the weaknesses of few nonlinear transformations in the key schedule algorithm of ciphers, and can break some reduced-round versions of AES. It can break 192-bit 9-round AES by using 256 dierent related keys. Rijndael inherits many properties from Square algorithm. So, the Square attack is also valid for Rijndael which can break round-reduced variants of Rijndael up to 6 or 7 rounds (i.e.AES-128 and AES-192) faster than an exhaustive key search . N.Ferguson et al. proposed some optimizations that reduce the work factor of the attack. So, this attack breaks a 256-bit 9-round AES with 277 plaintexts under 256 related keys, and 2224 encryptions.

[3]Cryptography is a common component of any Information Security infrastructure, whether it be for the encryption of large lines for secure long term storage or ensuring that communication lines are safe for the transfer of condential information. In this section I discuss two basic schemes of cryptography, symmetric cryptography and public key cryptography, also outlining cryptographic hash functions.

Symmetric Cryptography Symmetric cryptography, also known as secret key cryptography, has been in use since ancient times and has a wide variety of dierent implementations ranging from simple substitution ciphers such as Caesars Cipher to complex and supposedly mathematically unbreakable algorithms such as AES. Symmetric key encryption makes use of a single key that must be kept secret, this key is used for both the encryption and 5

decryption of messages to be sent or stored. I will outline some of these functions, how they work and the relative amount of work required to perform each.

The Data Encryption Standard (DES) The Data Encryption Standard was developed by IBM and was selected in 1976 as an ocial Federal Information Processing Standard for the United States. The original DES algorithm used a 64-bit key, of which 8-bits are used for parity and the remaining 56-bits are used to encrypt the plain-text. The required computations for brute forcing a DES key would be 255 operations, given a 64-bit plain-text and 64-bit DES key. While the DES algorithm itself is considered to be resistant to cryptanalysis, the actual keys used for encryption are considered to be fairly weak. The DES algorithm consists of three phases.

Phase 1 The rst 64-bits of plain-text, which we will call collectively, x , run through an Initial Permutation function, which we shall denote as IP, returning 64-bits of output, which we will call x0. We can mathematically represent this as x0 = IP(x): The output is separated into equal length sections, obviously consisting of 32-bits each. We will represent this separation as L0R0, where L0 represents the rst 32-bits and R0 represents the remaining 32-bits. Further we dene an inverse function of the Initial Permutation function, which we call IIP.

Phase 2 The output then undergoes 16 repetitions of a computation that is key dependent using some cipher function, which we shall call f, making use of a key scheduling function which we shall call KS. A key scheduler calculates all the sub-keys for each round or iteration. The output of each iteration or round can be represented as xi = LiRi with 1 = i = 16 with Li = Ri .. 1 and Ri = Li f(Ri .. 1;Ki). The Kis are 48-bit blocks that can be derived from the original 56-bit string using KS.

Phase 3 In the nal phase, IP is applied to x16to give another 64-bit cipher block which 6

we will call C, i.e. C = IIP(x16) = IIP(R16L16). We note the inverse property applies, that is IIP(IP(x)) = x [5]. The Cryptographic Hash function, f Firstly, this function will expand the Ris from their 32-bit block to a 48-bit block through an expansion permutation. Essentially this function increases the bit length by reusing some of the bits in the R0 i s, and also re-ordering them making use of a lookup table. We then exclusive-or this output together with Ki. This result is then broken up in 8 blocks of 6-bits each. These 6-bit blocks are then passed through an S-box giving an output of 4-bits. The S-box takes the rst bit and the last bit of the input forming a 2-bit binary number. The base10 value of this 2-bit number is used to select a row. The remaining inner 4-bits are used to select a column number. These row and column values are used to index a value from the S-box . The 4-bit output of each of these 8 boxes is then concatenated to yield a 32-bit output which is nally given to the permutation function P which gives a result of 32-bits.

Key Scheduling The key scheduling function, KS, is used to make the 48-bit Kis from the original 56-bit key . We note that while DES keys are 64-bit, only 56-bits are actually used to seed the random functions as 8-bits are used for error checking. Every 8th bit (i.e 8th, 16, 24 ... 64) is used for parity. The key scheduling functions consist of two permutation functions, PC1and PC2, where PC stands for Permutation Choice.

To select the Kis we apply the following algorithm. Given a 64-bit key K, we discard the 8- bits used for parity and apply PC1 to the remainder of the key. This can be represented as PC1(K) = C0D0 where C0 represents the rst 28-bits and D0 represents the remainder. PC itself has two components, with the rst half determining Ci and the second half determining Di. To calculate the individual CiDi we apply a LSi function, which represents the number of left cylindrical shifts, this is a value which is either 1 or 2, by whichCi or Di is to be shifted. That is Ci = LSi(Ci .. 1) and Di = LSi(Di .. 1).

TheLi function is yet another look up table function. The bits of Ci and Di are then concatenated together and PC2 is applied to the output of the concatenation, that is Ki = PC2(Ci;Di). For decryption the same key is used, but the order of functions applied is reversed.

Triple DES (3DES) In 1999 NIST set 3DES as the interim encryption standard for 1999. While 3DES is considered to be more secure than DES, it is also far more computationally intense. We can describe the algorithm as follows.

Let Ek(x) and Dk(x) represent the encryption and decryption functions respectively for a given key k. The variable x will represent the 64-bit bit-string that we wish to secure. We can obtain the cipher text from C = Ek3(Dk2(Ek1(x))) and we can obtain the original bit-string by applying the inverse functions in the following way x = Dk1(Ek2(Dk3(c))). For optimal security the three keys should be unique, this corresponds to an actual key strength of 168-bits. We can choose to make two of the keys, K = Kj but i 6= j, this reduces the actual key length to only 112-bits. 3DES is considered to be the slowest of the 64-bit ciphers in a software implementation, however it is thought to also be the most secure. Hardware accelerators may be used to improve performance. 3DES suers from potential MITM attacks which allow the keys to manipulated allowing for only 112-bits keys, as two keys are identical. 3DES, like DES, is potentially susceptible to chose and known plain-texts type attacks. However due to the increase in key length it is far more resistant to brute force type cryptanalysis.

AES The AES accepted candidate, Rijndael, was designed by John Daemen and Vincent Rijmen from Belgium and was published in 1998, it is an iterated block cipher allowing for variable key length and allows for a choice from a number of dierent block size. Rinjndael supports block sizes of 128-bits, 192-bits and 256-bits. Rijndael is byte orientated, compared to the bit orientated nature of DES. The number of rounds or iterations applied is dependent on the sizes of the block and the key 8

used. For example if the block size is 128-bits and if we let m be the size of key and r the number of rounds is given by r = k=32+6. At the start a 128-bit block of plain-text is used as the initial state. This initial state will be passed through a number of key-dependent transformations, nally returning a 128-bit block of plaintext. A state is treated as a 4x4 matrix, where Ai;j will represent a single byte with 0 = i; j = 3, i referring to the rows and j referring to the columns. For example A0;0 is the rst byte and A1;0 is the 5th byte. Rijndael makes use of four basics operators to allow for transformation from one state, say A = (Ai;j), to another state, say. The set of operators used by Rijndael include the following four operators.

Operator 1 : Byte Substitution This is a non-linear permutation that operates on each byte in the current state independently, allowing for parallelism. In this phase we take 8-bytes of the 16-byte phase a multiply them an 8 x 8 matrix, i.e. matrix multiplication of an 8 x 8 matrix by a 8x1 column vector resulting in a 8x1 column vector. This can be eciently implemented by making use of a 256-bit lookup table or an S-box.

Operator 2 : Shift Row This is a cyclic shift of the bytes in a state. This could be represented as say Bi;j = Ai;(j+1)mod4. The rst row will undergo no changes, however the second row will shift one column, the third row shifts two columns and the third row will shift three columns.

Operator 3 : Mix column Each of the columns Ai undergoes a linear transformation. A transformation is applied to a column at a time and is equivalent to multiplying the columns contents by a 4 x 4 matrix, that is matrix multiplication of a 4 x 4 matrix with a 4 x 1 column matrix containing the columns values.

Operator 4 : Round Key Addition For every round a round key, RK, is generated from the cipher key via the key scheduling function. The round key is the same length as the encryption block and 9

are represented in a 4 x 4 matrix, similar to how the plain-text is represented. We then perform exclusive or the round key with the current state.

Key Scheduler The key scheduler consists of two sections, the key expansion function and key round key selection. A key expansion function is used to expand the cipher key to produce the required number of bits for the round keys. The required number of key bits is equal to N(R + 1) where Nis the required block size and R is the number of rounds to be completed. In Round Key Selection if we assume a block size of 128-bits, after the Key Expansion has taken place, the most signicant 128-bits and used for the rst round, the next most signicant 128-bits are then used for the next round and so forth.

2.1
Sr no 1

TABLE OF RELATED PAPERS


Paper name An investigation into the eld of cryptography and cryptographic protocols Year of publish 2009 Publisher Bradley Cowie and Barry Irwin

Aes Algorithm Using 512 Bit Key Implemented For Secure Communication

2010

S Radhika, A ChandraSekar

Modications to AES Algorithm 2011 for Complex Encryption

PriyankaPimpale, Rohan Rayarikar, SanketUpadhyay

Table 2.1: Table of related papers

2.2

EXISTING SYSTEM

The rst open encryption algorithm, Data Encryption Standard (DES) was adopted by the National Institute of Standards and Technology(NIST) to protect the sensi10

tive information as Federal Information Processing Standard 46 (FIPS PUB 46) in 1977. However, the shorter length of key, the complementary property and existence of weak and semi-weak keys reduce the security of DES. Dierential cryptanalysis attack is capable of breaking DES in less than 255 complexities. The linear cryptanalysis method can nd a DES key given 243 known plaintexts, as compared to 247 chosen plaintexts for dierential cryptanalysis. So, it was more essential to nd a stronger encryption algorithm to substitute the DES.In spite of the vulnerability of DES to a brute-force attack, there has been considerable interest in nding an alternative.[1]

One approach is to design a completely new algorithm and another alternative would be the one that preserves the existing one by using multiple encryption with DES and multiple keys. Three other algorithms were found to solve the problems of DES. They are Double DES, Triple DES with two keys and Triple DES with three keys. The principal drawback of Triple DES is that it has three times as many rounds as DES and hence it is much slower. Triple DES uses a 64 bit block size which is another drawback because for both eciency and security, a larger block size is desirable. Because of these drawbacks, Triple DES is not favorable for long term use.The Rijndael algorithm was adopted as an encryption standard, the Advanced Encryption System (AES) by the NIST as FIPS PUB 197 (FIPS 197) on November 2001. The AES algorithm was believed to provide more security than the DES. The AES algorithm was designed to have resistance against all known attacks, speed and code compactness on a wide range of platforms and design simplicity. AES has three variable key lengths but block length is xed to 128 bits. The three key sizes of AES are 128, 192 and 256 bits. Their number of possible keys is 3.4x1038 , 6.2x1057 and 1.1x1077 respectively. There are on the order of 1021 times more AES 128-bit keys than DES 56-bit keys. AES with 128-bit keys has stronger resistance to an exhaustive key search than DES.

Rijndael has very strong resistance against the dierential cryptanalysis and linear cryptanalysis attacks since it used Wide Trail Strategy in its design. Although these linear attacks are invalid for the AES, they have been extended in several ways 11

for recent years and new attacks have been published that are relative to them. The newest attack combined boomerang and the rectangle attack with related-key dierentials was introduced by E. Biham, et al. in 2005. It uses the weaknesses of few nonlinear transformations in the key schedule algorithm of ciphers, and can break some reduced-round versions of AES. It can break 192-bit 9-round AES by using 256 dierent related keys. Rijndael inherits many properties from Square algorithm. So, the Square attack is also valid for Rijndael which can break round-reduced variants of Rijndael up to 6 or 7 rounds (i.e.AES-128 and AES-192) faster than an exhaustive key search . N.Ferguson et al. proposed some optimizations that reduce the work factor of the attack. So, this attack breaks a 256-bit 9-round AES with 277 plaintexts under 256 related keys, and 2224 encryptions.

2.3

DRAWBACKS OF EXISTING SYSTEM

Rijndael has very strong resistance against the dierential cryptanalysis and linear cryptanalysis attacks since it used Wide Trail Strategy in its design . Although these linear attacks are invalid for the AES, they have been extended in several ways for recent years and new attacks have been published that are relative to them .The newest attack combined boomerang and the rectangle attack with related-key dierentials was introduced by E. Biham, et al. in 2005 . It uses the weaknesses of few nonlinear transformations in the key schedule algorithm of ciphers, and can break some reduced-round versions of AES. It can break 192-bit 9-round AES by using 256 dierent related keys. Rijndael inherits many properties from Square algorithm. So, the Square attack is also valid for Rijndael which can break round-reduced variants of Rijndael up to 6 or 7 rounds (i.e.AES-128 and AES-192) faster than an exhaustive key search . N. Ferguson et al. proposed some optimizations that reduce the work factor of the attack . So, this attack breaks a 256-bit 9-round AES with 277 plaintexts under 256 related keys, and 2224 encryptions.[1]

12

2.4

FUTURE WORK IN EXISTING SYSTEM

AES is a block cipher and the most popular algorithm used in symmetric key cryptography. It is a substitution-permutation network and not a Fiestel network like DES. When the number of rounds is increased in AES, the complexity of AES encryption and decryption also increases. The number of rounds (Nr) in the AES algorithm depends on the length of main keys (Nk) and the number of block columns (Nb), i.e. Nr = Nk+Nb+abs(Nk-Nb). So, the length of the key is increased to 512 bits in order to increase the number of rounds. The structure of AES is quite simple. The input to the encryption and decryption algorithms is a single 128-bit block and the key is 512 bits. It requires the same key to be used for encryption and decryption.

13

CHAPTER - 3 REQUIREMENT ANALYSIS

Requirements analysis, also called requirements engineering, is the process of determining user expectations for a new or modied product. These features, called requirements, must be quantiable, relevant and detailed. In software engineering, such requirements are often called functional specications. Requirements analysis is an important aspect of project management. Requirements analysis involves frequent communication with system users to determine specic feature expectations, resolution of conict or ambiguity in requirements as demanded by the various users or groups of users, avoidance of feature creep and documentation of all aspects of the project development process from start to nish. Energy should be directed towards ensuring that the nal system or product conforms to client needs rather than attempting to mold user expectations to t the requirements.

3.1

REQUIRED FEATURES OF THE SYSTEM

The application should be secure The messages should be in threaded view. The user interface should be more clear to understand to user.

3.2

HARDWARE REQUIREMENT

For Development of the system following hardware would be required 1. CPU type : Dual Core and above 2. Clock speed : 2.2 GHz 3. Ram size : 2 GB 14

4. Hard disk capacity : 40 GB 5. Monitor type : 15 Inch color monitor 6. Keyboard type : Internet keyboard 7. Android Mobile : For Deployment of the Application Developed 8. GSM Modem : To receive sms on a remote PC / Desktop

3.3

SOFTWARE REQUIREMENT

The application will only be compatible with the Android operating system and will use a database stored on the devices memory in the form of a text document. 1. Operating System : Android on Mobile 2. Language : JAVA 3. Front End : Eclipse 4. Documentation :Latex

3.4
3.4.1

EXTERNAL INTERFACE REQUIREMENT


User Interfaces

Sender Side For the phone version at sender side the user can enter the text message in textbox provided on GUI. To select the senders number user can click on add sender button to select the sender or senders or user can enter phone number directly on another textbox provided to enter senders phone number. Then user can press Send button to send message to sender. Receiver Side For the phone version at receiver side user get notication for received message from user can view received messsage tapping on notication. 15

3.4.2

Hardware Interfaces

The supported devices are Android devices running Android version 2.0 and up. The tablet version of the application will support Android version 3.0 and up.

3.4.3

Software Interfaces

The application will only be compatible with the Android operating system and will use a database stored on the devices memory in the form of a text document.

3.4.4

Communication Interfaces

There will need to be an GSM connection to initially send message and receive message.

3.5
3.5.1

NONFUNCTIONAL REQUIREMNETS
Performance Requirements

1. System should give expected results 2. It should be easy to handle.

3.5.2

Safety Requirements

The user should never use this application while driving. Never provide sensitive personal information, such as your credit card numbers or passwords, in an IM conversation. Create a barrier against unwanted instant messaging. 1. Avoid Windows OS / system crash 2. Avoid Android crash

16

3.5.3

Security Requirements

1. To secured message at local level user need some othe application locker apps. 2. System must have password protection

3.5.4

Software Quality Attribute

1. Java Attributes: (a) Simple Java is simple because it uses automatic memory allocation and garbage collection whereas C++ requires the programmer to allocate memory and to collect garbage. Also, the number of language constructs in Java is small for such a powerful language. The clean syntax makes Java programs easy to write and read. (b) Object Oriented Object oriented programming models the real world. Java is Objectoriented language because programming in Java is centered on creating objects, manipulating objects, and making objects work together. (c) Low Cost You dont need to spend time and money to obtain licenses since ANDRIOD and much of its software come with the GNU General Public License. You can start to work immediately without worrying about, that your software may stop working anytime because the free trial version expires. Additionally, there are large repositories from which you can freely download high quality software for almost any task you can think of. (d) Stability ANDRIOD doesnt need to be rebooted periodically to maintain performance levels. It doesnt freeze up or slow down over time due to memory leaks and such. Continuous up-times of hundreds of days (up to a year or more) are not uncommon.

17

(e) Performance ANDRIOD provides persistent high performance on MOBILES and on networks. It can handle unusually large numbers of users location change, and can make old computers mobiles responsive to be useful again. (f) Flexibility Java can be used for high performance server applications, desktop applications, embedded systems and Mobile applications. You can save disk space by only installing the components needed for a particular use. You can restrict the use of specic computers by installing for example only selected oce applications instead of the whole suite.

3.5.5 3.5.6

Requirement for reuse of code User Classes and Characteristics

This application is intended for android base cell phone user who looking for more security for their messanging.

3.5.7

Operating Environment

This application will operate on Android 2.0 and up. Additionally, there will be an enhanced tablet version for tablets running Android version 3.0 and up.

3.5.8

Design and Implementation Constraints

The application will be reduced little speed than general messenger, battery intensive and only available in the English language.

18

CHAPTER - 4 SYSTEM ARCHITECTURE

A system architecture or systems architecture is the conceptual model that denes the structure, behavior, and more views of a system.An architecture description is a formal description and representation of a system, organized in a way that supports reasoning about the structures of the system, A system architecture can comprise system components, the externally visible properties of those components, the relationships (e.g. the behavior) between them. It can provide a plan from which products can be procured, and systems developed, that will work together to implement the overall system. There have been eorts to formalize languages to describe system architecture, collectively these are called architecture description languages.

19

4.1

PROPOSED SYSTEM

In this we are developing the secure messenger for android using advanced encryption standard algorithm using 512 bit key on android platform.This application will be more secure than AES 128 bit and 256 bit algorithms and will least vulnerable to bruteforce attack.

4.2

SYSTEM ARCHITECTURE

Figure 4.1: System Architecture

Here the system consist of two blocks in which each block consist of three sub blocks namely Senders text message AES Encryption 512 bit Encrypted message 20

4.3

SYSTEM WORKING

The sender creates the text message on his android bsed smartphone After that the message is encrypted using advanced encryption standard algorithm of 512 bit key and then tne encrypted message is sended to the receiver .After that the the message is decrypted and the original message is displayed to receiver

4.4

MODULES

Modular programming (also called top-down design and stepwise renement) is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality.Conceptually, modules represent a separation of concerns, and improve maintainability by enforcing logical boundaries between components. Modules are typically incorporated into the program through interfaces.A module interface expresses the elements that are provided and required by the module. The elements dened in the interface are detectable by other modules. The implementation contains the working code that corresponds to the elements declared in the interface.

4.4.1

Sender module

Creates messages whos maximum size is 160 character and sends the messages

4.4.2

Receiver module

Receives messages which are sended by the sender

4.4.3

AES module

This module encrypts the message which is sended by the sender and decrypts the message at receiver side by using advanced encryption standard algorithm

21

CHAPTER - 5 ALGORITHMIC STUDY

The algorithm study project provides tools and resources to augment the traditional study of algorithms, specically[14]: Real implementations of common and less-common algorithms in a variety of languages, and Visualization tools to help in gaining a deeper understanding of the algorithms.

5.1
5.1.1

AES ENCRYPT ALGORITHM


Input

1. Plain text 2. Round key

5.1.2

Output

1. Cipher text

5.1.3

Process

AES Encryption Algorithm AESEncrypt(state, key[0, ..., 4K-1]) //Essentially, take a state containing the plain-text // to be encrypted and a K-word cipher stored in an array called key InverseKeyExpansion(key[0, ..., K-1], W[0, ..., N(R+1) - 1]) //The rst k words of W contain 4k bytes of the key array 22

AddRoundKey(state, W[0,...,3N]) //Adds the rst round key to the state for(inti = r-2 ; i> 0 ; i--) { InverseByteSubstitution(state) InverseShiftRow(state) InverseMixColumn(state) AddRoundKey(state,W[i,... 3+i]) } //Do the Final Round ByteSubstitution(state) ShiftRow(state) ByteSubstitution(state) AddRoundKey(state, W[N(R+1) - 4,...,N(R+1) - 1]) //End of Encryption Algorithm

5.1.4

Complexity

The Complexity of one round of AES Algorithm (4(24n 1)) (4(n/4)) (2(24n + 1))) (log [4(24n 1) + 4(n/2) + 2(24n + 1)]) (log [216n 2 + 4(n/2) + 28n + 2)]) (log [224n]) (e24n)wheren = 32

The Complexity of one round of proposed 256 bits AES encryption algorithm: (e24n) where n=64 The proposed 512 bits AES algorithm also increased the complexity of previous AES algorithm by using an additional operation (XOR) for each round.

23

5.2
5.2.1

AES DECRYPTION ALGORITHM


Input

1. Round key 2. Cipher text

5.2.2

Output

1. Plain text

5.2.3

Process

AES Decryption Algorithm AESDecrypt(state, key[0, ..., 4K-1]) //Essentially, take a state containing the cipher-text // a K-word cipher stored in an array called key InverseKeyExpansion(key[0, ..., K-1], W[0, ..., N(R+1) - 1]) //The rst k words of W contain 4k bytes of the key array AddRoundKey(state, W[0,...,3N]) //Adds the rst round key to the state for(inti = 0 ; i< r - 2; i++) { InverseByteSubstitution(state) InverseShiftRow(state) InverseMixColumn(state) InverseAddRoundKey(state,W[i,... 3+i]) } //Do the Final Round InverseByteSubstitution(state)

InverseShiftRow(state)

24

InverseByteSubstitution(state) AddRoundKey(state, W[N(R+1) - 4,...,N(R+1) - 1]) //End of Decryption Algorithm

5.2.4

Complexity

The Complexity of one round of AES Algorithm (4(24n 1)) (4(n/4)) (2(24n + 1))) (log [4(24n 1) + 4(n/2) + 2(24n + 1)]) (log [216n 2 + 4(n/2) + 28n + 2)]) (log [224n]) (e24n)wheren = 32

The Complexity of one round of proposed 256 bits AES encryption algorithm: (e24n) where n=64 The proposed 512 bits AES algorithm also increased the complexity of previous AES algorithm by using an additional operation (XOR) for each round.

5.3

MATHEMATICAL MODEL

AES is a block cipher and the most popular algorithm used in symmetric key cryptography. It is a substitution-permutation network and not a Fiestel network like DES. When the number of rounds is increased in AES, the complexity of AES encryption and decryption also increases. The number of rounds (Nr) in the .

AES algorithm depends on the length of main keys (Nk) and the number of block columns (Nb), i.e. N r = N k + N b + abs(N k N b). So, the length of the key is increased to 512 bits in order to increase the number of rounds. The structure of AES is quite simple. The input to the encryption and decryption algorithms is a single 128-bit block and the key is 512 bits. It requires the same key to be used for encryption and decryption.

25

Implementation of AES Encryption AES operates on a 1632 array of bytes, termed the state. The input key for encryption is 512 bits. To represent the 512 values 9 bits are required. So each entry in S-box of AES 512 is 9 bits long. The cipher is specied in terms of repetitions of processing stjpg that are applied to make up rounds of keyed transformations between the input plain-text and the nal output of cipher-text. The encryption procedure of AES 512 has been illustrated in gure 1.Each round in AES 512 encryption includes four dierent round transformations namely Substitute Bytes, Shift Rows, Mix Columns and Add Round Key. The last round of AES 512 encryption alone does not include the Mix Columns transformation.

The AES Encryption Algorithm As already mentioned the AES encryption algorithm takes as input a state and produces a state that contains the cipher-text. The algorithm can be described as below

AES Encryption Algorithm

AESEncrypt(state, key[0, ..., 4K-1]) //Essentially, take a state containing the plain-text // to be encrypted and a K-word cipher stored in an array called key InverseKeyExpansion(key[0, ..., K-1], W[0, ..., N(R+1) - 1]) //The rst k words of W contain 4k bytes of the key array AddRoundKey(state, W[0,...,3N]) //Adds the rst round key to the state for( int i = r-2 ; i> 0 ; i--) { InverseByteSubstitution(state) InverseShiftRow(state) InverseMixColumn(state) 26

AddRoundKey(state,W[i,... 3+i]) } //Do the Final Round ByteSubstitution(state) ShiftRow(state) ByteSubstitution(state) AddRoundKey(state, W[N(R+1) - 4,...,N(R+1) - 1]) //End of Encryption Algorithm

Figure 5.1: Encryption procedure of AES 512

27

Implementation of AES Decryption A set of reverse rounds are applied to transform cipher-text back into the original plain-text using the same encryption key. The four reverse transformations used are Add Round Key, Inverse Mix Columns, Inverse Shift Rows and Inverse Substitute Bytes. The inverse S-box contains 512 values in its 16x32 array of bytes. Each round in decryption of AES 512 includes all the four reverse transformations except in the rst round. The Inverse Mix Column transformation is violated in the rst round of decryption since it does not occur in the last round of encryption. The decryption procedure of AES 512 is illustrated in gure 5.2.

The AES Decryption Algorithm The decryption of encrypted data is achieved by applying the inverse functions to those used in the encryption phase in the same order. AES Decryption Algorithm

AESDecrypt(state, key[0, ..., 4K-1]) //Essentially, take a state containing the cipher-text // a K-word cipher stored in an array called key InverseKeyExpansion(key[0, ..., K-1], W[0, ..., N(R+1) - 1]) //The rst k words of W contain 4k bytes of the key array AddRoundKey(state, W[0,...,3N]) //Adds the rst round key to the state for( int i = 0 ; i < r - 2; i++) { InverseByteSubstitution(state) InverseShiftRow(state) InverseMixColumn(state) InverseAddRoundKey(state,W[i,... 3+i]) } //Do the Final Round InverseByteSubstitution(state) 28

InverseShiftRow(state) InverseByteSubstitution(state) AddRoundKey(state, W[N(R+1) - 4,...,N(R+1) - 1]) //End of Decryption Algorithm

Figure 5.2: Decryption procedure of AES 512

5.4
5.4.1

FEASIBILITY STUDY
NP Hard Study

P(Polynomial Time):As name itself suggests, these are the problems which can be solved in polynomial time. 29

NP(Non-deterministic-polynomial Time):These are the decision problems which can be veried in polynomial time. That means, if I claim that there is a polynomial time solution for a particular problem, you ask me to prove it. Then, I will give you a proof which you can easily verify in polynomial time. These kind of problems are called NP problems. Note that, here we are not talking about whether there is a polynomial time solution for this problem or not. But we are talking about verifying the solution to a given problem in polynomial time. NP-Hard:These are the hardest problems. If we can solve these problems in polynomial time,we can solve any other NP problem that can possibly exist. Note that,these problems are not NP problems. That means, we may/may-not verify the solution to these problems in polynomial time. NP-Complete:These are the problems which are both NP and NP-Hard. That means,if we can solve these problems, we can solve any other NP problem and the solutions to these problems can be veried in polynomial time. In our system we convert the NP-Hard problem into NP-Complete.

30

CHAPTER - 6 SYSTEM DESIGN

Systems design is simply the design of systems. It implies a systematic and rigorous approach to design .An approach demanded by the scale and complexity of many systems problems. Systems design rst appeared shortly before World War II as engineers grappled with complex communications and control problems. They formalized their work in the new disciplines of information theory, operations research, and cybernetics. In the 1960s, members of the design methods movement (especially Horst Rittel and others at Ulm and Berkeley) transferred this knowledge to the design world. Systems design continues to ourish at schools interested in design planning and within the world of computer science. Among its most important legacies is a research eld known as design rationale, which concerns systems for making and documenting design decisions.

6.1

DFD

A data ow diagram (DFD) is a graphical representation of the ow of data through an information system, modeling its process aspects. Often they are a preliminary step used to create an overview of the system which can later be elaborated.[2] DFDs can also be used for the visualization of data processing (structured design). A DFD shows what kinds of information will be input to and output from the system, where the data will come from and go to, and where the data will be stored. It does not show information about the timing of processes, or information about whether processes will operate in sequence or in parallel

31

6.1.1

DFD level 0

Figure 6.1: Dfd level 0

32

6.1.2

DFD level 1

Figure 6.2: Dfd level 1

6.1.3

DFD level 2

Figure 6.3: Dfd level 2

33

6.2

CFD

A control ow diagram (CFD) is a diagram to describe the control ow of a business process, process or program.A control ow diagram can consist of a subdivision to show sequential steps, with if-then-else conditions, repetition, and/or case conditions. Suitably annotated geometrical gures are used to represent operations, data, or equipment, and arrows are used to indicate the sequential ow from one to another

Figure 6.4: Control ow diagram

34

6.3

ER DIAGRAM

An Entity-Relationship diagram (ERD) typically serves as the main deliverable of a conceptual data model. While newer approaches to E-R modeling have developed, the E-R approach is still cited by some professionals as the premier model for conceptual database design. An ERD is a logical representation of an organizations data, and consists of three primary components: Entities:An Entity is a person, place, object, event, or concept that an organization wants to maintain data on. Each entity has a unique identity that dierentiates it from other entities. A point of distinction must be made between entity types and entity instances. An entity type is a collection of entities that share common properties . Entity types are also known as entity classes. An entity instance is an individual occurrence of an entity type. A data model describes an entity type only once; however there may be numerous instances of that type within a database. Attributes:An Attribute is a characteristic of an entity that is relevant to the organization. When dening an attribute, an analyst should state why the attribute is important, what is included in the attributes value, the source of the value, and whether or not that value can change. Again, a sound understanding of an organizations business should assist the analyst in compiling relevant attributes. Relationships:Relationships link the various components in an E-R diagram together. It is usually best to think of relationships as verbs and entities as nouns, which together comprise a complete sentence.Relationships depict either some kind of event occurring or a natural link between entity instances. A relationships degree indicates the number of entity types that participate in a given relationship. The three most common relationship degrees are: Unary (between instances of one entity type), Binary (between instances of two entity types), and Ternary (between three entity types).

35

Figure 6.5: E-R diagram

6.4

UML DIAGRAM

Unied Modeling Language (UML) is a standardized, general purpose modeling language in the eld of software engineering. The Unied Modeling Language includes a set of graphic notation techniques to create visual models of object-oriented softwareintensive systems.

The Unied Modeling Language was developed by Grady Booch, Ivar Jacobson and James Rumbaugh at Rational Software in the 1990s. It was adopted by the Object Management Group (OMG) in 1997, and has been managed by this organization ever since.

Design modeling uses a combination of text and diagrammatic forms to depict the requirements for data, function and behavior in a way that is relatively easy to understand and more important, straightforward to review for correctness, elements most often rendered as a connected graph of vertices (things) and arcs (relationship). These diagrams are drawn to visualize a system from dierent perspectives so a diagram into a system.

6.4.1

Use Case Diagram

A use case diagram is a type of behavioral diagram dened by the UML created from a use case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals represented as use case and any 36

dependencies between those use cases. Four modeling elements make up the use case diagram; these are:

Actors: Actors refer to a type of users; users are people who use the system. In this case student, teacher developers are the users of the framework and application.

Use cases: A use case denes behavioral features of a system. Each use case is named using a verb phrase that expresses a goal of the system. The name may appear inside or outside the ellipse.

Associations: An association is a relationship between an actor and a Use case. The relationship is represented by a line between an actor and a use case.

The include relationship: It is analogous to a call between objects. One use case requires some type of behavior which is fully dened in another use case.

37

Figure 6.6: Use Case Diagram

6.4.2

Activity Diagram

Activity diagrams are graphical representations of workows of stepwise activities and actions with support for choice, iteration and concurrency. In the Unied Modeling Language, activity diagrams can be used to describe the business and operational step-by-step workows of components in a system. An activity diagram shows the overall ow of control.

Use cases show what your system should do. Activity diagrams allow you to specify how your system will accomplish its goals. Activity diagrams show highlevel actions chained together to represent a process occurring in your system. An

38

activity diagram is essentially a owchart, showing ow of control from activity to activity. Unlike a traditional owchart, an activity diagram shows concurrency as well as branches of control. Activity diagrams focus on the dynamic ow of a system.

39

Figure 6.7: Activity Diagram

40

6.4.3

Class Diagrams

A class diagram in the Unied Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the systems classes, their attributes, operations (or methods), and the relationships among the classes.

The class diagram shows the building blocks of any object oriented system.Class diagram depicts a static view of the model or part of the model, describing what attributes and behavior it has rather that the detailing the methods of achieving operations.Class diagrams are most useful in illustrating relationships between classes and interfaces.Generalizations,aggregations,and associations are all valuable in reecting interface,composition or usage and connections receptively.

41

Figure 6.8: Class Diagram

42

6.4.4

State-transition Diagrams

State transition diagrams have been used right from the beginning in object-oriented modeling. The basic idea is to dene a machine that has a number of states (hence the term nite state machine). The machine receives events from the outside world, and each event can cause the machine to transition from one state to another. For an example, take a look at gure 1. Here the machine is a bottle in a bottling plant. It begins in the empty state. In that state it can receive squirt events. If the squirt event causes the bottle to become full, then it transitions to the full state, otherwise it stays in the empty state (indicated by the transition back to its own state). When in the full state the cap event will cause it to transition to the sealed state. The diagram indicates that a full bottle does not receive squirt events, and that an empty bottle does not receive cap events. Thus you can get a good sense of what events should occur, and what eect they can have on the object.

43

Figure 6.9: State-transition Diagram

44

6.4.5

Object Diagram

In UML, object diagrams provide a snapshot of the instances in a system and the relationships between the instances. By instantiating the model elements in a class diagram, you can explore the behavior of a system at a point in time. An object diagram is a UML structural diagram that shows the instances of the classiers in models. Object diagrams use notation that is similar to that used in class diagrams. However, while class diagrams show the actual classiers and their relationships in a system, object diagrams show specic instances of those classiers and the links between those instances at a point in time. You can create object diagrams by instantiating the classiers in class, deployment, component, and usecase diagrams.

Figure 6.10: Object Diagram

45

6.4.6

Communication Diagram

A collaboration diagram describes interactions among objects in terms of sequenced messages. Collaboration diagrams represent a combination of information taken from class, sequence, and use case diagrams describing both the static structure and dynamic behavior of a system.

Figure 6.11: Communication Diagram

46

6.4.7

Sequence Diagram

The sequence diagram is used primarily to show the interactions between objects in the sequential order that those interactions occur. Developers typically think sequence diagrams were meant exclusively for them. However, an organizations business sta can nd sequence diagrams useful to communicate how the business currently works by showing how various business objects interact. Sequence diagrams illustrate how objects interact with each other. They focus on message sequences, that is, how messages are sent and received between a numbers of objects. The main purpose of sequence diagram is to show the order of events between the parts of system that are involved in particular interaction.

The basic element of sequence diagram is collection of participants, that is, the parts of the system that interact with each other during the sequence. The participants are arranged horizontally with no two participants overlapping each other. A message is communication between objects that conveys information with the expectation that action will be taken. An event is any point in an interaction where something occurs. Message can ow in whatever direction makes sense for the required interaction from left to right, right to left, or even back to the Message Caller itself.

Figure 6.12: Sequence Diagram

47

6.4.8

Component Diagram

Component diagram is a special kind of diagram in UML. The purpose is also dierent from all other diagrams discussed so far. It does not describe the functionality of the system but it describes the components used to make those functionalities.

So from that point component diagrams are used to visualize the physical components in a system. These components are libraries, packages, les etc.

Component diagrams can also be described as a static implementation view of a system. Static implementation represents the organization of the components at a particular moment.

A single component diagram cannot represent the entire system but a collection of diagrams are used to represent the whole.

So the purpose of the component diagram can be summarized as: Visualize the components of a system. Construct executables by using forward and reverse engineering. Describe the organization and relationships of the components.

48

Figure 6.13: Component Diagram

6.4.9

Package Diagram

Package diagrams are used to reect the organizations of packages and their elements, and provide a visualization of their corresponding name space. Following are the elements of package diagram: 1. Package: A package is a namespace as well as an element that can be contained in other packages namespace. A package can own or merge with other package, and its elements can be imported into a packages namespace.

49

2. Class: A class is a representation of objects, that reects their structure and behavior within the system. It is a template from which actual running instances are created. A class may have attributes and methods.

3. Interface: An interface is a specication of behavior that implements agree to meet, it is a contract. By implementing an interface, classes are guaranteed to support a required behavior.

4. Object: An object is an instance of a class at runtime. Objects are often used in analysis to represent the numerous artifacts and items that exist in any business.

5. Table: A table is a stereotyped class. It is drawn with a small table icon in the upper right corner. A table element has special properties dialog with settings for database type and ability to set column information and data related operations such as triggers and indices.

50

Figure 6.14: Package Diagram

6.4.10

Deployment Diagram

The deployment diagram depicts the runtime architecture of devices, execution environments and artifacts that reside in this architecture. It is the ultimate physical description of the system topology, describing the structure of the hardware units and the software that executes on each unit. The deployment diagram shows how a system will be physically deployed in the hardware environment. Its purpose is to show where the dierent components of the system will physically run and how they will communicate with each other.

Figure 6.15: Deployment Diagram

51

CHAPTER - 7 SYSTEM IMPLEMENTATION

System implementation refers to the fourth phase of the systems development life cycle, in which the information system is programmed, tested, installed and supported. During the life cycle, the reporting requirements are specied and reports produced.

7.1

TECHNICAL SPECIFICATION

A detailed description of technical requirements, usually with specic acceptance criteria, stated in terms suitable to form the basis for the actual design development and production processes of an item having the qualities specied in the operational characteristics. See also operational characteristics.

7.1.1

Platform

Java Android

7.1.2

Programming Language

Java

7.1.3

Framework

Eclipse

7.1.4

Development tools

Eclipse Android SDK 52

ADT

7.1.5

Other tools

Eclipse

53

7.2

SOFTWARE DEVELOPEMENT LIFE CYCLE

The Waterfall Model was rst Process Model to be introduced. It is also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases.Waterfall model is the earliest SDLC approach that was used for software development .The waterfall Model illustrates the software development process in a linear sequential ow; hence it is also referred to as a linearsequential life cycle model. This means that any phase in the development process begins only if the previous phase is complete. In waterfall model phases do not overlap. In this we are using waterfall model Waterfall model Waterfall approach was rst SDLC Model to be used widely in Software Engineering to ensure success of the project. In The Waterfall approach, the whole process of software development is divided into separate phases. In Waterfall model, typically, the outcome of one phase acts as the input for the next phase sequentially. Following is a diagrammatic representation of dierent phases of waterfall model.

The sequential phases in Waterfall model are: Requirement Gathering and analysis: All possible requirements of the system to be developed are captured in this phase and documented in a requirement specication doc System Design: The requirement specications from rst phase are studied in this phase and system design is prepared. System Design helps in specifying hardware and system requirements and also helps in dening overall system architecture. Implementation: With inputs from system design, the system is rst developed in small programs called units, which are integrated in the next phase.

54

Figure 7.1: Waterfall model Each unit is developed and tested for its functionality which is referred to as Unit Testing. Integration and Testing: All the units developed in the implementation phase are integrated into a system after testing of each unit. Post integration the entire system is tested for any faults and failures. Deployment of system: Once the functional and non functional testing is done, the product is deployed in the customer environment or released into the market. Maintenance: There are some issues which come up in the client environment. To x those issues patches are released. Also to enhance the product some better versions are released. Maintenance is done to deliver these changes in the customer environment. All these phases are cascaded to each other in which progress is seen as owing steadily downwards (like a waterfall) through the phases. The next phase is started only after the dened set of goals are achieved for previous phase and it is signed o, 55

so the name Waterfall Model. In this model phases do not overlap.

7.3

SYSTEM IMPLEMENTATION PLAN

The following table describes the project plan for semester I. It describes the various activities and accountability of the developers for the respective modules. Following are the major activities carried out in this plan: Identifying the functional requirements. Designing of the Framework. Studying the necessary development tools and technologies.

56

Phase Activity 1

Start Date

End date 18/07/2013

Selection of project 12/07/2013 topic

Search for related papers for project topic

19/07/2013

25/07/2013

Serrch

information 26/07/2013

1/08/2013

about AES algorithm 4 Study and understand working and calculation of Aes algorithm 5 6 Literature survey Construction of Uml diagrams 7 Study of android and its development environment 8 Develop the sender side module 9 Work on receiver side 27/09/2013 module 10 Presentation on phase I and generation of project report 01/10/2013 30/10/2013 20/09/2013 26/09/2013 06/09/2013 19/09/2013 23/08/2013 30/08/2013 29/08/2013 05/09/2013 2/082013 22/082013

57

7.3.1

Risk Management

Risk management is the identication, assessment, and prioritization of risks followed by coordinated and economical application of resources to minimize, monitor, and control the probability and/or impact of unfortunate events or to maximize the realization of opportunities. Risks can come from uncertainty in nancial markets, threats from project failures legal liabilities, credit risk, accidents, natural causes and disasters as well as deliberate attack from an adversary, or events of uncertain or unpredictable root-cause. Several risk management standards have been developed including the Project Management Institute, the National Institute of Standards and Technology, actuarial societies, and ISO standards.Methods, denitions and goals vary widely according to whether the risk management method is in the context of project management, security, engineering, industrial processes, nancial portfolios, actuarial assessments, or public health and safety. The strategies to manage threats typically include transferring the threat to another party, avoiding the threat, reducing the negative eect or probability of the threat, or even accepting some or all of the potential or actual consequences of a particular threat, and the opposites for opportunities. Certain aspects of many of the risk management standards have come under criticism for having no measurable improvement on risk, whether the condence in estimates and decisions seem to increase. For the risk management following methods should be carried out Identify, characterize threats. Assess the vulnerability of critical assets to specic threats Determine the risk (i.e. the expected likelihood and consequences of specic types of attacks on specic assets) Identify ways to reduce those risks. Prioritize risk reduction measures based on a strategy.

58

CHAPTER - 8 EXPECTED RESULT

8.1

EXPERIMENT NEEDED TO CONDUCT FOR ANALYSIS

In this section we are conducting the various experiments for analysis of input and output.specially this is for testing purpose in project.

8.1.1

Expected Output

The original plain text message which is identical to sended message.

8.1.2

Analysis

In this section we will conduct the experiment with the two android based smartphones. One is for sending message and another is for recieving message.Sender sends the message and reciever recieves the message.After this sender side message and reciever side message are checked and it will match.

8.2

FINAL ANALYSIS

In this we conclude that the both side messages are correct by comparing both messages.

59

CHAPTER - 9 APPLICATIONS

9.1

ADVANTAGES

More secured way for message communication Cost eceint No additional hardware required

9.2

LIMITATIONS

Decreases speed than general messangers operating speed Operates only on android based smartphone

9.3

APPLICATIONS

Military communication Mobile Banking Data communication where data need to be more secured personal use who want secured communication

60

CHAPTER - 10 CONCLUSIONS

Hence, We are going to implement new messenger which provides more security for users important communicating data. For this purpose we are going to use AES algorithm with 512 bit key which provides more security for encrypted data and the encrypted data becomes too much dicult to encrypt to the unauthorised third party.

61

REFERENCES

[1] Aes Algorithm Using 512 Bit Key Implemented For Secure Communication,2010, S Radhika, A ChandraSekar [2] Modications to AES Algorithm for Complex Encryp-

tion,2011PriyankaPimpale, Rohan Rayarikar,SanketUpadhyay [3] An investigation into the eld of cryptography andcryptographicprotocols,2009,Bradley Cowie and Barry Irwin [4] Advanced Encryption Standard,FIPS PUBcryptographicproto-

cols,2009,Bradley Cowie and Barry Irwin, November 2001. [5] AES-The Advanced Encryption Standard,2002,Springer-

Verlagcryptographicprotocols,2009,Bradley Cowie and Barry Irwin,J. Daemen and V. Rijmen. [6] A collision attack on seven rounds of Rijndael, Proceedings of the 3rd AEScryptographicprotocols,2009,Bradley Cowie and Barry Irwin ,H. Gilbert and M. Minier, April 2000. [7] Improved cryptanalysis of Rijndaelcryptographicprotocols,2009,Bradley Cowie and Barry Irwin,N. Ferguson, J. Kelsey, S. Lucks,2007. [8] Related-Key Boomerang and Rectangle Attackscryptographicproto-

cols,2009,Bradley Cowie and Barry Irwin,E. Biham, O. Dunkelman, and N. Keller,2005.

62

[9] Related-Key Dierential Cryptanalysis of 192-bit Key AES Variantscryptographicprotocols,2009,Bradley Cowie and Barry Irwin,G. Jakimoski and Y. Desmedt,2004. [10] Improved Impossible Dierential Cryptanalysis of Rijndael and Crypton,J. H. Cheon, M. J. Kim and K. Kim,et al.,2002. [11] Thread clustering: sharing-aware scheduling on SMP-CMPSMT multiprocessorscryptographicprotocols,2009,Bradley Cowie and Barry Irwin,D. Tam,R. Azimi,and M. Stumm,2007. [12] The performance implications of locality information usage in shared memory multiprocessorscryptographicprotocols,2009,Bradley Cowie and Barry Irwin,F. Bellosa and M. Steckermeier,1996. [13] Cryptography and network securitycryptographicprotocols,2009,Bradley

Cowie and Barry Irwin,Atul Kahate,Willam Stallings. [14] A Proposed 512 bits RC6 Encryption Algorithm,2008,Ashwaq

T,Hashim,Janan A. Mahdi,Salma H.Abdullah [15] Advanced Encryption Standard by Example,2009,Adam Berent

63

Você também pode gostar