You probably should not be deploying your own cryptography to begin with, especially if you don’t already understand that encryption is not authentication. For production systems, use PECL libsodium or defuse/php-encryption and save yourself the headache.
The rest of this post is intended for PHP developers who still want to write their own cryptography code, or already have.
Top 3 Reasons to Avoid Mcrypt
- Mcrypt is Abandonware
mcrypt extension provides bindings for a cryptography library called libmcrypt, which has been collecting dust since 2007 (eight years and counting) despite plenty of bugs, some which even have patches available.
If bit rot weren’t enough reason to avoid using this library, the major design flaws which make it easier to write insecure code than it is to write secure code should.
- It’s Confusing and Counter-Intuitive
Look at this list of mcrypt ciphers and tell me how you would implement
AES-256-CBC. If your code looks like this, you’ve just run headfirst into the first (and arguably most common) mcrypt design wart:
MCRYPT_RIJNDAEL_256 doesn’t mean
All variants of AES use a 128-bit block size with varying key lengths (128, 192, or 256). This means that
MCRYPT_RIJNDAEL_128 is the only correct choice if you want AES.
MCRYPT_RIJNDAEL_256 instead refer to non-standard, less-studied variants of the Rijndael block cipher that operate on larger blocks.
Considering that AES-256 has much worse key scheduling than AES-128, it’s not at all unreasonable to suspect there might be unknown weaknesses in the non-standard Rijndael variants that are not present in the standardized 128-bit block size version of the algorithm.
Isn’t it great that mcrypt makes you feel dumb for not knowing details that you probably shouldn’t really need to know? Don’t worry, it gets worse.
- Null Padding
We already stated that not authenticating your ciphertexts is a bad idea, and in all fairness, padding oracle attacks are going to be a problem in CBC (Cipher Block Chaining) mode no matter what padding scheme you select if you fail to Encrypt then MAC.
If you encrypt your message with
mcrypt_encrypt(), you have to choose between writing your own plaintext padding strategy or using the one mcrypt implements by default: zero-padding.
To see why zero-padding sucks, let’s encrypt then decrypt a binary string in AES-128-CBC using mcrypt (The result of running this code is available here) :
As you can see, padding a plaintext with zero bytes can lead to a loss of data. A much safer alternative is to use PKCS7 padding.
OpenSSL Does It Better
Here is an example of an unauthenticated AES-256-CBC encryption library written in Mcrypt with PKCS7 padding.
And here’s the library written using OpenSSL.
In almost every metric, openssl wins over mcrypt:
'aes-256-cbc'is much more obvious than remembering to use
MCRYPT_RIJNDAEL_128with a 32-byte binary key.
openssl_encrypt()performs PKCS7 padding by default, and lets you specify
OPENSSL_ZERO_PADDINGif you really want it.
- The code you write ends up much more compact and readable, with less room for implementation errors.
- It performs AES encryption/decryption much faster, since it supports AES-NI if your processor has this feature.
AES-NIalso means you don’t have to worry about an attacker recovering your secret key from cache-timing information.
- OpenSSL is being actively developed and maintained. In response of the Heartbleed vulnerability last year, several organizations (including the Linux Foundation) declared the project critical Internet infrastructure and began pouring resources into finding and fixing bugs in the system. If you still don’t trust it, there’s always LibreSSL.
Simplicity, security, and performance. What more is there to ask for?
There are, however, two things with OpenSSL that you should watch out for.
- The CSPRNG they offer is a userspace PRNG based on hash functions, which goes against the advice of Thomas Ptacek to use
/dev/urandom. The only one-liner alternative is
mcrypt_create_iv(), as demonstrated above, but this function is only exposed if you enable the
mcryptextension. Fortunately, PHP 7 will offer a core
random_bytes()function that leverages the kernel’s CSPRNG.
- Although your version of OpenSSL might list GCM based cipher modes (e.g.
aes-128-gcm), PHP doesn’t actually support these methods yet.
mcrypt. If you’re typing the word
mcrypt into your code, you’re probably making a mistake. Although it’s possible to provide a relatively secure cryptography library that builds on top of
mcrypt (the earlier version of defuse/php-encryption did), switching your code to
openssl will provide better security, performance, maintainability, and portability.
By P.I.E. Staff
[su_box title=”About P.I.E” style=”noise” box_color=”#0e0d0d”]
Paragon Initiative Enterprises (P.I.E) is an Orlando-based company that provides software consulting, application development, code auditing, and security engineering services.[/su_box]