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"); }