Answers.Body: <p>CiviCRM has a utility class CRM_Utils_Crypt for encryption &amp; decryption. If PHP Mcrypt is installed, it uses that plus base64 encoding. If not, it falls back to using just base64.</p>
  
  <p>This class is used for encrypting some settings, including:</p>
  
  <ul>
  <li><code>smtpPassword</code> in core 4.6.30</li>
  <li><code>sparkpost_apiKey</code> in com.cividesk.email.sparkpost</li>
  </ul>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>A few thoughts...</p>
  
  <ol>
  <li><p>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.</p></li>
  <li><p>The conditional code in CRM_Utils_Crypt::encrypt() &amp; decrypt(), which falls back to just base64 encoding, appears to have been added for PHP 5.2 compatibility on Windows: see Email Configuration at <a href="https://wiki.civicrm.org/confluence/display/CRMDOC/CiviCRM+Configuration" rel="nofollow noreferrer">https://wiki.civicrm.org/confluence/display/CRMDOC/CiviCRM+Configuration</a> . 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...</p></li>
  <li><p>The PHP Mcrypt extension <a href="http://php.net/manual/en/intro.mcrypt.php" rel="nofollow noreferrer">has been deprecated as of PHP 7.1.0 and moved to PECL as of PHP 7.2.0</a>. Comments there say:</p>
  
  <ul>
  <li>"This extension rely in libmcrypt which is dead, unmaintained since 2007."</li>
  <li>"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.]</li>
  </ul></li>
  </ol>
  
  <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-12T19:20:45.987Z
Answers.Text: This seems like it should be discussed on civicrm-dev, or on chat.civicrm.org in the ~dev channel.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-22T14:55:29.947Z
Answers.Text: I thought the same and [posted on Mattermost on 9th August](https://chat.civicrm.org/civicrm/pl/iwzt56391byrxk68ta7pixk8za). One suggestion there was to write this up as a Q&A here.
Answers.UserDisplayName: davejenx
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-22T15:15:15.253Z
Answers.Text: Ha :)  I realize my comment was super unclear.  I was referring specifically to the deprecation of mcrypt.  The rest seems appropriate for SE.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-22T17:11:00.503Z
Answers.Text: Tim Otten [offered a good suggestion on Mattermost](https://chat.civicrm.org/civicrm/pl/xozmpd8wp38kxdsjc9ukydj5ae): "fwiw, Civi includes a copy of phpseclib, which is wrapper that falls back to the best available implementation (eg openssl, mcrypt, pure-php). Rewriting CRM_Utils_Crypt with that (while preserving the crypto params) would also fix the compatibility issue."
Answers.UserDisplayName: davejenx
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-29T17:29:58.680Z
Answers.Text: I just had a similar experience and posted an issue to deal with the simpler problem here: https://issues.civicrm.org/jira/browse/CRM-21120
  Agree that longer term is a different issue and Tim's suggestion sounds like the right direction.
Answers.UserDisplayName: Alan Dixon
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-11T15:20:41.947Z
Answers.LastActivityDate: 2017-08-11T15:20:41.947Z
Answers.UserDisplayName: davejenx
Body: <p>On a CiviCRM 4.6.30 / Drupal 7 installation using the com.cividesk.email.sparkpost extension, outbound email stopped working after enabling the PHP Mcrypt extension on the server. This affected both CiviMail and transactional emails.</p>
  
  <p>Why would this occur and how can it be resolved?</p>
  
Tags: <email><sparkpost>
Title: Why does outbound email stop working after enabling the PHP Mcrypt extension?
ThreadText: # Why does outbound email stop working after enabling the PHP Mcrypt extension?
  
  (Asked by: username_0 on 2017-08-11)
  
  On a CiviCRM 4.6.30 / Drupal 7 installation using the com.cividesk.email.sparkpost extension, outbound email stopped working after enabling the PHP Mcrypt extension on the server. This affected both CiviMail and transactional emails.
  
  Why would this occur and how can it be resolved?
  
  **Tags:** email, sparkpost
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2017-08-11. Score: 3 | Accepted answer
  
  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...
  
  1. 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.
  2. 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...
  3. The PHP Mcrypt extension [has been deprecated as of PHP 7.1.0 and moved to PECL as of PHP 7.2.0](http://php.net/manual/en/intro.mcrypt.php). 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.
  
  > **Comments:**
  > **username_1**: This seems like it should be discussed on civicrm-dev, or on chat.civicrm.org in the ~dev channel.  
  > **username_0**: I thought the same and [posted on Mattermost on 9th August](https://chat.civicrm.org/civicrm/pl/iwzt56391byrxk68ta7pixk8za). One suggestion there was to write this up as a Q&A here.  
  > **username_1**: Ha :)  I realize my comment was super unclear.  I was referring specifically to the deprecation of mcrypt.  The rest seems appropriate for SE.  
  > **username_0**: Tim Otten [offered a good suggestion on Mattermost](https://chat.civicrm.org/civicrm/pl/xozmpd8wp38kxdsjc9ukydj5ae): "fwiw, Civi includes a copy of phpseclib, which is wrapper that falls back to the best available implementation (eg openssl, mcrypt, pure-php). Rewriting CRM_Utils_Crypt with that (while preserving the crypto params) would also fix the compatibility issue."  
  > **username_2**: I just had a similar experience and posted an issue to deal with the simpler problem here: https://issues.civicrm.org/jira/browse/CRM-21120 Agree that longer term is a different issue and Tim's suggestion sounds like the right direction.  
  
  ---
  
  