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
PHP’s optional 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:
Surprise! MCRYPT_RIJNDAEL_256
doesn’t mean AES-256
.
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_192
and 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.
In almost every metric, openssl wins over mcrypt:
- Specifying
'aes-256-cbc'
is much more obvious than remembering to useMCRYPT_RIJNDAEL_128
with a 32-byte binary key. openssl_encrypt()
performs PKCS7 padding by default, and lets you specifyOPENSSL_ZERO_PADDING
if 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-NI
also 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.
OpenSSL Gotchas
- 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 ismcrypt_create_iv()
, as demonstrated above, but this function is only exposed if you enable themcrypt
extension. Fortunately, PHP 7 will offer a corerandom_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.
In Sum
Don’t use 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”]
The opinions expressed in this post belongs to the individual contributors and do not necessarily reflect the views of Information Security Buzz.