I like to tell people that encryption is really answering two very different questions at once: “can someone read this who shouldn’t?” and “can someone change this without me knowing?” Most people only think about the first question. But the second one is just as important, and understanding both is what separates a surface-level view of encryption from a genuinely useful one. Let’s dig into the foundational security properties encryption provides, the mechanics behind them, and why modern systems need all of them working together.
The CIA Triad as a Starting Point
Information security is traditionally framed around three core properties: Confidentiality, Integrity, and Availability. Encryption, on its own, primarily targets confidentiality and — when combined with the right constructions — integrity as well. It’s worth being precise about what each of these actually means:
- Confidentiality — only authorized parties can read the data.
- Integrity — the data has not been altered, whether accidentally or maliciously, without detection.
- Availability — authorized parties can access the data when needed (encryption doesn’t directly provide this, and can even work against it if key management fails).
Confidentiality: The Foundation
Confidentiality is what most people mean when they think of encryption. Formally, an encryption scheme provides confidentiality if, given a ciphertext $C = E_k(P)$, an adversary without knowledge of $k$ cannot feasibly recover $P$, or even distinguish which of two possible plaintexts produced a given ciphertext (a property known as semantic security or indistinguishability, formalized as IND-CPA and IND-CCA security in modern cryptographic theory).
Why “Just Scrambling the Data” Isn’t Enough
Weak or naive encryption schemes can leak information even without fully recovering the plaintext. A classic example is using a deterministic cipher mode like ECB (Electronic Codebook), where identical plaintext blocks always encrypt to identical ciphertext blocks:
$$C_i = E_k(P_i) \quad \text{for each block } i, \text{ independently}$$
This means visual or structural patterns in the plaintext (famously demonstrated with images that remain visibly recognizable after “encryption” in ECB mode) leak directly through to the ciphertext. Modern modes like CBC, CTR, and especially authenticated modes like GCM incorporate randomization (via an initialization vector or nonce) specifically to prevent this kind of pattern leakage, ensuring that encrypting the same plaintext twice produces different ciphertexts each time.
Integrity: The Property Confidentiality Alone Doesn’t Provide
Here’s a fact that surprises a lot of people: encryption by itself does not guarantee that data hasn’t been tampered with. A ciphertext can often be modified by an attacker — even without knowing the key — in ways that produce predictable, exploitable changes to the decrypted plaintext. This is called a malleability weakness.
Malleability Attacks
Consider a stream cipher, where ciphertext is produced via XOR with a keystream:
$$C_i = P_i \oplus k_{s,i}$$
If an attacker flips a bit in $C_i$, the corresponding bit in the decrypted plaintext $P_i$ flips predictably too — without the attacker ever needing to know the key. This is a textbook example of malleability, and it’s exactly the kind of flaw that padding-oracle and bit-flipping attacks exploit against systems that use encryption without a separate integrity check.
Message Authentication Codes (MACs)
To guarantee integrity, a MAC is computed over the message using a secret key:
$$T = \text{MAC}_k(M)$$
The recipient recomputes the MAC over the received message and compares it to the received tag $T$. Any modification to $M$ — even a single flipped bit — produces a completely different, unpredictable MAC value (thanks to the avalanche effect designed into modern hash-based constructions), causing verification to fail.
Authenticated Encryption (AEAD)
Modern best practice combines confidentiality and integrity into a single, carefully designed construction called Authenticated Encryption with Associated Data (AEAD). Rather than separately applying encryption and then a MAC (a process that’s easy to get subtly wrong — the correct order is encrypt-then-MAC, not MAC-then-encrypt or encrypt-and-MAC), AEAD modes like AES-GCM and ChaCha20-Poly1305 produce both a ciphertext and an authentication tag in one integrated operation:
$$(C, T) = \text{AEAD}_k(P, \text{AD})$$
where $\text{AD}$ represents optional “associated data” — information (like a packet header) that is authenticated but not encrypted, ensuring it also can’t be tampered with even though it remains readable.
Why Both Properties Are Necessary Together
A system with confidentiality but no integrity protection can be manipulated by an attacker without ever revealing the plaintext — a classic and serious flaw. A system with integrity protection but no confidentiality reveals everything in plain sight while merely detecting tampering after the fact. Real-world secure systems, from TLS to encrypted messaging apps, need both simultaneously, which is precisely why AEAD modes have become the standard rather than using encryption and authentication as separate, independently bolted-on steps.
Authenticity and Non-Repudiation: The Next Layer
Beyond confidentiality and integrity, many systems also need authenticity (proof of who sent a message) and non-repudiation (the sender can’t later deny having sent it). Symmetric MACs provide integrity and a limited form of authenticity between two parties sharing a key, but they don’t provide non-repudiation, since either party could have generated the tag.
Digital signatures solve this using asymmetric cryptography:
$$\sigma = \text{Sign}{k{priv}}(H(M))$$
Anyone with the corresponding public key can verify $\sigma$ against $M$, confirming both that the message came from the holder of the private key and that it wasn’t altered — and because only the sender holds the private key, they cannot credibly deny having produced a valid signature.
Real-World Consequences of Missing These Properties
- Confidentiality failures — plaintext data exposed to unauthorized parties, ranging from personal data breaches to exposed trade secrets.
- Integrity failures — undetected tampering with financial transactions, firmware updates, or software packages, potentially leading to fraud or the silent installation of malicious code.
- Authenticity failures — impersonation attacks, forged communications, and successful phishing or business email compromise schemes that exploit a lack of verifiable sender identity.
A well-known illustration of integrity’s importance: software update mechanisms that don’t cryptographically verify update packages before installing them have historically been exploited to distribute malware disguised as legitimate updates, precisely because nothing checked whether the package had been tampered with in transit.
Practical Implementation Guidance
- Always use AEAD modes (AES-GCM, ChaCha20-Poly1305) for new systems rather than manually combining separate encryption and MAC steps.
- Never roll your own combination of encryption and authentication — subtle ordering mistakes (like MAC-then-encrypt) have historically led to real vulnerabilities.
- Use digital signatures, not just MACs, whenever non-repudiation matters — for example, legal or financial transactions where a signer must not be able to deny authorship.
- Validate integrity before trusting decrypted content — reject and discard any message that fails authentication, without processing the corresponding “decrypted” data at all.
- Protect associated data where relevant (e.g., message headers, sequence numbers) using AEAD’s associated-data feature, so metadata can’t be tampered with even though it stays visible.
Common Mistakes
- Assuming “encrypted” automatically means “tamper-proof” — it doesn’t, unless integrity protection is explicitly included.
- Using ECB mode or unauthenticated stream cipher modes for anything beyond trivial, non-sensitive use cases.
- Implementing MAC-then-encrypt instead of encrypt-then-MAC when manually combining primitives (a well-documented source of vulnerabilities).
- Confusing a MAC’s authenticity guarantee (works between two symmetric-key holders) with the stronger non-repudiation guarantee only digital signatures provide.
FAQs
Does encrypting my data automatically protect it from being altered? No. Confidentiality and integrity are separate properties. You need either a MAC or, better, an AEAD construction to detect tampering — encryption alone typically does not guarantee this.
What’s the difference between a MAC and a digital signature? A MAC uses a shared secret key and proves integrity/authenticity only between parties who share that key. A digital signature uses asymmetric keys, allowing anyone with the public key to verify authorship, and additionally provides non-repudiation.
Why is AEAD considered best practice today? Because it combines confidentiality and integrity into a single, carefully engineered construction, avoiding the well-documented pitfalls of manually combining separate encryption and MAC operations in the wrong order.
Can data be both confidential and tampered with at the same time? Yes — this is exactly what a malleability attack demonstrates. An attacker can modify ciphertext (and therefore the decrypted plaintext) in predictable ways without ever learning the plaintext itself, unless integrity protection is in place to detect the change.
Summary
Encryption is often discussed purely in terms of secrecy, but confidentiality is only half the picture. Integrity — the guarantee that data hasn’t been silently altered — is an equally essential property, and one that plain encryption does not provide on its own. Modern cryptographic practice addresses this through authenticated encryption (AEAD), MACs, and digital signatures, each targeting a specific combination of confidentiality, integrity, authenticity, and non-repudiation. Understanding why these properties are distinct — and why real systems need them working together — is the difference between using encryption as a checkbox and using it as an actual security foundation.
References
- NIST SP 800-38D — Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.
- RFC 2104 — HMAC: Keyed-Hashing for Message Authentication.
- RFC 8439 — ChaCha20 and Poly1305 for IETF Protocols.
- Bellare, M., & Namprempre, C. (2000). Authenticated Encryption: Relations among Notions and Analysis of the Generic Composition Paradigm.
- NIST FIPS 186-5 — Digital Signature Standard (DSS).
- Goldwasser, S., & Micali, S. (1984). Probabilistic Encryption. Journal of Computer and System Sciences.
