High-Level overview for
A Threshold Cryptosystem
Based on Elliptic Curve Cryptography
By
Ben Cohavi with the guidance of Baruch Ziv, Ben Riva and Prof. Ran Canetti
Table of Contents
Introduction ..................................................................................................................................... 3
Background...................................................................................................................................... 4
Participants ...................................................................................................................................... 5
Time Line ......................................................................................................................................... 6
Implementation Details ................................................................................................................... 7
Others’ code ................................................................................................................................ 7
Declaration .................................................................................................................................. 7
Reuse of Code .............................................................................................................................. 7
Performance .................................................................................................................................... 8
Remark ........................................................................................................................................ 8
Encryption ................................................................................................................................... 8
Decryption ................................................................................................................................... 8
Profiling ....................................................................................................................................... 9
Analysis ........................................................................................................................................ 9
Profiling Results ............................................................................................................................. 10
Encryption ................................................................................................................................. 10
Decryption ................................................................................................................................. 10
Analysis ...................................................................................................................................... 10
Further Work ................................................................................................................................. 11
Bibliography & Thanks ................................................................................................................... 12
Supplementary & Final words ....................................................................................................... 13
Introduction
This project implements a Threshold cryptosystem. Unlike ‘ordinary’ cryptosystems where both
the sender and the receiver sides stands for one person each, in a Threshold cryptosystem the
receiver side is actually a group of people. Each of the group members is referred to as ‘Player’,
and the number of Players in the group will be denoted as N.
Each Player has his own private key, and as a group the Players have a public Key, with which
the sender-side can encrypt his messages. The decryption of the ciphered message is only made
possible if K or more Players decide to decrypt it. K stands for the group’s Threshold number.
The protocol, by which I implement this system, although general on its own, is based on Elliptic
Curve Cryptography, and is available through here (section 3.3, page 14):
http://www.math.tau.ac.il/~amnon/Students/ben.riva.thesis.pdf
In this paper I aim to present the high-level design for this project.
Background
Elliptic curve cryptography (ECC) is yet another approach to a public-key cryptography system,
based on the algebraic structure of elliptic curves over finite fields. Using the same key length,
ECC achieves stronger encryption strength than RSA does. Or, similarly, a given encryption
strength can be achieved using smaller keys.
ECC allows a public-key approach for encrypting & decrypting much like RSA. Unlike RSA, where
security relies on the difficulty of finding the prime factors of a large integer, ECC assumes the
infeasibility of finding the discrete logarithm of a random Elliptic Curve element with respect to
a publicly-known base point (a.k.a generating point).
What determines the strength of an encrypted message is the Domain Parameters of the Curve
as well as the order of the generating point (that is, how many different points the point
generates that also satisfies the Curve’s equation).
Participants
The system as a whole involves 3 parties:
1. Sender-side
2. Receiver-side
3. Server
Though both Sender-side and the Server are not inherently a part of this cryptosystem, they are,
nevertheless, supplied in the project’s package – see ‘User’s Guide’ for relevant information.
The relations between the parties can be pictured as follows:
The protocol starts when a group of N players meet and exchange information. By doing so, a
group’s public key if formed. Then, a Sender, by using this key, can cipher whatever message
(file) he wishes and send it to the Server.
The left box stands for the Receiver side where I demonstrate a group of size 4 (N=4). The entire
protocol-related-message-passing is done via a Server. To make it as generic as possible, the
Server knows nothing about the protocol or the messages it passes from one Player to another
(note the double-sided arrows between each Player and the Server). It merely gets a message
from each of the Players, and dispatches them all back to everyone.
Messages between the Server and the Players are sent using TCP connection.
Time Line
I will now describe the chronological progress of the system using a time line:
Each of the depicted phases can be made by a different session, or by a single one (in that case
the Sender-side is assumed to already know the group’s public key).
Walking through the steps:
1. Group Players meet and agree upon a public key, which is made public for any sender.
2. A Sender how wishes to send an encrypted message to the group, sees the group’s
published public key, and uses it.
3. The ciphered message finds its way to each of the Players. This can be done by putting it
on a reachable server, privately sending it to the Players by email or handing a copy of
it.
4. The Players meet again so each would sign on the ciphered message if he wishes so. The
protocol states two kinds of messages: a public message and a private one. While a
public message is written by one Player and can be viewed by the rest of them, a private
message is encrypted using an RSA mechanism, and thus can be viewed only by the
intended recipient. To allow this, the first message each Player transmits is its own
public RSA-key. Thus, any private message meant for a specific Player will be decrypted
using this Player’s public RSA-key. Upon receiving such public RSA-keys (each Player gets
N-1 keys), each Player saves them for any future private-messaging.
5. Only if more than K Players had agreed to decipher the message, will the deciphering
process be made possible.
NOTE: steps (1) & (4) is where the implemented protocol actually takes place.
Implementation Details
The project was implemented using the C++ programming language and was implemented and
compiled under Microsoft Visual Studio 2008 – Professional Edition.
The code I supply compiles error-free & warning-free when compiling under Debug mode as
well as Release mode. Others’ code that I’m using, although error-free, does produce some
warnings.
Should one wants to use the ICP tool (explained later), and, chooses the USE_OS_TIMING flag,
then an additional linking phase is needed in order for it to compile correctly. In such a case, one
needs to add to the linker options the following lib file: Ws2_32.lib.
Besides that, since the RpcNdr.h file #defines the word ‘small’ as ‘char’, and since the NTL library
has in its c_lip_impl.h file few variables that are called ‘small’, I had to change the latter to
‘small1’. This was done by me, so no further changes should be made to c_lip_impl.h.
Others’ code
The following packages weren’t written by me:
1. The SHA protocol I used in order for the Players who wish to open the message was
taken from here.
2. The communication side between any of the Players and the Server was taken from
here.
3. The assert module I’m using was taken from here, and here.
4. No Elliptic Curve project can be designed without some kind of ‘Big Numbers’
library. This project is no exception to this rule. NTL is the library I choose for
computing an arbitrary large numbers. Documentation on the library can be found
here.
Declaration
I hereby state that besides the above 4 packages, all other code was written entirely and solely
by me, and me alone. All ideas, techniques and methods used, for better or for worse, are all
mines, and mine only.
Reuse of Code
All source code, except for the ICP tool, can be used freely.
The use of ICP is allowed only for future versions of this project. Should one wants to use it for
any other purpose, he or she may do so only after a written consent by me, and me alone.
Performance
Considerable amount of thought and work was given to this issue. Yet, making a long story
short, I have to say that I can’t see this program being used anywhere in practice.
As a rule of thumb, performing arithmetic operations using the NTL library is expensive in time. I
didn’t have the chance to test other such libraries so no comparison is available for this part.
To avoid using NTL objects, where ever it was possible a native ‘int’ was used. Thus, for example,
instead of multiplying NTL elements one by one, a lazy approach was used, and a set of integers
was kept. Only after finishing the computation, did NTL elements came to use. This trick alone
resulted in twice as fast a decryption process.
It is important to notice that performance is not affected by the implemented protocol as it
happens only one-time when the Players meet and exchange data.
Remark
All numbers presented below were measured while testing a version which was compiled in
Release mode. In addition, all results reported here are for a specific Elliptic Curve. This curve
was chosen so as to make the findSquareRoot method be as quick as possible. Hence, the below
measurements are actually an upper bound for other tests.
Encryption
The encryption process performs pretty poorly, averaging barely a 20 Kbytes/second rate on a
2.4 GHz Pentium 4 (single) processor. Thus, making it highly impracticable for almost any use.
Although slow, this rate is achieved after earlier versions resulted in merely 3.5 Kbytes/second
(see Profiling section).
Furthermore, the encrypted file is actually a text file that contains digits. These digits represent
points on the Elliptic Curve. The size of the encrypted file can reach sizes that are 10-11 times
larger than the input file. This is both unacceptable for large input files, as well as much less
desirable when the Sender wants to deliver the encrypted file to the group’s members. One
might consider other ways of representing this data (i.e. switching to binary file etc.). Such ideas
while no doubt will reduce output file’s size will most probably slow the application even more.
Having said all that, one can still zip the text files.
Decryption
The decryption process is even worse, as anyone who wants to decipher the message needs to
verify every single (a,b) pair.
Profiling
In order to fully understand where the bottle-neck of the system is, a special In-Code Profiler
(ICP) had been designed & implemented. Its tracks are noticeable at the entrant of every timeconsuming function and it is embedded throughout the code (using #define one can either turn
it on or off).
ICP collects data such as how much time we spent in each function, stack history, how many
times a function was called and by which function. At the end of the program, it then prints (to a
file) a table containing the collected data.
An example such a profiling analysis can be seen in the Profiling Results sub-sections.
Analysis
The most expensive operations (not functions) are: (A) InvMod, which finds the inverse number
of a given integer under a given field modulo, and (B) PowMod, which raises one NTL object to
the power of another NTL object and finally computes the result modulo a third NTL object.
These two operations lay in the heart of two functions: the plus operator between any two
elliptic points and the findSquareRoot method, used to find the y-coordinate of a elliptic point
given its x-coordinate. These functions are invoked proportionally to the input file’s size
(encryption talking). As for the decryption process, there is no need in calling the
findSquareRoot method and thus it results in a higher performance rate.
It is important to understand that the findSquareRoot method is called very often – for every 20
bytes read from the file we wish to encrypt, this function gets called. The reason it is called
every 20 bytes is due to the size of modulo of the field we work under. The larger the modulus
is, the fewer invocations to this method will be made, which may result in a better running time.
On the other hand, larger prime might slow other calculations.
One more note: findSquareRoot is more sensitive to file’s size, meaning for larger files, its
overall time is higher than that of the plus operator.
Profiling Results
I will now present some profiling measurements that were collected during the encryption and
decryption of 1 mega input file. I present only more than a 5% time-consuming functions.
Encryption
Function Name
Time / Total time
%
Util::findSquareRoot
(48.004%)
128421811 / 267525304
StandardEllipticPoint::operator +
(13.907%)
37204775 / 267525304
StandardEllipticPoint::Legendre
21847103 / 267525304
(8.166%)
EncryptedFile::addEncryptedMessage
20904729 / 267525304
(7.814%)
actAsCipherer
15784572 / 267525304
(5.900%)
Util::convertNumberToPoint
14985125 / 267525304
(5.601%)
Decryption
StandardEllipticPoint::operator +
(25.018%)
52847534 / 211238274
Protocol::Decipher
(12.568%)
26547545 / 211238274
Protocol::receiveMessageAsAWhole
(11.554%)
24405642 / 211238274
FileToDecrypt::getNextMessage
13708045 / 211238274
(6.489%)
StandardEllipticPoint::operator ==
13531600 / 211238274
(6.406%)
Analysis
As expected, on protocol-related functions appear here. Both the PowMod function (within the
findSquareRoot method) and InvMod function (within the plus operator) count for most of the
time during the encryption process. As for the decryption process, a quarter of the time is spent
in the plus operator.
Further Work
I will now present the work, which in my mind, needs to be done to improve this project:
1. First and foremost, combine this project with other projects. Make it receive ‘strong’
elliptic curves, maybe even such that are chosen for its quick arithmetic capabilities.
2. Making this project run on Linux as well. This issue would involve adapting the NTL
library.
3. Adding the ability to represent Elliptic Points using its Projective representation (current
implementation uses standard Elliptic Points representation). By switching to Projective
Point representation, arithmetic operations should result with higher performance
rates. This would most certainly speed-up the encryption process.
4. Although NTL declares itself as implementing arithmetic algorithms quite efficiently, one
can never be too sure. Searching for better algorithms might speed up things.
Bibliography & Thanks
Guide to Elliptic Curve Cryptography / Darrel Hankerson, Alfred Menezes, Scott Vanstone
Prime Numbers: A Computational Perspective / Richard Crandall, Carl B. Pomerance
http://en.wikipedia.org/wiki/Elliptic_curve_cryptography
I would like to thank the following persons:
1. Mr. Baruch Ziv – for his guidance in learning the foundations of Elliptic Curve
Cryptography.
2. Mr. Ben Riva – for his help in selecting a project as well as walking me through
difficulties along the way.
Supplementary & Final words
During the work on the project I learned a lot about the nature of Elliptic Curves, its history and
about its wide variety of applications. This was both demanding and interesting.
The study of the ‘threshold cryptosystem’ protocol was fascinating on its own. Implementing it
wasn’t easy as debugging such programs that involve very large numbers is not intuitive.
Nonetheless, the difficulty turned into a challenge which concluded in a fun time.
The optimizing phase, although not specifically required by my instructor, was very appealing to
me. This required a good understanding of the algorithms in use, and the workflow of the
program. During this activity, I started developing a tool I call ICP (In-Code Profiler). The
construction of which, mandated me to explore several profiling techniques and was very
fulfilling.