Introduction#

This course is about cryptography, of which encryption is just one part. Cryptography is a fascinating, fast-moving field, and its importance in the world is continually growing. A working knowledge of cryptographic concepts is essential for IT and software professionals, and that is what this course aims to give you. For example, as you loaded this site in your browser, a wide variety of cryptographic operations happened under the hood, and by the end of the course you will understand all of them.

Course Philosophy#

The overarching goals of this course are:

To prepare you to use cryptography well in your software or IT career.

Cryptography is hard. There is an enormous variety of ways to get things wrong, it is often not obvious when something is wrong, and the consequences of getting things wrong can be dire. Even experts get things wrong all the time.

I don’t say that to scare you. I say it to justify this course’s approach, which places a lot of emphasis on how things can go wrong. In some of the practical exercises, you will see how to exploit a weakness in cryptography. I want you to get hands-on with cryptography, and experience how simple mistakes can make it extremely easy to defeat. You’ll implement at least two exploits that have been used to break cryptography in household-name products.

This course will teach you how to stay on the beaten path. There are ways to use cryptography that have withstood many years of expert scrutiny and concerted attack. Those are what you’ll learn, and those are what you should use.

For real-world use, don’t invent your own cryptographic solutions, and don’t write your own cryptographic code.
To give you enough foundational knowledge that you can learn more on your own.

This course only scratches the surface. In keeping with the first goal, we’ll be focusing on the parts that are commonly used in practice, which means we’ll skip a lot of interesting but more obscure parts. I hope that with the knowledge you gain from this course, you’ll feel comfortable learning from other sources, distinguishing good information from bad, and staying oriented in a sea of information.

Cryptography is a fast-moving field, and the expert consensus on how things should be done evolves over time. It’s likely that, five years from now, at least one thing you learned in this course will be considered obsolete. However, the course should give you a solid enough foundation that you can keep up with the times, and understand how the expert consensus applies to your particular situation.

Security Properties#

Cryptography is the science of communicating securely in the presence of adversaries. In this context, an adversary is anyone, or anything, that is intentionally trying to interfere with communications.

This is where we’ll introduce Alice and Bob. Writings about cryptography almost always use these names to stand for two parties who are communicating with each other. It makes things more interesting, and less confusing, than simply using the letters A and B. We’ll introduce more names as needed, if there are more parties communicating.

Cryptography can be used to give four desirable properties to Alice and Bob’s communications:

Confidentiality: the property that no one other than Alice and Bob can read the contents of their messages to each other.
Integrity: the property that Alice knows whether the contents of the message she received from Bob is the same as what Bob sent (and vice versa). In other words, that no one can change the contents of their messages without being detected.
Authentication: the property that Alice knows that the person she is communicating with is really Bob, and not someone else who is impersonating Bob (and vice versa).
Non-repudiation: the property that Alice can convince a third party that the message she received from Bob is really from Bob, and not an impersonator (and vice versa). In other words, that Bob cannot deny having sent a message that he really did send.

Non-repudiation is not always desirable. Some cryptographic systems intentionally avoid providing it, opting instead to provide deniability: the ability of Alice or Bob to plausibly deny that they sent a message that they really did send.

Cryptography can be used to achieve these properties even when Alice and Bob are communicating in a medium in which adversaries can read, or even modify, what they send to each other.

These properties will be very important to keep in mind throughout the course, and especially in the later half, as we see how real-world systems are built.

One important qualification is that cryptography is not about hiding the existence of messages. It does not help Alice and Bob hide the fact that they are communicating. That is a different field, called steganography, which we won’t cover.

Fundamentals#

This section will introduce a lot of concepts and vocabulary words quickly. They might seem a bit abstract for now, but they’ll quickly start to make sense as we get into later chapters and look at things in detail.

Ciphers#

The core type of cryptographic algorithm is the cipher, pronounced “sigh-fur”. (Infrequently, and mostly in British English, you’ll see it spelled “cypher”.) A cipher is an algorithm that can do two things:

Encryption: the inputs are some legible, usable data, and a small piece of data called a key. The output is unintelligible data with no discernible pattern.
Decryption: the inputs are that unintelligible, patternless data, and a key. If the key is the same as the key that was used during the encryption that produced the unintelligible, the output will be the original legible, usable data. Otherwise, it will be some other unintelligible data.

The legible, usable data that is an input to encryption is called plaintext. It could be text, or a webpage, or a Word document, or an image, or a video, or whatever. The important point is that you can make use of it as-is. Whatever it is, in cryptography it’s called “plaintext”.

The patternless, unintelligible data that is the output of encryption is called ciphertext. The only useful thing you can do with ciphertext is to decrypt it with the correct key. It’s important to note, though, that if you use an incorrect key to decrypt, the cipher will not fail or report an error; it will simply produce an output that is not the original plaintext, and is instead unintelligible nonsense. The cipher itself has no concept of a “correct” or “incorrect” key.

The above definition of decryption specified that the key used during decryption has to be the same as the one used during encryption to get the plaintext back, but that is not actually the case for all ciphers. There are some ciphers called asymmetric-key ciphers, in which the key you must use to decrypt the ciphertext to the original plaintext is different from the key used during encryption. The two keys have a specific mathematical relationship, and are collectively called a key pair. Asymmetric-key ciphers are also called public-key ciphers; we’ll see why in a later chapter. Ciphers where decryption uses the same key as encryption to get the plaintext back are called symmetric-key ciphers.

Keys are relatively small, and most ciphers require keys of a fixed size. The most commonly used symmetric-key cipher can use 128-bit, 192-bit, or 256-bit keys (16, 24, or 32 bytes, respectively). Asymmetric-key ciphers usually require keys that are larger, but still a fairly small amount of data: 2048 bits (256 bytes) is a common size.

Keys should consist of bits with no discernible pattern. A key for a cipher should never be anything human-legible, like a password. There are ways to turn passwords into secure keys, but in most situations, keys should be randomly generated, and the details of that random generation are crucial. We’ll explore this in detail in a later chapter.

It’s important to note that ciphers are deterministic. That is, for a given set of inputs, a cipher will always produce the same output. Even though ciphertext looks like randomly-generated garbage, there is no actual randomness involved.

Good ciphers should have two important properties: confusion and diffusion:

Confusion is the property that each bit of the ciphertext should depend on many bits of the key. In a good cipher, flipping one bit of the key (changing it from 0 to 1 or vice versa) should cause about half of the ciphertext bits to flip. This obscures the relationship between the ciphertext and the key, and makes it so that it is hard to recover the key from the ciphertext, even if you have the corresponding plaintext too.
Diffusion is the property that each bit of the ciphertext should depend on many bits of the plaintext. In a good cipher, flipping one bit of the plaintext should cause about half of the ciphertext bits to flip. That effect is also sometimes called the avalanche effect. This obscures patterns in the plaintext, and makes it hard to recover the plaintext given only the ciphertext.

Ciphers are far from the only type of cryptographic algorithm. Two other types we’ll look at in detail in this course are hash functions and signature algorithms. We’ll save the definitions of those for later chapters.

Implementations#

Ciphers and other algorithms are abstract: they are just lists of instructions. To carry them out on real data, they must be implemented, either in hardware or software.

Hardware implementations are purpose-built electronic circuits that can do nothing but run the one algorithm they were built for. In the early days of cryptography on computers, hardware implementations were the only ones that existed, and they were standalone devices that only did encryption and decryption. Nowadays, many general-purpose CPUs, like those from Intel, have hardware support for some algorithms built into them. There are still specialized cryptographic hardware devices too: examples include the YubiKey line of authenticators, and the Secure Enclave processor included in newer Apple devices.

Software implementations are just computer programs and libraries. Cryptographic software is written in a wide variety of programming languages, though production software tends to implement cryptography in languages like C, C++, Go, or Rust, for the sake of speed and tight control of the contents of memory (to avoid leaking secret data).

Cryptography is used in a wide variety of computing contexts: server-class machines in datacenters, desktop computers, phones, routers, all the way down to the chip on your credit or debit card. As such, algorithm designers must take implementation concerns into account. Ideal algorithms are fast to execute, can be implemented with simple code or hardware circuitry, and don’t require a large amount of memory.

Protocols#

Cryptographic algorithms are just building blocks. To solve real-world problems, several algorithms have to be used together, each working to provide some of the security properties we covered above. Additionally, in real-world settings, there are generally multiple independent participants; e.g. two people who want to send messages to each other over an insecure network.

Multi-participant procedures that use cryptography to establish secure communications are called cryptographic protocols. We’ll see several examples of protocols in the later half of this course. We’ll look in detail at two of the most important:

Transport Layer Security (TLS), which secures web traffic. If you visit a URL that starts with https://, your web browser is using TLS. Older versions of TLS were called Secure Sockets Layer (SSL), and the terms are often used interchangeably, even though they really aren’t.
IPsec, which is actually several related protocols, used to create virtual private networks (VPN). A VPN allows multiple computers or devices, connected via an insecure network like the Internet, to act as if they are connected via a secure local network. IPsec isn’t the only way to create VPNs, but it’s the most common.

Note that “protocol” is not just a cryptography term. For example, HTTP, which web browsers use to fetch web pages, is a protocol, and it has nothing to do with cryptography. This course won’t address protocols that don’t involve cryptography, so we’ll use the word to mean only the cryptographic kind.

Kerckhoffs’ Principle#

Kerckhoffs’ Principle is named after Auguste Kerckhoffs, who first articulated it. It states that a cryptographic system “must not require secrecy, and must not cause a problem if it falls into enemy hands”. He was talking about military cryptography in 1883, but the idea is just as important today.

In modern terms, the principle is that the details of an algorithm or protocol should not need to be kept secret in order to be secure. The security of encryption should rest entirely on the secrecy of the key, not the algorithm.

This can feel counterintuitive to people first encountering cryptography. Why not keep as much secret as possible? Surely it makes an adversary’s task more difficult if they don’t know the algorithm? It does, but that’s somewhat beside the point. There are two problems with algorithms that must be kept secret.

Firstly, for an algorithm to be useful, implementations of it must be distributed, and when they are, adversaries inevitably get their hands on them. Hardware devices can be taken apart; software can be reverse-engineered. It is essentially impossible to keep an algorithm secret in the long term.

Secondly, secret algorithms must be kept secret in the long term. Algorithms are necessarily long-lived, because it is difficult to change an algorithm after it has been deployed. The original algorithm is still needed to decrypt any data that was encrypted with it, and to communicate with any party that still uses it. If a secret algorithm gets compromised, it’s not easy to stop using it. By contrast, changing a key, although not exactly easy, is orders of magnitude easier than changing an algorithm.

The inverse of Kerckhoffs’ Principle is referred to as security by obscurity. It’s a derogatory term for security measures that only hold up because their details are hidden.

Almost all algorithms and protocols in common use today are published in the open, and our collective security is better off for it. If an algorithm can’t hold up to public scrutiny, it’s not a good algorithm. Never trust a secret algorithm to keep your information secure.

Key Management#

Following Kerckhoffs’ Principle means resting the security of encryption on the secrecy of the keys, which means that protecting the secrecy of the keys is critical. The practice of storing, distributing, and updating keys is called key management, and it’s the hardest problem in real-world cryptography.

It’s all well and good to have a secure cipher, but before you can use it to communicate confidentially, you and your counterparty must somehow agree on a key. You must be able to store the key so that you can easily use it, but no adversaries can get hold of it. You should rotate (i.e. change) the key regularly, to limit the damage in case an adversary gets the key. All of this is part of key management, and we’ll look at it in detail in the later half of the course.

Attacks#

An attack is any way of defeating a cryptographic algorithm or protocol so that it doesn’t impart the security properties it is intended to.

Ethics#

In this course, you’ll learn about lots of attacks, including ones that have been used in real life to break real systems. You’ll even do exercises that implement some of them. It’s important, therefore, to talk about the ethics of attacks up front.

Developing an attack is not an unethical act in itself. In fact, that is most of what a cryptography researcher does. When creating a new algorithm or protocol, a researcher must demonstrate its security by trying to develop attacks that break it, and inviting others to do the same. Plenty of researchers have made their names not by creating new cryptography of their own, but by breaking other people’s. Developing attacks is an integral part of creating secure cryptography.

Writing code for an attack is not unethical either. It is also an important part of cryptography research: code that demonstrates an attack is concrete proof of its effectiveness, as opposed to words in a paper.

It is unethical, however, to use an attack in a way that harms people, or against an unconsenting target even if no harm is done. We will be doing neither of those things in this course.

It’s also considered unethical to publish the details of a new attack against a widely-used system, without first notifying the vendor of the system and giving them time to fix the problem. This practice is called responsible disclosure or coordinated vulnerability disclosure. In this course, you’ll only learn about attacks that have been publicly known for many years.

Attack Models#

Most attacks on ciphers can be classified according to what we assume the attacker knows. These are called attack models, and these are the three most common.

In ciphertext-only attacks, the attacker only has ciphertext, and the goal is to recover the plaintext or the key. Though this might be many people’s idea of “breaking encryption”, in practice, such attacks are very uncommon.
In known-plaintext attacks, the attacker is assumed to have access to a set of plaintexts and their corresponding ciphertexts, all encrypted with the same key; the goal is to recover the key. This type of attack is often qualified in terms of how many known plaintext/ciphertext pairs are required to do the attack. In many cases, the probability of an attack succeeding increases with the number of known pairs.

This may seem like an unreasonable assumption; if an attacker gets their hands on some ciphertext, how would they also have the plaintext? In practice, plaintexts (or at least parts of them) are highly predictable. In an encrypted HTTP request, for example, the first several bytes are almost always the same. Most file formats start with a few fixed bytes to identify the format (e.g. all PDF files start with the characters %PDF-). This kind of knowledge can be enough to form the basis of a known-plaintext attack.

It should also be noted that, in general, recovering a key is a much bigger success for an attacker than recovering a plaintext. Recovering a plaintext gets you just that one plaintext. Recovering a key gets you all the plaintexts that were encrypted with that key.
Chosen-plaintext attacks take this a step further: the attacker is assumed to be able to choose plaintexts, and receive their ciphertexts under the same key; the goal is to recover the key. This is a powerful assumption, since it means the attacker can choose plaintexts that will maximize the amount of information they gain with each step.

Again, this may seem like an unreasonable assumption, but it is realistic. One scenario where it applies is when encryption is done by a tamper-resistant piece of hardware. The hardware encrypts data that is sent to it, but does not reveal the key. The Secure Enclave chip that current Apple devices have is an example of such a hardware device; it contains features that are meant to defeat exactly this kind of attack.

There are some useful attacks that don’t fit neatly into these categories. In one attack we’ll look at, you can choose part of a plaintext, but the rest is unknown; you use your knowledge of the whole ciphertext and your chosen part of the plaintext to discover the unknown part of the plaintext.

Brute Force#

All cryptographic algorithms can be defeated by brute force. In the case of ciphers, it is always possible to decrypt a ciphertext without knowing the key, by simply trying every possible key until you get a usable output. Similarly, it’s always possible to recover a key from a known plaintext/ciphertext pair by trying every possible key.

This is called “brute force” because it doesn’t make use of any analysis of the cipher: it simply requires using a massive amount of computing power. The only defense against brute-force attacks is to make “every possible key” such a large number that trying all of them would entail far too much work to be feasible.

This is why key size is crucial for ciphers: the longer the key, the more possible keys there are. Specifically, there are \(2^n\) possible values that are \(n\) bits long. For example, \(2^3 = 8\), and there are eight possible 3-bit values: 000, 001, 010, 011, 100, 101, 110, 111.

This is why 128 bits is considered a secure key size: \(2^{128}\) is such a large number that it would take unimaginable advances in computing power to make it feasible to try that many keys. If you could use all the computing power on Earth, it would still take billions of years to try that many keys. We’ll see a little more about this in the next chapter.

There is no specific threshold for what is considered a “feasible” brute force attack. Different attackers will have different ideas of feasibility, depending on the resources they have at their disposal (computing power and time), and how valuable a successful attack is to them.

We generally talk about the effectiveness of an attack in terms of the number of steps it requires. The definition of a “step” is intentionally vague, and context-dependent. When talking about attacks on ciphers, a “step” is generally a single encryption or decryption using the cipher.

Because every algorithm can be defeated by brute force, it is the benchmark for all other attacks. If some attack that recovers a 128-bit key takes more than \(2^{128}\) steps to carry out, there’s no point to it; an attacker would do better to use brute force.

By contrast, attacks against ciphers that take fewer steps than brute-force are called breaks. The word doesn’t imply that the cipher is “broken” and thus useless. An attack that recovers a 128-bit key in \(2^{127}\) steps is a “break”, but it’s still no more feasible to actually carry out than a brute-force attack. Sometimes the word is qualified as “academic break”, meaning it has no meaningful impact on the cipher’s security in the real world.

A perfect cipher would have no attack against it that takes fewer steps than brute force.

Cryptanalysis#

No cipher is perfect. Although their output is supposed to look like it could have been randomly generated, it is not truly random, and there are inevitably statistical patterns in it that attackers can sometimes exploit.

Cryptanalysis is the mathematical analysis of a cryptographic algorithm and the patterns in its output. Cryptanalytic attacks generally rely on fairly advanced probability math, so we won’t cover how they are designed and executed in this course. When we cover specific ciphers and hash functions, we’ll survey the known cryptanalytic attacks against them.

Side Channel Attacks#

Side channel attacks are not attacks on algorithms themselves, but rather on implementations of algorithms. Whether hardware or software, implementations have to interact with the real world, and that is where things get messy.

There are several common categories of side channel attack:

Timing attacks involve measuring the amount of time it takes to execute a cryptographic operation. Tiny differences in these timings can leak information about the contents of the operation. An operation as simple as comparing two arrays for equality has to take precautions to use the same amount of time regardless of the contents of the arrays.
Power analysis works by monitoring the amount of electrical power that a device draws as it does a cryptographic operation. Similar to a timing attack, this can reveal information about the contents of those operations.

A related type of side channel is the electromagnetic radiation emitted by a computer’s circuits during cryptographic operations, which can be picked up in surprising ways, such as through the computer’s internal microphone[GNST22].
To do encryption or decryption in software, the key must exist somewhere in the computer’s memory. In modern computers, there are many ways by which that in-memory key can leak; this is called data remanence. For example, if the operating system runs low on free memory, the part of memory where the key is may get written to disk, where other programs may be able to recover it. Well-written cryptographic software takes special precautions to close off as many of these leaks as possible.
Differential fault analysis works by tampering with ciphertext or signatures, and gaining information by learning what goes wrong when a target tries to decrypt or verify it. For example, the target software may return different error messages for different problems. (This overlaps with timing attacks: different problems may cause different timing results.)

Side channel attacks are specific to implementations, not algorithms, although some algorithms’ design tends to make their implementations more susceptible than others. It is very easy to accidentally introduce implementation flaws that allow for side channel attacks, and they can be very tricky to defend against. Almost all practical attacks on real-world cryptography involve a side channel of some kind.

Protocol Attacks#

Attacks against protocols depend heavily on the nature of the protocol, so we’ll defer the details until later chapters, but there are two general categories that all protocols must contend with:

Man-in-the-middle attacks (MITM for short) involve an attacker inserting themselves between two participants in a protocol, intercepting and modifying all their messages. The attacker impersonates Bob while talking to Alice, and impersonates Alice while talking to Bob; Alice and Bob think they’re talking to each other, but they’re not.

Mitigating MITM attacks requires the participants to authenticate each other, which is a complex problem in its own right. We will see much more detail on this later in the course.
Replay attacks involve an attacker recording the messages of a protocol between two participants, and retransmitting them later. The attacker knows those messages are valid, since they were between honest participants. The attacker may not be able to produce valid messages on their own, but they can replay the valid messages they’ve recorded. They doesn’t necessarily know what those messages contain or mean, but they hope that repeating a message will repeat the effect of that message, or somehow put the system into an exploitable state.

Mitigating replay attacks generally involves adding some kind of unique marker to every message in a protocol, so that participants can quickly detect and discard repeated messages.

The Ecosystem#

Cast of Characters#

Who does all this stuff? Who invents ciphers and other cryptographic algorithms? Who builds the hardware and software that implements them? Who comes up with attacks?

The answers to those questions have changed significantly over time. Today, there are three major categories of entities that do those things:

Governments, including militaries. Their aims are generally to keep their own communications secure, as well as to break the security of others’ communications. (“Others” can mean other governments and militaries, or it can mean private organizations and individuals.) In the government context, these practices are called signals intelligence.

Most governments of developed countries have agencies that are tasked with signals intelligence. In the United States, that is the National Security Agency (NSA). The NSA is one of the world’s foremost employers of cryptanalytic talent, and is assumed to have access to massive amounts of computing power. Its cryptography-breaking capabilities are assumed to go well beyond what is publicly known.

The NSA has had a fraught relationship with the general public’s use of cryptography. As cryptography started to become widespread in the 1980s and 1990s, the NSA tried to undermine it in various ways, leading to a distinct lack of public trust in them.

More recently, though, it seems that the NSA’s institutional posture has changed. They no longer object to strong cryptography in public hands; in fact, several commonly-used algorithms were designed and published by the NSA, and the public cryptographic community trusts their security. The change of attitude is most likely because the NSA now places much more emphasis on breaking security in ways other than breaking cryptography, such as exploiting software bugs.

Other major powers have their own highly capable signals intelligence agencies (e.g. the British GCHQ, the Russian Spetssvyaz, and the Chinese Ministry of State Security). Allied countries sometimes share capabilities with each other.
Corporations. In the early days of computer cryptography, the only cryptography that was done outside governments was done by large companies. For example, the Data Encryption Standard (DES), the most widely used cipher from the 1970s until the 2000s, was designed by a team at IBM.

Along with generalist companies like IBM, telecom companies have long done work in cryptography too. Sometimes the aim is to secure the company’s own infrastructure and protect its customers and reputation, but sometimes it is simply to contribute basic research, for the public good.

These days, the major tech companies (primarily Google and Microsoft) do a lot of general security research, which sometimes involves cryptography. They are more focused on creating new attacks than new algorithms. For example, researchers at Google discovered the infamous Heartbleed bug in a widely-used cryptography software library in 2014.

Corporations are also significantly involved in writing cryptographic software. Companies that produce operating systems, server software, web browsers, and network devices like VPN appliances all have to put cryptographic code in those products. Even open-source cryptography software has significant contributions from software developers employed in the private sector; many companies use open-source software, and contribute money and development work in return.
Academia. These days, universities and other research institutions are the source of most new algorithms, and of most publicly known cryptanalysis. For example, the Advanced Encryption Standard (AES), the successor to DES and current most widely-used cipher, was designed by two postdoctoral researchers at KU Leuven.

Academic cryptography research is mostly done by faculty and graduate students in mathematics and computer science departments. The line between academia and the other categories can be slightly blurry, since a lot of academic research is funded by corporations or governments, which are interested in the fruits of this research but do not have the necessary talent in-house. There is often direct collaboration between academic and corporate researchers as well.

In comparison to governments and corporations, academia is a newcomer to cryptographic research. It was essentially nonexistent before the 1970s, because there was nothing public to study: governments considered cryptography to be sensitive information, and kept it secret. This changed in 1975, with the publication of DES, whose details you can read in the appendix.

Academic cryptographers from all over the world, and from many different institutions, have made significant contributions to the field. The top publications and conferences in the field are produced by the International Association for Cryptologic Research (IACR). This course will reference many papers from IACR publications as sources. Many newer papers (since 2001 or so) are freely available online. Older papers generally aren’t, but are accessible on the website of Springer (the publisher) by logging in through the Northeastern library.

Standards#

In order to be widely adopted, algorithms and protocols must be clearly and precisely described, so that a wide variety of parties can create implementations of them that are compatible with each other. Such descriptions that are designated as official are called standards.

There are standards about all sorts of algorithms and protocols, not just cryptographic ones. There are various organizations that publish cryptographic standards, and this course will cite standards primarily from two of them:

The National Institute of Standards and Technology (NIST), part of the United States Department of Commerce. NIST’s purview is science and engineering generally, and it includes computing and cryptography.

NIST publishes the Federal Information Processing Standards (FIPS) to specify computing standards, and several of them specify cryptographic algorithms and protocols. Those are the NIST publications we’ll be referencing.
The Internet Engineering Task Force (IETF). IETF is an all-volunteer organization, and operates much more informally than most standards organizations. Their purview is the Internet, and their standards specify how Internet communications work.

IETF publishes RFCs ¹ ¹This originally stood for “Request for Comments”, but now officially doesn’t stand for anything.. RFCs are of varying levels of official-ness. Only a subset of them are considered standards, though many others are used as if they were standards. We will reference many RFCs throughout the course; there are many algorithms and protocols whose most authoritative definitions are in RFCs.

Optional Further Reading#

Cryptography Engineering by Niels Ferguson, Bruce Schneier, and Tadayoshi Kohno is a book with the same practical approach as this course, as opposed to the theory-first, math-heavy approach of other cryptography textbooks. It is a good read if you want to learn about the field more deeply. However, it was last updated in 2010, which means it is somewhat outdated.
Understanding Cryptography by Christof Paar and Jan Pelzl is an introductory textbook. It covers the same ground as the first half of this course, and may be useful as a supplement to the course readings. It too was last updated in 2010. You can get a free PDF from the website of the publisher, Springer, by logging in through the Northeastern library.
The Codebreakers by David Kahn is a history of cryptography from its first use in antiquity, until 1961 when the book was written. We will not be covering pre-computer cryptography at all in this course, but it’s an interesting topic.

Introduction

Contents