Section 4.6. Performance Considerations
|
4.6. Performance ConsiderationsSSL has a reputation for being slow. This reputation originated in its early days when it was slow compared to the processing power of computers. Things have improved. Unless you are in charge of a very large web installation, I doubt you will experience performance problems with SSL. 4.6.1. OpenSSL Benchmark ScriptSince OpenSSL comes with a benchmark script, we do not have to guess how fast the cryptographic functions SSL requires are. The script will run a series of computing-intensive tests and display the results. Execute the script via the following: $ openssl speed The following results were obtained from running the script on a machine with two 2.8 GHz Pentium 4 Xeon processors. The benchmark uses only one processor for its measurements. In real-life situations, both processors will be used; therefore, the processing capacity on a dual server will be twice as large. The following are the benchmark results of one-way and symmetrical algorithms: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes md2 1841.78k 3965.80k 5464.83k 5947.39k 6223.19k md4 17326.58k 55490.11k 138188.97k 211403.09k 263528.45k md5 12795.17k 41788.59k 117776.81k 234883.07k 332759.04k hmac(md5) 8847.31k 32256.23k 101450.50k 217330.69k 320913.41k sha1 9529.72k 29872.66k 75258.54k 117943.64k 141710.68k rmd160 10551.10k 31148.82k 62616.23k 116250.38k 101944.89k rc4 90858.18k 102016.45k 104585.22k 105199.27k 105250.82k des cbc 45279.25k 47156.76k 47537.41k 47827.29k 47950.51k des ede3 17932.17k 18639.27k 18866.43k 18930.35k 18945.37k rc2 cbc 11813.34k 12087.81k 12000.34k 12156.25k 12113.24k blowfish cbc 80290.79k 83618.41k 84170.92k 84815.87k 84093.61k cast cbc 30767.63k 32477.40k 32840.53k 32925.35k 32863.57k aes-128 cbc 51152.56k 52996.52k 54039.55k 54286.68k 53947.05k aes-192 cbc 45540.74k 46613.01k 47561.56k 47818.41k 47396.18k aes-256 cbc 40427.22k 41204.46k 42097.83k 42277.21k 42125.99k Looking at the first column of results for RC4 (a widely used algorithm today), you can see that it offers a processing speed of 90 MBps, and that is using one processor. This is so fast that it is unlikely to create a processing bottleneck. The benchmark results obtained for asymmetrical algorithms were: sign verify sign/s verify/s rsa 512 bits 0.0008s 0.0001s 1187.4 13406.5 rsa 1024 bits 0.0041s 0.0002s 242.0 4584.5 rsa 2048 bits 0.0250s 0.0007s 40.0 1362.2 rsa 4096 bits 0.1705s 0.0026s 5.9 379.0 sign verify sign/s verify/s dsa 512 bits 0.0007s 0.0009s 1372.6 1134.0 dsa 1024 bits 0.0021s 0.0026s 473.9 389.9 dsa 2048 bits 0.0071s 0.0087s 141.4 114.4 These benchmarks are slightly different. Since asymmetric encryption is not used for data transport but instead is used only during the initial handshake for authentication validation, the results show how many signing operations can be completed in a second. Assuming 1,024-bit RSA keys are used, the processor we benchmarked is capable of completing 242 signing operations per second. Indeed, this seems much slower than our symmetrical encryption tests. Asymmetrical encryption methods are used at the beginning of each SSL session. The results above show that the processor tested above, when 1,024-bit RSA keys are used, is limited to accepting 242 new connections every second. A large number of sites have nowhere near this number of new connections in a second but this number is not out of the reach of busier e-commerce operations. Certain technological advances work to our advantage. The HTTP 1.1 Keep-Alive feature allows a client to keep a connection with the server open and reuse it across several requests. If this feature is enabled on the server, it will help reduce the impact of SSL since only one signing operation is required per connection. But the most important performance enhancement feature is the one built into SSLv3: session caching. When an SSLv3 connection is intially established, a session is created and given a unique session ID. The client can disconnect from the server, but when it comes to the server the next time, the client can use the session ID to reestablish the session without having to perform the expensive cryptographic operation. The ability to resume sessions has enormous impact on the performance of a web server. Using the openssl tool, you can check that your web server performs as expected: $ openssl s_client -connect www.thawte.com:443 -state -reconnect It will connect to the server five times, reusing the session ID created the first time. A line in the output such as this one will confirm the session ID was reused: Reused, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA More information about the performance impact of SSL and various approaches to increasing processing speeds can be found in the following resources:
4.6.2. Hardware AccelerationCryptographic accelerators are devices designed to perform cryptographic operations quickly with the purpose of allowing the processor to do something more useful. In the past, these devices were the only feasible approach to support wide-scale SSL deployment. Increased processing power of modern processors and their low cost have made cryptographic accelerators lose some of their appeal. An interesting thing about cryptographic accelerators is that they generate server private keys and store them; since all operations are done in hardware, they never leave the device. Nor can they leave the device, resulting in enhanced private-key security. |
|
