[Security Architecture] Encryption - Key Management Decides Encryption Strength

About this article

As the fourth installment of the “Security Architecture” category in the series “Architecture Crash Course for the Generative-AI Era,” this article explains encryption.

Modern systems are basically defended in 3 layers: at-rest, in-transit, and in-use. This article explains symmetric/public-key encryption, TLS, hashing, KMS, Envelope Encryption, and TDE - presenting the practical iron rule that encryption strength equals key-management strength.

What is encryption in the first place

Encryption is, roughly speaking, “the technology of converting data into an unreadable form so that only someone with the correct key can restore it.”

Imagine a wax seal on a letter. With a wax seal (encryption), even if someone peeks at it along the way, they can’t read the contents. However, if the signet ring (key) used to make the seal is stolen, anyone can open and forge it. Digital encryption works the same way: as long as the key is securely managed, the data is protected even though the algorithm itself is public. In other words, encryption strength equals key-management strength.

Designing on the premise of leakage - the inverted approach

Encryption isn’t “safe because it’s installed” - key management is everything. If keys leak, encryption is meaningless, and accidents of having “encrypted” while leaving keys in plaintext don’t stop happening.

Encryption strength equals key-management strength. The moment a key leaks, everything is neutralized.

Why it’s needed

1. Limit damage on leak

Even if the DB is stolen with backup and all, encrypted data can’t be read. Most info-leak news is caused by plaintext storage.

2. Regulation/law requirements

GDPR, Personal Information Protection Act, HIPAA, PCI DSS - all require encryption of personal info and credit-card info. Violations bring fines from hundreds of millions to billions.

3. Standard requirement for internet communication

Modern browsers warn against HTTP and require HTTPS. Plaintext transmission is effectively banned.

The 3 places of encryption

Encryption is classified into 3 by “where to defend.” In modern architecture, encrypting all 3 layers is standard.

flowchart LR
    USER([User])
    subgraph IN_TRANSIT["In Transit<br/>TLS 1.3 / mTLS"]
        NET[Encrypted communication path]
    end
    subgraph IN_USE["In Use<br/>TEE / homomorphic"]
        MEM[Computation in memory]
    end
    subgraph AT_REST["At Rest<br/>TDE / AES-256"]
        DB[(Encrypted DB)]
        FILE[(Encrypted file)]
    end
    USER -->|TLS| NET
    NET --> MEM
    MEM --> DB
    MEM --> FILE
    classDef user fill:#fef3c7,stroke:#d97706;
    classDef transit fill:#dbeafe,stroke:#2563eb;
    classDef use fill:#fae8ff,stroke:#a21caf;
    classDef rest fill:#dcfce7,stroke:#16a34a;
    class USER user;
    class IN_TRANSIT,NET transit;
    class IN_USE,MEM use;
    class AT_REST,DB,FILE rest;

Type	Target	Representative tech
At Rest	DB, files, backups	TDE (Transparent Data Encryption), AES-256
In Transit	Network communication	TLS 1.3, mTLS
In Use	In memory, during computation	TEE (Trusted Execution Environment, isolated execution area in CPU), homomorphic encryption

In-use encryption is still developing and hard to implement, but at-rest and in-transit are already established as standard tech and are required in modern systems.

Symmetric and public-key encryption

Two fundamental encryption principles where use cases differ. Either alone is insufficient; modern systems combine both.

	Symmetric key	Public key
Keys	One (shared)	Two (public/private)
Speed	Fast	Slow (1000x)
Key distribution	Hard	Easy
Representatives	AES-256	RSA, ECDSA
Use case	Bulk data encryption	Key exchange, signing

Modern TLS uses both - public-key encryption to safely exchange a symmetric key, and the body data encrypted with the fast symmetric key. This hybrid approach is standard.

TLS / HTTPS

The de facto standard for communication encryption - HTTPS is HTTP on TLS. Modern web has TLS 1.3 as the latest, with TLS 1.0/1.1 already deprecated, 1.2 as minimum, 1.3 as recommended.

Version	Status
SSL 3.0 and below	Banned (vulnerable)
TLS 1.0 / 1.1	Deprecated (major browsers ended support)
TLS 1.2	Minimum, backward-compatible
TLS 1.3	Recommended, fast, safe

TLS certificates can be obtained free via Let’s Encrypt, and managed services like CloudFront and ALB (Application Load Balancer, AWS L7 load balancer) auto-renew. Paid EV certificates have lost UX-improvement effect and are now mostly unnecessary.

Hashing (one-way functions)

A function that converts source data one-way, irreversibly - hashing. Used for password storage, tampering detection, and digital signatures. Often confused with encryption, but the fundamental difference is being non-decryptable.

Use case	Algorithm
Password storage	bcrypt, Argon2, scrypt
Tampering detection	SHA-256, SHA-3
Digital signature internal	SHA-256, SHA-384
Legacy (deprecated)	MD5, SHA-1

Using general hashes (SHA-256) for passwords is strictly forbidden. Too fast for brute force. Use “intentionally slow” hashes like Argon2 or bcrypt, and always add “salt” (a string different per user).

Key management (KMS)

The mechanism for safely managing keys - the heart of encryption - is KMS (Key Management Service). Holding keys plaintext on the app side is strictly forbidden; manage with dedicated hardware (HSM) or KMS. In cloud, it’s provided as a standard service.

Service	Characteristics
AWS KMS	AWS-integrated, cheap
Google Cloud KMS	GCP-integrated
Azure Key Vault	Azure-integrated, also Secret management
HashiCorp Vault	OSS, multi-cloud
Hardware HSM	FIPS 140-2 Level 3 compliant

Keys go through periodic rotation (auto-update) as the basis - KMS realizes this transparently.

Envelope Encryption

Envelope Encryption is the standard pattern for efficiently encrypting bulk data. The data is encrypted with a fast symmetric key, and that key itself is encrypted with the KMS key - a nested structure balancing safety and performance.

Data --- [DEK: Data Encryption Key] ---> Encrypted data
            │
            └── [KEK: KMS Key] ───> Encrypted DEK

Encrypting data using KMS directly is slow due to network round-trips, but with the Envelope approach, KMS is called only at the start and subsequent encryption is local. AWS S3 and BigQuery internals also use this approach.

For key management, leave it to KMS. Not holding keys app-side is the rule.

TDE (Transparent Data Encryption)

TDE is a feature where the DB itself automatically encrypts data, realizing at-rest encryption without app-side code changes. A standard feature of cloud DBs and enterprise DBs - just enabling it completes at-rest encryption.

DB	TDE support
PostgreSQL (managed)	Auto on RDS, Cloud SQL
SQL Server	TDE standard feature
MySQL	Supported from 8.0
Oracle	TDE standard feature
BigQuery, Snowflake	Always-on encryption by default

Many people misunderstand “encryption = TDE,” but TDE is only at-rest encryption - app-DB communication and in-app memory need separate measures.

Client-side encryption

A method that encrypts on the app side before sending to the server, creating a state where even the server can’t see plaintext. The “zero-knowledge designs” of LastPass, 1Password, Signal, and Proton Mail are this.

Pros	Cons
Safe even on server leak	Search/aggregate impossible server-side
True end-to-end	Key loss makes recovery impossible
Easy regulatory response	High implementation difficulty

For things like credit card numbers, passwords, and confidential memos, unless server-side decryption is needed, client-side encryption is worth considering.

Digital signatures and tampering detection

What guarantees data authenticity (it’s genuine) and integrity (not tampered) is the digital signature. An application of public-key encryption - the sender signs with the private key, the receiver verifies with the public key.

Use case	Example
Contracts	DocuSign, Cloud Sign
Code distribution	Code signing, software distribution
Container images	Cosign, Notary
SBOM (Software Bill of Materials)	Software composition attestation

In particular, signing container images (Cosign) has rapidly spread recently as a supply-chain-attack countermeasure.

Decision criteria

1. Sensitivity of data handled

Encryption strength is decided by data sensitivity. Strong encryption on public info is excessive, and weak encryption on personal info is criminal.

Data type	Recommended encryption
Public info	TLS only
General business data	TLS + TDE
Personal info	TLS + TDE + column-level encryption
Credit card info	PCI DSS-compliant, tokenization
Top secret/medical/finance	Above + HSM, client-side encryption

2. Cloud adoption level

Using cloud-managed KMS and TDE makes encryption standard-enabled. On-premises requires designing key management yourself, raising difficulty steeply.

Environment	Recommended
Full cloud	Standard managed KMS use
Hybrid	Vault + cloud KMS
On-prem-centric	Self-built HSM, key-management specialist needed
Top secret	FIPS 140-2 Level 3 HSM

How to choose by case

General web service / SaaS

TLS 1.3 + managed KMS + TDE-enabled. CloudFront/ALB for TLS termination, RDS/BigQuery TDE standard, passwords with Argon2. This alone covers 80% including regulatory response.

EC handling credit-card info

PCI DSS compliance + tokenization. Don’t store card numbers themselves in your DB - handle them with “payment-processor tokens” (e.g., tok_xxx) like Stripe or Adyen. Design so even if your DB leaks, card info doesn’t get out.

Password managers / secret-memo services

Client-side encryption (zero-knowledge). Server stores only ciphertext, decryption completes on user devices. Plaintext is protected even on server breach, but designing recovery procedures is the hardest part.

High-confidentiality data in finance/medical/government

FIPS 140-2 Level 3 HSM + column-level encryption + key audit logs. Each key access is left in audit logs, with key administrators separated by segregation of duties.

Encryption numerical gates and algorithm selection

Encryption isn’t “use it and OK” - you must correctly choose algorithms and parameters. Below are the standard values as of April 2026.

Use case	Recommended algorithm	NG / legacy
Symmetric-key encryption	AES-256-GCM (authenticated encryption)	AES-128-ECB, DES, 3DES
Public-key encryption	RSA 4096-bit / ECDSA P-256+	RSA 1024, DSA
Hash (password)	Argon2id (memory 64MB, time 2) / bcrypt cost 12+ / scrypt	MD5, SHA-1, SHA-256 alone
Hash (tampering detection)	SHA-256 / SHA-384 / SHA-3	MD5, SHA-1
TLS version	TLS 1.3 (or 1.2)	SSL / TLS 1.0 / 1.1 (all deprecated)
Random generation	CSPRNG (crypto.randomBytes etc.)	Math.random()
Key rotation frequency	90 days / immediate on leak	Permanent use
TLS cert expiry	90 days (Let’s Encrypt auto-renew)	1+ year manual
Post-quantum (future consideration)	ML-KEM / ML-DSA (NIST 2024 release)	-

“Argon2id (winner of the 2015 Password Hashing Competition)” is the standard for password hashing as of 2026. bcrypt remains usable, but Argon2id is the top candidate for new builds. “PBKDF2 used with old iteration counts” gets broken, so a minimum of 600,000 iterations (OWASP 2023 recommendation) is required.

The rule is don’t deviate one step from standard algorithms. Custom encryption is absolutely taboo.

Encryption-operation pitfalls and forbidden moves

Here are the typical accident patterns in encryption. All have the structure of leaking while thinking it’s encrypted.

Forbidden move	Why it’s bad
Hardcode keys in source	Permanently in Git history, picked up by bots in seconds on public repos
Place keys plaintext in .env and Git-commit	Same instant leak. Put in KMS / Secrets Manager
Implement custom encryption algorithms	Even security specialists avoid this. Lean on AES/TLS standard libraries
Hash passwords with MD5/SHA-1	Brute-forced instantly via GPU. Argon2id required
Hash without salt	Broken by rainbow tables. Use a unique salt per user
Run with TLS 1.0/1.1 enabled	Fails customer audits and finance certifications. TLS 1.2+, ideally 1.3
Don’t conduct key rotation	No insurance for “leak someday.” Auto-rotate every 90 days
Use AES ECB mode	Same landmine as the 2013 Adobe incident (150M passwords practically deciphered via ECB + same key + common hint field)
Old PBKDF2 iteration count	The 2022 LastPass leak put users with old iteration counts at higher risk. Adopt OWASP 2023’s 600,000+
Service stops on certificate expiry	Avoid via Let’s Encrypt + auto-renew. Manual management is an accident factory
Adopt AI-generated encryption code as is	AI can suggest old algorithms (MD5/DES). Always specialist review
”Safe because we encrypt” while neglecting key management	Keys hardcoded in source is a frequent accident
”Internal LAN doesn’t need encryption” complacency	In the Zero Trust era, mTLS is standard

The 2013 Adobe incident (about 150M passwords leaked “encrypted” but practically deciphered via ECB mode + common hint field) and the 2022 LastPass leak (encrypted vault copies taken, users with old PBKDF2 iteration counts at higher risk) drove home the lesson that “encrypted” and “protected” are different things.

Encryption has a deep gap between “installed” and “protected.” Key management decides everything.

AI decision axes

AI-era favorable	AI-era unfavorable
Managed KMS (auto-selection)	Self-built key-management code
TLS 1.3 standard settings	Manual encryption implementation
Code signing (Cosign)	Unsigned containers
Auto-rotation	Permanent fixed-key use

1. Encrypt in 3 layers — at-rest (TDE), in-transit (TLS 1.3), in-use, all handled managed
2. Entrust keys to KMS — don’t hold keys app-side, enable auto-rotation
3. Passwords with Argon2 / bcrypt + salt — SHA-256 alone is forbidden, adopt intentionally slow hashes
4. Specialist review of encryption code — don’t trust AI-generated as is, don’t deviate from standard libraries

Author’s note - cases where “encrypted” wasn’t actually protected

The story of “we’re encrypted so we’re fine” collapsing accounts for many recent large-scale leaks - a perennial industry talking point.

In the October 2013 Adobe info-leak incident, about 150M passwords were leaked “encrypted,” but multiple implementation flaws - same key, ECB mode, and common password-hint field - aligned, and ciphertext-pattern analysis practically deciphered them. A case told as the event that drove home to the world that “encrypted” and “protected” are different things.

Another, the 2022 LastPass info-leak incident, also left a heavy lesson. The encrypted password vault itself was taken, and it was later revealed that some users’ iteration counts (PBKDF2 repeats) remained at old settings, with low resistance to brute force. It became the trigger for the lesson “design must include not just ‘is it encrypted’ but ‘how slow a hash you used’” being widely shared.

I once left a test-purpose AES key in .env.example and pushed to Git, then got panicked half a year later when secret-scanning detected it. Since it wasn’t a production key, the damage was zero, but it was an event where I keenly felt that whether you can explain a key’s lifespan, path, and location matters. Both are lethal blows from “implementation laxness,” not flashy attacks - they slap home the lesson that encryption is “insufficient just to install.”

Mundane key-management mistakes always happen. Ask not “did you install it” but the key’s lifespan and path.

What to decide - what is your project’s answer?

For each of the following, try to articulate your project’s answer in 1-2 sentences. Starting work with these vague always invites later questions like “why did we decide this again?”

• Communication encryption (TLS 1.2/1.3, mTLS necessity)
• Storage encryption (TDE, KMS, column-level)
• Key management (KMS, Vault, HSM)
• Password hashing (Argon2 / bcrypt + salt)
• Key rotation (frequency, automation)
• Client-side encryption (necessity)
• Signing (code, container, contracts)

How to record decision reasons

Since encryption-method selection is always questioned in security audits and compliance, it’s essential to document selection reasons as an ADR (Architecture Decision Record).

Item	Content
Title	Adopt AWS KMS (CMK) for at-rest encryption
Status	Approved
Context	Storing personal data in Aurora PostgreSQL and S3. ISMS audit requires evidence of at-rest encryption and key management; want to automate key lifecycle management
Decision	Use AWS KMS Customer Managed Keys (CMK) with Envelope Encryption for at-rest encryption
Reasons	- Key auto-rotation (yearly) completes on KMS side, no application changes needed - CloudTrail auto-records key usage history, audit evidence can be submitted as-is - Native integration with Aurora, S3, EBS and other AWS services minimizes implementation cost
Rejected alternatives	AWS managed keys (aws/rds etc.) → can’t customize key policies or share across accounts. HashiCorp Vault → availability assurance and operational overhead are concerns for self-managed
Result	KMS API call charges incurred (thousands of yen/month~). Key policy design and IAM role least-privilege settings become additional tasks

ADRs should be stored in docs/adr/ alongside security policy documents, readily accessible during audits. The greatest value of an ADR is that “why this choice was made” is clear at a glance when revisited later.

Summary

This article covered encryption, including symmetric/public keys, TLS, hashing, KMS, Envelope Encryption, TDE, and the practical iron rule.

Encrypt in 3 layers, entrust keys to KMS, hash passwords with Argon2/bcrypt + salt, and have specialists review encryption code. That is the practical answer for encryption design in 2026.

Next time we’ll cover network security (FW, WAF, IDS/IPS, DDoS countermeasures).

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.