Locked in the Cupboard, Sealed on the Road: Encryption, Hashing, TLS and PKI Explained

The payroll file is safe in a locked cupboard. Only the payroll team has the key. Then someone needs to send the file to a manager in another office, so the file is attached to an ordinary email. The cupboard did its job perfectly, yet the document became exposed the moment it started travelling.

This small scene explains why 'the data is encrypted' is never a complete design answer. We need to ask which data, at which stage, under which key, against which threat, and who can decrypt it. A database setting may protect a stolen disk while doing nothing for a copied report, a compromised application process, or traffic leaving an unprotected endpoint.

The payroll document will give us one clean journey: it is created, processed, stored, transmitted, verified, backed up, and eventually deleted. At every stage we ask four questions: who can read it, who can change it, how would tampering be detected, and where are the keys?

Protection must follow the data through its lifecycle; securing one storage location is not the same as securing the information.

Read the visual from creation to deletion. Notice when plaintext appears inside an authorised process, when ciphertext is stored, when a protected channel begins and ends, and where backups create another copy. The memory target is the changing state of the same document.

At Rest, In Transit, and In Use

Data at rest is stored rather than actively moving between systems: database rows, object storage, disks, snapshots, backups, exported reports, and archived files. At-rest encryption can reduce exposure when media, snapshots, or storage layers are accessed outside the intended path. Its protection depends on where decryption keys and permissions live.

Data in transit moves across a network boundary: browser to API, service to service, database client to server, or backup process to remote storage. TLS can provide confidentiality, integrity, and authenticated endpoint properties for that connection when it is configured and validated correctly.

Data in use is being processed. The payroll application must eventually decrypt a salary amount to display or calculate with it. If the authorised process, host, browser, or administrator is compromised, storage and transport encryption may already have ended. Minimising exposed fields, isolating workloads, controlling access, and avoiding sensitive logs matter at this stage.

What this table is telling you is that the same field crosses several protection boundaries. A team that encrypts object storage should also ask how presigned access works, what appears in logs, where backups go, and which application role can decrypt. The storage lifecycle in Object Storage Explained provides useful context for those copies.

Encoding, Encryption, and Hashing Solve Different Problems

Encoding changes representation so systems can store or transmit data in an expected format. Base64 can represent binary bytes as text, but anyone can reverse it without a secret. Encoding provides compatibility, not confidentiality. Calling Base64 'encryption' is like putting the payroll file in a transparent folder and celebrating that it has packaging.

Encryption transforms plaintext into ciphertext using a cryptographic algorithm and key. An authorised party with the right key and parameters can recover the plaintext. Modern authenticated encryption can also detect tampering. Encryption exists primarily to protect confidentiality within a defined key and trust boundary.

Hashing produces a fixed-length digest from input. A cryptographic hash is designed so that reversing the digest or finding useful collisions is infeasible under its security assumptions. It is not decryption with a missing key. Hashes support integrity checks, content addressing, signatures, and specialised password-verification designs, but the surrounding protocol decides what a digest proves.

What this table is telling you is to begin with the question, not the algorithm. If another system merely needs bytes represented as text, encode. If an authorised party must later recover a secret value, encrypt. If you need a digest for comparison or as part of an authenticity mechanism, hash - while checking whether a plain hash is actually enough.

Symmetric, Asymmetric, and Hybrid Cryptography

Symmetric encryption uses the same secret key, or closely related secret material, for encryption and decryption. It is efficient for bulk data. The hard part is safe key distribution and lifecycle: every party that can decrypt holds power that must be protected, rotated, audited, and eventually removed.

Asymmetric cryptography uses a public and private key relationship. The public key can be distributed, while the private key remains protected. Depending on the scheme, this supports digital signatures, key establishment, or encryption for a recipient. It is computationally heavier and does not remove the need to trust how a public key is associated with an identity.

Real secure channels use a hybrid. Authenticated asymmetric mechanisms help establish identity and shared secret material. Both endpoints derive short-lived symmetric traffic keys. Efficient authenticated symmetric encryption then protects application data. This combines asymmetric trust/key-establishment properties with symmetric performance.

Analogy limit: a public padlock that anyone can close is useful for intuition, but modern key agreement, signatures, nonces, forward secrecy, and authenticated encryption have no exact physical equivalent.

Read the diagram in sequence. First authenticate and establish shared secret material. Then derive temporary symmetric keys. Only then follow the larger stream of protected application data. Remember that the mechanisms have different jobs rather than competing for one universal job.

Authenticated Encryption, Nonces, and Context

Encryption without integrity can allow an attacker to alter ciphertext in ways that produce meaningful changes after decryption. Modern designs prefer authenticated encryption, which produces ciphertext plus an authentication tag. Decryption succeeds only when the key, nonce, ciphertext, tag, and any authenticated context match. Tampering becomes detectable rather than silently becoming corrupted plaintext.

A nonce or initialization value is not normally a password. It is a value used under the algorithm's rules so repeated encryption does not create unsafe repetition. Some modes require the nonce never to repeat under the same key; reuse can destroy confidentiality or authenticity. The safest application approach is to use a maintained high-level cryptographic library that generates and stores parameters correctly, not invent a nonce counter casually.

Associated data can authenticate context without encrypting it. An encrypted payroll record may authenticate the employee ID, schema version, tenant, and field purpose so ciphertext cannot be copied into a different record unnoticed. This helps bind data to its intended place, but visible associated data must not contain secrets simply because it participates in the tag.

The stored object therefore needs more than ciphertext: algorithm/version information, nonce, tag, key reference or wrapped key, and any context needed for decryption. Versioning is essential when algorithms or key strategies change. 'Encrypted string' is not a self-describing format that will remain recoverable forever.

Password Hashing: Verification Without Recovery

A password should be verified, not recovered. At registration the server creates a unique salt, applies a purpose-built slow password-hashing function with recorded work parameters, and stores the resulting verifier. At login it repeats the operation with the candidate password and compares the result. The original password is never decrypted because no encrypted copy is required.

The salt prevents identical passwords from producing one reusable stored result and defeats broad precomputed tables. It is not normally secret. A pepper, if used, is separate secret material and creates its own availability and rotation burden. The main defence is a memory-hard or deliberately expensive password-hashing function such as Argon2id under current guidance, not a fast general-purpose hash.

Slow hashing raises the cost of offline guessing after a verifier leak. It does not stop online login attempts, phishing, session theft, weak recovery, or credential reuse. Those need rate controls, MFA, breached-password checks, secure sessions, monitoring, and user recovery design. The wider identity flow is covered in the authentication and authorization draft; the cryptographic memory line here is simply: verify with a slow salted function, never decrypt.

Hash, HMAC, and Digital Signature

Suppose the payroll file arrives with a hash published beside it. Recomputing the hash can reveal whether the bytes match that digest, but if an attacker can replace both file and hash, the comparison proves very little. A plain hash has no secret and does not identify who produced it.

A hash-based message authentication code, or HMAC, combines the message with a shared secret. Parties holding that secret can create and verify the authenticator. It protects integrity and authenticity against outsiders, but every verifier with the shared secret may also be able to create a valid HMAC. That shared capability matters for audit and dispute.

A digital signature is created with a private key and verified with the corresponding public key. Many verifiers can check the signature without gaining the ability to sign. The signature authenticates the signed bytes under the key relationship; it does not encrypt the content, prove the signer was uncompromised, or stop replay unless the protocol includes context such as nonce, timestamp, transaction ID, and intended audience.

What this table is telling you is to ask who may create proof and who may verify it. That key-ownership question often determines whether a shared HMAC or public-key signature fits the system better than an algorithm comparison does.

Read all three lanes using the same message. The hash lane has no key, the HMAC lane shares one secret among approved parties, and the signature lane separates private signing from public verification. Remember the verifier's power.

Pause and retrieve

Without looking back, explain why Base64 does not hide a salary, why a signed message is not necessarily secret, and why a valid hash beside a downloaded file may be unhelpful if the attacker replaced both.

TLS 1.3: Authenticate, Agree, Derive, Then Protect

When a browser opens an HTTPS connection, it does more than receive a server key and encrypt one permanent session key with RSA. Modern TLS 1.3 negotiates supported parameters, authenticates the server through its certificate and signature, performs ephemeral key agreement, derives shared secrets and traffic keys, and then protects application records with symmetric authenticated encryption.

1. The client sends supported protocol and cryptographic parameters plus key-agreement material.

2. The server selects parameters, sends its key-agreement material, and presents a certificate chain and proof tied to the handshake.

3. The client validates the chain, hostname, validity, signature, and trust policy.

4. Both sides derive shared handshake and application secrets without sending the resulting traffic keys directly.

5. Encrypted, integrity-protected HTTP data flows under short-lived symmetric traffic keys.

6. Resumption can reduce later work while introducing its own ticket and replay considerations.

Ephemeral key agreement supports forward secrecy: later compromise of a long-term authentication key should not automatically decrypt previously recorded sessions, assuming the ephemeral secrets were erased and the protocol was used correctly. This is a stronger mental model than 'the server has one key that encrypts everything forever'.

TLS protects the connection between two termination points. A CDN, load balancer, reverse proxy, or API gateway may terminate one connection and establish another downstream. The system design must state each hop, how the next endpoint is authenticated, and where plaintext can appear. Protocols in System Design provides the broader request journey for these boundaries.

Current OWASP TLS guidance recommends TLS 1.3 by default and TLS 1.2 where needed, with old SSL and TLS versions disabled. Configuration also includes certificate renewal, strong protocol choices, redirect/cookie behavior, mixed content, monitoring, and safe failure before expiration.

Read the six numbered stages, then follow the separate trust chain from server certificate to issuing authority and trusted root. The memory line is four verbs: authenticate, agree, derive, protect.

Certificates, CAs, PKI, and mTLS

A passport does not make its holder honest; it binds an identity claim to a document under an issuing authority and verification process. A digital certificate similarly binds a public key to names or identity information under a certificate authority's signature and policy. The client trusts selected root authorities and validates the chain presented by the server.

The client also checks that the requested hostname is covered, the certificate is valid for the current time, required usages fit, signatures verify, and local trust policy accepts the chain. Expiration limits lifetime but creates renewal risk. Revocation mechanisms exist but have deployment and availability tradeoffs, so short lifetimes and automated renewal are common parts of modern operations.

In ordinary server-authenticated TLS, the server presents a certificate and the client is authenticated later through application mechanisms. In mutual TLS, both sides present certificate-based identity during the transport handshake. This can give services strong workload identity and encrypted channels. It does not answer whether the authenticated service may refund this order, read this tenant, or call this endpoint; application authorization still decides.

Certificate operations are a reliability concern too. Inventory every certificate and owner, automate issuance and renewal, monitor well before expiry, test the complete chain clients actually receive, and rotate private keys under controlled rollout. A server may appear healthy to an internal probe while external clients reject an expired certificate or missing intermediate.

Trust stores and private CAs create governance work. Which roots are trusted, which names may be issued, how is a compromised issuer contained, and how quickly can workloads receive a replacement? Short-lived workload certificates can reduce reliance on revocation, but require highly available automated issuance and identity attestation.

Key Management and Envelope Encryption

Encrypting a database while placing an unrestricted raw key in the same application configuration is like locking the cupboard and leaving its key in the door. Cryptography moves the problem toward key management: creation, storage, distribution, authorization, use, rotation, backup, revocation, destruction, audit, and availability.

A key management service, or KMS, protects master or key-encryption keys behind policy and audit. A hardware security module, or HSM, can provide a hardened boundary for sensitive key operations. Neither removes design work. The team still decides which identity may request which operation, which region or service owns the key, how rotation works, and what happens during KMS or network failure.

Envelope encryption uses a data-encryption key to encrypt the payroll file. That data key is then encrypted, or wrapped, under a separately controlled key-encryption key in KMS. The application stores ciphertext plus the wrapped data key. To decrypt, an authorised workload asks KMS to unwrap the data key, uses it briefly, and should avoid persisting plaintext key material. Many objects can have separate data keys without exposing the KMS master key.

Rotation has two different meanings. Rotating the KMS key used for new wrapping may leave old wrapped data keys valid under previous versions. Rewrapping changes which key protects the data key without decrypting every large object. Full data-key rotation decrypts and re-encrypts the data itself and is more expensive. State which operation the design means when it says 'rotate the encryption key'.

Key deletion can be cryptographic deletion when destroying the only usable key makes ciphertext irrecoverable. That power is dangerous. Use waiting periods, separation of duties, backup and retention awareness, and evidence that no required object still depends on the key. A restore test should include the key path; restoring ciphertext without its key is a perfectly preserved loss.

Encryption is only as meaningful as the boundary around the decryption key and the identities allowed to use it.green

Read from the data outward: plaintext is encrypted by a data key; the data key is wrapped by a KMS-controlled key; policy and audit protect the unwrap operation. Remember that the master key need not leave its managed boundary for every object.

What Encryption Cannot Fix

An authorised but compromised payroll application receives plaintext and can leak it. An employee with excessive permission can request decryption legitimately. An insecure API can return another employee's record over a perfectly encrypted TLS connection. A logger can copy secrets into a less protected system. A backup can preserve data beyond intended deletion.

Encryption can also harm availability if keys, certificates, trust stores, or KMS access are unavailable. Rotation without versioning can make old ciphertext unreadable. A certificate renewal failure can stop traffic. A mistaken key deletion can turn durable storage into permanent loss. Key recovery and disaster planning must be tested with the same seriousness as confidentiality.

The design therefore combines data classification, minimal collection, least privilege, authorization, secure channels, field or storage encryption where justified, key separation, monitoring, backup handling, and deletion. Cryptography is powerful because it makes some attacks mathematically difficult; it is not a substitute for knowing which system is authorised to receive plaintext.

A Workplace Data-Protection Decision

A product stores delivery addresses, password verifiers, payment-event messages, exported finance reports, object-storage photos, and backups. Delivery addresses need access control and at-rest/transit protection but must become plaintext for fulfilment. Passwords need salted purpose-built hashing, not encryption. Payment events may need authenticated integrity, replay protection, and encrypted channels.

Finance reports should be encrypted in storage, shared through narrow short-lived access, logged without report content, and retained under policy. Photos can use storage encryption plus object-level authorization and constrained download links. Backups require encryption, separately controlled keys, restore testing, and retention/deletion awareness; Backup and Recovery Strategies explains why a copy that cannot be restored or safely decrypted is not a recovery plan.

For every field or object, write the threat and boundary before selecting a mechanism: stolen disk, storage-admin access, network interception, tampering, replay, excessive application privilege, or accidental logging. Then state who can decrypt or verify, how keys rotate, what evidence remains, and how the service behaves when protection infrastructure fails.

Interview phrasing: I classify data by lifecycle and threat, use purpose-built password hashing for passwords, authenticated encryption for recoverable secrets, TLS 1.3 for transport, signatures or HMAC for authenticity where appropriate, and envelope encryption with separately controlled keys for scalable storage.

Common Misunderstandings That Break the Boundary

• Base64 is encryption. It is reversible representation with no secret.

• Hashing and encryption are interchangeable. Hashing creates a one-way digest; encryption supports authorised recovery.

• A salt must be hidden. A unique salt is normally stored beside the password verifier; its job is uniqueness.

• HTTPS makes the application secure. It protects a connection, not endpoint code or resource authorization.

• A certificate proves a business is honest. It binds a key to a name/identity under a trust policy, not to good behaviour.

• A digital signature encrypts the message. It proves integrity/authenticity properties; plaintext may remain readable.

• mTLS authorizes every request. It authenticates peers at the transport layer; action/resource policy remains.

• Database encryption solves key management. If the same broad identity can fetch ciphertext and key, the boundary is weak.

Explain It Back Without Looking

Reconstruct the payroll file from cupboard to courier, verification, archive, and deletion. Match the locked cupboard, sealed courier case, fingerprint, signed wax seal, and passport office to their technical jobs, then state where each analogy fails.

1. Contrast data at rest, in transit, and in use with one field.

2. Contrast encoding, encryption, and hashing without naming an algorithm.

3. Draw the hybrid sequence: authenticate/key agreement -> derive symmetric keys -> protect bulk data.

4. Contrast hash, HMAC, and digital signature by asking who can create and verify proof.

5. Draw TLS 1.3 as authenticate -> agree -> derive -> protect, with certificate validation beside it.

6. Draw envelope encryption with data key, wrapped data key, KMS key, and authorised unwrap request.

Now transfer it. A background worker downloads an encrypted object, decrypts it, and sends a summary to another service. Identify every point where plaintext exists, every identity that can request keys, every connection that needs protection, and the evidence needed after misuse. If your answer starts with boundaries rather than 'use AES', the concept has become design knowledge.

A sixty-second retelling might sound like this: data changes risk as it is stored, transmitted, and processed. Encoding changes representation, encryption protects recoverable confidentiality under a key, and hashing creates a digest. Hybrid cryptography combines asymmetric authentication/key establishment with symmetric data protection. TLS 1.3 validates identity and derives traffic keys, PKI manages certificate trust, and envelope encryption separates per-data keys from KMS-controlled keys. None of these replaces authorization or endpoint security.