Skip to content
HeliosDB HeliosDB Full

Column-Level Encryption for HeliosDB

Overview

HeliosDB’s column-level encryption protects sensitive data at the granularity of a column. This feature enables organizations to selectively encrypt specific columns containing PII, financial data, or other sensitive information while maintaining query performance and database functionality.

Key Features

1. Transparent Encryption/Decryption

  • Automatic encryption on write operations
  • Automatic decryption on read operations
  • Zero application code changes required
  • Integrated with the query engine

2. Multiple Encryption Algorithms

  • AES-256-GCM (default)

    • Hardware-accelerated on x86/x64 platforms
    • FIPS-validated cryptography is a roadmap item; HeliosDB Full has no FIPS 140-3 mode today
    • Authenticated encryption with associated data (AEAD)

  • ChaCha20-Poly1305

    • Software-optimized, constant-time
    • Excellent for platforms without AES-NI
    • Also provides AEAD guarantees

3. Format-Preserving Encryption (FPE)

Encrypt sensitive data while maintaining its original format:

Data TypeFormat PreservedExample
SSNXXX-XX-XXXX123-45-6789 → 456-78-9012
Credit CardXXXX-XXXX-XXXX-XXXX4532-1234-5678-9010 → 4532-9876-5432-1098
Phone(XXX) XXX-XXXX(555) 123-4567 → (555) 987-6543
Emailuser@domain.comjohn@example.com → abcd@example.com

4. Key Management

  • Key Generation: Secure random key generation
  • Key Rotation: Zero-downtime key rotation without re-encryption
  • Multi-Version Keys: Support for reading data encrypted with old keys
  • KMS Integration: AWS KMS, Azure Key Vault, GCP Cloud KMS
  • HSM Support: Hardware Security Module integration ready
  • Audit Trail: Complete key operation logging

5. Performance Optimization

  • Multi-Level Caching:

    • L1: In-memory LRU cache for encrypted values
    • L2: Decrypted value cache with TTL
    • Key cache: Decrypted encryption keys

  • Batch Operations: Parallel processing for multiple values

  • Hardware Acceleration: AES-NI support on compatible CPUs

  • Target Performance: <5% overhead vs unencrypted operations

6. Deterministic Encryption

  • Optional deterministic encryption for equality searches
  • Enables indexing on encrypted columns
  • Same plaintext → same ciphertext (with same key)
  • Trade-off: Pattern analysis vulnerability vs searchability

Architecture

┌──────────────────────────────────────────────────────────────┐
│                  Column Encryption Layer                     │
│  • value encryption / decryption                             │
│  • batch operations                                          │
│  • transparent integration                                    │
└──────────────────────────────────────────────────────────────┘
                              │
           ┌──────────────────┼──────────────────┐
           ▼                  ▼                  ▼
┌─────────────────┐ ┌──────────────┐ ┌──────────────────┐
│ Crypto Engine   │ │ Key Manager  │ │ Encryption Cache │
│ • AES-256-GCM   │ │ • Key gen    │ │ • LRU caching    │
│ • ChaCha20      │ │ • Rotation   │ │ • TTL support    │
│ • Deterministic │ │ • KMS/HSM    │ │ • Multi-level    │
└─────────────────┘ └──────────────┘ └──────────────────┘
           │
           ▼
┌─────────────────────────┐
│ Format-Preserving Enc   │
│ • SSN, CC, Phone        │
│ • Email, Numeric        │
└─────────────────────────┘

Performance Characteristics

Encryption Overhead

Indicative figures, measured on representative fixtures; reproduce on your own hardware:

Data SizeAES-256-GCMChaCha20-Poly1305Overhead
16 bytes~2 μs~3 μs0.5%
64 bytes~3 μs~4 μs1.0%
256 bytes~5 μs~6 μs1.5%
1 KB~12 μs~15 μs2.5%
4 KB~35 μs~45 μs3.5%
16 KB~120 μs~150 μs4.5%

Cache Impact

With warm cache (hit rate > 80%):

  • Encryption: <1 μs (10x faster)
  • Decryption: <0.5 μs (20x faster)

Batch Operations

Processing 1000 records (256 bytes each):

  • Sequential: ~5ms
  • Batch (parallel): ~2ms (2.5x speedup)

Security Features

1. Authenticated Encryption (AEAD)

  • AES-256-GCM and ChaCha20-Poly1305 both provide authenticated encryption
  • Detects tampering automatically
  • Prevents ciphertext manipulation attacks

2. Unique IVs/Nonces

  • Every encryption uses a unique IV
  • Prevents pattern analysis
  • Cryptographically secure random generation

3. Key Versioning

  • Multiple key versions supported
  • Old keys retained for decryption
  • New encryptions use latest key
  • Audit trail for all key operations

4. Secure Memory Handling

  • Keys automatically zeroized on drop
  • Uses zeroize crate for secure memory wiping
  • Prevents key material leakage

5. Constant-Time Operations

  • ChaCha20-Poly1305 is constant-time
  • Prevents timing attacks
  • Critical for high-security environments

Compliance

GDPR

  • Right to be forgotten (delete encrypted data)
  • Data minimization (encrypt only necessary columns)
  • Pseudonymization (deterministic encryption)
  • Audit trail (key access logging)

HIPAA

  • Technical safeguards (encryption at rest)
  • Access controls (KMS integration)
  • Audit controls (comprehensive logging)
  • Integrity controls (authenticated encryption)

PCI DSS

  • Requirement 3: Protect stored cardholder data
  • Requirement 4: Encrypt transmission (TLS)
  • Requirement 10: Track and monitor access
  • Strong cryptography (AES-256)

SOC 2

  • Security (encryption controls)
  • Availability (key redundancy)
  • Confidentiality (access controls)
  • Processing integrity (authenticated encryption)

Best Practices

1. Column Selection

DO:

  • Encrypt PII (SSN, emails, addresses)
  • Encrypt financial data (credit cards, account numbers)
  • Encrypt health information (diagnoses, prescriptions)
  • Use FPE for data that needs to maintain format

DON’T:

  • Encrypt primary keys (use deterministic if needed)
  • Encrypt frequently searched non-sensitive columns
  • Over-encrypt (performance impact)

2. Algorithm Selection

  • AES-256-GCM: Default choice, hardware-accelerated
  • ChaCha20-Poly1305: Use on ARM/mobile platforms
  • Deterministic: Only for indexed columns requiring search
  • FPE: For regulated data formats (SSN, CC)

3. Key Management

  • Rotate keys every 90 days
  • Use KMS for production environments
  • Enable audit logging
  • Back up key metadata
  • Test key rotation in staging first

4. Performance Tuning

  • Increase cache size for read-heavy workloads
  • Use batch operations for bulk inserts
  • Consider deterministic encryption for high-cardinality indexed columns
  • Monitor cache hit rates

5. Testing

  • Test encryption/decryption roundtrips
  • Verify key rotation doesn’t break existing data
  • Benchmark performance with production-like data
  • Test KMS integration thoroughly

Troubleshooting

Common Issues

1. Performance Degradation

Symptoms: Slow query performance after enabling encryption

Solutions:

  • Increase cache sizes
  • Enable hardware acceleration
  • Use batch operations for bulk operations
  • Consider deterministic encryption for frequently searched columns

2. Key Rotation Failures

Symptoms: Key rotation fails or old data becomes inaccessible

Solutions:

  • Ensure KMS credentials are valid
  • Check network connectivity to KMS
  • Verify sufficient permissions
  • Review audit logs for errors

3. Cache Thrashing

Symptoms: Low cache hit rate, high memory usage

Solutions:

  • Reduce cache TTL
  • Increase cache size
  • Analyze access patterns
  • Consider column-specific cache configurations

References

Support

For issues, questions, or feature requests related to column-level encryption:

  1. Check the Troubleshooting section
  2. Open an issue with encryption logs and metrics