Home » Php » encryption – PHP Mcrypt, how secure is it really?

encryption – PHP Mcrypt, how secure is it really?

Posted by: admin July 12, 2020 Leave a comment


At the moment I am working on a project that will handle some quite sensitive personal information, although it are not backaccount numbers it is still sensitive personal information and I want to do everything I can do to encrypt and store this information inside a mysql as safely as possible. So now I am intensely looking for some security measures that could deal with this sensitive information.

One easy way I found to encrypt/decrypt strings and text blocks, would be using mcrypt. But when I search on mcrypt over here on stackoverflow, I noticed that many people tell that mcrypt is afterall not that secure.

So now I am wondering, how secure is it really? Does it takes a lot of hacking skills, let’s say expert skills, to crack and decrypt the stored information if the key is stored securely? Do I need to be afraid that a hacker with little skills can decrypt the encrypted information that I am going to store inside mysql server? So what skills does it take to crack the encrypted information that’s encrypted with mcrypt?

If Mcrypt is not usable enough, what are good alternatives that are not to complex as using the gnupg extensions?

How to&Answers:

A small guide you could follow to avoid a few pitfalls and apply some recommendations.

  • Do not reuse the same encryption key and initialization vector (IV) for two different messages.

Doing so will risk exposure of the plain-text if an adversary manages to intercept two or more messages during transit using the same key and IV.

  • Don’t use ECB mode; OFB and CTR mode are somewhat better, but it’s recommended to use CBC or CFB mode.

The main reason to not use ECB is because this mode leaks information about duplicate plain-text blocks which may undermine your encoded stream of data.

OFB and CTR are better, but they suffer from the aforementioned security issue of using the same IV+key combination more than once.

CFB and CBC are the most resilient against IV+key reuse, but separate messages with the same common prefix will leak out the length of said prefix. In addition, CFB leaks out the difference of the first non-identical plain-text blocks.

  • Make sure you have a strong encryption key

    It should not be chosen from printable ASCII (e.g. not “my super strong secret key”); PBKDF2 would be preferred (soon to be supported natively, until then Google it). It should be obvious that this key must be kept safe; if you lose it, bye bye data.

  • Use a good entropy source to generate the initialization vector.

    Mcrypt has an option to use MCRYPT_DEV_RANDOM or MCRYPT_DEV_URANDOM when you call mcrypt_create_iv().

Hope this will help you 🙂