Privacy-Preserving Ciphertext Multi-Sharing Control For Big Data Storage

PRIVACY-PRESERVING CIPHERTEXT MULTI-SHARING CONTROL
FOR BIG DATA STORAGE
ABSTRACT
The need of secure big data storage service is more desirable than ever to date. The
basic requirement of the service is to guarantee the confidentiality of the data.
However, the anonymity of the service clients, one of the most essential aspects of
privacy, should be considered simultaneously. Moreover, the service also should
provide practical and fine-grained encrypted data sharing such that a data owner is
allowed to share a ciphertext of data among others under some specified
conditions. A privacy-preserving ciphertext multi-sharing mechanism is proposed
to achieve the above properties. It combines the merits of proxy re-encryption with
anonymous technique in which a ciphertext can be securely and conditionally
shared multiple times without leaking both the knowledge of underlying message
and the identity information of ciphertext senders/recipients. The new primitive is
secure against chosen-ciphertext attacks in the standard model.
INTRODUCTION
To date many individuals and companies choose to upload their data to clouds
since the clouds supports considerable data storage service but also efficient data
processing capability. Accordingly, it is unavoidable that trillions of personal and
industrial data are flooding the Internet. For example, in some smart grid scenario,
a governmental surveillance authority may choose to supervise the electricity
consumption of a local living district. A great amount of electricity consumed data
of each family located inside the district will be automatically transferred to the
authority via Internet period by period. The need of big data storage, therefore, is
more desirable than ever. A basic security requirement of big data storage is to
guarantee the confidentiality of the data.
PROBLEM DEFINITION
Suppose a hospital stores its patients medical records in a cloud storage system
and meanwhile, the records are all encrypted so as to avoid the cloud server from
accessing to any patients medical information. After a record is encrypted and
further uploaded to the cloud, only those specified doctors can gain access to the
record. By using some traditional PKE, Identity-Based Encryption (IBE), or
Attribute-Based Encryption (ABE), the confidentiality of the record can be
protected effectively. By trivially employing traditional encryption mechanisms (to
guarantee the confidentiality of medical record), nevertheless, we cannot prevent
some sensitive personal information from being leaked to the cloud server but also
the public. This is because traditional encryption systems do not consider the
anonymity of a ciphertext sender/receiver.
Accordingly, someone, could be anyone with capability of obtaining a ciphertext
(e.g. cloud server), may know whose public key the ciphertext is encrypted under,
namely who is the owner of the ciphertext, such that the patient associated with the
ciphertext can be easily identified.
Similarly, the recipient/destination of the ciphertext, e.g., Cardiology Dept., can be
known from the ciphertext without any difficulty as well. This seriously disgraces
the privacy of patient.
Moreover, a patient might be transferred to more than one medical department in
different treatment phases. The corresponding medical record then needs to be
converted to the ciphertexts corresponding to various receivers so as to be shared
among the departments. Therefore, the update of ciphertext recipient is desirable.
Precisely speaking, a fine-grained ciphertext update for receivers is necessary in
the sense that a ciphertext can be conditionally shared with others. The medical
record owner, e.g., the patient, has rights to decide who can gain access to the
record, and which kinds of data are allowed for access. For example, the patient
can choose to specify that only the medical record described with teeth can be
read by a dentist. This fine-grained control prevents a data sharing mechanism
from being limited to the all-or-nothing share mode.
EXISTING SYSTEM
Some existing cryptographic encryption mechanisms can be employed to
fulfill the requirement.
Public Key Encryption (PKE) allows a data sender to encrypts the data
under the public key of receiver such that no one except the valid recipient
can gain access to the data.
To preserve anonymity, some well-known encryption mechanisms are
proposed in the literature, such as anonymous IBE. By employing these
primitives, the source and the destination of data can be protected privately.
There are some naive approaches to update ciphertexts recipient. For
instance, data owner can employ the decrypt then- re-encrypt mode.
Nonetheless, this is applicable to the scenario where there is only a small
amount of data. If the encrypted data is either a group of sequences of
genome information or a network audit log, the decryption and re-encryption
might be time consumed and computation costly.
A fully trusted third party with knowledge of the decryption key of the data
owner may be delegated to handle the task.
Identity-based cryptographic employ Proxy Re-Encryption (PRE) defined
the notion of Identity-Based Proxy Re-Encryption (IBPRE), which offers a
practical solution for access control in networked file storage. To capture
privacy-preserving
property
and
ciphertexts
recipient
update
simultaneously, proposed an anonymous IBPRE system, which is CCA

security in the Random Oracle Model (ROM).
Disadvantages
Public Key Encryption does not satisfy all the requirements of users in the
scenario of big data storage.
IBE primitives cannot support the update of ciphertext receiver.
Naive approaches suffer from a limitation that the data owner has to be online all the time.
Trusted third party knowledge of the decryption key relies on the fully trust
of the party. Besides, the anonymity of the ciphertext receiver cannot be
achieved as the party needs to know the information of recipient to proceed
the re-encryption.
Identity-Based Proxy Re-Encryption only supports one-time ciphertext
receiver update, while multiple receivers update is desirable in practice. On
the other hand, the work provides an all-or-nothing share mode that limits
the flexibility of data sharing.
PROPOSED SYSTEM
To propose a ciphertext sharing mechanism with the following properties:
Anonymity: given a ciphertext, no one knows the identity information of
sender and receiver.
Multiple receiver-update: given a ciphertext, the receiver of the ciphertext
can be updated in multiple times. In this paper, we refer to this property as
multi-hop.
Conditional sharing: a ciphertext can be fine-grained shared with others if
the pre-specified conditions are satisfied.
Consider the case where a proxy colludes with delegate to compromise the
underlying message and the secret key of delegator. Here, the protection of
the message is very difficult to achieve as the delegate can always decrypt
the corresponding ciphertext for the proxy. The secret key of the delegator,
however, is possible to be secured.
For the definition of collusion attacks model, allow an adversary to acquire
all re-encryption keys, and the adversary wins the game if it outputs a valid
secret key of an uncorrupted user.
Propose a concrete construction for unidirectional AMH-IBCPRE, in which
it achieves multiple ciphertext receiver update, conditional data sharing,
anonymity and collusion-safe simultaneously in asymmetric bilinear group.
Advantages
The new primitive is applicable to many real-world applications, such as
secure email forwarding, electronic encrypted data sharing, where both
anonymity and flexible encrypted data sharing are needed.
LITERATURE SUMMARY
Delegation of decryption rights introduced by Mambo and Okamoto, Blaze et al.
formalized the concept of PRE, and proposed a seminal bidirectional PRE scheme.
Employing traditional PRE in the context of IBE, Green and Ateniese initially
introduced the notion of IBPRE, and proposed two unidirectional IBPRE schemes
in the ROM: one is CPA secure and the other holds against CCA.
Later on, two CPA-secure IBE-PRE schemes have been proposed. Afterwards,
some IBPRE systems have been proposed for various requirements. In the multiple
ciphertext receiver update scenario, Green and Ateniese proposed the first MHIBPRE scheme with CPA security.
Later on, a RCCA-secure MH-IBPRE scheme without random oracles was
proposed by Chu and Tzeng. These schemes, however, are not collusion-safe.
To solve the problem, Shao and Cao proposed a CCA-secure MH-IBPRE in the
standard model with collusion-safe property.
Ateniese et al. defined the notion of key-privacy.
Shao et al. revised the security model.
To prevent a ciphertext from being traced, Emura et al. proposed a unidirectional
IBPRE scheme in which an adversary cannot identify the source from the
destination ciphertext.
To ensure the privacy of both delegator and delegatee, Shao et al. proposed the first
Anonymous PRE (ANO-PRE) system. The system guarantees that an adversary
cannot identify the recipient of original and re-encrypted ciphertext even given the
corresponding re-encryption key.
In 2012, Shao also proposed the first anonymous IBPRE with CCA security in the
ROM.
Leveraging them may partially fulfill proposed goals. However, it is need to focus
on the combination of anonymity and ciphertext update properties. Therefore, the
aforementioned systems are not taken in comparison below.
HARDWARE REQUIREMENTS
Processor
: Any Processor above 500 MHz.
Ram
: 128Mb.
Hard Disk
: 10 Gb.
Compact Disk
: 650 Mb.
Input device
: Standard Keyboard and Mouse.
Output device
: VGA and High Resolution Monitor.
SOFTWARE SPECIFICATION
Operating System
: Windows Family.
Techniques
: JDK 1.5 or higher
Database
: MySQL 5.0
LITERATURE SURVEY
Improved proxy re-encryption schemes with applications to secure distributed
storage
G. Ateniese, K. Fu, M. Green, and S. Hohenberger,Network and Distributed System Security.
Berlin, Germany: Springer-Verlag, 2005, pp. 2943.
In 1998, Blaze, Bleumer, and Strauss (BBS) proposed an application called atomic
proxy re-encryption, in which a semi-trusted proxy converts a ciphertext for Alice
into a ciphertext for Bob without seeing the underlying plaintext. We predict that
fast and secure re-encryption will become increasingly popular as a method for
managing encrypted file systems. Although efficiently computable, the widespread adoption of BBS re-encryption has been hindered by considerable security
risks. Following recent work of Dodis and Ivan, we present new re-encryption
schemes that realize a stronger notion of security, and we demonstrate the
usefulness of proxy re-encryption as a method of adding access control to a secure
file system. Performance measurements of our experimental file system
demonstrate that proxy re-encryption can work effectively in practice.
Two-tier signatures, strongly unforgeable signatures, and FiatShamir

without random oracles
M. Bellare and S. Shoup, Public Key Cryptography (Lecture Notes in Computer Science), vol. 4450.
Berlin, Germany: Springer-Verlag, 2007, pp. 201216.
We provide a positive result about the Fiat-Shamir (FS) transform in the standard
model, showing how to use it to convert three-move identification protocols into
two-tier signature schemes with a proof of security that makes a standard

assumption on the hash function rather than modeling it as a random oracle. The
result requires security of the starting protocol against concurrent attacks. We can
show that numerous protocols have the required properties and so obtain numerous
efficient two-tier schemes. Our first application is a two-tier scheme based efficient
transform of any unforgeable signature scheme into a strongly unforgeable one.
(This extends Boneh, Shen and Waters [BSW06] whose transform only applies to a
limited class of schemes.) The second application is new one-time signature
schemes that, compared to one-way function based ones of the same computational
cost, have smaller key and signature sizes.
Hierarchical identity based encryption with constant size ciphertext

D. Boneh, X. Boyen, and E.-J. Goh, Advances in CryptologyEUROCRYPT (Lecture Notes in
Computer Science), vol. 3494. Berlin, Germany: Springer-Verlag, 2005, pp. 440456
We present a Hierarchical Identity Based Encryption (HIBE) system where the

ciphertext consists of just three group elements and decryption requires only two
bilinear map computations, regardless of the hierarchy depth. Encryption is as
efficient as in other HIBE systems. We prove that the scheme is selective-ID secure
in the standard model and fully secure in the random oracle model. Our system has
a number of applications: it gives very efficient forward secure public key and
identity based cryptosystems (with short ciphertexts), it converts the NNL
broadcast encryption system into an efficient public key broadcast system, and it
provides an efficient mechanism for encrypting to the future. The system also
supports limited delegation where users can be given restricted private keys that
only allow delegation to bounded depth. The HIBE system can be modified to
support sublinear size private keys at the cost of some ciphertext expansion.
Blind and anonymous identity-based encryption and authorised private
searches on public key encrypted data
J. Camenisch, M. Kohlweiss, A. Rial, and C. Sheedy, Public Key Cryptography (Lecture Notes in
Computer Science), vol. 5443. Berlin, Germany: Springer-Verlag, 2009, pp. 196214.
Searchable
encryption
schemes
provide
an
important
mechanism
to
cryptographically protect data while keeping it available to be searched and

accessed. In a common approach for their construction, the encrypting entity
chooses one or several keywords that describe the content of each encrypted record
of data. To perform a search, a user obtains a trapdoor for a keyword of her interest
and uses this trapdoor to find all the data described by this keyword. We present a
searchable encryption scheme that allows users to privately search by keywords on
encrypted data in a public key setting and decrypt the search results. To this end,
we define and implement two primitives: public key encryption with oblivious
keyword search (PEOKS) and committed blind anonymous identity-based
encryption (IBE). PEOKS is an extension of public key encryption with keyword
search (PEKS) in which users can obtain trapdoors from the secret key holder
without revealing the keywords. Furthermore, we define committed blind trapdoor
extraction, which facilitates the definition of authorization policies to describe
which trapdoor a particular user can request. We construct a PEOKS scheme by
using our other primitive, which we believe to be the first blind and anonymous
IBE scheme. We apply our PEOKS scheme to build a public key encrypted
database that permits authorised private searches, i.e., neither the keywords nor the
search results are revealed.
SYSTEM ARCHITECTURE
Dataset
Proxy
server
Share/
authenticat
e key
User
Encryption
and reencryption
Upload
Server
Request
Data
Decryptio
n
MODULES
Dataset selection
Data Encryption and re-encryption
Anonymity
Conditional sharing
Data Access
Dataset Selection
In this module, first we have to collect the dataset. Patient Dataset is selected
for further process, which contains attributes such as name, age, gender, month,
location and symptoms of the patients. After the dataset has been chosen,
preprocess is done on the dataset. Preprocessing is nothing but a data cleaning. It is
the process of eliminating unwanted datas, unwanted noise values etc., Data
Preprocessing includes cleaning, normalization, transformation, feature extraction
and selection, etc.
Patient
Dataset
Check for
null
values
Preprocess
data
Data for
encryptio
n
Data Encryption and re-encryption

Data is encrypted using encryption algorithm called Password Based Encryption
with MD5 and DES. In this Module patient data is encrypted using
PBEwithMD5andDES. Then, upload the data into the HDFS location. Encrypted
and re-encrypted data is stored into HDFS Location. Hadoop File System was
developed using distributed file system design. HDFS holds very large amount of
data and provides easier access. To store such huge data, the files are stored across
multiple machines. After Encrypt the dataset, the generated ciphertext is stored in
the HDFS.
Encryption
Generate
keys
Cipher
text
Store in
HDFS
Anonymity
After encryption the data stored in the HDFS. Stored data from HDFS can
be share with multiple receivers. For a given ciphertext, no one knows the identity
information of sender and receiver. Here for hiding the receiver information's
anonymization of particular receiver is implemented. For Example, if the receiver
enters the user name that name will be anonymized and after that it will send to the
particular user.
Receivers send their profiles such as id, password, and category to the senders.
Category defines the data which is the receiver going to receive from sender and
also receiver defines the category of what receiver category. For each and every
individual receiver we generate the unique ids. Because, receivers information has
been anonymized and after that only it will be forwarded to sender.
Data
receiver
Register
Assign
unique ID
Share
with
owner
Conditional sharing
After the Multiple receiver update process is completed, conditional sharing
is going to be processed. In our implementation conditional sharing is takes place
based on the user's category and their receiver receiving data category, here we
check the condition. If both the categories are similar means, receiver will be
authenticated and he/she can receive their data in cipher text format only.
Otherwise they cant access the data and receiver will be excluded from the
process.
Receiver
Data
sharing
Satisf
es
conditi
on
Receive
cipher text
from owner
Data Access
After user authentication, data has been accessed in encrypted format. User
will get the key from sender and decrypt the data and they can view their original
data. Original Data has been accessed by the receiver if they are authenticated only.
Algorithm efficiency has been calculated by using the time efficiency of the
algorithm. Here we calculated the encryption time and decryption time of the
algorithm and finally we calculate the total time for executing the algorithm. By
using these types of parameters we evaluate the performance of the existing system
and proposed system.
Receiver
Send key
Decrypt
cipher
Access data
Owner
SAMPLE SOURCE CODE

DataEncryption.java
package privacypreservingdatasharing;
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
java.io.BufferedWriter;
java.io.File;
java.io.FileWriter;
java.security.Key;
java.sql.DriverManager;
java.sql.ResultSet;
java.sql.Statement;
javax.crypto.Cipher;
javax.crypto.spec.SecretKeySpec;
javax.swing.JOptionPane;
sun.misc.BASE64Encoder;
java.sql.*;
javax.crypto.SecretKey;
javax.crypto.SecretKeyFactory;
javax.crypto.spec.DESKeySpec;
public class DataEncryption extends javax.swing.JFrame {

Connection con;
Statement stat, st1, st, st2;
ResultSet rs, rs1, rs2, rs3;
int i = 0, na, j = 0;
public static long stime;
public DataEncryption() {
initComponents();
try {
Class.forName("com.mysql.jdbc.Driver");
con =
DriverManager.getConnection("jdbc:mysql://localhost:3306/multisharing",
"root", "root");
stat = con.createStatement();
st = con.createStatement();
st1 = con.createStatement();
st2 = con.createStatement();
st.executeUpdate("truncate table cipher");
st2.executeUpdate("truncate table secret_key");
rs1 = st.executeQuery("select count(*) from dataset");
na = 0;
while (rs1.next()) {
na = rs1.getInt(1);
}
} catch (Exception ex) {
System.out.println(ex.getMessage());
}
}
@SuppressWarnings("unchecked")
// <editor-fold defaultstate="collapsed" desc="Generated Code">//GENBEGIN:initComponents
private void initComponents() {
jPanel1 = new javax.swing.JPanel();
jButton1 = new javax.swing.JButton();
jLabel1 = new javax.swing.JLabel();
jScrollPane1 = new javax.swing.JScrollPane();
jTextArea1 = new javax.swing.JTextArea();
jPanel2 = new javax.swing.JPanel();
setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);
setTitle("DataEncryption");
setMinimumSize(new java.awt.Dimension(754, 534));
getContentPane().setLayout(null);
jPanel1.setBorder(javax.swing.BorderFactory.createTitledBorder(null,
"Encrypt", javax.swing.border.TitledBorder.DEFAULT_JUSTIFICATION,
javax.swing.border.TitledBorder.DEFAULT_POSITION, new
java.awt.Font("Traditional Arabic", 1, 14))); // NOI18N
jPanel1.setOpaque(false);
jPanel1.setLayout(null);
NOI18N
jButton1.setFont(new java.awt.Font("Traditional Arabic", 1, 14)); //

jButton1.setText("Disease");
jButton1.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(java.awt.event.ActionEvent evt) {
jButton1ActionPerformed(evt);
}
});
jPanel1.add(jButton1);
jButton1.setBounds(30, 280, 170, 30);
NOI18N
jButton2.setText("Name");
}
});
NOI18N
NOI18N
jButton3.setText("Age");
}
});
jButton4.setText("Gender");
}
});
NOI18N
NOI18N
jButton5.setText("Month");
}
});
jButton6.setText("Place");
}
});
jLabel1.setFont(new java.awt.Font("Traditional Arabic", 1, 24)); //
NOI18N
jLabel1.setText("Patient Data Encryption ");

jPanel1.add(jLabel1);
jLabel1.setBounds(270, 20, 310, 50);
NOI18N
jButton7.setText("Next");
}
});
getContentPane().add(jPanel1);
jPanel1.setBounds(30, 90, 250, 400);
jTextArea1.setColumns(20);
jTextArea1.setRows(5);
jScrollPane1.setViewportView(jTextArea1);
getContentPane().add(jScrollPane1);
jScrollPane1.setBounds(300, 90, 360, 400);
jPanel2.setBackground(new java.awt.Color(255, 255, 255));
jPanel2.setLayout(null);
NOI18N
jLabel2.setFont(new java.awt.Font("Traditional Arabic", 1, 24)); //

jLabel2.setText("Patient Data Encryption");
jLabel3.setIcon(new
javax.swing.ImageIcon(getClass().getResource("/images/canstock5326194.jpg")));
// NOI18N
getContentPane().add(jPanel2);
jPanel2.setBounds(0, 0, 760, 540);
pack();
}// </editor-fold>//GEN-END:initComponents
private void jButton2ActionPerformed(java.awt.event.ActionEvent evt)
{//GEN-FIRST:event_jButton2ActionPerformed
try {
String name[] = new String[81035];
String cipherText[] = new String[81035];
jTextArea1.setText("");
for (i = 0; i <= na; i++) {
rs = st.executeQuery("select Name from dataset");
while (rs.next()) {
name[i] = rs.getString(1);
i++;
}
}
i = 0;
j = 0;
for (j = 1; j < na; j++) {

String plainData = name[j];
String v = "TheBestSecretKey";
DESKeySpec dks = new DESKeySpec(v.getBytes());
SecretKeyFactory skf = SecretKeyFactory.getInstance("DES");
SecretKey desKey = skf.generateSecret(dks);
//
byte[] keyValue = v.getBytes();
//
Key key = new SecretKeySpec(keyValue, "AES");
st1.executeUpdate("INSERT INTO secret_key VALUES ('" + j +
"','" + desKey + "',null,null,null,null,null)");
Cipher cipher = Cipher.getInstance("DES");
//
Cipher aesCipher = Cipher.getInstance("AES");
cipher.init(Cipher.ENCRYPT_MODE, desKey);
byte[] byteDataToEncrypt = plainData.getBytes();
byte[] byteCipherText = cipher.doFinal(byteDataToEncrypt);
cipherText[j] = new BASE64Encoder().encode(byteCipherText);
jTextArea1.append("\n" + cipherText[j] + "\n");
//
st2.executeUpdate("INSERT INTO cipher VALUES ('" + j + "','"
+ cipherText[j] + "',null,null,null,null,null)");
st2.executeUpdate("INSERT INTO cipher VALUES ('" + j + "','" +
cipherText[j] + "',null,null,null,null,null)");
}
JOptionPane.showMessageDialog(null, "Secret key and ciphertext
generated successfully for Name");
} catch (Exception e) {
System.out.println(e.getMessage());
}
}//GEN-LAST:event_jButton2ActionPerformed
try {
String nodes[] = new String[81035];
for (i = 0; i <= na; i++) {
rs = st.executeQuery("select Age from dataset");
while (rs.next()) {
nodes[i] = rs.getString(1);
i++;
}
}
i = 0;
j = 0;
for (j = 1; j < na; j++) {
String plainData = nodes[j];
//DES
st1.executeUpdate("update secret_key set Agek= '" + desKey +
"' where metadata='" + j + "'");

st2.executeUpdate("update cipher set Agec= '" + cipherText[j]
+ "' where metadata='" + j + "'");
}
generated successfully for Age");
}
try {
for (i = 0; i <= na; i++) {
rs = st.executeQuery("select gender from dataset");
while (rs.next()) {
i++;
}
}
i = 0;
j = 0;
for (j = 1; j < na; j++) {
cipherText[j] + "' where metadata='" + j + "'");
//DES
st1.executeUpdate("update secret_key set Genk= '" + desKey +
"' where metadata='" + j + "'");
st2.executeUpdate("update cipher set genc= '" + cipherText[j]
}
generated successfully for Gender");
}
try {
for (i = 0; i <= na; i++) {
rs = st.executeQuery("select Month from dataset");
while (rs.next()) {
i++;
}
}
i = 0;
j = 0;
for (j = 1; j < na; j++) {
//DES
st1.executeUpdate("update secret_key set Monthk= '" + desKey
st2.executeUpdate("update cipher set monthc= '" +
}
generated successfully for Month");
}
try {
for (i = 0; i <= na; i++) {
rs = st.executeQuery("select place from dataset");
while (rs.next()) {
i++;
}
}
i = 0;
j = 0;
for (j = 1; j < na; j++) {
//DES
st1.executeUpdate("update secret_key set Placek= '" + desKey
st2.executeUpdate("update cipher set placec= '" +
}
generated successfully for place");
}
try {
for (i = 0; i <= na; i++) {
rs = st.executeQuery("select disease from dataset");
while (rs.next()) {
i++;
}
}
i = 0;
j = 0;
for (j = 1; j < na; j++) {

//DES
st1.executeUpdate("update secret_key set diseasek= '" +
desKey + "' where metadata='" + j + "'");
st2.executeUpdate("update cipher set diseasec= '" +
}
generated successfully for Disease");
}
try {
File file = new File("D:/ED.csv"); //filepath is being passes
through //ioc
//and filename through a method
if (!file.exists()) {
file.createNewFile();
}
if (file.exists()) {
file.delete();
} else {
file.createNewFile();
}
String query;
//
query = "SELECT metadata,name,agec,genc,monthc,placec,diseasec
into OUTFILE '" + file + "' FIELDS TERMINATED BY ',' FROM cipher";
//
st.executeQuery(query);
query = "SELECT
'metadata','name','agec','genc','monthc','placec','diseasec' UNION ALL SELECT
metadata,name,agec,genc,monthc,placec,diseasec INTO OUTFILE '" + file + "'
FIELDS TERMINATED BY ',' FROM cipher";
st.executeQuery(query);
stime = System.currentTimeMillis();
BufferedWriter bw = new BufferedWriter(new FileWriter("./enc.txt",
false));
bw.write(Long.toString(stime));
bw.close();
}

Reencryption re = new Reencryption();
re.setVisible(true);
public static void main(String args[]) {
/* Set the Nimbus look and feel */
//<editor-fold defaultstate="collapsed" desc=" Look and feel setting
code (optional) ">
/* If Nimbus (introduced in Java SE 6) is not available, stay with the
default look and feel.
* For details see
http://download.oracle.com/javase/tutorial/uiswing/lookandfeel/plaf.html
*/
try {
for (javax.swing.UIManager.LookAndFeelInfo info :
javax.swing.UIManager.getInstalledLookAndFeels()) {
if ("Nimbus".equals(info.getName())) {
javax.swing.UIManager.setLookAndFeel(info.getClassName());
break;
}
}
} catch (ClassNotFoundException ex) {
java.util.logging.Logger.getLogger(DataEncryption.class.getName()).log(java.ut
il.logging.Level.SEVERE, null, ex);
} catch (InstantiationException ex) {
} catch (IllegalAccessException ex) {
} catch (javax.swing.UnsupportedLookAndFeelException ex) {
}
//</editor-fold>
/* Create and display the form */
java.awt.EventQueue.invokeLater(new Runnable() {
public void run() {
new DataEncryption().setVisible(true);
}
});
}
// Variables declaration - do not modify//GEN-BEGIN:variables
private javax.swing.JButton jButton1;
private javax.swing.JLabel jLabel1;

private javax.swing.JPanel jPanel1;
private javax.swing.JPanel jPanel2;
private javax.swing.JScrollPane jScrollPane1;
private javax.swing.JTextArea jTextArea1;
// End of variables declaration//GEN-END:variables
}
SAMPLE SCREEN SHOTS
Run Receievr1.java and Receiver2.java
Click send
For Receiver2
CONCLUSIONS
A novel notion, anonymous multi-hop identity-based conditional proxy reencryption is proposed, to preserve the anonymity for ciphertext sender/receiver,
conditional data sharing and multiple recipient-update. A concrete system is
proposed for the notion. Meanwhile, the system is proved to be CCA-secure in the
standard model under the decisional P-bilinear Diffie-Hellman assumption. To the
best of our knowledge, primitive is the first of its kind in the literature.
REFERENCES
[1] G. Ateniese, K. Benson, and S. Hohenberger, Key-private proxy reencryption, in Topics in CryptologyCT-RSA (Lecture Notes in Computer
Science), vol. 5473. Berlin, Germany: Springer-Verlag, 2009, pp. 279294.
[2] G. Ateniese, K. Fu, M. Green, and S. Hohenberger, Improved proxy reencryption schemes with applications to secure distributed storage, in Network
and Distributed System Security. Berlin, Germany: Springer-Verlag, 2005, pp. 29
43.
[3] G. Ateniese, K. Fu, M. Green, and S. Hohenberger, Improved proxy reencryption schemes with applications to secure distributed storage, ACM Trans.
Inf. Syst. Secur., vol. 9, no. 1, pp. 130, 2006.
[4] M. Bellare and S. Shoup, Two-tier signatures, strongly unforgeable signatures,
and FiatShamir without random oracles, in Public Key Cryptography (Lecture
Notes in Computer Science), vol. 4450. Berlin, Germany: Springer-Verlag, 2007,
pp. 201216.
[5] M. Blaze, G. Bleumer, and M. Strauss, Divertible protocols and atomic proxy
cryptography, in Advances in Cryptology. Berlin, Germany: Springer-Verlag,
1998, pp. 127144.
[6] D. Boneh and X. Boyen, Efficient selective-ID secure identity-based
encryption without random oracles, in Advances in Cryptology EUROCRYPT
(Lecture Notes in Computer Science), vol. 3027. Berlin, Germany: SpringerVerlag, 2004, pp. 223238.
[7] D. Boneh, X. Boyen, and E.-J. Goh, Hierarchical identity based encryption
with constant size ciphertext, in Advances in Cryptology EUROCRYPT (Lecture
Notes in Computer Science), vol. 3494. Berlin, Germany: Springer-Verlag, 2005,

pp. 440456.
[8] X. Boyen and B. Waters, Anonymous hierarchical identity-based encryption
(without random oracles), in Advances in Cryptology CRYPTO (Lecture Notes
in Computer Science), vol. 4117. Berlin, Germany: Springer-Verlag, Aug. 2006,
pp. 290307.
[9] J. Camenisch, M. Kohlweiss, A. Rial, and C. Sheedy, Blind and anonymous
identity-based encryption and authorised private searches on public key encrypted
data, in Public Key Cryptography (Lecture Notes in Computer Science), vol.
5443. Berlin, Germany: Springer-Verlag, 2009, pp. 196214.
[10] R. Canetti, S. Halevi, and J. Katz, Chosen-ciphertext security from identitybased encryption, in Advances in CryptologyEUROCRYPT (Lecture Notes in
Computer Science), vol. 3027. Berlin, Germany: Springer-Verlag, 2004, pp. 207
222.

Privacy-Preserving Ciphertext Multi-Sharing Control For Big Data Storage

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Privacy-Preserving Ciphertext Multi-Sharing Control For Big Data Storage

Uploaded by

Copyright:

Available Formats

PRIVACY-PRESERVING CIPHERTEXT MULTI-SHARING CONTROL

FOR BIG DATA STORAGE

simultaneously, proposed an anonymous IBPRE system, which is CCA

: Any Processor above 500 MHz.

: Standard Keyboard and Mouse.

: VGA and High Resolution Monitor.

: JDK 1.5 or higher

Two-tier signatures, strongly unforgeable signatures, and FiatShamir

two-tier signature schemes with a proof of security that makes a standard

Hierarchical identity based encryption with constant size ciphertext

We present a Hierarchical Identity Based Encryption (HIBE) system where the

cryptographically protect data while keeping it available to be searched and

Data Encryption and re-encryption

SAMPLE SOURCE CODE

public class DataEncryption extends javax.swing.JFrame {

jButton1.setFont(new java.awt.Font("Traditional Arabic", 1, 14)); //

jLabel1.setText("Patient Data Encryption ");

jLabel2.setFont(new java.awt.Font("Traditional Arabic", 1, 24)); //

for (j = 1; j < na; j++) {

byte[] byteDataToEncrypt = plainData.getBytes();

String plainData = nodes[j];

private void jButton7ActionPerformed(java.awt.event.ActionEvent evt)

private javax.swing.JLabel jLabel1;

SAMPLE SCREEN SHOTS

Run Receievr1.java and Receiver2.java

Notes in Computer Science), vol. 3494. Berlin, Germany: Springer-Verlag, 2005,

You might also like