Loading

Encryption Engines

Fields marked for encryption are encrypted before they are stored. The Encryption Engine decides which library does that work.

Where to find it

Architect Panel → Configuration:

  • Site Settings — Encryption Engine, Encryption Cypher and Encryption Level

Architect Panel → Data:

  • Datastores — where individual fields are marked for encryption

The three options

  • OpenSSL — requires the OpenSSL extension. The default, and the right choice for most installations.
  • Sodium — requires the Sodium extension, bundled with PHP since 7.2. Modern, with a small set of well-chosen defaults.
  • mcrypt — deprecated as of PHP 7.1 and removed from later versions.

Do not use mcrypt

It is present for compatibility with installations that predate its deprecation. It has been unmaintained for years and is absent from any current PHP.

If you are running it, plan a migration. If you are setting up, do not select it — the choice is between OpenSSL and Sodium.

OpenSSL or Sodium

Both are sound. The practical difference is in what you configure:

  • OpenSSL uses the Encryption Cypher setting, and ignores Encryption Level.
  • Sodium uses the Encryption Level setting, and ignores Encryption Cypher.

Knowing this saves confusion: changing a setting that does not apply to your engine has no effect at all, and there is nothing to indicate that.

Choose before you encrypt anything

This is the important operational point. Data encrypted under one engine is not readable by another. Changing the engine on a system with encrypted data means decrypting and re-encrypting everything, which is a planned migration with downtime, not a settings change.

So decide at setup, confirm the extension is present, and leave it alone.

Verify the extension is actually available

Each engine depends on a PHP extension. Confirm it is present on every server that runs the platform — including any you add later. An engine selected but unavailable fails at the moment somebody saves an encrypted field, which is a poor time to discover it.

What encryption here does and does not cover

This encrypts specific field values at rest. It does not encrypt the whole database, it does not protect data in transit — that is TLS — and it does not protect against somebody with legitimate access to the field.

Field encryption defends against someone obtaining the database file or a backup. Pair it with field security, which defends against people who have access to the system but should not see that field.

Encrypt selectively

Encrypted fields cannot be searched or sorted in the ordinary way, so encrypting everything makes the application worse for no benefit. Encrypt what would genuinely harm somebody if a backup were lost — identifiers, financial details, health information — and leave the rest.

Worked example

An installation runs OpenSSL, confirmed present on both application servers. Four fields across two datastores are encrypted: national insurance number, bank account, and two free-text fields holding health information. Names and addresses are left unencrypted so they remain searchable, and are protected by field security instead.

Recommendations

  • Use OpenSSL or Sodium; never mcrypt.
  • Choose the engine before encrypting any data.
  • Verify the extension on every server.
  • Encrypt selectively — encrypted fields are not searchable.