Encryption

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.

Choosing a Cipher

The Encryption Cypher setting chooses the algorithm and mode used to encrypt field data. It applies only when the engine is OpenSSL.

Where to find it

Architect Panel → Configuration:

• Site Settings — Encryption Cypher — applies only with the OpenSSL engine

The default

It ships at AES-256 in CBC mode. That is a well-understood, widely reviewed choice, and it is the right answer for essentially every installation.

Why you probably should not change it

Cipher selection is one of those settings where the available options are not equally good, and the difference is not visible from the setting name. A shorter key length, an outdated algorithm or an inappropriate mode all look like ordinary choices in a list.

Unless you are working to a specific standard that names a different cipher, leave it. There is no performance problem to solve here — field encryption is not where a well-built application spends its time.

If you must change it

Change it before any data is encrypted. Data encrypted under one cipher is not readable under another, so changing it on a system holding encrypted fields means a planned decrypt-and-re-encrypt migration.

Confirm the cipher you choose is supported by the OpenSSL build on every server, and prefer a 256-bit key and an authenticated or well-established mode.

It does nothing under Sodium

If your engine is Sodium, this setting is ignored entirely — the equivalent control is Encryption Level. Changing the cipher while running Sodium produces no change and no warning, which has confused people into thinking encryption was not working.

Record what you chose

Note the engine and cipher in your system documentation. It is the first thing anybody needs when restoring a backup onto a rebuilt server, and it is otherwise only discoverable from a settings screen you may not be able to reach.

The key matters more than the cipher

Any modern cipher is strong enough. Whether the encryption is meaningful depends on where the key lives and who can reach it — a strong cipher with a key sitting beside the data in the same backup protects against very little.

Spend your attention on key handling and backup separation rather than on the algorithm choice.

Worked example

An organisation reviews its configuration before go-live, confirms the engine is OpenSSL and the cipher is the AES-256 default, checks the extension is present on both servers, and records both in the runbook. Nothing is changed — which is the correct outcome of that review.

Recommendations

• Keep the default unless a standard requires otherwise.
• Change it only before encrypting data, never after.
• Ignore it entirely under Sodium.
• Record engine and cipher in your runbook.

Encryption Levels

The Encryption Level setting applies only when the engine is Sodium. It selects among four options with different performance characteristics.

Where to find it

Architect Panel → Configuration:

• Site Settings — Encryption Level — applies only with the Sodium engine

The four levels

• ActiveManage standard — the default, described as very fast.
• Level 1 — very fast.
• Level 2 — fast.
• Level 3 — slow.

Slower is not simply stronger

It is tempting to read the list as a strength ladder and pick the slow one. Resist that.

The cost of these levels is paid on every read and write of every encrypted field — on every form load, every list, every API response that includes one. On a datastore with several encrypted fields and a busy list view, the difference between very fast and slow is not academic; it is the difference between a page that loads and one that people complain about.

Meanwhile the threat these levels differ over is not the one most installations face. Data is lost through a mislaid backup, an over-broad permission or a compromised account — not through somebody defeating a well-chosen modern cipher.

Keep the default

The ActiveManage standard is the intended setting and is very fast. Change it only if you have a specific requirement that names something else, and measure the effect if you do.

Measure before and after

If you do change it, take a benchmark from the status panel first, load a form and a list containing encrypted fields, and compare. A change that makes a routinely used screen noticeably slower will be reversed eventually — better to find that out deliberately than after a fortnight of complaints.

Set it before encrypting data

As with the engine and the cipher: data written under one level is read under the same one. Decide at setup.

It does nothing under OpenSSL

If your engine is OpenSSL, this setting is ignored and Encryption Cypher is the one that applies. Changing the level while running OpenSSL has no effect whatsoever.

The real performance lever is what you encrypt

Far more significant than the level is how many fields are encrypted and whether they appear in list views. An encrypted field in a browse view showing fifty rows is fifty decryptions per page load.

Keep encrypted fields off list views where you can, and encrypt only what genuinely needs it.

Worked example

A team running Sodium considers moving to the slowest level for a datastore holding health information. They benchmark first and find the case list — which showed two encrypted fields — takes noticeably longer. They keep the default level and instead remove the encrypted fields from the list view, which improves performance and reduces how often the data is displayed at all.

Recommendations

• Keep the default level.
• Do not treat slower as stronger.
• Benchmark before and after any change.
• Keep encrypted fields out of list views.