What "encrypted" actually promises, and the vocabulary that carries it

“The data is encrypted” is the sentence that ends most security conversations and begins a fair number of incidents. It is rarely false. It is almost always incomplete, because it names an operation without naming the key, the custodian, the adversary or the property being defended. This lesson gives you the vocabulary to finish that sentence, and the habit of refusing to accept it unfinished.

Four properties, four different mechanisms

Applied cryptography sells four things, and buying one does not get you the others. Every design argument you will have about certificates, tokens, backups or webhooks is really an argument about which of these four you need.

• Confidentiality. Nobody who lacks the key can recover the plaintext. This is what encryption buys, and it is the only one of the four that encryption buys on its own.
• Integrity. Any modification to the protected bytes is detected. A checksum gives you this against accidental corruption only; a keyed construction gives it to you against a deliberate attacker.
• Authenticity. The bytes came from a party holding a specific key. This is a claim about origin, not about secrecy, and it is the property most often assumed rather than checked.
• Freshness. These bytes belong to this exchange, now, and cannot be captured and replayed into a later one. Nonces, sequence numbers, timestamps and session binding buy this. Encryption does not.

A signed but unencrypted software release has authenticity and integrity with no confidentiality, and that is exactly right for a public download. A LUKS volume has confidentiality against a stolen disk and says nothing about who wrote the blocks. A bearer token in a header has none of the four by itself and borrows all of them from the TLS session carrying it, which is why the failure of that session is a credential disclosure rather than a connectivity problem.

Encoding, hashing and encryption are three different operations

The single most common vocabulary error in production is treating an encoding as a protection. Encoding changes representation for transport. Hashing produces a fixed-length fingerprint that cannot be reversed but can be recomputed by anyone. Encryption transforms plaintext into ciphertext under a key, and is reversible only by a holder of the matching key.

Base64 is the one people trip over, because it produces a string that looks scrambled to a human reader and is entirely transparent to a machine:

# Base64 is an encoding. It takes no key, and anyone can reverse it.
SECRET='lab-only-not-real'
printf '%s' "$SECRET" | base64
printf '%s' "$SECRET" | base64 | base64 -d

The second pipeline prints the original string back. No key was supplied to either command, because none was required. This is the mechanism behind the most-repeated fact about Kubernetes: a Secret object is base64-encoded, not encrypted, and by default it is stored unencrypted in etcd.

apiVersion: v1
kind: Secret
metadata:
  name: app-database
type: Opaque
data:
  password: bGFiLW9ubHktbm90LXJlYWw=

Anyone who can read that manifest can read the password, whether they get it from kubectl get secret -o yaml, from an etcd snapshot, or from a Git repository that a well-meaning engineer synchronised it into. The encoding is a transport convenience for binary values. It is not a control.

What encryption does not promise

Encryption hides content. It does not hide the shape of that content, and it does not answer questions about who or when.

• It does not hide metadata. Ciphertext length tracks plaintext length unless you pad deliberately. Timing, packet counts, destination addresses and connection patterns all survive. In TLS the ClientHello and ServerHello are cleartext, so the server name indication and the negotiated protocol are visible on the wire unless Encrypted Client Hello is in use.
• It does not prove origin. A ciphertext you can decrypt tells you that someone holding the key produced it. With a shared symmetric key, “someone” includes every party who holds that key, which in a fleet of forty hosts is forty hosts.
• It does not prevent replay. A captured ciphertext can be delivered again tomorrow. If the protocol has no nonce, sequence number or session binding, the receiver will accept it as new.
• It does not stop a legitimate caller. An application that can decrypt on demand will decrypt for anyone who can make it run, including an attacker with a shell in the container. This is why encryption at rest is an answer to physical media theft and a poor answer to application compromise.
• It does not survive a key you also stored next to it. A backup archive encrypted with a passphrase written into the same automation repository has moved the problem, not solved it.

Naming the boundary: at rest, in transit, in use

The three phrases in every compliance document map to three different attackers, and the mapping is what makes them useful.

flowchart LR
    A["Client process\nplaintext in memory"] -- "in transit\nTLS session keys" --> B["Server process\nplaintext in memory"]
    B -- "at rest\nvolume or field key" --> C["Disk or object store"]
    B -- "in use\nenclave or HSM" --> D["Key held outside\nthe process"]

Protection in transit defends the network path: anyone tapping a switch port, terminating a proxy or sitting on a shared cloud fabric. It ends the moment the bytes reach the process, which is why a TLS-protected request that the application then writes into a debug log has been protected right up to the point where it was disclosed. Protection at rest defends the storage medium and the snapshot: a lost laptop, a decommissioned array, a copied etcd backup. It does nothing while the volume is mounted and the service is running, because at that moment the operating system is decrypting on demand for anyone with the right file permissions. Protection in use is the narrow and expensive case where the key itself never enters the application’s address space, which is what a hardware security module or a remote key service provides, and it is the subject of Part XV.

Production discipline

1. Finish the sentence in writing. Every design document that says “encrypted” must also say with which key, held where, and which identities can request a decryption. If those three sentences cannot be written, the control does not exist yet.
2. Never treat an encoding as a control. Base64, hex, URL encoding, JSON escaping and gzip are transport mechanics. Reviewers should reject any change that presents one as protection.
3. State the adversary before the mechanism. “Protects against a stolen backup tape” is a reviewable claim. “Enterprise-grade encryption” is not.
4. Assume the plaintext exists somewhere. Every encrypted system has a moment of plaintext: in a process, in a log, in a crash dump, in a temporary file. Find that moment during design rather than during an incident.
5. Use mature implementations. You will select algorithms and operate key lifecycles in this course. You will not implement primitives. The library that ships with your platform has been attacked by people whose full-time job that is.

Cross-course references

• Linux for Production Sysadmins - Part LXXII (Secrets) covers where credentials actually live on a host, which is the concrete version of the key-custody question this lesson asks.
• Kubernetes for Production Sysadmins - Part LXV (SecretsSec) covers the Secret object whose base64 encoding this lesson uses as the worked example of encoding mistaken for protection.
• Observability for Production Sysadmins - Part LXXXII (SensitiveTelemetry) covers the log and metric pipelines that are the most common place a protected value becomes an unprotected one.

Quiz