ActiveManage Docs ← Back to activemanage.co.uk

Encryption Levels Explained

When using the sodium engine for ActiveManage's data encryption, the Encryption Level setting trades performance for cryptographic strength. The four options represent different iteration counts in the underlying key-stretching algorithm.

What "iteration count" actually means

Modern symmetric encryption (used by ActiveManage for at-rest encryption of fields you mark Encrypt) uses a key derived from your master key plus per-record randomness. The derivation algorithm runs through many rounds of hashing — "iterations". More iterations means each encrypt or decrypt operation takes longer, but it also means a brute-force attacker has to do more work per guess.

The trade-off: every legitimate read takes slightly longer, but every illegitimate brute-force attempt also takes longer. Picking the right level depends on how concerned you are about the brute-force angle versus how much per-request latency you can afford.

The four levels in detail

php_l1 (very fast)

Minimal iteration count. Each encrypt/decrypt is essentially as fast as the underlying cypher allows — typically microseconds. Suitable for:

  • High-volume environments where the values are not deeply sensitive (e.g. short-lived API tokens).
  • Encryption purely for hygiene rather than against a determined adversary.
  • Systems where the encrypted value is also protected by other means (e.g. it lives in a database that's already on a private network behind a firewall).

php_l2 (fast)

Moderate iteration count. Slight slowdown over l1. Reasonable balance — strengthens against the most casual brute-force without significantly affecting throughput. Sensible default for general business use.

php_l3 (slow)

High iteration count. Noticeably slower per operation — operations that took microseconds on l1 take milliseconds on l3. Reserve for the most sensitive data:

  • Long-lived credentials that an attacker might genuinely target.
  • Archival data where read frequency is low so the latency doesn't matter.
  • Highly-regulated environments (healthcare, finance, government) where the audit trail will be examined.

am (ActiveManage standard, very fast)

The platform's own tuned default. Carefully chosen to give reasonable security without significantly affecting throughput. Recommended starting point for most installs — close to l1 performance but with slightly better security properties.

Real-world numbers

The actual time per operation depends on your hardware. To give a rough sense:

  • php_l1 / am: 0.1–0.5 milliseconds per encrypt/decrypt on modern server hardware.
  • php_l2: 1–5 milliseconds.
  • php_l3: 10–50 milliseconds.

For most apps the difference is invisible. For high-throughput APIs handling thousands of requests per second, the difference adds up — a path that encrypts and decrypts five fields per request at php_l3 would add 50–250ms per request, which is significant.

Pick per use case

If you have multiple kinds of sensitive data, set the level globally to your most common case. Then handle exceptions in code:

  • Highly-sensitive fields can be configured individually with stronger algorithms via Custom PHP Code rather than relying on the platform default.
  • Cheap fields can skip encryption entirely if they're not actually sensitive.

Screenshot of the Security section of Site Settings showing the Encryption Level dropdown with the four options (php_l1, php_l2, php_l3, am) and their performance descriptions

Note: Don't pick the highest level just because it sounds safer. Higher iteration counts trade real per-request latency for protection against a brute-force attacker who's already managed to exfiltrate your encrypted data. If your real threat model is data theft via something other than brute-force (insider threat, credential compromise, etc.) higher iteration counts don't help — focus on access controls and audit logs instead.