I guess the start of this then would be

• Identify the methods that implement/consume mcrypt in the Joomla code,
• Document those,
• unit test them in their current state
• Refactor out the use of mcrypt
• Ensure tests still run
• TEST TEST TEST TEST TEST
• TEST
• TEST

?

This will also need @nikosdion help as mcrypt appears in the updater/restore.php etc.

Um, if mcrypt is no longer supported how do we implement AES encryption in PHP? Native PHP code is orders of magnitude slower.

Edit: I mean that we'd have to go through the OpenSSL extension which is even less popular than mcrypt. This is going to be "fun" on shared hosts. Especially those running PHP 5.3. We need to raise the minimum PHP requirement to 5.5 or 5.6 if we want people to run Joomla on configurations that have a chance of providing an alternative. Otherwise we will have a problem, especially with data migration of extensions using Joomla's crypto functions.

See. I knew it was important to tag @nikosdion ;-)

FWIW the restore.php only uses mcrypt out of context of the Joomla Update (extracting JPS archives). The part used during the update is native PHP code implementing AES-CTR, used to encrypt the serialized extraction engine state with a server side key and send encrypted instructions to the JavaScript side (which also implements AES-CTR in native JavaScript).

Um, if mcrypt is no longer supported how do we implement AES encryption in PHP?

According to the RFC I linked OpenSSL can handle AES encryption. Not sure about many details beyond that but that seems to be the primary recommendation from Scott.

Hence I edited my reply (sorry; just having my first coffee of the day). While OpenSSL handles AES encryption the extension itself is not as widely deployed as mcrypt on older PHP installs. So it's not a matter of replacing code but adding if-blocks to use what is available. If you want to be very conservative we'd also need a full native implementation so the order of preference would be:

• OpenSSL
• mcrypt
• native code (slow) The only thing I'm not sure is whether we can find a native AES implementation compatible with GPL 2.

On a different note, there is one place in Joomla where replacing mcrypt will be tricky: FOF2. It's obsolete and I'm not going to maintain it. The good news is that nobody seems to be using that code.

@nikosdion has updated FOF2

[HIGH] mcrypt is deprecated in PHP 7.1. This will cause Two Factor Authentication to fail under PHP 7.1 unless you apply this PR.

So the "tricky" bit has already been done :)

Just an aditional note, when joomla does not need mcrypt anymore i guess the two PR for info on mcrypt installed #9508 and #9532 should be reverted.

Remaining mcrypt uses are in deprecated code or third party libraries. Complete enough.