Today’s world is, unfortunately, a scary place. Digital bogeymen lurk within every e-mail waiting to let loose the worms of Internet panic. Subsequently, the technology world is eager to provide a panacea for all of our ills. Sometimes the fixes work, yet most of the time they equate to plain old snake oil. Which brings us to today’s subject: secure Ethernet cards (secure cards). The word “secure” is easy to misconstrue. In this case, it means an encrypted data stream like those used on a secure Web site.
The site is not like a secure site; it is a secure Web site when the Web traffic transmitted is using encryption. Secure Web encryption also relates to encrypted mail, telnets, and virtual private networks (VPNs).
Secure cards can ease some of the encryption stress placed on the processor, but is there really that much stress? And by doing so, will you really boost the performance of your system? Good questions. Here’s what I’ve found.
Building a case for secure cards
Under normal conditions, an encrypted connection is first handled by establishing the identities of both computers. Those identities, along with a few randomly generated bits of data that vary with the type of encryption, are used as the keys to lock and unlock the data. Then, and only then, do you get around to transmitting the data.
Whenever data is sent, it first takes a detour through the processor before passing through the network. The recipient machine also puts the transmission through its processor to pull the data out before it actually does anything with the data. These extra processing steps can create a potentially taxing situation. Depending on the type of encryption and the size of the key, it can take around an extra 100 clock cycles to get the data out the door. Admittedly, a lot of this extra time is spent waiting to shuffle the data between the processor, memory, and cache. Regardless of the reason, it can add up, especially when large keys use large keys.
Why use secure cards?
By using a secure card equipped with an onboard processor loaded with security algorithms, you can put part of the onus of encryption on the card. When a secure connection is needed, the card talks to the operating system and the encrypted application via the driver. The driver identifies the type of encryption to be used and the size of the key before the secure card begins negotiating the connection. Some secure cards are capable of storing the identities of authorized clients, thus removing another step from the process.
As long as the number of clients does not exceed the secure card’s buffer, and as long as the card supports the encryption standard, the secure card can also handle encryption and decryption of data. This frees up the processor for other tasks and cuts down on the amount of data being passed across the computer’s bus, providing another level of performance increase.
Of course, actual performance improvement will vary depending upon the server load, the speed of the encryption algorithms, and the quality of the driver. Note that if the secure card is capable of handling the number of clients currently using it, driver quality will not be that important. However, once the secure card is no longer able to handle the client load, the driver becomes critical.
Size does matter
Encryption keys vary in size. The size of the key indicates the key space. A tiny, 8-bit key space has only 256 keys (28 = 256). With only 256 keys in the way, it is easy to understand how quickly someone could figure out how to crack an 8-bit encryption key and extract the data. Many people could do it with pencil and paper. A computer is much faster. This is why a 56-bit key is considered the bare minimum by today’s standards. A more reasonable expectation is a 64-bit key, which is 256 times larger than the 56-bit key. Stronger encryption standards go up to 128-bit keys, with a few approaching the 168-bit level.
While it is a rare feature, it may be worthwhile to procure a secure card that can have its software upgraded. The encryption schemas in place are fairly well tested; however, the possibility of a flaw can never be eliminated. Fortunately, there is little immediate risk of the encryption algorithms retiring anytime soon. However, having support for the greatest number of algorithms is in your best interest to account for future expansion. In the same vein, supporting the largest encryption keys possible will extend the life of the secure card. While the algorithms will be around for a while, the size of the key space will continue to increase to maintain a reasonable level of protection.
I stated that encryption is a potentially taxing function, the emphasis being on the word potentially. Under the right circumstances, it can significantly impair the performance of a server. However, those circumstances are not all that common. For it to happen, you must be in a processor-limited condition. In other words, the bottleneck to your server would be the CPU. Furthermore, the load from encryption processes would have to be a sizeable percentage of the processor load.
Performance solutions involve splitting the encryption duties between two systems, yet it is not an inconsequential task. Failure to manage the client lists can result in frozen connections or a case where the client thinks it has a valid connection but the server does not remember authorizing it. This can result in an artificial denial of service condition, as these abandoned clients keep attempting to establish a connection.
Also, to be truly effective, the secure card must be more cost-effective to upgrade than the processor. On the plus side, a secure card supporting over a thousand connections using 168-bit encryption can be found for around $100, which is well beneath the upgrade cost of a new processor.
Of course, before you buy, you will want to verify the secure card’s performance with your chosen platform. Benchmark data on secure cards is very hard to come by, even from the vendors. Part of that comes from the basic complexity of the task. To properly stress test that $100 secure card, you will need to establish over a thousand simultaneous encrypted connections. Then you have to take into account the different kinds of connections. Many people debate the validity of most Web server tests based on the amount of static and dynamic content, let alone which combination you would use to analyze a secure card of this nature.
If you need to replace a network card, the additional cost of getting a secure card vs. another high-performance, 100-Mb card is relatively negligible. This makes the secure card a worthwhile acquisition for experimentation, depending upon your specific security conditions. However, I would be very hesitant to put my faith in one of these cards to significantly boost a server’s performance.