This should be a comment, but it's a bit long.
I get the impression that you are asking the wrong questions.
Yes, ECB is bad, but only if your ciphertext is more than a single block - and your data isn't. If it is longer, then any of the feedback modes (i.e. everything else) is an improvement.
Are you just asking about different encryption modes, or about the implementation of the encryption?
You only really have four choices for encryption in PHP:
- mcrypt extension
- openssl extension
- sodium extension
- PHP based implementations
While current versions of PHP are quite fast enough to handle encryption/decryption written in PHP, using an extension to a common shared object implies that the underlying implementation has much wider exposure - and hence review, testing and compatibility. Meanwhile libmcrypt has been described as abandonware. While it would be nice to think that the developers might actually have produced something which is known to be bug-free and resisted the temptation to keep adding new functionality, I would like to think that those developers would be pushing out information every now and again to say that they were still keeping an eye on things and everything was OK. Although I haven't done a lot of looking, I've not noticed any such information. The flipside is that if there were known vulnerabilities then these should appear as CVE announcements. The most recent CVE I can find for libmcrypt is from 2003 - so maybe the code really is finished. OTOH the PHP extension is now deprecated.
I've not looked at the sodium extension in any detail.
As shawn says (+1) Rijndael-256 is NOT AES-256. Why deliberately choose to use what is effectively an uncommon algorithm unless you have very specific reasons - which you have not stated in your question. Digressing for a moment....one valid reason would be that you need to maintain data compatability, but the algorithm alone does not determine this - that's about the encoding of the ciphertext, the initialization vector and any associated integrity verification mechanism. Which are also the things which determine the overhead and impact the security and reliability of the solution. Switching to a different implemementation of the algorithm while maintaining compatibility could mean a lot of re-engineering of the encoding.
what I am storing is session identifiers
...which implies you don't need to maintain compatibility. If you are changing the implementation then you merely need to provide for supporting 2 different implementations during a short transition.
If you need very high reliabilitiy/availability of the data, then the place to address this is after you have the ciphertext not in the implementation of the encryption.
I dont need authentication since I already have the hash of the Plaintext stored elsewhere
it's considered the best practice to authenticate the ciphertext. – Cthulhu Sep 28 '15 at 8:55