After almost a year of building enterprise key management systems at Thales, I’ve seen many encryption implementations - both good and bad. Encryption is often treated as a checkbox: “Is the data encrypted? Yes. Ship it!” But proper encryption is much more nuanced. Let me share what I’ve learned about implementing encryption correctly.
Encryption Is Necessary But Not Sufficient
The biggest misconception about encryption is that it solves all security problems. Organizations encrypt data and assume they’re secure, but encryption is just one component of a security strategy.
I’ve seen systems with strong encryption (AES-256) but weak key management (keys in configuration files). I’ve seen encrypted databases where the application has credentials to decrypt everything (so compromising the app gives access to all data). I’ve seen encrypted backups stored next to the encryption keys.
Encryption protects data confidentiality, but only if keys are properly managed, access controls are enforced, and the system is designed with security in mind end-to-end.
Choose Appropriate Algorithms
Not all encryption algorithms are created equal. Here’s what we recommend:
Symmetric encryption: AES-256 is the gold standard. AES-128 is also acceptable for most use cases - the theoretical weakness of 128-bit keys doesn’t represent a practical vulnerability. Avoid DES and 3DES - they’re legacy algorithms with known weaknesses.
Asymmetric encryption: RSA with 2048-bit keys minimum, 4096-bit for long-term protection. Elliptic curve cryptography (ECC) with 256-bit keys provides equivalent security to RSA-3072 with better performance.
Hashing: SHA-256 or better. Never use MD5 or SHA-1 for security-sensitive applications - both have known collision vulnerabilities.
Key derivation: PBKDF2, bcrypt, or scrypt for password-based key derivation. Never use simple hashing to derive keys from passwords.
These recommendations align with current NIST guidelines and industry standards. They may evolve as cryptographic research advances.
Understand Encryption Modes
Using AES isn’t enough - you need to choose the right mode of operation:
AES-GCM (Galois/Counter Mode): Our preferred mode for most use cases. Provides both confidentiality and authentication. GCM detects if ciphertext has been tampered with, preventing certain attacks.
AES-CBC (Cipher Block Chaining): Widely used but requires separate authentication (MAC). If you use CBC, you must implement encrypt-then-MAC, not MAC-then-encrypt or encrypt-and-MAC.
AES-ECB (Electronic Codebook): Never use this. ECB encrypts each block independently, which leaks patterns in plaintext. The famous ECB penguin image demonstrates this beautifully - you can still see the outline of the penguin even though the image is “encrypted.”
AES-CTR (Counter Mode): Good for parallel encryption/decryption but requires a nonce. Must be paired with authentication.
For most applications, start with AES-GCM. It’s secure, performs well, and provides authentication.
Generate Keys Properly
Key generation is critical. We’ve encountered several problematic approaches:
Weak random number generation: Using language-standard random number generators (like Java’s Random class) for cryptographic keys. These are predictable and must never be used for security. Use cryptographically secure random number generators (Java’s SecureRandom, /dev/urandom on Linux, CryptGenRandom on Windows).
Low-entropy sources: Generating keys in environments with low entropy (like virtualized servers at boot time) can produce weak keys. Ensure your system has sufficient entropy before key generation.
Derived keys with weak passwords: Deriving encryption keys from passwords like “password123”. If you must derive keys from passwords, use strong key derivation functions (PBKDF2, bcrypt, scrypt) with high iteration counts and require strong passwords.
The best approach: generate keys using hardware security modules (HSMs) or cloud provider KMS services. These use hardware entropy sources and are designed specifically for cryptographic key generation.
Implement Proper Key Rotation
Keys should have limited lifetimes. The longer a key is used, the more ciphertext an attacker can collect for cryptanalysis, and the more damage a compromised key can cause.
We implement key rotation at multiple levels:
Data encryption keys (DEKs): Rotated based on data sensitivity and volume. High-value data might have keys rotated monthly. Archive data might use keys that never rotate.
Key encryption keys (KEKs): Rotated on a regular schedule (quarterly or annually) independent of DEK rotation.
Master keys: Rotated annually or when personnel with access to them change.
Key rotation shouldn’t require re-encrypting all data immediately. With envelope encryption, you can rotate the KEK (re-encrypting the DEKs) without touching the data itself. DEKs are rotated opportunistically as data is accessed or modified.
Protect Keys at Rest and in Transit
Keys are more sensitive than the data they protect. Key protection requires multiple layers:
At rest: Keys should be encrypted when stored. Data encryption keys are encrypted by key encryption keys. Key encryption keys are stored in HSMs. Master keys never leave HSMs in plaintext.
In transit: Keys transmitted between systems must be protected. We use TLS with mutual authentication for key transport. The TLS session itself protects keys in transit, but we also encrypt keys under a transport key for defense in depth.
In use: This is the hardest part. Keys must be in plaintext to be used for encryption/decryption. We minimize the time keys exist in memory and use secure memory that can’t be swapped to disk.
Implement Proper Access Controls
Encryption doesn’t help if anyone can request decryption. We implement multiple access control layers:
Authentication: Verify the identity of entities requesting cryptographic operations. Use strong authentication (certificate-based, not just passwords).
Authorization: Not everyone who can authenticate should access all keys. Implement role-based or attribute-based access control.
Audit: Log all key access. Who requested decryption of what key, when, and was it approved or denied?
Separation of duties: Critical operations (like key deletion) require multiple approvals. No single person should have complete control over keys.
These controls are enforced by the key management system, not by applications. Applications can’t bypass them even if compromised.
Handle Encryption Failures Properly
Encryption operations can fail. Keys might be unavailable, HSMs might be overloaded, validation might fail. How you handle failures matters:
Fail closed, not open: If key validation fails, reject the operation rather than proceeding without encryption. It’s better to fail a transaction than leak sensitive data.
Log failures: Encryption failures might indicate attacks or system issues. Log them for investigation.
Retry with backoff: Transient failures (HSM timeout) can be retried. Use exponential backoff to avoid overwhelming recovering systems.
Provide meaningful errors: “Encryption failed” isn’t helpful for debugging. Provide enough detail to diagnose issues without leaking sensitive information in error messages.
Avoid Homegrown Crypto
“Don’t roll your own crypto” is standard advice, but what does it mean in practice?
Don’t invent algorithms: Use established algorithms (AES, RSA, etc.) that have been extensively analyzed by cryptographers.
Don’t implement algorithms yourself: Use vetted libraries (OpenSSL, Bouncy Castle, Java Cryptography Extension) rather than implementing AES yourself.
Don’t invent protocols: SSL/TLS, PGP, and other crypto protocols are the result of decades of research and attacks. Use them rather than inventing your own.
What you can (and should) do:
- Use crypto libraries correctly for your specific use case
- Implement key management workflows
- Build systems that use crypto appropriately
The distinction is between using cryptography and implementing cryptography. Most of us should be users, not implementers.
Consider Compliance Requirements
Encryption requirements often come from compliance:
PCI-DSS: Requires encryption of cardholder data with specific key management practices.
HIPAA: Requires appropriate encryption for ePHI, though specific requirements are flexible.
GDPR (coming soon): Will require encryption for personal data in many scenarios.
Industry-specific regulations add more requirements. Understand your compliance obligations and ensure your encryption approach satisfies them.
Compliance often requires:
- Specific algorithms and key lengths
- Regular key rotation
- HSM-based key storage
- Comprehensive audit logging
- Separation of duties
Design for compliance from the start; retrofitting is painful.
Encrypt at the Right Layer
Where should encryption happen? We’ve seen several approaches:
Application-layer encryption: Application encrypts data before storing it. Provides strong protection but requires application changes and key management integration.
Database encryption: Database handles encryption transparently. Easier to implement but DBA has access to keys. Transparent Data Encryption (TDE) falls into this category.
Storage encryption: Disk/volume encryption. Protects against physical theft but not logical access.
Network encryption: TLS protects data in transit but not at rest.
The best approach is often multiple layers. TLS for data in transit, application-layer encryption for sensitive fields, and storage encryption for defense in depth.
Plan for Key Compromise
Despite best efforts, keys can be compromised. Have a plan:
Detection: How will you know if a key is compromised? Audit logs might show unusual access patterns. Security investigations might reveal that an attacker had access to systems where keys were available.
Containment: Once compromise is detected, how do you limit damage? Revoke compromised keys immediately.
Recovery: Re-encrypt data with new keys. This is where key rotation infrastructure pays off - the process should already be in place.
Notification: Depending on compliance requirements and data sensitivity, you might need to notify affected parties.
Test your key compromise procedures before you need them. Simulating a compromise in a test environment reveals gaps in processes and tooling.
Performance Considerations
Encryption has performance costs. Some optimization strategies:
Use hardware acceleration: Modern CPUs have AES-NI instructions that dramatically accelerate AES encryption. Ensure your crypto library uses them.
Implement envelope encryption: Encrypt data with data keys, encrypt data keys with master keys. Most encryption happens with fast symmetric keys, not slow asymmetric crypto or HSM operations.
Cache decrypted keys: Once a data key is decrypted, cache it in memory for reuse. Balance security (shorter cache time) with performance (longer cache time).
Encrypt at appropriate granularity: Encrypting every field separately is slow. Encrypting entire databases together reduces security. Find the right balance for your use case.
Parallelize: Encryption can be parallelized. Use multiple threads to encrypt different chunks of data simultaneously.
Looking Forward
Encryption technology continues to evolving:
Post-quantum cryptography: Current asymmetric algorithms (RSA, ECC) will be vulnerable to quantum computers. NIST is working on post-quantum standards. For long-term data protection, start thinking about migration strategies.
Homomorphic encryption: Enables computation on encrypted data without decrypting it. Still mostly research, but could revolutionize cloud computing security.
Secure enclaves: Technologies like Intel SGX provide isolated execution environments where encryption keys can be used without exposing them to the OS. Promising for cloud environments.
Key Takeaways
For teams implementing encryption:
- Use established algorithms and vetted libraries - don’t roll your own
- Key management is as important as the encryption algorithm itself
- Choose appropriate encryption modes (prefer AES-GCM for most use cases)
- Generate keys with cryptographically secure random number generators or HSMs
- Implement key rotation from the start
- Enforce access controls at the key management layer
- Fail closed when encryption operations fail
- Plan for compliance requirements early
- Encrypt at multiple layers for defense in depth
- Have a plan for key compromise before it happens
Encryption is a powerful tool, but like any tool, it must be used correctly. The difference between secure encryption and ineffective encryption often comes down to implementation details and key management practices. Pay attention to these details, and encryption can provide strong protection for your organization’s sensitive data.