You are on page 1of 30

CHAPTER 4: SYSTEMS ANALYSIS AND DESIGN

OVERVIEW This chapter focuses on the analysis of the system to be developed. The principal goal guiding the design of any encryption algorithm must be security. In the real world, however, performance and implementation cost are always of concern. The increasing need for secure digital communication and the incredible processing power of desktop computers make performing software bulk encryption both more desirable and more feasible than ever. System Analysis, also known as requirement analysis, gathers a thorough and detailed understanding of the business needs and refines them into discreet requirements, which will be clearly defined and reviewed. This chapter gives the overall overview of how the multi algorithm cryptography concept is used in the project. It also gives complete picture of how multiple crypto algorithms work for example the popular AES and Triple-DES . It also illustrates supplementary design documents such as class diagrams; sequence diagrams and data flow diagrams that were drawn realizing the system

The quality of the final system is dependent on the requirements identification process. The System Analysis phase creates a detailed Functional Specification defining the full set of system capabilities to be implemented, along with the accompanying data and process models illustrating the information to be managed and the processes to be supported by the system. An in-depth knowledge of the design techniques is required together with a sound knowledge of the system requirements. Finally Design will merely build upon the requirements and will map the requirements to the design to satisfy them.

SYSTEM DESCRIPTION The system is a local application. The system components are listed below in the subsystem architecture. The system under development can be broken down into separate subsystems that interact together to produce one system. SUBSYSTEM ARCHITECTURE The system consists of the following subsystems: 1. Encryption At the basic level, the system will input unencrypted file name/location , algorithm, key. The system will output the encrypted file to a location or textfield. 2. Decryption At the basic level, the system will input encrypted file name/location, algorithm that was used to encrypt file, key. The system will output the decrypted file. 3. Hashing At the basic level, the system will input a file and a hash algorithm to be used. The system will then output the hash/message digest of the input file.

USER Key

Decryption

Encryption

Filename

Algorit
Password Safe

USER

Zero Level CryptoSystem DFD

Algorithm, Filename

HASHING

Hashing Key

Zero Level CryptoSystem DFD part 2

User account info

OVERVIEW OF DESIGN PROCESS The design process is divided into three phases, namely conceptual, logical and physical design. These two phases, logical and conceptual, will be used for each subsystem with different inputs and outputs. The subsystems will deal with different aspects of the system so can be designed as modular independent systems. Overall Description

Product Perspective The Encryption Project shall run as a standalone application. While the software is running, the user shall be able to select which component to input values. This incorporates the selection of a cryptographic algorithm and any plaintext.

System Interfaces The system is intended to interface with a single user at any given time. The user is able to interact with the system using a graphical user interface.

User Interfaces Paradigms The Graphical UI (GUI) will support all standard menus/buttons/options found in other programs such as menu bar (File, Edit, Help etc.), status bar, key generation progress bar etc.

The user interface must provide the user an understandable and effective way for entering attributes into the system. Java will be used to create the graphical user interface for the system. At the top of the GUI is a panel that will display each of the encryption algorithms that may be used (including the Caesar cipher, AES,RSA , columnar transposition, hashing algorithm, and etc. Below that is a text field that allows the user to enter the plaintext that is to be encrypted. Depending on the type of algorithm chosen, the user will also be given the option of choosing various options such as the various key or substitutions. At the bottom of the interface is a text area that displays the result of the cryptographic scheme or cipher text. An option is provided at the console area that displays any output that will attempt to give the user some insight into how the encryption schemes work.

Architectural Strategies Here are the design decision and strategy that will affect the overall organization of the system and its higher level structures:
I chose to use Java for core cryptographic code, Java Cryptographic Extension (JCE),

strong Cryptography for cryptographic algorithms, Java Swing desktop Application NetBeans 6.9 IDE for program GUI .
I chose Java Swing for this program GUI because Java is cross platform that makes the

program portable.

I chose Java language because of the security features that are built in to the platform

itself. Java was designed to enable small programs, applets, to be downloaded and run without danger. The Java Development Kit (JDK) 6 includes some interesting security enhancements, including the concepts of protection domains, permissions, and policies. This fits into our requirement for encryption/decryption program
Future plans to extend CryptoSystem include implementing asymmetric algorithms over

a secured network with centralized key management. There are future plans to include functions for compression, splitting, synchronizing, and archiving files to make this system a complete learning tool.

USER INTERFACE PARADIGMS: All cryptographic functions, and hashing functionalities are accessible from the GUI. Special effort is put in this project to produce an intuitive, simple, and streamlined graphical user interface for technical users.

Design Constraints:

Public key or asymmetric cryptographic algorithms usually take a lot of computation time

and memory as compared to symmetric ciphers. In most cases, symmetric ciphers are recommended for data encryption (and decryption) unless the user is willing to spend large amount of computational effort to encryption/decryption using public key cipher. Public key ciphers are recommended to be used only in situations such as authentication or to confidentially distribute symmetric keys. This project will be based on the symmetric key ciphers only.

Performance requirements: Most public key ciphers rely on high computational cost

operations. Therefore, keeping performance considerations in mind, in most cases symmetric ciphers are recommended for data encryption/decryption.
Security requirements: This application though it is a learning tool uses strong

cryptography, so it falls under certain export/import and/or use restrictions in some other parts of the world, even if it is created, maintained, and distributed from liberal countries (where it is legal to do so).
Safety requirements: This application suite is a learning tool or proof of concept project.

So there are chances of possible damage or loss to data or harm that will result from the use of this suite. User is required to remember his password that he/she used to encrypt data because most of the secure cryptographic algorithms implemented in this suite are secure enough so that no algorithms better than the brute force can be used to recover lost password. ANALYSIS AND DESIGN OF THE MULTI ALGORITHM CRYPTOSYSTEM Overview The first task is to develop the conceptual model of the system which seeks to describe the system from the perspective of the user. The conceptual model will be the input to the logical design which will describe how the system will be developed.

CONCEPTUAL DESIGN The conceptual design abstractly describes systems intended behavior. It is a process of acquiring, documenting, validating, and optimizing business and user perspectives of the solution. Specific Requirements for Proposed System Overview These requirements will allow the user to gain knowledge in how different encryption schemes do their magic.

FUNCTIONAL REQUIREMENTS Encryption Algorithms The system must be able to allow the user to select from the following encryption schemes: a Caesar Cipher, AES, RSA, RailFence, and the Hash functions.

Caesar Cipher The user must be allowed to select the extent to which the alphabet will be shifted.

Polyalphabetic Substitution (Vigenere) The user must be allowed to select the character mappings for each letter of the alphabet for each character that appears in the plain text. There must also be two different mappings depending on where the character appears in the plain text, one mapping for odd characters and another for even characters. AES The user must be allowed to enter the variable keys that are to be used in creating the ciphertext. RSA Each user will be allowed to enter in their own keys that will be used.

HASHING Each user will be allowed to enter their own keys that will be used

Plaintext Input The user must be able to enter a plaintext message that will be encoded by our software or allow user browse to a file of choice .

Encryption Algorithm Selection The user must be able to select the encryption mechanism to be used to create the ciphertext. Frequency Analysis The user must be able to select frequency analysis some of ciphertext produced by Caesar and Vigenere ciphers

ALGORITHMS

Caesar Cipher Algorithms


Input : plain message Output : crypted message function encipher(message, shift) for i from 0 to length(message) if message[i] greater than 126 or smaller than 32 then leave character unchanged else if message[i] + shift greater than 126 then cryptedMessage[i] = ((message[i] + shift)mod127)+33 else cryptedMessage[i] = message[i] + shift return cryptedMessage

Caesar Deciphering Algorithm


Input : crypted message Output : plain message function decipher (message , shift) for i from 0 to length(message) if message[i] greater than 126 or smaller than 32 then leave character unchanged else if message[i] shift smaller than 32 then plainMessage[i] = 126 - (31 - (message[i] - shift)) else plainMessage[i] = message[i] - shift return plainMessage

RSA Encryption/Decryption Algorithms RSA Key Generation Algorithm Input : p, q and e Output: d, n, (pq) 1. Take two distinct prime numbers p and q 2. Calculate n = p.q 3. Compute (pq) = (p 1)(q 1) 4. Take e, such that 1 < e < (pq), and e and (pq) share no divisors other than 1. Calculate d which satisfies : RSA Encryption Algorithm Input : plainMessage, e, n Output : ciphertextMessage c = m^e (mod n) RSA Decryption Algorithm Input : ciphertextMessage, d, n Output : plaintextMessage

m = c^d (mod n)

Encryption Algorithms Algorithm: Encryption with password using block cipher in CBC mode INPUT:

Plaintext inputText in text format. A pre-agreed secret password in text format. iterationCount, an integer > 1000. Encryption algorithm (e.g. AES-128) with given keySize and blockSize.

OUTPUT:

Initialization Vector iv in bit-string format. cipherText in bit-string format.

1. Generate a random value of the same size as the block length of the encryption algorithm randVal = GenerateRandomValue(blockSize) 2. Set iv = randVal salt = randVal 3. Generate a key of the required size for the encryption algorithm key=KDF2(password, salt, iterationCount, keySize) 4. Convert the input text to `binary' format work = BitStringFromText(inputText) . 5. Pad this to the next-highest multiple of the encryption block size work = Pad(work, blockSize) . 6. Encrypt the working block in CBC mode using the key and IV ciphertext = EncryptCBC(work, key, iv)
7. Output iv and cipherText.

Decryption Algorithm Algorithm: Decryption with password using block cipher in CBC mode INPUT:
cipherText in bit-string format. A pre-agreed secret password in text format.

An integer iterationCount Initialization Vector iv in bit-string format. Encryption algorithm (e.g. AES-128) with given keySize and blockSize.

OUTPUT:
Plaintext outText in text format or "decryption error"

1. If Length(iv) != blockSize OR Length(cipherText) Mod blockSize != 0 then output "decryption error" and stop. 2. Set salt = iv 3. Generate a key of the required size for the encryption algorithm key=KDF2(password, salt, iterationCount, keySize) 4. Decrypt the ciphertext using the key and IV work = DecryptCBC(cipherText, key, iv) 5. Remove the padding, if any work = Unpad(work, blockSize) 6. If no valid padding is found, output "decryption error" and stop. 7. Convert the bit-string ciphertext to `text' format outText = TextFromBitString(work)
8. Output Plaintext outText in text format.

Padding Before encryption you need to convert the plaintext to bit-string format and then pad so that the input to the encryption process is an exact multiple of the block length. For AES the block length

is 16 bytes (128 bits). The recommended padding procedure is to pad with bytes all of the same value as the number of padding bytes. This is the method recommended in [PKCS5], [PKCS7], and [CMS]. Pad the input with a padding string of between 1 and 16 bytes to make the total length an exact multiple of 16 bytes. The value of each byte of the padding string is set to the number of bytes added - i.e. 16 bytes of value 16 (0x10), 15 bytes of value 15 (0x0F), ..., 2 bytes of 0x02, or one

VIEWING MESSAGES

Plaintext The user must be able to view the plaintext message that he or she has input. The user must be able to select the path of the text file to be encrypted.

Ciphertext The user must be allowed to view the encoded ciphertext in one of a variety of forms that are used in encodings today, mainly the ASCII standard, decimal, hexadecimal, and binary. The user must be given an option to select path to store the cipher text and an option to wipe out the original plaintext.

Optional View Console The user must be able to select and view any messages that will give them insight into the inner workings of the particular encryption algorithm chosen.

Nonfunctional Requirements

User Interface and Human Factors Depending on how the user chooses to access the system, through login into standalone application, the system will still function independently of how the user chooses to execute it. All input fields will be aligned in the center of any panel that contains the component for ease of use reasons.

Documentation and Manuals The system should be self-explanatory to anyone that is familiar to the encryption algorithms employed. The message option will serve as a reference to beginners and help them understand the functionality of the algorithm.

Scalability The system should continue to perform as the size of encryption files increases.

DEPLOYMENT PLATFORM Software If run as a standalone application, the user must have a recent version of Java2 installed on their system.

Operating System Because Java is used, the operating system will be irrelevant. The system will run on any OS that supports Java2, including, but not limited to, Windows, Linux, and MacOS.

Graphics
A graphical user interface is used to enhance usability and must be able to run on any display that supports 640x480 resolution or higher.

Hardware The system must run on all systems that support Java2.

Error Handling The system must check to ensure that all values in fields are valid (if an input field expects a letter of the alphabet, then great pains must be taken to ensure that the user does not input a nonalphabetic character), and that numerical fields have values that lie within the specified range.

Quality Issues The program should not halt or crash during execution. The program must not alter the state of the users system after closing. As far as security issues are concerned, no files on the users system are read or otherwise modified.

ANALYSIS This section is responsible for the building of information models to ensure that the user requirements and business requirements are clearly understood and properly specified System Models Program Subsystems Outline Detail System Design The Multi Algorithm CryptoSystem consists of following subsystems: 1. Encryption 2. Decryption 3. Frequency Analysis and cryptanalysis 4. Hashing/ Message Digest

Program Subsystem Outline

M ulti A rithmC tosystem lgo ryp

C ryptographic A lgorithm s

C ry h ash

E ncryption

D ecryptio n

M ulti A lgorithm C rypto ystem S P rogramS ubsystemO utline

Encryption Classification: This component is classified as a separate module or subsystem. Definition: In cryptography encryption is the process of transforming (plaintext) using an algorithm (called cipher) to make it unreadable to anyone except those possessing special knowledge of the key.

Decryption: Classification: This component is classified as a separate module or subsystem. Definition: Decryption is process of making the encrypted text(cipher text) readable again.

File name , algorithm

Write output encrypted file

USER
Key

ENCRYPTION
Read input file

Figure : Level one DFD for Encryption

File name

Write out decrypted file

USER
Key

DECRYPTION

Read Encrypted file

Hashing: Figure : Level one DFD for Decryption Classification: This component is classified as a separate module or subsystem. Definition:A cryptographic hash function is a deterministic procedure that takes an arbitrary block of data and returns a fixed-size string, the (cryptographic) hash value , such that an

accidental or intentional change to the data will change the hash value

U R S E

H hg l ot m a i A rh sn g i

R dnuF e I pt ie a l

I ptF nm nu iea e l Lcto o in a

H hg ai sn P cs r e o s

F
W O Hh re u a i t t s Fu i r ge : L eO D f r ah g e l N F oH i v E D sn

Scenarios <not yet included>

Activity Diagrams and Sequence Diagrams <not yet included>

Use Cases

Multi Algorithm CryptoSystem should support the following use cases: Class of Use Cases Use case related to encryption Use case related to decryption Use case related to frequency analysis Use Cases Encryption Decryption Frequency analysis Description of Use Case Encrypts files to cipher Text Decrypts cipher text Gives the frequency of letters in cipher text

User Characteristics: The main users of this tool will be people who want to have some secrecy in their data and also students studying cryptography. General Constraints: It is a single user software and is build to run on any platform with Java Runtime Environment. USE CASES Use case related to encryption: Use case 1: Encryption Primary Actor: User Precondition: There is a plain text to encrypt. Main Scenario: 1. User selects the algorithm for encrypting 2. User can enter the key or generates it using passphrase. 3. Encryption is done by the system using the algorithm. 4. Cipher text is produced. Alternate Scenario: 1.(a)User enters invalid key 2.(a)Prompts key error to the user. Use case related to decryption: Use case 2: Decryption Primary Actor: User Precondition: There is a cipher text to decrypt Main Scenario: 1. User chooses the correct algorithm to decrypt. 2. User enters the key for decryption. 3. Decryption is carried out by the system. 4. Plain text is given as output.

Alternate Scenario: 1.(a) Algorithm for decryption not available. 2.(a) User enters wrong key 3.(a) User gets unreadable output Use case related to Login: Use case 3: Login Primary Actor: User Precondition: there is a database to authenticate user and grant security levels Main Scenario: 1.User enters user name and password 2. New user is added or deleted and assigned security levels 3.System performs encryption or decryption of password before storing onto database. 4.User is authenticated and presented with encryption/decryptions options to use. Alternate scenario: 1(a). The system fails to match users that are found in the database. 2(a). System reports unsuccessful authentication or reports user does not exit. Use Case related to frequency analysis: Use case 4: Frequency analysis Primary Actor: User Precondition: There is a cipher text for analysis Main Scenario: 1. User chooses the cipher test for frequency analysis. 2. Frequency analysis is done by the system. 3. System outputs the frequency distribution of the letters.

Software System Characteristics Security There are no known security flaws at this time.

Maintainability The source code should be properly documented, so that new developers will be able to understand the code as easily as possible.

Portability Since Java is used as the development language, there should be few problems porting the software to new platforms. As an added bonus, as long as the platform contains a java-capable browser, the system will run as an applet.

5. IMPLEMENTATION
The project is planned and implemented in Java, along with JDK 1.5 on windows environment. As mentioned in the design the project is mainly divided into main four modules Hybrid, Classic, Digital Signatures and Hashing Algorithms intern Hybrid contains three sub-modules RSA and AES, Classic contains four sub-modules vigenire, playfair, caesar and transposition, Digital signatures contains DSA using RSA, and hashing contains MD5 and SHA1 . These modules are implemented as separately in this section. The source code of the project contains the many built-in java packages, classes implemented in .java files and lot of data structures, inter-dependencies of the modules, our approach to explain the implementation is to start with the explanation of the content and purpose of some important java packages used, then follows the major data structures used and finally classes i.e. .java and their inter-dependency.

Java Packages
1. java.lang package: Provides classes that are fundamental to the design of the Java programming language. The most important classes are Object, which is the root of the class hierarchy, and Class, instances of which represent classes at run time. 2. java.awt package: Contains all of the classes for creating user interfaces and for painting graphics and images.

3. java.awt.event package: Provides interfaces and classes for dealing with different types of events fired by AWT components. 4. javax.swing package: Provides a set of "lightweight" (all-Java language) components that, to the maximum degree possible, work the same on all platforms. 5. javax.swing.event package: Provides for events fired by Swing components. 6. java.io package: Provides for system input and output through data streams, serialization and the file system. 7. java.net package: Provides the classes for implementing networking applications.

The Major Classes and the Functions Hybrid Algorithms Module


AES Classes and Functions AES.java
This class implements Aes GUI for running and testing AES implementations using Sun Java libraries, and the BouncyCastle.org libraries.

The class includes the following functions: private static void createAndShowGUI()

This function is responsible for creating and showing the graphical user interface.Creates the
JLabel, JRadioButton, ButtonGroup and other swing components.

private void generateKey()

creates an AES-implementing object of the specified type and have it generate a key. Update the key display area accordingly. private void generateIV()

creates an AES-implementing object of the specified type and have it generate a key. Update the key display area accordingly.

public String getCipherText() Get the cipher text to be decrypted, or returned from an encryption operation. public KeySize getKeySize() Get the KeySize to use for the current AES-implementing object. Returns the KeySize to use for the current AES implementing object. public Mode getMode()

Get the mode to use for the current AES-implementing object. Returns the mode to use for the current AES implementing object. public String getPlainText() Get the plaintext to be encrypted, or returned from a decryption operation. return the plaintext to be encrypted, or returned from a decryption operation. private void doEncrypt()

Method that ensures there is some plaintext to encrypt, initializes an AES-implementing object, encrypts the text, and displays the results. private void doDecrypt()

Method that ensures there is some cipher text to decrypt, initializes an AES-implementing object, decrypts the text, and displays the results. public interface AES_Implementable Interface for implementations of AES encryption, to allow comparisons of the various implementations.

You might also like