Large & Complex Data Streams Using Big Data

LARGE & COMPLEX DATA STREAMS USING BIG DATA
ABSTRACT
Recently, Cloud has become quite attractive because of elasticity, availability, and scalability.
However, the technologies such as virtualization build up Cloud represents a double-edged sword
because of the expansion on attacking surfaces to entire hardware-software stack. Moreover,
homogeneous computing in Cloud severely limits the computational power it can potentially
provide. Therefore, it is strongly desired to have new and comprehensive solutions to maintain all
benefits from Cloud and suppress backsides. This thesis proposes three solutions to address
security, computation and data issues in Cloud. Firstly, a GPU MapReduce framework
specifically aims at improving performance and reducing energy consumption to data parallel
problems.
In addition, the P-CP-ABE scheme overcomes not only the difficulties of data security, access
control, and key management issues in Cloud, but also the overall performance is enhanced
dramatically.
Finally, the multi-tenancy technology requires a strong network authentication protocols to assure
authenticity and nonrepudiation in the Cloud.
Guided by: Dr. Ashad Ullah Qureshi

Contact: 6260651575, 9179357477
Email: conceptsbookspublication@gmail.com
Web: https://researchitout.blogspot.com/
CHAPTER 1
INTRODUCTION
1.1 INTRODUCTION
Fifteen years ago, because the basic computing unit was physical servers, and different user used
different physical servers dedicatedly, the attacking surface to an application was limited to inputs
and outputs from and to the hosting physical server. Luckily, security specialists only had to keep
eyes on the possible physical interfaces to assure the application was relatively secured since the
trust boundary is minimal.
In addition, Cloud has started a new revolution on parallel and distributed computing world in late-
2000s. Since Cloud provides the opportunities of resource sharing and server consolidation, the
barrier of investment to get in the Internet business has been removed mostly and the average cost
to overall players in the market has been reduced significantly as well.
Even though Cloud looks like having many comparative advantages over traditional
infrastructures, the risks of overlapping trust domain objects may wash out all benefits. Moreover,
because of resource sharing and server consolidation, the entire hardware-software stack becomes
attacking surfaces to the applications in the Cloud.

Contact: 6260651575, 9179357477
To cope the backsides, cryptographic mechanisms, such as public key infrastructures [23], have
been widely used in the Cloud. However, key management has become a critical challenge in
traditional public key infrastructures. Although certificate is a general solution, we need a better
and comprehensive technology. Bethencourt et al. proposed a Ciphertext- Policy Attribute Based
Encryption (CP-ABE) scheme in 2007.
CP-ABE is a special public key cryptography scheme that includes three natural superiorities: all
users share one copy of public key; normally, one copy of plaintext is encrypted to single ciphertext
for different users rather than many different ciphertexts in traditional cases; and expressing the
access control policy in fine grained naturally. On the other hand, the main difficulty of CP-ABE
comes from its complexity. Its major components such as paring and elliptic curve computations
slow down the processes of key generation, encryption and decryption [22]. But also, the existing
CP-ABE system was written in a sequential algorithm, which worsens the performance.
As a result, CP-ABE seems impractical to the applications of industries. To take the advantages of
CP-ABE in Cloud, we are introducing Parallelized Ciphertext-Policy Attribute-Based Encryption,
P-CP-ABE as abbreviation.

Contact: 6260651575, 9179357477
1.2 BACKGROUND
Parallel Computing and GPU Computing Parallel Computing and GPU ComputingParallel
computing [29] allows us to solve large problems, to solve problems inless time, and to achieve
better solutions by splitting them into smaller ones andsolving them concurrently. Control,
synchronization, and communication are threemain aspects required to be concerned in parallel
computing. All of them are quitechallenging to programmers. Except in mechanisms of
parallelization, decomposingproblems into subproblems that can be safely solved at the same time
is also verysignificant because the longest task determines performance in parallel computing.
In addition, GPU computing is a “revival” of parallel computing after it was dyinglater in the 90’s.
GPU provides a special single instruction multiple threads mode(SIMT) for parallel programmers
to gain good performance from data parallelism.In this text, Nvidia CUDA - “Compute Unified
Device Architecture” [20] [21] [27] willbe used as the basic programming model. There are several
subtleties that will beanalyzed in detail: memory coalescing and alignment, explicit and implicit
synchronizations, and host and device memory allocation.
Memory coalescing and alignment Memory coalescing and alignmentGlobal memory bandwidth
is most efficient when the simultaneous memory accesses by threads in a half-warp (during the
execution of a single read or write instruction) can be coalesced into a single memory transaction
of 32, 64,or 128 bytes.Coalescing is achieved even if the warp is divergent and some threads of
the halfwarp do not actually access memory.

Contact: 6260651575, 9179357477
1.3 RESEARCH METHODOLGY
There are four main points related to the P-CP-ABE will be explained in this thesis as follows:
2 Analyze the existing CP-ABE thoroughly to identify performance bottlenecks.
3 Parallelize key generation and encryption/decryption processes by using multithreading
technique.
4 Switch encryption from Cipher Block Chaining (CBC) mode to Counter (CTR) mode.
5 Conduct experiments to demonstrate performance gains.
Cloud security includes much more than data security and accesscontrol. Indeed, authentication
deserves more concern in Cloud because of the twocharacteristics of Cloud: multi tenancy and
service oriented architecture. To establish a “trusted atmosphere” in the Cloud, authenticity and
nonrepudiation have to be provided and there must be a trusted “way” to prove a user is the one
who says so; aRPC was sent from the one who says so; a service is the one who says so; no one
iscapable to deny what he has done; and so on. To satisfy the requirement, we are proposing a
suite of strong network authentication protocols through secret-key cryptography on top of
insecure communication channels.
Besides of security issues, computational power and energy consumption inCloud are getting more
attentions from industries as well. One of the main purposesof Cloud is to solve data intensive

Contact: 6260651575, 9179357477
computations. However, because CPUs were designed for solving one problem faster rather than
solving numbers of smaller problems in parallel, CPUs might not be the best choice to data parallel
problems interms of computational power and energy consumption [17]. Moreover, data parallel
has been broadly used in industries for many years because it is not only relatively easy to be
implemented, but fits to many common applications as well. To sum up,because it is increasingly
desired to have a better data intensive computing framework, we are proposing a GPU MapReduce
framework in this thesis to specificallywork out data parallelization problems. Based on the
experimental statistics, theGPU MapReduce framework has nontrivial improvement in
performance over CPU.
For example, it speeds up 1200 times over single CPU thread in running word counting program
on the platform of Nvidia GTX970.

Contact: 6260651575, 9179357477
1.4 RESEARCH TOOLS
There many tools available in the market but some of them used in the research are as follows:
• CloudSim:
• MapReduce Algorithm
• GPU
• Nvidia GTX970
• CBC:Cipher Block Chainingetc

Contact: 6260651575, 9179357477
1.5 ORGANIZATION OF DISSERTATION
The rest of this thesis is organized as follows.
Chapter 1 briefs the introductory part of thesis.
Chapter 2 summarizes someessential backgrounds: parallel computing and GPU computing,
MapReduce programming model, and attributed-based encryption. They are required to be
understood before going further chapters.
Chapter 3 provides the design of GPU Mapreduce framework will be broken up and explained.
Chapter 4Parallelization on key generation, encryption and decryption of P-CP-ABE will be
covered.
Chapter 5 proposes the Kerberossimilar authentication protocol.
Chapter 6 Discusses the performance results are going to be listed.
Chapter 7 explains the attacking simulations, which composeboth passive and active attacks, are
illustrated in.

Contact: 6260651575, 9179357477
CHAPTER 2
LITERATURE SURVEY
[1] LizhiXiong ;ZhengquanXu,"Re-encryption security model over outsourced cloud data" IEEE
Xplore 2013
Cloud computing is recommended as a promising technology, which delivers computational facilities as
services to users over the Internet. As well as, the cloud computing brings significant risks for greater
exposure to data security when users outsource sensitive data for sharing on cloud servers. To keep sensitive
data confidentiality against untrusted cloud service provider, this paper discusses this challenging open
issue using re-encryption scheme in outsourced cloud data. On the one hand, it allows the data owner to
delegate most of the computation tasks to untrusted cloud servers providers without the need to have
knowledge of the underlying plain texts. On the other hand, it employs double cryptographic methods to
limit authorized users accessing updated cloud data with expired keys.
Verdict: This paper also obtains the restrictions of choosing appropriate encryption algorithm to establish
secure re-encryption scheme in cloud data services.

Contact: 6260651575, 9179357477
[2] Balachandra Reddy Kandukuri ; Ramakrishna Paturi V. ; AtanuRakshit, "Cloud Security
Issues" IEEE Xplore 2014
In past three decades, the world of computation has changed from centralized (client-server not web-based)
to distributed systems and now we are getting back to the virtual centralization (Cloud Computing).
Location of data and processes makes the difference in the realm of computation. On one hand, an
individual has full control on data and processes in his/her computer. On the other hand, we have the cloud
computing wherein, the service and data maintenance is provided by some vendor which leaves the
client/customer unaware of where the processes are running or where the data is stored. So, logically
speaking, the client has no control over it. The cloud computing uses the internet as the communication
media. When we look at the security of data in the cloud computing, the vendor has to provide some
assurance in service level agreements (SLA) to convince the customer on security issues. Organizations use
cloud computing as a service infrastructure, critically like to examine the security and confidentiality issues
for their business critical insensitive applications. Yet, guaranteeing the security of corporate data in the
"cloud" is difficult, if not impossible, as they provide different services like Software as a service (SaaS),
Platform as a service (PaaS), and Infrastructure as a service (IaaS). Each service has their own security
issues. So the SLA has to describe different levels of security and their complexity based on the services to
make the customer understand the security policies that are being implemented. There has to be a
standardized way to prepare the SLA irrespective to the providers. This can help some of the enterprises to
look forward in using the cloud services.
Verdict: In this paper, we put forward some security issues that have to be included in SLA.

Contact: 6260651575, 9179357477
[3] Mehdi Bahrami ;MukeshSinghal."A dynamic cloud computing platform for eHealth systems""
IEEE Xplore 2015
Cloud Computing technology offers new opportunities for outsourcing data, and outsourcing computation
to individuals, start-up businesses, and corporations in health care. Although cloud computing paradigm
provides interesting, and cost effective opportunities to the users, it is not mature, and using the cloud
introduces new obstacles to users. For instance, vendor lock-in issue that causes a healthcare system rely
on a cloud vendor infrastructure, and it does not allow the system to easily transit from one vendor to
another. Cloud data privacy is another issue and data privacy could be violated due to outsourcing data to
a cloud computing system, in particular for a healthcare system that archives and processes sensitive data.
In this paper, we present a novel cloud computing platform based on a Service-Oriented cloud architecture.
The proposed platform can be ran on the top of heterogeneous cloud computing systems that provides
standard, dynamic and customizable services for eHealth systems. The proposed platform allows
heterogeneous clouds provide a uniform service interface for eHealth systems that enable users to freely
transfer their data and application from one vendor to another with minimal modifications. We implement
the proposed platform for an eHealth system that maintains patients' data privacy in the cloud. We consider
a data accessibility scenario with implementing two methods, AES and a light-weight data privacy method
to protect patients' data privacy on the proposed platform. We assess the performance and the scalability of
the implemented platform for a massive electronic medical record.
Verdict: The experimental results show that the proposed platform have not introduce additional overheads
when we run data privacy protection methods on the proposed platform.

Contact: 6260651575, 9179357477
[4] Xin Gu ;Zhengquan Xu ; LizhiXiong ; Chunhui Feng, "The Security Analysis of Data Re-
Encryption Model in Cloud Services" IEEE Xplore 2016
Cloud computing provides both opportunities to develop more services as well as significant risks for
greater exposure to data privacy problem when users outsource sensitive data for sharing on cloud servers.
Re-encryption scheme offers a solution to this issue, which allows the data owner to delegate most of the
computation tasks to untrusted cloud servers providers without disclosing the underlying data contents.
However, collusion attack by untrusted cloud service providers and legal data users is still a key threat to
data privacy in cloud data service.
Verdict: In this paper, we study on the collusion attack issue by analyzing re-encryption model and classic
encryption methods, and indicate how to choose encryption algorithm to against collusion attack in re-
encryption model. Extended experiments show that our study is provably secure under existing cloud
environment.

Contact: 6260651575, 9179357477
[5] MeikoJensen ;JorgSchwenk ; Jens-Matthias Bohli ; Nils Gruschka ; Luigi Lo Iacono,"Security
Prospects through Cloud Computing by Adopting Multiple Clouds" IEEE Xplore 2017
Clouds impose new security challenges, which are amongst the biggest obstacles when considering the
usage of cloud services. This triggered a lot of research activities in this direction, resulting in a quantity of
proposals targeting the various security threats. Besides the security issues coming with the cloud paradigm,
it can also provide a new set of unique features which open the path towards novel security approaches,
techniques and architectures.
Verdict: This paper initiates this discussion by contributing a concept which achieves security merits by
making use of multiple distinct clouds at the same time.

Contact: 6260651575, 9179357477
[6] NiveditaShimbre ;Priya Deshpande, "Enhancing Distributed Data Storage Security for Cloud
Computing Using TPA and AES Algorithm" IEEE Xplore 2015
Cloud computing model is very exciting model especially for business peoples. Many business peoples are
getting attracted towards cloud computing model because of the features easy to manage, device
independent, location independent. But this cloud models comes with many security issues. A business
person keeps crucial information on cloud, so security of data is crucial issue as probability of hacking and
unauthorised access is there. Also availability is a major concern on cloud. This paper, discusses the file
distribution and SHA-1 technique. When file is distributed then data is also segregated into many servers.
So here the need of data security arises. Every block of file contains its own hash code, using hash code
which will enhance user authentication process, only authorized person can access the data. Here, the data
is encrypted using advanced encryption standard, so data is successfully and securely stored on cloud. Third
party auditor is used for public auditing.
Verdict: This paper discusses the handling of some security issues like Fast error localization, data
integrity, data security. The proposed design allows users to audit the data with lightweight communication
and computation cost. Analysis shows that proposed system is highly efficient against malicious data
modification attack and server colluding attack. Performance and extensive security analysis shows that
proposed systems are provably secure and highly efficient.

Contact: 6260651575, 9179357477
[7] A. Amali Angel Punitha ; G. Indumathi, "Security issues in distributed data storage & its
solutions" IEEE Xplore 2016
Privacy is mandatory to prevent unapproved clients from contact with the sensitive data as it is subject to
illicit disclose and access once it outsourced. Genuineness can keep outsourced data from being returned
and altered. The Distributed reckoning is the latest innovation which gives distinctive robust free
administrations through the web. The virtual cloud server permits the client to store their information on
the cloud without stressing over accuracy & integrity of the data. The distributed data storage has numerous
benefits over local data storage. The user can upload data to the cloud and get those data at anytime and
anywhere with no extra burden. The User doesn't need to stress over storage and maintenance of cloud data.
In any case, as the data are put in the remote place how users will get the affirmation about stored
information. Subsequently, distributed storage ought to have some system which will determine storage
correctness and trustworthiness of data stored on a cloud.
Verdict: The main issue of distributed storage is security. Numerous scientists have proposed their work
or new encryption algorithms to accomplish security or to resolve this security issue. The proposed
encryption scheme leverages to build a secure data storage to significantly improve the security.

Contact: 6260651575, 9179357477
[8] Deepak H. Sharma ; C A. Dhote ; Manish M. Potey, "Implementing Intrusion Management as
Security-as-a-service from cloud"IEEE Xplore 2016
In Security-as-a-service model the objective is to provide security as one of the cloud services. In this model
the security is provided from the cloud in place of on-premise implementation. The Intrusion Management
comprises of methods for intrusion detection, intrusion prevention and response to intrusions. In physical
environments Intrusion management methods have already matured. However, due to growth of cloud
computing, virtualization and multi-tenant resource sharing there are new targets for intrusion due to their
complex structure. There are several issues related to intrusion detection and prevention in a cloud
environment, and even in a traditional environment with intrusion management service to be delivered as a
service from the cloud. This paper provides implementation framework for cloud-based intrusion
management from the cloud as a service. The management is easy and efficient through Web-based console
anywhere, anytime.
Verdict: The Intrusion Management-SecaaS implemented as the cloud service can benefit the user with all
the advantages offered by Security-as-a-service (SecaaS). The proof of concept (POC) prototype of
Intrusion Management IM - SecaaS is implemented and evaluated successfully.

Contact: 6260651575, 9179357477
[9] ChuanFu ; Jun Yang ; Zheli Liu ; ChunfuJia, "A Secure Architecture for Data Storage in the
Cloud Environments"IEEE Xplore 2015
Due to the increasing popularity of cloud computing, data owners are motivated to upload their data of
different types from local devices to the interrelated public cloud for large-scale data storage and data
sharing. However, there are many security issues and challenges are associated with the storage and sharing
in the public cloud. In this paper, at first, we explore security issues of the public cloud and existing
solutions and establish requirements of privacy and usability. In order to solve these issues, as our principal
contribution, we design an updated secure architecture which can be applied in the multi-party data sharing
and computation under the public cloud environments. .
Verdict: At last, we discuss the practical application scenarios and show our new architecture which can
give comprehensive privacy guarantees, especially its better usability.

Contact: 6260651575, 9179357477
[10] M. Venkatesh ; M.R. Sumalatha ; C. SelvaKumar, "Improving public auditability, data
possession in data storage security for cloud computing" IEEE Xplore 2012
Cloud computing is Internet based technology where the users can subscribe high quality of services from
data and software that resides solely in the remote servers. This provides many benefits for the users to
create and store data in the remote servers thereby utilizing fewer resources in client system. However
management of the data and software may not be fully trustworthy which possesses many security
challenges. One of the security issues is the data storage security where frequent integrity checking of
remotely stored data is carried out. RSA based storage security (RSASS) method uses public auditing of
the remote data by improving existing RSA based signature generation. This public key cryptography
technique is widely used for providing strong security. Using this RSASS method, the data storage
correctness is assured and identification of misbehaving server with high probability is achieved. This
method also supports dynamic operation on the data and tries to reduce the server computation time.
Verdict: The preliminary results achieved through RSASS, proposed scheme outperforms with improved
security in data storage when compared with the existing methods.

Contact: 6260651575, 9179357477
CHAPTER 3
GPU MAPREDUCE SYSTEM DESIGN
3.1 Introduction of GPU Map Reduce
As we know the key idea of GPU computing is trying to launch a large number of threads interleave
execution to keep the GPU busy. Thus, our design goal is to decrease the overhead of computation
by accepting to increase the overhead of memory moderately as Figure 11 shows below implies
that no matter how long memory access takes, if we have a large enough problem size, we can
hide the memory latency mostly.
Figure 11 Using thread groups to hide memory latency
There are five design purposes, and they are as follows: take advantages of GPU architecture as
much as possible; reduce communication and make threads independent to each other as much as
possible; hide memory latency by launching a large number of threads with a large enough problem

Contact: 6260651575, 9179357477
size; decompose the inputs as even as possible; and reduce both local and global synchronizations
as much as possible. The global picture of our design is shown as Figures 12 and 13 below:
Figure 12 GPU MapReduce overview A

Contact: 6260651575, 9179357477
Figure 13 GPU MapReduce overview B

Contact: 6260651575, 9179357477
It is better to know the advantages and weaknesses of the design before digging into the details
because you will have some clues when you are reading the code.
3.2 Advantages of design
There are three main advantages that we believe are benefits to applications. Firstly, based on the
experiment results, which will be shown in chapter VII, the performances of many applications
are quite good on our GPU MapReduce framework because our design is shared memory based
[24] [25] [26]. Furthermore, most overheads of framework are memory accesses. Both these two
advantages are amplifying the advantage of GPU architecture. Finally, because our design uses
hash function to differentiate between keys, we believe a customized hash function will help
reducing hash collision and balancing the loads very well; thus, we provide customized hash
function to each application.
3.3 Weaknesses of design
Because design is about tradeoffs, and for having those advantages, there are some costs we have
to pay. There are four main weaknesses in our implementation. First, because the size of map
kernels determine the size of reduce kernels, sometimes the performance of reduce portion is pretty
bad if the size of map kernels was not controlled well which causes the load of reduce kernels are
not balanced well. Second, memory footprint is pretty bad due to our design decision. Third, the
difference of running times in map kernel and reduce kernel could be big, which worsens the
benefits that could be gained from pipelining because the length of the longest stage determinates
the lengths of pipelining stage. Last, because we use hash function, hash value collision is a big

Contact: 6260651575, 9179357477
issue we have to deal with. The collision intensities of different hash values could be different;
thus, the loads of different reduce kernels are different, which is also a performance killer.
3.4 Map Kernel 1
The reason that we divided the map procedure to two potions is that we do not accept allocating
dynamic memory in threads, which will be analyzed in the lesson learned section of this chapter
Figure 14 Map Kernel 1
Based on Figure 14, we can peek at the overall logic. There are five steps all threads of Map Kernel
1 have to take care of. Firstly, they try to decompose the inputs as evenly as possible by extracting
owning intervals of inputs, and delivering to the user defined map function. Secondly, they call
the user defined map function in parallel. Thirdly, the user defined map function writes
intermediate results to predefined memory locations, which were provided as parameters in
function call, in parallel. Fourthly, thread 0 of blocks calculate the size of intermediate results that
the user defined map functions produced in parallel to get the total size of intermediate results and

Contact: 6260651575, 9179357477
atomically add to a global location to allow CPU to do the memory allocation and offsets
calculations.
3.5 Map Kernel 2
Figure 15 Map Kernel 2A

Contact: 6260651575, 9179357477
Because both grid size and block size of Map Kernel 2 are the same to Map Kernel 1 and all
intermediate results are “checkpointed” in global memory, all threads of Map Kernel 2 can keep
going what Map Kernel 1 left and pretend nothing happened.
There are five steps that all threads of Map Kernel 2 have to go through. Firstly, they iteratively
copy each intermediate result to corresponding location of tabled_working_space based on its key.
Because key generation is based on mod function, every intermediate result is guaranteed to find
a location deterministically.
Also, each block needs to remember how many slots each hash value used among all threads, and
this array of data are stored in shared memory so that all threads in the block can access and
atomically add.
Secondly, based on figure above, after all threads in the block have written all intermediate results
to locations of table d_working_space, all threads, whose thread ID are less than the maximum of
hash value, will read from table d_working_space vertically in parallel; thus, thread ID 0 of the
block read all intermediate results, which have the key equal to hash value 0. Then, calculate thread
offsets for each hash value, and write back to corresponding locations.

Contact: 6260651575, 9179357477
Figure 16 Map Kernel 2B
Thirdly, there are two more global tables: d_hash_offsets and d_hash_sizes, in which we need
them to store the offsets and sizes of each hash value for all blocks.
Let’s look at the table d_addr_table above. We believe this is one of the most important points to
understand our design. We use this table to achieve two dimensional bucket sort in parallel.
Because all threads will write to and read from this table, threads have to know where to write and
where to read. Moreover, because the size of the table equals to the size of intermediate results;
thus, positioning is quite important. We believe threads can find locations if and only if three
conditions are met:
1. Each block knows block size of intermediate results it owns (size1).
2. Each hash value of a block knows size of intermediate results it owns (size2).
3. Each thread knows size for each hash value it owns (size3).
Contact: 6260651575, 9179357477
However, Size1 are defined by each thread 0 of blocks have written to global memory the size of
its owning intermediate results of Map Kernel 1; size2 are defined in the table d_hash_sizes; and
size3 are defined in the table d_working_space. As a result, all threads are able to write all
intermediate results to the right positions without any issues.
3.6 Reduce Kernel
Even though there is only one Reduce Kernel, its tasks are quite heavy because of collision in hash
values. In the current version, the size of Reduce Kernel is based on size of hash value and the grid
size of Map Kernel such that the size of hash value determines the number of blocks in Reduce
Kernel grid; and the number of blocks in Map Kernel grid determines the number of threads in
Reduce Kernel block. As a result, each thread in Map Kernel is responsible for reading and
processing all intermediate results, which have the same hash value as key and were produced
from an entire block of Map Kernel. There are three steps to finish the entire Reduce Kernel:

Contact: 6260651575, 9179357477
1. Read intermediate results and differentiate collision
Figure 17 Reduce Kernel A
Let’s look at figure above, each thread is responsible to read and process each square of
intermediate results. For example, thread 0 of block 0 is responsible to all intermediate results,
which have the hash value 0 as key and were produced by all threads in block 0 of Map Kernel.
Moreover, because there could be collision in each hash value key, we need a way to differentiate
different keys in the same hash value.
For example, both 1299 and 99 could map to the position 99 in a 100 elements array, but we still
need to differentiate 1299 and 99 eventually. We believe if the hash function is proper enough, the
collision will never exceed beyond a limitation. As a result, we assume this limitation by creating
Contact: 6260651575, 9179357477
a table to differentiate the collisions. All threads in a block write to the global table in parallel;
then, thread 0 of blocks are responsible to collect and reduce the result to shared memory locations
as below. Furthermore, because the limitation of collisions would be out of control if we were
doing this ahead of time.
2. Combining in block
Figure 18 Reduce Kernel B
Because we are assuming the collisions of each hash value is under controll, we are confident to
put information into shared memory for performance. Thread 0 of blocks combines the same key
together and calculates how many different keys (in columns) and how many elements are in each
key (in size fields). Then, thread 0 also calculates the offsets of each key by size of each key. This
shared memory table ktArray is extremely important and we will analyze it next.

Contact: 6260651575, 9179357477
3. Call user’s reduce function
Figure 19 Reduce Kernel A

Contact: 6260651575, 9179357477
Now, we need another table d_finalAddrTable, which is the same size to d_addr_table, to store the
sorted intermediate results. How to write to the correct position is quite complex because even
though d_finalAddrTable and d_addr_table are in the same size, the organizations are totally
different.
Figure 20 Tables of d_finalAddrTable, d_hash_offsets, and d_hash_sizes
The overview of d_finalAddrTable is showed above. The question is how to locate in this table?
With the help of tables d_hash_offsets, d_hash_sizes, and ktArray, each thread can easily identify

Contact: 6260651575, 9179357477
locations in the d_finalAddrTable. The sequence that each thread reads from table d_addr_table
and writes to table d_finalAddrTable will be showed as follows:
1. Calculate its corresponding hash value offset by checking table d_hash_sizes and summing sizes
of all hash value before it together as HashOffset.
2. Thread read one intermediate result from table d_addr_table, check its key.
3. Find corresponding location of the key in the shared memory table ktArray.
4. AtomicAdd (key.offset, 1); then, write to table d_finalAddrTable [HashOffset+ key.offset-1].
5. Going through 2-4 until there is no intermediate results the thread is responsible.
6. Call user’s reduce function with key/values pair in parallel.
There are five lessons learned from this project. First of all, GPU architecture is the base
knowledge of determining the performance of applications. GPU computing is quite different from
normal programming because many hardware dependent behaviors needed to be considered to
achieve better performance in GPU. Secondly, programmability of GPU is low. There is nothing
to help developing applications.
Thirdly, memory coalescing is extremely important especially when one wants to launch a large
number of threads. Fourthly, dynamically allocating memory in each thread is extremely expensive
and is a performance killer. Lastly, for achieving overall good performance, considering load
balances between threads and between blocks always benefits.

Contact: 6260651575, 9179357477
CHAPTER 4
PARALLELIZING CP-ABE
A ciphertext-policy attribute based (CP-ABE) scheme and implemented a sequential prototype
system. To utilize it effectively in Clouds, P-CP-ABE is developed to accelerate major processes
such as key generation and encryption/decryption for acceptable performance.
4.1 Parallelization of Key Generation
To represent attributes numerically, CP-ABE converts value equation such as “a = k” into a “bag
of bits” representation by specifying n, the number of bits of k, and the value of each bit in k. All
n non-numerical attributes will be a part of the user’s private key.
Thus, the overhead of private key generation is associated with the number of attributes possessed
by the user. Since bilinear group G0 is implemented in elliptic curve, the extra Ω(2*n*attributes)
exponentiation operations incur significant overhead which slows down key generation. Since
predefining the correct number of bits is not practical, CP-ABE simply assumes n = 64 and fixes
the bit number to 264.
However, this introduces a higher cost with Ω(128*attributes) exponentiation operations in group
G0. Consequently, it slows down the key generation dramatically.

Contact: 6260651575, 9179357477
Figure 21 Time distribution of key generation
Figure 21 above demonstrates the major overhead in the CP-ABE key generation process. It is
quite clear that function bswabe_keygen () in library libbswabe dominates the overall cost. Thus,
accelerating this part might achieve up to O(PEs) speedup where PEs are Processing Elements or
cores. The parallelization consists of four major stages.
1. Data and Task Decomposition: Since all attributes are independent, they could be partitioned
and assigned to different threads for parallel processing. However, the large number of threads
might not achieve good performance all the time. Each extra thread also introduces some
corresponding creation, maintenance and synchronization overheads. Therefore, once the thread
number reaches the threshold, the performance gain will disappear. P-CPABE determines the
thread number based on the physical core number in the computer systems.
Contact: 6260651575, 9179357477
2. Initialization: Since sequential CP-ABE system is based on PBC library, certain preparation
work is required for the parallelization process. Each thread is equipped with a pointer to the public
key for the calculation of pairing e(g,g)a. For each private key, one randomized r is required to be
resistant to collusion attacks. Therefore, each thread needs to calculate g r in bilinear group G0 to
satisfy `A = S} ∗ .(E)}A. Also, each thread will be informed how many attributes it needs to handle
and where to get them.
3. Parallelized Computation: Once the performance bottle is identified, the actual parallelization
process is quite straightforward. Since all attributes can be handled independently, key generation
is a perfect case for parallel computing.

Contact: 6260651575, 9179357477
The initialization for the loop is simply partitioned and assigned to different threads. The
pseudocode is shown in Algorithm 1.
4. Optimized Output: Once these threads finish processing the attributes assigned them, they
should apply the results to the final private key. However, if all threads do this at the same time,
both false and true sharing might happen. There are several ways to handle this. One extreme
approach is to let the master thread handle it, i.e., all threads pass their results to the main thread
who will apply them to the private key iteratively. Obviously this sequential process is quite slow.
Another extreme will go to the opposite way. Once each thread finishes processing an attribute, it
will apply the result to the private key directly. To avoid race condition, mutual exclusive lock is
required. However, this will incur O(attributes) locking and unlocking operations which might be
an extra overhead as well. P-CP-ABE adopts a neutral approach.
Each thread applies its result to the private key only after all local attributes have been processed.
This takes advantage of spatial locality and will incur lower extra overhead with O(threads)
locking and unlocking operations.
Thus, the overlapping of computation and communication can be achieved without too much extra
overhead.

Contact: 6260651575, 9179357477
4.2 Parallelization of Encryption and Decryption
In CP-ABE, encryption and decryption are used most frequently and become thefocus of P-CP-
ABE. They are parallelized with different strategies.
Table 2 Running time distribution of CP-ABE
1. Overlapping of Computation and Communication: Overlapping is the majorparallelization
technique to utilize multiple system resources simultaneously. For encryption in CP-ABE,
according to Table 2, both reading plaintext and parsing policies occupy 1%~40% of the total time
although their reasons of fluctuation are different. The time of reading plaintext varies due to the
communication delay caused by size of files as well as the status of memory and caches. However,
the parsing policy overhead mainly comes from the number of policies and can be purely treated
as computational delay. Since different system resources (communication channels and CPU) are
utilized, they can be employed simultaneously. In encryption, the main thread takes input and
parses the policies, whereas a dedicated communication thread is created to read plaintext from

Contact: 6260651575, 9179357477
hard disk. Two threads are executed in parallel and the one with shorter execution time will be
hidden by the other one completely.
For decryption, disk operation of reading ciphertext happens only if the user’s attributes satisfy
the earlier specified policies. The overlapping of computation and communication is still possible.
Once the user is authorized to decrypt the ciphertext, one communication thread will be launched
for disk operations. In the meantime, the main thread will start symmetric key generation,
including polynomial interpolations, pairing operations, and bilinear exponentiation operations.
Thus, overlapping can still happen. However, based on Table 2, symmetric key generation only
takes less than 1% of total time and performance gain will be minimal.
2. Analysis of Access Tree Structure: For encryption, after policies are parsed, an access tree
structure will be built by the function parse_lang in policy_ lang.y. Only two bilinear
exponentiation operations were called for each leaf node in the function bswabe_enc might incur
some CPU time. However, pairing and symmetric key generation takes no more than 1% of total
time. It might not be necessary to parallelize this portion. Decryption faces a similar situation.
Traversing the access tree structure to check if user’s attributes can satisfy the specified policies
might not be time-consuming. The process includes one polynomial interpolation operation per
node, two pairing operations per leaf, and up to one bilinear exponentiation operation per node for
symmetric key re-generation. Similar to encryption, this portion takes less than 1% of total time.
Therefore, operations on access tree structure are not good candidates for parallelization.

Contact: 6260651575, 9179357477
3. AES Parallelization with Counter Mode: For both encryption and decryption in CP-ABE, AES
encryption occupies 40% of total execution time and is definitely a good candidate for
parallelization. Original CP-ABE uses Cipher Block Chaining (CBC) mode for AES encryption.
P-CP-ABE adopts AES-CTR (Counter mode) to overcome the weaknesses in AES-CBC. First,
with CBC, the last block of plaintext has to be padded in encryption and then de-padded in
decryption.
This restriction is eliminated in AES-CBC to save computational power. Second, AES-CBC
requires sequential operations among data blocks, i.e., later blocks will rely on former ones.
However, in AES-CTR, all data blocks are independent for full parallelization, and direct data
access is supported. Flexibility helps achieve performance gains. Finally, AES-CTR supports
preprocessing to accelerate encryption/decryption further. Once data size is big enough, AES-CTR
outperforms AES-CBC clearly. To enable AESCTR, P-CP-ABE partitions both data and tasks for
parallel processing.
a. Task Decomposition. Multiple tasks are generated and mapped onto threads for execution on
physical hardware cores. Generally, more threads will achieve better performance. However, the
overheads associated with thread generation, maintenance and synchronization might drain out the
performance gains gradually. P-CP-ABE intends to create threads based on the number of physical
cores without too high overheads. Idle threads should be reduced for high efficiency.
Both performance and efficiency are design factors for P-CP-ABE.

Contact: 6260651575, 9179357477
b. Data Decomposition. P-CP-ABE adopts “Owner Compute” strategy. Data blocks will
determine tasks, and then threads. Therefore, the numbers of data blocks, tasks and threads are
consistent. The master thread intends to partition input data based on the number of physical
computing cores. To maximize the parallelization efforts, the master thread will only create threads
and generates data indices for them.
No data movement and operations such as merge will be conducted by the master thread.
Therefore, it is not a bottleneck in P-CP-ABE. Input data has been truncated into blocks based on
AES. The master thread assigns them to all threads which will read data blocks, encrypt or decrypt
them, and then put the results back to corresponding locations independently. No synchronization
and extra storage are required.
c. Parallelization Setups. The master thread assigns an initialization vector and an AES-CTR
counter for every working thread, which in turn calls function AES_ctr128_encrypt() provided

Contact: 6260651575, 9179357477
by OpenSSL library, for encryption and decryption. Data parallelism can be exploited
thoroughly. The pseudocode is given in Algorithm 2.

Contact: 6260651575, 9179357477
CHAPTER 5
AUTHENTICATION PROTOCOLS DESIGN
5.1 Authentication Protocols
There are three entities that are involved in the distributed P-CP-ABE system: central authenticator
(CA), storage servers, and users. Also, it assumes that neither user nor storage server trusts each
other in the insecure environment; and both user and storage server have CA’s public key.
Moreover, there is no secure middleware which will be used for building secure channels, such as
SSL.
Figure 22 Authentication protocols

Contact: 6260651575, 9179357477
Based on Figure 22 above the four core parts of P-CP-ABE are setup, key generation, encryption,
and decryption which have been separated to different entities. Because of the special feature of
P-CP-ABE, all users and the CA can share the same public key with different attributes. If CA’s
public key was certified by a public trust ed party, for example, government, all users’ public keys
are also certified. For security consideration, only the CA has the master key; thus, all private keys
must be generated by CA. Moreover, because the user, who has the private key, is the only one
can decrypt the ciphertext, the decryption procedure must be processed in the user’s workstation.
Finally, only ciphertexts will be uploaded and stored in the cloud storage. The messages that
composed authentication protocols are list below:
Message 1. E(PUCA, Session Key || nouns1) || E(Session Key, nouns1 || time || IP || PK|| USER ||
SHA(PASSWORD)).
Message 2. E(PUCA, KeyX|| nouns1) || E(KeyX, nouns1 || time || REGSERVER || Servername ||
IP).
Message 3. E(KeyX, nouns1 || Servername || IP || “OK”).
Message 4. E(Session Key, nouns1 || Private Key).
Message 5. E(PUCA, Session Key || nouns1) || E(Session Key, nouns1 || time || IP || SERVERX||
USER || SHA(PASSWORD)).
Message 6. E(Session Key, nouns1 || nouns2 || SessionKeyX|| SERVERX || SERVERIPX)
|| Ticket Ticket = E(KeyX, nouns2 || SessionKeyX || USER|| IP || SERVERX ||
Due date).
Contact: 6260651575, 9179357477
Message 7. Communicator || Ticket Communicator = E(SessionKeyX, SERV ERX ||
USER|| IP || nouns2 || time1) Ticket = E(KeyX, nouns2 || SessionKeyX || USER || IP ||
SERV ERX || Due date).
Message 8. E(SessionKeyX, nouns2 || nouns3 || Sub-session key || time1).
Message 9. E(Sub-session key, DOWNLOAD || nouns3 || nouns4 || filename).
Message 10. E(Sub-session key, DOWNLOAD || nouns4 || SHA(file)) || file.
5.2 Centralized Authentication
According to the system, the CA serves both centralized authentication and private key generation
functions; but, if one is willing to, he can easily separate functions to two parts because there are
not any dependences between them. Also, thanks to the feature of P-CP-ABE, all users and the
CA can share the same public key with different attributes. Thus, if our CA’s public key was
certified, all users’ public keys are also certified. Furthermore, if a user encrypts a message by the
public key with the CA’s attributes, the CA will be the only one who has the corresponding private
key to decrypt the message. In another word, because a message can be encrypted by the public
key with a user’s name according to P-CP-ABE’s feature, this message will only be decrypted by
the user who registered the name. Moreover, it is assuming that the public key was known to
everyone. For public key distribution and management, a broadly agreed certificate would be a
very good idea; however, it is out the scope of our concern in this thesis.

Contact: 6260651575, 9179357477
This subsection will only focus on CA’s behaviors which include private key generation, server
granting ticket generation, and storage server registration and management.
Figure 23 Users apply for private key
First of all, the CA generates private keys for all users if and only if the user has been authenticated
and authorized by CA. Before beginning, a new user has to register in the CA, which is not
included in this thesis. Because of P-CP-ABE’s feature, all users can share the same public key
with different attributes, and it is quite convenient for public key management. However, each user
has to have a distinct private key. In the system, the CA authenticates users by comparing the
username and hashed password they provided in Message 1 and 5 in Figure 23 and which was
stored in the CA’s local file during user’s registration. It uses the hash value of a user’s password
instead of displaying the password directly for protecting the user’s privacy. The hashed password
could be trusted the same as the original password because of two security requirements for
cryptographic hash functions that preimage resistant and second preimage resistant: for any given

Contact: 6260651575, 9179357477
hash value h, it is computationally infeasible to find y such that H(y) = h; nor for any given block
x, it is computationally infeasible to find yxwith H(y) = H(x); respectively.
Secondly, generating server granting tickets, which is showed in Message 5, to each user will
enhance the system’s security level. Although the hashed password is not the user’s password, it
still has some security risks. The goal is trying to reduce the possibilities of moving a user’s privacy
information as much as possible. Server granting ticket is a certificate, which proves the user is
who he is, will be sent to any storage server for acquiring storage service. More details of SGT
will be discussed shortly. In the scenario that a user asks the CA for a ticket to one of its managed
storage servers; the CA generates the ticket, which is encrypted by the key that is shared between
the CA and the storage server only, and sends the ticket to the user after he was authenticated and
authorized by the CA successfully. However, because the ticket was encrypted by the key that was
shared only between the CA and the server, any user, who received the ticket, can not see the
contents of the ticket. Furthermore, before the due date that is located in the ticket, the user can
upload or download his own files to or from the storage server by this ticket without providing his
password again. We can imagine that a certified user will have a dedicated directory after he
submits the ticket to the storage server, all his files will be stored in the directory, and the name of
directory will be his user’s name. Moreover, the user will receive the Message 6, which is
composed by two halves that the destination of the first half is the user; and the destination of the
second half - SGT will be the storage server eventually. Comparing the two parts of the Message
6, the session key, which is shared between the user and the CA only will be used to encrypt the

Contact: 6260651575, 9179357477
first half. Thus, only a corresponding user can decrypt the first half; then, obtain the SessionKeyX,
which will be shared between the user and the storage server X only.
Pairing SERVERX and SERVERIPX together, the user can identify the correct storage server for
the future. Besides, because its general communicational pattern is the exact same to the
communicational pattern of private key generation of CA, which was previously discussed, we
clearly know that there are not any passive nor active attack risks. By the same token, after a user
receives the Message 6, he can trust the sender due to Message 6’s nouns1 equals to Message 5’s
nouns1, which he picked, and he receives a new nouns2 from the CA by Message 6 for future
claiming to the storage server that he is who he is since his nouns2 will be exactly the same to the
ticket’s nouns2. Because the ticket was encrypted by the CA with the symmetric key keyX, which
were shared only between the CA and the server X, the storage server can confidently trust the
user by having and comparing both CA’s ticket and user’s communicator. There are several pieces
of information in SGT: nouns2 used for comparing with user’s nouns2, SessionKeyX shared
between the user and the storage server only, USER is used for finding and matching the user and
corresponding directory in the storage server, IP for identifying user’s workstation, SERVERX for
identifying the correct storage server, and due date for identifying the ticket is valid before a date.
All of this information will be needed by mutual authentication between Users and Storage Servers
in the future.
Finally, because a cloud storage system would have massive storage servers, how to manage them
more efficiently, dynamically, and automatically will represent the system’s overall performance.
We introduce a lax management model for our storage servers. In the construction, any user can
Contact: 6260651575, 9179357477
register his own storage server in our CA or use our public storage servers; and, because all data
in storage servers are cipher texts, the user does not need to worry about what data will be exposed
at all.
Figure 24 Servers register in CA
According to Figure 24 above, anyone can register his storage server in the the CA by voluntarily
sharing a keyX with the CA. This keyX will be used as secret key to encrypt the server granting
ticket, which will be issued by the CA and be sent to the authorized users. Thus, because only the
CA and the server have keyX, the storage server can confidently trust the server granting ticket.
5.3 Mutual Authentication
After the storage server and the user were registered and authorized in the CA, both can trust to
each other for transferring files by credentials. This subsection will focus on the communications
between users and storage servers. The mutual authentication and ciphertext transferring will be
defined in the protocol. Moreover, we are not interested in moving a user’s privacy information
Contact: 6260651575, 9179357477
nor asking the CA multiple times for authorizing or authenticating. Thus, we need a smart method
to overcome these two requirements.
Figure 25 Mutual authentication between users and servers
Based on Figure 25 above that there are two steps to finish the mutual authentication between the
two entities - user and storage server, which originally neither trusts to each other.
Step one, a user sends a Message 7, which includes a communicator and the server granting ticket,
to storage server. The communicator is an encrypted message, which uses the sessionkeyX that
will be shared only between the server and the user, for giving the storage server a user-self
introduction to tell the server who he is. The server granting ticket is an encrypted message, which
uses the keyX that was shared only between the server and the CA, for telling the storage server
who the user is by the CA’s saying. On the other hand, because the keyX is shared only between

Contact: 6260651575, 9179357477
the certified server and the CA, the server proves to the user that it is the correct server by having
the correct keyX. Thus, when the corresponding storage server receives the entire Message 7, it
first decrypts the ticket by the keyX; then, it owns the sessionkeyX to decrypt the communicator.
Now, it can compare the communicator’s contents, which must be provided by the user only, and
the ticket’s contents, which must be provided by the CA only, to judge the user’s identification by
passing four tests. Test one, communicator’s nouns2 equals the ticket’s nouns2 indicates that the
communicator was created by the user, who was the one that was authenticated and authorized by
the CA, due to only the user and the CA having the randomized nouns2.
Test two, communicator’s user name and IP equal to ticket’s user name and IP, which indicates
the workstation that user used to acquire the ticket from the CA is exactly the same to the
workstation that is sending the Message 7. Test three, |server's clock − communicator′s time1| <
(△t1 + △t2), where △t1 is the estimated normal discrepancy between the server’s clock and the
user’s clock and △t2 is the expected network delay time. It indicates that Message 1 is not a
replayed message.
The last test, ticket’s due date identifies that this ticket is only valid before a specific date. If all
four tests have been passed, the storage server can trust the user is who he claims he is.
Step two, after all four tests have been passed, the storage server will have to create a new sub-
session key as a one time pad because the less frequently the longer term key - sessionkeyX is
used, the fewer plaintext/ciphertext pairs that Darth.

Contact: 6260651575, 9179357477
CHAPTER 6
EXPERIMEMTAL RESULTS
6.1 Parallelization of Key Generation
The testbed is a machine with Intel I3 4010U, which has two cores and supports Hyper-Threading
technology.
Current P-CP-ABE adopts multithreading for shared memory parallelization. Thus, choosing a
correct number of threads will be critical. Once more threads are selected than the physical core
or hyper-core supported by Hyper Threading technology, extra threads will cause the penalty for
creation, maintenance and synchronization. In Linux systems,
sysconf(_SC_NPROCESSOR_ONLN) might provide a good sense about the actually available
computing units for P-CP-ABE. We can simply use sysconf(_SC_NPROCESSOR_ONLN) as the
actual number of the created threads to distribute input data to all threads as evenly as possible.
However, this might fit in all cases.
If the number of input data items is a multiple of sysconf(_ SC_NPROCESSOR_ONLN), the
number of threads equals to sysconf(_ SC_NPROCESSOR_ONLN). Otherwise, one more thread
will be created to handle the leftovers. Thus, the number of threads will be sysconf(_
SC_NPROCESSOR_ONLN)+1.

Contact: 6260651575, 9179357477
Figure 26 Performance of generating private keys in 50 attributes
In Figure 26 above, for example, we are generating private keys with constantly 50 numerical
policies by creating different quantities of threads to do so. The differences are obvious. In our
environment that Intel I3 4010U, which has two cores with Hyper-Threading technology, there is
a speeding up about 2.38 times when parallelization was used and at least 5 attributes inputted.

Contact: 6260651575, 9179357477
Figure 27 Speedups and efficiencies of private key key generation
Based on Figure 27, our construction has a significant performance gain comparing to the original
CP-ABE. We have tested 500 times from only one numerical policy to 500 numerical policies. We
can see that there are at least 2 times speedup in 2 cores platform and about 4 times speedup in 4
cores platform. Moreover, we knew that only an ideal parallel system containing p processing
elements can deliver a speedup equal to p and efficiency could be equal to one. Hyper threading is
the main reason that superlinear speedup has been created, which causes the speedup beyond
processing elements and efficiency excesses one. According to the efficiency showed in Figure 26
above, parallelization on key generation might not be very good in scalability because its efficiency
is asymptotically greater than (1). This is where we are going to keep working on.
Contact: 6260651575, 9179357477
6.2 Parallelization of Encryption and Decryption
Figure 28 Speedups and efficiencies of encryption
According to Figure 28 that we have tested the encryption on 1000 different input sizes from one
megabyte to 1000 megabytes, we can see that parallelization on encryption and decryption of our
system is cost-optimal and very scalable due to it has the ability to maintain efficiency at a
relatively fixed value by simultaneously increasing the number of processing elements and the size
of data. In the first graph of Figure 28 above, we only included 100 results for showing that even
though the problem size is relatively small, our system still has at least the same or better
performance to the original CP-ABE system.

Contact: 6260651575, 9179357477
CHAPTER 7
SIMULATION RESULTS
7.1 ATTACKS ON USER AUTHENTICATION
Figure 29 Passive attacks on user authentication
Based on the assumption that all can safely get the public key, clients can use this public key with
the CA’s attributes to encrypt the entire request for sending to the CA; but, we prefer to only use
the public key to encrypt a shorter term or one-timeuse symmetric key because the less frequent
use of a long-term key, the fewer plaintext/ciphertext pairs that Darth could collect for analyzing;
Contact: 6260651575, 9179357477
and, symmetric encryption is much faster than asymmetric encryption as well. According to the
protocol, public key encryption encrypts a randomized symmetric key and a randomized nouns1;
then, a symmetric encryption is used to encrypt the rest of the message, which also includes the
same nouns1. Because only the CA has the corresponding private key to decrypt the symmetric
key; and, only the user and the CA have the randomized symmetric key, it is confident that the
passive attacks, which Figure 29 shows, will never happen. Moreover, the reason of doubling the
same nouns1 is for comparing and contrasting the two halves of Message 1 in the CA.
For example, if the message is not readable data and without a comparable nouns1 in both halves
of Message 1, modification attacks could happen even if Darth does not know the session Key
because the CA could not distinguish the difference between incorrect and correct session keys if
the message is not readable. On the other hand, with doubled nouns1, CA compares these two
nouns1s to check if the message was modified or not because it is quite hard for Darth to have the
one-time pad - session key.

Contact: 6260651575, 9179357477
Figure 30 Masquerade and fabrication attacks on user authentication
Defending masquerade and fabrication attacks will be the reasons that both usernames and hashed
passwords are included in the message. In Figure 30, if Darth submits an incorrect user name or
password, the CA will reject him immediately because there was a copy of the username and
password in the CA’s database. As a result, without correct usernames and passwords, masquerade
or fabrication attacks are useless to the system.

Contact: 6260651575, 9179357477
Figure 31 Replay attacks on user authentication
In Figure 31, because there was a timestamp - time has been included in the message, replay attacks
can be prevented. If Darth replays any old message, which was sent from a user before, the CA
will find out immediately due to the Message 1’s time beyond the valid range that |server's clock−
Message1 ′s time| < (△t1+△t2), where △t1 is the estimated normal discrepancy between the
server’s clock and theuser’s clock and △t2 is the expected network delay time.

Contact: 6260651575, 9179357477
Figure 32 Man-in-middle attacks on user authentication
Based on Figure 32, neither modification attack nor man-in-middle attack will be successful in the
system because Darth will never know the randomized nouns1. Without the nouns1, these attacks
could happen because the user can not differentiate the correct session key if the data is not
readable. On the other hand, with a comparable nouns1, a user can always compare the nouns1
sent and received to check the sender is the CA or someone else involved because only the CA
and the user know the randomized nouns1 and the CA will always send the same nouns1 back to
the user. As a consequence, our construction authenticates and authorizes the CA and users that
each side is the entity that it claims to be. Both sides can confidently trust the information sent
from the other side.

Contact: 6260651575, 9179357477
7.2 ATTACKS ON SERVER AUTHENTICATION
Figure 33 Masquerade and fabrication attacks on server authentication
Because the general communicational pattern of server authentication is the exact same to the
communicational pattern of user authentication, which was previously discussed, we clearly know
that there are not any passive nor active attack risks except fabrication.
Based on Figure 33, however, fabrication could happen if Darth registers in CA as server x if the
real server x was not registered in CA before, he can register himself successfully. But, it is useless
due to all the data that will be uploaded to storage server must be encrypted by CP-ABE. Thus,
Contact: 6260651575, 9179357477
Darth has nothing to do with the encrypted ciphertext even if he got the files. Furthermore, because
storage servers are paired by servername and IP address in CA, and pairing information of storage
server will be sent to user after the user applies the server’s SGT from CA, user can decide whether
or not it is the correct server he is willing to use. In our implementation, we are assuming that
storage servers are also insecure and can not be trusted; and, we only make sure that there is no
way for Darth to break out the data. It is up to users to decide where to store the data, but data will
be absolutely safe even though the storage server may be fake. On the other hand, we can easily
change the management strategy of storage servers to be stricter by requiring that only certified
servers can be registered in CA.
Attacks on mutual authentication between user and server
Figure 34 Passive attacks on mutual authentication between user and server

Contact: 6260651575, 9179357477
Based on Figure 34, it is very clear that passive attacks will never succeed because all messages
are encrypted, and Darth can not easily get the keys. In extreme cases Darth may steal keys; but,
because the sessionkeyX is much less frequently used than sub-session keys, it is very hard for
Darth to crypto-analyze on the sessionkeyX. However, even though sub-session key has been
frequently used and he may steal it successfully, it is useless to Darth due to the fact that the sub
sessionkey is a one-time pad.
Figure 35 Personating attacks on mutual authentication
Based on Figure 35, personating attacks will not happen because the user is the only one who has
sessionkeyX , the nouns2, and the IP address of workstation. While the user’s IP might be used by
someone else, the attack still does not work because Darth does not have the nouns2 and the
sessionkeyX . Moreover, even though Darth knows the sessionkeyX and has the authority to use

Contact: 6260651575, 9179357477
the user’s IP address and workstation, he still can not personate the certified user because only the
user owns the randomized nouns2 and communicator’s nouns2 must equal to ticket’s nouns2.
Thus, the fabrication attack is useless in our implementation.
Figure 36 Replay attacks on mutual authentication between user and server
Based on Figure 36, replay attacks to either side will never succeed because of factor time1 and
many continuously “nounses” during exchanging.
In Message 7, if |server′s clock − communicator′s time1| > (△t1 + △t2), storage server will
immediately find out that the message is a replayed one. Moreover, if Darth replays Message 8,
the user will find out instantly because the Message 8’s time1 and nouns2 do not equal to Message
1’s time1 and nouns8; thus, the Message 8 must be a replayed message for sure. Furthermore, all
following messages of information exchanging are going to be linked sequentially by “nounses”
to make sure replay attacks will never work.

Contact: 6260651575, 9179357477
Figure 37 Man-in-middle attacks on mutual authentication
Based on Figure 37, neither modification attacks nor man-in-middle attacks will ever succeed
because any fake Message 8 can not be matched with the original Message 7 successfully when
the user compares with man-in-middle attacks. In addition, there is a very important factor - nouns2
would be worthy to be detailed. If the message is not readable and without nouns2, user has to
trust the Message 8 even though it might be fake because there is no way for user to distinguish
between a fake and a true Message 8. However, with nouns2’s help, user can compare the Message
8’s nouns2 to Message 7’s nouns2 to check if the message was sent from the server or not because
only the user and the server have the randomized nouns2.
Thus, if the two nouns2s are not the same, the user is assured that the Message 8 is fake.

Contact: 6260651575, 9179357477
CHAPTER 8
CONCLUSION & FUTURE ENHANCEMENT
8.1 CONCLUSION
In this thesis, new solutions to the security, computation, and data issues in Cloud have been
presented: the GPU MapReduce framework enhances the performance of data parallel problems
in Cloud; the P-CP-ABE aims at the issues of data security and access control in Cloud; and, the
strong network authentication protocol suite targets at the difficulties of authenticity and
repudiation in Cloud, which is built on top of multi tenancy and service oriented architecture.
According to the experimental results, solutions have been proved to be relatively better than
traditional mechanisms in the given scenarios.
The designing purposes of the GPU MapReduce framework are illustrated as follows: taking
advantages of GPU architecture as much as possible; reducing communication overhead and
making threads independent to each other as much as possible; hiding memory latency by
launching a large number of threads with a large enough problem size; decomposing the inputs as
even as possible; and reducing both local and global synchronizations as much as possible.

Contact: 6260651575, 9179357477
8.2 FUTURE ENHANCEMENTS
Traditional encryption algorithms (both symmetric and asymmetric ones) fail to support Cloud
well due to their severe issues such as complex key management and heavy redundancy. CP-ABE
scheme overcomes the aforementioned issues and provides fine-grained access control as well as
deduplication features. But, its high complexity has prevented it from being widely adopted. On
the other hand, P-CPABE scheme addresses the performance issues by parallelizing CP-ABE and
porting it to multi-core architecture machines. Major performance bottlenecks such as key
management and encryption/decryption processes are identified and accelerated.
Moreover, New AES encryption operation mode is adopted for further performance gains as well.
The strong network authentication protocol suite includes three identities: central authenticator
(CA), servers, and users. In addition, the protocol suite assumes neither user nor server trusts each
by communicating on top of the insecure network; and, both the user and server have CA’s public
key. Because of P-CP-ABE, CA, users, and servers share only one copy of public key, all public
keys in the infrastructure will be certified if CA’s public key is certified. Consequently, the burden
of key management in the infrastructure is relieved.

Contact: 6260651575, 9179357477
APPENDIX: CODE FILES
GPUMapReduce.cu
#include <stdio.h>
#include <unistd.h>
#include <time.h>
#include <sys/time.h>
#include <cuda_runtime.h>
#include <cuda_profiler_api.h>
#define THREADOFBLOCK 1024
#define MAX_HASH 251
#define LINESIZE 256
#define SPLITOR ' '
#define STRINGSIZE 32
#define SAMPLESIZE 128
#define KEYTABLESIZE 64
__device__ int ha[] = {
3 , 5 , 7 , 11 , 13 , 17 , 19 , 23 , 67 ,
29 , 31 , 37 , 41 , 43 , 47 , 53 , 59 , 61 , 109 ,
71 , 73 , 79 , 83 , 89 , 97 , 101 , 103 , 107 , 167 ,
113 , 127 , 131 , 137 , 139 , 149 , 151 , 157 , 163 , 227 ,
173 , 179 , 181 , 191 , 193 , 197 , 199 , 211 , 223 , 277 ,
229 , 233 , 239 , 241 , 251 , 257 , 263 , 269 , 271 , 347 ,
281 , 283 , 293 , 307 , 311 , 313 , 317 , 331 , 337 , 401 ,
349 , 353 , 359 , 367 , 373 , 379 , 383 , 389 , 397 , 461 ,
409 , 419 , 421 , 431 , 433 , 439 , 443 , 449 , 457 , 523 ,
463 , 467 , 479 , 487 , 491 , 499 , 503 , 509 , 521 , 599 ,
541 , 547 , 557 , 563 , 569 , 571 , 577 , 587 , 593 , 653 ,
601 , 607 , 613 , 617 , 619 , 631 , 641 , 643 , 647 , 727 ,
659 , 661 , 673 , 677 , 683 , 691 , 701 , 709 , 719 , 797 ,
733 , 739 , 743 , 751 , 757 , 761 , 769 , 773 , 787 , 859 ,
809 , 811 , 821 , 823 , 827 , 829 , 839 , 853 , 857 , 937 ,
863 , 877 , 881 , 883 , 887 , 907 , 911 , 919 , 929 , 997 ,
941 , 947 , 953 , 967 , 971 , 977 , 983 , 991
};
struct reduceResult{
char key[STRINGSIZE];
int value;
Contact: 6260651575, 9179357477
};
struct mapResult{
char *key;
int len;
int value;
unsigned int hash;
};
struct keyTable{
char *key;
unsigned int len;
unsigned int size;
unsigned int offset;
unsigned int offset2;
};
__host__ __device__ void reduce(struct mapResult** mr, int len, struct
reduceResult* rr){
unsigned int count = 0;
for(int i = 0; i < len; i++){
count += mr[i]->value;
}
memcpy(rr->key, mr[0]->key, mr[0]->len);
rr->value = count;
68
}
__host__ __device__ void map(char* data, unsigned int length, struct
mapResult* mrArray, unsigned
int& used){
used = 0;
char* p = data;
int j = 0;
for(int i = 0; i < length; i++){
if(p[i] < 65 || p[i] > 122 || (p[i] > 90 && p[i] < 97)){
if(i > j){
mrArray[used].key = &p[j];
p[i] = '\0';
mrArray[used].value = 1;
mrArray[used].len = i - j;
for(int k = 0; k < mrArray[used].len; k++){
mrArray[used].hash += (ha[k] * mrArray[used].key[k]) % MAX_HASH;
}
Contact: 6260651575, 9179357477
mrArray[used].hash %= MAX_HASH;
used++;
}
j = i+1;
}else if(p[i] >= 65 && p[i] <= 90){
p[i] += 32;
}
}
}
__global__ void mapKernel1(const unsigned int firstKernel, unsigned
int* lastThread, char
*input, unsigned int len, struct mapResult *d_intermediate_results,
unsigned int *d_used, unsigned
int* subSums, unsigned int* sum){
__shared__ unsigned int subSum;
unsigned int thread = blockDim.x * blockIdx.x + threadIdx.x;
unsigned int used = 0;
if(threadIdx.x == 0){
subSum = 0;
}
__syncthreads();
unsigned int start = thread * LINESIZE;
unsigned int end = (thread + 1) * LINESIZE;
if(start < len){
if(firstKernel != 1 || thread != 0){
while(input[start] != SPLITOR){
start++;
}
if(input[start] == SPLITOR){
start++;
}
}
if(end >= len){
end = len;
*lastThread = thread;
}else{
while(input[end] != SPLITOR){
end++;
if(end >= len){
end = len;
Contact: 6260651575, 9179357477
*lastThread = thread;
break;
}
}
}
int myLen = end - start;
if(myLen > 0){
69
myLen++;
struct mapResult* mr = d_intermediate_results + (thread * SAMPLESIZE);
map(&input[start], myLen, mr, used);
d_used[thread] = used;
atomicAdd(&subSum, used);
}
}
__syncthreads();
subSums[blockIdx.x] = subSum;
atomicAdd(sum, subSum);
}
}
__global__ void mapKernel2(unsigned int *lastThread, unsigned int*
subSums, struct mapResult
*d_intermediate_results, unsigned int *d_used, struct mapResult
**d_addr_table, unsigned int
*d_working_space, unsigned int *d_hash_offsets, unsigned int
*d_hash_sizes){
__shared__ unsigned int hashRequired[MAX_HASH];
if(threadIdx.x < MAX_HASH){
hashRequired[threadIdx.x] = 0;
}
__syncthreads();
if(thread <= *lastThread){
unsigned int *location = d_working_space + (thread * MAX_HASH);
for(int i = 0; i < d_used[thread]; i++){
location[mr[i].hash]++;
}
for(int i = 0; i < MAX_HASH; i++){
Contact: 6260651575, 9179357477
atomicAdd(&hashRequired[i], location[i]);
}
}
__syncthreads();
if(threadIdx.x < MAX_HASH){
unsigned int *location = d_working_space + (blockDim.x * blockIdx.x *
MAX_HASH);
unsigned int sum = 0;
for(int i = 0; i < blockDim.x; i++){
unsigned int locationBak = location[threadIdx.x + (i * MAX_HASH)];
location[threadIdx.x + (i * MAX_HASH)] = sum;
sum += locationBak;
}
}
__syncthreads();
d_hash_sizes[blockIdx.x * MAX_HASH + i] = hashRequired[i];
d_hash_offsets[blockIdx.x * MAX_HASH + i] = sum;
hashRequired[i] = sum;
sum += d_hash_sizes[blockIdx.x * MAX_HASH + i];
}
}
__syncthreads();
if(thread <= *lastThread){
unsigned int hashCounts[MAX_HASH];
hashCounts[i] = 0;
}
unsigned int blockOffset = subSums[blockIdx.x];
unsigned int * threadOffset = d_working_space + (thread * MAX_HASH);
70
for(int i = 0; i < d_used[thread]; i++){
unsigned int hashOffset = hashRequired[mr[i].hash];
unsigned int offset = blockOffset + hashOffset +
threadOffset[mr[i].hash] + hash-
Counts[mr[i].hash];
d_addr_table[offset] = &mr[i];
Contact: 6260651575, 9179357477
hashCounts[mr[i].hash]++;
}
}
}
__host__ __device__ int existing_key(char* key1, unsigned int len1,
char* key2, unsigned int
len2){
int result = 1;
if(len1 == len2){
for(int i = 0; i < len1; i++){
if(key1[i] != key2[i]){
result = 0;
break;
}
}
}else{
result = 0;
}
return result;
}
__global__ void reduceKernel1(struct mapResult **d_addr_table,
unsigned int* d_subSums, unsigned
int* d_hash_offsets, unsigned int* d_hash_sizes, struct keyTable* kt,
struct mapResult
**d_finalAddrTable, struct reduceResult* rr){
__shared__ unsigned int sharedUsed;
__shared__ struct keyTable ktArray[KEYTABLESIZE];
__shared__ unsigned int myHashOffset;
unsigned int blockOffset = d_subSums[threadIdx.x];
unsigned int hashOffset = d_hash_offsets[threadIdx.x * MAX_HASH +
blockIdx.x];
unsigned int hashSize = d_hash_sizes[threadIdx.x * MAX_HASH +
blockIdx.x];
struct mapResult **mr = d_addr_table + (blockOffset + hashOffset);
myHashOffset = 0;
memset(ktArray, 0, sizeof(struct keyTable) * KEYTABLESIZE);
}
unsigned int localSum = 0;
Contact: 6260651575, 9179357477
for(int i = 0; i < blockIdx.x; i++){

localSum += d_hash_sizes[threadIdx.x * MAX_HASH + i];
}
atomicAdd(&myHashOffset, localSum);
__syncthreads();
struct mapResult **mr2 = d_finalAddrTable + (myHashOffset);
unsigned int offset = thread * KEYTABLESIZE;
struct keyTable* kt2 = kt + (offset);
for(int i = 0; i < hashSize; i++){
int exist = 0;
for(int j = 0; j < used; j++){
if(existing_key(kt2[j].key, kt2[j].len, mr[i]->key, mr[i]->len) == 1){
kt2[j].size++;
exist = 1;
break;
}
}
if(exist == 0){
kt2[used].key = mr[i]->key;
71
kt2[used].len = mr[i]->len;
kt2[used].size = 1;
used++;
}
}
__syncthreads();
unsigned int offset = blockDim.x * blockIdx.x * KEYTABLESIZE;
for(int i = 0; i < blockDim.x; i++){
for(int j = 0; j < KEYTABLESIZE; j++){
if(kt[offset + i * KEYTABLESIZE +j].key != NULL){
int exist = 0;
for(int k = 0; k < used; k++){
if(existing_key(kt[offset + i * KEYTABLESIZE + j].key, kt[offset + i *
KEYTABLESIZE +
j].len, ktArray[k].key, ktArray[k].len) == 1){
ktArray[k].size += kt[offset + i * KEYTABLESIZE +j].size;
exist = 1;
Contact: 6260651575, 9179357477
break;
}
}
if(exist == 0){
ktArray[used].key = kt[offset + i * KEYTABLESIZE +j].key;
ktArray[used].len = kt[offset + i * KEYTABLESIZE +j].len;
ktArray[used].size = kt[offset + i * KEYTABLESIZE +j].size;
used++;
}
}else{
break;
}
}
}
sharedUsed = used;
for(int i = 0; i < used; i++){
unsigned int tmp = ktArray[i].size;
ktArray[i].offset = sum;
ktArray[i].offset2 = sum;
sum += tmp;
}
}
__syncthreads();
for(int i = 0; i < hashSize; i++){
for(int j = 0; j < sharedUsed; j++){
if(existing_key(mr[i]->key, mr[i]->len, ktArray[j].key,
ktArray[j].len) == 1){
unsigned int oldOffset = atomicAdd(&ktArray[j].offset2, 1);
mr2[oldOffset] = mr[i];
break;
}
}
}
__syncthreads();
if(threadIdx.x < sharedUsed){
struct mapResult **mr3 = mr2 + (ktArray[threadIdx.x].offset);
reduce(mr3, ktArray[threadIdx.x].size, &rr[blockIdx.x * KEYTABLESIZE +
threadIdx.x]);
}
Contact: 6260651575, 9179357477
}
int main(int argc, char* argv[]){
FILE *fp;
fp = fopen(argv[1], "r");
if(fp == NULL){
72
exit(1);
}
fseek(fp, 0, SEEK_END);
unsigned int fileSize = ftell(fp);
rewind(fp);
char *h_in_data = (char*) malloc(fileSize * sizeof(char) + 1);
ssize_t readSize = fread(h_in_data, sizeof(char), fileSize, fp);
h_in_data[readSize] = '\0';
printf("file size = %d \t read size = %d \t %d blocks/grid \t %d
threads/block\n", fileSize,
readSize, fileSize/(THREADOFBLOCK*LINESIZE)+1, THREADOFBLOCK);
if(fileSize != readSize){
printf("fileSize != readSize\n");
exit(1);
}
cudaError_t error1;
char *d_in_data;
error1 = cudaMalloc( (void**)&d_in_data, fileSize * sizeof(char) + 1);
unsigned int BLOCKOFGRID = (fileSize/(THREADOFBLOCK*LINESIZE))+1;
printf("sizeof(d_in_data) = %uMB \t error = %s\n",(fileSize *
sizeof(char) + 1)/(1024*1024) ,
cudaGetErrorString(error1));
cudaError_t error2;
unsigned int *d_sum;
error2 = cudaMalloc((void**)&d_sum, sizeof(unsigned int));
cudaMemset(d_sum, 0, sizeof(unsigned int));
printf("sizeof(d_sum) = %uB \t error = %s\n",sizeof(unsigned int) ,
cudaGetError-
String(error2));
cudaError_t error3;
unsigned int *d_subSums;
error3 = cudaMalloc((void**)&d_subSums, sizeof(unsigned int) *
BLOCKOFGRID);
cudaMemset(d_subSums, 0, sizeof(unsigned int) * BLOCKOFGRID);
Contact: 6260651575, 9179357477
printf("sizeof(d_subSums) = %uB \t error = %s\n",(sizeof(unsigned int)

* BLOCKOFGRID) ,
cudaEvent_t start, stop;
cudaEventCreate(&start);
cudaEventCreate(&stop);
cudaEventRecord(start, 0);
cudaMemcpy( d_in_data, h_in_data, fileSize * sizeof(char) + 1,
cudaMemcpyHostToDevice );
cudaError_t error4;
unsigned int *d_used;
error4 = cudaMalloc((void**)&d_used, sizeof(unsigned int) *
BLOCKOFGRID * THREADOFBLOCK);
cudaMemset(d_used, 0, sizeof(unsigned int) * BLOCKOFGRID *
THREADOFBLOCK);
printf("sizeof(d_used) = %uKB \t error = %s\n",(sizeof(unsigned int) *
BLOCKOFGRID *
THREADOFBLOCK)/(1024) , cudaGetErrorString(error4));
cudaError_t error5;
struct mapResult *d_intermediate_results;
error5 = cudaMalloc((void**)&d_intermediate_results, sizeof(struct
mapResult) * BLOCKOFGRID *
THREADOFBLOCK * SAMPLESIZE);
cudaMemset(d_intermediate_results, 0, sizeof(struct mapResult) *
BLOCKOFGRID * THREADOFBLOCK
* SAMPLESIZE);
printf("sizeof(d_intermediate_results) = %uMB \t error =
%s\n",(sizeof(struct mapResult) *
BLOCKOFGRID * THREADOFBLOCK * SAMPLESIZE)/(1024*1024) ,
cudaError_t error6;
unsigned int *lastThread;
error6 = cudaMalloc((void**)&lastThread, sizeof(unsigned int));
cudaMemset(lastThread, 0, sizeof(unsigned int));
printf("sizeof(lastThread) = %uB \t error = %s\n",sizeof(unsigned int)
, cudaGetError-
String(error6));
mapKernel1<<<BLOCKOFGRID, THREADOFBLOCK>>>(1, lastThread, d_in_data,
fileSize,
d_intermediate_results, d_used, d_subSums, d_sum);
Contact: 6260651575, 9179357477
unsigned int *h_sum = (unsigned int*)malloc(sizeof(unsigned int));

cudaMemcpy( h_sum, d_sum, sizeof(unsigned int), cudaMemcpyDeviceToHost
);
73
cudaFree(d_sum);
printf("sum = %u\n", *h_sum);
unsigned int *h_subSums = (unsigned int*) malloc(sizeof(unsigned int)
* BLOCKOFGRID);
cudaMemcpy( h_subSums, d_subSums, sizeof(unsigned int) * BLOCKOFGRID,
cudaMemcpyDeviceToHost
);
unsigned int offset = 0;
for(int i = 0; i < BLOCKOFGRID; i++){
unsigned int offsetBak = h_subSums[i];
h_subSums[i] = offset;
offset+= offsetBak;
}
cudaMemcpy( d_subSums, h_subSums, sizeof(unsigned int) * BLOCKOFGRID,
cudaMemcpyHostToDevice
);
free(h_subSums);
cudaError_t error7;
struct mapResult **d_addr_table;
error7 = cudaMalloc((void**)&d_addr_table, *(h_sum) * sizeof(struct
mapResult*));
cudaMemset(d_addr_table, 0, *(h_sum) * sizeof(struct mapResult*));
printf("sizeof(d_addr_table) = %uMB \t error = %s\n",(*(h_sum) *
sizeof(struct mapResult*))/(
1024*1024) , cudaGetErrorString(error7));
cudaError_t error8;
unsigned int *d_working_space;
error8 = cudaMalloc((void**)&d_working_space, MAX_HASH * BLOCKOFGRID *
THREADOFBLOCK *
sizeof(unsigned int));
cudaMemset(d_working_space, 0, MAX_HASH * BLOCKOFGRID * THREADOFBLOCK
* sizeof(unsigned
int));
printf("sizeof(d_working_space) = %uMB \t error = %s\n",(MAX_HASH *
BLOCKOFGRID *

Contact: 6260651575, 9179357477
THREADOFBLOCK * sizeof(unsigned int))/(1024*1024) ,

cudaError_t error9;
unsigned int *d_hash_offsets;
error9 = cudaMalloc((void**)&d_hash_offsets, MAX_HASH * BLOCKOFGRID *
cudaMemset(d_hash_offsets, 0, MAX_HASH * BLOCKOFGRID * sizeof(unsigned
int));
printf("sizeof(d_hash_offsets) = %uKB \t error = %s\n",(MAX_HASH *
BLOCKOFGRID *
sizeof(unsigned int))/(1024) , cudaGetErrorString(error9));
cudaError_t error10;
unsigned int *d_hash_sizes;
error10 = cudaMalloc((void**)&d_hash_sizes, MAX_HASH * BLOCKOFGRID *
cudaMemset(d_hash_sizes, 0, MAX_HASH * BLOCKOFGRID * sizeof(unsigned
int));
printf("sizeof(d_hash_sizes) = %uKB \t error = %s\n",(MAX_HASH *
BLOCKOFGRID *
sizeof(unsigned int))/(1024) , cudaGetErrorString(error10));
mapKernel2<<<BLOCKOFGRID, THREADOFBLOCK>>>(lastThread, d_subSums,
d_intermediate_results,
d_used, d_addr_table, d_working_space, d_hash_offsets, d_hash_sizes);
cudaFree(d_working_space);
cudaFree(lastThread);
cudaFree(d_used);
struct keyTable* kt;
error11 = cudaMalloc((void**)&kt, MAX_HASH * BLOCKOFGRID *
KEYTABLESIZE * sizeof(struct key-
Table));
cudaMemset(kt, 0, MAX_HASH * BLOCKOFGRID * KEYTABLESIZE *
sizeof(struct keyTable));
printf("sizeof(kt) = %uMB \t error = %s\n",(MAX_HASH * BLOCKOFGRID *
KEYTABLESIZE *
sizeof(struct keyTable))/(1024*1024) , cudaGetErrorString(error11));
struct mapResult **d_finalAddrTable;
error12 = cudaMalloc((void**)&d_finalAddrTable, *(h_sum) *
sizeof(struct mapResult*));
Contact: 6260651575, 9179357477
cudaMemset(d_finalAddrTable, 0, *(h_sum) * sizeof(struct mapResult*));

printf("sizeof(d_finalAddrTable) = %uMB \t error = %s\n",(*(h_sum) *
sizeof(struct mapResult*))/(
1024*1024) , cudaGetErrorString(error12));
struct reduceResult* rr;
error13 = cudaMalloc((void**)&rr, MAX_HASH * KEYTABLESIZE *
sizeof(struct reduceResult));
74
cudaMemset(rr, 0, MAX_HASH * KEYTABLESIZE * sizeof(struct
reduceResult));
printf("sizeof(rr) = %uKB \t error = %s\n",(MAX_HASH * KEYTABLESIZE *
sizeof(struct reduceResult))/(
1024) , cudaGetErrorString(error13));
reduceKernel1<<<MAX_HASH, BLOCKOFGRID>>>(d_addr_table, d_subSums,
d_hash_offsets,
d_hash_sizes, kt, d_finalAddrTable, rr);
struct reduceResult* results = (struct reduceResult*) malloc(MAX_HASH
* KEYTABLESIZE *
sizeof(struct reduceResult));
cudaMemcpy( results, rr, MAX_HASH * KEYTABLESIZE * sizeof(struct
reduceResult), cudaMemcpyDeviceToHost
);
for(int i = 0; i < MAX_HASH * KEYTABLESIZE; i++){
if(results[i].value > 0)
printf("%s = %u\n", results[i].key, results[i].value);
}
cudaFree(d_in_data);
cudaFree(d_intermediate_results);
cudaFree(d_addr_table);
cudaFree(d_subSums);
cudaFree(d_hash_offsets);
cudaFree(d_hash_sizes);
cudaFree(kt);
cudaFree(d_finalAddrTable);
cudaFree(rr);
cudaEventRecord(stop, 0);
cudaEventSynchronize(stop);
float t;
cudaEventElapsedTime(&t, start, stop);
Contact: 6260651575, 9179357477
printf("cudaEventElapsedTime = %f\n", t);

free(h_in_data);
return 0;
}
75
Authentication_ca.c
#include <stdio.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <fcntl.h>
#include <stdlib.h>
#include <string.h>
#include <strings.h>
#include <glib.h>
#include <pbc.h>
#include <pbc_random.h>
#include <openssl/sha.h>
#include "bswabe.h"
#include "../common.h"
#include "../policy_lang.h"
char pub_file[] = "pub_key";
char msk_file[] = "master_key";
char** attrs = 0;
char* out_file;
gint
comp_string( gconstpointer a, gconstpointer b)
{
return strcmp(a, b);
}
int
main( int argc, char** argv )
{
if( !strcmp(argv[0], "-d") || !strcmp(argv[0], "--deterministic") ){
printf("NO");
pbc_random_set_deterministic(0);
}
int fd = 0;
Contact: 6260651575, 9179357477
struct sockaddr_in addr;

socklen_t addrlen;
memset(&addr, '\0', sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_port = htons(16000);
addr.sin_addr.s_addr = htonl(INADDR_ANY);
if((fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0){
perror("socket()");
sleep(60);
}
int tr = 1;
if(setsockopt(fd,SOL_SOCKET,SO_REUSEADDR,&tr,sizeof(tr)) == -1){
perror("setsockopt()");
sleep(60);
}
if(bind(fd, (struct sockaddr*) &addr, sizeof(addr)) < 0){
perror("bind()");
close(fd);
sleep(60);
}
if(listen(fd, SOMAXCONN) < 0){
perror("listen()");
close(fd);
sleep(60);
}
while(1){
76
int clientFD = 0;
struct sockaddr_in clientADDR;
socklen_t clientADDRLEN;
char clientNAME[INET_ADDRSTRLEN];
memset(&clientADDR, '\0', sizeof(clientADDR));
memset(&clientNAME, '\0', sizeof(clientNAME));
clientADDRLEN = sizeof(clientADDR);
if((clientFD = accept(fd, (struct sockaddr*)&clientADDR,
&clientADDRLEN)) < 0){
perror("accept()");
}else{
if(inet_ntop(AF_INET, &clientADDR.sin_addr.s_addr, clientNAME,
sizeof(clientNAME)) ==
Contact: 6260651575, 9179357477
NULL){
perror("inet_ntop()");
}else{
printf("ClientIP = %s\n", clientNAME);
struct timeval tv;
tv.tv_sec = 3;
tv.tv_usec = 0;
setsockopt(clientFD, SOL_SOCKET, SO_RCVTIMEO, (char*)&tv,sizeof(tv));
setsockopt(clientFD, SOL_SOCKET, SO_SNDTIMEO, (char*)&tv,sizeof(tv));
char tmp[1024];
memset(tmp, '\0', 1024);
char data[1024];
memset(data, '\0', 1024);
int n = 0;
int all = 0;
n = read(clientFD, tmp, 1023);
sscanf(tmp, "%d\n", &all);
printf("all = %d\n", all);
printf("n = %d\n", n);
int a = 0;
int b = all;
while(b > 1){
b /= 10;
a++;
}
a++;
printf("a = %d\n", a);
char* p = (char*) malloc(all+a+1);
char* p0 = p;
memset(p, '\0', all+a+1);
memcpy(p, tmp, n);
p += n;
int np = n;
while(np < all+a){
n = 0;
np += n;
memcpy(p, tmp, n);
p += n;
}
Contact: 6260651575, 9179357477
printf("np = %d\n", np);

char* p1 = p0;
char* p2 = p0;
int i = 0;
all = 0;
int size1 = 0;
int size2 = 0;
char tmp1[1024];
char tmp2[1024];
memset(tmp1, '\0', 1024);
77
memset(tmp2, '\0', 1024);
sscanf(p0, "%d\n%d\n%d\n", &all, &size1, &size2);
printf("%d\n%d\n%d\n", all, size1, size2);
p1 = strstr(p0, "\n\n");
p1 += 2;
char* first = (char*) malloc(size1 + 1);
char* second = (char*) malloc(size2 + 1);
memset(first, '\0', size1 + 1);
memset(second, '\0', size2 + 1);
memcpy(first, p1, size1);
p1 += size1;
memcpy(second, p1, size2);
char prv_file[] = "CA.pr";
bswabe_pub_t* pub;
bswabe_prv_t* prv;
int file_len;
GByteArray* aes_buf;
GByteArray* plt;
GByteArray* cph_buf;
bswabe_cph_t* cph;
element_t m;
pub = bswabe_pub_unserialize(suck_file(pub_file), 1);
prv = bswabe_prv_unserialize(pub, suck_file(prv_file), 1);
read_cpabe_tmpfile(&cph_buf, &file_len, &aes_buf, first, size1);
cph = bswabe_cph_unserialize(pub, cph_buf, 1);
if( !bswabe_dec(pub, prv, cph, m) )
die("%s", bswabe_error());
bswabe_cph_free(cph);
plt = aes_128_ctr(aes_buf, m, 0);
Contact: 6260651575, 9179357477
g_byte_array_set_size(plt, file_len);
memcpy(tmp2, plt->data, file_len);
char sessionkey[17];
char nouns1[17];
memset(sessionkey, '\0', 17);
memset(nouns1, '\0', 17);
sscanf(tmp2, "%s %s", sessionkey, nouns1);
printf("sessionkey = %s \t nouns1 = %s\n", sessionkey, nouns1);
GByteArray* at;
at = g_byte_array_new();
g_byte_array_set_size(at, size2);
memcpy(at->data, second, size2);
aes_buf = aes_128_ctr(at, m, sessionkey);
char* tmp3 = (char*) malloc(aes_buf->len + 1);
memset(tmp3, '\0', aes_buf->len + 1);
memcpy(tmp3, aes_buf->data, aes_buf->len);
char nouns1p[17];
unsigned int time1;
char command[100];
char entity[100];
char auxiliary[100];
memset(nouns1p, '\0', 17);
memset(command, '\0', 100);
memset(entity, '\0', 100);
memset(auxiliary, '\0', 100);
sscanf(tmp3, "%s %d %s %s %s", nouns1p, &time1, command, entity,
auxiliary);
printf("%s \t%d \t%s \t%s \t%s\n", nouns1p, time1, command, entity,
auxiliary);
unsigned int t = (unsigned)time(NULL);
printf("t = %u\n", t);
if(time1 <= t + 100 && time1 >= t - 100){
printf("time checked OK.\t It is not replayed.\n");
78
if(strcmp(nouns1, nouns1p) == 0){
printf("nouns1(%s) checked OK. \t It is not modified or man in
middle.\n", nouns1);
if(strcmp(command, "REGSERVER") == 0){
}else{
FILE* fp;
Contact: 6260651575, 9179357477
fp = fopen("users.data", "r");
while (!feof(fp)) {
char line[100];
memset(line, '\0', 100);
if(fgets(line,100, fp) != NULL){
char u1[100];
char p1[100];
char i1[100];
memset(u1, '\0', 100);
memset(p1, '\0', 100);
memset(i1, '\0', 100);
sscanf(line, "%s %s %s", u1, p1, i1);
unsigned char obuf[SHA_DIGEST_LENGTH];
char pass[SHA_DIGEST_LENGTH * 2 + 1];
memset(obuf, '\0', SHA_DIGEST_LENGTH);
memset(pass, '\0', SHA_DIGEST_LENGTH);
SHA1(p1, strlen(p1), obuf);
for (i = 0; i < SHA_DIGEST_LENGTH; i++) {
sprintf(&pass[i*2], "%02x", obuf[i]);
}
printf("SHA = %s\n", pass);
if(strcmp(entity, u1) == 0 && strcmp(auxiliary, pass) == 0 &&
strcmp(i1, clientNAME)
== 0){
printf("user's name, password, and IP checked OK. \t It is authorized
by the user.
\n");
if(strcmp(command, "PK") == 0){
struct timeval start1, end1, diff1;
gettimeofday(&start1, NULL);
char* name = u1;
out_file = name;
char date[20];
memset(date, '\0', 20);
sprintf(date, "date = %u", (unsigned)time(NULL));
printf("%s\n", date);
int i = 0;
GSList* alist = 0;
GSList* ap = 0;
int n = 0;
Contact: 6260651575, 9179357477
parse_attribute(&alist, name);
parse_attribute(&alist, date);
alist = g_slist_sort(alist, comp_string);
n = g_slist_length(alist);
attrs = malloc((n + 1) * sizeof(char*));
i = 0;
for( ap = alist; ap; ap = ap->next )
attrs[i++] = ap->data;
attrs[i] = 0;
bswabe_pub_t* pub;
bswabe_msk_t* msk;
bswabe_prv_t* prv;
msk = bswabe_msk_unserialize(pub, suck_file(msk_file), 1);
prv = bswabe_keygen(pub, msk, attrs);
GByteArray* b = bswabe_prv_serialize(prv);
printf("len = %d\t", b->len);
g_byte_array_prepend(b, nouns1, strlen(nouns1));
79
aes_buf = aes_128_ctr(b, m, sessionkey);
memset(tmp2, '\0', 1024);
sprintf(tmp2, "%d\n", b->len);
g_byte_array_prepend(aes_buf, tmp2, strlen(tmp2));
printf("len = %d\n", aes_buf->len);
printf("aes_buf = %s\n", aes_buf->data);
int nw = write(clientFD, aes_buf->data, aes_buf->len);
if(nw == aes_buf->len){
printf("Send private key %d bytes to client successful.\n", nw);
}
g_byte_array_free(aes_buf, 1);
gettimeofday(&end1, NULL);
timersub(&end1, &start1, &diff1);
printf("Keygen() spent %ld sec and %ld micro sec.\n", diff1.tv_sec,
diff1.tv_usec);
free(attrs);
g_slist_free(alist);
}else{
FILE* fp2;
fp2 = fopen("servers.data", "r");
while (!feof(fp2)) {
Contact: 6260651575, 9179357477
char line2[100];
memset(line2, '\0', 100);
if(fgets(line2,100, fp2) != NULL){
char servernamex[100];
char serveripx[100];
char serverkeyx[100];
memset(servernamex, '\0', 100);
memset(serveripx, '\0', 100);
memset(serverkeyx, '\0', 100);
sscanf(line2, "%s %s %s", servernamex, serveripx, serverkeyx);
printf("servernamex = %s\tserveripx = %s\tserverkeyx = %s\n",
servernamex,
serveripx, serverkeyx);
if(strcmp(command, servernamex) == 0){
printf("Server's name check OK.\n");
char sessionkeyx[17];
memset(sessionkeyx, '\0', 17);
char nouns2[17];
srand(time(NULL) + time(NULL));
for(i = 0; i < 16; i++){
sessionkeyx[i] = (rand() % 26) + 97;
nouns2[i] = (rand() % 26) + 97;
}
printf("sessionkeyx = %s\tnouns2 = %s\tcommand = %s\n", sessionkeyx,
nouns2,
command);
char o1[1024];
memset(o1, '\0', 1024);
sprintf(o1, "%s %s %s %s %s", nouns1, nouns2, sessionkeyx,
servernamex, serveripx);
printf("o1 = %s\n", o1);
GByteArray* at;
g_byte_array_set_size(at, strlen(o1));
memcpy(at->data, o1, strlen(o1));
char ticket[1024];
memset(ticket, '\0', 1024);

Contact: 6260651575, 9179357477
sprintf(ticket, "%s %s %s %s %s %u", nouns2, sessionkeyx, u1, i1,

servernamex,
(unsigned)time(NULL) + 86400);
printf("ticket = %s\n", ticket);
GByteArray* aes_buf2;
80
GByteArray* at2;
at2 = g_byte_array_new();
g_byte_array_set_size(at2, strlen(ticket));
memcpy(at2->data, ticket, strlen(ticket));
aes_buf2 = aes_128_ctr(at2, m, serverkeyx);
char strn1[100];
memset(strn1, '\0', 100);
sprintf(strn1, "%d\n", aes_buf->len);
char strn2[100];
sprintf(strn2, "%d\n\n", aes_buf2->len);
char strn0[100];
sprintf(strn0, "%d\n", aes_buf->len + aes_buf2->len + strlen(strn1) +
strlen(strn2));
printf("strn0 = %sstrn1 = %sstrn2 = %s\n", strn0, strn1, strn2);
int n0 = write(clientFD, strn0, strlen(strn0));
int n3 = write(clientFD, aes_buf->data, aes_buf->len);
int n4 = write(clientFD, aes_buf2->data, aes_buf2->len);
printf("n0 = %d\tn1 = %d\t n2 = %d \t n3 = %d \t n4 = %d\n",
strlen(strn0),
strlen(strn1), strlen(strn2), aes_buf->len, aes_buf2->len);
printf("n0 = %d\tn1 = %d\t n2 = %d \t n3 = %d \t n4 = %d\n", n0, n1,
n2, n3,
n4);
g_byte_array_free(aes_buf2, 1);
break;
}
}
}
fclose(fp2);
Contact: 6260651575, 9179357477
}
close(clientFD);
break;
}
}
}
fclose(fp);
}
}
}
}
}
}
close(fd);
return 0;
}
81
Authentication_client.c
#include <string.h>
#include <netdb.h>
#include <fcntl.h>
#include <unistd.h>
#include <glib.h>
#include <pbc.h>
#include "bswabe.h"
char pub_file[] = "pub_key";
char in_file[100];// = "komodo.tar.gz";
char out_file[100];// = "komodo.tar.gz.cpabe";
char prv_file[100];
int keep = 0;
char* policy = 0;
GByteArray* plt;
Contact: 6260651575, 9179357477
void* encThread(void* a){

struct timeval start1, end1, diff1;
plt = suck_file(in_file);
gettimeofday(&end1, NULL);
timersub(&end1, &start1, &diff1);
printf("readfile() spent %ld sec and %ld micro sec.\n", diff1.tv_sec,
diff1.tv_usec);
pthread_exit(0);
}
int
main( int argc, char** argv )
{
if( !strcmp(argv[0], "-d") || !strcmp(argv[0], "--deterministic") ){
pbc_random_set_deterministic(0);
}
char user[100];
memset(user, '\0', 100);
char ibuf[100];
memset(ibuf, '\0', 100);
char servername[100];
memset(servername, '\0', 100);
char serverticketname[100];
memset(serverticketname, '\0', 100);
element_t m;
pthread_t hThread;
printf("Function lists: \n");
printf("1. Generate private key.\n");
printf("2. Apply storage server.\n");
printf("3. Encrypt file.\n");
printf("4. Decrypt file.\n");
printf("5. Send file to storage server.\n");
printf("6. Get file from storage server.\n");
int menu = 0;
scanf("%d", &menu);
switch (menu){
case 1:
printf("Input user's name: \t");
scanf("%s", user);
82
Contact: 6260651575, 9179357477
printf("Input user's password: \t");

scanf("%s", ibuf);
break;
case 2:
scanf("%s", user);
scanf("%s", ibuf);
printf("Input servername: \t");
scanf("%s", servername);
break;
case 3:
memset(in_file, '\0', 100);
memset(out_file, '\0', 100);
printf("Input file's name: \t");
scanf("%s", in_file);
pthread_create(&hThread, NULL, (void*)encThread, (void*)0);
sprintf(out_file, "%s.cpabe", in_file);
printf("Who can decrypt the file? \t");
scanf("%s", user);
break;
case 4:
memset(out_file, '\0', 100);
memset(prv_file, '\0', 100);
if( strlen(in_file) > 6 &&
!strcmp(in_file + strlen(in_file) - 6, ".cpabe") ){
memcpy(out_file, in_file, strlen(in_file) - 6);
printf("out_file = %s\n", out_file);
}
printf("Input private key: \t");
scanf("%s", prv_file);
break;
case 5:
pthread_create(&hThread, NULL, (void*)encThread, (void*)0);
Contact: 6260651575, 9179357477

scanf("%s", user);
scanf("%s", ibuf);
printf("Input server's ticket: \t");
scanf("%s", serverticketname);
break;
case 6:
scanf("%s", user);
scanf("%s", ibuf);
printf("Input server's ticket: \t");
scanf("%s", serverticketname);
break;
}
if(menu == 1 || menu == 2){
bswabe_pub_t* pub;
83
bswabe_cph_t* cph;
int file_len;
char sessionkey[17];
char nouns1[17];
memset(sessionkey, '\0', 17);
srand(time(NULL));
int i = 0;
for(i = 0; i < 16; i++){
sessionkey[i] = (rand() % 26) + 97;
nouns1[i] = (rand() % 26) + 97;
}
char temp[34];
memset(temp, '\0', 34);
sprintf(temp, "%s %s", sessionkey, nouns1);
Contact: 6260651575, 9179357477
plt = g_byte_array_new();
g_byte_array_set_size(plt, strlen(temp));
memcpy(plt->data, temp, strlen(temp));
printf("%s\n", temp);
char ca[] = "CA";
if( !policy )
policy = parse_policy_lang(ca);
if( !(cph = bswabe_enc(pub, m, policy)) )
free(policy);
policy = 0;
cph_buf = bswabe_cph_serialize(cph);
cph = 0;
file_len = plt->len;
aes_buf = aes_128_ctr(plt, m, 0);
element_clear(m);
char* pp = 0;
int n;
write_cpabe_tmpfile(out_file, cph_buf, file_len, aes_buf, &pp, &n);
printf("pp=%s \n n=%d\n", pp, n);
g_byte_array_free(cph_buf, 1);
file_len = 0;
memset(pass, '\0', SHA_DIGEST_LENGTH * 2 + 1);
SHA1(ibuf, strlen(ibuf), obuf);
}
char t[1024];
memset(t, '\0', 1024);
if(menu == 1){
sprintf(t, "%s %u PK %s %s", nouns1, (unsigned)time(NULL), user,
pass);
}else{

Contact: 6260651575, 9179357477
sprintf(t, "%s %u %s %s %s", nouns1, (unsigned)time(NULL), servername,

user, pass);
}
GByteArray* at;
g_byte_array_set_size(at, strlen(t));
84
memcpy(at->data, t, strlen(t));
int fd = 0;
int port = 16000;
char ip[] = "127.0.0.1";
if((fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) > 0){
inet_pton(AF_INET, ip, &addr.sin_addr);
addr.sin_port = htons(port);
if(connect(fd, (struct sockaddr*)&addr, sizeof(addr)) < 0){
close(fd);
}else{
struct timeval tv;
tv.tv_sec = 3;
tv.tv_usec = 0;
setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, (char*)&tv,sizeof(tv));
setsockopt(fd, SOL_SOCKET, SO_SNDTIMEO, (char*)&tv,sizeof(tv));
char strn1[100];
sprintf(strn1, "%d\n", n);
char strn2[100];
sprintf(strn2, "%d\n\n", aes_buf->len);
char strn0[100];
sprintf(strn0, "%d\n", (n + aes_buf->len+strlen(strn1)
+strlen(strn2)));
int n0 = write(fd, strn0, strlen(strn0));
int n3 = write(fd, pp, n);
Contact: 6260651575, 9179357477
int n4 = write(fd, aes_buf->data, aes_buf->len);

strlen(strn0),
strlen(strn1), strlen(strn2), n, aes_buf->len);
n2, n3, n4);
char tmp[1024];
memset(tmp, '\0', 1024);
int n = 0;
int all = 0;
n = read(fd, tmp, 1023);
if(all > 0){
int a = 0;
int b = all;
while(b > 1){
b /= 10;
a++;
}
a++;
char* p0 = p;
memcpy(p, tmp, n);
p += n;
int np = n;
while(np < all+a){
85
n = 0;
np += n;
memcpy(p, tmp, n);
p += n;
}
char* p1 = 0;
Contact: 6260651575, 9179357477
if((p1 = strchr(p0, '\n')) > 0){

p1 += 1;
if(menu == 1){
g_byte_array_set_size(at, all);
memcpy(at->data, p1, all);
char nouns1p[17];
memcpy(nouns1p, aes_buf->data, 16);
printf("nouns1(%s) checked OK. It is not modified or man in middle;
nor fake message.\
n", nouns1);
char* p2 = 0;
p2 = aes_buf->data;
p2 += 16;
GByteArray* s;
s = g_byte_array_new();
g_byte_array_set_size(s, all-16);
memcpy(s->data, p2, all-16);
spit_file(user, s, 1);
}
}else{
int size1 = 0;
int size2 = 0;
sscanf(p1, "%d\n%d\n", &size1, &size2);
printf("size1 = %d\tsize2 = %d\n", size1, size2);
if((p1 = strstr(p1, "\n\n")) > 0){
p1 += 2;
memcpy(at->data, p1, size1);
char nouns1p[17];
char nouns2[17];
Contact: 6260651575, 9179357477

char* tt1 = (char*) malloc(aes_buf->len + 1);
memset(tt1, '\0', aes_buf->len + 1);
memcpy(tt1, aes_buf->data, aes_buf->len);
sscanf(tt1, "%s %s %s %s %s", nouns1p, nouns2, sessionkeyx,
servernamex, serveripx);
printf("%s %s %s %s %s", nouns1p, nouns2, sessionkeyx, servernamex,
serveripx);
if(strcmp(nouns1, nouns1p) == 0 && strcmp(servernamex, servername) ==
0){
printf("Nouns1 and server's name checked OK.\n");
p1 += size1;
GByteArray* at2;
at2 = g_byte_array_new();
86
g_byte_array_set_size(at2, size2);
memcpy(at2->data, p1, size2);
aes_buf = aes_128_ctr(aes_buf, m, pass);
char t0[100];
memset(t0, '\0', 100);
sprintf(t0, "%d\n%d\n\n", size1, size2);
g_byte_array_prepend(at2, aes_buf->data, aes_buf->len);
g_byte_array_prepend(at2, t0, strlen(t0));
char serverticket[100];
memset(serverticket, '\0', 100);
strcpy(serverticket, servernamex);
strcat(serverticket, ".ticket");
spit_file(serverticket, at2, 1);
}
free(tt1);
}
}
}
}
close(fd);
Contact: 6260651575, 9179357477
}
}
}else if(menu == 3){
struct timeval start1, end1, diff1, start2, end2, diff2, start3, end3,
diff3, start4, end4,
diff4, start5, end5, diff5;
bswabe_pub_t* pub;
bswabe_cph_t* cph;
int file_len;
element_t m;
char tmp[100];
memset(tmp, '\0', 100);
sprintf(tmp, "%s and date > %u", user, (unsigned)time(NULL));
printf("tmp = %s\n", tmp);
if( !policy )
policy = parse_policy_lang(tmp);
if( !(cph = bswabe_enc(pub, m, policy)) )
free(policy);
cph_buf = bswabe_cph_serialize(cph);
pthread_join(hThread, NULL);
file_len = plt->len;
aes_buf = aes_128_ctr(plt, m, 0);
element_clear(m);
write_cpabe_file(out_file, cph_buf, file_len, aes_buf);
g_byte_array_free(cph_buf, 1);
if( !keep )
unlink(in_file);
}else if(menu == 4){
bswabe_pub_t* pub;
bswabe_prv_t* prv;
int file_len;
GByteArray* plt;
Contact: 6260651575, 9179357477
87
bswabe_cph_t* cph;
element_t m;
prv = bswabe_prv_unserialize(pub, suck_file(prv_file), 1);
read_cpabe_file(in_file, &cph_buf, &file_len, &aes_buf);
cph = bswabe_cph_unserialize(pub, cph_buf, 1);
if( !bswabe_dec(pub, prv, cph, m) )
plt = aes_128_ctr(aes_buf, m, 0);
g_byte_array_set_size(plt, file_len);
spit_file(out_file, plt, 1);
if( !keep )
unlink(in_file);
}else if(menu == 5 || menu == 6){
FILE* f;
f = fopen(serverticketname, "r");
fseek (f, 0, SEEK_END);
int nf = 0;
nf = ftell(f);
rewind(f);
char *p = (char*) malloc(nf + 1);
memset(p, '\0', nf + 1);
fread(p, 1, nf, f);
fclose(f);
int size1 = 0;
int size2 = 0;
sscanf(p, "%d\n%d\n", &size1, &size2);
char* p0 = 0;
if((p0 = strstr(p, "\n\n")) > 0){
p0 += 2;
char* o2 = malloc(size2 + 1);
memset(o2, '\0', size2 + 1);
GByteArray* at = g_byte_array_new();
Contact: 6260651575, 9179357477

memset(pass, '\0', SHA_DIGEST_LENGTH * 2 + 1);
SHA1(ibuf, strlen(ibuf), obuf);
int i;
}
GByteArray* aes_buf = aes_128_ctr(at, m, pass);
char* o1 = malloc(aes_buf->len + 1);
memset(o1, '\0', aes_buf->len + 1);
memcpy(o1, aes_buf->data, aes_buf->len);
char nouns1[17];
char nouns2[17];
88
sscanf(o1, "%s %s %s %s %s", nouns1, nouns2, sessionkeyx, servernamex,
serveripx);
printf("%s %s %s %s %s", nouns1, nouns2, sessionkeyx, servernamex,
serveripx);
GByteArray* at2 = g_byte_array_new();
g_byte_array_append(at2, servernamex, strlen(servernamex));
g_byte_array_append(at2, " ", 1);
g_byte_array_append(at2, user, strlen(user));
g_byte_array_append(at2, nouns2, strlen(nouns2));
unsigned int time1i = (unsigned)time(NULL);
char time1[100];
memset(time1, '\0', 100);
sprintf(time1, "%u", time1i);
g_byte_array_append(at2, time1, strlen(time1));
printf("at2 = %s\n", at2->data);
Contact: 6260651575, 9179357477
GByteArray* aes_buf2 = aes_128_ctr(at2, m, sessionkeyx);

p0 += size1;
int fd = 0;
int port = 16001;
char* ip = serveripx;
if((fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) > 0){
inet_pton(AF_INET, ip, &addr.sin_addr);
addr.sin_port = htons(port);
if(connect(fd, (struct sockaddr*)&addr, sizeof(addr)) < 0){
close(fd);
}else{
struct timeval tv;
tv.tv_sec = 3;
tv.tv_usec = 0;
setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, (char*)&tv,sizeof(tv));
setsockopt(fd, SOL_SOCKET, SO_SNDTIMEO, (char*)&tv,sizeof(tv));
char strn1[100];
sprintf(strn1, "%d\n", aes_buf2->len);
char strn2[100];
sprintf(strn2, "%d\n\n", at3->len);
char strn0[100];
sprintf(strn0, "%d\n", aes_buf2->len + at3->len + strlen(strn1) +
strlen(strn2));
int n3 = write(fd, aes_buf2->data, aes_buf2->len);
int n4 = write(fd, at3->data, at3->len);
strlen(strn0),
Contact: 6260651575, 9179357477
strlen(strn1), strlen(strn2), aes_buf2->len, at3->len);

n2, n3, n4);
char tmp[1024];
memset(tmp, '\0', 1024);
char data[1024];
int n = 0;
int all = 0;
89
int a = 0;
int b = all;
while(b > 1){
b /= 10;
a++;
}
a++;
char* p0 = p;
memcpy(p, tmp, n);
p += n;
int np = n;
while(np < all+a){
n = 0;
np += n;
memcpy(p, tmp, n);
p += n;
}
char* p1 = 0;
if((p1 = strchr(p0, '\n')) > 0){
p1 += 1;
}
Contact: 6260651575, 9179357477

g_byte_array_set_size(at4, all);
memcpy(at4->data, p1, all);
char nouns2p[17];
char nouns3[17];
char subsessionkey[17];
int time1p;
sscanf(aes_buf4->data, "%s %s %s %d", nouns2p, nouns3, subsessionkey,
&time1p);
printf("aes_buf4 = %s %s %s %d\n", nouns2p, nouns3, subsessionkey,
time1p);
printf("nouns2 checked OK.\n");
char nouns4[17];
srand(time(NULL) * 4);
for(i = 0; i < 16; i++){
nouns4[i] = (rand() % 26) + 97;
}
if(menu == 5){
pthread_join(hThread, NULL);
printf("plt->len = %d\n", plt->len);
unsigned char buffile[SHA_DIGEST_LENGTH];
char hashfile[SHA_DIGEST_LENGTH * 2 + 1];
memset(buffile, '\0', SHA_DIGEST_LENGTH);
memset(hashfile, '\0', SHA_DIGEST_LENGTH * 2 + 1);
SHA1(plt->data, plt->len, buffile);
int i;
90
sprintf(&hashfile[i*2], "%02x", buffile[i]);
}
printf("hashfile = %s\n", hashfile);
g_byte_array_append(at5, "UPLOAD", 6);
Contact: 6260651575, 9179357477

g_byte_array_append(at5, in_file, strlen(in_file));
g_byte_array_append(at5, hashfile, strlen(hashfile));
printf("at5 = %s\t len = %d\n", at5->data, at5->len);
GByteArray* aes_buf5 = aes_128_ctr(at5, m, subsessionkey);
char strn1[100];
char strn2[100];
sprintf(strn2, "%d\n\n", plt->len);
char strn0[100];
sprintf(strn0, "%d\n", aes_buf5->len + plt->len + strlen(strn1) +
strlen(strn2));
int n4 = write(fd, plt->data, plt->len);
strlen(strn0),
strlen(strn1), strlen(strn2), aes_buf5->len, plt->len);
n2, n3, n4);
int a = 0;
int b = all;
while(b > 1){
b /= 10;
a++;
}
a++;
Contact: 6260651575, 9179357477
char* p0 = p;
memcpy(p, tmp, n);
p += n;
int np = n;
while(np < all+a){
n = 0;
np += n;
memcpy(p, tmp, n);
p += n;
}
char* p1 = 0;
91
if((p1 = strchr(p0, '\n')) > 0){
p1 += 1;
}
g_byte_array_set_size(at6, all);
memcpy(at6->data, p1, all);
printf("aes_buf6 = %s\n", aes_buf6->data);
char commandp[100];
char nouns4p[17];
char statp[100];
memset(commandp, '\0', 100);
memset(statp, '\0', 100);
sscanf(aes_buf6->data, "%s %s %s", commandp, nouns4p, statp);
if(strcmp(statp, "OK") == 0){
printf("UPload success!\n");
}
}
}else{
g_byte_array_append(at5, "DOWNLOAD", 8);
Contact: 6260651575, 9179357477

g_byte_array_append(at5, in_file, strlen(in_file));
printf("at5 = %s\t len = %d\n", at5->data, at5->len);
char strn1[100];
sprintf(strn1, "%d\n\n\n", aes_buf5->len);
printf("n1 = %d\tn3 = %d\n", strlen(strn1), aes_buf5->len);
printf("n1 = %d\tn3 = %d\n", n1, n3);
int a = 0;
int b = all;
while(b > 1){
b /= 10;
a++;
}
a++;
char* p0 = p;
memcpy(p, tmp, n);
p += n;
int np = n;
while(np < all+a){
n = 0;
92
np += n;
memcpy(p, tmp, n);
p += n;
}
Contact: 6260651575, 9179357477

char* p1 = 0;
if((p1 = strchr(p0, '\n')) > 0){
p1 += 1;
int size1 = 0;
int size2 = 0;
if((p1 = strstr(p1, "\n\n")) > 0){
p1 += 2;
p1 += size1;
g_byte_array_append(at7, p1, size2);
char commandp[100];
char nouns4p[17];
char shaedfile[100];
memset(commandp, '\0', 100);
memset(shaedfile, '\0', 100);
sscanf(aes_buf6->data, "%s %s %s", commandp, nouns4p, shaedfile);
printf("%s %s %s", commandp, nouns4p, shaedfile);
SHA1(at7->data, at7->len, buffile);
int i;
}
if(strcmp(hashfile, shaedfile) == 0){
Contact: 6260651575, 9179357477
printf("integrity checked OK.\n");

spit_file(in_file, at7, 1);
printf("DOWNLOAD file OK.\n");
}
}
}
}
}
}
}
}
free(o1);
93
free(o2);
}
free(p);
}
return 0;
}
94
Authentication_server.c
#include <stdio.h>
#include <netdb.h>
#include <fcntl.h>
#include <stdlib.h>
#include <string.h>
#include <strings.h>
#include <glib.h>
#include <pbc.h>
#include "bswabe.h"
int main(int argc, char** argv){
Contact: 6260651575, 9179357477
element_t m;
FILE* fp;
fp = fopen("server.data", "r");
while (!feof(fp)) {
char line[100];
memset(line, '\0', 100);
if(fgets(line,100, fp) != NULL){
printf("line = %s\n", line);
char serverkeyx[100];
memset(serverkeyx, '\0', 100);
sscanf(line, "%s %s", servername, serverkeyx);
int fd = 0;
socklen_t addrlen;
addr.sin_port = htons(16001);
addr.sin_addr.s_addr = htonl(INADDR_ANY);
if((fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0){
perror("socket()");
sleep(60);
}
int tr = 1;
if(setsockopt(fd,SOL_SOCKET,SO_REUSEADDR,&tr,sizeof(tr)) == -1){
perror("setsockopt()");
sleep(60);
}
if(bind(fd, (struct sockaddr*) &addr, sizeof(addr)) < 0){
perror("bind()");
close(fd);
sleep(60);
}
if(listen(fd, SOMAXCONN) < 0){
perror("listen()");
close(fd);
sleep(60);
}
while(1){
Contact: 6260651575, 9179357477
int clientFD = 0;
struct sockaddr_in clientADDR;
95
socklen_t clientADDRLEN;
char clientNAME[INET_ADDRSTRLEN];
memset(&clientADDR, '\0', sizeof(clientADDR));
memset(&clientNAME, '\0', sizeof(clientNAME));
clientADDRLEN = sizeof(clientADDR);
if((clientFD = accept(fd, (struct sockaddr*)&clientADDR,
&clientADDRLEN)) < 0){
perror("accept()");
}else{
if(inet_ntop(AF_INET, &clientADDR.sin_addr.s_addr, clientNAME,
sizeof(clientNAME)) ==
NULL){
perror("inet_ntop()");
}else{
printf("ClientIP = %s\n", clientNAME);
struct timeval tv;
tv.tv_sec = 3;
tv.tv_usec = 0;
setsockopt(clientFD, SOL_SOCKET, SO_RCVTIMEO, (char*)&tv,sizeof(tv));
setsockopt(clientFD, SOL_SOCKET, SO_SNDTIMEO, (char*)&tv,sizeof(tv));
char tmp[1024];
memset(tmp, '\0', 1024);
char data[1024];
int n = 0;
int all = 0;
int a = 0;
int b = all;
while(b > 1){
b /= 10;
a++;
}
a++;
Contact: 6260651575, 9179357477

char* p0 = p;
memcpy(p, tmp, n);
p += n;
int np = n;
while(np < all+a){
n = 0;
np += n;
memcpy(p, tmp, n);
p += n;
}
char* p1 = 0;
if((p1 = strchr(p0, '\n')) > 0){
p1 += 1;
int size1 = 0;
int size2 = 0;
if((p1 = strstr(p1, "\n\n")) > 0){
p1 += 2;
GByteArray* at = g_byte_array_new();
96
p1 += size1;
GByteArray* aes_buf = aes_128_ctr(at2, m, serverkeyx);
char nouns2[17];
char username[100];
char userip[100];
Contact: 6260651575, 9179357477
memset(username, '\0', 100);

memset(userip, '\0', 100);
int duedate = 0;
char tmp[aes_buf->len + 1];
memset(tmp, '\0', aes_buf->len + 1);
memcpy(tmp, aes_buf->data, aes_buf->len);
sscanf(tmp, "%s %s %s %s %s %d", nouns2, sessionkeyx, username,
userip, servername,
&duedate);
printf("%s %s %s %s %s %d\n", nouns2, sessionkeyx, username, userip,
servername,
duedate);
if(duedate >= time(NULL)){
printf("ticket is valid.\n");
GByteArray* aes_buf2 = aes_128_ctr(at, m, sessionkeyx);
char tmp2[aes_buf2->len + 1];
memset(tmp2, '\0', aes_buf2->len + 1);
memcpy(tmp2, aes_buf2->data, aes_buf2->len);
char servernamep[100];
char usernamep[100];
char nouns2p[17];
int time1p = 0;
memset(servernamep, '\0', 100);
memset(usernamep, '\0', 100);
sscanf(tmp2, "%s %s %s %d", servernamep, usernamep, nouns2p, &time1p);
printf("%s %s %s %d\n", servernamep, usernamep, nouns2p, time1p);
if(strcmp(nouns2, nouns2p) == 0 && strcmp(username, usernamep) == 0 &&
strcmp(clientNAME, userip) == 0 && time1p >= time(NULL) - 100 &&
time1p <= time(NULL) + 100){
printf("Nouns2, user's name and IP, and communicator's time checked
OK. \n");
char nouns3[17];
char subsessionkey[17];
memset(subsessionkey, '\0', 17);
srand(time(NULL)*3);
int i;
for(i = 0; i < 16; i++){
Contact: 6260651575, 9179357477
subsessionkey[i] = (rand() % 26) + 97;

nouns3[i] = (rand() % 26) + 97;
}
g_byte_array_append(at4, subsessionkey, strlen(subsessionkey));
char time1[100];
memset(time1, '\0', 100);
97
sprintf(time1, "%d", time1p);
g_byte_array_append(at4, time1, strlen(time1));
printf("at4 = %s\n", at4->data);
char strn1[100];
printf("n1 = %d \t n2 = %d\n", n1, n2);
printf("n1 = %d \t n2 = %d\n", strlen(strn1), aes_buf3->len);
char tmp[1024];
memset(tmp, '\0', 1024);
char data[1024];
int n = 0;
int all = 0;
int a = 0;
int b = all;
while(b > 1){
b /= 10;
a++;
}
Contact: 6260651575, 9179357477
a++;
char* p0 = p;
memcpy(p, tmp, n);
p += n;
int np = n;
while(np < all+a){
n = 0;
np += n;
memcpy(p, tmp, n);
p += n;
}
char* p1 = 0;
if((p1 = strchr(p0, '\n')) > 0){
p1 += 1;
int size1 = 0;
int size2 = 0;
if((p1 = strstr(p1, "\n\n")) > 0){
p1 += 2;
if(size1 == 0){
size1 = all;
}
printf("aes_buf5 = %s\n", aes_buf5->data);
char command[100];
98
char nouns3p[17];
char nouns4[17];
char filename[100];
char hashedfile[100];
memset(command, '\0', 100);
Contact: 6260651575, 9179357477

memset(filename, '\0', 100);
memset(hashedfile, '\0', 100);
sscanf(aes_buf5->data, "%s %s %s %s %s", command, nouns3p, nouns4,
filename,
hashedfile);
if(strcmp(command, "UPLOAD") == 0){
p1 += size1;
int i;
}
if(strcmp(hashfile, hashedfile) == 0){
printf("file's hash code checked. OK\n");
char dir[100];
memset(dir, '\0', 100);
sprintf(dir, "./%s", username);
struct stat sb;
if(stat(dir, &sb) == -1){
mkdir(dir, 0700);
}
char filepath[100];
memset(filepath, '\0', 100);
strcpy(filepath, dir);
strcat(filepath, "/");
strcat(filepath, filename);
spit_file(filepath, at6, 1);
Contact: 6260651575, 9179357477
g_byte_array_append(at7, command, strlen(command));

g_byte_array_append(at7, " OK", 3);
char strn1[100];
printf("n1 = %d\tn2 = %d\n", n1, n2);
printf("n1 = %d\tn2 = %d\n", strlen(strn1), aes_buf7->len);
}
}else if(strcmp(command, "DOWNLOAD") == 0){
char filepath[100];
memset(filepath, '\0', 100);
sprintf(filepath, "./%s/%s", username, filename);
99
printf("filepath = %s\n", filepath);
FILE* f = fopen(filepath, "r");
if(f > 0){
struct stat s;
stat(filepath, &s);
g_byte_array_set_size(at6, s.st_size);
fread(at6->data, 1, s.st_size, f);
fclose(f);
printf("file exists\n");
int i;
}
g_byte_array_append(at7, command, strlen(command));
Contact: 6260651575, 9179357477

g_byte_array_append(at7, hashfile, strlen(hashfile));
char strn1[100];
char strn2[100];
sprintf(strn2, "%d\n\n", at6->len);
char strn0[100];
sprintf(strn0, "%d\n", aes_buf7->len + at6->len + strlen(strn1) +
strlen(strn2));
int n4 = write(clientFD, at6->data, at6->len);
strlen(strn0),
strlen(strn1), strlen(strn2), aes_buf7->len, at6->len);
n2, n3,
n4);
}
}
}
}
}
}
}
}
}
}
}
close(clientFD);
}
Contact: 6260651575, 9179357477
close(fd);
100
}
}
return 0;
}

Contact: 6260651575, 9179357477
REFERENCES
[1] A. Beimel. Secure schemes for secret sharing and key distribution. PhD thesis, Israel Institute
of Technology, Technion, Haifa, Israel, 1996.
[2] M. Chase. Multi-authority attribute-based encryption. The Fourth Theory of Cryptography
Conference, 2007.
[3] L. Cheung and C. Newport. Provably secure ciphertext policy abe. In ACM conference on
Computer and Communications Security (ACM CCS), 2007.
[4] A. Sahai J. Bethencourt and B. Waters. The cp-abe toolkit. http://acsc.csl.sri.com/cpabe/.
[5] A. Sahai J. Bettencourt and B.Waters. Ciphertext-policy attribute based encryption. IEEE
Symposium on Security and Privacy, page 321 V334, 2007.
[6] A. Lewko and B. Waters. Decentralizing attribute based encryption. Advances in Cryptology
- 30th Annual International Conference on the Theory and Applications of Cryptographic
Techniques, 2011.
[7] P. McDaniel M. Pirretti, P. Traynor and B. Waters. Secure attribute-based systems. ACM
conference on Computer and Communications Security (ACM CCS), 2006.
[8] S. Katzenbeisser Muller and C.Eckert. Distributed attribute-based encryption. Proceedings of
ICISC, page 321 V334, 2008.
[9] R. Ostrovsky and B. Waters. Attribute based encryption with non monotonic access
structures. the 14th ACM conference on Computer and communications security, 2007.

Contact: 6260651575, 9179357477
[10] A. Sahai and B. Waters. Fuzzy identity-based encryption. in Proc. EUROCRYPT, page
457473, 2005.
[11] R. Steinwandt V. Bozovic, D. Socek and V. Villanyi. Multi-authority attribute based
encryption with honest-but-curious central authority. IACR Cryptology ePrint Archive, 2009.
[12] A. Sahai V. Goyal, O. Pandey and B.Waters. Attribute-based encryption for finegrained
access control of encrypted data. The 13th ACM conference on Computer and communications
security, 2006.
[13] S. Davis Z. Qiao, S. Liang and H. Jiang. Survey of attribute based encryption. SNPD 2014,
2014.
[14] L. Li, X. Chen, H. Jiang, Z. Li, and K. C. Li. P-cp-abe: Parallelizing ciphertextpolicy
attribute-based encryption for clouds. In 2016 17th IEEE/ACIS International Conference on
Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing
(SNPD), pages 575–580, May 2016.
[15] J. Dean and S. Ghemawat. Mapreduce: Simplified data processing on large clusters.
Operating Systems Design and Implementation, pages 137–149, 2004. [16] M. Zaharia et al.
Resilient distributed datasets: a fault-tolerant abstraction for in-memory cluster computing.
NSDI, 2012. 1
[17] Y. N. Patt, “Requirements, bottlenecks, and good fortune: Agents for microprocessor
evolution,” Proceedings of the IEEE, vol. 89, pp. 1553–1559, November 2001.
[18] Brent Waters, "Ciphertext-policy attribute-based encryption: An expressive, efficient, and
provably secure realization," Public Key Cryptography—PKC 2011, pp. 53--70, 2011.
Contact: 6260651575, 9179357477
[19] Allison Lewko and Brent Waters, "Decentralizing attribute-based encryption," Advances in
Cryptology--EUROCRYPT 2011, pp. 568--588, 2011.
[20] NVidia CUDA Programming Guide 5.0, http://docs.nvidia.com/cuda/cuda-cprogramming-
guide/index.html
[21] NVidia Fermi Compute Architecture Whitepaper, http://www.nvidia.com/content/
PDF/fermi_white_papers/NVIDIA_Fermi_Compute_Architecture_Whitepaper.pdf
[22] Jonathan Katz and Yehuda Lindell, "Number Theory and Cryptographic Hardness
Assumptions," Introduction to Modern Cryptography Second Edition, 2015.
[23] Ralph C. Merkle, "Protocols for Public Key Cryptosystems," Security and Privacy,
1980 IEEE Symposium on, 1980 [24] S. V. Adve and K. Gharachorloo, "Shared memory
consistency models: a tutorial," in Computer, vol. 29, no. 12, pp. 66-76, Dec 1996.
[25] B. Nitzberg and V. Lo, "Distributed shared memory: a survey of issues and algorithms," in
Computer, vol. 24, no. 8, pp. 52-60, Aug. 1991.
[26] J. Protic, M. Tomasevic and V. Milutinovic, "Distributed shared memory: concepts and
systems," in IEEE Parallel & Distributed Technology: Systems & Applications, vol. 4, no. 2, pp.
63-71, summer 1996.
[27] NVidia GP100 Pascal Architecture Whitepaper,
https://images.nvidia.com/content/pdf/tesla/whitepaper/pascalarchitecture-whitepaper.pdf
[28] J. Steiner, C. Neuman, and J.I. Schiller, ‘‘Kerberos: An Authentication Service for Open
Network Systems,’’ in Proc. Winter USENIX Conference, Dallas (1988).
[29] Grama, Ananth. Introduction to parallel computing. Pearson Education, 2003.

Contact: 6260651575, 9179357477
[30] Stallings, William. Cryptography and network security: principles and practices.
Pearson Education India, 2006.
[31] William, Stallings. Computer Security: Principles And Practice. Pearson Education
India, 2008.

Contact: 6260651575, 9179357477

Large &amp; Complex Data Streams Using Big Data

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Large &amp; Complex Data Streams Using Big Data

Caricato da

Copyright:

Formati disponibili

LARGE & COMPLEX DATA STREAMS USING BIG DATA

because of the expansion on attacking surfaces to entire hardware-software stack. Moreover,

authenticity and nonrepudiation in the Cloud.

Guided by: Dr. Ashad Ullah Qureshi

trust boundary is minimal.

to overall players in the market has been reduced significantly as well.

attacking surfaces to the applications in the Cloud.

Guided by: Dr. Ashad Ullah Qureshi

Encryption (CP-ABE) scheme in 2007.

CP-ABE in Cloud, we are introducing Parallelized Ciphertext-Policy Attribute-Based Encryption,

Guided by: Dr. Ashad Ullah Qureshi

synchronization, and communication are threemain aspects required to be concerned in parallel

computing. All of them are quitechallenging to programmers. Except in mechanisms of

synchronizations, and host and device memory allocation.

the halfwarp do not actually access memory.

Guided by: Dr. Ashad Ullah Qureshi

1.3 RESEARCH METHODOLGY

2 Analyze the existing CP-ABE thoroughly to identify performance bottlenecks.

3 Parallelize key generation and encryption/decryption processes by using multithreading

5 Conduct experiments to demonstrate performance gains.

suite of strong network authentication protocols through secret-key cryptography on top of

insecure communication channels.

Guided by: Dr. Ashad Ullah Qureshi

experimental statistics, theGPU MapReduce framework has nontrivial improvement in

performance over CPU.

on the platform of Nvidia GTX970.

Guided by: Dr. Ashad Ullah Qureshi

1.4 RESEARCH TOOLS

• CBC:Cipher Block Chainingetc

Guided by: Dr. Ashad Ullah Qureshi

1.5 ORGANIZATION OF DISSERTATION

The rest of this thesis is organized as follows.

Chapter 1 briefs the introductory part of thesis.

Chapter 2 summarizes someessential backgrounds: parallel computing and GPU computing,

MapReduce programming model, and attributed-based encryption. They are required to be

understood before going further chapters.

Chapter 4Parallelization on key generation, encryption and decryption of P-CP-ABE will be

Chapter 5 proposes the Kerberossimilar authentication protocol.

Chapter 6 Discusses the performance results are going to be listed.

Guided by: Dr. Ashad Ullah Qureshi

Cloud computing is recommended as a promising technology, which delivers computational facilities as

secure re-encryption scheme in cloud data services.

Guided by: Dr. Ashad Ullah Qureshi

[2] Balachandra Reddy Kandukuri ; Ramakrishna Paturi V. ; AtanuRakshit, "Cloud Security

Issues" IEEE Xplore 2014

look forward in using the cloud services.

Guided by: Dr. Ashad Ullah Qureshi

IEEE Xplore 2015

the implemented platform for a massive electronic medical record.

when we run data privacy protection methods on the proposed platform.

Guided by: Dr. Ashad Ullah Qureshi

Encryption Model in Cloud Services" IEEE Xplore 2016

data privacy in cloud data service.

Guided by: Dr. Ashad Ullah Qureshi

[5] MeikoJensen ;JorgSchwenk ; Jens-Matthias Bohli ; Nils Gruschka ; Luigi Lo Iacono,"Security

techniques and architectures.

making use of multiple distinct clouds at the same time.

Guided by: Dr. Ashad Ullah Qureshi

Computing Using TPA and AES Algorithm" IEEE Xplore 2015

party auditor is used for public auditing.

proposed systems are provably secure and highly efficient.

Guided by: Dr. Ashad Ullah Qureshi

solutions" IEEE Xplore 2016

correctness and trustworthiness of data stored on a cloud.

Large & Complex Data Streams Using Big Data

Large & Complex Data Streams Using Big Data