Zero-Knowledge Encryption Explained

Editor's note (2026-10-15): HeliosDB Nano ships zero-knowledge encryption: keys are derived and data encrypted on the client, the server never sees plaintext keys. ZKE for HeliosDB Lite is planned. FIPS 140-3 is an opt-in fips build feature in Nano and Lite; HeliosDB Full has no FIPS mode, and FIPS-validated cryptography for it is on the roadmap. Post-quantum cryptography, encryption at rest, ABAC, single sign-on and LDAP for HeliosDB Full are planned. In Nano, when TLS is enabled, the PostgreSQL and MySQL listeners offer the X25519MLKEM768 post-quantum key exchange by default. The SQL and Rust samples below show the 2025 design; see the Nano encryption guide and FIPS compliance for current usage.

What if even your database server couldn't read your data? That's the promise of Zero-Knowledge Encryption (ZKE) — a client-side encryption model where data is encrypted before it leaves your application, and the database never has access to the decryption keys. HeliosDB implements ZKE with transparent column-level encryption that works with standard SQL.

Why Zero-Knowledge?

Traditional Transparent Data Encryption (TDE) encrypts data at rest on disk, protecting against physical theft of storage media. But the database server holds the encryption keys, which means anyone with server access (administrators, operators, attackers who compromise the server) can read all data.

ZKE flips this model: the application holds the keys, and the database processes encrypted data. Even a fully compromised database server reveals nothing.

How It Works

Traditional TDE:
  App → [plaintext] → Database Server → [encrypt] → Disk
  Risk: Server-side access reveals plaintext

Zero-Knowledge Encryption:
  App → [encrypt] → Database Server → [ciphertext] → Disk
  Safety: Server never sees plaintext, keys never leave the app

Encryption Algorithms

HeliosDB supports two authenticated encryption algorithms, selectable per column:

pub enum Algorithm {
    Aes256Gcm,           // AES-256-GCM: Hardware-accelerated, FIPS approved
    ChaCha20Poly1305,    // ChaCha20: Software-optimized, constant-time
}

pub enum KdfType {
    Pbkdf2,              // PBKDF2-HMAC-SHA256: FIPS-approved, fast
    Argon2id,            // Argon2id: Memory-hard, recommended for passwords
}

AES-256-GCM (default) provides authenticated encryption with 256-bit keys, hardware-accelerated via AES-NI instructions on modern CPUs. Each encryption operation generates a random nonce and produces an authentication tag, ensuring both confidentiality and integrity.

ChaCha20-Poly1305 is the software-optimized alternative, providing constant-time operations that resist timing side-channel attacks. Recommended for environments without AES hardware acceleration (ARM, embedded).

Key Derivation

Master encryption keys are derived from user-provided passphrases using memory-hard key derivation:

-- Set up column-level encryption
ALTER TABLE patients
  ADD COLUMN ssn_encrypted ENCRYPTED(
    algorithm = 'aes256gcm',
    kdf = 'argon2id'
  );

-- Application provides the key at connection time
SET heliosdb.encryption_key = 'your-256-bit-key-here';

-- Queries work transparently
INSERT INTO patients (name, ssn_encrypted) VALUES ('Jane', '123-45-6789');
SELECT name, ssn_encrypted FROM patients WHERE id = 1;
-- ssn_encrypted is automatically decrypted client-side

Secure Memory Handling

All sensitive data in HeliosDB is wrapped in Zeroize-implementing types, which overwrite memory on drop:

use zeroize::Zeroize;

pub struct EncryptionKey {
    key: Vec<u8>,  // 32 bytes for AES-256
    // When this struct is dropped, key bytes are
    // overwritten with zeros before deallocation
}

impl Drop for EncryptionKey {
    fn drop(&mut self) {
        self.key.zeroize();  // Guaranteed zeroing
    }
}

FIPS 140-3 Compliance

For regulated industries (healthcare, financial, government), HeliosDB supports FIPS 140-3 compliant cryptography via AWS-LC (Certificate #4816):

# Build with FIPS-compliant crypto provider
cargo build --no-default-features --features fips,encryption

# Standard build uses ring (faster, not FIPS)
cargo build --features ring-crypto,encryption

Post-Quantum Cryptography

A post-quantum cryptography (PQC) module for HeliosDB Full is planned, for organizations concerned about quantum computing threats to current encryption. It is designed around lattice-based and code-based algorithms that are resistant to quantum attacks.

HeliosDB Nano ships zero-knowledge encryption: keys are derived and data encrypted on the client, the server never sees plaintext keys. ZKE for HeliosDB Lite is planned. The FIPS 140-3 mode is an opt-in build feature in Nano and Lite.

← Back to Blog