Begin with a locked message
Imagine that a classmate slides this note across the table:
PHHW PH LQ WKH ODE
It does not look like ordinary English. Has the message been encrypted? Probably. Is it secure? That is a different question.
A readable message can be changed into an unreadable form with a simple rule. If an attacker can discover or try that rule quickly, the message is hidden only briefly. Cryptography is therefore not just about scrambling information. It is about protecting information against a clearly described attacker.
This topic establishes the vocabulary and reasoning used throughout the course.
Textbook connection: This lesson follows the foundations in Chapter 1 of Serious Cryptography, second edition. The chapter contains several advanced security models and constructions. We will build the concrete mental model first and return to the formal ideas as the course develops.
The basic encryption system
Encryption begins with information that someone wants to protect.
- Plaintext is the original, readable information.
- A cipher is the algorithm that performs encryption and decryption.
- A key is a value that controls how the cipher transforms the information.
- Ciphertext is the encrypted result.
- Encryption transforms plaintext into ciphertext.
- Decryption uses the appropriate key to recover the plaintext.
The basic path is:
plaintext + key → encryption → ciphertext
ciphertext + key → decryption → plaintext
Suppose the plaintext is MEET ME IN THE LAB and the cipher shifts every letter three places forward in the alphabet. The value 3 is the key. The resulting ciphertext is:
PHHW PH LQ WKH ODE
Decryption shifts each letter three places backward and returns the original message.
Encryption is not encoding
Encoding changes how information is represented so another system can store or transmit it. Base64 is an encoding. It uses a public, reversible procedure and no secret key.
Encryption is intended to protect information from someone who does not possess the required key. If a student changes hello into a Base64 string, the result may look unfamiliar, but anyone can reverse it. Unfamiliar text is not proof of encryption.
| Operation | Purpose | Secret required? | Example |
|---|---|---|---|
| Encoding | Represent data in another format | No | Base64 |
| Encryption | Protect data using a cipher and key | Yes, for the protected operation | AES encryption |
| Hashing | Produce a fixed-size digest | No secret in an ordinary hash | SHA-256 |
Hashing receives its own later topic. For now, remember that encryption is reversible with the proper key; an ordinary cryptographic hash is not designed to be reversed.
The Caesar cipher: useful for learning, unsafe for protection
The Caesar cipher shifts letters by a fixed number of positions. With key 3:
A → D
B → E
C → F
...
X → A
Y → B
Z → C
The key tells us how far to shift. A different key produces a different ciphertext.
The browser lab above lets you change the key and watch every letter move. This makes three ideas visible:
- The same plaintext and same key always produce the same ciphertext.
- Repeated plaintext letters produce repeated ciphertext letters.
- There are only 25 useful nonzero shifts to try.
That third fact breaks the cipher. An attacker does not need a clever mathematical shortcut. The attacker can try every possible shift and look for readable language. Trying an entire small set of keys is a brute-force search.
Worked example
Ciphertext:
KHOOR
Try shifting backward:
| Candidate key | Candidate plaintext |
|---|---|
| 1 | JGNNQ |
| 2 | IFMMP |
| 3 | HELLO |
Once HELLO appears, the attacker has a strong candidate. Context can confirm it.
The lesson is not that all substitution is useless. The lesson is that a secure modern cipher needs a key space and internal structure too large and complex for an attacker to search or predict with practical resources.
Never use a Caesar cipher, Vigenere cipher, or a homemade cipher to protect real information. They are teaching models, not modern security controls.
A key is not the algorithm
Students often imagine that encryption works because outsiders do not know the method. That is fragile. Methods leak. Software can be inspected. Employees change jobs. Attackers can purchase the same product or read its documentation.
Kerckhoffs's principle says that a cryptographic system should remain secure even when the attacker knows how the system works. Security should depend on keeping the key secret, not on hiding the algorithm.
That principle lets the public examine and test widely used algorithms. A public algorithm is not automatically weak. AES is publicly documented. Its security depends on the key and correct use, not on pretending that no one knows AES exists.
Compare two claims:
Weak claim: “Our encryption is safe because no one knows our special algorithm.”
Better claim: “The algorithm is public and reviewed. Each authorized user receives a protected key, and an attacker who knows the algorithm still cannot feasibly recover the plaintext without that key.”
The better claim can still fail if keys are exposed or the algorithm is used incorrectly. Kerckhoffs's principle removes one dangerous assumption; it does not solve every implementation problem.
Symmetric and asymmetric encryption
There are two main key arrangements.
Symmetric encryption
In symmetric encryption, the same secret key is used to encrypt and decrypt, or the decryption key can be directly derived from the encryption key.
shared secret key → encrypt
shared secret key → decrypt
Symmetric encryption is fast and works well for protecting large amounts of data. The difficult question is how the authorized parties obtain and protect the shared secret.
Examples later in the course include AES and ChaCha20.
Asymmetric encryption
In asymmetric encryption, the keys are different:
- A public key may be shared.
- A private key must remain secret.
Someone can use a recipient's public key for an allowed public operation, while only the private-key holder can perform the corresponding private operation.
public key → encrypt for the owner
private key → decrypt
This is a simplified first model. Public-key systems also support digital signatures and key agreement, and real systems commonly combine asymmetric and symmetric techniques. RSA, Diffie-Hellman, and elliptic curves receive their own topics.
| Question | Symmetric | Asymmetric |
|---|---|---|
| Key arrangement | Shared secret | Public/private pair |
| Main advantage | Fast for large amounts of data | Helps with key distribution and identity-related operations |
| Main challenge | Sharing and protecting the secret | More computation and more complex trust decisions |
| Later examples | AES, ChaCha20 | RSA, elliptic-curve systems |
Data at rest and data in transit
Encryption is applied in different situations.
Data at rest is stored data: a file on a drive, a database record, or a backup. At-rest encryption helps if someone steals storage media or gains access to stored ciphertext without the key.
Data in transit is moving between systems: a browser request, a chat message crossing a network, or data sent to a cloud service. In-transit encryption helps prevent network observers from reading the traffic.
These protections do not automatically replace one another. A database may encrypt its disk while an export is emailed without transport protection. A secure network connection may protect traffic while the receiving computer saves the plaintext in an exposed folder.
Ask where the information is readable, where it is encrypted, who holds the key, and which attacker is being considered.
“Secure” is incomplete by itself
Saying “this cipher is secure” leaves important questions unanswered.
Name the security goal
What must the system protect?
- Confidentiality: unauthorized parties should not learn the plaintext.
- Integrity: unauthorized changes should be detectable.
- Authenticity: the receiver should have evidence about who created the protected message.
Basic encryption aims primarily at confidentiality. Encryption alone does not automatically guarantee integrity or authenticity. Later topics introduce message authentication and authenticated encryption.
Name the attacker model
What can the attacker do?
- See one or many ciphertexts?
- Know part of the plaintext?
- Choose information that will be encrypted?
- Modify ciphertexts and observe errors?
- Steal the device or read the key file?
A design may resist a passive observer but fail when an attacker can modify messages or obtain the key. A useful security statement therefore combines a goal with assumptions about the attacker.
Repair the claim
Vague:
“The customer database is encrypted, so it is secure.”
Improved:
“The database is encrypted at rest to protect customer records from someone who obtains a copy of the storage volume but does not obtain the encryption key. Access to the running application and theft of the key require separate controls.”
The improved version states:
- what is protected;
- where encryption applies;
- what the attacker has;
- what the attacker does not have; and
- what remains outside the claim.
How encryption fails even when the idea sounds right
Common first failures include:
- using an obsolete or homemade cipher;
- choosing a key space that attackers can search;
- storing the key beside the ciphertext with the same access permissions;
- protecting data at rest but exposing it in transit;
- assuming that hiding the algorithm creates security;
- claiming confidentiality when the application also needs integrity; and
- ignoring what the surrounding application reveals through errors or behavior.
Cryptography is part of a system. The cipher matters, but key handling, software behavior, protocols, users, and attacker access matter too.
What to carry forward
Use this five-question check whenever you encounter encryption:
- What is the plaintext?
- What is the ciphertext?
- What key or keys are involved?
- What security property is needed?
- What can the attacker realistically do?
If a security claim cannot answer those questions, it is not ready to trust.
The next topic examines randomness. Keys, nonces, and many cryptographic operations depend on values an attacker cannot predict. A strong cipher supplied with predictable “random” values can still fail.