Laxmi Report

CONTENTS
LIST OF FIGURE V
LIST OF TABLES VI
1 SYNOPSIS 1
1.1 PROJECT TITLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 PROJECT OPTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 INTERNAL GUIDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.4 SPONSORSHIP AND EXTERNAL GUIDE . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.5 TECHNICAL KEYWORDS (AS PER ACM KEYWORDS) . . . . . . . . . . . . . . . . . 1
1.6 PROBLEM STATEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.7 ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.8 GOALS AND OBJECTIVES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.9 RELEVANT MATHEMATICS ASSOCIATED WITH THE PROJECT SET THEORY . 3
1.10 NAMES OF CONFERENCES / JOURNALS WHERE PAPERS CAN BE PUBLISHED 5
1.11 REVIEW OF CONFERENCE/JOURNAL PAPERS SUPPORTING PROJECT IDEA . 5
1.12 PLAN OF PROJECT EXECUTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 TECHNICAL KEYWORDS 9
2.1 AREA OF PROJECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 TECHNICAL KEYWORDS: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 INTRODUCTION 10
3.1 PROJECT IDEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 MOTIVATION OF THE PROJECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 LITERATURE SURVEY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4 PROBLEM DEFINITION AND SCOPE 13

4.1 PROBLEM STATEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1 Goals and objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.2 Statement of scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
I
4.2 MAJOR CONSTRAINTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3 METHODOLOGIES OF PROBLEM SOLVING AND EFFICIENCY ISSUES . . . . . . . 14
4.4 OUTCOME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5 APPLICATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.6 HARDWARE RESOURCES REQUIRED . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.7 SOFTWARE RESOURCES REQUIRED . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5 PROJECT PLAN 17
5.1 PROJECT ESTIMATES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.1 RECONCILED ESTIMATES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.2 PROJECT RESOURCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2 RISK MANAGEMENTW.R.T. NP HARD ANALYSIS . . . . . . . . . . . . . . . . . . . 19
5.2.1 RISK IDENTIFICATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.2 Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.3 PROJECT SCHEDULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3.1 Project task set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3.2 Task network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3.3 Timeline Chart: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3.4 Overall project planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.4 TEAM ORGANIZATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.4.1 Team structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.4.2 Management reporting and communication . . . . . . . . . . . . . . . . . . . . . . 25
6 SOFTWARE REQUIREMENT SPECIFICATION 27

6.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1.1 Purpose and Scope of Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2 USAGE SCENARIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2.1 User profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2.2 Use Case View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2.3 USE CASE DIAGRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.3 DATA MODEL AND DESCRIPTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.4.1 Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.4.2 Activity Diagram: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.4.3 Non Functional Requirements: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.4.4 State Diagram: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.4.5 Design Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.4.6 Software Interface Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
GSMCOE,DEPARTMENT OF COMPUTER ENGINEERING 2016 II

7 DETAILED DESIGN DOCUMENT USING APPENDIX A AND B 37
7.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.2 ARCHITECTURAL DESIGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.3 COMPOENT DESIGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.3.1 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8 PROJECT IMPLEMENTATION 40
8.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.2 TOOLS AND TECHNOLOGIES USED . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.3 METHODOLOGIES/ALGORITHM DETAILS . . . . . . . . . . . . . . . . . . . . . . . . 42
9 SOFTWARE TESTING 44
9.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.1.1 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.1.2 Integration Testing: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.1.3 White Box Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.1.4 Black Box Testing: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.2 TEST CASES AND TEST RESULTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
10 RESULTS 48
10.1 SCREEN SHOTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
10.2 OUTPUTS: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
11 DEPLOYMENT AND MAINTENAN 53

11.1 INSTALLATION AND UN-INSTALLATION . . . . . . . . . . . . . . . . . . . . . . . . . 53
11.2 USER HELP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
12 CONCLUSION AND FUTURE SCOPE 54

List of Figures
1.1 Plan of Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1 Project plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.2 Task sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3 Gantt chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1 Use case Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.2 USE CASE DIAGRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.3 Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.4 Activity Diagram 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.5 Activity Diagram 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.6 State Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.1 Architectural Design Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7.2 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.1 Black Box Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1 Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
10.2 Update Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.3 Download File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
10.4 Share Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
10.5 Upload File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
10.6 Revoke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
10.7 View File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
10.8 Access Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
12.1 Black Box Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

12.2 PLAGIARISM REPORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
12.3 Venn Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
IV
12.4 Open stack functional Dependency Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
12.5 Proposed system Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
List of Tables
1.1 Table For Project Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Risk Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.2 Risk Probability definitions [?] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3 Task sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1 TEST CASES AND TEST RESULTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

9.2 Crossover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.3 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.4 Indexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.5 File Upload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.6 File send . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
12.1 Table For Project plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Chapter 1
SYNOPSIS
1.1 PROJECT TITLE
Cost-Effective Authentic and Anonymous Data Sharing with Forward Security
1.2 PROJECT OPTION
Our project is Internal project
1.3 INTERNAL GUIDE
Internal Guide is Prof. Ashok Kumar
1.4 SPONSORSHIP AND EXTERNAL GUIDE
Project is only Internal project
1.5 TECHNICAL KEYWORDS (AS PER ACM KEYWORDS)
KEYWORDS:
• Anonymity,
• Authenticity,
• Security,
1
COST EFFECTIVE AUTHENTIC AND ANONYMOUS DATA SHARING WITH FORWARD
SECURITY
• Encryption based services ,
• Encryption techniques.
1.6 PROBLEM STATEMENT
• We are basically concerned with the development of application that makes publisher and sub-
scriber without broker to communicate and encrypt data to subscriber whereas subscriber get this
data and privet key by message and he will decrypt it. Existing system is Broker based One to
One Subsystem.
• Forward security technique is built in which Fully-TTP(Trusted Third Party) is used
• Elgamal and SHA 256 Security Algorithms are used.
• Revocation is obtained in the system.
1.7 ABSTRACT
For providing security mechanisms in, we leverage the principles of identity-based encryption to sup-
port many-to-many interactions between subscribers and publishers. Although we subsequently demon-
strate the implementation of our security methods in terms of a concrete variant called attribute-based
encryption, it is important to remark that our approach also benefits from other identity-based encryp-
tion schemes. In our approach, publishers and subscribers interact with a key server. They provide
credentials to the key server and in turn receive keys which fit the expressed capabilities in the cre-
dentials. Subsequently, those keys can be used to encrypt, decrypt, and sign relevant messages in the
content based pub/sub system, i.e., the credential becomes authorized by the key server. A credential
consists of two parts: a binary string which describes the capability of a peer in publishing and receiving
events, and 2) a proof of its identity. The latter is used for authentication against the key server and
verification whether the capabilities match the identity of the peer. While this can happen in a variety of
ways, for example, relying on challenge response, hardware support, and so on, we pay attention mainly
at expressing the capabilities of a credential, i.e., how subscribers and publishers can create a credential.
This process needs to account for the many possibilities to partition the set of events expressed by an
advertisement or subscription and exploits overlaps in subscriptions and publications. Subsequently, we
GSMCOE,DEPARTMENT OF COMPUTER ENGINEERING 2016 2

SECURITY
use the term credential only for referring to the capability string of a credential. The keys assigned
to publishers and subscribers, and the cipher texts, are labeled with credentials. In particular, the
identity-based encryption ensures that a particular key can decrypt a particular cipher text only if there
is a match between the credentials of the ciphertext and the key. Publishers and subscribers maintain
separate private keys for each authorized credential.
1.8 GOALS AND OBJECTIVES
We are basically concerned with the development of application that makes publisher and subscriber
without broker to communicate and encrypt data to subscriber whereas subscriber get this data and
privet key by message and he will decrypt it. The project objectives are:
1Encrypt the data which we want to send using the key and send it register users , users must register
to the server.
2. Receiver is getting data in encrypted format and also he get the privet key by message. Using this
privet key he decrypts the data .
3. Receiver can download the encrypted data.

The project Goals are:
• Save a great of time and computation in Authentication.
• High level data Security.
• Large scale secure data sharing system.
1.9 RELEVANT MATHEMATICS ASSOCIATED WITH THE

PROJECT SET THEORY
SET THEORY
Mathematical Model:
Lets,
D is denoted by dataset which includes the n number of paragraphs in file
D= Ci1,Ci2,Ci3..Cin
Here, C is the intermediate module which holds the data processing for security as well as data privacy.
C= C1,C2,C3Cn

SECURITY
C1= key generation

C2= encryption of data
C3= Authentication and TTP verification phase
C4 = decryption of data
C5=Revocation phase
C6=Resign key generation
Here R is web base approach which handles the parallel searching, the result of query
classified into n number of result pages. All R instances might be virtual machine on cloud which will
holds the data and when intermediate module generate the requirement it will execute parallel.
R= R1,R2,R3.Rn
When solving problems we have to decide the difficulty level of our problem. There are three types
of classes provided for that. These are as follows:
1) P Class
2) NP-hard Class
3) NP-Complete Class
P Informally the class P is the class of decision problems solvable by some algorithm within a number of
steps bounded by some fixed polynomial in the length of the input. Turing was not concerned with the ef-
ficiency of his machines, but rather his concern was whether they can simulate arbitrary algorithms given
sufficient time. However it turns out Turing machines can generally simulate more efficient computer
models (for example machines equipped with many tapes or an unbounded random access memory) by
at most squaring or cubing the computation time. Thus P is a robust class and has equivalent definitions
over a large class of computer models. Here we follow standard practice and define the class P in terms
of Turing machines.
NP-hard A problem is NP-hard if solving it in polynomial time would make it possible to solve all
problems in class NP in polynomial time. Some NP-hard problems are also in NP (these are called ”NP-
complete”), some are not. If you could reduce an NP problem to an NP-hard problem and then solve it
in polynomial time, you could solve all NP problems. Also, there are decision problems in NP-hard but
are not NP-complete, such as the infamous halting problem
NP-complete A decision problem L is NP-complete if it is in the set of NP problems so that any

given solution to the decision problem can be verified in polynomial time, and also in the set of NP-hard
problems so that any NP problem can be converted into L by a transformation of the inputs in polyno-
mial time.
The complexity class NP-complete is the set of problems that are the hardest problems in NP, in the
sense that they are the ones most likely not to be in P. If you can find a way to solve an NP-complete

SECURITY
problem quickly, then you can use that algorithm to solve all NP problems quickly.
1.10 NAMES OF CONFERENCES / JOURNALS WHERE

PAPERS CAN BE PUBLISHED
International Journal of Innovative Research in Computer and Communication Engineering
1.11 REVIEW OF CONFERENCE/JOURNAL PAPERS SUP-

PORTING PROJECT IDEA
Public key techniques are absolutely necessary to make password systems secure against offline dictionary
attacks, whereas the involvement of public key cryptosystems under a PKI (e.g., public key encryption
and digital signature schemes) is not essential. There are two separate approaches to the development
of secure pass-word systems one is a combined use of a password and public key cryptosystem under
a PKI and the other is a password only approach. In these systems, the use of public keys entails
the deployment and maintenance of a PKI for public key certification and adds to users the burden of
checking key validity. To eliminate this drawback, password-only protocols (password authenticated key
exchange or ) have been extensively studied. The protocols do not involve any public key cryptosystem
under a PKI and, therefore, are much more attractive for real world applications. Any use of public key
cryptosystem under a PKI in a password authentication system should be avoided since; otherwise, the
benefits brought by the use of password would be counteracted to a great extent. Most of the existing
password systems were designed over a single server, where each user shares a password or some password
verification data (PVD) with a single authentication server. These systems are essentially intended to
defeat offline dic-tionary attacks by outside attackers and assume that the sever is completely trusted in
protecting the user password database.
We propose a fully functional identity-based encryption scheme (IBE). The scheme has chosen ciphertext
security in the random oracle model assuming a variant of the computational DiffieHellman problem.
Our system is based on bilinear maps between groups. The Weil pairing on elliptic curves is an example
of such a map. We give precise definitions for secure identity based encryption schemes and give several
applications for such systems.
In an attribute-based encryption (ABE) scheme, a ciphertext is associated with an ’-bit public index
ind and a message m, and a secret key is associated with a Boolean predicate P. The secret key allows
to decrypt the ciphertext and learn m iff P(ind) = 1. Moreover, the scheme should be secure against
collusions of users, namely, given secret keys for polynomially many predicates, an adversary learns
nothing about the message if none of the secret keys can individually decrypt the ciphertext.

SECURITY
We present attribute-based encryption schemes for circuits of any arbitrary polynomial size, where the
public parameters and the ciphertext grow linearly with the depth of the circuit. Our construction is
secure under the standard learning with errors (LWE) assumption. Previous constructions of attribute-
based encryption were for Boolean formulas, captured by the complexity class NC1. In the course
of our construction, we present a new framework for constructing ABE schemes. As a by-product of
our framework, we obtain ABE schemes for polynomial-size branching programs, corresponding to the
complexity class LOGSPACE, under quantitatively better assumptions.
SOME REFERENCES
[1] E. Anceaume, M. Gradinariu, A.K. Datta, G. Simon, and A. Virgillito, A Semantic Overlay for
Self- Peer-to-Peer Publish/ Subscribe, Proc. 26th IEEE Intl Conf. Distributed Computing Systems
(ICDCS), 2006.
[2] J. Bacon, D.M. Eyers , J. Singh, and P.R. Pietzuch, ”Access Control in Publish Subscribe Sys-
tems,” Proc. Second ACM Intl Conf. Distributed Event-Based Systems (DEBS), 2008.
[3] W.C. Barker and E.B. Barker, SP 800-67 Rev. 1. Recommendation for the Triple Data Encryption
Algorithm (TDEA) Block Cipher, technical report, Natl Inst. of Standards and Technology, 2012.
[4] J. Bethencourt, A. Sahai, and B. Waters, Ciphertext-Policy Attribute-Based Encryption, Proc.

IEEE Symp. Security and Privacy, 2007.
[5] D. Boneh, G.D. Crescenzo, R. Ostrovsky, and G. Persiano, Public Key Encryption with Keyword
Search, Proc. Intl Conf. Theory and Applications of Cryptographic Techniques on Advances in Cryp-
tology (EUROCRYPT), 2004.
1.12 PLAN OF PROJECT EXECUTION
The statement of how and when a projects objective are to be achieved by showing the major products,
milestones, activities and resources required on the project. A project plan according to the project
management body of knowledge is a formal approve document used to guide both project execution and
project control. The primary use of the project plan are document planning assumption and decisions,
facilitate communication among stakeholders, are document approved scope, cost and schedule baselines.

SECURITY
Figure 1.1: Plan of Project

SECURITY
Table 1.1: Table For Project Schedule

Chapter 2
TECHNICAL KEYWORDS
2.1 AREA OF PROJECT
The Project Area is depends on our Data Security Domain
2.2 TECHNICAL KEYWORDS:
• Anonymity,
• Authenticity,
• Security,
• Encryption based services ,
• Encryption techniques,
• Elgamal algorithm,
• SHA -256 algorithm,
• private key ,
• Ring signature.
9
Chapter 3
INTRODUCTION
3.1 PROJECT IDEA
privet key by message and he will decrypt it.
3.2 MOTIVATION OF THE PROJECT
• In the existing having lot of data security issues on server as well client level.
• Multiple key dependency problem is another issue.
• Certificate verification dependency.
• All the problems having in existing system. So, we develop a system which will provide a data
security with minimum execution time and less requirement of resources in ring topology.
3.3 LITERATURE SURVEY
Review of paper:-
Public key techniques are absolutely necessary to make password systems secure against offline
dictionary attacks, whereas the involvement of public key cryptosystems under a PKI (e.g., public key
encryption and digital signature schemes) is not essential. There are two separate approaches to the de-
velopment of secure pass-word systems one is a combined use of a password and public key cryptosystem
under a PKI and the other is a password only approach. In these systems, the use of public keys entails
the deployment and maintenance of a PKI for public key certification and adds to users the burden of
checking key validity. To eliminate this drawback, password-only protocols (password authenticated key
10
SECURITY
exchange or ) have been extensively studied. The protocols do not involve any public key cryptosystem
under a PKI and, therefore, are much more attractive for real world applications. Any use of public key
cryptosystem under a PKI in a password authentication system should be avoided since; otherwise, the
benefits brought by the use of password would be counteracted to a great extent. Most of the existing
password systems were designed over a single server, where each user shares a password or some password
verification data (PVD) with a single authentication server. These systems are essentially intended to
defeat offline dic-tionary attacks by outside attackers and assume that the sever is completely trusted in
protecting the user password database.
Unfortunately, attackers in practice take on a variety of forms, such as hackers, viruses, worms, acci-
dents, misconfigurations, and disgruntled system administrators. As a result, no security measures and
precautions can guarantee that a system will never be penetrated. Once an authentication server is com-
promised, all the user passwords or PVD fall in the hands of the attackers, who are definitely effective
in offline dictionary attacks against the user passwords. To eliminate this single point of vulnerability
inherent in the single-server systems, password systems based on multiple servers were proposed. The
principle is distributing the password database as well as the authentication function to multiple servers
so that an attacker is forced to compromise several servers to be successful in offline dictionary attacks.
The system in D. Boneh and M. Franklin protocol, believed to be the first multi-server password system,
splits a password among multiple servers. However, the servers in D. Boneh and M. Franklin protocol
need to use public keys. An improved version of D. Boneh and M. Franklin protocol was proposed in D.
Boneh, The Decisional Diffie-Hellman Problem, protocol, which eliminates the use of public keys by the
servers.
Further and more rigorous extension were due to V. Boyko, P. Mackenzie, and S. Patel protocol,
where the former built a t-out of-n threshold protocol and provided a formal security proof under the
random oracle model D. Boneh and M. Franklin, Identity Based Encryption from the Weil Pairing,
and the latter presented two provably secure threshold protocols under the standard model. While the
protocols are theoretically significant, they have low efficiency and high operational overhead. In these
multi-server password systems, either the servers are equally exposed to the users or a user has to com-
municate in parallel with several or all servers for authentication, or a gateway is introduced between
the users and the servers. Recently, Brained et al. proposed a password system in which one server
exposes itself to users and the other is hidden from the pub-lic. While this setting is interesting, it is not
a password-only system: Both servers need to have public keys to protect the communication channels
from users to servers. As we have stressed earlier, this makes it difficult to fully en-joy the benefits of
a password system. In addition, the system in M. Abdalla and D. Pointcheval protocol only performs
unilateral authentication and relies on the Secure Socket Layer (SSL) to establish a session key between
a user and the front-end server. Subsequently, Yang et al. extended and tailored this system to the
context of federated enterprises, where the back-end server is managed by an enterprise headquarters

SECURITY
and each affiliating organization operates a front-end server. An improvement made in Yang is that
only the back-end server holds a public key Nevertheless, the system in Yang is still not a password-only
system.
Description:- In several distributed systems a user should only be able to access data if a user posses
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 paper we
present a system for realizing complex access control on encrypted data that we call Ciphertext 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 users keys; while in our system attributes are used to describe a users 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.
We propose a fully functional identity-based encryption scheme (IBE). The scheme has chosen ci-
phertext security in the random oracle model assuming a variant of the computational DiffieHellman
problem. Our system is based on bilinear maps between groups. The Weil pairing on elliptic curves is an
example of such a map. We give precise definitions for secure identity based encryption schemes and give
several applications for such systems. In an attribute-based encryption (ABE) scheme, a ciphertext is
associated with an ’-bit public index ind and a message m, and a secret key is associated with a Boolean
predicate P. The secret key allows to decrypt the ciphertext and learn m iff P(ind) = 1. Moreover, the
scheme should be secure against collusions of users, namely, given secret keys for polynomially many
predicates, an adversary learns nothing about the message if none of the secret keys can individually
decrypt the ciphertext.
We present attribute-based encryption schemes for circuits of any arbitrary polynomial size, where
the public parameters and the ciphertext grow linearly with the depth of the circuit. Our construc-
tion is secure under the standard learning with errors (LWE) assumption. Previous constructions of
attribute-based encryption were for Boolean formulas, captured by the complexity class NC1. In the
course of our construction, we present a new framework for constructing ABE schemes. As a by-product
of our framework, we obtain ABE schemes for polynomial-size branching programs, corresponding to the
complexity class LOGSPACE, under quantitatively better assumptions.

Chapter 4
PROBLEM DEFINITION AND SCOPE
4.1 PROBLEM STATEMENT
• Encrypt the data which we want to send using the key and send it register users , users must
register to the server.
• Receiver is getting data in encrypted format and also he get the privet key . Using this privet key
he decrypts the data .
• Receiver can generate the encrypted data.
4.1.1 Goals and objectives
privet key and he will decrypt it. The project objectives are:
1.Encrypt the data which we want to send using the key and send it register users , users must register
to the server.
2. Receiver is getting data in encrypted format and also he get the privet key by SMS on his mobile
. Using this privet key he decrypts the data .
3. Receiver can download the encrypted data.

The project Goals are:
• Save a great of time and computation in Authentication.
• High level data Security.
• Large scale secure data sharing system.
13
SECURITY
4.1.2 Statement of scope
The pub/sub overlay proposed is similar to DPS system with modifications to ensure subscription con-
fidentiality. In this paper, we, therefore, evaluate performance and scalability of the proposed pub/sub
system only with respect to the security mechanisms and omit other aspects. In particular, we evaluate
the performance of our system the overlay construction time and the event dissemination delays. We
measure the average delay experienced by each subscriber to connect to a suitable position in an attribute
tree. Delay is measured from the time a subscriber sends connection request message to a random peer
in the tree till the time the connection is actually established. The evaluations are performed only for
a single attribute tree. It shows that the average connection time (delay) increases with the number of
peers in the system because of the increase in the height of the attribute tree (each new hop increases
the network delay as well as time to apply security methods).
4.2 MAJOR CONSTRAINTS
• The product has been developed using JAVA.
• J2SE (Java 2 Standard Edition) Java would be the required as language for development of the
project.AWT and SWINGS are used for GUI design.
• Programming is done in NetBeans..
• Database using mysql.
4.3 METHODOLOGIES OF PROBLEM SOLVING AND EF-

FICIENCY ISSUES
The feasibility of the project is analyzed in this phase and business proposal is put forth with a very
general plan for the project and some cost estimates. During system analysis the feasibility study of the
proposed system is to be carried out. This is to ensure that the proposed system is not a burden to
the company. For feasibility analysis, some understanding of the major requirements for the system is
essential.
4.4 OUTCOME
A Cost Effective Authentic and Anonymous Data Shearing System with a Forward Security.

SECURITY
4.5 APPLICATIONS
MD5 digests have been widely used in the software world to provide some assurance that a transferred
file has arrived intact. For example, file servers often provide a pre-computed MD5 (known as Md5sum)
checksum for the files, so that a user can compare the checksum of the downloaded file to it. Most unix
based operating systems include MD5 sum utilities in their distribution packages; Windows users may in-
stall a Microsoft utility, or use third-party applications. Android ROMs also utilize this type of checksum.
Figure 4.1: Hardware Requirements
However, now that it is easy to generate MD5 collisions, it is possible for the person who created
the file to create a second file with the same checksum, so this technique cannot protect against some
forms of malicious tampering. Also, in some cases, the checksum cannot be trusted (for example, if
it was obtained over the same channel as the downloaded file), in which case MD5 can only provide
error-checking functionality: it will recognize a corrupt or incomplete download, which becomes more
likely when downloading larger files.
MD5 can be used to store a one-way hash of a password, often with key stretching. Along with other
hash functions, it is also used in the field of electronic discovery, in order to provide a unique identifier
for each document that is exchanged during the legal discovery process. This method can be used to
replace the Bates stamp numbering system that has been used for decades during the exchange of paper
documents.

SECURITY
4.6 HARDWARE RESOURCES REQUIRED
• Processor:- Intel Pentium 4 or above
• Memory:- 512 MB or above
• Other peripheral:- Printer
• Hard Disk:- 10gb
4.7 SOFTWARE RESOURCES REQUIRED
Front End
• Jdk 1.7.0
• Netbeans 7.4
• Internet Explorer 6.0/above
Back-End
• Mysql 5.1
Services
• Amazon EC2 for cloud Communication Interface
We use TCP/IP protocol for establishing connection and transmitting data over the network. We
use Ethernet for LAN.

Chapter 5
PROJECT PLAN
5.1 PROJECT ESTIMATES
The total estimate is calculated in person months, which can easily be converted to other units of effort
using the following conversion factors:
1 Person Days/Person Month

Effort levels are based on a relative distribution factor - they determine how much of the task group
estimate will be distributed to each individual task. The mathematical formula to calculate the hours
estimate for each task in a task group based on the effort level for each task is:
Task Hours Estimate = employee Hours Estimate * (Task Effort Level/employee Effort)
5.1.1 RECONCILED ESTIMATES
The completed project may significantly differ from the planned tasks and projected conditions upon
which the initial estimate was based. The initial estimate must be adjusted to account for these differ-
ences if a meaningful comparison between the estimate and the actual project effort is be established.
The purpose of the Reconciliation Advisor is to recalculate the estimated effort using the actual statistics
and results from the completed project. The Reconciliation Advisor gathers actual project data through
a question and answer process similar to that used when the system requirements were gathered for the
initial estimate. The questions differ only in that the past tense is used: ”Did the application replace a
mission critical or line of business process?” instead of Does the application replace a mission critical or
line of business process?”.
17
SECURITY
COST ESTIMATE
Function Point Analysis is to evaluate a system’s capabilities from a user’s point of view. To achieve
this goal, the analysis is based upon the various ways users interact with computerized systems. From a
user’s perspective a system assists them in doing their job by providing five basic functions.
5.1.2 PROJECT RESOURCES
A Bar Chart,is perhaps the simplest form of formal management. The bar chart is used almost exclu-
sively for scheduling purposes and therefore controls only the time dimension of projects.(developed by
Henry L.Gantt) are a project control technique that can be used for several purposes, including schedul-
ing, budgeting and resources planning. The length of each bar is proportional to the length of the time
planned for the activity. A Gantt chart helps in scheduling the activities of a project, but it does not
help in identifying them. One can begin with the activities identified in the work breakdown structure,
as we did for thecompiler example. During the scheduling activity, and also during implementation of
the project, new activities may be identified that were not envisioned during the initial planning.
Overall project planning
Table of overall project planning
Figure 5.1: Project plan

SECURITY
5.2 RISK MANAGEMENTW.R.T. NP HARD ANALYSIS
When solving problems we have to decide the difficulty level of our problem. There are three types of
classes provided for that. These are as follows:
5.2.1 RISK IDENTIFICATION
Schedule Risk
Project schedule get slip when project tasks and schedule release risks are not addressed properly.
Schedule risks mainly affect the project and may lead to project failure.
Schedules often slip due to following reasons:
• Wrong time estimation
• Resources are not tracked properly.
• Failure to identify complex functionalities and time required to develop those functionalities.
• Unexpected project scope expansions
Budget Risk:
• Wrong budget estimation.
• Cost overruns
• Project scope expansion
Operational Risk:
Causes of Operational risks:
• Failure to address priority conflicts
• Failure to resolve the responsibilities
• Insufficient resources
• No proper subject training

SECURITY
• No resource planning
• No communication in team.
Technical Risk:
Technical risks generally lead to failure of functionality and performance.

Causes of technical risks are:
• Continuous changing requirements
• Product is complex to implement.
• Difficult project modules integration.
Programmatic Risk
These are the external risks beyond the operational limits. These are all uncertain risks are outside
the control of the program.
These external events can be:
• Running out of fund.
• Market development
• Government rule changes.
Project Risks
Initially applications have similar threats, vulnerabilities and risks to those posed by typical web
and client/server applications. That said, because users have the power and ability to download
whatever they wish and manage their devices to their liking, we need to think about these top five
risks and how to mitigate them:
1. Inherent, Blind Trust
App stores come pre-installed on our mobile devices and provide access to a ton of mobile appli-
cations. We blindly trust that the app stores have performed due diligence on the apps in their
stores. Yet, in reality, app store vendors lack the cycles to ensure that the apps they make available
won’t open up our employees/users to risks that can harm the business.
2. Functional Risks
Opening, editing, sending, receiving and e-mailing documents; syncing backups; checking in to my
current location; etc. - these are a tiny subset of tasks that I can complete with my devices. But
what happens if I open a PDF from my business e-mail into a PDF viewer that I downloaded?

SECURITY
Suppose I then sync that document to the PDF viewer? At this point, my potentially sensitive
document is being managed by someone else’s application (probably insecure application and sync
storage), and it is completely outside of my control. How about if I check in to my current location
via Facebook or Foursquare? Due to the sensitive nature of what I do, some of my clients don’t
want others to know I am working for them, But if I ”check in,” the whole world (literally) becomes
aware of where I am.
3. Malware
Malware has forever been a problem in the IT world, and it is no different in the mobile sphere.
Malware can wreak havoc by stealing sensitive data, monitoring traffic, connecting to internal
networks and infecting internal machines. And that’s just for starters. Malware will continue to
evolve in apps from app stores, and attackers will continue to refine their approaches to malfeasance.
4. Root Applications
Rooting and jail breaking are commonplace. Users or attackers run exploits against the mobile
operating system to provide them with unfettered access to the file system and allow them to be
the ”root” user of the operating system. Some users appreciate the freedoms that having root
access gives them. Root access also provides a gateway to other app stores, such as Cydia, or the
ability to download applications from untrusted sources. The applications running as root deliver
functional and malware risks to the business. In some cases, the functional/malware line starts to
get fuzzy with the root applications because, typically, the applications provide more functionality
than the typical non-root applications provide.
5. Inappropriate Applications
Clearly, not all applications are appropriate in the workplace, and I’ll leave it to your imagination
to classify which ones would be classified as Not Safe For Work.
The number of mobile applications has gone from zero to 1.5 million in a little more than four
years, and it will continue to grow in quantum leaps. As the mobile app world continues to evolve,
so will the risks. In next month’s posting, I will discuss how to address each of these risks and
provide specifics on how to thwart them
5.2.2 Risk Analysis
The risks for the Project can be analyzed within the constraints of time and quality

SECURITY
Table 5.1: Risk Table
Table 5.2: Risk Probability definitions [?]
5.3 PROJECT SCHEDULE
5.3.1 Project task set
Major Tasks in the Project stages are:
Table 5.3: Task sheet

SECURITY
Figure 5.2: Task sheet
5.3.2 Task network
5.3.3 Timeline Chart:
A Bar Chart,is perhaps the simplest form of formal management. The bar chart is used almost ex-
clusively for scheduling purposes and therefore controls only the time dimension of projects.(developed
by Henry L.Gantt) are a project control technique that can be used for several purposes, including
scheduling, budgeting and resources planning. The length of each bar is proportional to the length of
the time planned for the activity. A Gantt chart helps in scheduling the activities of a project, but it
does not help in identifying them. One can begin with the activities identified in the work breakdown
structure, as we did for thecompiler example. During the scheduling activity, and also during implemen-
tation of the project, new activities may be identified that were not envisioned during the initial planning.

SECURITY
Gantt Chart
Figure 5.3: Gantt chart
5.3.4 Overall project planning

SECURITY
5.4 TEAM ORGANIZATION
5.4.1 Team structure
The manner in which group is organized and the mechanisms for reporting are noted. We are team of 3
People / Group Members.
5.4.2 Management reporting and communication
Mechanisms for progress reporting and inter team communication are identified as per assessment sheet
and lab time table. We are team of 3 People / Group Members and reported about progress report to
our guidance teacher.

SECURITY

Chapter 6
SOFTWARE REQUIREMENT
SPECIFICATION
6.1 INTRODUCTION
Our Application Secure broker less pub/sub system using identity based encryption is basically Im-
plemented using J2SE as a frontend. Java2SE consists of a virtual machine, which must be used to run
Java programs, together with a set of libraries (or packages) needed to allow the use of file systems,
networks, graphical interfaces, and so on, from within those programs. The task of web data extraction
performed by a system is usually divided into five different functions:
1)User login
2)Sharing
i)Browse data
ii)Key Generation
iii)Encryption
iv)Show data.
3)Accessing
i)Select user
ii)Select file
iii)Decrypt
iv)Download
v)Show Encryption
vi)Show Decryption
4)Dashboard
5)Analysis
i)Encryption Performance
ii)Decryption Performance
1. User Login:
27
SECURITY
User login accepts the user credentials like sign up and login;
2. Sharing:
Through sharing interface we can browse the data which we want to sent, for that we can generate
the encryption key. By using this key we can encrypt the data ,using show data option we can see
encrypted data. Also we can select the user which we want to sent the data and by send button we sent
the encrypted data to selected user.
3. Accessing:
Through the accessing interface form we can select the user from we get the file of data and select
the file. By get private key we get the private key by SMS on mobile. After the entering the private
key decrypt the data. Here we can see also encrypted data and see the decrypted data. We can also
download the data through the download button.
4. Dashboard:
In the dashboard user can view the file which it has sent.
5. Analysis:
In analysis we can view the performance of encryption and decryption of our proposed system. The
graph of execution time of various algorithm approach is represented. In this user can view Encryption
performance and Decryption performance of our system.
6.1.1 Purpose and Scope of Document
In old system user requires the authentication and that was provided by the broker and also the key
management was big problems . to overcome this problem we design the secure broker less pub/sub
system which give the access to those users which are registered with the server. At the time of encryption
the get the encryption key and also at the time of decryption the will get the privet key.
OVERVIEW OF RESPONSIBILITIES OF DEVELOPER
Application developers use programming languages and source code to create software that meets
client requirements. Developers may work with multiple programming languages and operating systems.
The roles and responsibilities that people can assume in the project are based on merit. Everybody can
help no matter what their role.
Developers are the people who write code or documentation patches or contribute positively to the
project in other ways. A developers contribution is always recognized. In source code, all developers
who contribute to a source file may add their name to the list of authors for that file.

SECURITY
6.2 USAGE SCENARIO
This section provides various usage scenarios for the system to be developed.
6.2.1 User profiles
The profiles of all user categories are described here.
• User: Accesses the Data.
• Data Owner: Providing Data to user with high Security.
• TTP: Apply 2nd level Security with the help of SHA 256
6.2.2 Use Case View
USE-CASES TABLE
Figure 6.1: Use case Table

SECURITY
Figure 6.2: USE CASE DIAGRAM
6.2.3 USE CASE DIAGRAM
6.3 DATA MODEL AND DESCRIPTION
A data flow diagram is graphical tool used to describe and analyze movement of data through a system.
These are the central tool and the basis from which the other components are developed. The transfor-
mation of data from input to output, through processed, may be described logically and independently
of physical components associated with the system.
These are known as the logical data flow diagrams. The physical data flow diagrams show the actual
implements and movement of data between people, departments and workstations. A full description
of a system actually consists of a set of data flow diagrams. Using two familiar notations Yourdon,
Gane and Sarson notation develops the data flow diagrams. Each component in a DFD is labeled with a
descriptive name. Process is further identified with a number that will be used for identification purpose.
The development of DFDS is done in several levels. Each process in lower level diagrams can be broken

SECURITY
down into a more detailed DFD in the next level. The lop-level diagram is often called context diagram.
It consists a single process bit, which plays vital role in studying the current system. The process in the
context level diagram is exploded into other process at the first level DFD.
The idea behind the explosion of a process into more process is that understanding at one level of
detail is exploded into greater detail at the next level. This is done until further explosion is necessary
and an adequate amount of detail is described for analyst to understand the process.
6.4
6.4.1 Data Flow Diagram
Figure 6.3: Data Flow Diagram

SECURITY
6.4.2 Activity Diagram:
An activity diagram is used for modelling the dyamic features of a system. An Activity diagram consists
of flowchart,which shows the flow of control from one activity to another activity.
Figure 6.4: Activity Diagram 1
The Activity diagram represents the steps taken.

SECURITY
Figure 6.5: Activity Diagram 2
6.4.3 Non Functional Requirements:
User have to provide valid username and password as an input. In processing part validation for id and
password is done. If it is the new user he have to provide all his details, which will include Name, Phone
No, Email-id, Password, username.
: User have to provide valid privet key. For this case there should be a browser through which user
can copy the data or refer the Data.
The functional requirement for this is the file name specified by the user must be appropriate. There
should be proper net connection available.
This one shouldnt come as a surprise. Quality software has to be fast. Or at least feel fast. As
a front-end guy, this is the one I always feel first. Its not fast enough is a battle I never want to get
into. I had this reported as a bug against one of my projects, but the client wouldnt specify what fast

SECURITY
enough was; talk about moving goalposts. When you think about an app being performant, thing about
specifying the following:
1. Response times
How long should your app take to load? What about screen refresh times or choreography?
Processing times
Can I get as spinning beachball please? How long is acceptable to perform key functions or export /
import data?
Query and Reporting times This could be covered off with general reporting times, but if youre
providing an API you should probably consider acceptable query times too.
. Throughput Think about how many transactions your system needs to handle. A thousand a day? A
million? When Amazon solved this for their needs, they decoupled systems and created a queue service
that became the foundation of AWS.
Storage How much data are you going to need to store to do the awesomeness you need it to do?
Growth Requirements
This is a tough one, because truly you dont know how popular your app is going to be until its out
there. But you can bet (or hope) that someone has made predictions about how wildly successful your
app is going to be. Be wary of over engineering here, but at least make sure you arent constantly laying
down track in front of a moving train
Hours of operation
When does your app need to be available? If you need to do a database upgrade or a system backup,
can you take the system offline while you do it?
Locations of operation
A few things to think about here: Geographic location, connection requirements and the restrictions
of a local network prevail. If you are building a killer app for use behind the corporate firewall, youd
better make damn sure you arent using any exotic ports.
Software Quality Attributes:
• Flexibility: The user interface provided should be user friendly.
• Portability: The system must be easily portable to a wide variety of platforms using various
operating systems. Porting the software from one operating system to another should not require
the code to be changed. Similarly changing the back end database should not require the code to

SECURITY
change.
• Extensibility/Reuse: The software should be extensible in order to add new features without
affecting the base modules. The new releases of the system should maximize the reuse of the
solutions developed in earlier releases.
• Ease of use: The system must be easy to use without requiring users to memorize the commands,
special terms or notations.
6.4.4 State Diagram:
Figure 6.6: State Diagram
6.4.5 Design Constraints
• The product has been developed using JAVA.
• J2SE (Java 2 Standard Edition) Java would be the required as language for development of the
project.AWT and SWINGS are used for GUI design.
• Programming is done in NetBeans..
• Database using mysql.

SECURITY
6.4.6 Software Interface Description
Software Interface:
Front End
• Jdk 1.7.0
• Netbeans 7.4
Back-End
• Mysql 5.1 Services
Amazon EC2 for cloud

Chapter 7
DETAILED DESIGN DOCUMENT USING

APPENDIX A AND B
1.Annexure A:- Laboratory assignment on project Analysis of algorithm Design.
7.1 INTRODUCTION
We implement our proposed system by using the advance java technology. The GUI is implemented
in Java Server Pages, html . As it is a server-client application Java Servlets is used for implementing it.
7.2 ARCHITECTURAL DESIGN
7.3 COMPOENT DESIGN
7.3.1 Class Diagram
37
SECURITY
Figure 7.1: Architectural Design Diagram

SECURITY
Figure 7.2: Class Diagram

Chapter 8
PROJECT IMPLEMENTATION
8.1 INTRODUCTION
For providing security mechanisms in pub/sub, we leverage the principles of identity-based encryption
to support many-to-many interactions between subscribers and publishers. Although we subsequently
demonstrate the implementation of our security methods in terms of a concrete variant called attribute-
based encryption, it is important to remark that our approach also benefits from other identity-based
encryption schemes. In our approach, publishers and subscribers interact with a key server. They pro-
vide credentials to the key server and in turn receive keys which fit the expressed capabilities in the
credentials. Subsequently, those keys can be used to encrypt, decrypt, and sign relevant messages in the
content based pub/sub system, i.e., the credential becomes authorized by the key server. A credential
consists of two parts: a binary string which describes the capability of a peer in publishing and receiving
events, and 2) a proof of its identity. The latter is used for authentication against the key server and
verification whether the capabilities match the identity of the peer. While this can happen in a variety of
ways, for example, relying on challenge response, hardware support, and so on, we pay attention mainly
at expressing the capabilities of a credential, i.e., how subscribers and publishers can create a credential.
This process needs to account for the many possibilities to partition the set of events expressed by an
advertisement or subscription and exploits overlaps in subscriptions and publications. Subsequently, we
use the term credential only for referring to the capability string of a credential. The keys assigned
to publishers and subscribers, and the cipher texts, are labeled with credentials. In particular, the
identity-based encryption ensures that a particular key can decrypt a particular cipher text only if there
is a match between the credentials of the ciphertext and the key. Publishers and subscribers maintain
separate private keys for each authorized credential.
8.2 TOOLS AND TECHNOLOGIES USED
User Interface:-
40
SECURITY
• Sender The sender will send the data to registered users and also he is get the data whatever
other users are send to it.
• Receiver:
• The receiver will get the data to which is sent by the user. Receiver may be the sender and vice
versa.
• Location Privacy
• Get Region Map
Hardware Interface:
• Pentium Processor (P4 and Above).
• A Pentium 1.2 GHz PC (or faster).
• Operating System (Windows XP/7,Linux).
• Jdk1.6.
• Net Beans 7.1.1 and above.
Software Interface:
Technologies and tools used in Policy system project are as follows Technology used:
Front End
• Jdk 1.7.0
• Netbeans 7.4
Back-End
• Mysql 5.1
Services
Amazon EC2 for cloud
Communication Interface
We use TCP/IP protocol for establishing connection and transmitting data over the network. We
use Ethernet for LAN.

SECURITY
8.3 METHODOLOGIES/ALGORITHM DETAILS
Processing Algorithm
1 ELGAMLs Algorithm.
2 SHA-256 Algorithm.
1. ELGAMLs Algorithm
Key Generation phase
Input : Plain text as text data d.
Output: a,b,p,g all are private keys
Step 1: Initialize the random message from user as d. (it should be any kind of text data).
Step 2: initialize a,b,p,g for private key purpose.
Step 3: generate P as randomly base on bit length of d. so,
Ans[]=GetRandomP(d.getbyte).bitlength base on probable prime no.
Step 4: p=Ans[0]
g=Ans[1]
Step 5: Generate a using P
a=RandomA(p)
its calculate like p.bitLength()-1,Random.
Step 6: Calculate b= calculateb(g, a, p);
so, b= g.modPow(a, p);
Step 7: Key generation done
a=RandomA(p)
Decryption
Input : input c1 and c2 as cipher a and p as private keys
Output: Plain text d.
Step 1: m = C2.multiply (C1.modPow (a.negate(), p)).mod (p);
Step 2: return m.
02 SHA 256 Algorithms

Information: string required to ascertain the SHA score.
Yield: SHA score of string
Step 1: Padded with the length in such way that the outcome is numerous in least 512 piece long.

SECURITY
Step 2: Parse into 512 piece message squares M(1),M(2.. M(n) the message square can prepare at one
time.
utilizing the beginning hash values H(0).
Step 3: Then process the succession
H(i) = H(i1)+ CM(i) (H(i1));
Step 4: give back the H(i) SHA score of given string.
Mathematical Model
Lets,
D is denoted by dataset which includes the n number of paragraphs in file
D= Ci1,Ci2,Ci3..Cin
Here, C is the intermediate module which holds the data processing for security as well as data privacy.
C= C1,C2,C3Cn
C1= key generation
C2= encryption of data
C3= Authentication and TTP verification phase
C4 = decryption of data
C5=Revocation phase
C6=Resign key generation
Here R is web base approach which handles the parallel searching, the result of query
classified into n number of result pages. All R instances might be virtual machine on cloud which will
holds the data and when intermediate module generate the requirement it will execute parallel.
R= R1,R2,R3.Rn

Chapter 9
SOFTWARE TESTING
9.1
9.1.1 Unit Testing
Unit testing is a method by which individual units of source code, sets of one or more computer program
modules are tested to determine if they are fit for use. A bottom up approach is used for testing. This
strategy will be useful to find out bugs in the individual modules of the system.
9.1.2 Integration Testing:
Integration testing is the phase in software testing in which individual software modules are combined
and tested as a group. It occurs after unit testing and before validation testing. Integration testing takes
as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined
in an integration test plan to those aggregates, and delivers as its output the integrated system ready
for validation testing.
9.1.3 White Box Testing
White-box testing is a testing that takes into account the internal mechanism of a system as opposed to
its functionality. It is used to verify the source code of the software system if it works as expected or
not. It can be applied to unit level testing or integration level testing.
9.1.4 Black Box Testing:
Black-box testing is a method of software testing that tests the functionality of an application as opposed
to its internal structures or working. Specific knowledge of the internal working of the applications code
44
SECURITY
Figure 9.1: Black Box Testing
is not required. The tester is only supposed to be aware of what the software is supposed to do, but not
how. The black box test cases designed for the testing purpose of the project.
9.2 TEST CASES AND TEST RESULTS
Login:
Table 9.1: TEST CASES AND TEST RESULTS
Crossover:
Table 9.2: Crossover
Login:
Indexing:
File Upload:
Manual Test:
Manual and Automated test are the types of software testing. We are doing a manual test for testing
our system that is without using any automated tool or any script. In this type tester takes over the
role of an end user and test the software to identify any unexpected behavior or bug. There are different

SECURITY
Table 9.3: Login
Table 9.4: Indexing
stages for manual testing like unit testing, integration testing, system testing and user acceptance testing.
Testers use test plan, test cases or test scenario to test the software to ensure the completeness of a
testing. Manual testing also includes exploratory testing as a testers explore the software to identify the
errors in it.
Automated Test:
Automation testing which is also known as Test Automation is when the tester writes scripts and
uses software to test the software. This process involves automation of a manual process. Automation
Testing is used to re-run the test scenarios that were performed manually, quickly and repeatedly.

SECURITY
Table 9.5: File Upload
Table 9.6: File send

Chapter 10
RESULTS
10.1 SCREEN SHOTS
OUTPUT
Figure 10.1: Registration
10.2 OUTPUTS:
We have a new approach to provide authentication and confidentiality with the help of two level
security by using Elgamals And SHA 256 algorithms and provide a secure way for a data transfer
We have presented a new approach to provide authentication and confidentiality in a broker-less

content- based pub/sub system. The approach is highly scalable in terms of number of subscribers and
48
SECURITY
Figure 10.2: Update Files
publishers in the system and the number of keys maintained by them. In particular, we have developed
mechanisms to assign credentials to publishers and subscribers according to their subscriptions and
advertisements. Private keys assigned to publishers and subscribers, and the cipher texts are labeled
with credentials. We adapted techniques from identity- based encryption

SECURITY
Figure 10.3: Download File
Figure 10.4: Share Files

SECURITY
Figure 10.5: Upload File
Figure 10.6: Revoke

SECURITY
Figure 10.7: View File
Figure 10.8: Access Files

Chapter 11
DEPLOYMENT AND MAINTENAN
11.1 INSTALLATION AND UN-INSTALLATION
For installing this system (Securing broker less pub/sub system using identity based encryption) there
are some tools needed on system to be installed. For this system to run, pre requisites are:
Platform: Java
• Download the Java Development Kit from : www.oracle.com
• Install it.
• Installation of Netbeans
• Installation of MySQL from: www.mysql.com/downloads.com
11.2 USER HELP
• College Start with Registration Process and fill in the required details.
• Login with your username and password
• You can update your profile by clicking edit profile.
• After login user can access the system
53
Chapter 12
CONCLUSION AND FUTURE SCOPE
CONCLUSION
We have presented a new approach to provide authentication and confidentiality in a broker-less

content- based pub/sub system. The approach is highly scalable in terms of number of subscribers and
publishers in the system and the number of keys maintained by them. In particular, we have devel-
oped mechanisms to assign credentials to publishers and subscribers according to their subscriptions and
advertisements. Private keys assigned to publishers and subscribers, and the cipher texts are labeled
with credentials. We adapted techniques from identity- based encryption 1) to ensure that a particular
subscriber can decrypt an event only if there is a match between the credentials associated with the event
and its private keys and 2) to allow subscribers to verify the authenticity of received events. Furthermore,
we developed a secure overlay maintenance protocol and proposed two event dissemination strategies to
preserve the weak subscription confidentiality in the presence of semantic clustering of subscribers. The
evaluations demonstrate the viability of the proposed security mechanisms and analyze attacks on sub-
scription confidentiality.
FUTURE SCOPE
The minimum resource utilization. We can virtualized the network, energy, storage And We can make
the system more cost effectives.
54
ANNEXURE A
REFERENCES
[1] T. Hashem and L. Kulik, Safeguarding location privacy in wireless ad-hoc networks, Ubicomp
2007: Ubiquitous Computing, pp. 372390, 2007.
[2] C. Bettini, X. Wang, and S. Jajodia, Protecting privacy against location based personal identifi-
cation, Secure Data Management, pp. 185199, 2005.
[3] M. Mokbel, C. Chow, and W. Aref, The new casper: query processing for location services with-
out compromising privacy, in Proceedings of the 32nd international conference on Very large data bases,
VLDB Endowment, 2006, pp. 763774.
[4] K. Vu, R. Zheng, and J. Gao, Efficient algorithms for k-anonymous location privacy in partici-
patory sensing. in IEEE INFOCOM, 2012. [5] L. Sweeney et al., k-anonymity: A model for protecting
privacy, International Journal of Uncertainty Fuzziness and Knowledge Based Systems, vol. 10, no. 5,
pp. 557570, 2002.
[6] H. Zang and J. Bolot, Anonymization of location data does not work: A large-scale measurement
study, in Proceedings of the 17th annual international conference on Mobile computing and networking,
2011, pp. 145156.
[7] H. Kido, Y. Yanagisawa, and T. Satoh, Protection of location privacy using dummies for location-
based services, in 21st International Conference on Data Engineering Workshops, 2005, pp. 12481248.
[8] A. Beresford and F. Stajano, Mix zones: User privacy in location-aware services, in Proceedings
of the Second IEEE Annual Conference on Pervasive Computing and Communications Workshops, 2004,
pp. 127131.
[9] B. Hoh, M. Gruteser, R. Herring, J. Ban, D. Work, J. Herrera, A. Bayen, M. Annavaram, and
Q. Jacobson, Virtual trip lines for distributed privacy-preserving traffic monitoring, in Proceeding of the
6th international conference on Mobile systems, applications, and services, ACM, 2008, pp. 1528.
55
SECURITY
[10] M. Li, K. Sampigethaya, L. Huang, and R. Poovendran, Swing and swap: user-centric approaches
towards maximizing location privacy, in Proceedings of the 5th ACM workshop on Privacy in electronic
society, 2006, pp. 1928.

ANNEXURE B
LABORATORY ASSIGNMENTS ON PROJECT ANALYSIS OF ALGORITHMIC DE-

SIGN 1 ELGAMLs Algorithm. 2 SHA-256 Algorithm. 2. ELGAMLs Algorithm
Key Generation phase
Input : Plain text as text data d.
Output: a,b,p,g all are private keys
Step 1: Initialize the random message from user as d. (it should be any kind of text data).
Step 2: initialize a,b,p,g for private key purpose.
Step 3: generate P as randomly base on bit length of d. so, Ans[]=GetRandomP(d.getbyte).bitlength
base on probable prime no.
Step 4: p=Ans[0]
g=Ans[1]
a=RandomA(p)
a=RandomA(p)
Decryption
Input : input c1 and c2 as cipher a and p as private keys
Output: Plain text d.
Step 1: m = C2.multiply (C1.modPow (a.negate(), p)).mod (p);
Step 2: return m.
57
SECURITY
02 SHA 256 Algorithms

Information: string required to ascertain the SHA score.
Yield: SHA score of string
Step 1: Padded with the length in such way that the outcome is numerous in least 512 piece long.
Step 2: Parse into 512 piece message squares M(1),M(2.. M(n) the message square can prepare at one
time.
utilizing the beginning hash values H(0).
Step 3: Then process the succession
H(i) = H(i1)+ CM(i) (H(i1));
Step 4: give back the H(i) SHA score of given string.

ANNEXURE C
LABORATORY ASSIGNMENTS ON PROJECT QUALITY AND RELIABILITY TEST-

ING OF PROJECT DESIGN
Unit Testing Unit testing is a method by which individual units of source code, sets of one or
more computer program modules are tested to determine if they are fit for use. A bottom up approach
is used for testing. This strategy will be useful to find out bugs in the individual modules of the system.
Integration Testing: Integration testing is the phase in software testing in which individual software
modules are combined and tested as a group. It occurs after unit testing and before validation testing.
Integration testing takes as its input modules that have been unit tested, groups them in larger aggregates,
applies tests defined in an integration test plan to those aggregates, and delivers as its output the
integrated system ready for validation testing.
Black Box Testing:
Figure 12.1: Black Box Testing
Black-box testing is a method of software testing that tests the functionality of an application as op-
posed to its internal structures or working. Specific knowledge of the internal working of the applications
code is not required. The tester is only supposed to be aware of what the software is supposed to do,
but not how. The black box test cases designed for the testing purpose of the project.
Manual Test:
Manual and Automated test are the types of software testing. We are doing a manual test for testing
our system that is without using any automated tool or any script. In this type tester takes over the
role of an end user and test the software to identify any unexpected behavior or bug. There are different
stages for manual testing like unit testing, integration testing, system testing and user acceptance testing.
59
SECURITY
Testers use test plan, test cases or test scenario to test the software to ensure the completeness of a
testing. Manual testing also includes exploratory testing as a testers explore the software to identify the
errors in it.
Automated Test:
Automation testing which is also known as Test Automation is when the tester writes scripts and
uses software to test the software. This process involves automation of a manual process. Automation
Testing is used to re-run the test scenarios that were performed manually, quickly and repeatedly.

ANNEXURE D
PROJECT PLANNER
The statement of how and when a projects objective are to be achieved by showing the major prod-
ucts, milestones, activities and resources required on the project. A project plan according to the project
management body of knowledge is a formal approve document used to guide both project execution and
project control. The primary use of the project plan are document planning assumption and decisions,
facilitate communication among stakeholders, are document approved scope, cost and schedule baselines.
61
SECURITY
Table 12.1: Table For Project plan

ANNEXURE E
REVIEWERS COMMENTS OF PAPER SUBMITTED

1. Paper Title: Cost Effective Authentic and Anonymous Data Sharing With Forward Security
2. Name of the Conference/Journal where paper submitted : International Journal of Innovative

Research in Computer and Communication Engineering
3. Paper accepted/rejected : Accepted
3. Review comments by reviewer : Rahul : Nice approach
63
ANNEXURE F
PLAGIARISM REPORT
Figure 12.2: PLAGIARISM REPORT
64
ANNEXURE G
TERM-II PROJECT LABORATORY ASSIGNMENTS

ASSIGNMENT 1 Problem Statement
We propose a new notion called forward secure ID-based ring signature, which is an essential tool for
building cost-effective authentic and anonymous data sharing system:
• For the first time, we provide formal definitions on forward secure ID-based ring signatures;
• We present a concrete design of forward secure IDbased ring signature. No previous ID-based ring
signature schemes in the literature have the property of forward security, and we are the first to
provide this feature;
• We prove the security of the proposed scheme in the random oracle model, under the standard
RSA assumption; and
• Our implementation is practical, in the following ways:
1) It is in ID-based setting. The elimination of the costly certificate verification process makes it
scalable and especially suitable for big data analytic environment.
2) The size of a secret key is just one integer.
3) Key update process only requires an exponentiation.
4) We do not require any pairing in any stage.
Feasibility assessment using mathematical model
65
SECURITY
When solving problems we have to decide the difficulty level of our problem. There are three types
of classes provided for that. These are as follows:
1) P Class
2) NP-hard Class
3) NP-Complete Class
P Informally the class P is the class of decision problems solvable by some algorithm within a num-
ber of steps bounded by some fixed polynomial in the length of the input. Turing was not concerned
with the efficiency of his machines, but rather his concern was whether they can simulate arbitrary
algorithms given sufficient time. However it turns out Turing machines can generally simulate more
efficient computer models (for example machines equipped with many tapes or an unbounded random
access memory) by at most squaring or cubing the computation time. Thus P is a robust class and has
equivalent definitions over a large class of computer models. Here we follow standard practice and define
the class P in terms of Turing machines.
NP-complete A decision problem L is NP-complete if it is in the set of NP problems so that any

given solution to the decision problem can be verified in polynomial time, and also in the set of NP-hard
problems so that any NP problem can be converted into L by a transformation of the inputs in polyno-
mial time.
The complexity class NP-complete is the set of problems that are the hardest problems in NP, in the
sense that they are the ones most likely not to be in P. If you can find a way to solve an NP-complete
problem quickly, then you can use that algorithm to solve all NP problems quickly.
Conclusion As I have seen all the classes of problems. My Topic is Adaptive Spammer Detection
at the Source Network is of P Class because:
1. Problem can be solved in polynomial time.
2. Shamirs secret algorithm will provide drastic supervision for better detection

SECURITY
Let S be the set of Rules, like S = {Pki,Pkj,P,C,R} where Pki represent the public key for the data
encryption. in the proposed approach. Pkj represent the private key. P is the plaintext here, C is the
cipher text and R is the collection of six different algorithms. Like { KeyGen, ReKey, Sign,ReSign,
ProofGen, ProofVerify.}
Pki = {Pki1, Pki2, Pki3}

Pkj = {Pkj1, Pkj2, Pkj3} C = {C1, C2, C3 } R= {R1, R2, R3 R6} Input is mapped to output which
is shown in the following vein diagram:
Figure 12.3: Venn Diagram
Success condition
c16=NULL
R16=NULL
System Failure
C1 == NULL
R1 == NULL
ASSIGNMENT 2
2. Identify Objects
In the proposed development research development we use java technology, with that we have also
follow some object oriented concepts, these are following
2.1 Morphism
When we generate the random chromosome and check the result data we use morhism in our project.
Using the same function name with the different signatures having in programs, we also find some

SECURITY
different characteristics of morphism
• If a function denotes different and potentially heterogeneous implementations depending on a lim-

ited range of individually specified types and combinations, it is called ad hoc polymorphism. Ad
hoc polymorphism is supported in many languages using function overloading.
• If the code is written without mention of any specific type and thus can be used transparently
with any number of new types, it is called parametric polymorphism. In the object-oriented
programming community, this is often known as generics or generic programming. In the functional
programming community, this is often simply called polymorphism.
• Subtyping (or inclusion polymorphism) is a concept wherein a name may denote instances of
many different classes as long as they are related by some common superclass.[3] In object-oriented
programming, this is often referred to simply as polymorphism. The interaction between parametric
polymorphism and subtyping leads to the concepts of variance and bounded quantification.
2.1 Overloading function Function overloading or method overloading is a feature found in various
programming languages such as Ada, C++, C, Delphi, D, Java, and Swift, that allows creating several
methods with the same name which differ from each other in the type of the input and the output of the
function. It is simply defined as the ability of one function to perform different tasks.
For example, doTask() and doTask(object O) are overloaded methods. To call the latter, an object
must be passed as a parameter, whereas the former does not require a parameter, and is called with an
empty parameter field. A common error would be to assign a default value to the object in the second
method, which would result in an ambiguous call error, as the compiler wouldn’t know which of the two
methods to use.
In our project in crossover phase we use some function overloading functions like this suppose we
have written two function with two different parameters when we call in main program this function
with two integer array it will call first and when with one it will second as same.
2.3 Functional Relations
The relationship between the functions will make the stability in our product, apart from this chro-
mosome initialization, crossover, mutation, fitness, selection as well as membership function in fuzzy, all
function are dependent on each other. Basically we cant complete a single phase in genetic algorithm
without this functionality.
• Basically Functional languages are good when you have a fixed set of things, and as your code
evolves, you primarily add new operations on existing things. This can be accomplished by adding
new functions which compute with existing data types, and the existing functions are left alone.

SECURITY
• Object-oriented languages are good when you have a fixed set of operations on things, and as your
code evolves, our primarily add new things. This can be accomplished by adding new classes which
implement existing methods, and the existing classes are left alone. We also some JDK package es
in our project with jar files like System.IO.*;
2.4 Other Dependencies
The quality of a program deteriorates over time and it becomes more and more expensive to update
and maintain it. This is often caused by poorly managed dependencies. Dependencies between software
artifacts (classes, packages, functions,.. ) are created when an artifact is referenced by another artifact,
for instance, when a method of a class invokes a method defined in another class. These dependencies
are then propagated to other units of code: a package depends on another package if there is a class
dependency between classes in the respective packages etc. Dependencies can become problematic when
they are created to solve short-term problems but bypass rules defined as part of the system architecture
such as the persistency layer should not depend on the presentation layer. These dependencies then
become technical debt that starts piling up.
And eventually, this will become a problem. Remember the late 90s when everybody wanted to port
their applications to the web. That was easy to do for applications with a clear separation between
user interface and logic layer, and difficult to impossible for applications where the logic depended on a
particular user interface (usually a desktop UI). Now Java programmers face a similar situation. There
are many use cases that require modularity - creating plugin ecosystems around products, product lines
and the ability to make incremental updates to name a few. And there are several great platforms for
modularity available, in particular OS Gi and its extensions (Eclipse, declarative services, Spring dy-
namic modules). But all of these platforms have strict requirements when it comes to dependencies. A
common theme is that these frameworks have containers to manage dependencies automatically. This
requires that programmers adhere to the following two principles:
package separability -
dependencies between different packages should be minimised so that packages can be deployed in
different modules. In particular, there should be no circular dependencies between packages.
interface separability -
dependencies between abstract classes and interfaces and their implementing concrete types should
be minimised, so that abstract types and implementation types can be part of different modules. This
facilitates the compatibility of different implementations and makes it easier to replace a particular im-
plementation within an application.

SECURITY
ASSIGNMENT 3
Functional Dependency Graph
Figure 12.4: Open stack functional Dependency Graph
A functional dependency is trivial if Y is a subset of X. In a table with attributes of employee name

and Social Security number (SSN), employee name is functionally dependent on SSN because the SSN is
unique for individual names. An SSN identifies the employee specifically, but an employee name cannot

SECURITY
distinguish the SSN because more than one employee could have the same name.
Functional dependency defines Boyce-Codd normal form and third normal form. This preserves de-
pendency between attributes, eliminating the repetition of information. Functional dependency is related
to a candidate key, which uniquely identifies a tuple and determines the value of all other attributes in
the relation. In some cases, functionally dependent sets are irreducible if:
• The right-hand set of functional dependency holds only one attribute
• The left-hand set of functional dependency cannot be reduced, since this may change the entire
content of the set
• Reducing any of the existing functional dependency might change the content of the set An im-
portant property of a functional dependency is Armstrongs axiom, which is used in database
normalization. In a relation, R, with three attributes (X, Y, Z) Armstrongs axiom holds strong if
the following conditions are satisfied:
• Axiom of Transivity: If X→ and Y→Z, then X→Z
• Axiom of Reflexivity (Subset Property): If Y is a subset of X, then X→Y
• Axiom of Augmentation: If X→Y, then XZ→YZ
UML Diagrams
New Architecture
Figure 12.5: Proposed system Architecture
In the current research work, we assume the cloud itself is semi-trusted, which means it follows pro-
tocols and does not pollute data integrity actively as a malicious adversary, but it may lie to verifiers
about the incorrectness of shared data in order to save the reputation of its data services and avoid

SECURITY
losing money on its data services. In addition, we also assume there is no collusion between the cloud
and any user during the design of our mechanism. Generally, the incorrectness of share data under the
above semi trusted model can be introduced by hardware/software failures or human errors happened in
the cloud. Considering these factors, users do not fully trust the cloud with the integrity of shared data.
To protect the integrity of shared data, each block in shared data is attached with a signature, which
is computed by one of the users in the group. Specifically, when shared data is initially created by the
original user in the cloud, all the signatures on shared data are computed by the original user. After that,
once a user modifies a block, this user also needs to sign the modified block with his/her own private
key. By sharing data among a group of users, different blocks may be signed by different users due to
modifications from different users. When a user in the group leaves or misbehaves, the group needs to
revoke this user. Generally, as the creator of shared data, the original user acts as the group manager
and is able to revoke users on behalf of the group. Once a user is revoked, the signatures computed by
this revoked user become invalid to the group, and the blocks that were previously signed by this revoked
user should be re-signed by an existing users private key, so that the correctness of the entire data can
still be verified with the public keys of existing users only. Alternative approach. Allowing every user
in the group to share a common group private key and sign each block with it, is also a possible way to
protect the integrity of shared data . However, when a user is revoked, a new group private key needs to
be securely distributed to every existing user and all the blocks in the shared data have to be re-signed
with the new private key, which increases the complexity of key management and decreases the efficiency
of user revocation.

ANNEXURE H
INFORMATION OF PROJECT GROUP MEMBERS
• Name : Shreyas Sudhir Barde
• Date of Birth : 05-07-1994
• Gender : Male
• Permanent Address : 1105, Prakash Optician, Sainath Chowk, Main Road, Sangamner, Dist. A-
Nagar, Maharashtra.
• E-Mail : shreyasbarde@gmail.com
• Mobile/Contact No. : 9860420279
• Placement Details : Ethenus Pvt. Ltd.
• Paper Published : IJIRCCE
73
SECURITY
• Name : Laxmi Ramesh Salunke
• Date of Birth : 24-05-1992
• Gender : Female
• Permanent Address : A/p:Jewali Tal:Lohara Dist: Osmanabad
• E-Mail :laxmisweet24@gmail.com
• Mobile/Contact No. :9763298390

SECURITY
• Placement Details :No
• Paper Published :IJIRCCE

SECURITY
• Name :Rupa Ravindar Kandula
• 2. Date of Birth :23-08-1991
• Gender :Female
• Permanent Address :Dattatreyanivas Building,Telipada kaneri tal; Bhiwandi
• Dist :Thane
• E-Mail :rupa.kandula34@gmail.com
• Mobile/Contact No. :9167834916
• Placement Details :No
• Paper Published : IJIRCCE

SECURITY

Laxmi Report

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Laxmi Report

Uploaded by

Copyright:

Available Formats

CONTENTS

4 PROBLEM DEFINITION AND SCOPE 13

6 SOFTWARE REQUIREMENT SPECIFICATION 27

GSMCOE,DEPARTMENT OF COMPUTER ENGINEERING 2016 II

11 DEPLOYMENT AND MAINTENAN 53

12 CONCLUSION AND FUTURE SCOPE 54

1.1 Plan of Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4.1 Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.1 Project plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.1 Use case Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7.1 Architectural Design Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

9.1 Black Box Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

12.1 Black Box Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

1.1 Table For Project Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5.1 Risk Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

9.1 TEST CASES AND TEST RESULTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

12.1 Table For Project plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

1.1 PROJECT TITLE

Cost-Effective Authentic and Anonymous Data Sharing with Forward Security

1.2 PROJECT OPTION

Our project is Internal project

1.3 INTERNAL GUIDE

Internal Guide is Prof. Ashok Kumar

1.4 SPONSORSHIP AND EXTERNAL GUIDE

Project is only Internal project

1.5 TECHNICAL KEYWORDS (AS PER ACM KEYWORDS)

• Encryption based services ,

1.6 PROBLEM STATEMENT

• Forward security technique is built in which Fully-TTP(Trusted Third Party) is used

• Elgamal and SHA 256 Security Algorithms are used.

• Revocation is obtained in the system.

GSMCOE,DEPARTMENT OF COMPUTER ENGINEERING 2016 2

1.8 GOALS AND OBJECTIVES

3. Receiver can download the encrypted data.

• Save a great of time and computation in Authentication.

• High level data Security.

• Large scale secure data sharing system.

1.9 RELEVANT MATHEMATICS ASSOCIATED WITH THE

GSMCOE,DEPARTMENT OF COMPUTER ENGINEERING 2016 3

C1= key generation

NP-complete A decision problem L is NP-complete if it is in the set of NP problems so that any

GSMCOE,DEPARTMENT OF COMPUTER ENGINEERING 2016 4

1.10 NAMES OF CONFERENCES / JOURNALS WHERE

International Journal of Innovative Research in Computer and Communication Engineering

1.11 REVIEW OF CONFERENCE/JOURNAL PAPERS SUP-

GSMCOE,DEPARTMENT OF COMPUTER ENGINEERING 2016 5

[4] J. Bethencourt, A. Sahai, and B. Waters, Ciphertext-Policy Attribute-Based Encryption, Proc.

1.12 PLAN OF PROJECT EXECUTION

GSMCOE,DEPARTMENT OF COMPUTER ENGINEERING 2016 6

Figure 1.1: Plan of Project

GSMCOE,DEPARTMENT OF COMPUTER ENGINEERING 2016 7

Table 1.1: Table For Project Schedule

GSMCOE,DEPARTMENT OF COMPUTER ENGINEERING 2016 8

2.1 AREA OF PROJECT

The Project Area is depends on our Data Security Domain

2.2 TECHNICAL KEYWORDS:

• Encryption based services ,

• SHA -256 algorithm,

3.1 PROJECT IDEA

3.2 MOTIVATION OF THE PROJECT

• Multiple key dependency problem is another issue.

• Certificate verification dependency.

3.3 LITERATURE SURVEY

GSMCOE,DEPARTMENT OF COMPUTER ENGINEERING 2016 11