The Implementation
and Adoption
of ECC for PKI
By Brian Saville & Jonathan Mitchell
TABLE OF CONTENTS
Table of Contents ....................................................................................................... 2
Abstract .................................................................................................................... 3
Introduction .............................................................................................................. 4
Background ............................................................................................................... 4
Elliptic Curves ......................................................................................................... 4
Mathematical Properties ........................................................................................... 5
Finite Fields ............................................................................................................ 5
Generating Parameters ............................................................................................ 6
Public Key Infrastructure ............................................................................................. 7
Algorithms .............................................................................................................. 7
ECC and RSA in PKI ................................................................................................. 7
ECC Key Generation................................................................................................. 8
Weaknesses ............................................................................................................ 8
Approach .................................................................................................................. 9
Methodology ........................................................................................................... 9
Experimentation .................................................................................................... 10
Results & Analysis .................................................................................................... 10
Key Generation Time ............................................................................................. 10
Data Encryption Time............................................................................................. 11
Adoption of ECC ....................................................................................................... 11
Conclusion............................................................................................................... 12
Recommendations ................................................................................................. 12
References .................................................................... Error! Bookmark not defined.
Appendix................................................................................................................. 13
Point Addition ....................................................................................................... 13
Point Multiplication ................................................................................................ 13
Time Testing ......................................................................................................... 14
ABSTRACT
Security in digital communications today depends on cryptography, and specifically on
Public Key Infrastructure (PKI). Public Key Infrastructure relies on algorithms for generating
asymmetric keys. The current algorithm in use is RSA, which uses mathematical properties
of prime numbers and the complexity of factoring large numbers to generate secure
asymmetric keys. A newer algorithm that could be used is Elliptic Curve Cryptography
(ECC). Elliptic Curves have mathematical properties such that asymmetric keys can be
generated which are much stronger than those created by RSA.
To investigate the use of ECC for PKI, the authors first implement a basic Elliptic Curve
generator in C# through which they can measure key generation and encryption durations.
ECC is compared to RSA in terms of raw key size and also comparative key strength. It is
demonstrated that RSA is faster than ECC for both key generation and encryption using the
same raw key sizes, but when the comparative key strength of ECC and RSA is taken into
consideration, ECC is orders of magnitude faster than RSA for the same security.
Finally, the issues preventing the adoption of ECC for PKI are discussed. Despite intellectual
property rights prohibiting the use of ECC in PKI for now, the largest obstacle to ECC
adoption will be replacing the current PKI infrastructure that uses RSA. It can be expected
that ECC will become standard by 2020.
INTRODUCTION
The world today is largely defined by
technology, with the digital world of
personal computers and social networks
reigning supreme. In a domain where so
much information is available and being
transmitted at any given point in time,
information security is becoming a topic of
great importance. The field of
cryptography permeates through
information security, and covers issues of
encrypting messages such that personal
information remains private, and the
exchanging of keys such that secure
communication is possible.
A heavyweight in the arena of
cryptography and information security is
the Public Key Infrastructure (PKI). PKI
relies on two asymmetric keys, such that
a message that is encrypted with one key
can only be decrypted with the other. In
the implementation of PKI, an entity will
keep one key private and broadcast the
other publicly. A message that is then
encrypted with the sender's private key
can only be decrypted by using the
sender's public key, and as such one can
ensure that the message did indeed
originate from that sender.
The PKI infrastructure that is in place
today relies on the RSA algorithm, named
after the authors who created it. RSA
relies on interesting properties of large
prime numbers to generate asymmetric
keys. However, RSA has been around a
long time and is beginning to show some
weaknesses; the keys used in RSA are
becoming longer and longer to provide the
same level of security as they used to.
However, a newer algorithm has arrived
on the scene which uses interesting
properties of elliptic curves to generate
asymmetric keys. These keys are stronger
and shorter than the RSA keys. As such,
Elliptic Curve Cryptography (ECC) will
likely replace RSA as the algorithm of
choice for implementing Public Key
Infrastructure. As evidence of this shift,
the US National Security Agency has
recommended the use of ECC in its Suite
B set of algorithms to protect top secret
data.
The purpose of this study was to
investigate the mathematical foundation
of ECC, to implement it as a computer
may execute it, and to conduct a series of
experiments comparing it to RSA. We
performed experiments in the context of
the comparative strength of ECC and RSA
in order to achieve a true comparison of
security-per-time-spent. We then
researched what has currently prevented
the adoption of ECC in PKI, as well as
when the community at large can expect
to see ECC in use.
BACKGROUND
This section contains information on
elliptic curves in general, their
mathematical properties, curves in finite
fields, and generating curves
programatically.
Elliptic Curves
An elliptic curve is defined by an equation
of the form y2 = x3 + ax + b,
where a and b are arbitrary constants. An
example of an elliptic curve is shown in
Figure 1.
Figure 1: Basic Elliptic Curve1
1
http://www.deviceforge.com/files/misc/ce
rticom_figure6.gif
Mathematical Properties
Elliptic curves have some unique qualities
that make them useful for certain
applications. If a point is added to the
curve at infinity, called “O,” and some
operations are defined, the points on the
curve form an abelian group. One
important operation is point addition. The
sum of two points on an elliptic curve is
the negated point where the line between
those two points intersects the curve a
third time. An example of point addition is
shown in Figure 2.
Figure 3: Point Addition Rules
Finite Fields
Figure 2: Point Addition2
The nature of the elliptic curve is such
that the addition of two points will always
generate a third, except in the case of a
vertical line. In such a case, the sum of
the points equals the point-at-infinity O.
In the case that a point is added to itself,
the tangent line at that point is used, and
will result in a negated second point being
the sum. The complete rules for point
addition are shown in Figure 3.
2
Stallings Fig 10-9b.
The elliptic curve has many neat and
interesting properties, but the points on
the curve may contain floating point
numbers, which are numbers with
decimals. In order to use elliptic curves in
cryptography, the curve must first be
wrapped into a finite field. The two most
common fields used are a prime field Fp,
which is easier to implement in software,
or a binary field F2m, which is easier to
implement in hardware [1]. For a
software implementation such as ours, the
curves are most often wrapped in the
prime field, which is done by using a
modulus. Using a modulus is similar to
telling the time using a clock; we count up
to 12 and then “wrap around” and
continue counting at 1. Thus, our standard
clock uses a 12 for its modulus, and we
know that the hour will never exceed 12.
Applying a similar modulus to elliptic
curves creates a finite field of integers
within which cryptography can work.
When elliptic curves are placed in a finite
field, the graphical representation of the
curve is no longer applicable, but the
algebra is. Hence, we are still able to do
point addition, with the added benefit that
the resultant point will always have
integer values. An example of the valid
points on a finite elliptic curve is shown in
Figure 4. The total number of points on a
curve is referred to as the curve's order,
or mathematically as #E(Fp) or #E(F2m).
Each point on the curve also has an order,
which is the smallest number that, when
multiplied with the point, results in the
point at infinity. One more term that is
commonly used in ECC is the cofactor,
which is simply the curve order divided by
the point order, or #E(Fp) / n.
5. Compute h0 as the bit string obtained
from the w rightmost bits of h.
6. Let z be the integer whose binary
expansion is given by the string s.
7. For i from 1 to v do the following:
a. Define the k bit size string si to
be the binary expansion of the
integer (z + i) mod(2k).
b. Compute hi as the SHA-1 hash
of si.
8. Compute h as the bitwise or operation
of h0, h1, h2,...hv.
9. Let c be the integer whose binary
expansion is given by the bit string h.
10. If c = 0 or 4*c + 27 mod p = 0, then
go back to step 3.
Figure 4: Elliptic Curve in a Finite Field
Our implementation of point addition in
C# code can be found in the Appendix.
Generating Parameters
Several parameters must be defined to
fully create a curve for use in
cryptography. Following is a step by step
method to generating an elliptic curve in
the Fp field [8]:
1. Generate p, a large prime modulus to
be used in the curve arithmetic. In
order to speed up modular
multiplication, NIST recommends that
a special type of number called
generalized Marsenne numbers be
used for p such as 2521 - 1 or 2192 – 264
- 1 [8].
2. Set the following values for l, v, and w
for a key size of k:
l = bit length of p
v = (l - 1) / k
w = l - k*v - 1
3. Choose an arbitrary string of k bit
length and call it s.
4. Compute h as the SHA-1 hash of s.
11. Choose two integers a and b to fulfill
the equation c*b2 mod p = a3 mod p.
NIST gives the simplest choice as a =
b = c, but also recommends choosing
others for performance reasons.
12. Verify that the elliptic curve given by
the equation y2 = x3 + ax + b has a
suitable order r. This can be
calculated using Hasse's theorem,
which gives the estimate of #E(Fp) as
p + 1 - 2*sqrt(p). If it does not have
a suitable order, meaning that the
order is not a large enough number,
go back to step 3.
13. Choose a base point by generating a
random X value in the Fp field, finding
the corresponding Y value, and testing
if the resulting point also has a
suitable order n. Suitable order in this
case results in a cofactor of 1, 2, or 4
by NIST's recommendation. To
reiterate, the cofactor is obtained by
dividing the curve order by the point
order, or r/n. If the cofactor is too
large, increment the X value by one or
generate another random value and
test again until a suitable one is found.
PUBLIC KEY
INFRASTRUCTURE
This section contains information on the
current central algorithms used in PKI, the
use of ECC in PKI, the patent issues
involved, and the known weaknesses of
ECC.
Algorithms
PKI uses asymmetric algorithms, and
sometimes symmetric algorithms
additionally, to encryption
communications between two systems.
Symmetric algorithms require that a
secret key be first generated and
exchanged between the communicating
servers, while asymmetric methods make
use of one way mathematical functions.
Symmetric algorithms are not fit for
initiating communications over the
internet, because a secret key must first
be exchanged. For this reason,
asymmetric keys are often first used to
set up a secure connection over which the
symmetric key can then be transmitted.
Although there are many different
asymmetric algorithms, the most
commonly used today is RSA, which
stands for the names of its creators. RSA
keys are computed by multiplying large
prime numbers together.
There are algorithms that exist to solve
these problems. For RSA, there is the
general-number-field-sieve algorithm
(GNFS). This algorithm runs in subexponential time, meaning that the time it
takes to run is somewhat less than 2k,
where k is the length of the key.
Currently, the best algorithm to use on
ECC is Pollard’s Rho Attack, which runs in
full-exponential time [10]. The differences
in the available algorithms that can be
used to attack these difficult problems are
the reason for ECC being much stronger
than RSA.
Figure 5 gives approximate equivalent key
sizes for ECC, RSA, and the symmetric
AES algorithm. From the table it is clear to
see that ECC affords the same security as
RSA while using significantly smaller key
sizes.
Figure 5: Comparative Key Strengths3
ECC and RSA in PKI
The strength of an asymmetric encryption
algorithm such as ECC and RSA is found in
the complexity of computing the inverse
of the function used to generate the key.
Creating the key is straight forward, but
finding the inputs that were used to create
the key is computationally infeasible. In
RSA, the computationally intense problem
is called the “Integer Factorization
Problem”, and has to do with the fact that
it is very difficult to find the factors of
very large prime numbers. In ECC, the
computationally intense problem is called
“Elliptic Curve Discrete Logarithm
Problem”, and involves the difficulty in
computing the discrete logarithm
(exponent) from the result.
As stated by the NSA, ECC is not only
more secure, but are also
"computationally efficient than the first
generation public key systems, RSA and
Diffie-Hellman" [6]. This fact is
demonstrated in Figure 6, where the ratio
of Diffie-Hellman computation versus ECC
computation for different key sizes. It is
important to note that at a key size of
192, the smallest recommended by NIST,
elliptic curves are computed 32 times
faster than DH.
3
http://www.deviceforge.com/articles/AT42
34154468.html
data to send as a point Pm, which
does not necessarily need to lie on the
chosen curve.
5. Alice sends Bob a pair of points
consisting of G multiplied by a
randomly chosen integer k and
another point calculated by adding
Pm to Bob's public key P also
multiplied by k.
SentPair = {k*G, Pm + k*P}
Figure 6: Security Level by bits [6]
ECC Key Generation
There are many methods for generating
keys for use in PKI, with one of the most
common being Diffie-Hellman (DH).
When applied to ECC, the algorithm is
called Elliptic Curve Diffie-Hellman
(ECDH). Suppose there are two people,
Alice and Bob, who wish to speak to each
other privately, but they must use a
transport which can easily be
eavesdropped by another, namely Eve. In
order to send data back and forth, Alice
and Bob decide to use ECDH to
communicate. The steps they must use
are as follows:
1. Agree on the parameters of an elliptic
curve to use. The parameters that
must be generated and agreed on are
the curve constants a and b, the
modulo p, the curve order N, and the
base point G.
2. Each person must generate n, which is
their private key, and multiple the
base point G by n, resulting in their
public key P.
n = random integer
P = n*G
3. Public keys are exchanged between
Alice and Bob over the possibly
eavesdropped transport.
4. After the keys are exchanged, Alice
can begin sending encrypted data to
Bob by first representing her text or
6. Bob receives the pair of points
containing encrypted data from Alice
over the transport, and deciphers it by
making use of mathematical
properties. He decodes the pair by
taking the second point and
subtracting his own private key
n multiplied by the first point. This
results in the original encoded point
Pm due to the nature of addition and
multiplication over the curve. It is
important to remember that Bob's
public key was derived from the base
point, and so this step reduces to Pm.
Pm + k*P - n(k*G) = Pm + k(n*G) n(k*G) = Pm
It is important to note that when the point
Pm is larger bitwise than the keys
themselves, encryption will fail. For this
reason, it is best to split the data to be
encoded into chunks smaller in bits than
the key size.
Weaknesses
ECC is inherently more secure because it
does not use a common algebra. Its
custom algebra has been utilized for
attacks against current algorithms such as
RSA. The NSA has said that unlike the
RSA cryptosystem that has "slowly
succumbed to increasingly strong attack
algorithms, elliptic curve cryptography has
remained at its full strength since it was
first presented in 1985" [6]. Some have
said that this is due to ECC not being used
in many full production environments, and
that only recently ECC has been probed
for weaknesses. Because of this, "the
confidence level in ECC is not yet as high
as that in RSA" [1]. It is unknown
whether full investigation into elliptic
curves in cryptography will reveal further
weaknesses, but the fact that it has this
long with so few weaknesses does bode
well for its future.
Most of the weaknesses revealed so far in
ECC are due to poorly chosen parameters.
For example, many safeguards are used
in generating a modulus p due to the
weakness of the discrete logarithm
problem if such factors are not
considered. On the other hand, even the
best attacks, such as Pollard's rho attack,
runs in exponential time, which means
that ECC is still considered quite secure.
Even though elliptic curves over F2m are
vulnerable to attacks that run in subexponential time, curves over Fp "have
well-established properties that make
them attractive for practical
implementations" [2].
APPROACH
In order to gain a better understanding of
ECC and how it compares to RSA for
cryptography, we implemented the ECC
algorithm in code. To compare ECC vs.
RSA, we built a suite of tests that would
measure the duration of time for key
generation and encryption of various key
lengths. We then plotted the results on
graphs both according to raw key size and
comparative key strength.
Methodology
We created an implementation of ECC
using the C# language with the Visual
Studio 2008 editor. Version control was
managed using Subversion, with both the
subversion repository and the wiki
documentation hosted by Google Code at
http://code.google.com/p/byu-ecc. We
also utilized several external libraries:
NUnit for testing, a C# wrapper for the C
GMP library, and a graphing library called
ZedGraph. The links for these libraries as
well as sample code is provided in the
Appendix.
In the course of creating the framework to
create elliptic curves and ECDH keys, we
discovered that we were unable to
correctly find a base point in our custom
generated curves. The reason is that we
could not correctly find a Y value given an
X value. Because of this, we were never
able to truly find an existing point on the
curve, and therefore could not find a base
point of the correct order. We solved this
issue by using the parameters provided by
NIST in their recommended curves over
prime fields at key sizes of 192, 224, 256,
384, and 521 [8]. Following is a brief
description of the overall method used to
generate keys using the techniques
described in previous sections:
1. Select a NIST curve of a desired bit
key size.
2. Generate a private and public key for
system or object A and B.
While our implementation does not define
the curve parameters, the private and
public key pairs for ECDH are created
dynamically. The ECDH encryption
method described above was also
implemented. Physical transportation
between the encoder and the decoder
were ignored for simplicity of the
experiments, with the decoder taking the
encrypted messages directly from the
encoder's properties. Following is brief
overview of the encoding and decoding
process:
1. Select a NIST curve of a desired bit
key size.
2. Generate a private and public key for
system or object A and B.
3. Encode a data string of arbitrary
length
a. Split the data into chunks smaller
than the key size in bits.
b. Convert each chunk into a point
representation.
c. Convert the resulting point as an
ECDH encrypted pair of points.
d. Store the encrypted pair in
memory.
4. Decode the stored encrypted pairs
stored in the encoder
a. Retrieve a pair of points.
b. Decipher the original encoded point
Pm using the method described in
the ECDH process above.
c. Convert the point Pm back into the
original data string.
d. Add the string chunk to the overall
decoded string data.
In order to demonstrate the properties of
elliptic curves over the finite field Fp, we
also created a light GUI interface to
demonstrate finding points on a simple
curve. For these examples, we did not
use large prime numbers, but rather small
values which made it easy to calculate
points. Figure 7 shows a screenshot of
the demonstration GUI generating points
on a curve and graphing them on a grid.
for each algorithm. This test was run for
the same key sizes as the first
experiment, and compared in the same
manner by similar key size and key
strength.
RESULTS & ANALYSIS
This section contains the results and
analysis of our experiments involving key
generating and data encryption timing.
Key Generation Time
The results of our experiment on key
generation time for ECC vs. RSA are
shown in Figures 8 and 9. First, it is
evident from Figure 8 that for the same
key size, ECC generates keys much slower
than RSA. Note that the scale used here
is logarithmic.
Figure 7: ECC Demonstration GUI
The RSA functions used in our
implementation were also custom made,
but are outside the scope of this paper.
Suffice it to say that we followed a very
simple and easy implementation of RSA
for our experiments which could accept
some set values of key sizes for testing.
Experimentation
Two experiments were conducted using
the custom implementation of RSA. First,
we tested the time it took to generate
keys for both ECC and RSA at key bit sizes
of 192, 224, 256, 384, and 521 for both,
and at 1024, 2048, 3072, 7680, and
15360 for RSA alone. We compared the
results first by similar key sizes and also
by similar key strength sizes using the
NIST guidelines for public key sizes. The
second test we conducted was to encrypt
data files of sizes 1K, 10K, 100K, and 1M
Figure 8: Key Generation Times by Key Size
However, when the comparative strength
of the keys is taken into consideration, as
shown in Figure 9, ECC is not only faster
than RSA in all cases but also shows a
much shallower rate of increase in key
generation times as opposed to RSA.
Again note the logarithmic scale for
generation times. This definitively shows
that ECC is much faster than RSA in real
world scenarios where key strength is
more important than the key size itself.
Figure 11: Encryption Times by Key Strength
Figure 9: Key Generation by Key Strength
Data Encryption Time
Similar results to key generation times
were found when comparing ECC and RSA
in data encryption. For the same key size,
ECC is orders of magnitude slower than
RSA, as shown in Figure 10.
Interestingly, as the files became larger,
the speed advantage of ECC over RSA
diminished. The exact cause of this
behavior is unknown, but it is assumed to
be due to a naive implementation of
chunking in the ECC algorithm. In other
words, the RSA algorithm was most likely
better at splitting up the file and
processing the chunks individually. With
this in mind, the data again shows that
ECC is faster than RSA at similar key
strengths, especially as the key size
increases.
ADOPTION OF ECC
Figure 10: Encryption Times by Key Size
However, when comparing keys of the
same strength, ECC proved to be faster
than RSA in all but the smallest key sizes
as shown in Figure 11. RSA times were
marked by a steep slope as file key size
increased (again note the logarithmic
scale), whereas ECC encrypting times
were generally constant regardless of key
size. Here the 1M file took too long to run
in time constraints, and therefore it was
limited to only the 192 and 256 bit key
sizes of ECC and the 1024 and 3072 sizes
of RSA.
It is clear that though the technology and
algorithms are present to immediately
make use of elliptic curves in
cryptography, there are still some issues
preventing the mass adoption of ECC.
One of these issues is the amount of
patents covering ECC. The NSA has
observed that many "view the intellectual
property environment surrounding elliptic
curves as a major roadblock to their
implementation and use" [6]. Some
organizations that hold patents include
Hewlett-Packard, Sun, Apple Computer,
Cylink, the NSA, RSA Data Security, and
Certicom. A few of the companies, such
as Sun, are open to others using their
patents freely and have even openly
donated technology utilizing ECC to open
source projects. On the other hand,
Certicom alone holds most of the related
patented intellectual property, including
over 130 patents covering elliptic curves
and public key cryptography in general
[6].
Although most of the patents will expire
by the year 2020, the NSA has currently
worked through this problem by obtaining
licenses from Certicom for use in
encrypting top secret information. For
others, the most important point about
these patents is that elliptic curve
cryptosystems themselves are not
patented, only specific implementations
[7]. This means that although a specific
fast implementation may be patented, a
relatively comparable algorithm may be
substituted in its place. Perhaps the
largest factor in preventing adoption of
ECC lies not in the intellectual property,
but in the logistical problems involved in
changing current system encryption
methods to ECC. The transition will
"require mass replacement of hardware
and software to be compatible with ECC"
[9]. The cost for such a move in time and
money will be extraordinary and is likely
the largest cause of the slow adoption of
ECC. That being considered, it can be
expected that ECC will be in common use
by 2020.
CONCLUSION
Elliptic Curve Cryptography is an exciting
field of study and has promise to greatly
enhance the security of electronic
communications. Through our
experiments, we have demonstrated that
ECC is superior to RSA in run time for
keys of comparative strengths, and
therefore is the preferred choice over
RSA. Unfortunately, due to the intellectual
property rights and patents that have
severely limited the use of fast
implementations of ECC in the public
domain, as well as the cost required to
replace the current RSA-based PKI
infrastructure, ECC may still remain
largely unused for many years to come.
Recommendations
Future work in this area would include
implementation of algorithms to find a
base point given an arbitrary curve. In the
current implementation, we had to use
NIST recommended curves in our
experimentation due to their inclusion of a
base point. There are algorithms for
finding a base point, but implementing
them proved out of scope and time
constraints for this project. Other possible
work may include faster implementations
of current algorithms, and producing a
standardized format for communicating
public keys and encrypted data.
REFERENCES
1. Stallings, William (2008).
Cryptography and Network
Security: Principles and Practices
(4th ed.) New Delhi: Prentice-Hall.
2. http://citeseerx.ist.psu.edu/viewdo
c/download?doi=10.1.1.35.1946&r
ep=rep1&type=pdf
3. www.certicom.com/index.php/10introduction
4. www.certicom.com/index.php/20elliptic-curve-groups-over-realnumbers
5. http://www.secg.org/download/aid
398/certicom_patent_letter_SECG.
pdf
6. http://www.nsa.gov/business/prog
rams/elliptic_curve.shtml
7. http://www.rsa.com/rsalabs/node.
asp?id=2325
8. http://csrc.nist.gov/publications/ni
stpubs/800-56A/SP80056A_Revision1_Mar08-2007.pdf
9. http://gcn.com/Articles/2007/08/0
3/Encrypting-the-future.aspx
10. http://www.deviceforge.com/articl
es/AT4234154468.html
APPENDIX
This appendix contains information about the C# implementation of ECC and RSA used in
experimentation as well as sample code. Our implementation used several external libraries
in order to simplify the project and to make code generation easier:




NUnit: http://www.nunit.org/
GNU Multi-Precision library (GMP): http://gmplib.org/
BigInt C# GMP Wrapper: http://www.emilstefanov.net/Projects/GnuMpDotNet/
ZedGraph: http://zedgraph.org/
Point Addition
This implementation is a straightforward application of the rules of point addition.
public static Point operator +(Point p1, Point p2) {
if (p1.IsInfinity && p2.IsInfinity) return Point.Infinity;
if (p1.IsInfinity) return p2;
if (p2.IsInfinity) return p1;
if (p1.x == p2.x && p1.y != p2.y) return Point.Infinity;
if (p1.x != p2.x) {
BigInt lambda = (p2.y - p1.y).DivideMod(p2.x - p1.x, Curve.Mod);
BigInt x3 = (lambda.Power(2) - p1.x - p2.x).Mod(Curve.Mod);
if (x3 < 0) x3 = x3.Mod(Curve.Mod);
BigInt y3 = (lambda * (p1.x - x3) - p1.y).Mod(Curve.Mod);
if (y3 < 0) y3 = y3.Mod(Curve.Mod);
return new Point(x3, y3);
}
if (p1 == p2 && p1.y != 0) {
BigInt lambda = (3 * p1.x.Power(2) + Curve.A).DivideMod(2 * p1.y,
Curve.Mod);
BigInt x3 = (lambda.Power(2) - 2 * p1.x).Mod(Curve.Mod);
if (x3 < 0) x3 = x3.Mod(Curve.Mod);
BigInt y3 = (lambda * (p1.x - x3) - p1.y).Mod(Curve.Mod);
if (y3 < 0) y3 = y3.Mod(Curve.Mod);
return new Point(x3, y3);
}
throw new Exception(String.Format("Unable to add points {0} and {1}",p1, p2));
}
Point Multiplication
This algorithm implements the double-and-add technique as described in [2].
public static Point operator *(BigInt k, Point py) {
if (k <= 0) throw new Exception("Can not multiply than any number less that 1");
Boolean first = true;
Point px = null;
string kBinary = k.ToString(2);
int m = kBinary.Length;
for (int i = m-1; i >= 0; i--) {
if (kBinary[i] == '1') {
if (first) {
first = false;
px = py;
} else {
px = px + py;
}
}
py = py + py;
}
return px;
}
Time Testing
The following uses NUnit test cases to encrypt and decrypt a data file of 10 MB three times
at each key size that we tested ECC at:
[TestCase(KeySizeEnum.Size192, "datafile10m")]
[TestCase(KeySizeEnum.Size224, "datafile10m")]
[TestCase(KeySizeEnum.Size256, "datafile10m")]
[TestCase(KeySizeEnum.Size384, "datafile10m")]
[TestCase(KeySizeEnum.Size521, "datafile10m")]
[Repeat(3)]
public void TestECCEncryption(KeySizeEnum keySize, string fileName)
{
string message = OpenFile(fileName);
ParameterGenerator.GenerateTestParameters(keySize);
KeyPairs.GenerateKeyPairs();
Encoder.GenerateEncoder(message);
Decoder.GenerateDecoder();
Console.Write("ECC" + (int)keySize + "," + fileName + ",");
}
For timing, we used the System.Diagnostics.Stopwatch class included in C# wrapped in the
SetUp and TearDown methods from NUnit as follows:
private Stopwatch watch = new Stopwatch();
[SetUp]
public void Start()
{
watch.Reset();
watch.Start();
}
[TearDown]
public void Stop()
{
watch.Stop();
Console.WriteLine("Elapsed: " + watch.Elapsed.TotalSeconds+"s");
}