I know that Rijndael and AES are pretty similar and AES is just a subset of Rijndael, and I have read that Rijndael can have 256 bit blocks while AES has "only" 128 bit blocks.

The problem is that I have no real idea of cryptography my question is what is more secure? Is "standard AES" more secure or some of the tweaked options using Rijndael? Right now I am using MCRYPT_RIJNDAEL_256 in PHP which is (as far as I can tell) Rijndael with 256 bit block and key size while AES-256 has 256bit key but "just" 128 bit blocks.

  1. The point is in the end whether to use AES or Rijndael?

  2. Also what mode would be best for security/performance? Right now I have ECB since that was used in a tutorial at that time.

  3. Is there another algorithm that is even more secure? It should be fast, since I am doing a lot of crypto stuff using it, but still stay secure.

  • paragonie.com/book/pecl-libsodium has advice. You are asking good questions but there are far better choices available as to details. Sep 18, 2015 at 11:50
  • I would rather wonder if you should use a wrapper that relies on a C library that hasn't had an update in oh, about 11 years. It doesn't just not do authenticated encryption, it doesn't even do padding properly. Sep 18, 2015 at 14:44
  • I dont think I need an authenticated encryption since the crypto is literally doing the session auth, the crypto key isnt going anywhere and the session key that is literally generated upon some factors I get from the client (agent IP) and some of the server (additional secret, time and other stuff) and once I decrypted that session key it is looked up in a DB and the session data is derived from the DB stuff.
    – My1
    Sep 18, 2015 at 16:04

2 Answers 2


128 bit blocks are fine

Yes, larger block sizes have some advantages. If your blocks are larger, then can encrypt more data with the same key until you have to roll over to a new key.

But for practical purposes it's enough. (Re-evaluate once you intend stay safe past the petabyte barrier with the same key.)

ECB is bad.

Identical input blocks are encrypted to identical output blocks. This is bad.

Unauthenticated encryption is bad.

Attackers can flip bits in your blocks, delete blocks, resort blocks, insert blocks. This is bad.

Try to use GCM

GCM is an "Authenticated Encryption" mode of operation for block ciphers. It hides repetitions in the plaintext and it seals the ciphertext against manipulation.

I don't know if this is in PHP natively. This questions suggests something like this is doable via OpenSSL:

  • okay I got that ECB is bad, that's why I ask. but what do you exactly mean with the block manipulation? they have the cipher and I know how to generate the key to get what I need to check this and then essentially the crypto is what does the authentication. I usually encrypt 256 character long strings (aka session keys) using a 32 character key which I generate upon several parameters, like time, IP and stuff
    – My1
    Sep 18, 2015 at 11:59
  • 1
    Yes and no. This is sometimes referred to as "Poor mans' authentication". The thinking goes like this: "Okay, if someone flips a bit, then he will just end up with complete garbage on decryption. Which is useless." But what about dropping/replaying/resorting a complete block? No way to tell, unless you authenticate. Sep 18, 2015 at 12:06
  • well I usually go this way: for starters try to decrypt, then check whether only the desired character types are used and THEN check whether that session exists in the DB using the hash of the decrypted result (since the key is nowhere in plaintext only crypted (client) or hashed (server) as there needs to be some way to indenticate who is on what session.
    – My1
    Sep 18, 2015 at 12:23
  • by the way are there other factors influenced by the block size other than the max size of the plain text? like if smaller blocks are faster without affecting the security maybe that could help for reducing server load and stuff, especially since I am not encrypting more than 256 alphanumeric characters, case sensitive
    – My1
    Sep 18, 2015 at 16:06

AES/Rijndael block size has no influence on security. The larger block sizes of Rijndael might help with security only when you begin to encrypt substantially more than 268 bytes or so with a single key: we are talking about a million terabytes here, so that won't happen any time soon.

What matters for security is how you use the algorithm. You talk about "ECB" and that is not a good sign. Cryptographic algorithms achieve some very precise characteristics, that make sense and actually improve security only when used in a sensible way, i.e. as part of a well-defined and well-designed protocol where matters attack models and key management have been thoroughly investigated. Simply sprinkling crypto over your code as if it was some magic pixie dust will not give you security; only a feeling of security.

As for performance, it shall be measured. When people measure performance impact of using cryptography, they usually notice that it matters a lot less than what they initially assumed.

  • well I see that ECB is bad now, it would be nice to have some help for it, here my code, (function names are historical): ``` public static function aescrypt($encrypt, $mc_key) { $passcrypt = mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $mc_key,trim($encrypt),MCRYPT_MODE_ECB); $encode = base64_encode($passcrypt); return $encode; } public static function aesdecrypt($decrypt, $mc_key) { $decoded = base64_decode($decrypt); $decrypted = trim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, $mc_key,$decoded,MCRYPT_MODE_ECB)); return $decrypted; } ```
    – My1
    Sep 18, 2015 at 12:06
  • There is no "good code" until you have at least defined what you are trying to achieve: what potential attackers may try to do, and why encryption actually prevents them from doing so. Sep 18, 2015 at 12:10
  • well in short I use the crypto for keeping the session key a secret on the cookie of client side it goes as this: get key, try decryption check result for plausability (char types) and then has and check the DB for session ID, user ID and stuff. what I need is a plain encrypt/decrypt function, since all the other checks are already implemented for going around garbage strings, while a false MIGHT do stuff I dont want, so I just need a trim->crypt->base64 and vice versa
    – My1
    Sep 18, 2015 at 12:27
  • So what you want, in fact, is not to prevent the user (presumed attacker here) from learning his own session ID (it is just an indexing key in your database), but to prevent the user from feeding you with an "invalid" session ID (because it "might do stuff"). Your need is thus not for confidentiality (that encryption provides) but for integrity (that encryption does NOT provide). You want a MAC. Doing encryption combined with a "check for plausability" is just a poor, homemade way to make a (weak) MAC. Sep 18, 2015 at 12:35
  • it does not just for plausability, it is an in between step, before it does the real stuff (similar as you sanitize user data) like checking the db for it. point is that my implementation is made to get a string no matter if garbage or not , because the sort out of garbage is done later but before any "serious" check occur. it is more like a pre-sort out g (et key -> try to decrypt -> check for plausability -> check db for its existence and parameters) as I have a db check the attacker cant even fill a nicely crypted invalid key as it wont get any results in the db, and junk is dropped before.
    – My1
    Sep 18, 2015 at 12:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .