ABSTRACT
The unprecedented growing demands on security and privacy protection ushered the proliferation of cryptographic tools. This article presents a study on the performance comparison of cryptographic Application Program Interfaces (APIs) that are implemented for the Java and the .Net frameworks. The results of the study clearly indicate the superiority of a set of commercial cryptographic APIs over its open-source counterpart.
INTRODUCTION
The unprecedented growing demands on security and privacy protection ushered the proliferation of cryptographic tools. The concerns on the vulnerability of our information technology (IT) infrastructure and our constantly increasing dependence on IT have prompted government agencies to re-examine the consequences of an act of a major cyberspace aggression (CitationThe White House, 2000). One of the most important components of such undertaking is that aspect which involves data protection through effective and secure encryption. Although there is much discussion on the efficacy of several cryptographic techniques and algorithms in published literature, there is little information about performance comparison among each other on actual applications. Such applications may include, but are limited to, the ANSI X9 Standards (CitationMeneges, Oorschot, & Vanstone, 1996) used by the financial services industry, the Secure Socket Layer (SSL) protocol (CitationThomas, 2000) on the Web, and the Secure Multipurpose Internet Mail Extension (S/MIME) (CitationRhee, 2003) for Web-based email systems.
This article presents a study on the performance comparison of cryptographic Application Program Interfaces (APIs) that are implemented for the Java and .Net frameworks. The comparison is based on the four encryption algorithms and the four message digest algorithm implementations in the .Net and the Java frameworks. The four encryption algorithms are:
Data Encryption Standard (DES), | |||||
Rivest's Cipher 2 (RC2), | |||||
Rijndael (the basis of Advanced Encryption Standard, AES) , and | |||||
Triple DES. | |||||
The four message digest algorithms are:
Message Digest 5 (MD5), | |||||
Secure Hash Algorithm (SHA1), | |||||
Secure Hash Algorithm 256 (SHA256), and | |||||
Secure Hash Algorithm 512 (SHA512). | |||||
The fact that the above cryptographic algorithms are available on both frameworks is the main reason that led us to limit our study to that set.
ALGORITHMS AND IMPLEMENTATIONS
Encryption Algorithms
The DES Algorithm
This algorithm, first introduced in 1974 by IBM researcher Horst Feistel, works as block cipher meaning it encrypts 64 message bits, or 16 hexadecimal numbers and encrypt them as a single unit. DES also uses a key which ostensibly consists of 64 bits; however, only 56 are actually used. This algorithm consists of 16 rounds of cipher processing with an initial and final permutation. The first step in the DES algorithm is to create 16 subkeys, each of which is 48 bits long. After that, the 64-bit key goes through a 56-bit permutation. The key is then split into two 32-bit halves, which are processed alternately. Each 32-block is expanded to 48 bits. It is then combined with a subkey. There are 16 48-bit subkeys for each round. After a nonlinear transformation, the 32 bits are rearranged.
The RC2 Algorithm
The RC2 algorithm is a variable key-size block cipher designed by Ronald Rivest. It is reported to be two to three times faster than the DES algorithm. RC2 is a 64-bit block cipher with a variable key size. Its 18 rounds are arranged as a Feistel network, with 16 rounds of mixing interspersed by 2 rounds of mashing.
The Rijndael Algorithm
Developed by two cryptographers from Belgium, Dr. Joan Daemen and Dr. Vincent Rijmen, the Rijndael Algorithm (FIPS-197, 2001) is another block cipher algorithm. This encryption technique is a product of the National Institute of Standards and Technology (NIST) Advanced Encryption Standard (CitationNIST, 1997) program, which solicited for a new standard that will replace the controversial and somewhat outdated standard, the Data Encryption Standard (DES) (CitationNBS, 1976). Rijndael supports a larger range of block and key sizes; it can be specified with key and block sizes in any multiple of 32 bits, with a minimum of 128 bits and a maximum of 256 bits.
Triple DES Algorithm
Triple DES was designed by Walter Tuchman, a member of IBM's DES development team. He proposed using the widely accepted Triple DES implementation using two keys. The first key is used to encrypt the message, while the second key is used to decrypt the encrypted message. Thus, the message is twice-scrambled then encrypted again with the first key to yield the final cipher text.
Hash Functions
MD5
One of the two most popular nonkeyed message digest programs is Message Digest 5 (MD5). MD5 makes a 128-bit digest and is commonly used to check the integrity of files.
SHA1
The other most popular nonkeyed message digest program is the Secure Hash Algorithm-1 (SHA1). Produced by the National Institute of Standards and Technology (NIST) and NSA, SHA1 makes a 160-bit digest; this means that a birthday attack, a class of brute force attack based on the birthday paradox (CitationSchneier, 1996), can be mounted using 80 bits. So far, SHA1 has been immune to cryptanalytic attacks that are successfully mounted against MD5 (CitationMel and Baker, 2001).
SHA256/SHA512
NIST also published additional hash functions found in the SHA family. Each named after their digest lengths in bits SHA256 and SHA512.
Implementation Details
In the .Net Framework implementations, the Visual Studio development environment was used with the System.Security.Cryptography namespace (MSDN2, 2006). The .Net Framework 2.0 is a development and execution environment that provides a seamless integration of various programming languages in Windows (Citation.Net, 2007). C# was chosen as the .Net framework implementation language. The rationale behind this choice is that C# has the closest affinity to Java in terms of being 100% object-oriented, unavailability of pointers, provision of multiple-inheritance, utilization of automatic garbage collection, and the compilation to a portable intermediate language, Microsoft Intermediate Language (MSIL) that runs on a multiplatform firmware, Common Language Runtime (CLR). The Java equivalent of MSIL and CLR are byte code and Java Virtual Machine (JVM).
In the Java implementations, the NetBeans development environment coupled with Java Cryptography Extension (JCE) for the Java 2 SDK (Java2, 2006) and the Java Cryptography Application Program Interface (API) Cryptix (CitationCryptix, 2006) was used.
For more details on cryptography implementations in Java, the reader is referred to Knudsen, 1998. Interesting cryptography implementation projects may also be located in (ECE575, 2002).
The empirical study was conducted on three distinct operating systems on the same computer: Windows XP, Fedora Linux, and Sun Solaris.
The encryption and hash digest source codes for both Java and C# .Net are shown in the Appendix.
HYPOTHESES
The experiments are to be conducted to test the following hypotheses:
Cryptographic APIs released for commercial use (such as that with the .Net Framework) provide better performance compared to their open source counterparts (such as that used in the Java Framework: the Cryptix APIs). | |||||
The DES encryption algorithm, due to its simplicity, would outperform the other encryption algorithms. | |||||
The Rijndael (also known as AES) encryption algorithm provides a consistent performance in a wide range of computing environments. | |||||
The file input/output process that is inherent in every operating system has an impact on the performance of cryptographic algorithm implementations. | |||||
COMPUTING PLATFORMS
The hardware test bed consists of a Gateway notebook computer with a 3.0 GHz Intel® Pentium 4 processor, 512 MB RAM, and running as a triple-boot system consisting of Microsoft Windows XP SP2 Fedora Linux 5.0, and Sun Solaris 10.
TEST METHODOLOGY
The test methodology is divided into four schemes.
A scheme that enables performance comparisons of the encryption in the .Net and the Java frameworks on the Windows platform. | |||||
Similarly on the Windows platform, a scheme that enables performance comparison of message digest algorithm implementations in the .Net and the Java frameworks on the Windows platform. | |||||
A scheme in which the Java implementations were ported to the Linux platform. | |||||
A scheme that collected baseline performance data on file input/output operations of C# .Net on Windows XP and of Java on Windows XP, Fedora Linux, and Sun Solaris. | |||||
The experiments on the same data sets were executed and the results are presented in what follows.
TABLE 1 .NET encryption speed in msec
TABLE 2 JAVA encryption speed in msec
FIGURE 1 DES Encryption
FIGURE 2 RC2 Encryption
FIGURE 3 Rijndael Encryption
FIGURE 4 TripleDES Encryption
PERFORMANCE ANALYSES
In scheme I, the comparison is made between the .Net and the Java encryption algorithms APIs, and the results are shown in and . The corresponding visualizations of these data are depicted using 3-dimensional bar charts and are shown in through . In those figures, one can see the remarkable difference in speed between the .NET and the Java frameworks. The encryption speed of the .Net Framework APIs are almost twice as the speed of those in the Java APIs. There is, however, an exception. In the 128-bit implementation of the Rijndael algorithm, it shows that the two implementations are considerably similar in speed. In CitationMel and Baker, 2001, it has been conjectured that Rijndael's combination of security, performance efficiency, ease of implementation, and flexibility make it consistently a very good performer in both hardware and software across a wide range of computing environments. This may be the underlying factor for which the speeds of our encryption implementation are very similar.
TABLE 3 .NET hashing speed in msec
TABLE 4 JAVA hashing speed in msec
FIGURE 5 MD5 Message Digest
FIGURE 6 SHA1 Message Digest
FIGURE 7 SHA256 Message Digest
FIGURE 8 SHA512 Message Digest
In scheme II, the comparison is made between .Net and Java message (hash) digest APIs. The raw numerical data are shown in and and the corresponding data visualizations are shown in through . As the figures would indicate, the .Net framework message digest APIs outperform once again the Java message digest APIs with the exception of the MD5 algorithm. In the MD5 algorithm, there is no clear perceptible evidence of which message digest API is better.
A performance comparison of encryption and message digest algorithm implementations on both the .Net and Java frameworks are made and the results are depicted in –. The results confirmed our initial hypothesis that DES, due to its relative simplicity, would outperform the other encryption algorithms. However, one can argue that DES's performance advantage should not outweigh the stronger encryption that the others provide. As a matter of fact, AES has supplanted DES as the preferred algorithm for most government and commercial encryption requirements. The results also indicate and validate our hypotheses that the MD5 implementations in both frameworks would outperform the other hash algorithm implementations.
FIGURE 9 Encryption .NET
FIGURE 10 Encryption JAVA
FIGURE 11 Hashing .NET
FIGURE 12 Hashing JAVA
The next logical question is, “Will the encryption and hash digest algorithm API implementations in the Java framework fare better in the Linux platform?” A third scheme was devised with the goal to answer this question. The Java implementations were ported in a Linux platform and the experimental runs were made on the same data sets. The results were gathered and are shown in and . Multiple comparisons between the Linux and the Windows experiments are displayed using visual charts in –. The following observations are quite evident: the Java encryption APIs perform better in the Windows platform than in the Linux platform, the comparison between the Java hash digest API performances in the Windows and Linux platforms is too close to draw a definite conclusion, and that the encryption and the hash digest algorithm implementations on the Linux platform perform as hypothesized.
Baseline Results
Scheme IV is dedicated to gathering baseline timing data for file input/output performance of the three operating systems that were used in the study. The results of the experiments are summarized in the following tables.
TABLE 5 Linux-JAVA encryption speed in msec
TABLE 6 Linux-JAVA hashing speed in msec
FIGURE 13 Linux Encryption DES JAVA
FIGURE 14 Linux Encryption RC2 JAVA
FIGURE 15 Linux Encryption Rijndael JAVA
FIGURE 16 Linux Encryption TripleDES JAVA
depicts the comparison of running Java read and write operations on multiple file sizes on three different operating systems. It can easily be gleaned from the results that Java on Windows is the worst performer. Further investigation led us to examine the performance of the development languages when performing file input/output (IO) operations on their native operating systems, that is, C# .Net on Windows XP and Java on Solaris. The results of the experiment are shown in . Clearly, the results indicate that the development languages perform best in their respective native operating systems when doing file system operations.
For the final analysis, we normalized the results by taking out the overhead that is attributed to the system file IO operations. The results, as shown in and , further support the advantage of the .Net framework over the Java framework in both encryption and hash digest implementations.
FIGURE 17 Linux Hashing MD5 JAVA
FIGURE 18 Linux Hashing SHA1 JAVA
FIGURE 19 Linux Hashing SHA256 JAVA
FIGURE 20 Linux Hashing SHA512 JAVA
TABLE 7 File I/O timing of Java in msec
TABLE 8 File I/O timing on native OS in msec
A Deeper Investigation
To precisely determine the impact of memory management on the performance of the cryptographic implementations, we used two profilers: the Netbeans Java Profiler 5.5 (CitationNetbeans, 2007) and the Windows Performance Monitor (MSDN2, 2007). The profiling experiments revealed the following results:
The overhead attributed to memory garbage collection, which is 0.3% of the total time, is negligible. | |||||
The committed memory utilization averages 41% for the .Net implementations and 45% for the Java implementations. These results, together with the garbage collection data, support the notion that memory size does not have a major impact on the performance of the cryptographic implementations. | |||||
TABLE 9 TripleDES encryption less file IO overhead in msec
REMARKS AND CONCLUSIONS
Based on the data that were gathered in the above experiments, the following observations are made:
The DES algorithm, due to its relative simplicity, outperforms the other encryption algorithm implementations in the .Net framework. However, this does not appear to be the case in the Java framework in which the Rijndael implementation came out on top. A closer look would reveal the stability of the Rijndael algorithm across multiple frameworks and operating systems. | |||||
In the scheme where the performances of the encryption and hash digest APIs on the .Net and Java frameworks were measured, the .Net implementations, in most instances, clearly outperform their counterparts in the Java framework. An exception is in the Rijndael encryption implementation, which supports the claim of the being a consistent performer in a wide range of computing environments (CitationMel and Baker, 2001). The results impart an insight into the merits of using commercially developed APIs rather than the open source variety. | |||||
The most interesting result is the relatively poor performances of most of the Java encryption APIs on the Linux platform as compared to those on the Windows platform. The exception is on the Rijndael implementations where the advantage of the Windows system is not well pronounced. This shortcoming can not be attributed to a deficiency in Java's file system input/output handling in Linux. It is quite evident, as shown in , that Java's file system input/output operations perform best on the Linux platform. It is likely that the relatively poor performance data are a result of the nonoptimal implementations of the Java encryption APIs.
TABLE 10 SHA512 hashing less file IO overhead in msec | |||||
In choosing the encryption algorithm API or implementation to use, developers should be guided by the following factors: performance, cryptographic strength, regulatory compliance requirements, laws and ethics. Furthermore, it should be noted that cryptographic performance enhancements using software and hardware such as those described in (CitationMicrosoft Technet, 2003), (CitationRSA-EMC, 2007), and (CitationTan, Lin, Yin, & Li, 2004) are available. | |||||
Future directions for the expansion of this work include the following:
the utilization of dual core and multicore CPU systems that are optimized for multithreading operations, | |||||
the utilization of computer systems that are enabled for 64-bit addressing, and | |||||
the investigation of hardware enhanced cryptographic algorithm implementations. | |||||
ACKNOWLEDGEMENT
This article is based on a project supported by the National Science Foundation under grant DUE-0125635. Opinions expressed are those of the author and not necessarily of the Foundation.
REFERENCES
- ANSI X9.17 (Revised). 1985 . American national standard for financial institution key management. , Washington, DC : American Bankers Association .
- Cryptix. (2006). Java cryptography API: http://www.cryptix.org
- ECE575. (2002). Data security and cryptography. http://islab.oregonstate.edu/koc/ece575/02Project
- ElGamal , T. 1985 . A public-key cryptosystem and signature scheme based on discrete logarithms . IEEE Transactions on Information Theory , 31 ( 4 ) : 469 – 472 .
- FIPS-197. (2001). Federal Information Processing Standards Publication 197. http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
- Java 2. (2006). Java Cryptography Extension (JCE) for the Java 2 SDK, v1.4. http://java.sun.com/products/jce/index-14.html
- Knudsen , J. 1998 . Java cryptography. , Sebastopol, CA : O'Reilly & Associates Pub. .
- Mel , H. X. and Baker , D. 2001 . Cryptography decrypted. , NJ : Addison-Wesley Pearson .
- Meneges , A. , Oorschot , P. and Vanstone , S. 1996 . Handbook of applied cryptography. , Boca Raton, FL : CRC Press .
- Microsoft Technet. (2003). Performance considerations. http://technet2.microsoft.com/windowsserver/en/library/9d47b6a2-3216-45fc-9bb8-41a7d89e42d11033.mspx?mfr=true
- MSDN2. (2006). Microsoft Developer Network 2. System.security. cryptography namespace http://msdn2.microsoft.com/en-us/library/system.security.cryptography.aspx
- MSDN2. (2007). Microsoft Developer Network 2. Performance monitoring. http://msdn2.microsoft.com/en-us/library/aa830465.aspx
- National Bureau of Standards. 1976 . “ NBS FIPS PUB 46. ” . In Data encryption standard. , Washington, DC : U.S. Department of Commerce .
- National Institute of Standards and Technology. 1997 . NIST announcing development of a federal information standard for Advanced Encryption Standard (AES) . Federal Register , 62 ( 1 ) : 93 – 94 .
- .Net (2007). What is the .Net framework? http://www.microsoft.com/net
- Netbeans. (2007). Netbeans Java Profiler 5.5. http://www.profiler.org
- Rabin , M. O. 1979 . Digital signatures and public-key functions as intractable as factorization. , Boston, MA : MIT Laboratory of Computer Science, technical report, MIT/LCS/TR-212 .
- Rhee , M. 2003 . Internet Security. , New York : John Wiley & Sons .
- Rivest , R. , Shamir , A and Adleman , L. 1978 . A method for obtaining digital signatures and public-key cryptosystems . Communications of the ACM , 21 ( 2 ) : 120 – 126 .
- RSA-EMC. RSA BSAFE. (2007). http://www.rsa.com/node.aspx?id=1204
- Savard, J. (2001). TwoFish. http://home.ecn.ab.ca/∼jsavard/crypto/co040402.htm
- Schneier , B. 1996 . Applied Cryptography, , 2nd Ed. , New York : John Wiley & Sons .
- Schneier, B., Kelsey, J., Whiting, D., Wagner, D., Hall, C., & Ferguson, N. (1998). Twofish: A 128-Bit Block Cipher, White Paper. http://www.counterpane.com/twofish.html
- Schneier , B , Kelsey , J. , Whiting , D. , Wagner , D. , Hall , C. and Ferguson , N. 2003 . The Twofish encryption algorithm: A 128-bit Block Cipher. , New York : John Wiley & Sons .
- Tan , Z. , Lin , C. , Yin , H. and Li , B. 2004 . Optimization and benchmark of cryptographic algorithms on network processors . IEEE Micro , 24 ( 5 ) : 55 – 69 .
- The White House. (2000). National plan for information systems protection: an invitation to dialogue: the President of the United States.
- Thomas , S. 2000 . SSL and TLS Essentials. , New York : John Wiley & Sons .
APPENDIX
Code Listing 1: Java Encryption
Code Listing 2: Java Hash Digest
Code Listing 3: C# .Net Encryption
Code Listing 4: C# Hash Digest
