Encryption

Encryption inside ActiveManage is pluggable — you choose which underlying library handles the crypto operations. The choice mostly affects performance, supported algorithms, and which PHP extensions need to be available on the server.

Available Engines

• Sodium (recommended): Modern, fast, with sensible defaults. Bundled with PHP 7.2+. Supports XChaCha20-Poly1305, Curve25519, Ed25519.
• OpenSSL: Wider algorithm choice — AES-GCM in multiple key sizes, RSA, ECDSA across many curves. Useful when interoperating with non-PHP systems.
• mcrypt (legacy): Deprecated in PHP 7.2. Only enable for read-back compatibility with very old encrypted data; never use for new writes.

Choosing

• New deployment: Sodium. No exceptions.
• Need interoperability with Java/C# system using AES-GCM-256: OpenSSL.
• Migrating from a system that used mcrypt: Enable mcrypt-legacy for read access, write new records with Sodium, run a background task to re-encrypt old records.

Performance

Sodium is typically 1.5–3× faster than equivalent OpenSSL operations for small payloads (under 4KB). For bulk file encryption (multi-megabyte) OpenSSL's hardware AES support edges ahead on modern Intel/AMD CPUs.

Worked Examples

• Default greenfield app: Sodium throughout — encrypts session cookies, stored API tokens, sensitive datastore columns.
• FIPS-required environment: OpenSSL with the FIPS provider — required for some US government contracts.
• Migration project: Both engines enabled; legacy reads via mcrypt, all new writes via Sodium, weekly batch re-encrypts 100,000 rows.

Warning: mcrypt has known weaknesses and is unmaintained. Never expose it to user-controlled input — limit its use strictly to decrypting historical data.

Even within a given engine you choose a cipher — the algorithm and mode that does the actual encrypting. Choosing the right cipher matters for security, performance and compatibility.

Recommended Ciphers

• XChaCha20-Poly1305 (Sodium): Fast on all hardware (no AES-NI required), authenticated, 24-byte nonce reduces nonce-reuse risk.
• AES-256-GCM: Hardware-accelerated on modern CPUs, widely interoperable, 256-bit security level.
• AES-128-GCM: Slightly faster, 128-bit security level — fine for most use cases but choose 256 if you're encrypting data with a long lifetime.

Avoid

• AES-CBC without HMAC: Not authenticated; vulnerable to padding-oracle attacks. Acceptable only when paired with HMAC.
• AES-ECB: Reveals patterns in encrypted data. Never use.
• DES, 3DES, RC4: Cryptographically broken. The platform refuses these by default.

Use-Case Recommendations

• Database column encryption: XChaCha20-Poly1305 or AES-256-GCM.
• File-at-rest encryption: AES-256-GCM (hardware acceleration matters for large blobs).
• API token signing: Ed25519 (not encryption per se, but the signature scheme of choice).
• JWT signing: EdDSA over Ed25519, falling back to RS256 only when required by a third party.

Worked Examples

• Encrypting customer email addresses in the DB: XChaCha20-Poly1305 — fast, authenticated, no hardware dependency.
• Encrypting uploaded scans/IDs: AES-256-GCM — multi-megabyte files benefit from hardware AES.
• Long-term archive encryption (10+ years): AES-256-GCM — gives a comfortable margin against future advances.

Encrypting everything sounds great until performance dies. This article explains the encryption levels available, their performance impact, and how to choose what to encrypt.

Available Levels

• None: Data stored as plaintext. Default for public/non-sensitive columns.
• Column-level: Specific columns are encrypted (e.g. email, phone, address). Other columns remain queryable. Search still works on the unencrypted columns.
• Record-level: Entire records are encrypted as a blob. Queries can only filter on a small set of indexed metadata columns; deep search is impossible without decryption.
• Field + integrity hash: Column-level plus an HMAC stored alongside, catching tampering.

What to Encrypt

• Always: Passwords (hashed, not encrypted), API tokens, payment-instrument tokens, social security/national ID numbers, health records.
• Often: Email addresses, phone numbers, postal addresses, date of birth.
• Sometimes: Names (consider tradeoff with search), free-text notes (consider redaction instead).
• Rarely: Public profile fields, system metadata.

Performance Tips

• Keep decryption caches enabled — a 60-second per-process cache massively reduces re-decryption cost.
• Prefer column-level over record-level whenever search/filtering is needed.
• Don't encrypt a column that's used in WHERE clauses unless you're prepared for full-table scans.
• Batch decryption when fetching lists — single round-trip to the engine for N values is faster than N round-trips.

Worked Examples

• Healthcare app: Patient name, DOB, address, all medical notes — column-encrypted. Patient ID stays plaintext for indexing.
• Marketplace: Buyer/seller messaging encrypted; product titles and descriptions plain to allow search.
• Finance app: Account numbers and routing details column-encrypted with integrity hash. Transaction amounts plain to allow reporting.

Tip: Run a load test before turning on column-level encryption on a hot table. The 2× latency increase per read can saturate your DB if the workload isn't expected.