Accelerating Encryption: AES-NI
If you’re an average desktop user, encryption probably isn’t very important to you today. After all, password-protecting everything just creates one extra layer of complexity when you want to actually use your machine, right? But for those with something to hide (and I think that includes all of us to some degree, thank you very much Eric Schmidt), there’s value in being able to protect that information.
All of Intel’s 32nm Westmere-based processors, starting with the dual-core Clarkdale desktop CPUs, include six new SIMD instructions that Intel calls AES-NI (Advanced Encryption Standard New Instructions), which are designed to help consolidate the mathematical operations used in the block cipher algorithm. In conjunction with applications optimized for AES-NI, the new instructions help maintain the security of AES by protecting against side-channel attacks, while alleviating the performance overhead of encrypting and decrypting in software.
Intel sees five different areas where its AES instructions apply: whole disk encryption (via apps like BitLocker, PGP, and TruCrypt), file storage encryption (7-Zip and WinZip are two favorites), conditional access of HD content (pay-to-play; yuck), Internet security, and VoIP communications. We have coverage upcoming putting AES-NI to the test with whole disk encryption, but wanted to at least run the new instructions through their paces in file storage encryption—something we all use in one form or another.
Our first round of tests pit the dual-core Core i5-661 against a number of quad-core models, along with Intel’s Core 2 Duo E8500, in the 9.10 beta of 7-Zip, which is optimized for AES-NI. Surprisingly, the Core 2 Duo actually finished our 334MB Ultra compression routine in less time than the Clarkdale chip.
Of course, we didn’t really have any reference point to compare against, so it was hard to say whether the performance delta was caused by the Core 2 architecture or some shortcoming inherent to Westmere. We nevertheless approached Intel with our findings, and the company let us know that 7-Zip’s compress/decompress algorithm operates in such a way as to cover up any benefit that’d otherwise be realized by AES-NI.
Such a "heavy" algorithm doesn’t help us much here, so we swapped to WinZip 14. Although we recently removed WinZip from our benchmark suite due to its single-threaded nature (and thus, generally slower performance than apps like WinRAR), this is another title optimized for AES-NI.
|WinZip 14||Processor Family||Compress 334MB||Decompress 334MB|
|256-bit AES||Clarkdale (i5-661)||2:17||:09|
|No Encryption||Clarkdale (i5-661)||2:12||:09|
Without the use of encryption, both our Lynnfield- and Clarkdale- CPUs are on even footing and we’re able to assess each CPU’s base performance in WinZip 14. The Core i5-750 is clearly faster in our compression test, finishing 20 seconds before the Core i5-661. However, Turbo Boost kicks in on the decompression, and the Clarkdale chip finishes the task a second quicker.
Enabling 256-bit AES tells the story we’re looking for, though. The gap in compression narrows to 16 seconds. And while the Lynnfield chip, which lacks AES-NI, incurs a six second penalty attributable to encryption, the Clarkdale processor suffers no such slow-down.
With all of that said, it's easy to fire up SiSoftware's Sandra 2010, run the Cryptography test, and witness the massive jump in iAES bandwidth attributable to Intel's new instructions. As you can see, the NSA's SHA-2 hash functions aren't accelerated, and consequently don't enjoy the speed-up seen by AES.
At least for now, the benefits of AES-NI are subtle at best. But, as is the case with any hardware capability reliant on software support, this will likely become a feature that has more of an impact as time goes on—and especially as Intel prepares to launch its Nehalem-EX processors in a couple of months. The tenets of security and encryption are most deeply rooted in the enterprise space, after all.