Cryptography Lecture 10–11

The lecture starts with a motivating example from large-object comparison.

Suppose we have a very large object, for example a DNA segment or gene snippet. The professor gives an example where each object may be around one gigabyte, and there may be hundreds of thousands of possible database entries or mutations.

A direct comparison is expensive:

• sending the entire object to the server is expensive;
• comparing the whole object against every database entry is expensive;
• if there are many database entries, the communication and computation cost becomes huge.

The idea is to compute a short fingerprint, also called a digest, of the large object.

Instead of comparing

\[ x \]

directly with every database object, we compute

\[ H(x) \]

and compare the short digest with stored digests.

A hash function therefore takes a potentially very large input and compresses it to a short output, for example \(128\) bits or \(256\) bits.

The professor emphasizes that this is useful even outside cryptography:

• speeding up comparisons;
• membership tests in large databases;
• reducing communication cost;
• obtaining a short handle for a large object.

The important intuition is:

\[ \boxed{ \text{Hashing compresses large objects into short fingerprints.} } \]

However, since the digest is much shorter than the input, it cannot be a statistically unique identifier for every possible input. Collisions must exist. Cryptography only asks that collisions should be hard to find.

The professor briefly discusses a related but different problem.

Sometimes we do not want exact equality. For example, for text or images, we may want to know whether two objects are close:

• a sentence with one comma missing;
• a sentence with one word changed;
• an image shifted or rotated slightly;
• images that are semantically similar.

For this, ordinary cryptographic hash functions are not suitable, because a tiny change in the input should normally make the hash value look unrelated.

Instead, one can use locality-preserving hashing.

The rough idea is:

\[ d(x,y) \text{ small} \quad \Longrightarrow \quad d(H(x), H(y)) \text{ small}. \]

That is, if two objects are close in the source space, then their hashes should also be close.

This is useful for approximate matching, but it is not the same as a cryptographic hash function.

The professor mentions that images live in some metric space. A naive metric could compare images as large pixel vectors, but more semantic metrics such as optical flow can better capture shifts, rotations, or visually similar images.

The lecture then returns to cryptographic hash functions.

A hash function family is described by two algorithms:

\[ (\mathsf{Gen}, H). \]

The main security notion introduced in this lecture is collision resistance.

A collision is a pair of distinct inputs

\[ x \neq x' \]

such that

\[ H_s(x) = H_s(x'). \]

Because the hash output is shorter than the input space, collisions always exist. The security requirement is only that they are computationally hard to find.

The professor compares hash functions with earlier primitives.

Assume \(H\) is collision-resistant.

Define

\[ H'_s(x) = H_s(x \parallel 0^\lambda). \]

Question:

\[ \text{Is } H' \text{ collision-resistant?} \]

Answer: \[ \boxed{\text{Yes.}} \]

Now define

\[ H''_s(x_1,\ldots,x_n) = H_s(x_1,\ldots,x_{n-1}). \]

That is, \(H''\) ignores the last input bit.

Question:

\[ \text{Is } H'' \text{ collision-resistant?} \]

Answer: \[ \boxed{\text{No.}} \]

For example, take two inputs that differ only in the last bit:

\[ 0\ldots 00 \]

and

\[ 0\ldots 01. \]

They are distinct, but \(H''\) drops the last bit, so both are hashed as

\[ 0\ldots 0. \]

Therefore,

\[ H''_s(0\ldots 00) = H''_s(0\ldots 01). \]

This gives an easy collision.

The lesson is:

\[ \boxed{ \text{A cryptographic hash value must depend on every input bit.} } \]

The professor briefly adds that there are some very recent advanced research ideas where encodings allow hash computations to depend only on a logarithmic number of bits of an encoded message. But this is bleeding-edge research and not the standard notion used in this lecture.

For the classical cryptographic hash functions discussed here, ignoring even one input bit is fatal for collision resistance.

Collision resistance is useful, but sometimes it is not enough.

There are situations where we want stronger properties. For example, we may want it to be hard to find arbitrary correlations between the hash function and some other function.

One example discussed in the lecture is:

Given a fixed function \(f\), it should be hard to find \(x\) such that

\[ H_s(x) = f(x). \]

This is not merely a collision between two hash inputs. It is a more general correlation between \(H_s\) and another function.

The professor notes that the details matter. If the target value or function is chosen independently before the seed \(s\), then collision resistance may already imply some such properties. But if the adversary can choose the target after seeing \(s\), then some formulations become unachievable.

For example, if the adversary is allowed to choose a target \(T\) after seeing \(s\), it can simply choose

\[ T = H_s(x) \]

for some \(x\).

So single-target correlation notions can easily become either trivial or impossible.

The broader concept mentioned is correlation intractability, which may appear later in connection with the Fiat–Shamir paradigm.

To model an ideal hash function, practitioners often use the random oracle model.

A random oracle is a uniformly random function

\[ \mathcal H : \{0,1\}^* \to \{0,1\}^{\lambda} \]

that can only be accessed by oracle or black-box access.

This means algorithms can query the oracle on inputs \(x\) and receive \(\mathcal H(x)\), but they cannot inspect the code or implementation.

The professor gives a programming analogy:

\[ \boxed{ \text{Think of a random oracle as a library function whose implementation is hidden.} } \]

The professor strongly emphasizes that the random oracle model is conceptually problematic.

Real hash functions are not random oracles.

A real hash function has:

• a small description;
• concrete code;
• a concrete implementation;
• public algorithms.

A uniformly random function from a huge domain cannot have a small circuit or short implementation. To store it exactly, one would need its entire function table.

So the random oracle model does not literally describe real hash functions.

Let \(\mathcal H\) be a random oracle.

Define

\[ H_s(x) = \mathcal H(s \parallel x). \]

This is a salted hash construction. The seed \(s\) is prefixed to the input.

The claim is that \(H_s\) is collision-resistant when \(\mathcal H\) is modeled as a random oracle.

The lecture then discusses how to extend a fixed-length compression function to a hash function with a larger domain.

Suppose we have a compression function

\[ H_K : \{0,1\}^{2\lambda} \to \{0,1\}^{\lambda}. \]

Can we build a hash function

\[ H'_K : \{0,1\}^{4\lambda} \to \{0,1\}^{\lambda}? \]

The idea is to iterate the compression function.

For input

\[ x = x_1 \parallel x_2, \]

where

\[ x_1,x_2 \in \{0,1\}^{2\lambda}, \]

define

\[ H'_K(x_1,x_2) = H_K\bigl(H_K(x_1) \parallel H_K(x_2)\bigr). \]

So the construction first hashes the two halves separately, then concatenates the two intermediate hash values and hashes them again.

This is a tree-like iteration of the compression function.

The professor says that one can recursively extend this idea to longer strings. If necessary, one can pad the input length to a power of two. Padding to the next power of two increases the length by at most a factor of two.

The lecture ends with the following takeaways:

• Hash functions compress large objects into short digests.
• Since the digest is short, collisions must exist.
• The digest is only computationally unique.
• Collision resistance captures the idea that collisions are hard to find.
• Hash functions differ from PRFs because their seed is public.
• Random oracles model ideal hash functions with stronger behavior.
• Random oracle proofs are often easy, but the model is only heuristic.
• Proofs in the random oracle model do not automatically hold in the real world.
• Merkle–Damgård-style iteration can extend a compression function to longer inputs while preserving collision resistance.

Lecture 11 begins with an addendum to the previous lecture.

The professor notes that for earlier primitives, such as PRGs, PRFs, and PRPs, he had usually mentioned how they are implemented in the real world. For hash functions, he had forgotten to include such a slide, so he adds a practical hashing discussion.

The main point is that practical cryptographic base primitives must be extremely efficient.

For primitives like AES and hash functions, the bottleneck is usually not whether we believe the primitive is secure. From a cryptanalytic perspective, standard constructions are believed to be very secure. The important practical issue is speed.

These primitives may be called billions of times on servers, so efficiency is critical.

The practical construction discussed is the sponge construction.

The professor identifies Keccak as the NIST-standardized construction behind SHA-3.

The sponge construction has two internal registers or parts of state:

• \(r\), often called the rate;
• \(c\), often called the capacity.

Both are initialized to zero.

The input message is split into blocks:

\[ p_0,p_1,\ldots,p_{n-1}. \]

Each block has length roughly corresponding to the rate \(r\), for example the professor mentions an order of magnitude such as \(64\) bits for illustration.

The lecture then moves to the new topic: authentication.

In the course-topic picture, this is still symmetric-key cryptography, but now the goal is authenticity rather than privacy.

Previously, the course studied symmetric-key encryption, whose goal is secrecy. Now the course studies message authentication codes, whose goal is message integrity.

The main message is:

\[ \boxed{ \text{Secrecy and integrity are different security goals.} } \]

Encryption by itself does not necessarily protect integrity.

The professor recalls an earlier example with two armies.

One army wants to send an encrypted command to another army. The possible messages are:

\[ m_0 = \operatorname{Binary}(\text{"Attack"}) \]

and

\[ m_1 = \operatorname{Binary}(\text{"Wait"}). \]

Suppose the message is encrypted with a one-time pad:

\[ c = K \oplus m_b. \]

An adversary intercepts \(c\). The adversary may not know whether \(b=0\) or \(b=1\), so secrecy is not necessarily broken.

But the adversary can compute

\[ c' = c \oplus m_0 \oplus m_1. \]

Then:

• if \(c\) encrypted \(m_0\), then \(c'\) decrypts to \(m_1\);
• if \(c\) encrypted \(m_1\), then \(c'\) decrypts to \(m_0\).

So the adversary can flip the meaning of the command without learning the original message.

This attack does not break secrecy, but it breaks integrity.

The professor notes that the same style of malleability attack also applies to the encryption schemes seen so far where encryption is essentially XORing a pseudorandom mask onto the message, such as:

• one-time pad;
• PRG-based private-key encryption;
• PRF-based CPA-secure encryption.

Some block-cipher modes may already provide limited structure that makes this specific attack less direct, but encryption alone should not be relied on for authenticity.

The lecture gives two main real-world examples.

A message authentication code, or MAC, consists of three PPT algorithms:

\[ (\mathsf{Gen}, \mathsf{Mac}, \mathsf{Verify}). \]

Correctness says that honestly generated tags verify.

For all security parameters \(\lambda\), all messages \(m\), and keys

\[ K \leftarrow \mathsf{Gen}(1^\lambda), \]

we require

This is only a functionality requirement.

The professor addresses a student question: why do we not also require that \(\mathsf{Verify}\) is not the constant function that always outputs \(1\)?

The answer is that correctness only says honest behavior works. Abuse resistance is captured by the security definition.

A verification algorithm that always accepts will be ruled out by security, because then an adversary could easily forge tags.

To define security, the professor asks two questions.

The standard security notion is existential unforgeability under adaptive chosen message attacks.

Abbreviation:

\[ \mathsf{EUF\text{-}CMA}. \]

The name decomposes as follows:

• EUF = existential unforgeability, describing the adversary’s goal;
• CMA = chosen message attack, describing the adversary’s resource.

The lecture then defines a stronger notion:

\[ \mathsf{sEUF\text{-}CMA}. \]

In ordinary EUF-CMA, the adversary must output a tag for a new message:

\[ m^* \notin \{m_1,\ldots,m_q\}. \]

In strong EUF-CMA, the adversary is allowed to reuse an old message, but not an old message-tag pair.

The adversary wins if

\[ (m^*,t^*) \notin \{(m_1,t_1),\ldots,(m_q,t_q)\} \]

and

\[ \mathsf{Verify}(K,m^*,t^*)=1. \]

So if the adversary reuses a previously queried message \(m_i\), it must produce a different valid tag \(t^* \neq t_i\).

The professor then discusses using MACs in practice.

Suppose Bob wants to send Alice \(100\) euros.

A natural authenticated message might be:

\[ ((100\text{€}, \text{Bob}, \text{Alice}), t). \]

The tag \(t\) authenticates the tuple.

Now an attacker cannot simply change Alice to the attacker’s name or change \(100\) to \(1000\), because that would require forging a valid tag for a new message.

Such tampering is captured by EUF-CMA security.

The next question is how to construct MACs.

The security definition says it should be hard to find a valid tag for a new message.

This suggests using a function that is unpredictable on new inputs.

The primitive from earlier lectures with exactly this flavor is a pseudorandom function.

So the construction uses a PRF.

Assume for now that messages have fixed bit-length \(n\).

Let

\[ \mathsf{PRF} : \{0,1\}^{\lambda} \times \{0,1\}^{n} \to \{0,1\}^{\lambda} \]

be a pseudorandom function.

Define a MAC as follows.

The theorem stated in the lecture is:

If \(\mathsf{PRF}\) is a pseudorandom function, then the above construction is a strongly EUF-CMA secure MAC.

Formally:

\[ \boxed{ \mathsf{PRF}\text{ secure} \Longrightarrow \mathsf{Mac}_K(m)=\mathsf{PRF}_K(m) \text{ is sEUF-CMA secure.} } \]

The professor proves this by a hybrid argument and reduction to PRF security.

Assume toward contradiction that the MAC is not sEUF-CMA secure.

Then there is a PPT adversary \(\mathcal A\) that wins the sEUF-CMA experiment with non-negligible probability \(\varepsilon\).

In the real experiment, tags are computed as

\[ t_i = \mathsf{PRF}_K(m_i). \]

Now define a hybrid experiment \(X'\), where the PRF is replaced by a truly random function

\[ H : \{0,1\}^n \to \{0,1\}^{\lambda}. \]

So in \(X'\), tags are

\[ t_i = H(m_i). \]

Verification checks whether

\[ t^* = H(m^*). \]

The proof has two parts:

1. The adversary’s winning probability in the real experiment and in \(X'\) differs only negligibly, otherwise we could distinguish the PRF from a random function.
2. The adversary’s winning probability in \(X'\) is negligible, because on a new input the random function value is uniformly random and unknown.

Suppose the adversary’s success probability differs non-negligibly between:

• the real sEUF-CMA experiment using \(\mathsf{PRF}_K\);
• the hybrid experiment \(X'\) using a random function \(H\).

Then build a distinguisher \(\mathcal D\) against PRF security.

The distinguisher \(\mathcal D\) gets oracle access to a function \(O\), where \(O\) is either:

\[ O = \mathsf{PRF}_K \]

or

\[ O = H \]

for a truly random function \(H\).

\(\mathcal D\) simulates the MAC experiment for \(\mathcal A\).

When \(\mathcal A\) queries a message \(m_i\), \(\mathcal D\) forwards it to its own oracle:

\[ t_i := O(m_i). \]

Then \(\mathcal D\) returns \(t_i\) to \(\mathcal A\).

\(\mathcal D\) stores the list

\[ L = \{(m_1,t_1),\ldots,(m_q,t_q)\}. \]

Eventually \(\mathcal A\) outputs

\[ (m^*,t^*). \]

The distinguisher checks whether

\[ (m^*,t^*) \notin L \]

and

\[ t^* = O(m^*). \]

If yes, \(\mathcal D\) outputs \(1\); otherwise it outputs \(0\).

In \(X'\), the adversary sees

\[ (m_1,H(m_1)),\ldots,(m_q,H(m_q)). \]

Then it outputs

\[ (m^*,t^*). \]

There are two cases.

At the end of the lecture, the professor says that the next topic is extending MACs from fixed-length messages to arbitrary-length messages.

The idea will be to use hash functions.

The construction shown in the slides, although only previewed at the end of the transcript, is:

Let

\[ H_s : \{0,1\}^* \to \{0,1\}^{\lambda} \]

be a collision-resistant hash function, and let

\[ \mathsf{MAC} = (\mathsf{Gen},\mathsf{Mac},\mathsf{Verify}) \]

be a MAC for messages of length \(\lambda\).

Define a new MAC for long messages:

\[ K = (s,K') \]

where

\[ K' \leftarrow \mathsf{Gen}(1^\lambda), \qquad s \xleftarrow{\$} \{0,1\}^{\lambda}. \]

Then

\[ \mathsf{Mac}'(K,m) = \mathsf{Mac}(K',H_s(m)). \]

Verification recomputes the hash and verifies the MAC tag on the digest.

The corresponding theorem is:

If \(H\) is collision-resistant and the underlying MAC is sEUF-CMA secure, then the composed MAC is also sEUF-CMA secure.

The professor says this will be discussed next time.

The lecture ends with these key messages:

• Practical hash functions such as SHA-3 use highly optimized constructions, such as the sponge construction.
• The sponge construction has absorbing and squeezing phases.
• Keccak is the NIST-standardized SHA-3 construction.
• Message secrecy and message integrity are fundamentally different.
• Encryption does not automatically guarantee integrity.
• MACs protect message integrity.
• EUF-CMA security says an adversary cannot forge a valid tag for a new message.
• sEUF-CMA security also prevents producing a new valid tag for an old message.
• MACs do not prevent replay attacks.
• Replay protection requires extra protocol mechanisms, such as timestamps.
• PRFs give a clean construction of fixed-length MACs.
• The proof of security uses a hybrid argument: replace the PRF by a random function, then show that forging requires guessing a fresh random value.