Encryption bottleneck: Lessons from performance analysis

Your computer is running slowly. Guess you have to buy a faster processor, right?

Not necessarily.

You want strong encryption. Guess you have to increase the encryption keylength, right?

Not necessarily.

Long ago in Internet time – which is to say, a more than quarter of a century ago, from 1980 through 1983 – I was an HP3000 MPE-operating-systems-internals specialist and IMAGE/3000 database-performance specialist for Hewlett-Packard (Canada) Ltd, working out of the Kirkland, Québec, office. One of the lessons we learned and had to teach our customers as performance specialists is that there are five components that can account for computer system performance:

• Access to and speed of the CPU;
• Access to and speed of main memory (RAM);
• Access to and speed of secondary memory (magnetic disk);
• Network bandwidth;
• Application design.

Whichever of these factors is slowest defines the current performance bottleneck and limits the overall system throughput. Improve the factor causing that bottleneck and you will improve performance – until it hits the next bottleneck.

For example, after I went solo in my own JINBU (Mandarin Chinese for “Progress”) Corp. consulting firm (1986-1998, RIP), I handled a major Canadian government HP3000 system in August 1989 that was up for replacement at a projected cost of C$2 million. The administrators called me to help because their batch processing had crept over the morning shift start time of 7 a.m. and the unionized employees had to be paid for waiting around until 7:30 and then paid 1.5x for working the extra half-hour at the end of their shift – an expensive half-hour indeed. They wanted to survive until the January 2000 delivery date.

That report had my favorite executive summary of my entire consulting career so far. It was a single page that said “EXECUTIVE SUMMARY” and then had the question “Does <government agency> need to replace its HP3000 computer?” After 20 blank lines I wrote the single word, centered on the page, “No.” <g>

The next page was labeled “SLIGHTLY LESS EXECUTIVE SUMMARY” and explained that the reasons the batch processing was slow had nothing to do with the speed of the CPU, which was the only improvement available from a CPU upgrade. The problem was that the product databases (1) hadn’t be repacked on the main indexes in use and (2) were missing a couple of obviously useful indexes that would convert serial searches of huge datasets into random-access searches.

One month after my report, the head of operations called me gleefully to say that they were only through the first 10 recommendations (of about 36) and were already completing the nightly batch processing by 3:30 a.m. They canceled the order and were able to keep working efficiently for another 18 months, at which time they upgraded to an even better HP3000 for less money than the original order. Cool. The Canadian federal government then gave me a contract for 12 more HP3000 performance analyses over the next year; very cool.

Now back to encryption.

Dave Whitelegg writes an interesting, thoughtful and valuable blog that I recommend to readers. Earlier this year, he posted the article “WinZip Encryption Password Security” that makes the point that it’s very nice that newer versions of WinZip include AES encryption at 128-bit, 192-bit, and 256-bit keylengths – but that it’s the keyspace of the password, not of the key, that will determine the time required for dictionary and brute-force password cracking. Nobody is going to start cracking using all 192 bits: they start with short sequences such as obvious words plucked from a dictionary or a modified dictionary that includes typical character substitution and inclusion of randomly placed special characters in password strings of increasing length.

I’ll make the argument obvious by pushing it to its absurd extreme: If someone picks a one-character password from all possible extended ASCII characters, it doesn’t matter how big the encryption key is, because there are only 256 characters in the set and 32 of them are not even usable in most password-entry fields (e.g., Null, EOT, ENQ, ACK, BELL, and so on).

So just as in analyzing system performance, we have to remember when analyzing cryptographic strength that we are studying a system, not just isolated components.

Go forth and teach your users how to create appropriately complex passwords for the value of their data in addition to choosing the right keylength of their encryption algorithms.

M. E. Kabay, PhD, CISSP-ISSMP, specializes in security and operations management consulting services and teaching. He is Chief Technical Officer of Adaptive Cyber Security Instruments, Inc. and Associate Professor of Information Assurance in the School of Business and Management at Norwich University. Visit his Web site for white papers and course materials.