Collisions exist. Hash functions do have collisions, since the domain is larger than the target . In fact, trying values as an input will for sure produce a collision. Moreover, if we pick random inputs and compute the hash values, we’ll find a collision with high probability long before examining inputs. In fact, if we randomly choose just inputs, it turns out there is a 99.8% chance that at least two of them are going to collide. This phenomenon in probability is known as as the birthday paradox [need only 23 people for >50% of the same birthday].

Collisions are hard to find via enumeration. The catch, is of course, this way of finding a collision is extremely resource-intensive. If a computer computes 10000 hashes per second, we would need years to compute hashes, an average number of hashes needed to find a collision. Thus we can conclude that finding a collision in a life-span of a human (something someone might try to do) is much less probable than an asteroid hitting the earth, and therefore we do not need to worry about it — for practical applications, we can assume hash functions to be collision resistant.

Collisions may be easy to find by some other, clever method. Here is an example where a different, cleverer method to find a collision works. Hash function is not collision-resistant, since and give an obvious collision. [Remember that a string = sequence of bits = binary number] This example showcases that some arbitrary function can very well be not collision-resistant. Turns out, there are no functions that are proven to be collision-resistant.

Cryptographic hash functions are empirically collision resistant. The cryptographic hash functions that we rely on in practice are just functions for which people have tried really, really hard to find collisions and haven’t yet succeeded. In some cases, such as the old MD5 hash function, collisions were eventually found after years of work, leading to the function being deprecated and phased out of practical use.

Application: recognition of a file that you have seen before.

A function H is pre-image resistant if given y=H(x) it is infeasible to guess what x is.

Problem: what if we have y=H(”heads”) and also know that x can attain only two values, ”heads” or “tails”. Then a brute-force search algorithm will quickly find the pre-image: try H(”tails)” and try H(”heads”), and pick the one which gives y.

Solution: we can add to the hash something very random, a secret string r that can have many many values. Then, knowing y=h(r || ”heads”), one will not be able to guess what x was.

Application 1: secure password storage on a website server.

Question: why storing plain hashes(passwords) (without salt) by a website is not acceptable?

Intuitively, what this means is that if someone wants to target the hash function to come out to some particular output value y, that if there’s part of the input that is chosen in a suitably randomized way, it’s very difficult to find another value that hits exactly that target.

Application: search puzzle. It consists of:

A solution to this puzzle is a value, x, such that H(id ‖ x) ∈ Y.

How this fits into proof-of-work in Bitcoin. There H = sha256, ID = new block, x = nonce that miners try to find, , where the number is the difficulty number automatically adjusted by the Bitcoin nodes’ software once in two weeks so that the average time between blocks is ten minutes. The fact that ID comes from a close to uniform distribution is insured by the fact that it cointains the hash of the previous block.

The size of Y determines how hard the puzzle is. If Y is the set of all n‐bit strings the puzzle is trivial, whereas if Y has only 1 element the puzzle is maximally hard. The fact that the puzzle-ID is randomly chosen from a large value-set ensures that there are no shortcuts. On the contrary, if a particular value of the ID were likely, then someone could cheat, say by pre‐computing a solution to the puzzle with that ID.

If H is puzzle‐friendly, this implies that there’s no solving strategy for the search-puzzle which is much better than just trying random values of x. And therefore, if we want to pose a puzzle that’s difficult to solve, we can do it this way as long as we can generate puzzle‐IDs in a suitably random way. This is crucial for the proof-of-work idea in mining.

Block cipher consists of two maps satisfying . Each E(k,-) is essentially a permutation on X. E stands for enccryption, D stands for decryption.

Secure block cipher is a block cipher where a random permutation from is probabilistically indistinguishable from a random permutation from . In other words, the subset is scattered uniformly inside , as illustrated below.

How are secure block ciphers constructed? Secure block ciphers are built using iterations of a round function R:

Key point: if the round function R is chosen appropriately (obv needs to be non-linear) and if n is large enough, this proccess arrives at a secure block cipher. In real life this is done more or less experimentally, two standard algorithms:

Compression function is the name for a fixed-length-input hash function, eg . They should satsify the same properties: collision and pre-image resistance, and uniform randomness.

Given a block cipher (), one can construct a compression function as follows:

where is bit-wise summation (mod 1) [01=1, 10=1, 00=0, 11=0] (aka “xor” functions, aka exclusive “or”)

Thm: if a block cipher is secure, then the Davies-Meyer compression function is as collision resistant as possible.

Enables transition [compression function] → [arbitrary-length-input hash function], via the scheme illustrated below (the specific numbers of bits are from SHA-256).

The input is subdivided into substrings, 512 bit each; the last substring is padded at the end with the total length of the initial input, so that the total length of the resulting input is a multiple of 512 bits. IV = Initialization Vector = some number that is chosen a priori.

Thm: if compression function h is collision resistant, then so is the resulting hash function.