Encryption

Keeping data confidential, and checking that it has not been altered, are two of the most important jobs in computing. This lesson covers encryption — turning readable plaintext into unreadable ciphertext with a key — through the Caesar and Vernam ciphers and the symmetric / asymmetric distinction, and then covers hashing, a related-but-different one-way transformation used for password storage, file integrity and hash tables. Encryption and hashing are easy to confuse, so a clear contrast between them is built in throughout.

---

Spec Mapping

This lesson addresses the H446 1.3.1 content on encryption and hashing:

• Define encryption and explain the purpose of plaintext, ciphertext and keys.
• Describe the Caesar (substitution) cipher and the Vernam cipher (one-time pad), including XOR and the conditions for perfect secrecy.
• Distinguish symmetric and asymmetric encryption, including key exchange and typical uses.
• Explain hashing: what a hash function is, the properties of a good one, and its real uses (password storage with salting, file-integrity checks, hash tables).
• Explain clearly how hashing differs from encryption (no key, not reversible).

(This is a paraphrase of the specification content, not a verbatim quotation.)

---

What is Encryption?

Encryption transforms readable data (plaintext) into scrambled data (ciphertext) using an algorithm (cipher) and a key. The transformation is designed to be reversible: anyone with the correct key can decrypt the ciphertext back to the exact plaintext, while anyone without it sees only noise.

Term	Meaning
Plaintext	The original, readable data
Ciphertext	The scrambled, unreadable data
Cipher	The algorithm performing the transformation
Key	The secret value that parameterises the cipher
Encryption	Plaintext $\rightarrow$→ ciphertext
Decryption	Ciphertext $\rightarrow$→ plaintext

The vital principle is that security rests on the key, not on keeping the algorithm secret (Kerckhoffs's principle). Modern ciphers such as AES are public and heavily scrutinised; safety comes from the attacker not knowing the key.

---

Caesar Cipher

The Caesar cipher is a substitution cipher that shifts every letter a fixed number of places along the alphabet; the shift is the key, and the alphabet wraps around (after Z comes A).

Worked Example — shift of 3

Plain	A	B	C	D	E	F	G	…	X	Y	Z
Cipher	D	E	F	G	H	I	J	…	A	B	C

Encrypting HELLO with shift 3 gives KHOOR. We can express the shift arithmetically by numbering A–Z as $0$0–$25$25:

$c = (p + k) \bmod 26$c=(p+k)mod26

For example E is $p=4$p=4; with $k=3$k=3, $c = (4+3) \bmod 26 = 7 = \text{H}$c=(4+3)mod26=7=H. Decryption reverses it:

$p = (c - k) \bmod 26$p=(c−k)mod26

so KHOOR with $k=3$k=3 returns HELLO.

Why it is hopelessly weak

Aspect	Assessment
Key space	Only 25 useful shifts
Brute force	Try all 25 shifts in moments
Frequency analysis	The commonest ciphertext letter is probably E shifted
Verdict	Educational only — never real security

Frequency analysis is the deeper weakness: a Caesar shift preserves letter frequencies, just relabelled. Since E is the commonest letter in English, if the commonest ciphertext letter is H, the shift is almost certainly 3 — the cipher falls instantly, regardless of key space.

---

Vernam Cipher (One-Time Pad)

The Vernam cipher is, uniquely, provably unbreakable when its conditions are met — it offers perfect secrecy. It combines the plaintext with a random key of equal length using bitwise XOR.

XOR and why it works

A	B	A XOR B
0	0	0
0	1	1
1	0	1
1	1	0

XOR is its own inverse: if $C = P \oplus K$C=P⊕K then $P = C \oplus K$P=C⊕K, because $K \oplus K = 0$K⊕K=0. The same key both encrypts and decrypts.

Worked Example

Encrypt ASCII H (01001000) with a random key 10110101:

Operand	Binary
Plaintext H	01001000
Key (random)	10110101
Ciphertext = P XOR K	11111101

Decrypt by XORing the ciphertext with the same key:

Operand	Binary
Ciphertext	11111101
Key (same)	10110101
Plaintext = C XOR K	01001000 = H

The conditions for perfect secrecy

The proof of unbreakability holds only if all of these are true:

Condition	Why it matters
Key is truly random	Any pattern in the key is a pattern an attacker can exploit
Key is at least as long as the plaintext	A short, repeated key leaks structure
Key is used only once	Reuse lets an attacker XOR two ciphertexts and cancel the key
Key is kept completely secret	The key is the security

The reason perfect secrecy holds is elegant: for a given ciphertext, every plaintext of that length is equally possible, because some key would produce it. The ciphertext therefore reveals nothing about the plaintext — there is no statistical foothold for frequency analysis, unlike Caesar.

Why perfect secrecy is genuinely perfect

This is worth unpacking, because it is the only cipher with a mathematical proof of unbreakability and the contrast with Caesar is the heart of the topic. Take the 8-bit ciphertext 11111101 from above. An attacker who has only the ciphertext cannot make any progress, because for any plaintext byte they might guess, there exists exactly one key that would have produced this ciphertext from it:

Suppose the plaintext was	Then the key must have been	…which is a perfectly valid random key
H = 01001000	10110101	yes
A = 01000001	10111100	yes
Z = 01011010	10100111	yes

Because the key is truly random, every one of those keys is equally likely, so every candidate plaintext is equally likely after seeing the ciphertext as it was before. The ciphertext therefore carries zero information about the message — there is literally nothing to attack. Contrast Caesar, where the ciphertext preserves the plaintext's letter-frequency fingerprint, handing the attacker a statistical foothold; the one-time pad destroys that fingerprint completely.

The proof, however, leans entirely on the four conditions. Break any one and the magic evaporates — most dramatically key reuse: if the same key $K$K encrypts two messages, $C_1 = P_1 \oplus K$C1​=P1​⊕K and $C_2 = P_2 \oplus K$C2​=P2​⊕K, then an attacker who XORs the two ciphertexts gets $C_1 \oplus C_2 = P_1 \oplus P_2$C1​⊕C2​=P1​⊕P2​, eliminating the key entirely and leaking the relationship between the two plaintexts. The "one-time" in one-time pad is not a slogan; it is a load-bearing requirement.

Why it is rarely used in practice

• Generating truly random keys as long as the data is hard.
• The key is as long as the message, so storing/sending it is as costly as the data itself.
• Key distribution — getting that huge secret key to the recipient securely — is the same chicken-and-egg problem all shared-key schemes face.

---

Symmetric Encryption

In symmetric encryption the same key encrypts and decrypts.

flowchart LR
    P1["Plaintext"] --> E["Encrypt with key K"]
    E --> C["Ciphertext"]
    C --> D["Decrypt with same key K"]
    D --> P2["Plaintext"]

Algorithm	Key size	Status
DES	56 bits	Obsolete — key too short
3DES	112/168 bits	Legacy — being retired
AES	128/192/256 bits	Current standard

Advantage	Disadvantage
Fast — efficient for large data	Key must be shared secretly (key distribution problem)
Low computational overhead	If the key leaks, all messages are exposed
Ideal for encrypting stored data	No built-in authentication of the sender

---

Asymmetric Encryption

In asymmetric (public-key) encryption each party has a mathematically linked key pair: a public key anyone may hold, and a private key kept secret. What one key locks, only the other can unlock.

flowchart LR
    P1["Plaintext"] --> E["Encrypt with recipient's PUBLIC key"]
    E --> C["Ciphertext"]
    C --> D["Decrypt with recipient's PRIVATE key"]
    D --> P2["Plaintext"]

To send a confidential message you encrypt with the recipient's public key; only their private key can decrypt it, so the public key can be shared openly with no loss of secrecy. This neatly solves key distribution — no shared secret need ever travel.

The key-distribution problem it solves

It is worth being precise about why this is such a breakthrough. With symmetric encryption, both parties must already share one secret key — but how do you get that key to the other person in the first place? You cannot send it over the same insecure channel you are trying to protect, because an eavesdropper would simply copy it. For $n$n people who all want to talk privately in pairs, symmetric encryption needs a separate shared secret for every pair, which is $\frac{n(n-1)}{2}$2n(n−1)​ keys — for just 100 users that is $\frac{100 \times 99}{2} = 4{,}950$2100×99​=4,950 keys to generate and guard. Asymmetric encryption dissolves both problems at once: each person publishes one public key for the whole world to use and keeps one private key secret, so $n$n users need only $n$n key pairs, and nothing secret ever has to be transmitted — the public key can be shouted from the rooftops because it can only lock, never unlock.

Algorithm	Based on	Typical key size
RSA	Difficulty of factoring large semiprimes	2048–4096 bits
ECC	Elliptic-curve mathematics	256–384 bits
Diffie–Hellman	Secure key exchange	2048+ bits

Advantage	Disadvantage
No shared secret — solves key distribution	Much slower than symmetric
Enables digital signatures (authentication)	High computational cost
Each user needs just one key pair	Needs larger keys for equivalent strength

A conceptual RSA walkthrough (tiny verified numbers)

You will not be asked to perform full RSA in the exam, but seeing how the key pair is mathematically linked removes the mystery. RSA's security rests on a one-way asymmetry: multiplying two large primes is easy, but factoring their product back into those primes is, for big enough numbers, computationally infeasible. The tiny numbers below are far too small to be secure — they exist only to show the mechanism, and they are real, checkable values.

Key generation.

1. Choose two primes, $p = 3$p=3 and $q = 11$q=11.
2. Compute the modulus $n = p \times q = 33$n=p×q=33.
3. Compute $\phi = (p-1)(q-1) = 2 \times 10 = 20$ϕ=(p−1)(q−1)=2×10=20.
4. Choose a public exponent $e$e coprime to $\phi$ϕ; take $e = 7$e=7.
5. Find the private exponent $d$d such that $(e \times d) \bmod \phi = 1$(e×d)modϕ=1. Here $d = 3$d=3, since $7 \times 3 = 21 = 1\times 20 + 1$7×3=21=1×20+1, so $21 \bmod 20 = 1$21mod20=1.

The public key is the pair $(e, n) = (7, 33)$(e,n)=(7,33); the private key is $(d, n) = (3, 33)$(d,n)=(3,33). Note that $n$n is public, yet recovering $d$d from it would require knowing $\phi$ϕ, which requires factoring $n$n back into $3$3 and $11$11 — easy here, infeasible for 2048-bit primes.

Encrypting a message number $m = 4$m=4 with the public key, using $c = m^{e} \bmod n$c=memodn:

$c = 4^{7} \bmod 33 = 16384 \bmod 33 = 16$c=47mod33=16384mod33=16

Decrypting the ciphertext $c = 16$c=16 with the private key, using $m = c^{d} \bmod n$m=cdmodn:

$m = 16^{3} \bmod 33 = 4096 \bmod 33 = 4$m=163mod33=4096mod33=4

The original $4$4 returns. The two exponents are inverses modulo $\phi$ϕ, which is precisely why "what $e$e locks, only $d$d unlocks". Crucially, anyone can encrypt with the public $(7, 33)$(7,33), but only the holder of the private $3$3 can reverse it — confidentiality with no shared secret.

Digital signatures

Reversing the key roles gives authentication and integrity instead of confidentiality. The mechanism:

flowchart LR
    M["Message"] --> H["Hash the message"]
    H --> S["Encrypt hash with SENDER'S PRIVATE key = signature"]
    S --> T["Send message + signature"]
    T --> V["Receiver decrypts signature with SENDER'S PUBLIC key"]
    V --> C["Re-hash received message and compare"]

The sender hashes the message and encrypts that hash with their own private key to form a digital signature, sent alongside the message. The receiver decrypts the signature with the sender's public key (which only succeeds if it really was the sender's private key that made it, proving authenticity and non-repudiation), then independently hashes the received message and checks the two hashes match (proving integrity — the message was not altered in transit, since any change would yield a different hash). Note this combines both big ideas of the lesson — asymmetric keys and hashing — and it provides authentication, which symmetric encryption alone cannot.

A subtle point students miss: a signature does not hide the message (it travels in the clear); it proves who sent it and that it is unchanged. To get confidentiality as well, you would also encrypt the message with the recipient's public key — the two operations are independent.

---

Symmetric vs Asymmetric, and the Hybrid in Practice

Feature	Symmetric	Asymmetric
Keys	One shared secret	Public + private pair
Speed	Fast	Slow
Key distribution	Hard (must share secretly)	Easy (public key is open)
Best use	Bulk data	Key exchange, signatures
Examples	AES, DES	RSA, ECC

Real systems such as HTTPS/TLS use a hybrid scheme to get the best of both:

flowchart LR
    A["Use ASYMMETRIC to exchange a random symmetric key"] --> B["Then use fast SYMMETRIC (AES) to encrypt the actual data"]

Asymmetric solves key distribution for one small item — the session key — and fast symmetric encryption then protects the bulk traffic. This is the standard pattern examiners expect you to describe.

---

Hashing