I use MCRYPT_RIJNDAEL_256 in CBC mode using mcrypt in PHP. This supports key sizes of 16, 24 or 32.

Is a key size of 32 more secure than a key size of 16 or 24? If it is, does it really matter or is it just a little bit better? And does a larger key noticeably impact performance in this case?

Searching on Google or here on Information Security doesn't help me, I can't find an answer to this question.

My guess is that a longer key is more secure and that it doesn't really affect the performance but I would like a confirmation (preferably along with some sources).

  • Is there any reason why you picked MCRYPT_RIJNDAEL_256? Note that this is not AES-256. It's actually not AES at all. The number in the Mcrypt constant refers to the blocksize, whereas the numbers of the AES variants refer to the key length. AES is Rijndael with a blocksize of 128 bit, so that would be MCRYPT_RIJNDAEL_128. If you want the AES-256 variant, you simply use a 256-bit key. – Fleche Jun 15 '14 at 15:41
  • Yeah I've read that, thanks! I just used it for a test and was wondering about the key size, if I would really use it I would do some research for the best cipher first. – Louis Matthijssen Jun 15 '14 at 17:34

More often, you'll hear key sizes discussed in bits rather than bytes. So, 32 bytes = 256 bits. 16 = 128, 24 = 192.

In theory, yes, longer key lengths are more secure, as there are more permutations of the key possible. Each additional bit means twice as many possible keys, so doubles the amount of time necessary to brute force the key. That being said, physics suggests it's impossible to even brute force 128 bits. So, in reality, situations where 256-bit crypto is being used for one of two reasons: 1) they want additional safety margin if weaknesses (but not a full break) are found in AES, or 2) they want to be able to market it as "256 bit crypto!" In other words, it's often used for the warm-and-fuzzy feeling of "better" crypto.

Way more important than the key length you choose is how you create your key. If your keys are created by a human at a keyboard choosing a password, they're highly unlikely to come up with 128 bits. According to NIST, based on studies of common password practices, a human chosen password would need to be 112 characters long to give 128 bits of entropy. Given that users are unlikely to type 112 characters, your key generation strategy may be the weak point (again, assuming user-generated keys). Consider using something like PBKDF2 to harden user input into keys.

If you're generating the keys, make sure you use a quality source of entropy, like /dev/urandom or openssl_random_pseudo_bytes in PHP. Do not use rand or mt_rand, as those are not cryptographically secure, and are predictable to an attacker.


Longer keys are not more secure -- not when the "short" key is already way too long to be breakable through brute force. You cannot be more secure than secure. It does not matter if the time needed to break your key is 10 times or 10 billion times the lifetime of the Universe.

Rijndael is better known as AES. When you use a 256-bit key (32 bytes), it is 40% slower than when you use a 128-bit key (16 bytes); the extra time is a quirk of the way the algorithm is defined (14 rounds with a 256-bit key instead of 10 rounds for a 128-bit key). It rarely matters in practice, though.

Therefore, you got it in reverse: a longer key is not "more secure", but it can affect performance.

(In practice, the key size is the strongest part of your system; it will be time to fidget about quantum computers when every other bit of software and hardware in your application has been brought up to such levels of safety, which is unlikely to happen in any actual piece of software, especially one containing a general-purpose OS, a Web server, and PHP.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.