Cryptographic Algorithms - Impact On Application Performance
Written by Atul Kahate
May 12, 2008 at 10:52 PM
The importance of security is often realized only after an application's security is breached. One of the reasons why security is not enforced is it's impact on application performance. Adding security makes my application slow is a very common excuse for not securing applications. While security features is a generic term, and can mean a number of things right from firewalls to identity management and more, in this article we will concentrate on the cryptographic implications. We will study the impact of using various kinds of cryptographic algorithms on performance.
Measuring performance of cryptography
Let us first categorize our areas of measurement into various types of functionalities. We normally need to perform some of the following cryptographic operations:
Confidentiality – Encrypt/Decrypt data to provide for confidentiality. This can be classified further into symmetric key cryptography (same key being used at both ends) and asymmetric key cryptography (public key is used at one end, and a different private key is used at the other end)
Integrity – Message digests are computed and are used to detect alterations made to the original message so as to prevent tampering.
Non-repudiation – To ensure that the original sender can prove (or cannot deny!) that she was the creator/sender of a message, it can be digitally signed.
Hence, our measurement of speeds of cryptographic operations would be restricted to these three categories. The exercise was done using NetBeans 6.0 on Windows Vista with 2 GB RAM and 110 GB hard disk.
Before we get into more hands-on experiences, let us first review the numbers that famous security expert Bruce Schneier has quoted in his classic “Applied Cryptography”:
Algorithm type
Operation
Thumb rules
Message digest
Compute message digest using SHA-1 algorithm
75,000 bytes can be digested per second
Symmetric key encryption
DES
45,000 64-bit blocks can be encrypted per second
Asymmetric key encryption
RSA
Encryption in 0.03 seconds, decryption in 0.16 seconds, Digital signature in 0.16 seconds, verification in 0.02 seconds
Now, let us try doing the measurements ourselves.
Message digest performance tests
Algorithm used
Original text
Length of original text
Size of message digest
Execution time (in milliseconds)
This is short!
14
128
13.289957
MD5
This is the text to be digested. It is quite interesting!
57
128
13.008148
This is a very long string. Let us see if it can cause significant delays in computing a message digests!
105
128
12.155805
SHA-1
This is short!
14
160
13.813069
This is the text to be digested. It is quite interesting!
57
160
13.347436
This is a very long string. Let us see if it can cause significant delays in computing a message digests!
105
160
12.779836
SHA-512
This is short!
14
512
13.994446
This is the text to be digested. It is quite interesting!
57
512
13.229545
This is a very long string. Let us see if it can cause significant delays in computing a message digests!
105
512
13.967278
Summary of observations
Regardless of the message digest size (and therefore the perceived complexity of the algorithm) the amount of time it takes for computing message digests remains more or less the same.
The size of the input text does not make any difference.
Symmetric key encryption and decryption performance tests
Note: This test includes run-time symmetric key generation, encryption of plain text into cipher text and decryption of cipher text back into plain text.
Algorithm used
Original text
Length of original text
Key size
Execution time (in milliseconds)
Blowfish
Small plain text for encryption!
32
…
40.0159098
Bigger plain text for encryption! This should increase the time taken for encryption!
85
…
41.2025411
Much bigger plain text for encryption! This should significantly increase the time taken for encryption! Or would it? I have my own doubts looking at the past results. Well, let us try ourselves and see!
203
128
40.0815467
DES-3
Small plain text for encryption!
32
160
41.5861513
Bigger plain text for encryption! This should increase the time taken for encryption!
85
160
40.5570750
Much bigger plain text for encryption! This should significantly increase the time taken for encryption! Or would it? I have my own doubts looking at the past results. Well, let us try ourselves and see!
203
160
41.3329487
AES
Small plain text for encryption!
32
256
42.7647718
Bigger plain text for encryption! This should increase the time taken for encryption!
85
160
42.3849121
Much bigger plain text for encryption! This should significantly increase the time taken for encryption! Or would it? I have my own doubts looking at the past results. Well, let us try ourselves and see!
203
160
42.4304486
Summary of observations
Regardless of the algorithm (and therefore the perceived complexity of the algorithm) the amount of time it takes for encryption and decryption remains more or less the same.
The size of the input text does not make any difference.
Asymmetric key encryption and decryption performance tests
Note: This test includes run-time symmetric key generation, encryption of plain text into cipher text and decryption of cipher text back into plain text.
Algorithm used
Original text
Length of original text
Execution time (in milliseconds)
RSA
Small plain text for encryption!
32
86.1157563
Bigger plain text for encryption! This should increase the time taken for encryption!
85
88.0750277
Much bigger plain text for encryption! This should significantly increase the time taken for encryption! Well ...
104
93.0025534
Summary of observations
Time taken is certainly more than what symmetric key encryption algorithms require.
The size of the input text does make a difference. The more the plain text, the higher is the time taken for encryption and decryption.
As we can see, message digest algorithms are the fastest. No encryption is involved here. Symmetric key encryption algorithms are much faster than asymmetric key algorithms. Asymmetric key algorithms perform worse as the size of the plain text increases.
About the author : Atul Kahate is Head – Technology Practice, Oracle Financial Services Consulting (formerly i-flex solutions limited). He has authored 16 books on Information Technology, 2 on cricket, and over 1500 articles on both of these in various newspapers/journals. His site can be visited at www.atulkahate.com and he can be reached via email at .
Copyright 2004 to 2008 Rightrix Solutions. All rights reserved. All product names are trademarks of their respective companies. Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. Rightrix Solutions and IndicThreads.com are independent of Sun Microsystems, Inc.
Views expressed at IndicThreads.com reflect the views of the authors alone, and do not necessarily reflect those of IndicThreads.com. IndicThreads.com and it's authors are not responsible for reader comments and opinions.
Home | 
The importance of security is often realized only after an application's security is breached. One of the reasons why security is not enforced is it's impact on application performance. Adding security makes my application slow is a very common excuse for not securing applications. While security features is a generic term, and can mean a number of things right from firewalls to identity management and more, in this article we will concentrate on the cryptographic implications. We will study the impact of using various kinds of cryptographic algorithms on performance.
