Workshop 02 · Cryptography

Decode, Decrypt, and Find Where Crypto Fails

Encoding versus encryption, classical ciphers, and why key handling matters more than the algorithm. Learn where cryptography fails in practice.

What You’ll Practice

Each challenge targets a different misunderstanding about what cryptography does and what it does not.

Encoding vs Encryption

Base64 and hex hide nothing. Recognising an encoding for what it is comes before any real analysis.

Classical Ciphers

Substitution and shift ciphers that fall to frequency analysis or a few minutes of brute force.

Key Handling

Reused keys, short keys, and unsalted hashes — strong algorithms undone by how they were used.

Lesson 1 · CRY-01

Encoding Is Not Encryption

Encoding changes how data is represented so it can travel safely, for example as plain text in an email or a URL. Encryption hides data so only someone with the key can read it. Encoding has no key: anyone can reverse it.

Mistaking one for the other is a classic cryptographic failure, number two in the OWASP Top 10 (2021).

How it works

Base64 turns bytes into letters, digits, + and /. Output whose length is not a multiple of three bytes is padded with one or two = signs, a tell-tale sign of Base64. Every browser console reverses it with atob(). 

"hello"      → Base64 → aGVsbG8=
"aGVsbG8="   → atob() → hello      (no key needed)

How it is prevented

  • Use real encryption (for example AES-GCM) from a reviewed library for anything secret.
  • Do not store secrets in configuration files at all: use a secrets manager or environment variables.
  • Treat any value you can decode without a key as public.

Lesson 2 · CRY-02

Classical Ciphers and Brute Force

A Caesar cipher shifts every letter a fixed number of places through the alphabet. The Roman historian Suetonius records Julius Caesar using a shift of three. It hides a message from a casual glance, but nothing more.

How it works

There are only 25 useful shifts, so an attacker can simply try them all, which is a brute-force attack on a tiny key space. A second method is frequency analysis: in English, E is the most common letter, so the most common letter in the ciphertext is probably E. 

Plaintext:  HELLO WORLD
Shift 3:    KHOOR ZRUOG

Word lengths and punctuation survive, which helps the attacker.

How it is prevented

  • Use modern algorithms whose key space is far too large to search (AES uses keys of 128 bits or more).
  • Follow Kerckhoffs’s principle: a system must stay secure even when everything except the key is public.

Lesson 3 · CRY-03

Never Reuse a Key

XOR-based encryption combines each byte of the message with a byte of the key. With a truly random key that is as long as the message and used only once (a one-time pad), it is unbreakable. Reuse the key and it collapses.

How it works

If two messages are encrypted with the same key, XOR-ing the two ciphertexts cancels the key out, leaving the two plaintexts combined. Knowing or guessing part of one message (a known plaintext, such as a standard greeting) then reveals the matching part of the other. 

C1 = P1 ⊕ K
C2 = P2 ⊕ K
C1 ⊕ C2 = P1 ⊕ P2        (the key K is gone)

How it is prevented

  • Never reuse a one-time key, and never reuse a nonce with modern ciphers such as AES-GCM.
  • Use authenticated encryption from a reviewed library rather than building XOR schemes by hand.

Lesson 4

Storing Passwords: Hash, Salt, and Slow Down

Passwords should not be encrypted (which can be reversed) but hashed: turned into a fixed-length fingerprint that cannot be turned back. To log in, the system hashes what you type and compares fingerprints.

How it works

Plain fast hashes are not enough. Without a salt (a random value added to each password before hashing), identical passwords produce identical hashes, so one precomputed table cracks them all. Fast hashes also let attackers test billions of guesses per second, which is why password storage uses deliberately slow algorithms such as bcrypt, scrypt, or Argon2. 

SHA-1("password1")          → same hash for every user (crackable by lookup)
bcrypt("password1", salt)   → different for every user, slow to guess

How it is prevented

  • Use a slow, salted password hash (Argon2, scrypt, or bcrypt), as OWASP recommends.
  • Never store passwords in plain text or with reversible encryption.
  • This lab follows that advice: Firebase Authentication stores passwords with salted scrypt, and challenge flags are stored only as SHA-256 hashes.

What You Take Away

Cryptographic failures in practice are almost never broken maths — they are broken usage.

  • Know what each tool provides

    Encryption gives confidentiality, hashing gives integrity, signatures give authenticity. They are not interchangeable.

  • Never roll your own

    Use reviewed libraries and current standards such as AES-GCM and SHA-256 rather than a scheme you invented.

  • Treat keys as the secret

    The algorithm is public by design. All the protection lives in the key, so how it is generated, stored, and rotated is the security.

  • Salt and stretch passwords

    Unsalted fast hashes fall to rainbow tables. Password storage needs a slow, salted function such as bcrypt or Argon2.

Sources

  1. OWASP Foundation. (2021). A02:2021 Cryptographic failures. https://owasp.org/Top10/A02_2021-Cryptographic_Failures/
  2. OWASP Foundation. (n.d.). Password storage cheat sheet. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
  3. Wikipedia. (n.d.). Caesar cipher. https://en.wikipedia.org/wiki/Caesar_cipher
  4. Wikipedia. (n.d.). Venona project. https://en.wikipedia.org/wiki/Venona_project
  5. The Register. (2012, June 7). LinkedIn admits site hack, adds pinch of salt to passwords. https://www.theregister.com/2012/06/07/linkedin_admits_data_breach/

Ready to put it into practice?

Try the Cryptography challenges: capture the flags, score points, and unlock the explanation for each one.

Start the Cryptography challenges Next workshop: Security Awareness