Advanced

Homomorphic Encryption Best Practices

Practical guidance for deciding when to use HE, designing FHE-friendly models, choosing security parameters, and deploying encrypted ML in production.

When to Use HE

HE is the right choice when:

  • Single-server outsourced computation: A client wants to offload computation to a server without trusting it with plaintext data. This is the classic HE use case.
  • Regulatory data sovereignty: Data must remain encrypted at all times, even during processing, to satisfy regulatory requirements.
  • Non-interactive computation: The data owner cannot be online during computation (unlike MPC which requires interaction).
  • Small to medium models: Logistic regression, small neural networks, decision trees, and random forests are practical today.

Consider alternatives when:

  • Multiple parties need to collaborate: Use MPC instead — it is more efficient for multi-party scenarios.
  • You only need to protect the output: Use differential privacy — it is orders of magnitude faster.
  • You can trust the hardware: Use TEEs (SGX, TrustZone) — they are much faster than HE.
  • Large models (LLMs, large CNNs): Current HE technology cannot handle these efficiently.

Model Design for FHE

  1. Start with a Standard Model

    Train your model normally with standard activations and architectures. Establish baseline accuracy.

  2. Replace Activations

    Swap ReLU with polynomial activations (x² or degree-3/5 polynomials). Retrain and check accuracy.

  3. Reduce Depth

    Use fewer layers. Prefer wide, shallow architectures over deep, narrow ones. Each additional layer adds multiplicative depth.

  4. Fold Operations

    Merge batch normalization into linear layers. Precompute any constant operations.

  5. Quantize

    If using Concrete ML / TFHE, quantize the model. Lower bit-widths run faster under FHE.

  6. Compile and Test

    Compile the model for FHE, run encrypted inference, and verify that accuracy is within acceptable bounds.

Security Parameter Selection

⚠
Critical: Never choose HE parameters below 128-bit security. Use the Homomorphic Encryption Standard recommended parameters. Do not reduce security levels for performance — instead, optimize your circuit or model architecture.
  • Follow the Homomorphic Encryption Standard (homomorphicencryption.org) for parameter recommendations
  • Use at least 128-bit security level
  • Validate parameters with the lattice estimator tool
  • Account for key switching and rotation key sizes in your system design
  • Plan for key management: generation, distribution, storage, and rotation

Production Deployment

Architecture

  • Client-side: Key generation, encryption, decryption. Keep secret keys on client devices only.
  • Server-side: Encrypted computation with public keys and evaluation keys. No access to secret keys.
  • Communication: Ciphertexts are large (MBs). Use compression and streaming for network transfer.

Key Management

  • Generate keys on the client side only
  • Transmit only public keys and evaluation keys to the server
  • Implement key rotation policies
  • Store secret keys in hardware security modules (HSMs) when possible

Testing

  • Always test with simulated FHE first (faster iteration)
  • Compare FHE inference results against plaintext to verify correctness
  • Benchmark with production-size inputs, not toy examples
  • Test failure modes: What happens with out-of-range inputs?
✅
The future of HE: Performance improves roughly 10x every 2-3 years through better algorithms, compiler optimizations, and hardware accelerators. Models that are too expensive to run under HE today may become practical in 2-3 years. Design your system architecture to be HE-ready even if you use a different PET today.