Hybrid-Homomorphic-Encryption
Symmetrical Disguise : Hybrid Homomorphic Encryption
The primary objective of this project is to implement Hybrid Homomorphic Encryption and
replicate the results of a research paper: “Symmetrical Disguise: Realizing Homomorphic
Encryption Services from Symmetric Primitives
(extended version)“. This involves developing
a practical system that mirrors the outlined evaluations, contributing to a deeper understanding
of the theoretical concepts and demonstrating the real-world applicability of Hybrid
Homomorphic Encryption. The focus is on bridging the gap between academic theory and
practical implementation, shedding light on potential challenges and optimizations in the
process.
So what are these encryption methods?
Homomorphic Encryption
The text introduces Homomorphic Encryption (HE) as a powerful cryptographic concept.
In HE, users generate key pairs and an evaluation key, enabling computation on encrypted
data without revealing the plaintext. This has significant implications for privacy-preserving
cloud computing. However, HE is hindered by inefficiencies, making it mainly of interest
to the academic community. To tackle these challenges, researchers are exploring Hybrid
Homomorphic Encryption (HHE) as a potential solution.
Hybrid Homomorphic Encryption
In a Hybrid Homomorphic Encryption (HHE) scheme, a user encrypts local data with a
symmetric key (K) and encrypts K under HHE’s public key (pk), sending it to the cloud with
ciphertexts and an evaluation key (evk). The Cloud Service Provider (CSP) transforms
encrypted data into homomorphic ciphertexts, reducing computation costs for the client.
The work doesn’t propose a new HHE scheme but focuses on a detailed protocol to
showcase HHE’s practical applicability in real-world scenarios.
- Frameworks and libraries
I used PASTA3 and SEAL Libraries to develop an Hybrid Homomorphic Encryption system and conduct experimentations on the project. <br >
2.Tools and platforms
I used C++ to program and cmake to compile the code. For Symmetric Encryptions, I used Openssl.1
2
3
4SEAL==4.0.0
CMAKE>=3.13
CPP==9.4.0
openssl>=3.0.10
Content of the code
As presented in the paper, the procedural framework comprises three distinctive modules:
SD.Setup, SD.Add, and SD.Query, each intricately linked with three principal entities—
Analyst, User, and CSP. In the present project, a judicious strategy has been adopted wherein
these entities are methodically instantiated as classes. This decision not only imparts a sense of
systematicity to the codebase but also furnishes an object-oriented manifestation of the
theoretical underpinnings. The orchestration of the simulation is tactically orchestrated through
the invocation of class methods within the main function. This structural alignment ensures a
coherent and programmatic emulation of the specified building blocks Turning these entities
into classes is a structured way to make the theoretical plan practical.
Class diagram:
First, classes are constructed here. All three entities generates their RSA keys. Analyst
creates it’s own HE keys, CSP creates it’s own. User generates symmetric key. After the
construction of the classes are finished, analyst starts to build the message m1 with the
method “createFirstMessage”. Upon creation, CSP starts to process the message. In order
to reach evk key from the analyst, Evk key is so large to be able to encrypt. Due to this fact,
analyst encapsulates the evk key using AES and encrypts the key with th public key of CSP.
Finally sends them over to CSP. CSP has to decrypt the message and check it’s integrity.
This behaviour is implemented in the “processMessageFromAnalyst” method of CSP class.
If everything goes well CSP stores the evk key of analyst.
2. ### SD.Add
In this next step, the user puts together a message using the “sendMessageToCSP” method.
Here, the user encrypts its messages and a secret key, resulting in ci and ck. After doing
this, the user saves these values in a file and adds an extra layer of security by encrypting
the file using the AES algorithm. Once this is done, the user sends the message to the Cloud
Service Provider (CSP). The CSP then starts turning the encrypted message into a special
kind of encrypted message called homomorphic ciphertext. This transformation happens by
using the “decompression” method from the CSP class. The process showcases how the
user’s encrypted data is changed into a format that allows for secure computation by the
CSP, making the communication secure and practical within the context of the project’s
goals.
3. ### SD.Query
In the project’s final stage, the analyst encrypts their input, keeping it secure, and then sends
it over to the Cloud Service Provider (CSP). The CSP, acting like a digital evaluator,
processes the encrypted input using the “evaluate” method, a crucial step in the Hybrid
Homomorphic Encryption system. This method allows the CSP to perform computations
on the encrypted data while maintaining its confidentiality. After this assessment, the
analyst decrypts the result, referred to as Cres, using the appropriate decryption key.
Experimentation
The motivation driving this project is centered on the exploration of Hybrid Homomorphic
Encryption through practical experiments. The primary objective is to move beyond theoretical
comprehension and immerse ourselves in the real-world dynamics of this cryptographic
approach. A particular emphasis has been placed on analyzing the computational costs,
specifically how they fluctuate with changes in plaintext within user interactions.
Results
This scheme is working on only one user plaintext. The whole reason of this code is to show the
user how the scheme works and how much time it takes to complete a whole scheme with one
plaintext added by the user.
Below, we can observe the output of the whole scheme and their costs.
image here
According to the output of the program, we can see that the most costly building block is the
SD.Add. It took 17297 milliseconds. The reason being that HHE.Decomp is computationaly
expensive. It took 17010 milliseconds for CSP to operate HHE.Decomp. The second most costly
build block is SD.Setup. RSA key generations, signings and file readings makes this building
block the second most costly building block. The average of RSA key generation is 217.3
milliseconds. Generating HE secret key for CSP and a symmetric key for User took 0
milliseconds. However on the other hand, generating HE keys for analyst took 2099
milliseconds. In the constructor of the analyst four keys are being generated: a public key, a
private key, a relinearization key (evk) and a galois key. Due to this fact, it took more than the
other entities.