Anda di halaman 1dari 53

CHAPTER 01

INTRODUCTION

1|P a g e
1. INTRODUCTION
Data de-duplication is a technique for eliminating duplicate copies of data, and has been widely used
in cloud storage to reduce storage space and upload bandwidth. However, there is only one copy for
each file stored in cloud even if a huge number of users owns such a file. As a result, de duplication
system improves storage utilization while reducing reliability. Furthermore, the challenge of privacy for
sensitive data also arises when users to cloud outsource them. Aiming to address the above security
challenges, this paper makes the first attempt to formalize the notion of distributed reliable de
duplication system. We propose new distributed de duplication systems with higher reliability in which
the data chunks are distributed across multiple cloud servers. The security requirements of data
confidentiality and tag consistency are also achieved by introducing a deterministic secret sharing
scheme in distributed storage systems, instead of using convergent encryption as in previous de
duplication systems. Security analysis demonstrates that our de duplication systems are secure in terms
of the definitions specified in the proposed security model. As a proof of concept, we implement the
proposed systems and demonstrate that the incurred overhead is very limited in realistic environments.

1.1 MOTIVATION

1.1.1 PROBLEM STATEMENT


A number of de duplication systems have been proposed based on various de duplication strategies
such as client-side or server-side de duplications, file-level or block-level de duplications. Formalized
this primitive as message-locked encryption, and explored its application in space efficient secure
outsourced storage. There are also several implementations of convergent implementations of different
convergent encryption variants for secure de duplication. Li addressed the key-management issue in
block-level de duplication by distributing these keys across multiple servers after encrypting the files.
1.1.2 OVERVIEW OF PROPOSED SYSTEM
In this project, we show how to design secure de duplication systems with higher reliability in cloud
computing. We introduce the distributed cloud storage servers into de duplication systems to provide
better fault tolerance. To further protect data confidentiality, the secret sharing technique is utilized,
which is also compatible with the distributed storage systems. In more details, a file is first split and
encoded into fragments by using the technique of secret sharing, instead of encryption mechanisms.
These shares will be distributed across multiple independent storage servers. Furthermore, to support de
duplication, a short cryptographic hash value of the content will also be computed and sent to each
storage server as the fingerprint of the fragment stored at each server.

2|P a g e
1.2 SCOPE
This document is the only one that describes the requirements of the system. It is meant for the use
by the developers, and will by the basis for validating the final delivered system. Any changes made to
the requirements in the future will have to go through a formal change approval process. The developer
is responsible for asking for clarifications, where necessary, and will not make any alterations without
the permission of the client.

1.3 PROJECT OBJECTIVE


The main aim of this project is to implement our de duplication systems using the Ramp secret
sharing scheme that enables high reliability and confidentiality levels. Our evaluation results
demonstrate that the new proposed constructions are efficient and the redundancies are optimized and
comparable with the other storage system supporting the same level of reliability.

1.4 ORGANIZATION OF DOCUMENT


The reminder of this document is first providing the full description of the project. It lists all the
functions performed by the system. In addition, it concerns the details of the system functions and
actions of each function, which was performed by the system.
Chapter 2: describes about the Literature survey.
Chapter 3: Describes about the Analysis of the Project
Chapter 4: Describes about the Design of the Project
Chapter 5: Describes about the Implementation of the Project
Chapter 6: Describes about output of the project
Chapter 7: Describes about the Testing and Validation of the Project
Chapter 8: Conclusion and future enhancement of the project

3|P a g e
CHAPTER 02
LITERATURE SURVEY

4|P a g e
2. LITERATURE SURVEY

Data de-duplication techniques are very interesting techniques that are widely employed for
data backup in enterprise environments to minimize network and storage overhead by
detecting and eliminating redundancy among data blocks. There are many de duplication
schemes proposed by the research community. However, they only focused on traditional files
without encryption, without considering the reliable de duplication over cipher text. Showed
how to achieve reliable key management in de duplication. However, they did not mention
about the application of reliable de duplication for encrypted files.
Later we extended the methods for the construction of reliable de-duplication for user files.
However, all of these works have not considered and achieved the tag consistency and
integrity in the construction. Convergent encryption. Convergent encryption ensures data
privacy in de duplication. Formalized this primitive as message-locked encryption, and
explored its application in space efficient secure outsourced storage. There are also several
implementations of convergent implementations of different convergent encryption variants
for secure de duplication

2.1 Cipher text-Policy Attribute-Based Encryption

In several distributed systems a user should only be able to access data if a user possess a
certain set of credentials or attributes. Currently, the only method for enforcing such policies
is to employ a trusted server to store the data and mediate access control. However, if any
server storing the data is compromised, then the confidentiality of the data will be
compromised. In this project, we presented a system for realizing complex access control on
encrypted data that we call Cipher text-Policy Attribute-Based Encryption. By using our
techniques, encrypted data can be kept confidential even if the storage server is untrusted;
moreover, our methods are secure against collusion attacks. Previous Attribute Based
Encryption systems used attributes to describe the encrypted data and built policies into user’s
keys; while in our system attributes are used to describe a user’s credentials, and a party
encrypting data determines a policy for who can decrypt. Thus, our methods are conceptually
closer to traditional access control methods such as Role-Based Access Control (RBAC). In
addition, we provide an implementation of our system and give performance measurements.

5|P a g e
2.2 Attribute-Based Encryption for Fine-Grained Access Control of
Encrypted Data

As more sensitive data is shared and stored by third-party sites on the Internet, there
will be a need to encrypt data stored at these sites. One drawback of encrypting data, is that it
can be selectively shared only at a coarse-grained level (i.e., giving another party your private
key). We develop a new cryptosystem for fine-grained sharing of encrypted data that we call
Key-Policy Attribute-Based Encryption (KP-ABE). In our cryptosystem, cipher texts are
labeled with sets of attributes and private keys are associated with access structures that
control which cipher texts a user is able to decrypt. We demonstrate the applicability of our
construction to sharing of audit-log information and broadcast encryption. Our construction
supports delegation of private keys which subsumes Hierarchical Identity-Based Encryption
(HIBE).

2.3 Secure Data Deduplication

As the world moves to digital storage for archival purposes, there is an increasing demand
for systems that can provide secure data storage in a cost-effective manner. By identifying
common chunks of data both within and between files and storing them only once,
deduplication can yield cost savings by increasing the utility of a given amount of storage.
Unfortunately, deduplication exploits identical content, while encryption attempts to make all
content appear random; the same content encrypted with two different keys results in very
different cipher text. Thus, combining the space efficiency of deduplication with the secrecy
aspects of encryption is problematic. We have developed a solution that provides both data
security and space efficiency in single-server storage and distributed storage systems.
Encryption keys are generated in a consistent manner from the chunk data; thus, identical
chunks will always encrypt to the same cipher text. Furthermore, the keys cannot be deduced
from the encrypted chunk data. Since the information each user needs to access and decrypt
the chunks that make up a file is encrypted using a key known only to the user, even a full
compromise of the system cannot reveal which chunks are used by which users.

6|P a g e
2.4 Reclaiming Space From Duplicate Files In A Server Less Distributed File
System

The Farsite distributed file system provides availability by replicating each file onto
multiple desktop computers. Since this replication consumes significant storage space, it is
important to reclaim used space where possible. Measurement of over 500 desktop file
systems shows that nearly half of all consumed space is occupied by duplicate files. We
present a mechanism to reclaim space from this incidental duplication to make it available for
controlled file replication. Our mechanism includes: convergent encryption, which enables
duplicate files to be coalesced into the space of a single file, even if the files are encrypted
with different users' keys; and SALAD, a Self-Arranging Lossy Associative Database for
aggregating file content and location information in a decentralized, scalable, fault-tolerant
manner. Large-scale simulation experiments show that the duplicate-file coalescing system is
scalable, highly effective, and fault-tolerant.

2.5 A Secure Data Deduplication Scheme for Cloud Storage

As more corporate and private users outsource their data to cloud storage providers, recent
data breach incidents make end-to-end encryption an increasingly prominent requirement.
Unfortunately, semantically secure encryption schemes render various cost-effective storage
optimization techniques, such as data deduplication, ineffective. We present a novel idea that
differentiates data according to their popularity. Based on this idea, we design an encryption
scheme that guarantees semantic security for unpopular data and provides weaker security
and better storage and bandwidth benefits for popular data. This way, data deduplication can
be effective for popular data, whilst semantically secure encryption protects unpopular
content. We show that our scheme is secure under the Symmetric External Decisional Diffie-
Hellman Assumption in the random oracle model.

7|P a g e
CHAPTER 03
SYSTEM ANALYSIS

8|P a g e
3. SYSTEM ANALYSIS

3.1 EXISTING SYSTEM


Existing system uses an encryption technique that meets the security requirement of data
providers called attribute-based encryption (ABE). However, the standard ABE system fails to
achieve secure deduplication, which is a technique to save storage space by eliminating
redundant copies of the encrypted data stored in the cloud.

3.2 DISADVANTAGES
Data reliability is actually a very critical issue in a de duplication storage system because
there is only one copy for each file stored in the server shared by all the owners. Most of the
previous de duplication systems have only been considered in a single-server setting. The
traditional de duplication methods cannot be directly extended and applied in distributed and
multi-server systems.

3.3 PROPOSED SYSTEM


In this application, we presented an approach to realize an attribute-based storage system
supporting secure de-duplication. Our storage system is built under a hybrid cloud architecture,
where a private cloud manipulates the computation and a public cloud manages the storage.
Only the data owner who first uploads the data is required to compute and distribute such secret
shares, while all following users who own the same data copy do not need to compute and store
these shares any more.
To recover data copies, users must access a minimum number of storage servers through
authentication and obtain the secret shares to reconstruct the data. In other words, the secret
shares of data will only be accessible by the authorized users who own the corresponding data
copy. Four new secure de duplication systems are proposed to provide efficient de duplication
with high reliability for file-level and block-level de duplication, respectively. The secret
splitting technique, instead of traditional encryption methods, is utilized to protect data
confidentiality. Specifically, data are split into fragments by using secure secret sharing
schemes and stored at different servers.

9|P a g e
3.4 ADVANTAGES
Distinguishing feature of our proposal is that data integrity, including tag consistency, can
be achieved. To our knowledge, no existing work on secure de duplication can properly address
the reliability and tag consistency problem in distributed storage systems. Our proposed
constructions support both file-level and block-level de duplications. Security analysis
demonstrates that the proposed de duplication systems are secure in terms of the definitions
specified in the proposed security model. In more details, confidentiality, reliability and
integrity can be achieved in our proposed system. Two kinds of collusion attacks are considered
in our solutions.
These are the collusion attack on the data and the collusion attack against servers. In
particular, the data remains secure even if the adversary controls a limited number of storage
servers. We implement our de duplication systems using the Ramp secret sharing scheme that
enables high reliability and confidentiality levels. Our evaluation results demonstrate that the
new proposed constructions are efficient and the redundancies are optimized and comparable
with the other storage system supporting the same level of reliability.

3.5 ARCHITECTURE
3.5.1 SYSTEM ARCHITECTURE:

Fig 3.5.1 System Architecture

10 | P a g e
3.5.2 INTERNAL SYSTEM ARCHITECTURE:

Request
Database
Browser
Web Server
(MYSQL)
HTML/JSP
JSP
Response

3.5.2 Internal System Architecture

3.6 FEASIBILTY STUDY


The next step in analysis is to verify the feasibility of the proposed system. “All projects
are feasible given unlimited resources and infinite time“. However, in reality, both resources
and time are scarce. Project should confirm to time bounce and should be optimal in there
consumption of resources. These places a constant are approval of any project.
Feasibility has applied to Maintenance of Elementary School Data pertains to the following
areas:
• Technical feasibility
• Economical feasibility
• Operational feasibility
3.6.1 Technical Feasibility
To determine whether the proposed system is technically feasible, we should take into
consideration the technical issues involved behind the system.
Maintenance of Elementary School Data uses the web technologies, which is rampantly
employed these days worldwide. The world without the web is incomprehensible today. That
goes to proposed system is technically feasible.
To determine the operational feasibility of the system we should take into consideration
the awareness level of the users. This system is operational feasible since the users are familiar
with the technologies and hence there is no need to gear up the personnel to use system. In
addition, the system is very friendly and to use.

11 | P a g e
3.6.2 Economic Feasibility
To decide whether a project is economically feasible, we have to consider various factors
as:
• Cost benefit analysis
• Long-term returns
• Maintenance costs
The proposed Maintenance of Elementary School Data is computer based. It requires
average computing capabilities and access to internet, which are very basic requirements and
can be afforded by any organization hence it does not incur additional economic overheads,
which renders the system economically feasible.
3.6.3 Operational Feasibility
To determine the operational feasibility of the system we should take into consideration
the awareness level of the users. This system is operational feasible since the users are familiar
with the technologies and hence there is no need to gear up the personnel to use system. In
addition, the system is very friendly and to use.
3.7 SOFTWARE REQUIREMENTS SPECIFICATION
Software Requirement Specification (SRS) is the starting point of the software developing
activity. As system grew more complex, it became evident that the goal of the entire system
cannot be easily comprehended. Hence, the need for the requirement phase arose. The
software project is initiated by the client needs. The SRS is the means of translating the ideas
of the minds of clients (the input) into a formal document (the output of the requirement phase.)
The SRS phase consists of two basic activities:

1) Problem/Requirement Analysis: The process is order and more nebulous of the


two, deals with understand the problem, the goal and constraints.

2) Requirement Specification: Here, the focus is on specifying what has been


found giving analysis such as representation, specification languages and tools, and
checking the specifications are addressed during this activity.

The Requirement phase terminates with the production of the validate SRS document.
Producing the SRS document is the basic goal of this phase.

12 | P a g e
3.7.1 FUNCTIONAL REQUIREMENTS
Functional requirement should include function performed by a specific screen outline
workflows performed by the system and other business or compliance requirement the system
must meet. Functional requirements specify which output file should be produced from the
given file they describe the relationship between the input and output of the system, for each
functional requirement a detailed description of all data inputs and their source and the range
of valid inputs must be specified.
The functional specification describes what the system must do, how the system does, it is
described in the design specification. If a user requirement specification was written, all
requirements outlined in the user requirements specifications should be addressed in the
functional requirements.
3.7.2 NON FUNCTIONAL REQUIREMENTS
Describe user-visible aspects of the system that are not directly related with the
functional behavior of the system. Non-Functional requirements include quantitative
constraints, such as response time (i.e. how fast the system reacts to user commands.) or
accuracy (i.e. how precise are the systems numerical answers.).
3.7.3 HARDWARE REQUIREMENTS
 System : Pentium IV 2.4 GHz.

 Hard Disk : 1 TB.

 Ram : 4 GB.

3.7.4 SOFTWARE REQUIREMENTS


 Technology : Java 2 Standard Edition.
 Web Server : Tomcat 7.0
 Client Side Technologies : HTML, CSS, JavaScript
 Server Side Technologies : Servlets, JSP
 Data Base Server : MySQL
 Operating System : Microsoft Windows 10
 IDE : Eclipse

13 | P a g e
CHAPTER 04
SYSTEM DESIGN

14 | P a g e
4. SYSTEM DESIGN

System design is transition from a user-oriented document to programmers or data base


personnel. The design is a solution, how to approach to the creation of a new system. This is
composed of several steps. It provides the understanding and procedural details necessary for
implementing the system recommended in the feasibility study. Designing goes through
logical and physical stages of development, logical design reviews the present physical
system, prepare input and output specification, details of implementation plan and prepare a
logical design walkthrough.
The database tables are designed by analyzing functions involved in the system and format of
the fields is also designed. The fields in the database tables should define their role in the
system. The unnecessary fields should be avoided because it affects the storage areas of the
system. Then in the input and output screen design, the design should be made user friendly.
The menu should be precise and compact.

4.1 SOFTWARE DESIGN


In designing the software following principles are followed:
1. Modularity and partitioning: software is designed such that, each system should consists
of hierarchy of modules and serve to partition into separate function.
2. Coupling: modules should have little dependence on other modules of a system.
3. Cohesion: modules should carry out in a single processing function.
4. Shared use: avoid duplication by allowing a single module be called by other that need the
function it provides

4.2 UML INTRODUCTION


The Unified Modeling Language (UML) is a standard language for specifying, visualizing,
constructing, and documenting the artifacts of software systems, as well as for business
modeling and other non-software systems. The UML represents a collection of best engineering
practices that have proven successful in the modeling of large and complex systems. The UML
is a very important part of developing objects oriented software and the software development
process. The UML uses mostly graphical notations to express the design of software projects.
Using the UML helps project teams communicate, explore potential designs, and validate the
architectural design of the software.

15 | P a g e
Building Blocks of The UML:
The vocabulary of the UML encompasses three kinds of building blocks:
 Things
 Relationships

 Diagrams
Things in the UML:
There are four kinds of things in the UML:
 Structural things
 Behavioral things
 Grouping things
 Annotational things
Relationships in the UML:
There are four kinds of relationships in the UML:
 Dependency
 Association

 Generalization
 Realization
Goals of UML:
The primary goals in the design of the UML are:
Provide users with a ready-to-use, expressive visual modelling language so they can develop
and exchange meaningful models.
1. Provide extensibility and specialization mechanisms to extend the core concepts.
2. Being independent of particular programming languages and development processes.
3. Provide a formal basis for understanding the modeling language.
4. Encourage the growth of the OO tools market.
5. Support higher-level development concepts such as collaborations, frameworks, patterns
and components.

Types of UML Diagram


Each UML diagram is designed to let developers and customers view a software system from
a different perspective and in varying degrees of abstraction. UML diagrams commonly created
in visual modeling tools include:

16 | P a g e
1. USECASE DIAGRAM
Display the relationship among actors and Use Cases. A use case is a set of scenarios that
describing an interaction between a user and a system. A use case diagram displays the
relationship among actors and use cases. The two main components of a use case diagram are
use cases and actors.

An actor represents a user or another system that will interact with the system you are modeling.
A use case is an external view of the system that represents some action the user might perform
in order to complete a task. Use cases are used in almost every project. They are helpful in
exposing requirements and planning the project.

Fig: 4.2.1 Use Case diagram

17 | P a g e
2. CLASS DIAGRAM

Class diagrams are widely used to describe the types of objects in a system and their
relationships. Class diagrams model class structure and contents using design elements such as
classes, packages and objects. Class diagrams describe three different perspectives when
designing a system, conceptual, specification, and implementation. These perspectives become
evident as the diagram is created and help solidify the design. Classes are composed of three
things: a name, attributes, and operations.
Class diagrams also display relationships such as containment, inheritance, associations
and others. The association relationship is the most common relationship in a class diagram.
The association shows the relationship between instances of classes. Another common
relationship in class diagrams is a generalization. A generalization is used when two classes are
similar, but have some differences.

Fig: 4.2.2. Class diagram

18 | P a g e
3. INTERACTION DIAGRAM

Interaction diagrams model the behavior of use cases by describing the way groups of
objects interact to complete the task. The two kinds of interaction diagrams are sequence and
collaboration diagrams.

4. SEQUENCE DIAGRAM

Sequence diagrams demonstrate the behavior of objects in a use case by describing the
objects and the messages they pass. The diagrams are read left to right and descending. Display
the time sequence of the objects participating in the interaction. This consists of the vertical
dimension (time) and horizontal dimension (different objects).

Fig: 4.2.3 Sequence diagram

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

Fig: 4.2.4 Collaboration diagram

20 | P a g e
6. 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 are intended to model both computational and organizational processes (i.e.
workflows). Activity diagrams show the overall flow of control.

Fig 4.2.5. Activity diagram

21 | P a g e
4.3 INPUT/OUTPUT DESIGN
Input design: considering the requirements, procedures to collect the necessary input data
in most efficiently designed. The input design has been done keeping in view that, the
interaction of the user with the system being the most effective and simplified way.
Also the measures are taken for the following
 Controlling the amount of input
 Avoid unauthorized access to the classroom.
 Eliminating extra steps
 Keeping the process simple
 At this stage, the input forms and screens are designed.
Output design: All the screens of the system are designed with a view to provide the user
with easy operations in simpler and efficient way, minimum key strokes possible. Instructions
and important information is emphasized on the screen. Almost every screen is provided with
no error and important messages and option selection facilitates. Emphasis is given for speedy
processing and speedy transaction between the screens. Each screen assigned to make it as
much user friendly as possible by using interactive procedures. So to say user can operate the
system without much help from the operating manual.

22 | P a g e
CHAPTER 05
DEVELOPMENT PROCESS

23 | P a g e
5. DEVELOPMENT PROCESS
5.1 DEVELOPMENT PROCESS
The process of development mainly divided according to the module that are included in
our application. There are mainly four modules in our project and each has a development
process and all these are again combined into a single application. Now we will discuss briefly
about each and every module included in our application.
5.2 OVER VIEW OF SOFTWARE DEVELOPMENT TOOLS
HTML
Html is a language, which is used to create web pages with html marking up a page to
indicate its format, telling the web browser where you want a new line to begin or how you
want text or images aligned and more are possible.
We used the following tags in our project.
TABLE:

Tables are so popular with web page authors is that they let you arrange the elements of a
web page in such a way that the browser won’t rearrange them web page authors frequently
use tables to structure web pages.
TR:
TR is used to create a row in a table encloses <TH> and <TD> elements
<TR> contain many attributes. Some of them are,
 ALIGN: specifies the horizontal alignment of the text in the table row.
 BGCOLOR: Specifies the background color for the row.
 BORDERCOLOR: Sets the external border color for the row.
 VALIGN: Sets the vertical alignment of the data in this row.
TH:
TH is used to create table heading.
 ALIGN: Sets the horizontal alignment of the content in the table cell. Sets LEFT,
RIGHT, CENTER.
 BACKGROUND: Species the back ground image for the table cell.
 BGCOLOR: Specifies the background color of the table cell
 VALIGN: Sets the vertical alignment of the data. Sets to TOP, MIDDLE, BOTTOM
or BASELINE.

24 | P a g e
TD:
TD is used to create table data that appears in the cells of a table.
 ALIGN: Species the horizontal alignment of content in the table cell. Sets to LEFT,
CENTER, RIGHT.
 BGCOLOR: Specifies the background image for the table cell.
 BGCOLOR: sets the background color of the table cells.
 WIDTH: Species the width of the cell
FRAMES:
Frames are used for either run off the page or display only small slices of what are supposed
to be shown and to configure the frame we can use <FRAMESET>There are two important
points to consider when working with <FRAMESET>.
 <FRAMESET> element actually takes the place of the <BODY> element in a
document.
 Specifying actual pixel dimensions for frames.
<FRAME> Elements are used to create actual frames.
From the frameset point of view dividing the browser into tow vertical frames means creating
two columns using the <FRAMESET> elements COLS attribute.
The syntax for vertical fragmentation is,
<FRAMESET COLS =”50%, 50%”>
</FRAMESET>
Similarly, if we replace COLS with ROWS then we get horizontal fragmentation.
The syntax for horizontal fragmentation is,
<FRAMESET ROWS=”50%, 50%”>
</FRAMESET>
FORM:
The purpose of FORM is to create an HTML form; used to enclose HTML
controls, like buttons and text fields.
ATTRIBUTES:

 : Gives the URL that will handle the form ACTION data.
 NAME: Gives the name to the form so you can reference it in code set to an alphanumeric
string.
 METHOD: method or protocol is used to sending data to the target action URL. The GET
method is the default, it is used to send all form name/value pair information in an URL.

25 | P a g e
CONTROLS IN HTML

<INPUT TYPE =BUTTON>:


Creates an html button in a form.
ATTRIBUTES:
 NAME: gives the element a name.
 SIZE: sets the size.
 VALUE: sets the caption of the element.

<INPUT TYPE = PASSWORD>:


Creates a password text field, which makes typed input.
ATTRIBUTES:

 NAME: gives the element a name,set to alphanumeric characters.


 VALUE: sets the default content of the element.

<INPUT TYPE=RADIO>:
Creates a radio button in a form.
ATTRIBUTE:

 NAME: Gives the element a name. Set to alphanumeric character.


 VALUE: Sets the default content of the element.

<INPUT TYPE=SUBMIT>:
Creates a submit button that the user can click to send data in the form back to
the web server.
ATTRIBUTES:

NAME: Gives the element a name. Set to alphanumeric characters.


VALUE: Gives this button another label besides the default, Submit Query. Set to
alphanumeric characters.
<INPUT TYPE=TEXT>:
Creates a text field that the user can enter or edit text in.
ATTRIBUTES:
NAME: Gives the element a name. Set to alphanumeric characters.
VALUE: Holds the initial text in the text field. Set to alphanumeric characters.

26 | P a g e
5.3 JAVA SCRIPT

Java script originally supported by Netscape navigator is the most popular web scripting
language today. Java script lets you embedded programs right in your web pages and run these
programs using the web browser. You place these programs in a <SCRIPT> element, usually
within the <HEAD> element. If you want the script to write directly to the web page, place it
in the <BODY> element.
JAVASCRIPT METHODS:
 Writeln: Document.writeln() is a method, which is used to write some text to the
current web page.
 onClick: Occurs when an element is clicked.
 onLoad: Occurs when the page loads.
 onMouseDown: Occurs when a mouse button goes down.
 onMouseMove: Occurs when the mouse moves.
 onUnload: Occurs when a page is unloaded.
MySQL JDBC DRIVERS:
The JDBC API only defines interfaces for objects used for performing various database-
related tasks like opening and closing connections, executing SQL commands, and retrieving
the results. We all write our programs to interfaces and not implementations. The resource
manager either vendor or a third party provides the implementation classes for the standard
JDBC interfaces. These software implementations are called JDBC drivers, JDBC drivers
transform the standard JDBC calls to the external resource manager-specific API calls. The
diagram below depicts how a database client written in java accesses an external resource
manager using the JDBC API and JDBC driver.

27 | P a g e
TYPES OF JDBC DRIVERS
Depending on the mechanism of implementation, JDBC drivers are broadly classified
into four types.
TYPE1:

Type1 JDBC drivers implement the JDBC API on top of a lower level API like ODBC. These
drivers are not generally portable because of the independency on native libraries. These
drivers translate the JDBC calls to ODBC calls and ODBC sends the request to external data
source using native library calls. The JDBC-ODBC driver that comes with the software
distribution for J2SE is an example of a type1 driver.
TYPE2:

Type2 drivers are written in mixture of java and native code. Type2 drivers use vendors specific
native APIs for accessing the data source. These drivers transform the JDBC calls to vendor
specific calls using the vendor’s native library. These drivers are also not portable like type1
drivers because of the dependency on native code.
TYPE3:

Type3 drivers use an intermediate middleware server for accessing the external data sources.
The calls to the middleware server are database independent. However, the middleware server
makes vendor specific native calls for accessing the data source. In this case, the driver is purely
written in java.
TYPE4:

Type4 drivers are written in pure java, implement the JDBC interfaces, and translate the JDBC
specific calls to vendor specific access calls. They implement the data transfer and network
protocol for the target resource manager. Most of the leading database vendors provide type4
drivers for accessing their database servers.
DRIVER MANAGER AND DRIVER:
The java.sql package defines an interface called Java.sql.Driver that makes to be implemented
by all the JDBC drivers and a class called java.sql.DriverManager that acts as the interface to
the database clients for performing tasks like connecting to external resource managers, and
setting log streams. When a JDBC client requests the DriverManager to make a connection to
an external resource manager, it delegates the task to an appropriate driver class implemented
by the JDBC driver provided either by the resource manager vendor or a third party.

28 | P a g e
JAVA.SQL.DRIVERMANAGER:
The primary task of the class driver manager is to manage the various JDBC drivers register.
It also provides methods for:
 Getting connections to the databases.
 Managing JDBC logs.
 Setting login timeout.
MANAGING DRIVERS:
JDBC clients specify the JDBC URL when they request a connection. The driver
manager can find a driver that matches the request URL from the list of register drivers and
delegate the connection request to that driver if it finds a match JDBC URLs normally take the
following format:
<protocol>:<sub-protocol>:<resource>

The protocol is always jdbc and the sub-protocol and resource depend on the type of
resource manager. The URL for postgreSQL is in the format:

Jdbc: postgres ://< host> :< port>/<database>

Here host is the host address on which post master is running and database is the name of the
database to which the client wishes to connect.

MANAGING CONNECTION:

DriverManager class is responsible for managing connections to the databases:

Public static Connection getConnection (String url,Properties info) throws


SQLException

This method gets a connection to the database by the specified JDBC URL using the
specified username and password. This method throws an instance of SQL Exception if a
database access error occurs.

JDBC RESULTSETS:
A JDBC resultset represents a two-dimentional array of data produced as a result of executing
SQL SELECT statements against databases using JDBC statements. JDBC resultsets are
represented by the interface java.sql.ResultSet. The JDBC vendor provider provides the
implementation class for this interface.

29 | P a g e
CONNECTIONS:

The interface java.sql.Connection defines the methods required for a persistent connection
to the database. The JDBC driver vendor implements this interface. A database ‘vendor-
neutral’ client never uses the implementation class and will always use only the interface. This
interface defines methods for the following tasks:

 Statements, prepared statements, and callable statements are the different types of
statements for issuing sql statements to the database by the JDBC clients.
 For getting and setting auto-commit mode.
 Getting meta information about the database.
 Committing and rolling back transactions.
CREATING STATEMENTS:
The interface java.sql.Connection defines a set of methods for creating database
statements. Database statements are used for sending SQL statements to the database:
Public Statement createStatement () throws SQLException
This method is used for creating instances of the interface java.sql.Statement. This interface
can be used for sending SQL statements to the database. The interface java.sql.Statement is
normally used for sending SQL statements that do not take any arguments. This method throws
an instance of SQLException if a database access error occur.
Public Statement createStatement (int resType, int resConcurrency) throws SQLException.
STATEMENT:
The interface java.sql.Stament is normally used for sending SQL statements that do not
have IN or OUT parameters. The JDBC driver vendor provides the implementation class for
this interface. The common methods required by the different JDBC statements are defined in
this interface. The methods defined by java.sql. Statement can be broadly categorized as
follows:
 Executing SQL statements
 Querying results and resultsets
 Handling SQL batches
 Other miscellaneous methods
 The interface java.sql.statements defines methods for executing different SQL
statements like SELECT, UPDATE, INSERT, DELETE, and CREATE.

Public Resultset execute Query (string sql) throws SQLException

30 | P a g e
5.4 JAVA SERVER PAGES
INTRODUCTION:
Java Server Pages (JSP) technology enables you to mix regular, static HTML with
dynamically generated content. You simply write the regular HTML in the normal manner,
using familiar Web-page-building tools. You then enclose the code for the dynamic parts in
special tags, most of which start with <% and end with %>.
THE NEED FOR JSP:
Servlets are indeed useful, and JSP by no means makes them obsolete. However,
 It is hard to write and maintain the HTML.
 You cannot use standard HTML tools.
 The HTML is inaccessible to non-Java developers.

BENEFITS OF JSP:
JSP provides the following benefits over servlets alone:
 It is easier to write and maintain the HTML: In this no extra backslashes, no double
quotes, and no lurking Java syntax.
 You can use standard Web-site development tools: We use Macromedia Dreamweaver
for most of the JSP pages. Even HTML tools that know nothing about JSP can used
because they simply ignore the JSP tags.
 You can divide up your development team: The Java programmers can work on the
dynamic code. The Web developers can concatenate on the representation layer. On
large projects, this division is very important. Depending on the size of your team and
the complexity of your project, you can enforce a weaker or stronger separation
between the static HTML and the dynamic content.
CREATING TEMPLATE TEXT:
A large percentage of our JSP document consists of static text known as template text. In almost
all respects, this HTML looks just likes normal HTML follows all the same syntax rules, and
simply “passed through” to that client by the servlet created to handle the page. Not only does
the HTML look normal, it can be created by whatever tools you already are using for building
Web pages.
There are two minor exceptions to the “template text passed through” rule. First, if you want
to have <% 0r %> in the out port, you need to put <\% or %\> in the template text. Second, if
you want a common to appear in the JSP page but not in the resultant document,

<%-- JSP Comment -- %>

31 | P a g e
TYPES OF JSP SCRIPTING ELEMENTS:

1. Expressions of the form <%=Java Expression %>, which are evaluated and inserted
into the servlet’s output.
2. Scriplets of the form <%Java code %>,which are inserted into the servlet’s_jsp Service
3. Declarations of the form<%! Field/Method Declaration %>, which are inserted into
the body of the servlet class, outside any existing methods.

5.5 USING JSP EXPRESSIONS:


A JSP element is used to insert values directly into the output. It has the following form:
<%= Java Expression %>
The expression is evaluated, converted to a string, and inserted in the page. This evaluation
is performed at runtime (when the page is requested) and thus has full access to the information
about the request. For example, the following shows the date/time that the page was requested.
Current time: <%=new java.util.Date () %>

5.6 PREDEFINED VARIABLES:


To simplify expressions we can use a number of predefined variables (or “implicit objects”).
The specialty of these variables is that, the system simple tells what names it will use for the
local variables in _jspService. The most important ones of these are:
 Request, the HttpServletRequest.
 Response, the HttpServletResponse.
 Session, the HttpSession associated with the request
 Out, the writer used to send output to clients.
 application, the ServletContext. This is a data structure shared by all servlets and JSP
pages in the web application and is good for storing shared data.

5.7 COMPARING SERVLETS TO JSP PAGES


JSP works best when the structure of the HTML page is fixed but the values at various places
need to be computed dynamically. If the structure of the page is dynamic, JSP is less beneficial.
Sometimes servlets are better in such a case. If the page consists of binary data or has little
static content, servlets are clearly superior. Sometimes the answer is neither servlets nor JSP
alone, but rather a combination of both.

32 | P a g e
WRITING SCRIPTLETS
If you want to do something more complex than output the value of a simple expression .JSP
scriptlets let you insert arbitrary code into the servlet’s jspService method. Scriptlets have the
following form:
<% Java code %>
Scriptlets have access to the same automatically defined variables as do expressions (request,
response, session, out , etc. ) .So for example you want to explicitly send output of the resultant
page, you could use the out variable, as in the following example:
SCRIPTLET EXAMPLE:
As an example of code that is too complex for a JSP expression alone, a JSP page that uses the
bgColor request parameter to set the background color of the page .Simply using
<BODY BGCOLOR=”<%= request.getParameter (“bgcolor”) %> “>
Would violate the cardinal rule of reading form data.
USING DECLARATIONS
A JSP declaration lets you define methods or fields that get inserted into the main body of
the servlet class .A declaration has the following form:
<%! Field or Method Definition %>
Since declarations do not generate output, they are normally used in conjunction with JSP
expressions or scriptlets. In principle, JSP declarations can contain field (instance variable)
definitions, method definitions, inner class definitions, or even static initializer blocks:
anything that is legal to put inside a class definition but outside any existing methods. In
practice declarations almost always contain field or method definitions.
5.8 APACHE TOMCAT

Apache Tomcat is a web Server.Tomcat is the Servlet/JSP container that implements the
Servlet 2.4 and Java Server Pages 2.0 specification. It also includes many additional features
that make it a useful platform for developing and deploying web applications and web services.
DIRECTORIES AND FILES:
/bin – Startup, shutdown, and other scripts. The *.sh files (for Unix systems) are functional
duplicates of the *.bat files (for Windows systems). Since the Win32 command-line lacks
certain functionality, there are some additional files in here.
/conf – Configuration files and related DTDs. The most important file in here is server.xml. It
is the main configuration file for the container.
/logs – Log files are here by default.

33 | P a g e
INSTALLATION:
Tomcat will operate under any Java Development Kit (JDK) environment that provides a
JDK 1.2 (also known as Java2 Standard Edition, or J2SE) or later platform. JDK is needed so
that servlets, other classes, and JSP pages can be compiled.

5.9 DEPLOYMENT DIRECTIONS FOR DEFAULT WEB APPLICATION


HTML and JSP Files
 Main Location
$CATALINA_HOME/webapps/ROOT
 Corresponding URLs.
http://host/SomeFile.html
http://host/SomeFile.jsp
 More Specific Location (Arbitrary Subdirectory).
$CATALINA_HOME/webapps/ROOT/SomeDirectory
 Corresponding URLs
http://host/SomeDirectory/SomeFile.html
http://host/SomeDirectory/SomeFile.jsp
Individual Servlet and Utility Class Files
 Main Location (Classes without Packages).
$CATALINA_HOME/webapps/ROOT/WEB-INF/classes
 Corresponding URL (Servlets).
http://host/servlet/ServletName
 More Specific Location (Classes in Packages).
$CATALINA_HOME/webapps/ROOT/WEB-INF/classes/packageName
 Corresponding URL (Servlets in Packages).
http://host/servlet/packageName.ServletName
Servlet and Utility Class Files Bundled in JAR Files
 Location
$CATALINA_HOME/webapps/ROOT/WEB-INF/lib

 Corresponding URLs (Servlets)


http://host/servlet/ServletName
http://host/servlet/packageName.ServletName

34 | P a g e
CHAPTER 06
IMPLEMENTATION

35 | P a g e
6. IMPLEMENTATION
6.1 HOME PAGE
index.htlm
<!DOCTYPE HTML>
<html>

<head>
<title>Hybrid Cloud</title>
<meta name="description" content="website description" />
<meta name="keywords" content="website keywords, website keywords" />
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<link rel="shortcut icon" type="image/x-icon" href="images/brainstorming_alternative.png"/>
<link rel="stylesheet" type="text/css" href="css/style.css" />
<!-- modernizr enables HTML5 elements and feature detects -->
<script type="text/javascript" src="js/modernizr-1.5.min.js"></script>
</head>

<body>
<div id="main">
<header>
<div id="logo">
<div id="logo_text">
<!-- class="logo_colour", allows you to change the colour of the text -->
<pre> <h2 style="color:black;">
Attribute Based Storage Supporting Secure Deduplication of Encrypted Data on Cloud
</h2>
</pre>
</div>
</div>
<nav>
<ul class="sf-menu" id="nav">
<li class="selected"><a href="index.html">Home</a></li>
<li><a href="admin.jsp">Admin</a></li>

<li><a href="#">User</a>
<ul>
<li><a href="user.jsp">Login</a></li>
<li><a href="register.jsp">Register</a></li>

</ul>
</li>

</ul>
</nav>
</header>
<div id="site_content">

</div>
<footer>
<p></p>
</footer>
</div>
<p>&nbsp;</p>
<!-- javascript at the bottom for fast page loading -->
<script type="text/javascript" src="js/jquery.js"></script>
<script type="text/javascript" src="js/jquery.easing-sooper.js"></script>

36 | P a g e
<script type="text/javascript" src="js/jquery.sooperfish.js"></script>
<script type="text/javascript" src="js/image_fade.js"></script>
<script type="text/javascript">
$(document).ready(function() {
$('ul.sf-menu').sooperfish();
});
</script>
</body>
</html>

6.2 USER HOME PAGE


user.jsp
<!DOCTYPE HTML>
<html>

<head>
<title>Hybrid Cloud</title>
<meta name="description" content="website description" />
<meta name="keywords" content="website keywords, website keywords" />
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<link rel="shortcut icon" type="image/x-icon"
href="images/brainstorming_alternative.png" />
<link rel="stylesheet" type="text/css" href="css/style.css" />
<!-- modernizr enables HTML5 elements and feature detects -->
<script type="text/javascript" src="js/modernizr-1.5.min.js"></script>
<script>
function validation() {
if (document.name.token.value == 0) {
alert('Enter your token');
document.name.token.focus();
return false;
}
}
</script>

<style>
form, h1 {
position: relative;
left: 350px;
}

#id {
width: 200px;
height: 25px;
background-color: #D5D5D5;
}

#but {
width: 60px;
height: 25px;
}
</style>
</head>

<body>
<%
if (request.getParameter("no") != null) {
out.println("<script>alert('your not having permission to do this...')</script>");

37 | P a g e
}
if (request.getParameter("status") != null) {
out.println("<script>alert('Your request sent to private cloud')</script>");
}
%>
<div id="main">
<header>
<div id="logo">
<div id="logo_text">
<!-- class="logo_colour", allows you to change the colour of the
text -->
<pre> <h2 style="color:black;">
Attribute Based Storage Supporting Secure Deduplication of Encrypted Data on Cloud
</h2>
</pre>
</div>
</div>
<nav>
<ul class="sf-menu" id="nav">

<li><a href="upload.jsp">Upload</a></li>
<li><a href="download.jsp">Download</a></li>

<li><a href="#"><img width="40" height="40"


src="images/user.png" alt="photo_two" /></a>
<ul>
<li><a href="index.html">Logout</a></li>

</ul></li>

</ul>
</nav>
</header>
<div id="site_content">

<div id="content">
<%
HttpSession user = request.getSession();
String uname = user.getAttribute("username").toString();
String name = user.getAttribute("name").toString();
%>
<h1>
Welcome ! <font style="color: tomato"> <%=name%></font>
</h1>
<div style="position: relative; left: 200px;">
<img src="images/hybrid.png" width="500" height="400"></img>
</div>

</div>
</div>
<footer>
<p></p>
</footer>
</div>
<p>&nbsp;</p>
<!-- javascript at the bottom for fast page loading -->
<script type="text/javascript" src="js/jquery.js"></script>
<script type="text/javascript" src="js/jquery.easing-sooper.js"></script>

38 | P a g e
<script type="text/javascript" src="js/jquery.sooperfish.js"></script>
<script type="text/javascript" src="js/image_fade.js"></script>
<script type="text/javascript">
$(document).ready(function() {
$('ul.sf-menu').sooperfish();
});
</script>
</body>
</html>

39 | P a g e
CHAPTER 07
OUTPUT SCREENS

40 | P a g e
7. OUTPUT SCREENS
7.1 HOME PAGE

Fig: 7.1 Home page

7.2 USER REGISTATION PAGE

Fig: 7.2 User Registration Page

41 | P a g e
7.3 USER LOGIN PAGE

Fig: 7.3 User Login Page

7.4 USER HOME PAGE

Fig: 7.4 User Home Page

42 | P a g e
7.5 FILE UPLOAD PAGE

Fig: 7.5 File Upload Page

7.6 BLOCK WISE SEPARATION OF UPLOADED FILE

Fig: 7.6 Block wise Separation of Uploaded File

43 | P a g e
7.7 FILE UPLOADED INTO THE CLOUD

Fig: 7.7 File Uploaded into the Cloud

7.8 ADMIN LOGIN PAGE

Fig: 7.8 Admin Login Page

44 | P a g e
7.9 ADMIN HOME PAGE

Fig: 7.9 Admin Home Page

7.10 UPLOADED FILE DATA

Fig: 7.10 Uploaded File Data

45 | P a g e
7.11 DOWNLOADED FILE DATA

Fig: 7.11 Downloaded File Data

46 | P a g e
CHAPTER 8
TESTING AND VALIDAYION

47 | P a g e
8 TESTING AND VALIDATION

8.1. TESTING
Software testing is a critical element of software quality assurance and represents the ultimate review
of specification, design and code generation.

8.1.1 TESTING OBJECTIVES


 To ensure that during operation the system will perform as per specification.
 TO make sure that system meets the user requirements during operation
 To make sure that during the operation, incorrect input, processing and output will be
detected
 To see that when correct inputs are fed to the system the outputs are correct
 To verify that the controls incorporated in the same system as intended
 Testing is a process of executing a program with the intent of finding an error
 A good test case is one that has a high probability of finding an as yet undiscovered
error
The software developed has been tested successfully using the following testing
strategies and any errors that are encountered are corrected and again the part of the program
or the procedure or function is put to testing until all the errors are removed. A successful test
is one that uncovers an as yet undiscovered error.
Note that the result of the system testing will prove that the system is working correctly.
It will give confidence to system designer, users of the system, prevent frustration during
implementation process etc.

8.2 TEST CASE DESIGN:

8.2.1 White box testing

White box testing is a testing case design method that uses the control structure of the
procedure design to derive test cases. All independents path in a module are exercised at least
once, all logical decisions are exercised at once, execute all loops at boundaries and within
their operational bounds exercise internal data structure to ensure their validity. Here the
customer is given three chances to enter a valid choice out of the given menu. After which the
control exits the current menu.

48 | P a g e
8.2.2 Black Box Testing

Black Box Testing attempts to find errors in following areas or categories, incorrect
or missing functions, interface error, errors in data structures, performance error and
initialization and termination error. Here all the input data must match the data type to
become a valid entry
The following are the different tests at various levels:

8.2.3 Unit Testing:

Unit testing is essentially for the verification of the code produced during the coding
phase and the goal is test the internal logic of the module/program. In the Generic code
project, the unit testing is done during coding phase of data entry forms whether the
functions are working properly or not. In this phase all the drivers are tested whether they
are rightly connected or not.

8.2.4 Integration Testing:

All the tested modules are combined into sub systems, which are then tested. The goal
is to see if the modules are properly integrated, and the emphasis being on the testing
interfaces between the modules. In the generic code integration testing is done mainly on
table creation module and insertion module.

8.2.5 Validation Testing


This testing concentrates on confirming that the software is error-free in all respects. All the
specified validations are verified and the software is subjected to hard-core testing. It also aims
at determining the degree of deviation that exists in the software designed from the
specification; they are listed out and are corrected.

8.2.6 System Testing


This testing is a series of different tests whose primary is to fully exercise the computer-based
system. This involves:
 Implementing the system in a simulated production environment and testing it.
 Introducing errors and testing for error handling.

49 | P a g e
8.3 TEST CASES

TEST CASE 1 :

Test case for Login form:


When a user tries to login by submitting an incorrect ID or an incorrect Password then it
displays an error message “NOT A VALID USER NAME”.

TEST CASE 2:

Test case for User Registration form:


When a user enters user id to register and ID already exists, then this result in displaying
error message “USER ID ALREADY EXISTS”.

TEST CASE 3:

Test case for Change Password:


When the old password does not match with the new password, then this results in
displaying an error message as “OLD PASSWORD DOES NOT MATCH WITH THE NEW
PASSWORD”.

TEST CASE 4:

Test case for Forget Password:


When a user forgets his password he is asked to enter Login name, ZIP code, Mobile
number. If these are matched with the already stored ones then user will get his Original
password.

TEST CASE 5:

Test case for Phone Number:


When a user tries to get registered by entering nine digits or some other alphabets, an
error message is popped up saying “ENTER VALID PHONE NUMBER”.

50 | P a g e
CHAPTER 09
CONCLUSION

51 | P a g e
9. CONCLUSION

Attribute-based encryption (ABE) has been widely used in cloud computing where data
providers outsource their encrypted data to the cloud and can share the data with users
possessing specified credentials. On the other hand, deduplication is an important technique to
save the storage space and network bandwidth, which eliminates duplicate copies of identical
data. However, the standard ABE systems do not support secure deduplication, which makes
them costly to be applied in some commercial storage services. In this paper, we presented a
novel approach to realize an attribute-based storage system supporting secure deduplication.
Our storage system is built under a hybrid cloud architecture, where a private cloud manipulates
the computation and a public cloud manages the storage. The private cloud is provided with a
trapdoor key associated with the corresponding cipher text, with which it can transfer the cipher
text over one access policy in to cipher texts of the same plaintext under any other access
policies without being aware of the underlying plaintext. After receiving a storage request, the
private cloud first checks the validity of the uploaded item through the attached proof. If the
proof is valid, the private cloud runs a tag-matching algorithm to see whether the same data
underlying the cipher text has been stored. If so, whenever it is necessary, it regenerates the
cipher text into a cipher text of the same plaintext over an access policy that is the union set of
both access policies. The proposed storage system enjoys two major advantages. Firstly, it can
be used to confidentially share data with other users by specifying an access policy rather than
sharing the decryption key. Secondly, it achieves the standard notion of semantic security while
existing deduplication schemes only achieve it under a weaker security notion.

52 | P a g e
REFERENCES
[1] D. Quick, B. Martini, and K. R. Choo, Cloud Storage Forensics. Syngress Publishing / Elsevier,
2014. [Online]. Available: http://www.elsevier.com/books/cloud-storageforensics/quick/978-0-12-
419970-5
[2] K. R. Choo, J. Domingo-Ferrer, and L. Zhang, “Cloud cryptography: Theory, practice and
future research directions,” Future Generation Comp. Syst., vol. 62, pp. 51–53, 2016.
[3] K. R. Choo, M. Herman, M. Iorga, and B. Martini, “Cloud forensics: State-of-the-art and future
directions,” Digital Investigation, vol. 18, pp. 77–78, 2016.
[4] Y. Yang, H. Zhu, H. Lu, J. Weng, Y. Zhang, and K. R. Choo, “Cloud based data sharing with
fine-grained proxy re-encryption,” Pervasive and Mobile Computing, vol. 28, pp. 122–134, 2016.
[5] D. Quick and K. R. Choo, “Google drive: Forensic analysis of data remnants,” J. Network and
Computer Applications, vol. 40, pp. 179– 193, 2014.
[6] A. Sahai and B. Waters, “Fuzzy identity-based encryption,” in Advances in Cryptology -
EUROCRYPT 2005, 24th Annual International
ConferenceontheTheoryandApplicationsofCryptographicTechniques, Aarhus, Denmark, May 22-
26, 2005, Proceedings, ser. Lecture Notes in Computer Science, vol. 3494. Springer, 2005, pp.
457–473.
[7] B. Zhu, K. Li, and R. H. Patterson, “Avoiding the disk bottleneck in the data domain
deduplication file system,” in 6th USENIX Conference on File and Storage Technologies, FAST
2008, February 2629, 2008, San Jose, CA, USA. USENIX, 2008, pp. 269–282.
[8] M. Bellare, S. Keelveedhi, and T. Ristenpart, “Message-locked encryption and secure
deduplication,” in Advances in Cryptology - EUROCRYPT 2013, 32nd Annual International
Conference on the Theory and Applications of Cryptographic Techniques, Athens, Greece, May
26-30, 2013. Proceedings, ser. Lecture Notes in Computer Science, vol. 7881. Springer, 2013, pp.
296–312.
[9] M. Abadi, D. Boneh, I. Mironov, A. Raghunathan, and G. Segev, “Message-locked encryption
for lock-dependent messages,” in Advances in Cryptology - CRYPTO 2013 - 33rd Annual
Cryptology Conference,SantaBarbara,CA,USA,August18-22,2013.Proceedings,
PartI,ser.LectureNotesinComputerScience,vol.8042. Springer, 2013, pp. 374–391.
[10] S. Keelveedhi, M. Bellare, and T. Ristenpart, “Dupless: Serveraided encryption for
deduplicated storage,” in Proceedings of the 22th USENIX Security Symposium, Washington, DC,
USA, August 14-16, 2013. USENIX Association, 2013, pp. 179–194.

53 | P a g e