Re-Thinking our Crypto implementation

Motivation:

We need to move away from the usage of mcrypt code to a more modern way of handling crypto within the civicrm code base. Also there have been desire to have more fields other than just the SMTP password field encrypted within the database e.g. Payment Processor Passwords.

Problems:

1. Not easily able to determine what Crypto method has been used (Mcrypt or Base64 encoded only) to save the SMTP password.
2. Not easily to assess which extensions have had fields encrypted (e.g. know that Sparkpost has encrypted their API key but other than that unsure)
3. Relies on CIVICRM_SITE_KEY (which is maybe over-using that value).
4. Linked to Item 2, is there is no way for the API/DAO/Extensions to know what fields have been encrypted so to decrypt code appropriately.

Potential ideas:

1. Create a setting which stores the encryption class and use a factory / hooks to allow for extensions to customise which crypto library to use within CiviCRM
2. Have a hook / use some level of meta data to determine if a field is to be encrypted

Discussion Questions:

1. Should we completely break CRM_Utils_Crypt class as we re-work the encryption within the app
2. How should we handle switching between Crypto libraries?
3. Should extensions be able to use their own Crypto Library whilst leaving rest of the App to use a system specific Crypto?
4. Do we want to allow for civicrm.settings.php defines / environment variable overrides for encrypted fields / data points?