# Basic encryption question: Why does 128/256 bit encryption have set length keys?

I've read about 128 and 256 bit encryption (I obvioulsy haven't read enough). I believe 128 and 256 refer to the size (in bits) of the keys used to encrypt.

Why are these of set length? Surely an encryption key can be any length you want to encrypt with? What part of encryption am I misunderstanding here? Or am I confusing encryption with hashing?

• 128 and 256 is NOT the key size. well, it could be i guess, but that's not what the number means. – dandavis Jan 4 '17 at 22:19
• @dandavis I guess when people talk about "128 and 256 bit encryption" that they do mostly mean the key size, which, for unbroken symmetric ciphers, is also identical to (or at least pretty close to) the strength of the cipher. – Maarten Bodewes Jan 5 '17 at 21:24

The first thing that you really need to understand is that cryptographic keys are not the same thing as passwords. Many newcomers to cryptography are familiar with passwords, and identify keys as an analogous concept—which it is, but the differences are very important:

1. Passwords are generally chosen by humans; cryptographic keys are randomly generated with a good source of randomness (dice are good, brains are not);
2. Passwords are generally memorized by humans; but no strong cryptographic key can be memorable. Keys are instead stored in secure hardware.
3. Passwords are text that humans can read and type easily; keys are binary data and not generally printable in their raw form. You need to format them as hexadecimal, Base64 or similar for display. (Actually, you really shouldn't display them at all, since they're not memorable anyway!)

If your AES key is something like PASSWORDPASSWORD (which I've actually seen 😠), somebody has likely made a terrible mistake. A 128-bit key should be 128 randomly chosen bits!

With that out of the way, now we can say: practical cryptographic systems are built by assembling together well-studied primitives (e.g., AES, SHA-2, RSA, etc.), into complete protocols (e.g., SSL, SSH, OpenPGP) for achieving the users' goals. And given this sort of architecture:

• Fixed key sizes generally make the primitive simpler to design, implement and evaluate.
• If arbitrary-length key sizes are needed, this can generally be accomplished at the protocol level. For example, the AES-CMAC-PRF-128 function is based on AES-128 but uses variable-length keys. So part of the function's definition is a method for converting the arbitrary-length key into an AES-128 key.
• There's no earth-shattering advantage to supporting arbitrary-length keys, so most protocols don't bother with it.
• For cryptographic systems that work with passwords, there's an area known as password-based cryptography—cryptographic constructions and protocols for generating cryptographic keys out of human-supplied passwords. A protocol for encrypting files based on user-supplied passwords works this way—it uses a password-based key derivation function like PBKDF2 to convert the password to a key, and then uses that key to encrypt and decrypt files. So this is another example of cryptographic modularity—the primitives support only fixed-size keys, but their combination supports arbitrary-length passwords.

When people talk about encryption keys, they are usually thinking about a type of encryption called a "block cipher", meaning that it iterates over the plaintext message one "block" at a time using the key and the output of the previous block to produce one block of cipher text. The block size (number of bits in a block) is usually fundamental to how the algorithm is designed and can not be changed on the fly. There are lots of different kinds of block ciphers, so it's hard to generalize.

The key size is often the same as the block size. Most modern block ciphers also allow a key that's larger than the block size though the sizes are usually related; key size needs to be a multiple of the block size, or they both need to be a multiple of 32, or something like that depending on the algorithm.

Let's dive into a concrete example: AES-128 vs AES-256. Wikipedia says:

For AES, NIST selected three members of the Rijndael family, each with a block size of 128 bits, but three different key lengths: 128, 192 and 256 bits.

AES is a subset of a more general family of ciphers called Rijndael ciphers. This quote (also from wikipedia) gives us a bit more context:

AES has a fixed block size of 128 bits and a key size of 128, 192, or 256 bits, whereas Rijndael can be specified with block and key sizes in any multiple of 32 bits, with a minimum of 128 bits. The blocksize has a maximum of 256 bits, but the keysize has no theoretical maximum. AES operates on a 4×4 column-major order matrix of bytes, termed the state (versions of Rijndael with a larger block size have additional columns in the state).

You can see that 4x4 bytes (=128 bits) is the fundamental block size of AES. While the number of bits in the key does not need to be the same as the block, it does need to a multiple of 32 in order for the math to work out properly.

As for hashes: if you dig into hashes, you'll learn that most of them work in the same way: they have a fundamental block size which is also usually a multiple of 32!

For security, the encryption always operates on blocks of a fixed length. For efficiency, this is always a power of 2. If the input does not match, it will have to be padded. Same goes for the keys. Any length password can be used, but first a key of the appropriate length will have to be derived from it, like PBKDF2 (password based key derivation function two). This takes a passphrase and spits out a 128/256 bit hash-like result to be used as the actual key