The Project | About Us | Contribute | Donations | License
HOME My courses Completed
◄ Previous
◄

What Cryptography Is and What It's For

Next ►
►

Cryptography is the discipline that protects information in the presence of adversaries: people or systems trying to read it, alter it, or impersonate someone to obtain it. For a developer or an IT professional, cryptography isn't an academic luxury — it's the foundation behind the passwords you store, the session tokens you issue, the padlock icon a user sees in the browser, and the signature that guarantees a document hasn't been tampered with. In this first lesson we'll define what cryptography is (and isn't), look at the four goals it pursues, take a very brief historical tour, and introduce the running case study that will accompany us throughout the course: MediNube, a fictional SaaS platform for medical records.

Contents

  1. The four goals of cryptography
  2. A little history (very little): from Caesar to modern cryptography
  3. The modern cryptography landscape: symmetric, asymmetric, and hashes
  4. The MediNube case: our throughline
  5. A Python appetizer: the Caesar cipher
  6. Course roadmap

The four goals of cryptography

When someone says "cryptography," almost everyone thinks of "secret messages." But keeping something secret is only one of four fundamental goals. It's worth memorizing them from day one, because every cryptographic tool we'll cover in this course exists to serve one or more of them:

Goal Question it answers Everyday example Example in MediNube
Confidentiality Can only the people who should be able to read this? No one else reads your WhatsApp messages Patient Ana Pérez's medical record is only seen by authorized doctors at Clínica Sol
Integrity Has the data been modified since it was created? A downloaded installer isn't corrupted or trojanized No one has changed a medication dosage in a stored prescription
Authenticity Who actually generated this data or message? The text message from your bank really is from your bank The request to the MediNube API comes from Clínica Sol's official app, not an impostor
Non-repudiation Can the author later deny having done it? An electronic signature on a contract The doctor who signed an electronic prescription can't deny having issued it

A few important nuances:

  • Confidentiality doesn't imply integrity. A message can be unreadable to an attacker and still be modifiable blindly. This nuance, which surprises almost every beginner, we'll cover in depth when we discuss authenticated encryption (module 2).
  • Authenticity and non-repudiation look alike, but they aren't the same. If you and I share a secret key, I can verify a message comes from you (authenticity between the two of us)... but I can't prove it to a judge, because I could have created it too. Non-repudiation requires that only the author can produce the proof, and that requires digital signatures (module 4).
  • There are secondary goals (availability, anonymity, message freshness...) that we'll touch on as they come up, but these four are the core.

A useful mental model:

graph TD
    C[Cryptography] --> O1[Confidentiality<br/>only the right people can read it]
    C --> O2[Integrity<br/>hasn't been altered]
    C --> O3[Authenticity<br/>comes from who it claims to]
    C --> O4[Non-repudiation<br/>the author can't deny it]

What cryptography does NOT solve

It's just as important to know what falls outside its scope:

  • It doesn't replace access control. Encrypting the database is worthless if the application decrypts and shows the data to any logged-in user.
  • It doesn't fix vulnerable software. A SQL injection bypasses all the encryption in the world, because it attacks the application that already has the data in plaintext.
  • It doesn't protect against a compromised endpoint. If the doctor's laptop has malware, the attacker sees exactly what the doctor sees.

Cryptography is an (essential) piece of a secure system, not the whole system.

A little history (very little)

You don't need to be a historian to use cryptography well, but three milestones help explain why modern cryptography is the way it is:

  • The Caesar cipher (~50 BC). Julius Caesar shifted every letter of the alphabet by a fixed number of positions (with a shift of 3, A becomes D). It's trivial to break: there are only 25 possible shifts in the Latin alphabet, and trying all of them takes seconds. Lesson: a small key space is a death sentence.
  • Enigma (World War II). A German electromechanical machine with a key space that was enormous for its time. It was broken at Bletchley Park (with Alan Turing among others) by combining operational mistakes, predictable patterns in the messages, and calculating machines. Lesson: theory isn't enough; incorrect use and message patterns break "strong" systems. We'll see echoes of this in the modes of operation (module 2).
  • Modern cryptography (from ~1970 on). With the publication of DES, the work of Diffie and Hellman (1976), and RSA (1977), cryptography moved from secret military art to public science: published algorithms, analyzed by thousands of experts, with security grounded in mathematics rather than in the secrecy of the method. This idea — that the algorithm is public and only the key is secret — is Kerckhoffs's principle, the subject of lesson 01-04.

That's all the history we need. This is an applied course: we care about the cryptography deployed today, not archaeology.

The modern cryptography landscape

All the cryptography you'll use as a developer rests on three major families of primitives. Here we'll just introduce them; each one gets its own full module later on.

graph TD
    M[Modern cryptography] --> S[Symmetric<br/>one shared key]
    M --> A[Asymmetric<br/>public/private key pair]
    M --> H[Hash functions<br/>keyless: digital fingerprint]
    S --> S1[Encryption: AES, ChaCha20]
    S --> S2[Authentication: HMAC]
    A --> A1[Encryption and key exchange]
    A --> A2[Digital signatures]
    H --> H1[Integrity, passwords,<br/>identifiers]
Family Core idea Strength Main limitation Covered in
Symmetric Sender and receiver share the same secret key Very fast, suitable for gigabytes of data How do two parties who've never met share the key? Module 2
Asymmetric Each party has a key pair: a public one (freely distributed) and a private one (never shared) Solves key exchange and enables signatures Slow, with limited message size; almost always combined with symmetric crypto Module 4
Hash A keyless function that reduces any data to a fixed-size "fingerprint" that can't be inverted Detects any tampering; the basis of passwords and signatures On its own, gives neither confidentiality nor authenticity Module 3

In real practice a family is almost never used in isolation: TLS (the protocol behind HTTPS, module 5) combines all three, and "hybrid encryption" (module 4) is exactly that combination. Hold on to the big picture; the details will arrive in order.

A classic sender/receiver flow using symmetric cryptography, to fix the vocabulary we'll use throughout (plaintext, ciphertext, key):

sequenceDiagram
    participant E as Sender (Clínica Sol)
    participant R as Receiver (MediNube)
    Note over E,R: Both share a secret key K
    E->>E: encrypt(plaintext, K) → ciphertext
    E->>R: sends the ciphertext (insecure channel)
    R->>R: decrypt(ciphertext, K) → plaintext
    Note over E,R: An eavesdropper on the channel only sees the ciphertext

The MediNube case: our throughline

Throughout the course we'll work with the same scenario, so that every technique has a realistic context.

MediNube is a (fictional) SaaS platform that manages medical records for private clinics. Its clients are clinics like Clínica Sol or Luna Medical Center; its end users are doctors, administrative staff, and, through a patient portal, patients like Ana Pérez. You've just joined the team as the developer responsible for reviewing and building its security layer.

What does MediNube need from cryptography? Practically the whole catalog:

MediNube's need Goal(s) it covers Where we'll build it
Stored medical records must stay unreadable if disks or backups are stolen Confidentiality Modules 2 and 6 (encryption at rest)
Doctors' and patients' passwords must not leak even if the database is stolen Confidentiality (of the password) Module 3
Session and password-recovery tokens must be unpredictable Authenticity, unpredictability Lesson 01-03 and module 6 (JWT)
An electronic prescription issued by a doctor must be verifiable and unforgeable Integrity, authenticity, non-repudiation Module 4 (signatures)
Browser ↔ API communication must travel protected Confidentiality, integrity, authenticity Module 5 (TLS)
Storing and rotating all of the above keys without disasters (Cross-cutting) Module 6

Important warning: MediNube handles health data, a category specially protected under the GDPR. Throughout this course we always use fictional data and educational examples. A real deployment of a system like this requires, in addition to solid cryptography, a review by security and compliance professionals (GDPR and any applicable healthcare-sector regulations). No example from this course should be copied into production without that review.

A Python appetizer: the Caesar cipher

To set the stage for what's coming, let's implement the Caesar cipher. Heads up: this is an educational toy; you'd never protect anything real with it. That's exactly why it's useful — it lets us see a complete cipher (algorithm + key) and check just how easy it is to break.

def encrypt_caesar(text: str, shift: int) -> str:
    """Encrypts text by shifting each letter a fixed number of positions."""
    result = []
    for char in text:
        if char.isalpha():
            # base is the code point of the starting letter: 'A' or 'a'
            base = ord('A') if char.isupper() else ord('a')
            # Shift within the 26-letter alphabet using modulo (%)
            shifted = (ord(char) - base + shift) % 26 + base
            result.append(chr(shifted))
        else:
            result.append(char)  # spaces, digits, etc. are left untouched
    return "".join(result)


def decrypt_caesar(text: str, shift: int) -> str:
    """Decrypting is just encrypting with the opposite shift."""
    return encrypt_caesar(text, -shift)


message = "Appointment for the patient Ana Perez on Monday"
key = 3
ciphertext = encrypt_caesar(message, key)
print(ciphertext)                        # Dssrlqwphqw iru wkh sdwlhqw Dqd Shuhc rq Prqgdb
print(decrypt_caesar(ciphertext, key))   # Appointment for the patient Ana Perez on Monday

Let's break the code down piece by piece:

  • ord(char) returns the character's numeric code (for example, ord('A') is 65), and chr() does the reverse. Ciphers work with numbers, not letters; this letter ↔ number conversion is the first step in almost everything.
  • (ord(char) - base + shift) % 26 first converts the letter to an index from 0 to 25 (by subtracting base), then adds the shift, and the modulo 26 (%) wraps us back from Z to A, like a wheel.
  • The key is the shift (here, 3). The algorithm (shifting letters) can be public; what should be secret is the key.

And breaking it? You don't even need to know the key: there are only 25 possible shifts, so an attacker just tries them all (brute-force attack):

ciphertext = "Dssrlqwphqw iru wkh sdwlhqw Dqd Shuhc rq Prqgdb"
for candidate_key in range(1, 26):
    print(candidate_key, decrypt_caesar(ciphertext, candidate_key))
# The readable text shows up on line 3: key found.

This five-line loop illustrates the most important idea in lesson 01-03: security depends on the size of the key space. 25 keys can be tried in microseconds; 2^128 keys (typical in modern cryptography) can't be tried even with every computer on the planet. It also previews lesson 01-04: even if we'd kept "we're using Caesar" secret, an attacker would figure it out in minutes; the algorithm's secrecy protects nothing.

From module 2 on we'll set the toys aside and use the cryptography library (from the pyca project), the de facto standard in Python for serious cryptography. For this first module, the standard library (base64, secrets, os.urandom) is all we need.

Course roadmap

Here's how everything that follows fits together:

  1. Module 1 (this one): fundamentals and vocabulary — what encryption is and isn't (01-02), where the randomness that fuels everything comes from (01-03), and the golden rules we'll never break (01-04).
  2. Module 2: symmetric cryptography — AES, ChaCha20, modes of operation, authenticated encryption, and key derivation. With this we'll encrypt MediNube's documents.
  3. Module 3: hashes, HMAC, and secure storage of user passwords.
  4. Module 4: asymmetric cryptography — RSA, elliptic curves, digital signatures (electronic prescriptions), Diffie-Hellman, and hybrid encryption.
  5. Module 5: PKI, X.509 certificates, and TLS: the browser padlock, from the inside.
  6. Module 6: cryptography in real-world development — key and secrets management, encryption at rest/in transit, JWT, common mistakes, and a look at post-quantum cryptography.

Common Mistakes and Tips

  • Confusing "encrypted" with "secure." Encrypting with a weak algorithm (or using a strong algorithm correctly but with poorly managed keys) creates a false sense of security that's worse than not encrypting at all, because it relaxes every other control.
  • Believing confidentiality includes integrity. They are distinct goals achieved with distinct mechanisms. Burn this in now — it will save you from the most common mistake in module 2.
  • Blurring "decrypt" and "break." In everyday speech people use "decrypt" loosely for both recovering plaintext with the key and recovering it without the key through cryptanalysis. Keep the vocabulary precise: decrypting requires the key; breaking (or cryptanalyzing) a cipher doesn't — and precise vocabulary helps you think precisely.
  • Diving into cryptographic code without identifying the goal. Before picking a tool, always ask: do I need confidentiality, integrity, authenticity, non-repudiation... or several? The tool follows from the answer, not the other way around.
  • Tip: when you read security documentation, mentally translate each mechanism into "which of the four goals does this cover?" It's an exercise that organizes your thinking in surprisingly useful ways.

Exercises

Exercise 1. For each MediNube situation, identify which cryptographic goal(s) are at stake: (a) an attacker intercepts traffic between a doctor's browser and the API and reads Ana Pérez's data; (b) someone with database access changes "500 mg" to "5000 mg" in a stored prescription; (c) a patient claims they never authorized sharing their medical record with another clinic, even though there's a record that they did; (d) a fake app impersonates MediNube's patient portal.

Exercise 2. Modify the Caesar cipher brute-force loop so that, instead of printing all 25 candidates, it automatically returns the most likely one. Simple hint: the correct English text will almost certainly contain the word " the " or a high proportion of vowels. Implement whichever heuristic you prefer.

Exercise 3. The Caesar cipher has 25 useful keys. A "general substitution cipher" maps each of the 26 letters to some other distinct letter (a permutation of the alphabet). (a) How many possible keys does it have? (b) Does that number mean it's secure? Justify your answer (hint: think about letter frequencies in English).

Solutions

Solution 1. (a) Confidentiality (unauthorized reading in transit; solved by TLS, module 5). (b) Integrity (tampering with stored data; hashes and MACs, module 3, and authenticated encryption, module 2). (c) Non-repudiation: we need to be able to prove the patient performed the action, so they can't deny it; this requires a digital signature (module 4) — a database log isn't enough (MediNube itself could have fabricated it). (d) Authenticity (verifying the service's identity; certificates and TLS, module 5).

Solution 2. A simple, effective heuristic: score each candidate by how many times common words appear.

def crack_caesar(ciphertext: str) -> tuple[int, str]:
    common_words = [" the ", " and ", " of ", " to ", " in "]
    best = (0, 0, ciphertext)  # (score, key, text)
    for key in range(1, 26):
        candidate = decrypt_caesar(ciphertext, key)
        score = sum(candidate.lower().count(w) for w in common_words)
        if score > best[0]:
            best = (score, key, candidate)
    return best[1], best[2]

print(crack_caesar("Dssrlqwphqw iru wkh sdwlhqw Dqd Shuhc rq Prqgdb"))
# (3, 'Appointment for the patient Ana Perez on Monday')

We loop over the 25 keys, decrypt with each one, and count occurrences of very common English words; the correct key produces real text and wins on score. On very short texts the heuristic can fail: counting vowel frequencies or the letters E/T/A is more robust.

Solution 3. (a) It's the number of permutations of 26 elements: 26! ≈ 4 × 10^26, a key space of about 88 bits — huge, out of reach for brute force. (b) It's not secure at all. Brute force isn't the only attack: every letter of the plaintext is always replaced by the same ciphertext letter, so the language's letter frequencies (in English, E and T dominate) are preserved in the ciphertext. With frequency analysis, a text of just a few sentences can be broken by hand in minutes. Key takeaway for the course: a large key space is necessary but not sufficient; the algorithm must not leak patterns from the message. We'll come back to this idea with the modes of operation in module 2.

Conclusion

In this lesson you've picked up the course's map and vocabulary: cryptography pursues confidentiality, integrity, authenticity, and non-repudiation; it rests on three families of primitives (symmetric, asymmetric, and hash) that combine with one another; and its history teaches two lessons that still hold today — the key space must be enormous, and misuse breaks theoretically strong systems. You've also met MediNube, the medical-records platform whose security layer we'll be building throughout the course, and you've seen with the Caesar cipher that a cipher is always algorithm + key... and that a space of 25 keys protects nothing.

Before we encrypt anything for real, we need to untangle a confusion that causes real vulnerabilities every day: the difference between encoding, obfuscating, and encrypting. Base64 will show up everywhere in this course, and it encrypts absolutely nothing. That's exactly what we'll cover in the next lesson.

◄ Previous
◄
Next ►
►
The Project | About Us | Contribute | Donations | License
© Copyright 2026. All rights reserved