Goals of Cryptography: Confidentiality, Integrity, Authenticity

Cryptography exists to make precise promises to honest parties in the presence of an adversary who controls the communication channel. Three promises recur so often that they are treated as the foundational goals of the field, and it is worth stating each as a game rather than a slogan.

Confidentiality is the promise that an adversary observing the transmitted data learns nothing about the underlying plaintext except, at most, its length. Formally, confidentiality is tested by an indistinguishability game: the adversary picks two messages $m_0$ and $m_1$, receives an encryption of one of them chosen at random, and must guess which one it was. A scheme is confidential if no efficient adversary can guess correctly with probability meaningfully better than $1/2$. Confidentiality says nothing about whether the message can be tampered with in transit — a ciphertext can be perfectly secret and still be flippable bit-by-bit by an attacker who doesn't know the plaintext.

Integrity is the promise that any modification to a message in transit will be detected by the receiver. The adversary's goal in the integrity game is to produce a message (or a modification of an intercepted message) that the receiver accepts as valid, without having legitimately produced or forwarded it unchanged. Integrity is checked using a short, unforgeable tag attached to the data — but critically, integrity by itself does not tell the receiver who sent the message, only that whatever was sent has not been altered. A public checksum like a plain hash gives a form of integrity against accidental corruption but gives zero protection against a deliberate adversary, because the adversary can simply recompute the hash after tampering.

Authenticity (sometimes split into data-origin authentication and entity authentication) is the promise that the receiver can verify the claimed identity of the sender. This requires the sender to hold a secret (a shared key or a private key) that the adversary does not possess, so that only the legitimate sender could have produced a valid tag or signature. Authenticity subsumes a meaningful form of integrity — if you can verify who sent something, and the verification also covers the content, then you automatically detect tampering — but authenticity is strictly harder to achieve than integrity alone, because it requires binding the message to a secret identity rather than just to a public, checkable invariant. A fourth goal, non-repudiation, often rides alongside authenticity: the guarantee that a sender cannot later deny having sent an authenticated message. This matters for digital signatures (a signature is verifiable by anyone, using the sender's public key) but does not typically apply to symmetric Message Authentication Codes, where the verifier holds the same secret as the sender and so could have forged the tag itself.

Each goal is realized by a specific cryptographic primitive, and the mechanisms are worth walking through explicitly so the distinctions are concrete rather than definitional.

Confidentiality is achieved by an encryption scheme $(\text{Gen}, \text{Enc}, \text{Dec})$. A shared or public key is used to transform plaintext into ciphertext such that ciphertext reveals (ideally) nothing about plaintext without the corresponding decryption key. ``` // Confidentiality via symmetric encryption function Encrypt(key, plaintext): nonce ← GenerateRandomNonce() ciphertext ← SymmetricCipher(key, nonce, plaintext) return (nonce, ciphertext) function Decrypt(key, nonce, ciphertext): plaintext ← SymmetricCipherInverse(key, nonce, ciphertext) return plaintext ```

Integrity is achieved by a keyed function that produces a tag which only someone who processed the exact message could have produced — but crucially, when the key is shared between two parties, this construction gives integrity and authenticity together (this is exactly what a MAC is). If instead the "key" is nothing — a plain hash function known to everyone — you get only a weak, non-adversarial integrity check (useful for detecting accidental corruption, e.g., a file download checksum) with zero protection against a deliberate attacker, since anyone can recompute the hash after tampering. ``` // Weak "integrity" against accidental corruption only (NOT secure vs adversary) function ChecksumSend(message): tag ← Hash(message) return (message, tag) function ChecksumVerify(message, tag): return Hash(message) == tag // an adversary who changes 'message' just recomputes Hash(message') -- broken ```

Authenticity, and integrity against a real adversary, is achieved with a Message Authentication Code (MAC) using a shared secret key, or a digital signature using a public/private key pair. ``` // Integrity + authenticity via MAC (shared secret key) function MacSend(key, message): tag ← MAC(key, message) return (message, tag) function MacVerify(key, message, tag): expected ← MAC(key, message) return ConstantTimeEqual(expected, tag) // Only someone holding 'key' could have produced a tag that verifies. // A single bit flip in 'message' changes MAC(key, message) with // overwhelming probability -- this also gives integrity "for free". ``` ``` // Authenticity + non-repudiation via digital signature (asymmetric) function Sign(privateKey, message): signature ← SignatureAlgorithm(privateKey, Hash(message)) return (message, signature) function VerifySignature(publicKey, message, signature): return VerifyAlgorithm(publicKey, Hash(message), signature) // Anyone with publicKey can verify, but only the privateKey holder // could have produced a valid signature -- this also yields // non-repudiation, unlike a symmetric MAC. ``` Real systems compose these primitives rather than picking one. The standard construction is authenticated encryption (AE), typically built as encrypt-then-MAC: encrypt the plaintext for confidentiality, then compute a MAC over the ciphertext (and any associated data, like a sequence number) for integrity and authenticity, combined into an authenticated-encryption-with-associated-data (AEAD) scheme like AES-GCM or ChaCha20-Poly1305. ``` // Authenticated Encryption (Encrypt-then-MAC) function AuthEncrypt(encKey, macKey, plaintext, associatedData): nonce ← GenerateRandomNonce() ciphertext ← SymmetricCipher(encKey, nonce, plaintext) tag ← MAC(macKey, nonce ‖ associatedData ‖ ciphertext) return (nonce, associatedData, ciphertext, tag) function AuthDecrypt(encKey, macKey, nonce, associatedData, ciphertext, tag): expected ← MAC(macKey, nonce ‖ associatedData ‖ ciphertext) if not ConstantTimeEqual(expected, tag): return REJECT // integrity/authenticity check fails FIRST plaintext ← SymmetricCipherInverse(encKey, nonce, ciphertext) return plaintext ``` The order matters: verify the tag before decrypting. Decrypting first and only then checking integrity exposes the system to padding-oracle-style attacks, where an adversary learns information from how decryption fails.

Confidentiality. For a symmetric cipher with an $n$-bit key, encryption and decryption run in $O(\ell)$ time for a message of length $\ell$, since block or stream ciphers process data in linear passes. Security is argued computationally: an adversary's advantage in the indistinguishability game is bounded by the best known attack against the underlying primitive, and for a well-designed cipher like AES-256, the best attack requires roughly $2^{256}$ operations — infeasible for any adversary bounded by realistic computing power. This is computational security, not information-theoretic: it depends on the assumed hardness of breaking the cipher, in contrast to the Perfect Secrecy and the One-Time Pad setting, where confidentiality holds unconditionally against any adversary, at the cost of requiring a key as long as the message.

Integrity/Authenticity via MAC. Computing and verifying a MAC over a message of length $\ell$ takes $O(\ell)$ time (one pass over the data, e.g., HMAC internally runs a hash function twice with a linear cost each). The correctness argument is existential unforgeability: assuming the MAC is a pseudorandom function (or built from one, as HMAC is from a hash function), an adversary who has seen valid (message, tag) pairs but does not know the key cannot produce a new valid pair, except with probability negligible in the key length — typically bounded by $O(q^2/2^n)$ for $q$ queries against an $n$-bit tag, using a birthday-style argument on tag collisions. This is why tags must be long enough (128 bits at minimum) that $q^2/2^n$ stays astronomically small even for an adversary who tries billions of forgeries.

Digital signatures. Signing and verifying typically cost $O(\ell)$ for hashing the message plus one constant-cost public-key operation (e.g., one modular exponentiation for RSA, one elliptic-curve scalar multiplication for ECDSA), so overall $O(\ell + C)$ where $C$ is a fixed asymmetric-crypto cost independent of message length. Correctness (existential unforgeability under chosen-message attack) reduces to the hardness of an underlying number-theoretic problem — integer factorization for RSA, the discrete-log problem for DSA/ECDSA/EdDSA — meaning breaking the signature scheme would imply an efficient algorithm for a problem believed to require exponential or sub-exponential time.

The honest tradeoff. Confidentiality alone is cheap but blind to tampering. Authenticity alone (a bare MAC with no encryption) protects origin and integrity but leaks all content. Combining both, as in authenticated encryption, costs roughly the sum of both operations — still $O(\ell)$ overall — but requires careful composition order (encrypt-then-MAC, verified in that direction) to avoid subtle failures; MAC-then-encrypt and encrypt-and-MAC variants have historically enabled real attacks (e.g., padding oracle attacks against certain TLS cipher suites that used MAC-then-encrypt with CBC-mode padding). The key correctness invariant across all three goals is the same shape: an adversary without the secret cannot win the corresponding game with more than negligible probability, where "negligible" is quantified against the adversary's running time and the security parameter (key length). This unifies confidentiality, integrity, and authenticity as instances of one proof paradigm — reduction to a hard problem or a formally defined game — even though the games themselves protect against entirely different actions.

Consider a message `m = "PAY $100 to Alice"` sent from a sender holding secret key `k`, with an adversary Mallory sitting on the network.

Trace Scenario A concretely with a stream cipher (XOR with keystream `ks`): `c = m ⊕ ks`. If Mallory flips the third character's bits by XORing a known offset `Δ` into `c`, she gets `c' = c ⊕ Δ = m ⊕ ks ⊕ Δ`. On decryption, the receiver computes `c' ⊕ ks = m ⊕ Δ` — the plaintext has been altered exactly according to Mallory's chosen `Δ`, silently, with no error raised. This is the textbook demonstration that encryption alone provides zero integrity: an attacker who knows (or guesses) plaintext structure, e.g., that bytes 5–7 encode a dollar amount, can flip `$100` to `$900` without ever learning the key. Now trace Scenario C. Suppose Mallory intercepts `(nonce, c, tag)` and flips one bit of `c` to produce `c'`. When the receiver runs `AuthDecrypt`, it recomputes `MAC(kM, nonce ‖ c')`, which — because a secure MAC behaves like a random function of its input — differs from the transmitted `tag` in roughly half its bits with overwhelming probability. The equality check fails, decryption is never attempted, and the tampered message is rejected outright. This is why AEAD schemes are the default recommendation in essentially every modern protocol (TLS 1.3, SSH, WireGuard, Signal).

The separation of these three goals crystallized gradually. Shannon's information-theoretic treatment addressed confidentiality alone, because in his military-communications context, message tampering by an active adversary was a secondary concern to eavesdropping. The rise of computer networks in the following decades exposed a different threat model: active adversaries who could inject and modify traffic, not merely listen. This drove the independent formalization of integrity and authenticity as distinct cryptographic games, culminating in the modern consensus that a secure channel requires all three properties jointly — a principle now baked into essentially every transport security protocol in use.

• TLS/HTTPS: every HTTPS connection uses an AEAD cipher suite (commonly AES-GCM or ChaCha20-Poly1305) to give web traffic confidentiality, integrity, and server authenticity simultaneously.
• Secure messaging (Signal, WhatsApp): each message is authenticated-encrypted per-message with ratcheting keys, so a compromised key does not retroactively break past messages' confidentiality or authenticity.
• Code signing and software updates: operating systems and package managers verify a digital signature before installing an update, giving authenticity (this really came from the vendor) and integrity (it wasn't altered) without requiring confidentiality, since the update binary is public.
• Banking and payment systems: transaction messages carry MACs or signatures binding amount, account, and timestamp, specifically to prevent the bit-flipping attack shown in the worked example.
• VPNs (WireGuard, IPsec): tunnel every packet through an AEAD construction, since a VPN must resist both eavesdropping and active packet injection on untrusted networks.
• Blockchain and cryptocurrency: transactions are signed (authenticity/non-repudiation) and chained via hashes (integrity of history), while confidentiality is often deliberately not provided, illustrating that these goals are chosen independently per system.

These deployments foreshadow deeper questions this article does not resolve: how do we formally define the adversary's power (see Threat Models and Kerckhoffs's Principle), what is the strongest possible confidentiality guarantee achievable (see Perfect Secrecy and the One-Time Pad), how do keyless integrity checks work at scale (see Cryptographic Hash Functions), and how are MACs constructed and proven secure in practice (see Message Authentication Codes).

Ask the tutor: How does encrypt-then-MAC formally prevent the padding-oracle attacks that plagued older TLS cipher suites?