Somewhat Homomorphic Encryption Technique

Implementing Somewhat Homomorphic Encryption Technique
Naishil Shah
nanshah@ucsc.edu
Abstract— The world of network security revolves around a
prime concern - Maintaining privacy of user and it’s data.
It is hard to delegate data to a third party nowadays to
perform some kind of operations on it, provided there is no
security features implemented between them. Hence, the idea
of Homomorphic encryption is of utmost importance to enable
computations on encrypted data without actually giving access
to the third party performing it. The area of Homomorphic
Encryption has been in the research community for a really long
time, but mainly as a theoretical topic of interest. Extremely few
techniques are actually implementable in real world application
scenarios. This paper describes the implementation of a partic-
ular version of Somewhat Homomorphic Encryption Scheme.
It successfully performs operations of addition, subtraction and
multiplication over integers. This implementation is carried
using already existing algorithms and techniques but with few
modifications to enable the above mentioned operations. It also
summarizes the simulation results obtained on actually running
the algorithm over variety of test cases.
I. INTRODUCTION
Encryption techniques have been existent since almost
the 9th Century. Caesar’s Cipher is one of the oldest and
most easy to use encryption mechanism present. But soon
it was realized that it was not at all secure and a variety
of attacks were possible on it. Next phase of encryption
techniques arrived when Symmetric Key Encryption started
being accepted. The idea was to basically use a same key to
encrypt and decrypt the data. There were many algorithms
and schemes developed for this method and they were
all categorized into either Block based or Stream based
Symmetric Key Encryption Techniques. Examples of these
were Advanced Encryption Standard (AES), Data Encryption
Standard (DES), 3DES etc. There were plenty of attacks
which can still be used to crack the above mentioned sym-
metric key encryption techniques. Some of these attacks are -
know plain-text attacks, chosen plain-text attacks, differential
cryptanalysis and linear cryptanalysis.
Next in the phase, came the idea of Asymmetric Encryp-
tion Techniques. This used the idea of using two different
keys for the encryption process and the decryption process
respectively. These are still used in real world scenarios along
with various other encryption schemes to provide as much as
security as possible. Some examples of asymmetric encryp-
tion techniques are Diffie-Hellman Key Exchange Algorithm,
Rivest, Shamir, Adleman (RSA) and Digital Signature. But
again, no scheme is completely secured. Attacks possible on
Asymmetric Encryption include Man in the middle attacks,
brute force attacks, etc.
Until these two schemes, the only thing which could
be done with encrypted data, was decrypt it. There was
no flexibility of manipulating encrypted data. Some people
observed a property in RSA scheme. As seen,
E(m1) = (m1)e
andE(m2) = (m2)e
ergo...E(m1) ∗ E(m2) = (m1 ∗ m2)e
= E(m1 ∗ m2)
the result of multiplication of encrypted data was the same
as the result of encrypting the data and then multiplying it.
Although there was no other property ( like additive ) in the
scheme, the researchers found this multiplicative property as
a starting idea for the concept of homomorphic encryption.
Homomorphic comes from the word Greek word trans-
lating to ’homos’ meaning ’same’ while word translating
to ’morphe’ meaning ’shape’[4]. Homomorphic encryption
is a form of encryption which allows specific types of
computations to be carried out on ciphertexts and generate an
encrypted result which, when decrypted, matches the result
of same operations performed in the same order on the
plaintexts[4].
The remaining of the paper, is in the following format.
Section II introduces and describes some features of the 3
prevalent schemes in literature of homomorphic encryption.
Section III proceeds to discuss the original algorithm and the
changes done done in it for this particular implementation.
Section IV describes the initial scope of the project and
the final implementation. Section V explains the challenges
faced in the implementation of the project and some solutions
to them. Next, Section VI presents, analyses and discusses
some results which were obtained during the test runs of the
project. Finally, Section VII concludes the report and Section
VIII provides a future scope.
II. HOMOMORPHIC ENCRYPTION SCHEMES
First lets start with a generic definition of a Homomorphic
Encryption (HE) Scheme. An encryption scheme is called
homomorphic over an operation * if it supports the following
equation:
E(m1) ∗ E(m2) = E(m1 ∗ m2); ∀m1, m2 ∈ M
where E is the encryption algorithm and M is the set of all
possible messages [4]. Any HE scheme will mainly consist
of four parts. First, generating a key for the encryption and

decryption processes. This can be a single key in the case
of symmetric key encryption or two different (public and
private) keys in the case of asymmetric key encryptions. The
next two parts - Encryption and Decryption Mechanisms,
are also somewhat similar to the classical roles in the
traditional encryptions schemes. However, the last part -
the Evaluation function is a HE specific operation, which
provides a ciphertext output corresponding to a functioned
plaintext.
Currently, HE schemes are categorized into three broad
categories in the literature. These are as given below.
A. Partially Homomorphic Encryption (PHE)
PHE schemes provide support for either of addition or
multiplication operations. This is one of the most basic
HE schemes providing ONLY ONE of the above operation
and NOT BOTH. Examples of this type of scheme are -
Rivest et al. 1978b; Goldwasser and Micali 1982; ElGamal
1985; Benaloh 1994; Naccache and Stern 1998; Okamoto
and Uchiyama 1998; Paillier 1999; Damgrd and Jurik 2001;
Kawachi et al. 2007.
B. Somewhat Homomorphic Encryption (SWHE)
SWHE schemes provide support for only limited number
of operations or some limited circuits (e.g. - branching pro-
grams) [4]. Examples of this scheme are Yao 1982; Sander
et al. 1999; Boneh et al. 2005; Ishai and Paskin 2007. There
were many improvements after 2009 after the first Fully
Homomorphic Scheme was introduced by Gentry. This is
where the paper’s focus lies. We discuss the implementation
of one of the SWHE scheme which was already proposed in
the literature but with some modification which we will be
explaining in the further sections.
C. Fully Homomorphic Encryption (FHE)
This is considered to be the holy grail of the HE schemes.
This is the most theoretically complex scheme and has the
most amount of work done in the research domain, with
the least amount of actually usable outputs. FHE, as you
must have guessed by now, basically supports any arbitrary
computations on homomorphically encrypted data, over and
over again for unlimited times. Imagine the sheer scope
of applications if this is implemented in practice. We can
delegate operations to be done on a set of data to a third
party, without actually giving access to the data itself. The
first scheme of FHE was developed (after almost 30 years
of noticing HE properties in RSA), by Craig Gentry in
his PhD Thesis [1]. He proposal was based on the use
of Ideal Lattices, which involved high computational costs,
complexity and other factors which made it difficult to
actually implement the scheme in real life.
Nevertheless, his thesis also laid a foundation for devel-
oping a FHE scheme, which proved to be a boon for future
research. The next big advancement in the area was in the
very next year of 2010, where Van Dijk et al. proposed
their FHE scheme over Integer. This paper present a highly
simplified approach for successfully implementing a FHE
over simple integers. Though the whole scope of this paper
is huge, we will be implementing only a part of the paper
where it describes a simplified approach of a SWHE.
III. PROJECT ALGORITHM
A. Notations
These are some of the common symbols and notations
which we will be using in the following subsections:
• p - shared secret key
• m - bit of the data
• n - noise
• c - ciphertext
B. Original Algorithm
The paper [3] mentions a SWHE scheme which works
over small degree of polynomials. With some changes in
the key generation, encryption algorithm and the decryption
algorithm, we make the technique work for the operations of
addition, subtraction and multiplication using two integers.
The process for the same is as follows:
• Key Generation : Selecting a random odd numbered
key p, from an interval of [2n−1
, 2n
).
• Encryption : To encrypt a bit m ∈ (0,1), set the
ciphertext as an integer whose residue has the same
parity as the plaintext. Namely, set c = pq + 2r + m,
where the integers q and r are chosen at random in
some other prescribed intervals, such that 2r is smaller
than p/2 in absolute value [3].
• Decryption : The Decryption mechanism provided in
the paper was simple. Output was (c mod p)mod 2.
C. Algorithm Changes
The key generation mechanism and the encryption stage
of the algorithm is useful for us and there no changes made
in it. The changes which have been done in the algorithm
have been listed and explained below.
• The first major change is in the Decryption Stage. As
we saw above, the stage uses ’mod 2’ as a final segment
in its computation to decrypt a given ciphertext. Since
the original ’mod2’ part in the process gives a final
output of either 0 or 1, it was a limiting the working of
the algorithm to only single digit integers which have
a value less than or equal to the mod value which
we provide. Hence we convert ( c mod p)mod 2
to (c mod p)mod X, where X is the limiting integer
value for operations to be performed. Decryption works
properly only if m+2r ¡ p/2. This actually restricts the
depth of the homomorphic operations performed on the
ciphertext.
• For example, let us say X = 100. This means that the
operations will now work correctly until the answer to
those operations in plaintext will be less than hundred.
To elaborate further, addition of 10 and 35 will produce
the correct result of 45, but the addition of 10 and
120 will produce an incorrect result since the resulting

answer now exceeds 100, and this causes the ’mod 100’
segment of the decryption stage to fail.
• The original algorithm also mentioned that the Noise
r, needs to be sufficiently small than the secret key p.
This also can be changed according to the our strength
of the encryption security required by us, by increasing
the length of the secret key and thereby allowing the in-
crease of the noise parameter as well. This will be much
more clearer when we proceed with the implementation
of the project in the coming sections.
IV. SCOPE AND APPROACH
The whole aim of the project was to provide security
features using HE schemes, so that a resource constrained
client can delegate the operations it required to be performed
on a set data, to a third party server without actually giving
the server access to the data itself. Hence, the plan was to
simulate this exact scenario.
For the creation of the client-server architecture, socket
programming concepts in Python were used. But again,
the data transfer between the client and the server should
be protected from prying adversaries. Hence, to transfer
the data, the decision was to encrypt the exchanging of
messages with the use of Advances Encryption Standard
(AES) between the two parties. Python provides a standard
package named pycrypto which includes various encryption
algorithms and hash functions. We used the AES algorithm
library directly from this package, since our focus was on HE
schemes and not how the data is being transferred between
two parties. This approach caused a lot of troubles in the later
stages of the project as we will see in the further sections.
But also helped us infer a crucial aspect of working in this
area which we will discuss later.
The final work flow of the project is as mentioned below.
• Both the client and server both establish TCP connec-
tion with each other.
• The client selects the operation to be performed (addi-
tion, subtraction, or multiplication) and selects the two
integers as the data to be homomorphically encrypted
and performed the operation on.
• Use the HE algorithm discussed above to encrypt both
the integers.
• Encrypt the already homomorphically encrypted data
once again, now using AES libraries so that it can be
transmitted to the server securely.
• The server on getting this as a input, uses its shared
secret key used in AES encryption at client side, to
decrypt the received data. Remember that this decrypted
data is not the original data but the homomorphically
encrypted data.
• It then performs the required operations and computa-
tions on the data as asked by the client.
• Finally it encrypts the final answer once again using the
same AES mechanism, and sends it back to the client.
• The client on receiving the reply from the server, first
decrypts the data to obtain the ciphertext and then uses
decryption algorithm of the HE scheme to reveal the
final plaintext solution.
The complete working of the application is summarized
in the Figure 1 shown below.
V. CHALLENGES
A. Challenges Faced in Implementation
The first challenge faced was that changing the original
algorithm according to our needs. Originally it only sup-
ported addition operation due to the ’mod2’ factor in the
decryption as we previously explained. Several brute force
like methods were used to detect this exact problem which
was limiting the scope of the operations performed. This also
caused incorrect outputs when the operation produced out of
bound results which exceeded the mod value.
The next major challenge was in the use of AES en-
cryption techniques using the pycrypto library in Python.
AES uses CBC (Cipher Block Chaining) method in its
default mode. This has two major restrictions - It does not
support more than 16 bit blocks and secondly it requires
padding. Both of these cause a problem to us since our
homomorphically encrypted data can be padded with extra
bits, since that will make it lose its properties. Also, there is
no guarantee that our encrypted data will be of exactly 16
bit in length.
The final hurdle we faced in our implementation was that
AES supports encryption and decryption of only fixed length
of data. It also does not provide support for long data types in
Python. Again, these technically render our implementation
useless. This is because if we force our encrypted data to be
a fixed length value each time (example - 16, 32, 64, 128
bits), it will lose its security and privacy values after some
brute force attacks.
B. Solutions
As mentioned in the above subsection, there were three
prime problems with the implementation of the application
as a whole. There were few options available for handling
most of the problems and therefore decided to follow their
solutions given below.
• The first solution was handled in a convenient way as
mentioned twice above. Just for clarity, let’s reiterate.
There was a simple modification done in the decryp-
tion stage which changed the ’mod2’ segment to the
’modX’. This change handled both incorrect answers
and operations using other computations.
• Next, the limiting factor of the CBC mode was solved
by using an alternate mode altogether. Ciphertext feed-
back (CFB) is a mode of operation for a block cipher.
In contrast to the cipher block chaining (CBC) mode,
which encrypts a set number of bits of plaintext at a
time, it is at times desirable to encrypt and transfer
some plaintext values instantly one at a time, for which
ciphertext feedback is a method[5]. This solved our
problem and hence we ended up using this mode.
• Finally the most crucial hurdle. The inability of AES
to take into account variable length data as input. This

Fig. 1. Work-flow of the application
really caused a big hurdle in developing the applica-
tion. Various approaches were tried to rectify it. First,
the thought of creating a fixed length encryption was
considered. But this idea instantly was skipped since
this meant compromising the security of the encryption
itself which proves to be counter beneficial to the whole
aim. Next, the use of hash functions and message digests
was considered. Although this helped in reducing the
size of the encrypted data as a whole, the problem
with this method was that the encrypted data lost its
homomorphic properties when it was hampered for
obvious reasons. Hence, this method also could not help
solve this problem in hand. Currently, there is nothing
with us which can help solving this problem and hence
the whole implementation remains stalled due to this
single problem.
VI. FINAL IMPLEMENTATION
Considering the original scope and all the problems en-
countered in the process, the final implementation of the
project is completed as follows.
• The implementation of the algorithm of our modified
version of Somewhat Homomorphic Encryption Scheme
works perfectly and as expected.
• The approach successfully performs Addition, Subtrac-
tion and Multiplication operations on integers. The
value of integers used and the solution obtained depends
on the Mod value as discussed in the previous sections.
• The client server architecture using AES as a security
method for exchanging data was created using the
standard Python library of crypto. But this architecture
failed to exchange the homomorphically encrypted data
between each other due to the third problem described
in section V.
• To provide more flexibility to the user in terms of
whether its requirement is speed of the encryption or
high security, the application provides two options to the
user. They are called as low and high security options
and the user can select its choice at the start of the
application for each operation.
• The low encryption scheme uses a power of 2 for
generating the length of the noise and the key itself.
This causes the final encrypted output to be of a smaller
length but the process itself can be faster.
• The high encryption scheme uses a power of 5 for
generating the length of the noise and the key itself.
This causes the final encrypted output to be of a much
higher length (long enough that I could not attach a
screen shot of it as a sample in the results section), but
the process itself can take some time to complete.
Hence we will only be analyzing the results of the
Somewhat Homomorphic encryption scheme which we have
developed and not the complete client-server architecture as
mentioned earlier. We present and discuss our results in the
coming section.
VII. RESULTS
In this section, we present the results obtained from the
runtime of the simulations of the Somewhat Homomorphic
Encryption Scheme. All possible cases are summarized so
as to help us analyze the properties, computational costs in
each scenario and the efficiency of the algorithm itself. The
results are classified into 4 broad categories as described in
the following subsections. To show an example of how the
application is designed and its simulation, Figure 2 has been
provided below.
The mod value is kept at 100 as a standard in all
the categories. This implies that the final plaintext answer
expected should be under 100 for the algorithm to work.
That said, the user can simply change the value in the code
to modify the value to suit its need.
Also, the following tables mention the runtime of each case
and the unit of time measured in is seconds. We have used
the standard time package available in Python to achieve the

Fig. 2. Example Simulation of Single Digit Addition using Low Security
results.
All the results presented have been achieved by taking an
average value of 6 simulations. For example, the run time
of the Addition operation in any of the case, is the average
value of 6 test runs of that case.
A. Single Digit Integers with Low Security
This case includes the low option selected by the user. As
mentioned earlier, the length of the key and the encryption
is raised to the power of 2.
• Addition - 2.131
• Subtraction - 2.635 Average - 2.384
• Multiplication - 2.386
B. Single Digit Integers with High Security
This case includes the high option selected by the user. As
C. Double Digit Integers with Low Security
This case includes the low option selected by the user. As
D. Double Digit Integers with High Security
This case includes the High option selected by the user. As
E. Analysis
As we clearly observe in the run times obtained above,
the simulation time of each encryption depends on both
the level of security used and how large the data to be
homomorphically encrypted is. The relation between the time
and these two factors, as expected is directly proportional.
The run times of single digit low security cases have the
lowest average value of 2.384 (lowest) whereas those of the
double digit high security cases have an average of 5.460
(highest). This simply validates our theory and assumptions
that on either increasing the data length or the level of
security used, the run time of the process keeps on increasing.
There were a few aberrations seen during the calculation
of these cases but I feel that they must be caused due to
the varying time taken by the random number generator to
generate a case each time.
In terms of the use of this approach in real time application,
I feel that there can be a lot of performance improvements
before actually being deployed. For a given time critical
application, any run time which is more than two seconds
can cause a lot of delay in the entire process. Hence, the
proposed approach can be used as a base foundation to work
on in scenarios where time is not the limiting factor and
is perfectly alright for the application to take seconds to
complete its processing.
VIII. FUTURE SCOPE
The future scope of the topic itself is tremendously huge.
The performance of any encryption scheme is evaluated on
three important parameters - security, simplicity and speed.
I have tried to implement all of these in this Somewhat
Homomorphic Encryption Approach. Based on the history of
HE schemes, we already know how difﬁcult it is to actually
implement them in real life. Even though there have been
advancements in the community since, such as [6] and [7],
the topic is still not good enough to be used in real life.

Coming to the limitations of the paper, the major one is the
incomplete structure of client server architecture to exchange
homomorphically encrypted messages securely. This helped
me realize, that even if have a good homomorphic encryption
scheme, it is very hard to actually use it in the real life
scenarios where the existing techniques and protocols are
based on some assumptions and ground rules on which they
currently operate. The merging of our technique with them
will require a completely innovative approach.
The next area where some work could be carried out is
in improving the timing of the simulations. As mentioned
earlier, our scheme might cause a hindrance in time critical
applications and will fail to perform efficiently. Improving
this will take it one step closer to the actual real life
implementation.
Finally, talking about HE schemes in general, the focus of
the research community has been primarily on FHE schemes
in particular. The area is promising, fruitful and highly
beneficial if used in day to day scenarios, but is highly
complex and challenging to achieve in practice. This said,
schemes have been developed after Gentry and Van Dijk.
which have made advancements in the same field.
IX. CONCLUSION
In todays, Internet-centric world, privacy of data plays a
more significant role than ever before. For highly sensitive
systems such as online retail and e-banking, it is crucial
to protect users accounts and assets from malicious third
parties. Nonetheless, todays norm is to encrypt the data and
share the keys with the service provider, cloud operator,
etc. In this model, the control over the privacy of the
sensitive data is lost.The users or service providers with the
key have exclusive rights on the data. Untrusted providers,
cloud operators can keep sensitive data and its identifying
credentials of users long after the user ends the relationship
with the services. One promising direction to preserve the
privacy of the data is to utilize homomorphic encryption
(HE) schemes. HE is a special kind of encryption scheme,
which allows any third party to operate on the encrypted data
without decrypting it in advance. Indeed, the idea of HE has
been around for over 30 years; however, the first plausible
and achievable FHE scheme was introduced by Craig Gentry
in 2009. Since then, different FHE schemes demonstrated
that FHE still needs to be improved significantly to be
practical on every platform as they are very expensive for
real-life applications[4].
Hence in this paper we present a small approach of a
Somewhat Homomorphic Encryption Scheme. It successfully
implements Addition, Subtraction and Multiplication over
Integers using either of the two levels of security provided
by us. It provides a base foundation for further developments
in the application field.
ACKNOWLEDGMENT
This report is written for the course project of Network
Security ( CMPE253 - UCSC, Spring 2017 ) taught by
professor Dr. Chen Qian. I thank him for providing us an
open ended topic and the opportunity of working on a topic
which we find interesting in the field.
REFERENCES
[1] Gentry, C. Fully homomorphic encryption using ideal lattices. 2009.
[2] Gentry, C., Halevi, S. Implementing Gentrys Fully-Homomorphic
Encryption Scheme. 2011.
[3] Van Dijk M., Gentry C., Halevi S., Vaikuntanathan V. (2010) Fully
Homomorphic Encryption over the Integers. In: Gilbert H. (eds)
Advances in Cryptology EUROCRYPT 2010. EUROCRYPT 2010.
Lecture Notes in Computer Science, vol 6110. Springer, Berlin,
Heidelberg.
[4] Abbas Acar, Hidayet Aksu, A. Selcuk Uluagac, Mauro Conti. A
Survey on Homomorphic Encryption Schemes: Theory and Implemen-
tation
[5] http://searchsecurity.techtarget.com/definition/ciphertext-feedback
[6] Zvika Brakerski and Vinod Vaikuntanathan. 2011. Fully homomorphic
encryption from ring-LWE and security for key dependent messages.
In Advances in CryptologyCRYPTO 2011. Springer, 505524.
[7] Adriana Lpez-Alt, Eran Tromer, and Vinod Vaikuntanathan. 2012.
On-the-fly multiparty computation on the cloud via multikey fully
homomorphic encryption. In Proceedings of the forty-fourth annual
ACM symposium on Theory of computing. ACM, 2191234.

Somewhat Homomorphic Encryption Technique

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Somewhat Homomorphic Encryption Technique

Similar to Somewhat Homomorphic Encryption Technique (20)

Recently uploaded

Recently uploaded (20)

Somewhat Homomorphic Encryption Technique