A Project on

ENCRYPTION OF A FILE TO STORE

ON THE CLOUD SERVER
Submitted for partial fulfilment of award of
BACHELOR OF TECHNOLOGY

Degree
In
Computer Science
By

Prachi Pant (1310303037)

Kumar Shanu (1310303024)
Avantika (1310303016)
Anit Kumar (1310303011)

Name of Guide
Mr Rahul Rastogi

1
 Invertis University, Bareilly, INDIA
May, 2017

BONA-FIDE CERTIFICATE

This is to certify that this project report entitled “ENCRYPTION OF A FILE TO STORE ON
THE CLOUD SERVER” submitted to “Invertis Institute of Engineering and Technology,
Invertis University, Bareilly” is a bona-fide record of work done by “PRACHI PANT
(1310303037), KUMAR SHANU (1310303024), AVANTIKA (1310303016), ANIT KUMAR
(1310303011)” under my supervision from 02 Feb 2017 to 02 May 2017. The project embodies
result of original work and studies carried out by student himself and the contents of the project
do not form the basis for the award of any other degree to the candidate or to anybody else.

Name of Supervisor
Mr. Rahul Rastogi
Assistant Professor
Invertis University, Bareilly

Date: 26 May 2017

2
 DECLARATION

This is to declare that we have written this report. No part of the report is plagiarized from other
sources. All information included from other sources has been duly acknowledged. We aver that
if any part of the report is found to be plagiarized, we are shall take full responsibility for it.

Place Prachi Pant

Date 1310303037

3
 ACKNOWLEDGEMENT

It is our privilege to express our sincerest regards to our project coordinator Mr. Rahul Rastogi,
for their valuable inputs, guidance, encouragement, whole-hearted cooperation and constructive
criticism throughout the duration of our project.
We deeply express our sincere thanks to the Head of Department Dr. Ravi Shankar Shukla for
encouraging and allowing us to present the project on the topic “Compression of a File after
Encrypting the Data” for the partial fulfilment of the requirements leading to the award of
Bachelor of Technology Degree.
We take this opportunity to thank all our lecturers who have helped in our project. We pay our
respects and love to our parents and all other family members and friends for their love and
encouragement throughout our career. Last but not the least we express our thanks to our friends
for their cooperation and support.

Prachi Pant
Kumar Shanu
Avantika
Anit Kumar

4
 ABSTRACT

This project is about storing the data files in encrypted form. Normally we can store data files on
an open server and there is less security as the files are stored without any encryption. Here we
will be encrypting the data file provided by the user and then store them as a result files will be
not in readable form. If any unknown person needs to read, the file then he will need to take the
permission from the user whose file it is. If the owner does not permitted then user will only be
able to view the encrypted format of file.

No one can see through the file until the file owner permits. The file is downloaded in the
decrypted format only and only if the authorized user grants the permission. Theft of data and
personal files led to the need of encrypted data in order to save your data from intruders who
may steal the data or change it.

● Interactive user interface

● High security
● Data piracy can be avoided to some extent
● Data consistency
● Easy file upload

5
 TABLE OF CONTENTS

CHAPTER NO. TITLE PAGE NO.

ABSTRACT 3
LIST OF TABLES 7
LIST OF FIGURES 7

1. INTRODUCTION
1.1 Problem Definition.................................................................................................08
1.2 User panel...............................................................................................................08
2. SYSTEM REQUIREMENT SPECIFICATION
2.1 Process Model…………………………………………………………………….
2.2 Hardware Configuration..........................................................................................11
2.3 Software Configuration...........................................................................................11
2.4 Application Features....................................................................................................11
2.5 Feasibility Study……………………………………………………………………
3. SYSTEMANALYSIS
3.1 Existing System........................................................................................................24
3.2 Proposed System…………………………………………………………………...25
4. SYSTEM DESIGN
4.1 Input Design.............................................................................................................25
4.2 Process Design.........................................................................................................26
4.3 Database Design.......................................................................................................29
4.4 Output Design...........................................................................................................34
5. SYSTEM TESTING
5.1 Unit testing................................................................................................................36
5.2 Integration testing.....................................................................................................37
5.3 User Acceptance testing...........................................................................................37
6. IMPLEMENTATION
6.1 User Training.........................................................................................................38

6
 6.2 Security and Maintenance......................................................................................39
7. SCREENSHOTS……………………………………………………….................

8. CONCLUSION........................................................................................................40

9. BIBLIOGRAPHY......................................................................................................41

10. REFERENCES.................................................................................................................

7
 LIST OF FIGURES

PAGE NO. NAME OF FIGURE FIGURE NO.

33 Flow Chat 6.1(a)

35 Context Level DFD 6.1.4(a)

35 DFD Level 1 6.1.4(b)

36 DFD Level 2 6.1.4(c)

37 ER Diagram 6.2(a)

38 Use Case Diagram (Encryption) 6.3 (a)

38 Use Case Diagram (Decryption) 6.3 (b)

8
 CHAPTER 1
INTRODUCTION

9
 1. INTRODUCTION

1.1 Problem Definition

Earlier all the data was stored in the own systems for saving from malicious attacks that occur
online. With increase in data the need for storage also increased and so the requirement of cloud
storage did and thus the security of the data.
Encryption/decryption is especially important in wireless communications or online storage of
data. This is because wireless circuits are easier to "tap" than their hard-wired counter parts.
Encryption protects our data. It protects our data when it's sitting on our computers and in data
centres and it protects it when it's being transmitted around the Internet. It protects our
conversations, whether video, voice, or text. It protects our privacy. It protects our anonymity. It
protects our data from criminals. It protects it from competitors, neighbours, and family
members. It protects it from malicious attackers, and it protects it from accidents. Encryption
should be enabled for everything by default, not a feature you turn on only if you are doing
something you consider worth protecting.

1.2 Project Description

In this project Encryption is the conversion of data into a form, called a cipher text that cannot be
easily understood by unauthorized people. Decryption is the process of converting encrypted
data back into its original form, so it can be understood.

The use of encryption/decryption is as old as the art of communication. In wartime, a cipher,

often incorrectly called a "code," can be employed to keep the enemy from obtaining the
contents of transmissions. (Technically, a code is a means of representing a signal without the
intent of keeping it secret; examples are Morse code and ASCII.) Simple ciphers include the
substitution of letters for numbers, the rotation of letters in the alphabet, and the "scrambling" of
voice signals by inverting the sideband frequencies. More complex ciphers work according to
sophisticated computer an algorithm that rearranges the data bits in digital signals.

In order to easily recover the contents of an encrypted signal, the correct decryption key is
required. The key is an algorithm that "undoes" the work of the encryption algorithm.
Alternatively, a computer can be used in an attempt to "break" the cipher. The more complex the

10
encryption algorithm, the more difficult it becomes to eavesdrop on the communications without
access to the key.

Encryption/decryption is especially important in wireless communications. This is because

wireless circuits are easier to "tap" than their hard-wired counterparts. Nevertheless,
encryption/decryption is a good idea when carrying out any kind of sensitive transaction, such as
a credit-card purchase online, or the discussion of a company secret between different
departments in the organization. The stronger the cipher – that is, the harder it is for unauthorized
people to break it – the better, in general. However, as the strength of encryption/decryption
increases, so does the cost.

In recent years, a controversy has arisen over so-called strong encryption. This refers to ciphers
that are essentially unbreakable without the decryption keys. While most companies and their
customers view it as a means of keeping secrets and minimizing fraud, some government’s view
strong encryption as a potential vehicle by which terrorists might evade authorities.

Decryption keys would be stored in a supposedly secure place, used only by authorities, and
used only if backed up by a court order. Opponents of this scheme argue that criminals could
hack into the key-escrow database and illegally obtain, steal, or alter the keys.

1.3 Objection of the project

In order to be able to define our system architecture, we must first dearly state what our objective
that will deliver system behaviour at the same one of our objective is to create an experience,
which is not only unique to the (user) client, but also makes him feel that he has loyal attachment
to the system and approaches us whenever he/she needs.
To achieve better results and success by implement computerized process instead of manual
process.

1.4 User Panel

1.4.1 User Login

Home
1. It contains category of Feedback.

11
 2. It allows different users to access the registration forms.
3. He/she can also view the files stored on cloud.
4. The registered user can update their files on the cloud.

Registration Form

This section provides an online form to the user in which they fill details. After the details
are filled, they are submitted to be stored in the database for the user to be authenticated by
the server for the regular login to access the services offered.

12
 CHAPTER 2
SOFTWARE PROJECT PLAN

13
 2. SOTWARE PROJECT PLAN

This chapter discusses about that time schedule for the project and it contains the various phases
of the project.

The Various Phases of the Project:

S.NO TASK Duration

1 Requirement Specification 10 Days

2 Requirement document specification 10 Days

3 Design analysis 20 Days

4 Design Documentation 15 Days

5 Design Review 20 Days

6 Coding 15 Days

Total 90 Days

14
 CHAPTER 3
SYSTEM ENVIRONMENT

15
 3. SYSTEM ENVIRONMENT

3.1 Process Model

To solve actual problems in an industry setting, a software engineer or a team of engineers must
incorporate a development strategy that encompasses that process, methods, and tools. This
strategy is often referred to as process model or a software engineering paradigm.
A process model for software engineering is chosen based on the nature of the project and
application, the methods and tools to be used and the controls and the deliverables that are
required.
So, our application is based on the Object Oriented Approach. In this model we design the
UML diagrams like Use case, Activity, Sequence, Collaboration and Class diagrams.

3.2 Hardware Configuration

● Hard Disk Drive – 2 GB (min.)
● Processor - Pentium 1 and above
● RAM – 128 MB

3.3 Software Configuration

● Operating System : Windows (Preferably Windows 7, Vista, 8)
● Programming Language : Java
● Database : MySQL 2008
● User Interface : HTML
● Client Side Scripting : JavaScript, Query

3.4 Application Features

3.4.1 MODULES
3.4.1.1 Admin
The login module consists of username and password. This process is for authentication. The
username and password is correct it is link into next page. This process is done in login.

16
 3.4.1.2 Symmetric Key
● AES Algorithm
● RC4 Algorithm
● Triple DES Algorithm

3.4.1.3 Public Key

● RSA Algorithm

3.4.2 ALGORITHM DESCRIPTION

DES originated at IBM in 1977, it was adopted by the NIST as the standard encryption
algorithm for protecting unclassified information within the United States. The DES held
up pretty well to public cryptanalytic attacks until the mid-1990s when attacks based on
differential cryptanalysis and linear cryptanalysis were identified. It is specified in the
ANSI standards. DES has enjoyed general acceptance as the standard for symmetric
encryption.
Despite its vulnerability, DES is still in use in many applications and provides reasonable
security in cases where the cost of carrying out a DES attack outweighs the value of the
information being protected. In addition, DES is being used in more sophisticated ways,
such as in the TripleDES algorithm. These protect DES from being broken using publicly
available computing resources and cryptanalysis techniques.
DES is a symmetric block cipher that transforms 64-bit data blocks using a 56-bit shared
secret key, involving 16 rounds of permutation and substitution.
The overall scheme of DES encryption is illustrated in Figure 1 given on the next page.
There are two inputs to the encryption function: the plaintext to be encrypted and the key.
In case of DES, the plaintext is 64 bits in length and key is 56 bits long.

The left hand side of the figure shows that the processing of the plaintext proceeds in
three phases. First, the 64-bit plaintext passes through an initial permutation (IP) that
rearranges the bits to produce a permuted input. This is followed by a phase consisting of
16 rounds of the same function, which involves both permutation and substitution
functions. The output of the last (16th) round consists of 64 bits that are a function of the
input plaintext and the key. The left and the right halves of the output are swapped to
produce the preoutput. Finally the preoutput is passed through a permutation (IP-1) that is
the inverse of the Initial permutation function, to produce the 64-bit cipher-text.
The right hand portion of the figure 1 shows the way in which the 56 bit key is used.
Initially the key is passed through a permutation function. Then, for each of the 16

17
rounds, a sub-key (Ki) is produced by the combination of a left circular shift and a
permutation. The permutation function is the same for each round, but a different sub-key is
produced because of the repeated iteration of the key bits.

Fig 3.4.2 (a)

Initial and Final Permutation:

The initial and final permutations are straight Permutation boxes (P-boxes) that are inverses of
each other. They have no cryptography significance in DES. The initial and final permutations
are shown as follows −

18
 Fig.3.4.2(b)
Round Function

The initial and final permutations are straight Permutation boxes (P-boxes) that are inverses of
each other. They have no cryptography significance in DES. The initial and final permutations–

Fig 3.4.2(c)

19
Expansion Permutation Box:
Since right input is 32-bit and round key is a 48-bit, we first need to expand right input to 48 bits.
Permutation logic is graphically depicted in the following illustration

Fig 3.4.2(d)

XOR (Whitener):

After the expansion permutation, DES does XOR operation on the expanded right section and
the round key. The round key is used only in this operation.

Fig 3.4.2 (e)

Key Generation:
The round-key generator creates sixteen 48-bit keys out of a 56-bit cipher key. The process of
key generation is depicted in the following illustration that the encrypted message comes
decrypted using the algorithm used in the encryption phase.

20
 Fig 3.4.2(f)

3.5 Feasibility Study

Feasibility study is conducted once the problem is clearly understood. The feasibility study is a
high level capsule version of the entire system analysis and design process. The objective is to
determine whether the proposed system is feasible or not and it helps us to the minimum expense
of how to solve the problem and to determine, if the Problem is worth solving. The following are
the five important tests that have been carried out for feasibility study.

3.5.1 Technical Feasibility

3.5.2 Economical Feasibility
3.5.3 Operational Feasibility

21
 3.5.4 Political feasibility
3.5.5 Management feasibility
3.5.1 Technical feasibility
In the technical feasibility study, one has to test whether the proposed system can be developed
using existing technology or not. It is planned to implement the proposed system in JSP. The
project is technically feasible because of the following reasons,
• All necessary technology exists to develop the system.
• The existing system is so flexible that it can be developed further.

3.5.2 Economical feasibility

As a part of this, the costs and benefits associated with the proposed systems are to be compared.
The project is economically feasible only if tangible and intangible benefits outweigh the cost.
We can say the proposed system is feasible based on the following grounds.
• The cost of developing the full system is reasonable.
• The cost of hardware and software for the application is less.

3.5.3 Operational feasibility

The project is operationally feasible because there is sufficient support from the project
management and the users of the proposed system .Proposed system definitely does not harm
and will not produce the bad results and no problem will arise after implementation of the system

3.5.4 Political feasibility

As this project is for online discussions about technologies and we are using open source and
free technologies so there should be no political or legal difficulty for this project.

3.5.5 Management feasibility

The project is manageable from all aspects because it is feasible in all respect and the technology
used well tested the teams involved have knowledge of all domains and are skilled.

22
 CHAPTER 4
CUSTOMER REQUIREMENTS
DETERMINATION

23
 4. CUSTOMER REQUIREMENTS DETERMINATION

4.1 EXISTING SYSTEM

In the existing system, the encrypted key is send with the document. If the key is send with
document, any user can view the encrypted document with that key. It means the security
provided for the encryption is not handled properly.
In addition, the Key byte (encrypted key) generate with random byte. Without the user
interaction the Key byte is generated.

Drawbacks
Some of the drawbacks are:
1. Lack of security
2. Key byte is generated without user interaction

4.2 PROPOSED SYSTEM

To overcome all the problems in the existing system, we develop an “Encryption -Secure
Communication Using Public Key and Symmetric Key” to ease the operation.
A system is required which is being capable of elimination all the problems and become useful to
users and thus the new system is derived. Here, user can set the byte of key manually.

Benefits
1. Security is enhanced in well manner.
2. Users set the byte key manually.

24
 CHAPTER 5
SOFTWARE REQUIREMENT
SPECIFICATION

25
 5. SOFTWARE REQUIREMENTS SPECIFICATION

Software Requirements Specification (SRS) is the starting point of the software development
activity. Little importance was given to this phases in the early days of software development.
The emphasis was first on coding and then shifted to design.

As systems grew more complex, it become evident that the goal of the entire system cannot be
easily comprehended. Hence need for the requirements analysis phase arose. Now, for large
software systems, requirements analysis is perhaps the most difficult activity and also the most
error prone.

Some of the difficulty is due to the scope of this phase. The software project is imitated by the
client needs. In the beginning these needs are in the minds of various people in the client
organization. The requirement analyst has to identify the requirements by tacking to these people
and understanding their needs. In situations where the software is to automated a currently
manuals process, most of the needs can be understood by observing the current practice.

The SRS is a means of translating the ideas in the minds of the clients (the output) into formal
document (the output of the requirements phase). Thus the output of the phase is a set of
formally specified requirements, which hopefully are complete and consistent, while the input
has none of these properties.

26
5.1 Functional Requirements

Start

Upload File

Encrypt File

Store File in Access File from

Database Database

logout

5.2 Performance Requirements

The project must the end user requirements. Accuracy and fast must be imposed in the Project.
The project is development as easy as possible for the sake of end user. The project has to be
developed with view of satisfying the future requirements and future enhancement.
The tool has been finally implemented satisfying the needs specified by the company. As per the
performance is concerned this system said is performing This processing as well as tine taken to

27
generate well reports were also even when large amount of data was used.

5.3 Interface requirements

5.3.1 Hardware Interface
The stranded input device like keyboard and mouse are to get input. The output will be generated
and display in the monitor. The reports can also be exported to a SQL-server document are text
file. The stranded printer in used to take outputs.

5.3.2 Software Interface

The design part and interface id done the front end ASP.Net and SQL server as a backend of the
project.

5.4 Operational requirements

The database or databases that are being failed over to the stand by server cannot be used for
anything else. But databases on the standby server not being used for failover can still be used
normally.
When it comes time for actual failover, you much one of two things to make your application
work either rename the standby server the same name as the failed production server(and the IP
address) or re-point your user’s applications to new standby server in some cases, neither of this
option is practical.

5.5 Resource Requirements

5.1 Hardware Requirements
PROCESSOR : PENTIUM I 1.90 GHz
RAM : 2 GB
HARD DISK : 100 GB

5.5.2 Software Requirements

OPERATING SYSTEM : Windows 7
ENVIRONMENT : Netbeans IDE 8.0.2
JAVA FRAMEWORK : Version 8

28
LANGUAGE : Java
WEB TECHNOLOGY : HTML
BACKEND : MySQL 1.2.10

5.6 Security Requirements

Web application are available via network access, it is a difficult. If not possible, to limit the
population of the end-user who may access the applications? In order to product sensitive
connect and provide secure mode be implemented throughout the infrastructure that the supports
web application and within the application itself.
Web Application have become heavy integrated with critical corporate and database.
E-commerce application extracts and then store sensitive customer information.

5.7 Design Requirements

To create project, add base masters and masters to the project, assign
behaviours to the master, create and assign behaviour sets, and then apply, test and validate those
behaviours. It also shows how to create and build a stencil to hold the shapes.

5.8 Quality and Reliability Requirements

A software component that is developed for reuse would be correct and contain no defects. In
reality, formal verification is not carried out routinely, and defects can add to occur. However,
with each reuse, defects are found eliminated, and a components qualify improve as a result.
Over time the components virtually defect free.

Software reliability is defined in statical term as” the probability of faultier-free operation of a
computer program in a specified environment for specified tine”. The software quality and
reliability, failure is non-conformance to software requirements. Failure can be only anything or
catastrophic. One failure can be corrected within seconds while another requirements week even
mouths to correct. Complicating the issue even further, the correction of the one failure may in
fact result in the introduction of the errors that ultimately result in other failure.

29
Web Correct link processing
Application Reliability Error recovery
Quality Input validation and recovery

30
 CHAPTER 6

SYSTEM ANALYSIS

31
 6. SYSTEM ANALYSIS

In this section discussed about data flow diagram, Entity relationship diagram. These things are
represented as diagrams with proper notation.

6.1 Data Flow Diagram

The data flow diagram is one of the most improvement tools used by the system analyst
DeMacro (1978) NadGandSarson (1979) popularized the use if the data flow diagram as
modelling tools through their structured system analysis methodologies.
A data flow diagram should be the first tool used by system analyst to model system
components. These components are the system processes; the data used by this processes and
external entities that interact with the system and the information flows in the system. There are
four kinds of system components.

32
 Fig 6.1(a)

6.1.1. Process
Process show what system does. Each process has one or more data inputs and produces one or
more data output, Circles in a data flow diagram represent process. Each process has unique
name and number. This name and number appear inside the circle that represents the processes
in a data flow diagram. It is denoted as a circle.

33
6.1.2. Data Stores
File or data store is depositary of data. They contain data that is retained in the system.
Processes can enter the data into a data store or retrieve data from the data store. Each data store
is represented by thin line in the data flow diagram and each data store has a unique name. The
data store is represented in form of a line.

6.1.3 External Entities

External entities are outside the system but they either supply input data into the system or use
the system output, they are entities which the designer has no control. Square or rectangle may
represent external entities that supply data into a system or sometimes called sources. External
entities that use the system data are sometimes called sinks.

6.1.4 Data Flows

Dataflow model the passage of data in the system and are represented lines joining system
components. An arrow indicates the direction of the flow and the line labelled by the name of
the data flow.

34
DFD Level 0
(Context Level DFD)

DATA FILE (.txt)

ENCRYPTION
USER SYSTEM
ENCRYPTION KEY

Fig 6.1.4(a)

DFD Level 1

35
 USER LOGIN LOGIN TA

CIPHER FILE

ENCRYPTION
PROCESS

CIPHER FILE

DECRYPTION
PROCESS
DATA FILE

DATABASE HARD DISK

Fig 6.1.4(b)

DFD Level 2

36
 Fig 6.1.4(c)

6.2 ER Diagram

File Upload Encryption

37
 Key
User ID

USER 1
View Data

HAS

PERMISSIO
Text Data N
DATA
EXCHANGE

HAS

USER 2 View Data

Key User ID
Encryptio
File Upload n

Fig 6.2 (a)

38
6.3 Use Case Diagram

Encryption

Register into Cloud

Login to Cloud

Select File to Upload

Client
Encrypt Uploaded
File

Fig 6.3 (a)

Decryption

Select File to View

Ask for permission

from owner

Logout of Cloud

Client

Fig 6.3 (b)

39
 CHAPTER 9
SYSTEM TESTING

40
 9. SYSTEM TESTING
System testing involves user training system testing and successful running of the developed
proposed system. The user tests the developed system and changes are made according to their
needs. The testing phase involves the testing of developed system using various kinds of data.

An elaborate testing of data is prepared and the system is tested using the test data. While testing,
errors are noted and the corrections are made. The corrections are also noted for the future use.
The users are trained to operate the developed system.

TESTING
System testing is the stage of implementation that is aimed at ensuring that the system works
accurately and efficiently before live operation commences. Testing is vital to the success of the
system. System testing makes logical assumption that if all the parts of the system are correct,
then the goal will be successfully achieved. A series of testing are done for the proposed system
before the system is ready for the user acceptance testing.
The following are the types of Testing:
1. Unit Testing
2. Integration Testing
3. Validation Testing
4. Verification testing
5. User acceptance testing

9.1 UNIT TESTING

The procedure level testing is made first. By giving improper inputs, the errors occurred are
noted and eliminated. Then the web form level testing is made. For example storage of data to
the table in the correct manner.
In the company as well as seeker registration form, the zero length username and password are
given and checked. Also the duplicate username is given and checked. In the job and question
entry, the button will send data to the server only if the client side validations are made.

The dates are entered in wrong manner and checked. Wrong email-id and web site URL
(Universal Resource Locator) is given and checked.

41
9.2 INTEGRATION TESTING

Testing is done for each module. After testing all the modules, the modules are integrated and
testing of the final system is done with the test data, specially designed to show that the system
will operate successfully in all its aspects conditions. Thus the system testing is a confirmation
that all is correct and an opportunity to show the user that the system works.

9.3 VALIDATION TESTING

The final step involves Validation testing, which determines whether the software function as the
user expected. The end-user rather than the system developer conduct this test most software
developers as a process called “Alpha and Beta Testing” to uncover that only the end user seems
able to find.

9.4 VERIFICATION TESTING

Verification is a fundamental concept in software design. This is the bridge between customer
requirements and an implementation that satisfies those requirements.
This is verifiable if it can be demonstrated that the testing will result in an implementation that
satisfies the customer requirements.
Inadequate testing or non-testing leads to errors that may appear few months later. This will
create two problems.
● Time delay between the cause and appearance of the problem.
● The effect of the system errors on files and records within the system.

9.5 USER ACCEPT TESTING

User acceptance testing of a system is the key factor of the success of any system. The system
under study is tested for the user acceptance by constantly keeping in touch with the prospective
system users at any time of developing and making changes whenever required.

42
SYSTEM IMPLEMENTATION

Implementation is the most crucial stage in achieving a successful system and giving the user’s
confidence that the new system is workable and effective. Implementation of a modified
application to replace an existing one. This type of conversation is relatively easy to handle,
provide there are no major changes in the system.

Each program is tested individually at the time of development using the data and has verified
that this program linked together in the way specified in the programs specification, the
computer system and its environment is tested to the satisfaction of the user. The system that has
been developed is accepted and proved to be satisfactory for the user. And so the system is going
to be implemented very soon. A simple operating procedure is included so that the user can
understand the different functions clearly and quickly.

Initially as a first step the executable form of the application is to be created and loaded in the
common server machine which is accessible to all the user and the server is to be connected to a
network. The final stage is to document the entire system which provides components and the
operating procedures of the system.

SCOPE FOR FUTURE DEVELOPMENT

Every application has its own merits and demerits. The project has covered almost all the
requirements. Further requirements and improvements can easily be done since the coding is
mainly structured or modular in nature. Changing the existing modules or adding new modules
can append improvements. Further enhancements can be made to the application, so that the web
site functions very attractive and useful manner than the present one.

43
 CHAPTER 10
PROBLEMS FACED AND
FUTURE WORK

44
 10. PROBLEMS FACED

When there is a clear goal in sight but no clear set of directions or means to attain that goal, then
it is called a problem. Problems can be broken down into four aspects; goal, givens, means of
transforming conditions, and obstacles.

Goal – the goal is the desired end state which the problem solving is being directed toward. The
hope is to reach that end state and be able to assess whether or not you achieved what you
wanted.

Givens- these are the objects, conditions, and constraints that accompany a problem, and can be
either explicit or implicit.

Means of transforming conditions- there should be a way of changing the initial state of the
problem. This is most usually a person’s knowledge or skill level. For instance, a computer
programmer presented with a problem would utilize his or her knowledge of programming
language to transform the state of the problem.

Obstacles- the problem should present a challenge. If there are no challenges involved and the
situation can be easily solved then it is not so a problem so much as a routines task.

Every problem has a problem faced, which is the whole range of possible states and operators.
Only some of these states and operators will bring the person closer to the goal state. The
problem starts at the initial state and operators are applied to change the state, creating a series of
intermediate states that should hopefully lead to the final goal state.

45
 FUTURE WORK

1. In future the software will compress the encrypted data and stores it on cloud server so
that the user can store the data by paying minimal amount.

2. Currently .txt files can be encrypted only, but in future other file formats like .doc, .exe
and image files .jpg can also be encrypted.

3. For now system allows client to view files only, but in future they can download them.

46
CHAPTER 12
CONCLUSION

47
 12. CONCLUSION

It is concluded that the application works well and satisfy the users. The application is tested
very well and errors are properly debugged. The site is simultaneously accessed from more than
one system. Simultaneous login from more than one place is tested.

The application works according to the restrictions provided in their respective system. Further
enhancements can be made to the application, so that the application functions very attractive
and useful manner than the present one. The security of file is well enough to save from data
being copied.

48
 CHAPTER 13
SCREEN SHOTS

49
50
 13. REFERENCES

► http://googleweblight.com/i?u=http://www.cse.wustl.edu/~jain\cse567-

06\ftp\encryption_perf%232_5&hl=en=IN

► http://www.tutorialspoint.com

► http://slogix.in

► https://stackoverflow.com

51