Week 2 - Cryptography

2026-02-10  |  Lecture , Cryptography

Download the lecture slides for this week here: COMP6420_2026T1_Week2_Cryptography in Hardware.pdf

COMP6420 Week 2 – Cryptography in Hardware

1. Where this fits in hardware security

This week connects cryptography back to the broader “trust” story from Week 1. In hardware security, we care about supporting confidentiality and integrity in real systems, along with authentication and non-repudiation. The lecture frames symmetric-key cryptography as the practical building block that shows up everywhere in hardware implementations.

2. Part 1: A short history of cryptography (and why it matters)

2.1 Pencil-and-paper crypto: Caesar and why it fails

The lecture starts with “old” cryptography to build intuition about why modern primitives look the way they do. A Caesar cipher is a monoalphabetic substitution (e.g., shifting letters by 3). The key point is not the mechanics, but the weakness: language has non-uniform letter frequencies, so ciphertext often leaks structure and can be attacked statistically.

2.2 Fixing Caesar’s core problem: Vigenère and longer keys

The next step is the Vigenère cipher: instead of one fixed shift, you apply different shifts based on a repeating key. That moves from monoalphabetic to polyalphabetic substitution, which hides frequency patterns better (especially as key length increases). The slides walk through the Vigenère table and an encryption example.

The important conceptual lesson: short / repeating keys leak structure, and attackers exploit that.

2.3 Mechanical era: Enigma and operational security lessons

The lecture then jumps to the early 1900s “mechanical crypto” era. Enigma was designed to be “unbreakable,” but it was broken through a combination of math, intelligence, captured knowledge, and operational mistakes. The slides outline the timeline: German development (~1917), early Polish breakthroughs (~1932), and later large-scale work at Bletchley Park; by WWII’s end, Enigma traffic could often be read, with a commonly cited estimate that this shortened the war by about a year.

A nice local detail: the lecture notes that a pair of Enigma machines came to UNSW last year, along with examples of rotor-setting materials.

A video of the Enigma machine is provided here, with Hammond encrypting the message “H” then decrypting it back to “H”.

2.4 Tunny/Lorenz: stream ciphers, XOR, and “don’t reuse keystreams”

Tunny (Lorenz) is introduced as an in-line teleprinter attachment used by German High Command. Conceptually, it’s presented as a stream cipher: ciphertext is produced by XOR-ing plaintext with a keystream (C = P ⊕ K_s).

Tunny was broken when a long message had to be retransmitted with the same keystream but different content; XOR-ing the ciphertexts cancels the keystream and reveals relationships between the plaintexts, eventually exposing the keystream and enabling broader cryptanalysis. This is the enduring operational rule: never reuse a one-time keystream.

3. One-Time Pads (OTP) and “perfect secrecy” in theory vs practice

Shannon’s post-WWII information theory work is used to position OTPs as the “perfect cipher” when used correctly (unbreakable in the information-theoretic sense). The lecture describes OTPs as essentially “Vigenère done properly”: the key is as long as the message, non-repeating, shared between sender/receiver, and destroyed after use.

The practical limitations are emphasized:

The takeaway: OTPs are theoretically ideal but operationally painful—so most real systems use computational cryptography instead.

4. Part 2 – Computerized crypto: symmetric vs asymmetric (and why we focus on symmetric hardware)

4.1 Symmetric keys: the workhorse

Symmetric crypto is introduced as the oldest and most intuitive model: both parties share the same secret key; the same key is used (conceptually) for encryption and decryption.

Block-ciphers: encrypt/decrypt over fixed-size blocks using the same secret key, with DES and AES as the canonical examples.

4.2 Asymmetric keys: mathematically “hard,” used to protect symmetric keys

Public-key crypto relies on one-way functions and heavier mathematics (Diffie–Hellman key exchange, RSA, and ECC).

The key engineering point is that public-key operations are computationally expensive and use larger keys (e.g., RSA-2048 comparable security to AES-256 but far more costly).

Therefore, asymmetric crypto is typically used to establish or protect symmetric keys, after which bulk data moves under symmetric encryption.

5. DES: structure, hardware implications, and what “security margin” looks like

5.1 DES in context

DES is presented as a symmetric-key standard published in 1977, controversial historically, successfully attacked in practice (EFF, 1999), replaced by AES (2002), and finally retired in modern guidance (3DES retired in 2018).

The course covers the algorithm and a hardware implementation.

6. AES: the modern standard and its hardware-relevant structure

6.1 AES in context

AES is introduced as published in 1998 by Joan Daemen and Vincent Rijmen, standardized in 2001, with key sizes 128/192/256 (and the course focuses primarily on AES-128 because differences are “slight” structurally).

The lecture covers the algorithm and a hardware implementation, with an emphasis on the structure of the rounds and how that maps to hardware design patterns.

7. “Crypto in hardware” emphasis: implementations, not just algorithms

Across DES and AES, the recurring theme is that algorithms become hardware micro-architectures: datapaths, key schedules, RAM/register layout, and carefully structured XOR/substitution/permutation networks. The lecture repeatedly points students toward thinking in terms of implementable blocks (e.g., DES Feistel reuse; AES state + repeated transformations).

Deliverable: Report 2 – Hardware Crypto “Whiteboard” Walkthrough

The Week 2 deliverable is Report 2, described as a “Hardware Crypto ‘Whiteboard’” task. You are told:

The due date is Friday of Week 3.