Key length greater than block size

In AES, if I have 192-bit key to encrypt 128-bit block size, won't it only be using the first 128-bit of my 192-bit key? So what's that extra 64-bit key used for, and how does that increase security?

• What research have you done? I was able to find this fairly easily. Commented May 22, 2018 at 19:27
• check this link i think it can solve your question crypto.stackexchange.com/questions/8121/… Commented Jun 1, 2018 at 0:17
• No, this one explains it better. This Q would be better placed on the crypto site, if it would not be closed as a duplicate (which it would). Commented Jun 14, 2018 at 9:55

The key is first put through an algorithm called a key schedule, which splits it up and expands it into a number of 128-bit round keys. These round keys are always 128 bits in length, regardless of the size of the AES key itself. Each of these round keys are fed into the end of each single round of the block cipher using the XOR operation. AES128 expands a 128-bit key into 11 round keys, AES192 expands a 192-bit key into 13 round keys, and AES256 expands a 256-bit key into 15 round keys.

The internals of the AES algorithm are described excellently in A Stick Figure Guide to AES.

• That guide is really good. Commented Sep 1, 2022 at 23:40
• @ThoriumBR Agreed. It's by far the best description of AES that I have ever come across. Commented Sep 1, 2022 at 23:40

Any given 128-bit block can only benefit from 128 bits of entropy, but that doesn't mean the other bits are wasted. By the pigeonhole principle, using AWS-192 means that there must be on average at least 2^64 keys that, if used to encrypt block A, output block B. However, decrypting a single block usually doesn't get you the whole message, and of those roughly 2^64 keys that can map A to B (or vice versa), probably only one of them works for the rest of the message.

Suppose you had plaintext P0 and corresponding ciphertext C0 (both one block long) and you wanted to mount a known-plaintext attack and extract the key. You would (on average) only need to try 2^128 candidates (note: this is, for practical purposes, impossible) to find some key that works, even though each candidate is 192 bits long, because there are probably 2^64 working keys.

However, suppose you have two pairs of blocks, P0,C0 and P1,C1, which are not equal. Now, you still only need to search (on average) 2^128 candidate keys to find one that works for P0,C0 or P1,C1... but there is probably (likelihood of about 2^64:1, assuming the cipher is as strong as we think) only a single 192-bit key that works for both.

This has huge implications for known-plaintext key-recovery attacks, of course; if you only have one block of known plaintext, you still have to try on average half of the 2^64 keys that work for that single block before finding the one that works for the rest. This is of course the same 2^191 candidates you'd need to check (on average) to guess the right 192-bit value.

Full key recovery from known plaintext is utterly impractical even at 128 bit keys, but imagine you knew the first 80 bits? Then the search for a 128-bit key requires trying only at most 2^48 candidates - practical (given some time) even on a home PC - while trying to find a key that correctly decrypts an entire message consisting of at least two distinct blocks encrypted with AES-192 would require trying up to 2^112 candidate, which is probably still functionally impossible even for nation-state attackers. That generalizes to other attacks too, such as using (theoretical) quantum computers to cut the effective entropy in half; 64 bits of effective entropy probably aren't enough, but 96 bits would be for at least a while (and 128 bits effective - from halving the entropy of an AES-256 key - would be functionally impossible to crack).