Foundations of Cryptography — Security Goals (Ultimate Notes)

Objectives: Foundations of Cryptography — Security Goals (Ultimate Notes)

Foundations of Cryptography — Security Goals (Ultimate Notes)

Security Goals of Cryptography

Master the six core goals with crisp definitions, mental models, real‑life analogies, protocol mappings, exam‑style traps, and interview‑ready answers.

Confidentiality Integrity Authenticity Non‑repudiation Forward Secrecy Deniability

The Big Picture

Think of a secure conversation as a registered parcel with tamper‑evident tape, sealed inside a private box, with the sender’s ink stamp, and a receipt you can show later. Each goal maps to one job:

Confidentiality
Keep content secret from unauthorized parties. Encryption.
Integrity
Detect any modification. MACs / hashes.
Authenticity
Know who/what you’re talking to. MACs / signatures.
Non‑repudiation
Prevent sender from denying authorship later. Digital signatures.
Forward Secrecy
Past messages stay safe even if long‑term keys leak. (EC)DHE.
Deniability
Opposite of non‑repudiation in chat: outside parties cannot prove you said it. Signal’s design.
Mnemonic: CIAN‑FDConfidentiality, Integrity, Authenticity, Non‑repudiation, Forward secrecy, Deniability.

Real‑World Mapping

  • Bank app: TLS (confidentiality+integrity+auth), server cert, FS; signed transactions → non‑repudiation.
  • WhatsApp/Signal: End‑to‑end AEAD (C+I), X3DH + Double Ratchet → FS & deniability by design.
  • Email: PGP/S/MIME → C+I+A; S/MIME signing → non‑repudiation (policy‑dependent).
  • File storage: AES‑GCM + file hashes; signed releases (e.g., software updates).

1) Confidentiality

Keep secrets secret

Definition. Only intended parties can learn the message content. In practice: encrypt data in transit (TLS, VPN) and at rest (disk, database, backups) using strong algorithms and correct modes.

Core Building Blocks

  • AES‑GCM / ChaCha20‑Poly1305 for AEAD; XChaCha20 for large nonces.
  • For passive attackers: IND‑CPA security; for active attackers: IND‑CCA via AEAD or KEM+DEM.
  • Key hygiene: strong KDF (HKDF / scrypt / Argon2), per‑message nonces, no reuse.

Everyday Examples

  • Wi‑Fi home network → WPA3‑SAE traffic is confidential to outsiders.
  • Cloud storage with client‑side encryption (e.g., AES‑GCM) prevents provider from reading files.
  • ATM PIN encrypted on smartcard + terminal link.
Pitfalls. ECB mode, nonce reuse in CTR/GCM, hard‑coding keys, weak passwords, leaking plaintext in logs/URLs/metadata.

Exam Quick‑Hits

  • Confidentiality ≠ privacy: encryption hides content, not necessarily metadata.
  • AEAD gives confidentiality + integrity together (ciphertext + tag).
  • Perfect secrecy (OTP) is information‑theoretic; AES is computational secrecy.
Answer pattern: “Use AEAD with unique nonce per message, derive keys via HKDF from an ephemeral (EC)DHE handshake; store keys in HSM; never log plaintext.”

2) Integrity

Detect tampering

Definition. Any unauthorized change to data is detectable. Integrity resists silent flips, truncations, replays, and re‑orderings.

Core Building Blocks

  • MACs (HMAC‑SHA‑256, Poly1305) when sender & receiver share a key.
  • Digital signatures (Ed25519/ECDSA) when verifiers don’t share a secret.
  • Hashes (SHA‑256/512, BLAKE3) for unkeyed checksums, versioning, Merkle trees.

Everyday Examples

  • Mobile money / bank API: request body has HMAC; server rejects if tag fails.
  • Software updates: package signed; OS verifies before install.
  • Backups: chunk hashes; repair or alert on mismatch.
Pitfalls. Using plain hash for integrity (no key → vulnerable to length‑extension); reusing nonces; ignoring associated data (AAD) like headers.

Compare & Clarify

  • Checksum (CRC) ≠ cryptographic integrity (HMAC/signature).
  • AEAD’s tag is a MAC bound to ciphertext and AAD.
  • Merkle trees ensure integrity of huge datasets efficiently.
Answer pattern: “Bind data + context as AAD; compute HMAC with rotating keys; verify before processing; reject on failure; log tamper events.”

3) Authenticity

Prove origin/identity

Definition. The receiver can verify the data came from the claimed party and not an impostor. Achieved via shared‑key MACs or public‑key signatures and often bound to transport authentication (TLS server certs, mutual TLS).

Core Building Blocks

  • PKI (X.509 certificates, CA trust) for server/client auth.
  • Signatures (Ed25519/ECDSA/RSA‑PSS) for origin authentication.
  • MACs for channel/authenticated messages among known peers.

Everyday Examples

  • HTTPS lock: your browser validates the site’s certificate → talking to the real domain.
  • Mobile app attestation: device proves it’s genuine (TEE/secure enclave).
  • API webhooks: provider includes HMAC header; consumer verifies origin.
Pitfalls. Not verifying hostname, ignoring certificate revocation, accepting self‑signed certs blindly, weak clock sync causing validation errors.

Auth vs. Integrity

Integrity says “not changed.” Authenticity adds “and it’s really from Alice.” You can have integrity without knowing who created it (e.g., unkeyed hash).

Answer pattern: “Authenticate endpoints with TLS 1.3 + PKI; sign messages; include context (timestamps, nonce, audience) to defeat replay and misbinding.”

4) Non‑repudiation

Can’t deny later

Definition. The sender cannot plausibly deny creating a message later. Achieved with public‑key signatures + proper identity binding (certificates, policy, time‑stamps) and audit trails.

Core Building Blocks

  • Digital signatures (Ed25519/ECDSA/RSA‑PSS) + trusted time‑stamps.
  • PKI with identity vetting; secure key custody (HSM, smart cards).
  • Immutable logs (append‑only, Merkle‑tree or ledger backed).

Everyday Examples

  • E‑contracts: user signs; service stores signature + time‑stamp → hard to deny.
  • Tax filings: digitally signed submissions bound to identity.
  • Bank transfers: signed instructions (sometimes with hardware tokens).
Pitfalls. Using MACs instead of signatures (either party could have forged), poor key management (stolen key undermines claims), missing time‑stamps.

Policy & Law

Cryptography provides technical evidence; legal non‑repudiation also needs process: verified identity, consent records, time‑stamps, and secure custody of private keys.

Answer pattern: “Use digital signatures with hardware‑protected keys, RFC‑3161 time‑stamps, audit logs, and PKI enrollment policies to achieve non‑repudiation.”

5) Forward Secrecy (Perfect Forward Secrecy)

Past stays safe

Definition. Compromise of long‑term keys today does not reveal past session content. Enabled by ephemeral Diffie–Hellman (DHE/ECDHE) where each session uses fresh ephemeral keys discarded after use.

Core Building Blocks

  • TLS 1.3 mandates forward secrecy via (EC)DHE handshakes.
  • Messaging protocols rotate keys frequently (Double Ratchet) → post‑compromise security.
  • Key erasure: securely delete ephemeral secrets after use.

Everyday Examples

  • HTTPS on modern sites → ECDHE; captured traffic cannot be decrypted later with server key.
  • Private chats: each message chain derives new keys; old messages remain safe if a phone is stolen.
Pitfalls. Reusing non‑ephemeral DH keys; logging session secrets; TLS 1.2 with static RSA key exchange (no FS).

Why It Matters

Attackers can store ciphertext now and decrypt later if keys leak. FS breaks that strategy by ensuring past keys never existed long enough to be stolen.

Answer pattern: “Use TLS 1.3 (ECDHE), ephemeral keys per session, regular re‑keying, and secure key erasure to guarantee forward secrecy.”

6) Deniability

Can’t prove it to outsiders

Definition. After a conversation, an outsider cannot cryptographically prove that a specific participant authored a specific message. Useful for private chats and whistle‑blowing scenarios.

How Protocols Achieve It

  • Use MACs (shared secret) rather than public‑key signatures on messages → either party could have produced the tag.
  • Ephemeral key exchanges + no durable identity‑binding on message content.
  • Optional transcript binding only for in‑band participants, not third‑party proofs.

Everyday Examples

  • Signal: messages authenticated with MACs derived from session keys; transcripts aren’t cryptographic evidence to outsiders.
  • Off‑the‑record (OTR) messaging explicitly designs for deniability.
Pitfalls. Adding digital signatures to chat content destroys deniability; server‑side logging or screenshots may still be social evidence (non‑cryptographic).

Deniability vs. Non‑repudiation

They pull in opposite directions. Choose based on context: chats favor deniability; contracts/payments favor non‑repudiation.

Answer pattern: “Use AEAD without public‑key message signatures and rely on ephemeral session keys; avoid durable, third‑party verifiable transcripts.”

Exam Power‑Ups & Interview One‑Liners

Golden Rules

  • Prefer AEAD (AES‑GCM / ChaCha20‑Poly1305) over “encrypt‑then‑hash yourself”.
  • Bind context (nonce, seq#, AAD) to defeat replay/misbinding.
  • Use TLS 1.3 with ECDHE for FS; avoid static RSA key exchange.
  • Use signatures for non‑repudiation; MACs for deniable chat authenticity.

Common Traps

  • “HTTPS lock = end‑to‑end” → No, it’s browser↔server, not user↔user.
  • “Hash = integrity” → Only if keyed (HMAC) for adversarial settings.
  • “Sign every message in chat” → breaks deniability; use MACs.

Mini Q&A (Exam‑ready)

Q: How to secure an API request end‑to‑end?
A: TLS 1.3 (ECDHE) for transport C+I+A+FS; inside, sign body or HMAC with rotating keys; include nonce/timestamp in AAD; log audit trail if non‑repudiation required.
Q: Why MAC not signature for chat?
A: MAC provides authenticity with deniability (either party could create it). Signatures create third‑party verifiable proof (non‑repudiation), which we often don’t want in chat.
Q: What ensures captured TLS traffic can’t be decrypted later?
A: Forward secrecy via ephemeral (EC)DHE; session keys aren’t derivable from long‑term keys and are erased.
Q: Does encryption alone give integrity?
A: No. Use AEAD or add a MAC (encrypt‑then‑MAC). Otherwise flips may go undetected.
© Crypto Foundations Notes Bootstrap 5 • Print‑friendly
Foundations — Goals of Cryptography

Foundations of Cryptography — Goals

This section explores the six major goals of cryptography — confidentiality, integrity, authenticity, non-repudiation, forward secrecy, and deniability — in full depth, with definitions, real-world examples, and exam-level insights.

1. Confidentiality

Ensures that only authorized parties can read the data. Achieved using encryption algorithms like AES or ChaCha20. Example: Your bank encrypts transactions so only you and the bank can read them.

2. Integrity

Ensures that data has not been altered. Achieved using cryptographic hashes (SHA-256) or HMAC. Example: Software updates are signed so that even a single-bit change will be detected.

3. Authenticity

Confirms the source of data. Achieved via digital signatures or certificates. Example: HTTPS certificates confirm you are connected to the real website.

4. Non-repudiation

Prevents denial of sending a message. Achieved via public-key signatures. Example: Signed contracts where the signer cannot later deny their involvement.

5. Forward Secrecy

Ensures past sessions remain secure even if keys are compromised later. Example: TLS 1.3 uses ephemeral keys so recorded communications cannot be decrypted in the future.

6. Deniability

Allows a participant to plausibly deny authorship. Example: Off-the-record messaging where messages can’t be cryptographically linked to a sender.


20 Mastery Questions & Answers

  1. Q: What cryptographic goal ensures that only authorized parties can read data?
    A: Confidentiality.
  2. Q: Which algorithm type is typically used for confidentiality?
    A: Symmetric encryption (e.g., AES).
  3. Q: How does integrity differ from authenticity?
    A: Integrity ensures data isn't altered; authenticity confirms the source.
  4. Q: What mechanism provides integrity in HTTPS?
    A: HMAC or AEAD (Authenticated Encryption with Associated Data).
  5. Q: Give an example of authenticity in daily life.
    A: Email signed with DKIM.
  6. Q: Which cryptographic goal prevents someone from denying sending a message?
    A: Non-repudiation.
  7. Q: How is non-repudiation achieved?
    A: Digital signatures with public/private key pairs.
  8. Q: Define forward secrecy.
    A: Property ensuring past data can't be decrypted if future keys are compromised.
  9. Q: Which TLS version enforces forward secrecy by default?
    A: TLS 1.3.
  10. Q: Give a real-world analogy for forward secrecy.
    A: Changing door locks every day so stolen keys are useless for past days.
  11. Q: What is deniability in cryptography?
    A: The ability to deny authorship of a message while still having secure communication.
  12. Q: Name a protocol that supports deniability.
    A: Off-the-Record (OTR) messaging.
  13. Q: Which cryptographic goal is most critical in online banking?
    A: Confidentiality, followed by integrity and authenticity.
  14. Q: Can digital signatures provide confidentiality?
    A: No, they provide authenticity and non-repudiation.
  15. Q: Which cryptographic primitive is used for both confidentiality and integrity?
    A: AEAD schemes like AES-GCM.
  16. Q: How does a hash ensure integrity?
    A: Any data change alters the hash output, revealing tampering.
  17. Q: Which property protects against man-in-the-middle attacks?
    A: Authenticity via digital certificates.
  18. Q: How is deniability different from forward secrecy?
    A: Forward secrecy protects past keys; deniability hides message authorship.
  19. Q: Why is forward secrecy important for long-term privacy?
    A: It prevents stored encrypted data from being decrypted in the future if keys are leaked.
  20. Q: Give an everyday example of non-repudiation outside computing.
    A: A handwritten signature on a physical contract.

Reference Book: Applied Cryptography – Bruce Schneier Cryptography and Network Security – William Stallings Understanding Cryptography – Christof Paar & Jan Pelzl Introduction to Modern Cryptography – Jonathan Katz & Yehuda Lindell Serious Cryptography – Jean-Philippe Aumasson

Author name: SIR H.A.Mwala Work email: biasharaboraofficials@gmail.com
#MWALA_LEARN Powered by MwalaJS #https://mwalajs.biasharabora.com
#https://educenter.biasharabora.com

:: 1::