SEC-101 Week 4: Cryptography I

Symmetric encryption (AES-GCM, ChaCha20-Poly1305). Asymmetric cryptography (RSA, elliptic curves, Ed25519/X25519). Why "don't roll your own crypto" is technical advice, not gatekeeping. Lab 3: Crypto warm-up.

Reading (~45 min)

Read the Wikipedia article on Authenticated Encryption with Associated Data (AEAD). Pay attention to the three-property definition: confidentiality, integrity, and authenticity. Notice that a bare block cipher (AES in ECB mode, for example) provides only confidentiality, not integrity. A "secure" cipher that doesn't authenticate its output can still be tampered with. This is one reason "don't roll your own crypto" is technical advice.

Then skim the Diffie-Hellman key exchange article on Wikipedia. You don't need to follow the modular arithmetic; focus on the intuition: two parties exchange public information and both arrive at the same secret, without ever sending the secret over the wire.

Lecture outline (~1.5 hr)

Part 1: Symmetric encryption (40 min)

Symmetric encryption uses the same key for encryption and decryption. The security of the scheme is entirely in the key, not the algorithm (Saltzer and Schroeder's open-design principle).

The modern AEAD ciphers:

AES-GCM (AES in Galois/Counter Mode) and ChaCha20-Poly1305 are the two AEAD ciphers you will see in real systems. Both provide confidentiality (the ciphertext reveals nothing about the plaintext without the key) and authentication (the authentication tag proves the ciphertext hasn't been tampered with).

Both require a nonce (number used once). Nonce reuse is catastrophic: it breaks both confidentiality and authentication. This is one of the "don't roll your own crypto" failure modes: designing a scheme that uses the same nonce twice, even accidentally.

ECB mode as a teaching counterexample:

AES in ECB (Electronic Codebook) mode encrypts each 16-byte block independently. Identical plaintext blocks produce identical ciphertext blocks. The famous "ECB penguin" image (the Linux Tux logo encrypted in ECB mode, where the penguin's outline is still visible in the ciphertext) demonstrates that ECB mode leaks structural information even though each individual block is encrypted.

The lesson: cryptographic security depends not just on the algorithm but on the mode of operation and all the surrounding parameters (nonce, authentication tag, key management). This is why you use a library's AEAD function rather than assembling a cipher yourself.

Part 2: Asymmetric cryptography (35 min)

Asymmetric (public-key) cryptography uses different keys for encryption and decryption. The public key can be shared freely; the private key must never leave the owner's control.

RSA:

RSA is based on the computational difficulty of factoring large integers. Given N = p * q where p and q are large primes, finding p and q from N is hard even with modern computers at sufficient key sizes. RSA is still widely used for key exchange and digital signatures, but has been gradually replaced by elliptic curve methods for new deployments because RSA requires much larger keys for equivalent security.

RSA-2048 is the current minimum for new deployments; RSA-4096 is used where long-term security is needed. RSA-1024 is deprecated.

Elliptic curve cryptography (ECC):

Elliptic curve methods achieve the same security as RSA with much smaller keys. A 256-bit EC key is roughly equivalent to a 3072-bit RSA key. Smaller keys mean faster computation and smaller message sizes.

Two common EC algorithms students will encounter:

• Ed25519 (Edwards-curve Digital Signature Algorithm): used for digital signatures (SSH keys, git commit signing, certificate signing in some modern CAs). Resistant to common implementation side-channels.
• X25519 (Curve25519 Diffie-Hellman): used for key exchange in TLS 1.3 and other protocols. The "x" indicates it uses the x-coordinate only.

The curve name "Curve25519" refers to a specific elliptic curve equation with well-understood security properties. The "25519" is mathematical: the field size is 2^255 - 19.

Why ECC replaced RSA in new protocols:

TLS 1.3 (2018) removed RSA key exchange entirely. Modern HTTPS uses X25519 for key exchange and either Ed25519 or P-256 (NIST elliptic curve) for certificates. RSA is still common in certificates for backward compatibility, but the trend is toward EC.

Part 3: Don't roll your own crypto (15 min)

"Don't roll your own crypto" is one of the most-repeated pieces of security advice. It sounds like gatekeeping ("only experts can touch this"). It is actually technical advice with a specific set of reasons.

The reasons, concretely:

1. Side-channel attacks. A correct implementation of AES that doesn't account for timing side-channels leaks key bits through its execution time. Constant-time code is non-trivial to write. The standard library's AES-NI-backed implementation is constant-time; a hand-rolled table-lookup implementation probably isn't.

2. Nonce management. Getting nonces right is harder than it looks. Increment correctly; never reuse; handle wrapping; manage state across process restarts. A custom nonce scheme that accidentally reuses a nonce breaks AES-GCM's security guarantees completely.

3. Key derivation. A 256-bit key needs to be derived from human-memorable material (a password) correctly. PBKDF2, bcrypt, and argon2 do this correctly. A home-rolled scheme that just SHA-256s the password does not (no salt, no work factor, easily pre-computed).

4. Protocol composition. Combining a correct cipher with a correct MAC in the wrong order (encrypt-then-authenticate vs. authenticate-then-encrypt) produces different security properties. Getting this wrong is an authenticated-encryption bug even if both primitives are correct.

The practical rule: use an AEAD cipher (AES-GCM or ChaCha20-Poly1305) through a well-maintained library (libsodium, OpenSSL 3.x, Python's cryptography package). Treat the key as the only secret; treat the algorithm, mode, and nonce scheme as decisions that were made correctly by people who have written hundreds of security proofs.

Lab exercises (~1.5 hr)

Lab 3: Crypto warm-up (graded)

See labs/lab-3-crypto-warm-up.md for the full lab.

The lab uses CyberChef (browser-based, no install) to encode, decode, and encrypt data using various cipher modes. The goal is hands-on experience with the difference between encoding (Base64, hex), hashing (SHA-256), symmetric encryption (AES-CBC vs. AES-GCM), and public-key operations. The lab also includes a picoCTF cryptography warm-up challenge.

Tier-1 companion: Cipher Visualizer Workout

See worksheets/sec-101/lab-cipher-visualizer.md. Drive the academy Cipher Visualizer byte by byte through HELLO XOR LEMON (the canonical OTP example) and the repeating-key cycling case. The worksheet picks up the Week-5 substitution and frequency-analysis tabs after the Week 4 XOR work.

• ~60 minutes; predict-then-verify discipline on each XOR byte
• Recommended primer for the Week 5 Caesar-cracking lab
• The cycle-asterisks in the repeating-key tab anchor Week 4 §4's OTP-vs-repeating-key distinction

Independent practice (~5 hr)

• Reading (1 hr): Read "A Beginner's Guide to Elliptic Curve Cryptography" (any well-written primer; search "elliptic curve cryptography explained" and find one with diagrams). The goal is visual intuition, not mathematical proof.
• picoCTF spine (3 hr): Focus on Cryptography challenges. Good targets: a beginner challenge involving Caesar cipher or ROT13, a Base64-decode challenge, and one XOR cipher challenge. XOR cipher is the gateway to understanding why simple cipher constructions fail: XOR with a repeated key leaks structure.
• Reflection (1 hr): Write the prompts below.

Reflection prompts

1. The "ECB penguin" demonstrates that encrypting data block-by-block with the same key leaks structural information. But each individual AES-ECB block is cryptographically secure. What does this tell you about the difference between a secure primitive and a secure protocol?

2. RSA and ECC both rely on mathematical problems that are "hard" to reverse. Briefly explain in plain English (without modular arithmetic) why the Diffie-Hellman key exchange works: two people can both end up with the same secret without the secret crossing the wire.

3. Your company's developer wrote a custom encryption function that XORs the plaintext with a key, then Base64-encodes the result. Why is this not a secure cipher? Which of the "don't roll your own crypto" failure modes does it violate?

Week 4 of 14. Next: Cryptography II (hashing, digital signatures, TLS handshake, common mistakes).