[Security Architecture] Encryption

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.

Why encryption matters

Steal the database, backups and all, and encrypted data still cannot be read. Most of the leaks that make the news trace back to storing things in plaintext. GDPR, data-protection law and PCI DSS all require personal and card data to be encrypted, and a violation brings fines in the hundreds of millions. Modern browsers warn on HTTP, so sending traffic in the clear is effectively prohibited.

What matters most is that encryption is not “safe because we installed it”: key management is the whole of it. Incidents where somebody believed they had encrypted the data while leaving the key sitting in plaintext keep on happening.

The three places encryption happens

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

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.

The basic toolkit

Symmetric and public keys — TLS is a hybrid of both

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

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.

On the wire, the de facto standard is TLS; HTTPS is simply HTTP carried over it. The 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.

TLS certificates can be obtained free via Let’s Encrypt, and managed services like CloudFront and ALB auto-renew. Paid EV certificates have lost UX-improvement effect and are now mostly unnecessary.

Hashing — for passwords, use something deliberately slow

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.

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).

KMS and envelope encryption — the app never holds the key

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

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

For large volumes of data, envelope encryption is the standard pattern.

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 and client-side 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.

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

Where stronger protection is required, as in a password manager or a confidential-notes service, you can encrypt on the client before sending.

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.

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

A related tool is the digital signature, used for tamper 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.

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

How to choose — sensitivity, and the numeric gates on algorithms

The strength of encryption is decided by how sensitive the data is. Public information gets TLS only; ordinary business data gets TLS plus TDE; personal data adds column-level encryption; card data is handled through PCI DSS-compliant tokenisation — payment-processor tokens from Stripe and the like, with no card number in your own database. Top-secret data in finance and healthcare goes up to an HSM plus client-side encryption. If you are fully on cloud, managed KMS plus TDE lets you turn encryption on by default and covers around 80% of the regulatory requirement.

Standard values as of April 2026.

“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.

Three scenarios

If you are building solo or at a startup

TLS 1.3, a managed KMS and TDE switched on. Terminate TLS at CloudFront or an ALB, leave TDE on for RDS or BigQuery as it comes, and hash passwords with Argon2id. That alone covers most of what you need, regulatory response included, and it costs almost nothing.

Personal / Startup: Ship in One Month Is Correcten.senkohome.com/arch-intro-case-startup/

If you are a small or mid-size SaaS

The same baseline plus column-level encryption for personal data, and tokenisation the moment card data appears. Do not put card numbers in your own database; hand them to Stripe or Adyen and keep only the token. Design it so that a database leak does not leak card data, and PCI DSS scope shrinks dramatically.

Small-Mid SaaS - Lean on Managed and Run with Few Peopleen.senkohome.com/arch-intro-case-saas/

If you are a large or regulated enterprise

A FIPS 140-2 Level 3 HSM, column-level encryption and audit logs on every key access, with key administrators separated under segregation of duties. Where confidentiality demands it, client-side encryption keeps even your own servers from seeing plaintext. The price is that search and aggregation become impossible and a lost key means unrecoverable data, so the recovery procedure is the hardest part of the design.

Large-Enterprise Core: Design That Holds Up for Yearsen.senkohome.com/arch-intro-case-enterprise/

AI decision axes — Let the AI write the wrapper code and nothing else

Why you shouldn’t have AI write encryption code

AI can write the “usage” of encryption, but its judgment on whether the “usage is correct” can’t be trusted. For example, when generating AES encryption code, it may produce code using ECB mode (a dangerous mode where identical plaintext blocks produce identical ciphertext) or code with fixed initialization vectors (IVs).

For encryption, the principle is “only have AI write KMS/SDK calling code.” Wrapper code like AWS KMS encrypt/decrypt calls, TLS certificate configuration, and bcrypt hash calls can be safely delegated to AI. Having AI write encryption algorithm implementations or key-generation logic should be avoided.

Declare KMS auto-rotation settings in IaC

AWS KMS key-rotation settings are just one line addition in Terraform, but without that line, keys stay fixed permanently. When having AI write Terraform code, it may create the KMS resource but omit rotation settings. A CI tfsec rule that detects “KMS key without rotation setting” is effective.

Pitfalls and forbidden moves

Here are the six most dangerous instances of the pattern “leaking while believing it was encrypted”.

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)

Write your answers down as an ADR. A concrete guide to writing them is here.

[DevOps Architecture] Documentationen.senkohome.com/arch-intro-devops-docs/

Related Articles

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.