CiviCRM has a utility class CRM_Utils_Crypt for encryption & decryption. If PHP Mcrypt is installed, it uses that plus base64 encoding. If not, it falls back to using just base64.
This class is used for encrypting some settings, including:
smtpPassword
in core 4.6.30
sparkpost_apiKey
in com.cividesk.email.sparkpost
PHP Mcrypt was not initially installed on the server, so these settings will have been encoded by CRM_Utils_Crypt::encrypt() just using base64_encode.
Once PHP Mcrypt is installed, CRM_Utils_Crypt::decrypt() will try to decrypt these settings using mcrypt functions. This fails in this case, because they weren't encrypted with mcrypt when they were entered.
The simplest solution is to re-enter the settings. They will then be stored encrypted with mcrypt. If this wasn't feasible, it should be possible to write a script to decode specified settings using the non-mcrypt method and then encrypt and store them using mcrypt.
A few thoughts...
If Mcrypt is not installed, settings are not being stored encrypted. It would be good if site admins were made aware of this, perhaps via the System Status page. This could also warn of the consequences of enabling Mcrypt on a server where Civi is already configured.
The conditional code in CRM_Utils_Crypt::encrypt() & decrypt(), which falls back to just base64 encoding, appears to have been added for PHP 5.2 compatibility on Windows: see Email Configuration at https://wiki.civicrm.org/confluence/display/CRMDOC/CiviCRM+Configuration . As CiviCRM no longer supports PHP 5.2, the reason for this change seems no longer to apply and perhaps we should make Mcrypt a requirement. However...
The PHP Mcrypt extension has been deprecated as of PHP 7.1.0 and moved to PECL as of PHP 7.2.0. Comments there say:
- "This extension rely in libmcrypt which is dead, unmaintained since 2007."
- "Avoiding mcrypt is only half of the advice. The other half: NEVER do crypto in PHP in the first place!" [It goes on to give some good arguments and alternatives.]
In summary, I think Civi should not leave it to chance, when it comes to deciding whether or not to encrypt something, whether a particular PHP extension is installed or not. It should at least warn site admins, if not require a suitable encryption method to be available. Which method that should be needs discussion, given the deprecation of PHP Mcrypt.