Isn't AES-NI useless because now the key length need to be longer?

Question

AES-NI speeds up both encryption and decryption. The encryption is as secure as the time needed to brute force the decryption. Doesn't it mean that the application developers will just need to increase key length until the time taken is almost the same as without AES-NI?

Answer 1

You might gain some perspective from reading up on specialized AES search hardware, like these two systems:

• COPACOBANA
• Its successor RIVYERA

If you go to the second link and expand the "Cryptanalysis Performance" section, they give a performance comparison between their custom AES machine and other platforms. But the short version is that their custom hardware is 3-4 orders of magnitude faster at searching AES keys as Intel processors are.

And yet the page cautions you:

Please keep in mind that AES has a too large key space for exhaustive search attacks against correctly implemented encryptions with computer-generated keys - no matter if cutting-edge FPGA hardware is used. [...]

They benchmark their machine at 119 billion keys/second, so we can easily calculate how long it would take them to search half the AES-128 keyspace at that speed: $2^{127}\div 1.19 \times 10^{11} = 1.43\times 10^{27}$ seconds, which is about $4.5 \times 10^{19}$ years. Those numbers are so inconceivably large that the speed improvements from AES-NI make the proverbial "drop in a bucket" look enormous.

Note therefore that the application they highlight for their machine is cracking encryptions where the AES key is not chosen randomly with equal likelihood out of the whole keyspace, for example AES keys derived from human-chosen passwords:

[...] But, human-generated passwords are still at risk, if the attacker has sufficient processing resources available and below figures may provide an approximate guide for selecting a minimum length and complexity of passwords.

Answer 2

No, AES-NI provides a hardware implementation of AES. Before AES-NI, anyone could have purchased a specialized hardware encryption device that ran AES in hardware. So having AES-NI doesn't really change anything. When key sizes are chosen, they must take into account that specialized hardware could be developed. So, the key sizes we use already take this into account.

Answer 3

The key lengths (128-bits and up) are already long enough that a several orders of magnitude speed-up still makes a brute-force attack unfeasible.

There is even a physical argument to be made against the possibility of brute-forcing 128-bit encrypton.

Answer 4

AES uses 3 different key sizes. Currently it is already the case that you should use AES-192 or rather AES-256 if you're not comfortable with AES-128, for instance if you expect quantum computing to take off.

AES-256 is still considered very secure and will probably remain so unless cryptoanalytic results against the algorithm are discovered. AES is not provably secure after all.

I don't see specialized hardware (voted up the answer by mikeazo) or AES-NI make a dent in the security of AES-256, when it is used as block cipher in an otherwise cryptographically secure scheme.

Answer 5

AES-NI accelerates AES rounds and isn't specifically tied to the notion of 128, 192, or 256 key lengths in common usage.

AES round keys are all 128-bit even in the 192 and 256 bit variants of AES. AES-NI would still be relevant even if a hypothetical AES-512 variant were defined with a new key schedule and more rounds.

Answer 6

One has to consider the whole system with an understanding of the effort required to achieve a break. When seen this way, breaking AES, even with the fastest attacks, proven or conjectured, would still require a vast amount of resources and processing power.

I don't doubt that a (more) serious break may someday be found, and that at some future time, breakthroughs in technology and mathematics will make this more likely, but for the time being, I think it is a hypothetical only, and something that could be easily remedied by strengthening the key schedule, and increasing the key size and the number of transformation rounds.

There are far better ways to attack the system; leakage of state information, low-entropy sources used in key generation, weaknesses in big-number based asymmetric cryptography, poorly designed and constructed applications, flaws in cryptographic libraries, even bribery or coercion.

The AES-NI api certainly does add a large speed up, (my own implementation runs a multi-threaded CTR mode at close to 9GB per second on my desktop pc), and this is a very large increase in performance, but not enough I think to make a difference, especially considering that there are many more cost effective ways to acheive the objective.

Consider also, the aeskeygenassist api make timing attacks more difficult, and these are some of the most serious attacks against the cipher to date.

Answer 7

AES-NI makes no difference to an attack, because no meaningful attack can be based on using AES-NI in the first place.

Even for DES, a meaningful brute-force attack required specialized hardware that could attempt many more keys in parallel than any reasonable configuration using AES-NI could even approach.

The (dramatically) larger key space of AES means the same is required for it, but to an even greater degree. With AES-NI, you need to support an entire CPU just to get encryption/decryption.

Also note that a system similar to AES-NI isn't necessarily a huge help to an attacker anyway. When you're making normal use of cryptography, you do key setup fairly rarely, then make use of the key for a long time.

For an attacker, however, that's not the case. The attacker only needs to attempt to decrypt a fairly small amount of data with each key (often only a single block). For the attacker, accelerating encryption itself makes relatively little difference. For an attacker, the bottleneck is much more likely to be key setup, so accelerating key setup is what he really needs/cares about.

But in the end, the first point is the one that really matters: AES-NI simply isn't a useful tool for an attacker so its existence makes no meaningful difference to security.