best operation mode for Rijndael-256 in PHP

Question

so my question is about the operation mode. In another thread I heard that ECB is bad which makes sense when I read about it, so I wanna change some things at my Crypto to make it better and wanted to ask on which of the Rijndael-256 modes is the best with regard to the following points:

• PHP compatible
• Secure
• reliable
• not too much overhead in the ciphertext (it gets transferred over the internet more than often enough)
• I dont need authentication since I already have the hash of the Plaintext stored elsewhere

what I am storing is session identifiers, which are 256-char A-Z a-z 0-9 strings, and the key is an automatically generated hash of certain user data (user agent and similar things) in case it may help

if there's a better encryption method feel free to tell me about that as well.

Answer 1

For mode selection: anything other than ECB is safer. Do not worry too much ( have a look at https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation )

But for Rijndael-256 ...

http://php.net/manual/en/function.mcrypt-encrypt.php#117667

Rijndael-256 is NOT AES-256. Do not use Rijndael-256 or you may fail to decrypt (say, by OpenSSL).

https://en.wikipedia.org/wiki/Advanced_Encryption_Standard

AES is a variant of Rijndael which has a fixed block size of 128 bits, and a key size of 128, 192, or 256 bits. By contrast, the Rijndael specification per se is specified with block and key sizes that may be any multiple of 32 bits, with a minimum of 128 and a maximum of 256 bits.

And, mcrypt was DEPRECATED in PHP 7.1.0, and REMOVED in PHP 7.2.0, please consider to use OpenSSL or Sodium

Answer 2

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.

Answer 3

Considering PHP has gone a long way and axed mcrypt and I didnt want to go with an extension, I went a better way and switched completely to openSSL with normal AES-256 (128 bit blocks instead of the 256-bit blocks in Rijndael-256) and used CTR mode because of the parallelization properties making it potentially faster in both en- and decryption, and that, unlike with e.g. CBC, I dont also need unredictability for the IV, something I dont really want to rely on.

I honestly still consider auth'ed crypto fairly useless in my Design (because something similar is already in place), but I did make some more upgrades to justify it. But for many things it is definitely useful)

By switching to a JWT-style scheme (to add more data that doesnt need to be encrypted), I already have a Signature, not only over the encrypted data but also over the entire rest of the data, which is probably a bit more secure than JUST storing the plaintext hash in the database (which is basically a remote version of MAC-and-Encrypt), I have no more data to pre-test before deriving the key and doing the whole decryption and then do stuff.