Chapter 1 named the harm (the CIA triad: confidentiality, integrity, availability). This chapter is the toolbox that pushes back. Read it as one chain, not a list of algorithms:
Problem. Once data leaves your machine it travels over wires you do not own and sits on disks others can reach. The asset is exposed; you need a way to protect it that does not depend on protecting the channel. Solution: cryptography — math that protects the data itself, so the channel can stay hostile.
Cryptography is asked to do four distinct jobs. Keep them countable, because the rest of the chapter is just "which tool delivers which job":
Confidentiality and integrity are two of the three CIA properties; authentication is the practical face of authenticity from Chapter 1. Cryptography does not directly buy availability — a flooded server is still down whether or not the traffic was encrypted. That gap is why this chapter never claims to be the whole of security.
Punchline: encryption hides data, but hiding is only one of four jobs — most exam mistakes come from assuming "encrypted" also means "authentic" or "available". It does not.
Two basic operations sit under everything: encryption converts plaintext (readable) into ciphertext (a cryptogram, semantically unreadable), and decryption reverses it. The ciphertext can travel or be stored in the clear precisely because it is meaningless without the key.
plaintext + key -> [CIPHER] -> ciphertext ciphertext + key -> [CIPHER] -> plaintext
A cipher is the algorithm that performs encryption and decryption; a series of well-defined steps that turn a clear message into an obscured one and back. A key is the piece of information the cipher uses to fix the exact transformation — the same plaintext under two different keys yields two different ciphertexts. Examples of ciphers: the Caesar cipher (historical substitution), DES and AES (symmetric block ciphers), RSA (public-key), with SHA as the related hash family. The cipher is the recipe; the key is the secret ingredient.
"A cryptosystem should be secure even if everything about the system, except the key, is public knowledge." Security must rest only on the secrecy of the key, never on the secrecy of the algorithm. This is the cryptographic form of Chapter 1's open design principle: a public, long-scrutinized algorithm is trusted because it survived public attack. A "strong" algorithm is exactly one that has been open and studied for years with no known break — which is why 3DES is more trusted than DES, and both far more than a cipher invented ad hoc for one project.
Punchline: open beats closed — a secret algorithm has been tested by no one; a public one has been tested by everyone.
Why start here. The Caesar cipher is the smallest complete example of the whole chain: a cipher, a key, a vulnerability, and two attacks that generalize to every cipher after it. Used by Gaius Julius Caesar, it is a monoalphabetic substitution cipher: each letter is replaced by the letter a fixed number of positions further in the alphabet. That fixed shift is the secret key.
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z D E F G H I J K L M N O P Q R S T U V W X Y Z A B C (shift = 3)
It breaks two ways, and both are universal:
CIA tag: a successful attack recovers the plaintext, so it breaks Confidentiality. What it is NOT: brute force depends on the size of the key space; cryptanalysis depends on structure left in the cipher. The same two levers reappear against DES, AES, and hash functions.
Punchline: every cipher has exactly these two enemies — too few keys (brute force) or too much leftover structure (cryptanalysis). Strong ciphers simply make both infeasible.
Problem. You want confidentiality for data in transit or at rest. Solution: symmetric (also called conventional or single-key) encryption — the universal technique for confidentiality, where sender and receiver share the same secret key. It is the workhorse; everything later in the chapter exists to fix what it cannot do alone. Concrete use: data at rest is protected this way — full-disk encryption (BitLocker, LUKS) and AES-encrypted database columns mean a stolen laptop, disk, or backup yields only ciphertext, not the records.
Requirement 2 is a paradox the professor states bluntly: "to get a secure communication channel you need a secure channel." How do online banking or e-commerce work with two strangers who never met? This unanswerable question is exactly the motivation for public-key cryptography (Section 12). Connection: symmetric crypto is fast and confidential but stuck on distribution; asymmetric crypto is slow but solves distribution — which is why real systems combine them (the digital envelope, Section 15).
Punchline: symmetric encryption is the cheap, fast confidentiality engine — its single weakness is getting the shared key to the other side in the first place.
The same two attacks from the Caesar cipher scale up, and the consequence sharpens: if either attack recovers the key, all past and future messages under that key are compromised.
A smart attacker does not start from random keys. If the key is a human-chosen word, trying every word in a dictionary (a list of common/leaked passwords) collapses the search space dramatically. Distinction: brute force over the full key space assumes a random key; a dictionary attack assumes a guessable one. This is the bridge to the password material in Chapter 3 (salting and key stretching exist to defeat exactly this). CIA: breaks Confidentiality.
Adjust the decryption speed to see how long it takes to break each key size (time shown for half the key space).
| Key size | Cipher | Keys | Time required |
|---|
Punchline: a broken key is catastrophic, not local — it retroactively exposes every message ever sent under it, which is why key size is non-negotiable.
Three standards tell the story of "how big must the key be?". The professor's rule of thumb: prefer an international standard over a proprietary design (open design again). Memorize the numbers — they are graded directly.
| Feature | DES | Triple DES (3DES) | AES |
|---|---|---|---|
| Plaintext block size | 64 bits | 64 bits | 128 bits |
| Ciphertext block size | 64 bits | 64 bits | 128 bits |
| Key size | 56 bits | 112 or 168 bits | 128, 192, or 256 bits |
| Status | Insecure (broken) | Slow but secure | Fast and secure (current standard) |
DES takes a 64-bit plaintext block and a 56-bit key and produces a 64-bit ciphertext block. It is likely the most-studied cipher ever, with some cryptanalytic curiosities but no relevant structural weakness. Its fatal flaw is the key size: 56 bits is far too small. The concrete loss: in 1998 the EFF broke DES in under 3 days with special hardware; by 1999 a distributed effort broke it in about 22 hours. Is DES secure? No — the algorithm is sound but the ~7.2 x 1016 key space is searchable in hours today. A second, quieter problem is the 64-bit block size, too small for modern data volumes. (Historical aside: the NSA pushed IBM toward a 48-bit key; they compromised on 56 — not even a power of two.)
3DES is literally "execute DES three times", using two or three distinct keys for a total of 112 or 168 bits. This defeats brute force while reusing the well-vetted DES core (and the same hardware accelerators). Its disadvantages: it is about three times slower than DES (three passes of a 1970s design built for hardware, not efficient software), and the block size is still 64 bits — too small. So 3DES is "secure but a stopgap".
AES (Rijndael) was chosen through an open public competition — the embodiment of open design and the reason it is trusted. It uses a 128-bit block and keys of 128, 192, or 256 bits. Why AES beats 3DES: (1) larger block (128 vs 64), (2) far better performance, with dedicated AES instructions in modern CPUs, (3) multiple key sizes, (4) thorough public vetting. It is fast and secure and is the current standard.
Punchline: DES died of a small key, 3DES survives but limps, AES wins by being big, fast, and chosen in the open — the exam answer is always "block size, key size, speed, and how it was vetted".
Problem. Real data is bigger than one 64- or 128-bit block, so you must encrypt many blocks. Simplest solution — Electronic CodeBook (ECB):
Because each block is independent, identical plaintext blocks produce identical ciphertext blocks. Patterns in the plaintext (image regions, repeated headers) survive into the ciphertext and feed cryptanalysis. Concrete example: encrypt a bitmap image block-by-block in ECB and the original picture's outline stays clearly visible in the ciphertext (the well-known "ECB penguin") — identical pixel blocks map to identical ciphertext blocks. Worse, an attacker can reorder or replay whole blocks and each still decrypts cleanly, silently changing the message's meaning. CIA: the pattern leakage erodes Confidentiality; the reordering attack breaks Integrity. More advanced modes (CBC and others) add diffusion at a cost; their internals are out of scope here — what is tested is why ECB is weak.
Shared problem: both turn plaintext into ciphertext under a key. The difference and its consequences:
| Axis | Block cipher | Stream cipher |
|---|---|---|
| Unit processed | One fixed-size block at a time (64 / 128 bits) | Input processed continuously, one byte at a time |
| Key reuse | Can reuse keys (and usually do) | Same key = same keystream; never reuse a key |
| Padding | May need padding on the last block | No padding |
| Speed / size | Slower, more code | Almost always faster, far less code |
| When to use | File transfer, e-mail, databases | Data-communication channels, browser links |
A stream cipher feeds the key into a pseudorandom bit generator to produce a keystream, then XORs it with the plaintext; the same key always reproduces the same keystream, and the secret key is never sent in the clear. Properly designed, a stream cipher is as secure as a block cipher of comparable key length. When to use which: reach for a stream cipher when data arrives as a continuous flow (a network link); reach for a block cipher when you have whole files or records.
Punchline: ECB proves that a strong cipher used naively is still weak — confidentiality of the algorithm is not confidentiality of the message.
Everything so far buys confidentiality. But Chapter 1's active attacks (masquerade, falsification, replay) target integrity and authenticity, and encryption alone does not stop them. This section is the pivot in the chain: same asset, different threat, different tool.
Authenticity means a message is genuine: it was not altered and it came from the claimed source. Cryptography can provide it — through digital signatures, a MAC, or a hash combined with encryption — but the tool is not plain symmetric encryption.
Three reasons, each a concrete attack:
Shared problem: both defeat replay by making a recorded message un-reusable. How each works: a nonce is a fresh random value generated per message; the receiver rejects any nonce it has already seen. A timestamp stamps each message with the clock time; the receiver accepts only messages inside a recent window. Consequence of the difference: nonces need a secure random source and a memory of values already seen, but no shared clock; timestamps need synchronized clocks and break if clocks drift or an attacker manipulates system time. When to use which: nonces for interactive session/handshake authentication (high-security cryptographic protocols); timestamps for logged or stored data where a reliable shared clock already exists.
Punchline: a message can be perfectly secret and still be forged, reordered, or replayed — confidentiality and authenticity are different jobs needing different tools.
Motivation. To detect tampering you need a tiny, fixed-size "fingerprint" of a message that changes if even one bit changes. That fingerprint is the output of a hash function, and it is the building block under both MACs and signatures.
A secure (one-way) hash function H takes a variable-size input and produces a fixed-size output — the hash value, message digest, or fingerprint. It is "one-way" because you cannot run it backwards. Note: a hash takes no key (this is the line that separates it from a MAC).
Properties 1-3 make it usable; 4-6 make it secure. A collision is two different inputs with the same hash; a function is collision resistant when finding one is computationally impossible. Why it matters: if an attacker can find a collision, they can swap a benign document for a malicious one with the same fingerprint and break Integrity on anything that trusts the digest (including signatures and certificates). Concrete cases: MD5 collisions were used to forge a rogue CA certificate (2008) and helped the Flame malware fake a Microsoft code-signing certificate (2012); SHA-1 fell to the 2017 SHAttered attack, which produced two distinct PDF files sharing the same hash.
The SHA (Secure Hash Algorithm) family is the standard. SHA-0 and SHA-1 (160-bit) are retired after cryptanalytic breaks. SHA-2 (SHA-256 / SHA-384 / SHA-512) is the current workhorse and shares SHA-1's internal structure. SHA-3 (2015) uses a deliberately different construction as a hedge.
Punchline: a hash is integrity compressed into a fixed string — and the birthday paradox means you always get only half the bits of security you would expect against collisions.
A bare hash gives integrity but not source authentication: anyone can recompute H(message), so anyone can also forge a matching fingerprint for a forged message. Adding a shared secret fixes this.
A Message Authentication Code (MAC) is a small block of data generated from the message and a secret key, then appended to the message. The receiver, who shares the key, recomputes the MAC and compares. A match assures: (1) the message was not altered, (2) it is from the alleged sender (the only other holder of the key), and (3) with sequence numbers, that ordering is correct. A MAC does NOT provide confidentiality — the message itself is not encrypted. Concrete use: TLS and IPsec authenticate every record or packet with a keyed-hash MAC (e.g. HMAC-SHA-256), so any tampering in transit is detected. CIA: Integrity + authenticity.
A MAC uses a secret key directly, so only key-holders can produce or verify it — that is what delivers source authentication. A plain hash uses no key; on its own it gives integrity but not authentication, because anyone can compute it. To turn a keyless hash into authentication you must encrypt the digest or fold in a secret (the keyed-hash MAC). Composition to remember: MAC = hash + shared secret; signature (next) = hash + asymmetric encryption.
Punchline: a hash proves nothing changed; a MAC also proves who sent it — the secret key is the whole difference.
Beyond authentication and signatures, the one-way property alone is useful:
Operating systems and online services store only the hash of each password, never the plaintext. At login the entered password is hashed and compared. If the password file leaks, the actual passwords are not directly revealed — this relies on preimage resistance. (Why plaintext is never stored, and the salting/stretching that hardens this against dictionary and rainbow-table attacks, is the start of Chapter 3.) CIA: a leak of hashes limits the loss of Confidentiality.
Compute and securely store the hashes of critical files; periodically recompute and compare. A changed hash means a changed file (e.g. malware tampering) — a Integrity check. Two caveats the professor stresses: it is costly, so you hash only critical files rather than the whole disk; and it only works if the verification tool itself is not compromised.
Punchline: one-wayness turns a hash into a safe to store secrets in and a tripwire to detect tampering — same property, two defenses.
Problem. Symmetric crypto cannot solve key distribution between strangers (Section 4). Solution: public-key cryptography (Diffie and Hellman, 1976; the theoretical basis was found earlier at GCHQ and kept classified until 1997). Every user has two keys:
The pair is linked by hard mathematical problems so that deriving the private key from the public key is computationally infeasible. The pair must be generated together, atomically: the two keys are mathematically bound (e.g. RSA's prime factors), so they cannot be made independently and matched up afterwards — key generation is the one operation that must be atomic. Concrete deployment: HTTPS/TLS uses RSA or ECC public keys to set up each secure web session, and SSH uses public-key pairs to authenticate logins without sending a password.
Why must it be atomic? The public key (RSA's (e, n)) and private key (d, n) are not independent pieces of data — they emerge from a single mathematical construction. Whoever knows the primes p and q can compute both keys; whoever holds only the public key would have to factor n to recover the private key, which is computationally infeasible. Key generation IS the moment the trapdoor (knowledge of p and q) is created — this is a trapdoor one-way function. Generating the two keys separately would either expose that trapdoor to both parties (defeating the scheme) or fail to create the asymmetry at all. The mathematical link between the keys is the algorithm itself.
Bob encrypts with Alice's public key; only Alice's private key can decrypt. This gives confidentiality — even Bob cannot read it back, and an interceptor without Alice's private key is helpless. This is how confidentiality is guaranteed in asymmetric crypto. CIA: Confidentiality.
Bob: ciphertext = E(Alice_public, plaintext) Alice: plaintext = D(Alice_private, ciphertext)
Bob encrypts with his own private key; anyone with Bob's public key can decrypt, proving it came from Bob. This gives authenticity and integrity but NOT confidentiality — the public key is public, so anyone can read it. This direction is the seed of the digital signature. CIA: Integrity + authenticity (not Confidentiality).
Bob: ciphertext = E(Bob_private, plaintext) Alice: plaintext = D(Bob_public, ciphertext)
| Algorithm | Signature | Key exchange | Encryption |
|---|---|---|---|
| RSA (most widely used) | Yes | Yes | Yes |
| Diffie-Hellman | No | Yes (key agreement only) | No |
| DSS / DSA | Yes | No | No |
| Elliptic Curve (ECC) | Yes | Yes | Yes |
ECC is the main rival to RSA: comparable security at much smaller key sizes.
How does Alice know a key labelled "Bob's public key" is really Bob's? An impostor can publish a fake "Bob's public key" and a man-in-the-middle then reads everything sent to Bob and impersonates him. CIA: Confidentiality (the attacker reads the traffic) and Integrity/authenticity (a masquerade, in Chapter 1's terms). This public-key authentication problem is what certificates (Section 14) exist to solve.
Punchline: two keys dissolve the key-distribution paradox but introduce a new one — you can now publish a key freely, but how does anyone know it is yours?
A digital signature authenticates both the source and the data integrity of a message. It is the composition we have been building toward: a one-way hash plus asymmetric encryption used in the "private key" direction — sign the fingerprint, not the whole message. Concrete use: software publishers sign their executables (Authenticode, GPG-signed packages) so the operating system can prove the binary came from them and was not altered; signed e-mail (S/MIME, PGP) proves authorship of a message.
Guarantees: (1) source authentication — it is from the claimed sender; (2) data integrity — it was not altered; (3) non-repudiation — the sender cannot later deny it (only they hold the private key — this is the extra guarantee a public-key system adds over a shared-key MAC). Does NOT guarantee confidentiality — the message itself is not encrypted, and since the public key is public, anyone can read both the message and the signed hash. CIA: Integrity + authenticity, never Confidentiality. Add confidentiality only by also encrypting (Section 15-16).
Standard signature algorithms: DSA (discrete logarithms), the RSA signature, and ECDSA (elliptic curve).
Punchline: a signature is a MAC's public-key cousin — it adds non-repudiation precisely because the signing key is not shared.
Section 12 left an open wound: a public key is only useful if you can trust whose it is. The fix is to have a trusted third party vouch for the binding.
A Certificate Authority (CA) is a trusted third party that verifies a requester's identity and then signs a statement binding that identity to its public key. A public-key certificate is that signed data structure: it contains the owner's identity and public key, the CA's information, a validity period, and the CA's digital signature. The signature is what makes it unforgeable — a certificate is just a digital signature applied to "this key belongs to this person". X.509 is the universal certificate format (used in TLS, SSH, S/MIME, IPsec).
Only the CA holds the CA's private key, so only the CA could have signed it. Forging a certificate would need the CA's private key or a hash collision — both infeasible. Browsers and operating systems ship with a built-in list of trusted CAs' public keys, used to verify the certificates that sites such as Amazon and Google present.
An attacker who poisons DNS redirects a user to a fake site. Under HTTPS the browser checks the certificate: if the certificate's domain does not match, or it is self-signed (no recognized CA), the browser warns. CIA: pharming is a Chapter 1 masquerade / deception, threatening Confidentiality and Integrity; certificates are the countermeasure that detects it.
Punchline: certificates do not remove the need for trust — they relocate it from "every stranger's key" to "a handful of CAs", which is a trust problem small enough to ship in a browser.
Problem. Asymmetric encryption solves key distribution but is far too slow for bulk data; symmetric encryption is fast but needs a pre-shared key. Solution: use each for what it is good at — the digital envelope, equivalent to a sealed envelope containing an unsigned letter. It protects a message without sender and receiver having pre-arranged a shared secret.
CIA: Confidentiality. When to use: whenever two parties who never shared a key need confidentiality — encrypted e-mail, secure messaging between first-time correspondents. Concrete scenario: Bob e-mails Alice, whom he has never met, with no pre-shared key — he generates a one-time AES key, encrypts the message with it, encrypts that AES key with Alice's public RSA key, and sends both (this is exactly what PGP/GPG encrypted e-mail does). Distinction: an envelope gives confidentiality; a signature gives authenticity — combine both for full protection (next section).
Punchline: the envelope is the real-world compromise — public-key crypto only ever encrypts a one-time symmetric key, so you get its key-distribution magic at symmetric speed.
The two procedures the exam loves are just compositions of the parts above. State the purpose of each step.
Match => authentic and unmodified. The message is not encrypted, so there is no confidentiality (an eavesdropper reads it; CIA harmed: Confidentiality, while Integrity/authenticity are protected).
Apply both procedures in sequence — a digital envelope for secrecy, a signature for authenticity:
GPG (GnuPG) is a full implementation of the OpenPGP standard for secure communication: symmetric and asymmetric ciphers, encrypted e-mail, file encryption, and signatures. Its distinction from the CA model: GPG uses a decentralized web of trust instead of central Certificate Authorities. OpenSSL is the open-source library and command-line toolkit behind much of TLS/SSL: it implements the ciphers (DES, 3DES, AES), hashes (SHA), and public-key algorithms (RSA, DSA, ECC), and is the standard way to actually encrypt, sign, and benchmark.
Punchline: "secure e-mail" is not one primitive but a stack — envelope for secrecy, signature for authenticity — and naming which step buys which CIA property is exactly what the high grade rewards.
Why it belongs here. Almost every tool above silently depends on good randomness: generating public-key pairs, stream-cipher keystreams, one-time session keys, the random symmetric key in a digital envelope, and handshaking nonces that prevent replay attacks. A predictable "random" number quietly breaks all of them.
| Axis | TRNG (true) | PRNG (pseudorandom) |
|---|---|---|
| Source | Nondeterministic physical process (thermal noise, radiation, leaky capacitors) | Deterministic algorithm |
| Output | Genuinely unpredictable | Statistically random but predictable if the seed is known |
| Cost | Often needs special hardware (now common on modern CPUs) | Pure software |
| Used for | Seeds, high-security key generation | Most cryptographic use, seeded by a TRNG |
Hardware RNGs raise a question: do you trust your CPU vendor? The Dual_EC_DRBG case (a standardized generator later suspected of an NSA backdoor) shows the concern is real. Concrete failure: the 2008 Debian OpenSSL bug accidentally removed almost all entropy from key generation, shrinking the pool of possible SSH and TLS keys to a few thousand predictable values — every affected key had to be regenerated and revoked. A weak generator silently breaks an otherwise perfect cipher. Cross-link: this is Chapter 1's trust-boundary question applied to entropy — choose your random source according to your threat model.
Punchline: cryptography is only as unpredictable as its randomness — a guessable key generator silently undoes a perfect cipher.
The looming threat. Quantum computers exploit quantum parallelism to speed up some computations, and the effect on cryptography is sharply asymmetric:
The response is post-quantum cryptography: new public-key schemes built on problems believed quantum-resistant (lattice-based, code-based, multivariate), now being standardized and rolled into software including browsers.
Punchline: remember the split — symmetric crypto survives quantum by growing its keys; public-key crypto must be replaced outright.
Symmetric cryptography uses the same secret key for both encryption and decryption. The sender encrypts the plaintext with a secret key and a cipher algorithm; the receiver decrypts the ciphertext using the same key and the inverse algorithm. Security depends on: (1) a strong algorithm, and (2) secure key distribution between sender and receiver. The key must be kept secret by both parties.
Two main approaches: (1) Cryptanalysis — exploits logical weaknesses in the algorithm itself, using knowledge of plaintext characteristics or known plaintext-ciphertext pairs. (2) Brute-force attack — tries every possible key. Feasibility depends on key size and computational speed. If an attack succeeds, all past and future messages encrypted with that key are compromised.
Cryptanalysis is the study of attacking cryptographic systems by exploiting the characteristics of the algorithm rather than trying all keys. It uses knowledge of the algorithm's structure, statistical properties of the plaintext, and sometimes known plaintext-ciphertext pairs to deduce the key or plaintext without brute-forcing the entire key space.
A brute-force attack tries every possible key until the ciphertext decrypts to intelligible plaintext. On average, half of all possible keys must be tried to achieve success. If there are x distinct keys, the expected number of attempts to find the correct key is x/2.
DES (1977): 56-bit key, 64-bit block — now insecure due to small key size. 3DES: repeats DES three times with 112 or 168-bit key — slow but secure, uses 64-bit blocks. AES (2002): 128-bit blocks, key sizes 128/192/256 — fast, secure, the current standard. DES was broken by EFF in 1998. 3DES is slow due to three passes of a 1970s design. AES is efficient, thoroughly vetted, and has hardware acceleration in modern CPUs.
Two main problems: (1) Key size is too small — 56 bits provides only ~7.2*1016 possible keys, which can be searched in hours with modern hardware. (2) The 64-bit block size is too small for modern security requirements. Additionally, the algorithm is sluggish in software since it was designed for 1970s hardware.
3DES can use either two (112-bit key) or three (168-bit key) unique keys. The algorithm repeats DES three times: encrypt-decrypt-encrypt (EDE) when using two keys, or encrypt-encrypt-encrypt with three distinct keys.
(1) Sluggish performance — requires three times the computation of DES, and DES itself was designed for hardware, not efficient software. (2) 64-bit block size is too small and limits security for large data volumes. (3) Despite being secure, it is not suitable for long-term use due to efficiency concerns.
AES offers: (1) Larger block size — 128 bits vs 64 bits. (2) Better performance — designed for efficient software and hardware implementation; modern CPUs have dedicated AES instructions. (3) Multiple key sizes — 128, 192, or 256 bits. (4) Thorough public vetting — selected through an open NIST competition from 15 proposals.
ECB (Electronic CodeBook) divides the plaintext into fixed-size blocks and encrypts each block independently with the same key. Disadvantages: (1) No diffusion — identical plaintext blocks produce identical ciphertext blocks, revealing patterns. (2) Vulnerable to block reordering — an attacker can reorder ciphertext blocks to alter the meaning of the decrypted message. These weaknesses make ECB unsuitable for encrypting large or structured data.
Stream ciphers encrypt data one byte at a time, continuously, using a keystream generated from the key XORed with the plaintext. They are faster and use less code but keys cannot be reused. Block ciphers encrypt data in fixed-size blocks, can reuse keys, and may require padding. Stream ciphers are preferred for data communications channels and browser links; block ciphers are more common for file transfer, email, and databases, though either can be used in most applications.
Authenticity means verifying that a message is genuine and came from its alleged source. Cryptography provides authenticity through: (1) Digital signatures — the sender encrypts a hash with their private key. (2) MAC (Message Authentication Code) — a secret key is used to generate an authentication tag. (3) Hash functions combined with encryption — the hash is encrypted and attached to the message.
Symmetric encryption alone is insufficient because: (1) Block reordering — in ECB mode, an attacker can reorder ciphertext blocks and each still decrypts successfully, altering the message's meaning. (2) It does not prevent replay attacks. (3) It provides no non-repudiation — both parties share the same key, so neither can prove which party sent a given message.
A MAC is a small block of data generated using a secret key and a message as input. It is appended to the message for transmission. The receiver recomputes the MAC using the same key and compares it to the received MAC. If they match, the receiver is assured that: (1) the message has not been altered, (2) the message is from the alleged sender (who shares the secret key), and (3) if sequence numbers are used, the proper sequence is maintained.
A one-way hash function takes a variable-size input message and produces a fixed-size output called a hash value or message digest. It is "one-way" because it is computationally infeasible to reverse: given a hash value h, finding x such that H(x) = h is infeasible (preimage resistance). Unlike MAC, a hash function does NOT use a secret key as input.
A MAC incorporates a secret key directly into the algorithm; only parties sharing that key can generate or verify the tag. A one-way hash function alone does not use a key — to provide authenticity, the hash must be encrypted (symmetric or asymmetric) or combined with a secret value (keyed hash MAC). Without this step, anyone can compute the hash of a message, so it provides integrity but not source authentication.
A message digest is the fixed-size output of a hash function. When public-key encryption is used to encrypt the digest, it provides non-repudiation in addition to authenticity: because only the sender has their private key, they cannot later deny having signed the message. This is the basis of digital signatures.
Keyed Hash MAC combines a secret key with a hash function. Both sender and receiver share a secret key K. The sender computes H(K || M || K) (hash of key || message || key) and sends the message plus this hash. The receiver, knowing K, recomputes and verifies. Using the key as both prefix and suffix is more secure than using it as only one or the other.
(1) Applies to data of any size. (2) Produces fixed-length output. (3) Easy to compute. (4) One-way (preimage resistant): given h, infeasible to find x with H(x)=h. (5) Second preimage resistant: given x, infeasible to find y!=x with H(y)=H(x). (6) Strong collision resistant: infeasible to find any pair (x,y) with H(x)=H(y). Properties 1-3 are practical requirements; 4-6 are security requirements.
Two approaches: (1) Cryptanalysis — exploits logical weaknesses in the algorithm. (2) Brute-force — depends on the length n of the hash code. For preimage resistance: effort is ~2n. For collision resistance: effort is ~2n/2 (due to the birthday paradox). A 128-bit hash provides only 64-bit security against collision attacks.
The SHA (Secure Hash Algorithm) family is the most widely used. SHA-1 (160-bit) is now considered weak. SHA-2 (SHA-256, SHA-384, SHA-512) is the current standard. SHA-3 (standardized 2015) provides a structurally different alternative.
Two important applications: (1) Password storage — systems store only the hash of passwords, not the plaintext. (2) Intrusion detection — securely stored hash codes of critical files can be periodically recomputed and compared to detect unauthorized modifications.
Asymmetric (public-key) cryptography uses two different keys: one public and one private, linked mathematically but such that the private key cannot be derived from the public key. The public key is published widely; the private key is kept secret. Encryption with the public key can only be decrypted with the corresponding private key, and vice versa. This solves the key distribution problem of symmetric encryption.
To guarantee confidentiality, the sender encrypts the message using the receiver's public key. Only the receiver, possessing the corresponding private key, can decrypt it. Even the sender cannot decrypt the message afterwards (they don't have the receiver's private key). This ensures that only the intended recipient can read the message.
(1) Easy to generate key pairs. (2) Easy to encrypt (knowing public key). (3) Easy to decrypt (knowing private key). (4) Infeasible to determine private key from public key. (5) Infeasible to recover plaintext from ciphertext + public key. (6) Optionally, either key can be used for encryption with the other for decryption (as in RSA).
RSA (Rivest-Shamir-Adleman) — the most widely adopted. Diffie-Hellman — key exchange only. DSA/DSS — digital signatures only. Elliptic Curve Cryptography (ECC) — offers equivalent security with smaller key sizes, increasingly used in modern systems.
A digital signature is created by encrypting a message's hash code with the sender's private key. Guarantees: (1) Source authentication — confirms the sender's identity. (2) Data integrity — detects any modification. (3) Non-repudiation — the sender cannot deny sending it. Does NOT guarantee: confidentiality — the message itself is not encrypted and can be read by anyone.
The public-key authentication problem: how can one be sure that a public key belongs to the person it claims to? An attacker can publish a fake public key in someone else's name. This is solved by public-key certificates issued by trusted Certificate Authorities (CAs).
A CA (Certificate Authority) is a trusted third party that issues digital certificates. The CA verifies the identity of the certificate requester and then digitally signs the certificate binding the requester's identity to their public key. Browsers and operating systems come with a pre-installed list of trusted CAs whose public keys are used to verify certificates.
A public-key certificate is a data structure that binds a public key to the identity of its owner. It contains: the user's identity and public key, information about the CA, a validity period, and a digital signature from the CA. The signature ensures the certificate cannot be forged. X.509 is the universally accepted standard format.
The CA: (1) takes the unsigned certificate (containing user ID + public key), (2) computes a hash code of it, (3) encrypts the hash using the CA's private key to create a digital signature, and (4) attaches the signature to the certificate. The resulting signed certificate can be verified by anyone using the CA's public key.
A digital envelope combines symmetric and asymmetric encryption: the message is encrypted with a random symmetric key (fast), and that symmetric key is encrypted with the recipient's public key (secure). Both are sent together. It is used when the sender and receiver do not have a pre-arranged shared secret key, for example in email encryption or secure messaging between parties who have never communicated before.
Random numbers = truly unpredictable, statistically independent values. Pseudorandom numbers = generated by deterministic algorithms, statistically random but predictable if the seed is known. True Random Number Generators (TRNG) exist and use physical processes: thermal noise (Intel DRNG), radioactive decay, atmospheric noise. Most cryptographic applications use PRNGs seeded by TRNG outputs.
GPG (Gnu Privacy Guard) is a complete implementation of the OpenPGP standard for secure communication. It uses public-key encryption for secure email, file encryption, and digital signatures. GPG implements both symmetric and asymmetric ciphers and uses a "web of trust" model for public-key authentication (instead of centralized CAs).
The Caesar cipher is a substitution cipher used by Julius Caesar. Each letter in the plaintext is shifted a fixed number of positions in the alphabet. The shift value is the secret key. With a shift of 3, A->D, B->E, etc. It has only 25 possible keys, making it trivially breakable by brute force.
A cipher is an algorithm used to encrypt and decrypt data. Examples include: Caesar cipher (historical substitution cipher), DES (56-bit symmetric block cipher, now broken), AES (modern symmetric block cipher, current standard), RSA (public-key algorithm), and SHA (hash function family).
The sender: (1) composes the message, (2) generates a random symmetric key, (3) encrypts the message with the symmetric key (for confidentiality), (4) encrypts the symmetric key with the recipient's public key (digital envelope), (5) computes a hash of the message, (6) encrypts the hash with the sender's private key (digital signature). The recipient: uses their private key to decrypt the symmetric key, then the symmetric key to decrypt the message; uses the sender's public key to verify the signature. This provides confidentiality, authentication, integrity, and non-repudiation.
(1) Compose the message. (2) Compute a hash of the message. (3) Encrypt the hash with the sender's private key — this is the digital signature. (4) Send the message (in plaintext) plus the signature. The recipient: (1) computes the hash of the received message, (2) decrypts the signature using the sender's public key, (3) compares the two hashes. If they match: the message is authentic and unmodified. Note: the message is not encrypted, so confidentiality is not provided.
Atomicity in asymmetric cryptography refers to the fact that the key generation operation — which creates the mathematically linked public-private key pair — must be atomic. Both keys must be generated together in a single operation; they cannot be generated independently and then linked. The public and private keys are inherently tied by the underlying mathematical structure (e.g., RSA's prime factorization).
No, DES is not secure. Its 56-bit key is too small by modern standards: a brute-force attack can break it in hours using modern hardware (EFF broke DES in less than 3 days in 1998; current hardware is far faster). While the algorithm itself has no fatal cryptanalytic weaknesses, the key space of ~7.2*1016 keys is searchable.
Two ways: (1) Brute force — try all 25 possible shifts; the correct one will produce readable text. (2) Frequency analysis — in human languages, letters have different frequencies. By analyzing letter frequencies in the ciphertext and comparing to known language distributions, the shift can be deduced without trying all keys.
The diagram shows a sender encrypting with the receiver's public key and the receiver decrypting with their private key. This provides confidentiality. Applications: secure email (PGP/GPG), HTTPS/TLS (web browsing), encrypted messaging, and digital envelopes. In all these cases, the sender obtains the recipient's public key (from a certificate or key server), encrypts the message, and only the intended recipient can decrypt it.
OpenSSL is an open-source software library providing cryptographic functions and command-line tools. It implements symmetric ciphers (DES, 3DES, AES), hash functions (SHA family), public-key algorithms (RSA, DSA, ECC), and protocols (TLS/SSL). The openssl enc command can encrypt/decrypt files, openssl speed benchmarks cipher performance, and it is widely used to test cryptographic assumptions (e.g., brute-force feasibility).
Symmetric encryption uses a single shared secret key for both encryption and decryption. Asymmetric (public-key) encryption uses two keys: a public key (for encryption) and a private key (for decryption), where the private key cannot be derived from the public key.
This provides authentication (and data integrity), because only the sender possesses their private key. However, confidentiality is NOT provided — anyone with the sender's public key can decrypt the message.
3DES was created to extend the life of DES by increasing the key size to 112 or 168 bits, overcoming DES's vulnerability to brute-force attacks. It reuses the well-studied DES algorithm, providing confidence in its resistance to cryptanalysis, while the larger key makes brute-force infeasible.
The birthday paradox shows that for collision resistance, the security level is only 2n/2, not 2n. This means a 128-bit hash (like MD5) provides only 64-bit security against collision attacks — feasible to break with sufficient resources. This is why modern hashes need at least 256-bit outputs.
Public-key encryption is computationally expensive. By using it only to encrypt a small symmetric key (typically 128-256 bits) and using fast symmetric encryption for the (potentially large) message, digital envelopes achieve both security and performance. This is called hybrid encryption.
key. The algorithm, the system design, and the implementation can all be public. Only the cryptographic key must remain secret.
Symmetric algorithms remain secure with larger key sizes (effectively doubling needed length). Public-key algorithms (RSA, ECC, Diffie-Hellman) are fundamentally broken by Shor's algorithm and require entirely new post-quantum cryptographic algorithms.