Are the AES legal key sizes really the limit?

Question

The AesCryptoServiceProvider.LegalKeySizes field shows you the allowed sizes in bits.

However what I don't understand is if those are true, how am I able to successfully utilise a 2048 bit key length (256 Bytes)?

I suppose my real question is, does my key get produced to the size requested (larger than max 32 Byte), but then only the first 32 Bytes (256 bits) are actually taken in the encryption/decryption process, rendering the larger key size a waste of space?

I don't know if there is a way of actually telling from what's exposed in the API...

Any thoughts? Maybe I'm looking at this in the wrong way?

Nonscheduled

(new AesCryptoServiceProvider()).Key = new byte[256]; --> "CryptographicException: The specified key is not a valid size for this algorithm." -- Can you show the code you're using with a 256 byte key? – Clothilde

I've written a direct answer but I do agree with Blorgbeard on this, I don't see how AesCryptoServiceProvider can be used with any key sizes other than the "legal" key sizes. That said, the Mickeysoft docs are - again - vague enough to not specify any errors that may arise. – Dagger

If you set key size to 256 first, then generate a key, the API produces a 256 Byte key with no errors, and allows you to use it in the correct way with no errors. I wrote a whole functional class library that uses a 256Byte key size for AES and hybridised RSA/AES to see if it would work when writing programs on more platforms. And it does... only explanation 8s that either the legal keys are wrong or the majority of the key isnt being used. Im inclined to believe the latter. – Nonscheduled

Answer 1

AES can be used for 3 key sizes: 128, 192 and 256 bit keys. Basically if you are able to use larger keys than 256 bit, then the library is "lying to you" i.e. some bits of the larger key are discarded or compressed somehow. For instance PHP mcrypt simply cuts the size of the key down to the largest possible size.

Larger key "seeds" are rather common in the world of cryptography. For instance Diffie-Hellman - a key agreement algorithm - usually generates a secret larger than the key size required. So the question of extracting (concentrating) the amount of entropy in a key often arises. If bits are truncated then the entropy in those bits is discarded.

So what is actually used in modern cryptography is a KDF, a Key Derivation Function. If the input - the seed - is a password, you should utilize a PBKDF (Password Based KDF). Modern PBKDF's are PBKDF2, bcrypt, scrypt and Argon2.

If the input is already a key - data that is provides enough entropy (randomness) if taken together - you should utilize a KBKDF (Key Based KDF). A modern KBKDF is for instance HKDF. Note that these algorithms require additional input, so if no additional data is provided it is most likely that the extra key bits are simply ignored.

The cryptographic strength of AES-128 is and stays 128 bits of course. As long as these bits are indistinguishable from random by an attacker, AES-128 should provide enough security for practical needs. AES-256 could be used if you fear breakthroughs in Quantum Cryptography.

---

So for the answer: "Are AES legal key sizes really the limit?" the answer is a resounding yes. 2048 bit key sizes are more commonly found for asymmetric algorithms such as RSA / DSA. For RSA and DSA the key size is actually rather low, even though it should still be out of reach for practical attacks. Maybe the ciphertext was encrypted using hybrid encryption.

Dagger

Ok so the extra bytes are definitely being ignored? Maybe I could find a test to prove this... perhaps generate a larger key, then encrypt with both full size and max legal size seperately (same salt ofcourse) and see if the cypher text is the same? – Nonscheduled

I don't think they are ignored if you use the AesCryptoServiceProvider directly. Code would be nice, yes! It would probably indicate a bug though, please include API & runtime info if you decide to post it (in the question, please). – Dagger

Ok i have noticed that the documentation states the variable for setting keysize is in bits. If this is true why would the API return that entered quantity of Bytes? 'AES.KeySize = Xbits;' but KeyProduced = Xbytes... – Nonscheduled

Right well this is embarrassing, but now im writing a fresh test, it's not doing the same thing it was before :/ I will have to work backwards and figure out why i was seeing this in the first place, in any case a 256byte key was 100% going through as acceptable, which means you must be right about some kind of key length compensation... Thanks :) – Nonscheduled

Bits / bytes are often confused, I will always make sure that there is little to no confusion possible regarding what is returned or accepted by methods. So I do use ...KEY_BYTES in identifiers of constants or getKeySizeBytes() when bits are the default. – Dagger

In extreme hindsight: There were bugs in RijndaelManaged, maybe you stumbled upon those. – Dagger

Answer 2

You can use larger key sizes with Rijndael, the encryption algorithm on which AES is based, usually up to some library-defined limit. However, you can only use key sizes of 128, 192 or 256 bits with AES. Some implementations may use the first X bits (where is is the key size of 128, 192 or 256 bits) of a byte array or bit stream (usually C/C++ ones) but the .Net Base Class Library (BCL) implementations do not, as @Blorgbeard mentions in his comment.

Edit: To clarify the relationship between Rijndael and AES, AES is a specification created by the US National Institute of Standards and Technology (NIST) (FIPS 197 to be precise) that defines a subset of Rijndael. AES is included in FIPS 140-2, meaning it is approved for certain uses by US government departments.

Pneumococcus

"based" can use some clarification here -- AES is identical to Rijndael, except with restricted key/block sizes. – Rogan

It is not possible to use a key size larger than 256 bits even with Rijndael, Rijndael uses 128, 160, 192, 224 or 256 bit keys, however implementations of Rijndael often just implement the AES keysizes instead. – Dagger