Definition. Cryptographic hash functions

[comp1110-4P]
  • Liam O'Connor

A cryptographic hash function is a hash function with an additional defining property: preimage resistance. This means that computing \(H(x)\) is easy, but recovering \(x\) from \(H(x)\) is computationally infeasible. Well-known examples include SHA-1 and MD5.

Cryptographic hash functions are also designed to produce avalanche effects: a tiny change to the input scrambles the output completely, so that \(H(x)\) and \(H(x')\) look unrelated even if \(x\) and \(x'\) differ by a single bit. This makes them useful for verifying integrity, storing passwords, and similar security applications.

Context

    Hashing and Hash Tables

    [comp1110-4I]
    • September 29, 2026
    • Liam O'Connor, Fabian Muehlboeck

    Can we do better than O(log n) for lookups?

    [comp1110-4J]
    • Liam O'Connor

    Binary Search Trees and sorted arrays give us \(\mathrm {O}(\log n)\) lookup, but this requires the data to be sorted, and sorting requires a total order on keys. Even when a total order exists, \(\mathrm {O}(\log n)\) starts to hurt for very large \(n\). Furthermore, for some key types, such as composite objects with no natural ordering, defining a total order may be awkward or arbitrary.

    The goal is \(\mathrm {O}(1)\) (average-case) lookup, insertion, and deletion, regardless of whether the keys have a natural ordering. This is what hash tables deliver.

    Example. Most common number in an array of bounded range

    [comp1110-4K]
    • Liam O'Connor, Fabian Muehlboeck

    Suppose we want to find the most common number in an array of integers known to lie in the range 0 to 99 (inclusive). We can use the integer itself as a direct index into a counts array:

    int mostCommonNumber(int[] numbers) { int[] counts = new int[100]; for(int n : numbers) { counts[n] = counts[n] + 1; } int maxNum=0; int maxCount=0; int i = 0; while(i<100) { if(counts[i] > maxCount) { maxNum = i; maxCount = counts[i]; } i = i + 1; } return maxNum; }

    This is \(\mathrm {O}(n)\) time and \(\mathrm {O}(1)\) space (the array size is fixed). The key insight is that the integer is its own index. The challenge for hash tables is generalising this idea to arbitrary key types like strings.

    Definition. Hash functions

    [comp1110-4L]
    • Liam O'Connor

    A hash function is a computable function H mapping values of some type to integers. The only correctness condition is that H must respect equality: if a.equals(b) then H(a) == H(b). Note the converse need not hold: two unequal values may hash to the same integer.

    Definition. Hash tables

    [comp1110-4M]
    • Liam O'Connor

    A hash table is a data structure that uses a hash function to map keys to positions in a backing array of "buckets". If the hash function meets certain conditions, this provides \(\mathrm {O}(1)\) average-case lookup, insertion, and deletion. Given a hash function H and an array of capacity buckets, a key is stored at index: Math.abs(H(key)) % capacity.

    Since there are infinitely many possible keys but only capacity buckets, collisions are unavoidable: two distinct keys will sometimes map to the same bucket. A collision resolution strategy determines what the table does when this happens.

    Definition. Desiderata for hash functions used in hash tables

    [comp1110-4N]

      Beyond basic correctness conditions, a hash function intended for use in a hash table should also be:

      • Deterministic: every call to \(H(a)\) returns the same value for the same input, across all executions. This rules out functions that depend on memory addresses, random numbers, or wall-clock time.
      • Fast: \(H\) should run in \(\mathrm {O}(1)\) time with respect to the number of keys in the table. The cost of hashing a single key may grow with the size of that key (e.g., hashing a longer string takes more steps), but it should not grow as more keys are inserted.
      • Well-distributed: hash codes should be spread roughly uniformly across the integer range, to minimise collisions. A function that always returns 0 is technically correct but useless in practice, as every key lands in the same bucket, and lookup degrades to \(\mathrm {O}(n)\).

      Example. Hash functions for strings

      [comp1110-4O]
      • Liam O'Connor, Fabian Muehlboeck

      This is what's called a polynomial rolling hash for strings:

      int stringHash(String s) { int hash = 0; int pos = 0; while(pos < s.length()) { hash = hash * 31; hash = hash + s.charAt(pos); pos = pos + 1; } return hash; }

      At each step, the accumulated sum is multiplied by \(31\) before adding the next byte. This means the contribution of each byte is weighted by its position: the first byte is multiplied by \(31^{n-1}\), the last by \(31^0\). Using a prime multiplier (\(31\) is a small, odd prime) empirically produces good distribution and avoids systematic collisions on common string patterns. This is essentially the algorithm used by java.lang.String.hashCode(). Contrast with a bad hash function:

      int badHash(String s) { return 0; }

      This satisfies the equality and determinism desiderata but violates distribution: every key collides.

      Definition. Cryptographic hash functions

      [comp1110-4P]
      • Liam O'Connor

      A cryptographic hash function is a hash function with an additional defining property: preimage resistance. This means that computing \(H(x)\) is easy, but recovering \(x\) from \(H(x)\) is computationally infeasible. Well-known examples include SHA-1 and MD5.

      Cryptographic hash functions are also designed to produce avalanche effects: a tiny change to the input scrambles the output completely, so that \(H(x)\) and \(H(x')\) look unrelated even if \(x\) and \(x'\) differ by a single bit. This makes them useful for verifying integrity, storing passwords, and similar security applications.

      Warning. Cryptographic hash functions are not appropriate for hash tables

      [comp1110-4Q]
      • Liam O'Connor

      Cryptographic hash functions are correct hash functions, and they do satisfy our desiderata. However, they are a poor choice for a hash table for two reasons:

      1. They are much slower to compute than a simple purpose-built hash, for no benefit in this setting. The resistance to inversion that makes them cryptographically useful is irrelevant when you are building a lookup table.
      2. Avalanche and one-wayness do not guarantee good distribution for real-world key distributions. A purpose-built hash function can be tuned for the structure of likely inputs.

      Construction.  Object.hashCode()

      [comp1110-4R]
      • Liam O'Connor

      Every Java object inherits hashCode() from java.lang.Object.

      The default Object.hashCode() is typically derived from the object's memory address, which means two distinct objects with the same field values will hash differently. This makes it wrong for value-typed keys unless overridden. Any class you intend to use as a hash table key must override both equals and hashCode consistently.

      Definition. Hash table collisions

      [comp1110-4S]
      • Liam O'Connor

      A collision occurs when two distinct keys hash to the same position in a hash table's backing array. Since there are (usually) infinitely many possible keys but only finitely many positions, by the pidgeonhole principle collisions are unavoidable for any hash function. A good hash function minimises their frequency; a collision resolution strategy determines what the table does when they occur.

      Definition. Collision resolution: chaining vs linear probing

      [comp1110-4T]
      • Liam O'Connor

      When two keys map to the same bucket in a hash table — a collision — a collision resolution strategy is needed. There are many approaches, but here are two:

      • Chaining: each bucket holds a linked list (or other collection) of all entries that hash to that index. Lookup scans the list linearly. With a good hash function and a sufficiently large array, lists stay short and lookup is \(\mathrm {O}(1)\) amortised.
      • Linear probing: the backing array stores entries directly (no linked lists). On a collision, the table scans forward (wrapping around) until it finds an empty slot. Lookup similarly scans forward until it finds the key or an empty slot. Linear probing has better cache performance than chaining but is sensitive to clustering: long runs of occupied slots that slow down both insertion and lookup. Once the hash table becomes too full, the array size is typically doubled and all elements re-hashed and copied to the new array, similarly to the trick used for ArrayList.

      Java's HashMap uses chaining (with a tree fallback for very long chains). Linear probing is used in some high-performance open-addressing maps.

      Example. Worked example: most common word with chaining

      [comp1110-4U]
      • Liam O'Connor, Fabian Muehlboeck

      Building on Example [comp1110-4K], here is a hand-rolled hash table using chaining to find the most common word in a string array. Each bucket is a LinkedList<Entry>, where Entry holds a word and its current count.

      class WordEntry { String word; int count = 1; WordEntry(String word) { this.word = word; } } String mostCommonWord(String[] words) { java.util.List<WordEntry>[] counts = new java.util.List[500]; int pos = 0; while(pos < words.length) { int hash = Math.abs(stringHash(words[pos]) % 500); if(counts[hash] == null) { counts[hash] = new LinkedList<>(); counts[hash].add(new WordEntry(words[pos])); } else { boolean found=false; for(WordEntry entry : counts[hash]) { if(entry.word.equals(words[pos])) { found = true; entry.count = entry.count+1; break; } } if(!found) { counts[hash].add(new WordEntry(words[pos])); } } pos = pos + 1; } String maxWord=null; int maxCount=0; int i = 0; while(i<500) { if(counts[i] == null) { i = i + 1; continue; } for(WordEntry entry : counts[i]) { if (entry.count > maxCount) { maxWord = entry.word; maxCount = entry.count; } } i = i + 1; } return maxWord; }

      Definition. HashMap and HashSet in Java

      [comp1110-4V]
      • Liam O'Connor

      java.util.HashMap<K, V> is the standard library's general-purpose hash table. It implements the Map<K, V> interface from Java collections with \(\mathrm {O}(1)\) amortised put, get, and containsKey, handles resizing automatically, and uses chaining internally.

      java.util.HashSet<E> is a hash table storing only keys (no associated values), implementing Set<E>. It is backed by a HashMap internally.

      Both require that keys correctly implement equals and hashCode.

      Example. Worked example: most common word with built-in HashMap

      [comp1110-8Q]
      • Fabian Muehlboeck

      Usually, instead of creating a hash table implementation yourself as we did in Worked example: most common word with chaining, it is better to rely on standard library classes for such functionality:

      String mostCommonWordStandard(String[] words) { Map<String, Integer> counts = new HashMap<>(); for(String word : words) { if(counts.containsKey(word)) { counts.put(word, counts.get(word) + 1); } else { counts.put(word, 1); } } int maxCount = 0; String maxWord = null; for(String word : counts.keySet()) { if(counts.get(word) > maxCount) { maxCount = counts.get(word); maxWord = word; } } return maxWord; }

      Warning. Mutable keys are an extremely bad idea

      [comp1110-4W]
      • Liam O'Connor

      In a hash table, a key's bucket index is computed from its hash code at insertion time. If you mutate a key after inserting it into a hash table, its hash code may change, placing it in a different bucket — but the table still stores it in the original bucket! The entry becomes permanently lost: containsKey returns false, get returns null, and no error is raised.

      public class Person { String name; int age; @Override public boolean equals(Object o) { if (!(o instanceof Person person)) return false; return age == person.age && Objects.equals(name, person.name); } @Override public int hashCode() { return Objects.hash(name, age); } } void main() { Map<Person, Integer> grades = new HashMap<Person, Integer>(); p.name = "Fabian"; p.age = 38; grades.put(p, 100); IO.println(grades.get(p)); //prints 100 p.name = "Darth Fabian"; //changes the hash IO.println(grades.get(p)); //prints null }

      Use only immutable objects as hash table keys. Strings, boxed primitives, and classes that only have final fields are safe. Mutable objects are not.

      Backlinks

        Warning. Cryptographic hash functions are not appropriate for hash tables

        [comp1110-4Q]
        • Liam O'Connor

        Cryptographic hash functions are correct hash functions, and they do satisfy our desiderata. However, they are a poor choice for a hash table for two reasons:

        1. They are much slower to compute than a simple purpose-built hash, for no benefit in this setting. The resistance to inversion that makes them cryptographically useful is irrelevant when you are building a lookup table.
        2. Avalanche and one-wayness do not guarantee good distribution for real-world key distributions. A purpose-built hash function can be tuned for the structure of likely inputs.

        Related

          Definition. Hash functions

          [comp1110-4L]
          • Liam O'Connor

          A hash function is a computable function H mapping values of some type to integers. The only correctness condition is that H must respect equality: if a.equals(b) then H(a) == H(b). Note the converse need not hold: two unequal values may hash to the same integer.

          bars magnifying-glass caret-down plus minus arrow-right xmark