A Project Report on

A LOSSLESS MOD-ENCODER
TOWARDS A SECURE
COMMUNICATION
Submitted in partial fulfilment for award of

Bachelor of Technology

Degree

in

Computer Science & Engineering

By

K.SAI SPHURTHI (Y10ACS450)

A.NIVYA (Y10ACS402)
B.NAGA SATYA NARAYANA (L11ACS523)
K.TEJASWINI (Y10ACS449)

Under the guidance of

S.NAGA SINDHU,M.Tech
Asst.Professor

Department of Computer Science & Engineering

Bapatla Engineering College
(Autonomous)
BAPATLA 522 101, Andhra Pradesh, INDIA
2013-2014

1
 Department of
Computer Science & Engineering

CERTIFICATE
This is to certify that the project report entitled A LOSSLESS MOD-

ENCODER TOWARDS COMMUNICATION that is being submitted by

K.SaiSphurthi(Y10ACS450), A.Nivya(Y10ACS402), B.N.Satyanarayana

(L11ACS523), K.Tejaswini(Y10ACS449) in partial fulfilment for the

award of the Degree of Bachelor of Technology in Computer Science and

Engineering to the Acharya Nagarjuna University is a record of bonafide

work carried out by them under my guidance and supervision. The results

embodied in this project report have not been submitted to any other

University or Institute for the award of any degree or diploma.

Date:

Signature of Guide Signature of HOD

S.NAGA SINDHU,M.Tech V.CHAKRADHAR, M.Tech
Asst. Professor Professor & Head
Department of CSE Department of CSE

(a) ACKNOWLEDGEMEN
T

2
 I sincerely thanks many distinguished personalities who have given their
advice and support for successful completion of thesis work.

I am deeply indebted to most respected and guide Miss. S. NAGA SINDHU,

Asst.Professor, Department of CSE, for her valuable and inspiring guidance,
comments, suggestions and encouragements.

I extend my sincere thanks to Prof.V.CHAKRADHAR, Head of the

Department and other senior faculty for extending their cooperation and providing the
required resources.

I would like to thank Dr. N.SUDHAKAR, Principal, for providing the online
resources and allowed to carry out this work.

I would like to thanks to Sri P. RAJESH KUMAR Project Coordinator for

providing the guidance, suggestions and sources and allowed to carry out this work.

I extend my sincere thanks to all other teaching faculty and non-teaching staff
of the department, who helped directly or indirectly for their cooperation and
encouragement.

TABLE OF CONTENTS

3
CHAPTER NO. TITLE PAGE NO.

ABSTRACT vii

LIST OF TABLES viii

LIST OF FIGURES ix

1.INTRODUCTION 1
2. EXISTING ALGORITHMIC ANALYSIS 2
2.1 Triple DES 2
2.2 AES 2
2.3 RC4 2
3. THE PROPOSED MOD ENCODER ALGORITHM 3
3.1 The MOD-ENCODER Encoding Algorithm 3
3.2 The MOD-ENCODER Decoding Algorithm 3
3.3 Compression mechanism 4
3.4 Examples and Discussions 4
4. SOFTWARE REQUIREMENTS SPECIFICATION 6
4.1 Introduction 6
4.2 Functional Requirements 6
4.2.1 Functional Requirements for Present Project 6
4.3 Non Functional Requirements 6
5. SYSTEM REQUIREMENTS 8
5.1 Introduction 8
5.2 Hardware Requirements 8
5.2.1 Hardware Requirements for Present Project 8
5.3 Software Requirements 8
5.3.1 Software Requirements for Present Project 8
6. LANGUAGE SPECIFICATION-JAVA 9
6.1 Introduction 9
6.2 Java Architecture 9

4
 6.3 The Java Programming Environment 10
6.4 The Java Virtual Machine 10
6.5 Features of Java 11
7. SYSTEM DESIGN 13
7.1 Use Case Diagram 13
7.2 Sequence Diagram 14
7.3 Collaboration Diagram 14
7.4 Activity Diagram 15
7.5 State Chart Diagram 16
7.6 Class Diagram 17
8. SYSTEM IMPLEMENTATION 19
8.1 Introduction 19
8.1.1 Authentication 19
8.1.2 Parameters Acceptance 19
8.1.3 The Algorithm 19
8.1.4 The Result 19
9. TESTING 39
9.1 Introduction 39
9.2 Testing methods 39
9.2.1 White box testing 39
9.2.1.1 Types of white box testing 39
9.2.1.2 Test coverage 40
9.2.2 Black box testing 40
9.2.3 Grey box testing 40
9.3 Testing levels 41
9.3.1 Unit testing 41
9.3.2 Integration testing 41
9.3.3 System testing 41
9.3.4 System integration testing 41

5
 9.3.5 Regression testing 41
9.3.6 Acceptance testing 42
9.3.7 Alpha testing 42
9.3.8 Beta testing 42
9.3.9 Non-functional testing 42
9.3.10 Software performance testing and load testing 42
9.3.11 Stability testing 43
9.3.12 Usability testing 43
9.3.13 Security testing 43
9.3.14 Internationalization and localization 43
9.3.15 Destructive testing 43
9.4 Test Cases 43
10. SCREENSHOTS 46
CONCLUSION 47
REFERENCE 48

ABSTRACT

The Internet traffic is increasing day by day. Also, secure data communication is
the need of the hour. But the standard compression techniques which are in use, are
independent and do not consider the security issues. Hence, we present a general
encoding technique for secure data communication over a language L with a finite

6
alphabet set . The encoded message is a bi-tuple of which, the first is a vector of
quotients denoted as Q and the second is a representation of remainders denoted as R
with respect to a modulus M. The secrecy of the message is retained by
communicating R over a secure channel using some standard encryption mechanism.
The computation overhead is also reduced as the encryption is done only on one half
of the encoded message. Further, this encoding mechanism provides a lossless
compression.

LIST OF TABLES

TABLE NO. NAME PAGE NO.

3.1 Quotient and remainder for different values of 5

10.1 Test cases 44

7
 LIST OF FIGURES

FIGURE NO. NAME PAGE NO.

6.1 Compile-time and Run-time Environment 10

6.2 Java Virtual Machine 11

8
9
 Chapter 1
INTRODUCTION
The rapid growth of Internet in the recent days and the wide spread availability of
networks have led to the development of powerful and creative applications. Almost
all the software applications are becoming online, not to mention the Google Docs and
Microsoft Office Live. So, the networks have become more open and accessible. The
volume of data transmitted over the Internet is also increasing. Presently, we have
eBooks, multimedia, e-business, open source applications, etc. online.
Therefore, the information on the Internet is becoming more sensitive and
vulnerable. Many applications demand confidential data communication between the
sender and the receiver. Moreover, such overwhelming internet traffic demands the
efficient use of bandwidth available. So, we require secure communication with low
bandwidth usage. In this regard, the role played by Data Compression becomes
significant.
Furthermore, textual data, where every single character matters, cannot be
afforded to be compressed with Lossy Compression techniques. Hence, Lossless Data
Compression Algorithms are applied to ensure the reconstruction of the original data
from the compressed data. The conventional encryption (symmetric or asymmetric)
does not provide data compression, i.e. the ciphers are of same or bigger size as the
plaintexts. The symmetric encryptions like Triple DES, AES, and RC5 are relatively
less computational intensive than asymmetric encryptions like RSA, ElGammal, and
ECC. In general, the plaintexts are first compressed and then encrypted.
So, the overhead of encryption is reduced to the order of the compressed data.
Hence, encryption followed by data compression can reduce the computational
overheads of encryption. Cryptography encompasses techniques that protect the
secrecy of messages transmitted over public communication lines. Encryption is done
at the sender side which uses some secret information (a key) and produces a cipher in
such a way that an eavesdropper cannot interpret. The legitimate receiver does the
Decryption with the corresponding key to get back the message.
The original message M = m0,m1, . . . mn is a string over a language L with finite
alphabet set. Let mk M, a letter of the string, corresponds to the i th letter of . The
message M is encoded as a bi-tuple < R, Q>. R represents a vector of remainders with
respect to a modulus , < | |. That is, the k th element of R is i%. Q represents the
corresponding quotients in a Base B number, where B is the measure of base to
represent the individual quotients.
All the quotients in Q are within the range [0, B 1]. The encoded message M can
be securely communicated when the bi-tuple < R, Q> is transmitted. While R may be
transmitted through open channel, Q should be transmitted through a secure channel.
The rest of the paper is organized as follows.
The present project aims at developing and implementing a new Mod Encoder
algorithm that can expel the existing algorithm out spells.

Chapter 2
EXISTING ALGORITHMIC ANALYSIS
10
 Compression and Encoding algorithms are of major interest of the research since
long. The following algorithms are a few of them are briefed below:

2.1 Triple DES

Triple DES (3DES) is the common name for the Triple Data Encryption Algorithm
(TDEA) block cipher, which applies the Data Encryption Standard (DES) cipher
algorithm three times to each data block. Because of the availability of increasing
computational power, the key size of the original DES cipher was becoming subject to
brute force attacks; Triple DES was designed to provide a relatively simple method of
increasing the key size of DES to protect against such attacks, without designing a
completely new block cipher algorithm. This suffers from time complexity and long
ciphers to be transmitted.
2.2 AES
The Advanced Encryption Standard (AES) is a symmetric-key encryption standard
adopted by the U.S. government. The standard comprises three block ciphers, AES-
128, AES-192 and AES-256, adopted from a larger collection originally published as
Rijndael. Each of these ciphers has a 128-bit block size, with key sizes of 128, 192
and 256 bits, respectively. This also suffers from time complexity and long ciphers to
be transmitted.
2.3 RC4
RC4 (also known as ARC4 or ARCFOUR meaning Alleged RC4) is the most
widely-used software stream cipher and is used in popular protocols such as Secure
Sockets Layer (SSL) (to protect Internet traffic) and WEP (to secure wireless
networks). This is less computationally intensive compared to asynchronous
algorithms. Thus, an attempt to construct a simple, faster, and less heavy cipher
encoder algorithm is being made in this project.

Chapter 3
THE PROPOSED MOD ENCODER ALGORITHM
The proposed MOD-ENCODER algorithm uses any standard encryption technique
which incorporates lossless compression in order to cater to the needs of low
bandwidth and data security. As mentioned above, let L be a defined language over the
alphabet set. For example, L be English and be {A, B . . . Z, a, b . . . z}. Let the letters
of be indexed by a bi-jection function I that maps a letter to an integer i, where 1 i
||. is a constant, called modulus constant. Let the data string M be {m1, m2, m3. . .
mn} . Performing modulus operation on every I (mi) by , sequentially yields
remainder set R as {r1, r2, r3. . . rn} and quotient set Q as {q1, q2, q3, . . . , qn}. The
elements in R have the values between [0, 1]. So, we consider the elements in R to

11
be a vector of numbers in base R. Each ri takes log2 R bits for binary representation. If
the message is of n characters, the number of bits required to represent the vector R is
n log2 R. The quotient set is represented in a different way. Let B = [] + 1 be
another parameter called Base-valuer. The elements of Q will have values within [0,
B1]. Consider Q as a number in base B, i.e. (q1, q2. . . qn) B. Convert the number to a
higher base. It is obvious that a higher base representation would reduce the digits in
the number. If B is less than 10, then we convert Qb to a Q10 number.

3.1. The MOD-ENCODER Encoding Algorithm

1) Input: M
2) n = |M| , i.e. length of M
3) Z = n bit size i.e. bit size is the number of bits require to represent each char.
4) for i = 1 to n
4.1) Read mi the ith character from M.
4.2) Find R: R[i] = I (mi) %
4.3) Find Q: Q[i] = I (mi)/
5) Representation of R: for i = 1 to n
5.1) Represent R[i] in Base .
6) Representation of Q: Interpret Q as Base B number and convert it to Base 10.
The vector R is communicated through open channel, whereas Q is encrypted to a
cipher Qc using any standard cryptographic technique and communicated to the
receiver to ensure the confidentiality of the message M. By doing so, the overhead of
encryption is reduced as we encrypt only tuple Q, rather than the whole message M.
The receiver on receiving R and Qc, decrypts Qc to Q and decodes the message from
the bituple < R, Q>.

3.2. The MOD-ENCODER Decoding Algorithm

1) Input: Bi-tuple < R, Q>

2) Convert Q from Base 10 to Base B: Let Qb = (q1, q2,. . . qn) be the
representation in Base B
3) Interpret R as a vector of Base number
4) for 1 i n
4.1) i = qi+ri
where qi the ith digit of Qb ri the ith element of R.
4.2) mi = I-1 (i)
5) M=(m1 , m2 , . . . mn)

3.3. Compression mechanism

As mentioned above, the encrypted message M is a bituple < Q, R>of quotient and
remainder. So, the size of the encrypted message can be obtained by calculating the
number of bits required to represent Q and R. Let X be the total number of bits
required to represent R and is given by X = n log2 , where n is the length of the
message and log2 is the number of bits required to represent each remainder. The

12
quotient Q is looked upon as a Base B number. Each qi needs log2 B bits for its
representation. As we know, a number in Base 10 requires lesser number of bits than
its equivalent in another Base B for representation, considering B <10. Therefore, to
lessen the number of bits required to represent Q, we first convert it into a Base 10
number, say T. So, the number of bits required to represent Q is given as Y = log2 T.
Hence, the total number of bits needed for representation of the encrypted message M
can be given by X +Y. Considering, a 7-bit representation for every character as in
ASCII (or 8-bit in Unicode), Z = n 7 is the total number of bits required for plain text
message. We can observe that Z >(X+Y). So this reduction in bits provides us with the
desired compression and the Compression Ratio C.R. is given by C.R. = Z./(X+Y).

3.4. Examples and discussion

Let us consider L to be the alphabet English with 26 characters. Let us take a
sample message string M as I love my country. The following illustrates the
functioning of the above proposed algorithm. Length of M, i.e. n = 14. Number of bits
required for original message = 98 bits.

Table. 3.1 Quotient and remainder for different values of

Case 1:
Take = 4. Above table shows the corresponding quotients and remainders.
X=Total number of bits needed for R = 28. Now, we convert the Base 7 Quotient to a
Base 10 number T. Base B = (26/4) +1 = 7 T = 491220602 Y = Total number of bits
required for Q = 29 Total number of bits required to represent the encrypted message
= X + Y = 57 Compression Ratio CR = 1.719
Case 2:
Take = 5. The value of is now varied and above table gives the corresponding
quotients and remainders. X = Total number of bits needed for R = 42. Now, we
convert the Base 6 Quotient to a Base 10 number T. Base B = (26/5) +1 = 6 T =
5789913061 Y = Total number of bits required for Q = 33 Total number of bits
required to represent the encrypted message = X + Y = 75 Compression Ratio CR =
1.307 This shown that, for any fixed , if the input message size increases the

13
compression ratio remains almost constant. This implies that the compression ratio is
independent to the size of the message. The comparative results of the degree of
compression with different Base-values . Here the Q tuple is converted to the Base
10 number for all the cases. That is, for any quotient Q = (q1, q2. . . qn) B the number
is converted to a Base 10 number. It can be realized that, as B is much smaller than 10,
the degree of compression is better. Whereas, when B is close to 10 the degree of
compression reduces. For values of B greater than 10 there is no compression as the
size of encoded message becomes bigger than M.

Chapter 4
SOFTWARE REQUIREMENTS SPECIFICATION
4.1 Introduction
A Software Requirements Specification (SRS) is a complete description of the
behavior of the system to be developed. It includes a set of use cases that describe all
the interactions the users will have with the software. Use cases are also known as
functional requirements. In addition to use cases, the SRS also contains non-functional
(or supplementary) requirements. Non-functional requirements are requirements
which impose constraints on the design.
4.2 Functional Requirements
In software engineering, a functional requirement defines a function of a software
system or its component. A function is described as a set of inputs, the behavior, and
outputs. Functional requirements may be calculations, technical details, data
manipulation and processing and other specific functionality that define what a system
is supposed to accomplish. Behavioral requirements describing all the cases where the
system uses the functional requirements are captured in use cases. Functional
requirements are supported by non-functional requirements (also known as quality
requirements), which impose constraints on the design or implementation (such as
performance requirements, security, or reliability). How a system implements
functional requirements is detailed in the system design.
4.2.1 Functional Requirements for Present Project

1. Encoding Input: A Plain Text, Delta Value.

14
 2. Decoding Input: Bituple cipher <R, Q> and Delta Value.

3. Encoding Output: Bituple cipher <R, Q>

4. Decoding Output: The Plain Text.

5. Process: Implement the Mod Encoder Algorithm.

6. Process: Display Base value

7. Process: Display Quotient and Reminder table.

8. Process: Display the Qb and Q10 as well.

4.3 Non Functional Requirements:

In systems engineering and requirements engineering, a non-functional

requirement is a requirement that specifies criteria that can be used to judge the
operation of a system, rather than specific behaviors. This should be contrasted with
functional requirements that define specific behavior or functions. In general,
functional requirements define what a system is supposed to do whereas non-
functional requirements define how a system is supposed to be. Non-functional
requirements are often called qualities of a system. Other terms for non-functional
requirements are "constraints", "quality attributes", "quality goals" and "quality of
service requirements", and "non-behavioral requirements. Qualities, that is, non-
functional requirements, can be divided into two main categories:

1. Execution qualities, such as security and usability, which are observable at run
time.
2. Evolution qualities, such as testability, maintainability, extensibility and
scalability, which are embodied in the static structure of the software system.

15
 Chapter 5
SYSTEM REQUIREMENTS
5.1 Introduction
To be used efficiently, all computer software needs certain hardware components
or other software resources to be present on a computer. These pre-requisites are
known as (computer) system requirements and are often used as a guideline as
opposed to an absolute rule. Most software defines two sets of system requirements:
minimum and recommended.
5.2 Hardware Requirements
The most common set of requirements defined by any operating system or
software application is the physical computer resources, also known as hardware, a
hardware requirements list is often accompanied by a hardware compatibility list
(HCL), especially in case of operating systems. An HCL lists tested, compatible, and
sometimes incompatible hardware devices for a particular operating system or
application. The following sub-sections discuss the various aspects of hardware
requirements.
5.2.1 Hardware Requirements for Present Project

1. VDU: Monitor/ LCD TFT / Projector

2. Input Devices: Keyboard and Mouse
3. RAM: 512 MB
4. Processor: P4 or above
5. Storage: Less than 100 MB of HDD space.
5.3 Software Requirements
Software Requirements deal with defining software resource requirements and
pre-requisites that need to be installed on a computer to provide optimal functioning
of an application. These requirements or pre-requisites are generally not included in
the software installation package and need to be installed separately before the
software is installed.
5.3.1 Software Requirements for Present Project
16
 1. Operating System: win 07,2000.
2. Run-Time: OS Compatible JVM.

Chapter 6
LANGUAGE SPECIFICATION JAVA
6.1 Introduction
At first glance, it may appear that Java was developed specifically for the World
Wide Web. However, interestingly enough, Java was developed independently of the
web, and went through several stages of metamorphosis before reaching its current
status of de facto programming language for the World Wide Web.
According the Java FAQ, Bill Joy, currently a vice president at Sun Microsystems,
is widely believed to have been the person to conceive of the idea of a programming
language that later became Java. In late 1970's, Joy wanted to design a language that
combined the best features of MESA and C. In an attempt to re-write the UNIX
operating system in 1980's, Joy decided that C++ was inadequate for the job.
In January of 1991, Bill Joy, James Gosling, Mike Sheradin, Patrick Naughton
(formerly the project leader of Sun's Open Windows user environment), and several
other individuals met in Aspen, Colorado for the first time to discuss the ideas for the
Stealth Project. The goal of the Stealth Project was to do research in the area of
application of computers in the consumer electronics market. According to Gosling,
"the goal was ... to build a system that would let us do a large, distributed,
heterogeneous network of consumer electronic devices all talking to each other." With
this goal in mind, the stealth group began work.
There were several criteria that Oak had to meet in order to satisfy the project
objective given the consumer electronics target market. Given the wide array of
manufacturers in the market, Oak would have to be completely platform independent,
and function seamlessly regardless of the type of CPU in the device.
For the above reason, Oak was designed to be an interpreted language, since it
would be practically impossible for a complied version to run on all available
platforms. To facilitate the job of the interpreter, Oak was to be converted to an
intermediate "byte-code" format. Additionally, reliability was of great concern. A
consumer electronics device that would have to be "rebooted" periodically was not
acceptable. Another important design objective for Oak would then have to be high
reliability by allowing the least amount of programmer-introduced errors. This was the
motivation for several important modification to C++. The concepts of multiple-
inheritance and operator overloading were identified as sources of potential errors, and
eliminated in Oak.
6.2 Java Architecture
Java's architecture arises out of four distinct but interrelated technologies:
The Java programming language
The Java class file format
The Java Application Programming Interface
The Java virtual machine
When you write and run a Java program, you are tapping the power of these four
technologies. You express the program in source files written in the Java programming
17
language, compile the source to Java class files, and run the class files on a Java
virtual machine. When you write your program, you access system resources (such as
I/O, for example) by calling methods in the classes that implement the Java
Application Programming Interface, or Java API. As your program runs, it fulfills
your program's Java API calls by invoking methods in class files that implement the
Java API. You can see the relationship between these four parts in
Fig. 6.1

Fig. 6.1 Compile-time and Run-time Environment

6.3 The Java Programming Environment

Together, the Java virtual machine and Java API form a "platform" for which all
Java programs are compiled. In addition to being called the Java runtime system, the
combination of the Java virtual machine and Java API is called the Java Platform.
Java programs can run on many different kinds of computers because the Java
Platform can itself be implemented in software. A Java program can run anywhere the
Java Platform is present.

6.4 The Java Virtual Machine

At the heart of Java's network-orientation is the Java virtual machine, which
supports all three prongs of Java's network-oriented architecture: platform
independence, security, and network-mobility.
The Java virtual machine is an abstract computer. Its specification defines certain
features every Java virtual machine must have, but leaves many choices to the
designers of each implementation. For example, although all Java virtual machines
must be able to execute Java bytecodes, they may use any technique to execute them.
Also, the specification is flexible enough to allow a Java virtual machine to be
implemented either completely in software or to varying degrees in hardware. The
flexible nature of the Java virtual machine's specification enables it to be implemented
on a wide variety of computers and devices. A Java virtual machine's main job is to
load class files and execute the bytecodes they contain.

18
 Fig. 6.2 Java Virtual Machine
6.5. Features of Java
Platform Independence
o The Write-Once-Run-Anywhere ideal has not been achieved (tuning for
different platforms usually required), but closer than with other
languages.
Object Oriented
o Object oriented throughout - no coding outside of class definitions,
including main ().
o An extensive class library available in the core language packages.
Compiler/Interpreter Combo
o Code is compiled to byte codes that are interpreted by a Java virtual
machines (JVM).
o This provides portability to any machine for which a virtual machine
has been written.
o The two steps of compilation and interpretation allow for extensive
code checking and improved security.
Robust
o Exception handling built-in, strong type checking (that is, all data must
be declared an explicit type), local variables must be initialized.
Several dangerous features of C & C++ eliminated:
o No memory pointers.

19
 o No preprocessor
o Array index limit checking
Automatic Memory Management
o Automatic garbage collection - memory management handled by JVM.
Security
o No memory pointers
o Programs runs inside the virtual machine sandbox.
o Array index limit checking
o Code pathologies reduced by
byte code verifier - checks classes after loading
Class loader - confines objects to unique namespaces. Prevents
loading a hacked "java.lang.SecurityManager" class, for
example.
Security manager - determines what resources a class can
access such as reading and writing to the local disk.
Dynamic Binding
o Where linked code is changed and memory pointers then point to the
wrong addresses the linking of data and methods to where they are
located, is done at run-time.
o New classes can be loaded while a program is running. Linking is
done on the fly.
o Even if libraries are recompiled, there is no need to recompile code that
uses classes in those libraries. This differs from C++, which uses static
binding. This can result in fragile classes for cases.
Good Performance
o Interpretation of bytecodes slowed performance in early versions, but
advanced virtual machines with adaptive and just-in-time compilation
and other techniques now typically provide performance up to 50% to
100% the speed of C++ programs.
Threading
o Lightweight processes, called threads, can easily be spun off to perform
multiprocessing.
o Can take advantage of multiprocessors where available.
o Great for multimedia displays.
Built-in Networking
o Java was designed with networking in mind and comes with many
classes to develop sophisticated Internet communications.

20
 Chapter 7
SYSTEM DESIGN
Systems design is the process or art of defining the architecture, components,
modules, interfaces, and data for a system to satisfy specified requirements. One could
see it as the application of systems theory to product development. There is some
overlap with the disciplines of systems analysis, systems architecture and systems
engineering .If the broader topic of product development "blends the perspective of
marketing, design, and manufacturing into a single approach to product development,
then design is the act of taking the marketing information and creating the design of
the product to be manufactured. Systems design is therefore the process of defining
and developing a systems to satisfy specified requirements of the user.
7.1 Use Case Diagram
A use case diagram in the Unified Modeling Language (UML) is a type of
behavioral diagram defined by and 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 cases), and any dependencies between those use
cases.

7.2 Sequence Diagram

A sequence diagram in Unified Modelling Language (UML) is a kind of
interaction diagram that shows how processes operate with one another and in what
order. It is a construct of a Message Sequence Chart. Sequence diagrams are
sometimes called event diagrams, event scenarios, and timing diagrams. A sequence
diagram shows, as parallel vertical lines (lifelines), different processes or objects that

21
live simultaneously, and, as horizontal arrows, the messages exchanged between them,
in the order in which they occur. This allows the specification of simple runtime
scenarios in a graphical manner.

7.3 Collaboration Diagram

A Collaboration diagram is very similar to a Sequence diagram in the purpose it
achieves; in other words, it shows the dynamic interaction of the objects in a system.
A distinguishing feature of a Collaboration diagram is that it shows the objects and
their association with other objects in the system apart from how they interact with
each other. The association between objects is not represented in a Sequence diagram.
A Collaboration diagram is easily represented by modeling objects in a system and
representing the associations between the objects as links. The interaction between the
objects is denoted by arrows.

22
7.4 Activity Diagram
Activity diagrams are graphical representations of workflows of stepwise activities
and actions with support for choice, iteration and concurrency.In the Unified
Modeling Language, activity diagrams can be used to describe the business and
operational step-by-step workflows of components in a system. An activity diagram
shows the overall flow of control. Activity diagrams are constructed from a limited
repertoire of shapes, connected with arrows. The most important shape types:
rounded rectangles represent activities;

diamonds represent decisions;

bars represent the start (split) or end (join) of concurrent activities;

a black circle represents the start (initial state) of the workflow;

an encircled black circle represent the end (final state). Array run from the
start towards the end and represent the order in which activities happen

23
7.5 State Chart Diagram
A state diagram is a type of diagram used in computer science and related fields to
describe the behavior of systems. State diagrams require that the system described is
composed of a finite number of states; sometimes, this is indeed the case, while at
other times this is a reasonable abstraction. There are many forms of state diagrams,
which differ slightly and have different semantics. State diagrams are used to give an
abstract description of the behavior of a system. This behavior is analyzed and
represented in series of events, that could occur in one or more possible states. Hereby
"each diagram usually represents objects of a single class and track the different states
of its objects through the system. State diagrams can be used to graphically represent
finite state machines. This was introduced by Taylor Booth in his 1967 book
"Sequential Machines and Automata Theory".

24
7.6 Class Diagram
In software engineering, a class
diagram in the Unified Modeling Language
(UML) is a type of static structure diagram that
describes the structure of a system by showing the
system's classes, their attributes, and the
relationships between the classes. The class
diagram is the main building block in object
oriented modelling. They are being used both for
general conceptual modelling of the
systematics of the application, and for
detailed modelling translating the models into programming code. The classes in a
class diagram represent both the main objects and or interactions in the application
and the objects to be programmed. In the class diagram these classes are represented
with boxes which contain three parts:
A class with three sections:
The middle part contains the attributes of the class
The upper part holds the name of the class
The bottom part gives the methods or operations the class can take or
undertake

25
 Chapter 8
SYSTEM IMPLEMENTATION
8.1 Introduction

26
 The Proposed system is implemented to the best of no deviation implemented part
has the below modules.
1. Authentication
2. Parameters Acceptances
3. The Algorithm
4. Results
8.1.1 Authentication
The log in screen is displayed as soon as the project execution starts. The login
screen is expected to provide a valid user name and password on failing which the rest
of the application is not allowed to be accessed.
8.1.2 Parameters Acceptance
The parameters to be accepted are the Delta value. The log in screen on reviving the
valid user name and password displays the parameters screen where a valid delta
value can be entered and base value is calculated. Then the QRTable screen is shown
where the Quotient and Reminder table is shown.
8.1.3 The Algorithm
This is the model where the Mod Encoder Algorithm is coded. The preparation of the
QRTable and the encoding and decoding mechanism lie here. The class ModEncoder
constitutes this module.
8.1.4 The Result
On entering the accepting the delta once the base is calculated and the QRTable is
populated, the encryption and decryption screen appears. Where the encryption screen
offers to enter the plain text and once the R and Q are generated they may be saved in
different files. The Decryption screen is where the Q and R files are browed and
loaded and the decoding happens displaying the plain text.

Code:
LogIn.java
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import javax.swing.*;
class LogIn extends JDialog implements ActionListener
{
public LogIn()
{
lUid = new JLabel("User Name: ");
lPwd = new JLabel("Password : ");
tUid = new JTextField();
tPwd = new JPasswordField();
bNext = new JButton("Next");
bClose = new JButton("Quit");
setLayout(null);
add(lUid, 10, 10, 100, 20);
add(tUid, 135, 10, 100, 20);
add(lPwd, 10, 35, 100, 20);
add(tPwd, 135, 35, 100, 20);
add(bNext, 130, 65, 75, 20);
add(bClose, 215, 65, 75, 20);

27
 bClose.addActionListener(this);
bNext.addActionListener(this);
setTitle("Log In");
setVisible(true);
setBounds(30, 30, 330, 130);
setDefaultCloseOperation(2);
}
public void add(JComponent jcomponent, int i, int j, int k, int l)
{
jcomponent.setBounds(i, j, k, l);
add(((java.awt.Component) (jcomponent)));
}
public void actionPerformed(ActionEvent actionevent)
{
if(actionevent.getSource() == bClose)
dispose();
else
if(tUid.getText().equals("Admin") && tPwd.getText().equals("Admin"))
{
new ParameterScreen();
dispose();
}
else
{
JOptionPane.showMessageDialog(this, "Invalid LogIn Details", "Access
Denied", 0);
}
}
JLabel lUid;
JLabel lPwd;
JTextField tUid;
JPasswordField tPwd;
JButton bNext;
JButton bClose;
}
Main.java:
class Main
{
Main()
{
public static transient void main(String args[])
{
new LogIn();
}
}
}
ModEncoder.java:
import java.util.StringTokenizer;
class ModEncoder
{

28
 ModEncoder()
{
}
public static int getBase()
{
return 256 / delta + 1;
}
public static QRTableModel getQRTableModel()
{
QRTableModel qrtablemodel = new QRTableModel();
for(int i = 0; i < 256; i++)
{
qrtablemodel.setValueAt(Integer.valueOf(i / delta), i, 2);
qrtablemodel.setValueAt(Integer.valueOf(i % delta), i, 3);
}
return qrtablemodel;
}
public static String encode(String s)
{
String s1 = "";
String s2 = "";
String s3 = "";
char ac[] = s.toCharArray();
int i = ac.length;
for(int j = 0; j < i; j++)
{
char c = ac[j];
s1 = (new StringBuilder()).append(s1).append(c %
delta).append(",").toString();
s3 = (new StringBuilder()).append(s3).append(c / delta).toString();
}
s2 = String.valueOf(Long.valueOf(s3, getBase()));
return(newStringBuilder()).append(s1).append("#").append(s3).append
("#").append(s2).toString();
}
public static String decode(String s, String s1)
{
String s2 = "";
StringTokenizer stringtokenizer = new StringTokenizer(s, ",");
char ac[] = s1.toCharArray();
int i = ac.length;
for(int j = 0; j < i; j++)
{
char c = ac[j];
s2 = (new StringBuilder()).append(s2).append((char)(Integer.parseInt((new
StringBuilder()).append(c).append("").toString()) * delta +
Integer.parseInt(stringtokenizer.nextToken()))).toString();
}
return s2;
}

29
 public static int delta;
}
Coder.java:
import java.awt.FlowLayout;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import javax.swing.*;
class Coder extends JDialog implements ActionListener
{
public Coder()
{
p = new JPanel(new FlowLayout(2));
tabp = new JTabbedPane();
bClose = new JButton("Quit");
p.add(bClose);
add(tabp);
add(p, "South");
tabp.addTab("Encode", new EncodePanel());
tabp.addTab("Decode", new DecodePanel());
bClose.addActionListener(this);
setTitle("Mod Encoder Screen");
setVisible(true);
setBounds(30, 30, 430, 430);
setDefaultCloseOperation(2);
}
public void actionPerformed(ActionEvent actionevent)
{
if(actionevent.getSource() == bClose)
dispose();
}
JPanel p;
JTabbedPane tabp;
JButton bClose;
}
DecoderPanel.java:
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.io.*;
import javax.swing.*;
class DecodePanel extends JPane implements ActionListener
{
public DecodePanel()
{
l1 = new JLabel("Choose Plain Text: ");
l2 = new JLabel("Reminder Vector: ");
l3 = new JLabel("Quotient Vector (Qb): ");
l4 = new JLabel("Quotient Vector (Q10): ");
t1 = new JTextField();
t2 = new JTextField();
t3 = new JTextField();

30
 t4 = new JTextField();
bDecode = new JButton("Decode");
bOpenR = new JButton("Open");
bOpenQ = new JButton("Open");
setLayout(null);
add(l2, 10, 10, 200, 20);
add(t2, 10, 35, 250, 20);
add(bOpenR, 265, 35, 80, 20);
add(l4, 10, 60, 200, 20);
add(t4, 10, 85, 250, 20);
add(bOpenQ, 265, 85, 80, 20);
add(l3, 10, 120, 200, 20);
add(t3, 10, 145, 250, 20);
add(l1, 10, 170, 200, 20);
add(t1, 10, 195, 250, 20);
add(bDecode, 265, 195, 80, 20);
t1.setEditable(false);
t2.setEditable(false);
t3.setEditable(false);
t4.setEditable(false);
bDecode.addActionListener(this);
bOpenR.addActionListener(this);
bOpenQ.addActionListener(this);
}
public void add(JComponent jcomponent, int i, int j, int k, int l)
{
jcomponent.setBounds(i, j, k, l);
add(((java.awt.Component) (jcomponent)));
}
public void actionPerformed(ActionEvent actionevent)
{
try{
if(actionevent.getSource() == bDecode)
{
String s = ModEncoder.decode(t2.getText().trim(), t3.getText().trim());
t1.setText(s);
} else
if(actionevent.getSource() == bOpenR)
{
JFileChooser jfilechooser = new JFileChooser();
int i = jfilechooser.showOpenDialog(this);
if(i == 0)
{
java.io.File file = jfilechooser.getSelectedFile();
BufferedReader bufferedreader = new BufferedReader(new
InputStreamReader(new FileInputStream(file)));
t2.setText(bufferedreader.readLine());
}
} else
{

31
 JFileChooser jfilechooser1 = new JFileChooser();
int j = jfilechooser1.showSaveDialog(this);
if(j == 0){
java.io.File file1 = jfilechooser1.getSelectedFile();
BufferedReader bufferedreader1 = new BufferedReader(new
InputStreamReader(new FileInputStream(file1)));
t4.setText(bufferedreader1.readLine());
t3.setText(Long.toString(Long.parseLong(t4.getText()),
ModEncoder.getBase()));
}
}
}
catch(Exception exception)
{
System.out.print(exception);
}
}
JLabel l1;
JLabel l2;
JLabel l3;
JLabel l4;
JTextField t1;
JTextField t2;
JTextField t3;
JTextField t4;
JButton bDecode;
JButton bOpenR;
JButton bOpenQ;
}
EncoderPanel.java:
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.io.*;
import java.util.StringTokenizer;
import javax.swing.*;
class EncodePanel extends JPanel implements ActionListener
{
public EncodePanel()
{
l1 = new JLabel("Choose Plain Text: ");
l2 = new JLabel("Reminder Vector: ");
l3 = new JLabel("Quotient Vector (Qb): ");
l4 = new JLabel("Quotient Vector (Q10): ");
t1 = new JTextField();
t2 = new JTextField();
t3 = new JTextField();
t4 = new JTextField();
bEncode = new JButton("Encode");
bSaveR = new JButton("Save");
bSaveQ = new JButton("Save");

32
 setLayout(null);
add(l1, 10, 10, 200, 20);
add(t1, 10, 35, 250, 20);
add(bEncode, 265, 35, 80, 20);
add(l3, 10, 60, 200, 20);
add(t3, 10, 85, 250, 20);
add(l4, 10, 120, 200, 20);
add(t4, 10, 145, 250, 20);
add(bSaveQ, 265, 145, 80, 20);
add(l2, 10, 170, 200, 20);
add(t2, 10, 195, 250, 20);
add(bSaveR, 265, 195, 80, 20);
t2.setEditable(false);
t3.setEditable(false);
t4.setEditable(false);
bEncode.addActionListener(this);
bSaveR.addActionListener(this);
bSaveQ.addActionListener(this);
}
public void add(JComponent jcomponent, int i, int j, int k, int l)
{
jcomponent.setBounds(i, j, k, l);
add(((java.awt.Component) (jcomponent)));
}
public void actionPerformed(ActionEvent actionevent)
{
try
{
if(actionevent.getSource() == bEncode)
{
String s = ModEncoder.encode(t1.getText().trim());
StringTokenizer stringtokenizer = new StringTokenizer(s,"#");
t2.setText(stringtokenizer.nextToken());
t3.setText(stringtokenizer.nextToken());
t4.setText(stringtokenizer.nextToken());
} else
if(actionevent.getSource() == bSaveR)
{
JFileChooser jfilechooser = new JFileChooser();
int i = jfilechooser.showSaveDialog(this);
if(i == 0)
{
java.io.File file = jfilechooser.getSelectedFile();
PrintWriter printwriter = new PrintWriter(new FileOutputStream(file),
true);
printwriter.println(t2.getText());
System.out.print((new StringBuilder()).append(t2.getText()).append("
saved as R").toString());
}
} else

33
 {
JFileChooser jfilechooser1 = new JFileChooser();
int j = jfilechooser1.showSaveDialog(this);
if(j == 0)
{
java.io.File file1 = jfilechooser1.getSelectedFile();
PrintWriter printwriter1 = new PrintWriter(new FileOutputStream(file1),
true);
printwriter1.println(t4.getText());
System.out.print((new StringBuilder()).append(t4.getText()).append("
saved as Q").toString());
}
}
}
catch(Exception exception)
{
System.out.print(exception);
}
}
JLabel l1;
JLabel l2;
JLabel l3;
JLabel l4;
JTextField t1;
JTextField t2;
JTextField t3;
JTextField t4;
JButton bEncode;
JButton bSaveR;
JButton bSaveQ;
}
ParameterScreen.java:
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import javax.swing.*;
import javax.swing.event.CaretEvent;
import javax.swing.event.CaretListener;
class ParameterScreen extends JDialog implements ActionListener, CaretListener
{
public ParameterScreen()
{
lDelta = new JLabel("Delta (1 to 256): ");
lBase = new JLabel("Base (<10): ");
tDelta = new JTextField();
tBase = new JTextField("0");
bNext = new JButton("Next");
bClose = new JButton("Quit");
setLayout(null);
add(lDelta, 10, 10, 100, 20);
add(tDelta, 135, 10, 100, 20);

34
 add(lBase, 10, 35, 100, 20);
add(tBase, 135, 35, 100, 20);
add(bNext, 130, 65, 75, 20);
add(bClose, 215, 65, 75, 20);
bClose.addActionListener(this);
bNext.addActionListener(this);
tDelta.addCaretListener(this);
setTitle("Delt Value Screen");
setVisible(true);
setBounds(30, 30, 330, 130);
setDefaultCloseOperation(2);
}
public void add(JComponent jcomponent, int i, int j, int k, int l)
{
jcomponent.setBounds(i, j, k, l);
add(((java.awt.Component) (jcomponent)));
}
public void caretUpdate(CaretEvent caretevent)
{
if(tDelta.getText().length() == 0)
{
tBase.setText("0");
} else
{
ModEncoder.delta = Integer.parseInt(tDelta.getText());
if(ModEncoder.delta <= 0 || ModEncoder.delta >= 256)
JOptionPane.showMessageDialog(this, "Delta value out of range (1 to 256)",
"Invalid Delta", 0);
else
tBase.setText(String.valueOf(ModEncoder.getBase()));
}
}
public void actionPerformed(ActionEvent actionevent)
{
if(actionevent.getSource() == bClose)
{
dispose();
} else
{
ModEncoder.delta = Integer.parseInt(tDelta.getText());
if(ModEncoder.delta <= 0 || ModEncoder.delta >= 256)
JOptionPane.showMessageDialog(this, "Delta value out of range (1 to
256)", "Invalid Delta", 0);
else
if(ModEncoder.getBase() > 10)
{
JOptionPane.showMessageDialog(this, "Choose Delta so that Base<10",
"Invalid Delta For Base", 0);
} else
{

35
 new QRTable();
dispose();
}
}
}

JLabel lDelta;
JLabel lBase;
JTextField tDelta;
JTextField tBase;
JButton bNext;
JButton bClose;
}
QRTable.java:
import java.awt.FlowLayout;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import javax.swing.*;
class QRTable extends JDialog implements ActionListener
{
public QRTable()
{
lDelta = new JLabel((new StringBuilder()).append("Choosen Delta:
").append(ModEncoder.delta).toString());
jt = new JTable(ModEncoder.getQRTableModel());
p = new JPanel(new FlowLayout(2));
bNext = new JButton("Next");
bClose = new JButton("Quit");
add(lDelta, "North");
add(new JScrollPane(jt));
add(p, "South");
p.add(bNext);
p.add(bClose);
bClose.addActionListener(this);
bNext.addActionListener(this);
setTitle("Quotient and Reminder Table");
setVisible(true);
setBounds(30, 30, 430, 530);
setDefaultCloseOperation(2);
}
public void actionPerformed(ActionEvent actionevent)
{
if(actionevent.getSource() == bClose)
{
dispose();
} else
{
new Coder();
dispose();
}

36
 }

JLabel lDelta;
JTable jt;
JPanel p;
JButton bNext;
JButton bClose;
}
QRTableModel.java
import javax.swing.table.DefaultTableModel;
class QRTableModel extends DefaultTableModel
{
public QRTableModel()
{
addColumn("Alphabet (Sigma)");
addColumn("ASCII Map (I)");
addColumn("Quotient (Q)");
addColumn("Reminder (R)");
Object aobj[] = new Object[4];
for(int i = 0; i < 256; i++)
{
aobj[0] = Character.valueOf((char)i);
aobj[1] = Integer.valueOf(i);
addRow(aobj);
}
}
public boolean isCellEditable(int i, int j)
{
return false;
}
}
Test.java:
import java.io.PrintStream;
class test
{
test()
{
}
public static transient void main(String args[])
{
System.out.println(Integer.toString(10, 8));
System.out.println(Integer.valueOf(Integer.toString(10, 8), 8));
System.out.println(Integer.toOctalString(10));
}
}

37
 Chapter 9
TESTING
9.1 Introduction

Software testing is an investigation conducted to provide stakeholders with

information about the quality of the product or service under test. Software testing
also provides an objective, independent view of the software to allow the business to
appreciate and understand the risks at implementation of the software. Test techniques
include, but are not limited to, the process of executing a program or application with
the intent of finding software bugs. Software testing can also be stated as the process
of validating and verifying that a software program/application/product:
1. Meets the business and technical requirements that guided its design and
development;
2. Works as expected; and
3. Can be implemented with the same characteristics.
Software testing, depending on the testing method employed, can be implemented at
any time in the development process. In a more traditional model, most of the test
execution occurs after the requirements have been defined and the coding process has
been completed.
9.2 Testing methods
The box approach
Software testing methods are traditionally divided into white- and black-box testing.
These two approaches are used to describe the point of view that a test engineer takes
when designing test cases.
9.2.1 White box testing
White box testing is when the tester has access to the internal data structures and
algorithms including the code that implement these.
9.2.1.1 Types of white box testing
The following types of white box testing exist:
API testing (application programming interface) - testing of the application
using public and private APIs
Code coverage - creating tests to satisfy some criteria of code coverage (e.g.,
the test designer can create tests to cause all statements in the program to be
executed at least once)

38
 Fault injection methods - improving the coverage of a test by introducing
faults to test code paths
Mutation testing methods
Static testing - White box testing includes all static testing
9.2.1.2 Test coverage
White box testing methods can also be used to evaluate the completeness of a test
suite that was created with black box testing methods. This allows the software team
to examine parts of a system that are rarely tested and ensures that the most important
function points have been tested.
Two common forms of code coverage are:
Function coverage, which reports on functions executed

Statement coverage, which reports on the number of lines executed to

complete the test
9.2.2 Black box testing
Black box testing treats the software as a "black box"without any knowledge of
internal implementation. Black box testing methods include: equivalence partitioning,
boundary value analysis, all-pairs testing, fuzz testing, model-based testing,
traceability matrix, exploratory testing and specification-based testing.
Specification-based testing: Specification-based testing aims to test the functionality
of software according to the applicable requirements.Thus, the tester inputs data into,
and only sees the output from, the test object. This level of testing usually requires
thorough test cases to be provided to the tester, who then can simply verify that for a
given input, the output value (or behavior), either "is" or "is not" the same as the
expected value specified in the test case.
Advantages and disadvantages: The black box tester has no "bonds" with the code,
and a tester's perception is very simple: a code must have bugs. Using the principle,
"Ask and you shall receive," black box testers find bugs where programmers do not.
But, on the other hand, black box testing has been said to be "like a walk in a dark
labyrinth without a flashlight," because the tester doesn't know how the software being
tested was actually constructed. As a result, there are situations when
1) a tester writes many test cases to check something that could have been tested
by only one test case, and/or
2) some parts of the back-end are not tested at all. Therefore, black box testing
has the advantage of "an unaffiliated opinion," on the one hand, and the
disadvantage of "blind exploring," on the other.
9.2.3 Grey box testing
Grey box testing (American spelling: gray box testing) involves having knowledge of
internal data structures and algorithms for purposes of designing the test cases, but
testing at the user, or black-box level. Manipulating input data and formatting output
do not qualify as grey box, because the input and output are clearly outside of the
"black-box" that we are calling the system under test. This distinction is particularly
important when conducting integration testing between two modules of code written
by two different developers, where only the interfaces are exposed for test. However,
modifying a data repository does qualify as grey box, as the user would not normally
be able to change the data outside of the system under test. Grey box testing may also

39
include reverse engineering to determine, for instance, boundary values or error
messages.
9.3 Testing levels
Tests are frequently grouped by where they are added in the software development
process, or by the level of specificity of the test.
9.3.1 Unit testing
Unit testing refers to tests that verify the functionality of a specific section of code,
usually at the function level. In an object-oriented environment, this is usually at the
class level, and the minimal unit tests include the constructors and destructors These
type of tests are usually written by developers as they work on code (white-box style),
to ensure that the specific function is working as expected. One function might have
multiple tests, to catch corner cases or other branches in the code. Unit testing alone
cannot verify the functionality of a piece of software, but rather is used to assure that
the building blocks the software uses work independently of each other.
Unit testing is also called component testing.
9.3.2 Integration testing
Integration testing is any type of software testing that seeks to verify the interfaces
between components against a software design. Software components may be
integrated in an iterative way or all together ("big bang"). Normally the former is
considered a better practice since it allows interface issues to be localised more
quickly and fixed. Integration testing works to expose defects in the interfaces and
interaction between integrated components (modules). Progressively larger groups of
tested software components corresponding to elements of the architectural design are
integrated and tested until the software works as a system.[26]
9.3.3 System testing
System testing tests a completely integrated system to verify that it meets its
requirements.
9.3.4 System integration testing
System integration testing verifies that a system is integrated to any external or third
party systems defined in the system requirements.
9.3.5 Regression testing
Regression testing focuses on finding defects after a major code change has occurred.
Specifically, it seeks to uncover software regressions, or old bugs that have come
back. Such regressions occur whenever software functionality that was previously
working correctly stops working as intended. Typically, regressions occur as an
unintended consequence of program changes, when the newly developed part of the
software collides with the previously existing code.
9.3.6 Acceptance testing
Acceptance testing can mean one of two things:
1. A smoke test is used as an acceptance test prior to introducing a new build to
the main testing process, i.e. before integration or regression.
2. Acceptance testing performed by the customer, often in their lab environment
on their own hardware, is known as user acceptance testing (UAT). Acceptance
testing may be performed as part of the hand-off process between any two
phases of development.[citation needed]
9.3.7 Alpha testing
Alpha testing is simulated or actual operational testing by potential users/customers or
an independent test team at the developers' site. Alpha testing is often employed for
40
off-the-shelf software as a form of internal acceptance testing, before the software
goes to beta testing. van Veenendaal, Erik. "Standard glossary of terms used in
Software Testing".
9.3.8 Beta testing
Beta testing comes after alpha testing. Versions of the software, known as beta
versions, are released to a limited audience outside of the programming team. The
software is released to groups of people so that further testing can ensure the product
has few faults or bugs. Sometimes, beta versions are made available to the open public
to increase the feedback field to a maximal number of future users.[citation needed].
9.3.9 Non-functional testing
Special methods exist to test non-functional aspects of software. In contrast to
functional testing, which establishes the correct operation of the software (correct in
that it matches the expected behavior defined in the design requirements), non-
functional testing verifies that the software functions properly even when it receives
invalid or unexpected inputs. Software fault injection, in the form of fuzzing, is an
example of non-functional testing. Non-functional testing, especially for software, is
designed to establish whether the device under test can tolerate invalid or unexpected
inputs, thereby establishing the robustness of input validation routines as well as error-
handling routines.
9.3.10 Software performance testing and load testing:
Performance testing is executed to determine how fast a system or sub-system
performs under a particular workload. It can also serve to validate and verify other
quality attributes of the system, such as scalability, reliability and resource usage.
Load testing is primarily concerned with testing that can continue to operate under a
specific load, whether that be large quantities of data or a large number of users. This
is generally referred to as software scalability.
9.3.11 Stability testing
Stability testing checks to see if the software can continuously function well in or
above an acceptable period. This activity of non-functional software testing is often
referred to as load (or endurance) testing.
9.3.12 Usability testing
Usability testing is needed to check if the user interface is easy to use and understand.
9.3.13 Security testing
Security testing is essential for software that processes confidential data to prevent
system intrusion by hackers.
9.3.14 Internationalization and localization
Internationalization and localization is needed to test these aspects of software, for
which a pseudo localization method can be used. It will verify that the application still
works, even after it has been translated into a new language or adapted for a new
culture .
9.3.15 Destructive testing
Destructive testing attempts to cause the software or a sub-system to fail, in order to
test its robustness.
9.4 Test cases

Test No Test case Excepted output Actual output Result

41
1.
Invalid Log A dialog Box A dialog Box Passe
In Test: By to be is displayed d
providing displayed saying Invalid
invalid User saying Invalid Login, Access
name and Login, Access Denied
Password Denied
2.
Valid Log In The Text The Text Passe
Test: By Screen for Screen for d
providing accepting the accepting the
Valid User text to be text is shown
name and shown
Password
3.
Delta value A message A message Passe
validation: box with box with d
By entering a message message
delta value Invalid delta Invalid delta
other than a value, delta value, delta
number value out of value out of
between 1 to range is range is
256 expected to displayed
be shown
4.
Base value A message A message Passe
validation: by box saying box saying d
entering the the message the message
delta value choose delta choose delta
such that such that base such that base
base value is below 10 is below 10
above 10 is expected to is displayed
be shown
Table 9.1 Test cases

Chapter 10
SCREENSHOTS

42
43
 CONCLUSION
The transmission of tuple Q to the receiver via a secure channel ensures the
confidentiality of the message. However, tuple R can be communicated through open

44
channel. So, R becomes easily accessible. Let some intruder capture R as (r1, r2, . . . ,
rn) from the open channel. In that case, the probability that an element ri is interpreted
correctly by the intruder is . For example, if is the set of 26 English characters and
is 5, any remainder ri = 3 has 5 possible outcomes as {d, i, n, s, x}. The message can
be correctly decoded if the corresponding quotient qi is known. As Q is communicated
securely, the intruder cannot decode the message. In general, if the message is of n
characters, the unconditional probability for correctly decoding a message is n. The
proposed MOD-ENCODER technique represents the message as a bi-tuple <R, Q>.
The individual tuples can be communicated independently to the receiver. The secrecy
of the message is ensured by encoding one half, generally Q, of the bi-tuple. The error
probability of decoding is considerably high when either Q or R is unknown. The
proposed technique also provides a lossless compression that facilitates 0 0.5 1 1.5 2
2.5 3 0 1000 2000 3000 4000 5000 Compression Ratio (CR) Size of Plain Text (n)
DELTA = 4 DELTA = 5 DELTA = 7 Fig. 1. C.R. vs n 0 0.5 1 1.5 2 2.5 3 0 5 10 15 20
Compression Ratio (CR) Modulus Constant (Delta) Fig. 2. C.R. vs better bandwidth
utilization. Moreover, as the encryption is applied to one half of the encoded message,
it reduces the computational complexity.

REFERENCES
[1] Debra A. Lelewer, Daniel S. Hirschberg Data Compression, ACM
Computing Surveys (CSUR), vol 19, Issue 3, pp. 261 - 296, Sep. 1987
[2] William C. Barker,Recommendation for the Triple Data Encryption
Algorithm (TDEA) Block Cipher, National Institute of Standards and
Technology, NIST Special Publication 800-67, 2008.
[3] Announcing the ADVANCED ENCRYPTION STANDARD (AES), Federal
Information Processing Standards Publication 197, Nov. 2001
[4] R.L. Rivest, The RC5 encryption algorithm,Proceedings of the 1994 Leuven
Workshop on Fast Software Encryption, pp. 86-96, Springer- Verlag, 1995.
[5] Ron Rivest, Adi Shamir and Len Adleman,A method for obtaining Digital
Signatures and Public Key Cryptosystems, Communications of the ACM, pp
120-126, Feb. 1978.
[6] Taher ElGamal, A Public-Key Cryptosystem and a Signature Scheme Based
on Discrete Logarithms, IEEE Transactions on Information Theory, v. IT-31,
n. 4, 1985, pp.469472 or CRYPTO 84, pp.1018, Springer-Verlag.
[7] Elliptic Curve Cryptography, Certicom Research, 2000 [8] Huffmans original
article: D.A. Huffman,A Method for the Constructionof Minimum-
Redundancy Codes, Proceedings of the I.R.E., Sep

45
46