A team exports a customer table to an analytics partner and replaces the email column with its SHA-256 digest, reporting that the export is now "anonymised" and safe to share. Explain what a digest of a personal identifier actually gives you, how hashing differs from encryption and from encoding such as Base64, and what you would do instead.

## The claim under test: anonymised vs pseudonymised Data is *anonymous* when no one can single out an individual in it, by any means reasonably available. Data is *pseudonymised* when the direct identifier has been swapped for a placeholder but each individual still has a distinct, consistent handle in the file. A digest of an identifier is squarely the second: it is a placeholder computed by a public function with no key. Under most privacy regimes pseudonymised data is still personal data, so "we hashed it" changes the risk profile but does not remove the obligations, and it certainly does not by itself make a partner export safe. ## Determinism is the feature and the flaw A hash function is deterministic by definition — the same input always produces the same digest — and that is exactly what makes it useful for fingerprinting. Applied to an identifier column, determinism has four consequences: - **Singling out.** Every distinct customer has a distinct digest. Collisions are a theoretical possibility for arbitrary inputs, but over a set of a few million real email addresses the mapping is effectively one-to-one, so the digest is a perfect surrogate identity. - **Linkage / joinability.** Any other party who hashed the same field with the same function produces the same digests, so two independently "anonymised" datasets join on the hashed column. Your health flag plus their purchase history become one profile, without either side ever handling an email address. - **Membership testing.** Anyone holding a candidate value can hash it and check whether that person is in your file. Often the sensitive fact *is* membership: presence in a debt-collection, medical or fraud dataset. - **Persistence.** Because the digest is stable forever, it also links the same person across time and across breaches, which is precisely what an identifier is for. ## The second blow: input entropy, not digest length, bounds the protection Preimage resistance is a statement about the *function* — there is no method faster than trying inputs. It is not a statement about the *input*. When the set of plausible inputs is small enough to enumerate, trying them all is the method, and digest size is irrelevant. Emails are enumerable from any leaked address list; phone numbers, national IDs, dates of birth, postcodes and card numbers all live in spaces small enough to sweep on commodity hardware. Moving to SHA-512 changes nothing here, because the attacker never attacks the function. So the sentence to carry: **a hash protects a value only up to the entropy of that value, not up to the size of its output.** ## The three primitives that get confused - **Encoding** — Base64, hex, URL-encoding. Purpose: fit bytes through a channel with restricted characters. No key, no secret, no security claim; anyone reverses it. Treating encoded data as protected is the most basic error in this area. - **Encryption** — a keyed, reversible transformation. Reversibility is the *point*: you encrypt so that you can decrypt later. The algorithm is public; confidentiality lasts exactly as long as key custody does. - **Hashing** — an unkeyed, deterministic map to a fixed-length digest. There is no decrypt operation because there is no inverse to invoke; it is built for integrity, fingerprinting and content addressing. It makes no confidentiality claim at all — that claim is something readers add. The crisp one-liner: hashing has no key and no inverse; encryption has a key and is meant to be undone; encoding has neither a key nor a security property. ## Choosing the primitive from the goal Decide from what the system must still be able to do: - **Must display or transmit the original later** → encryption, with keys managed outside the datastore holding the ciphertext and access separated from the data. - **Must only match or deduplicate, never read** → a keyed hash (a MAC or PRF) whose secret is held outside the exported data. The key is what actually breaks offline enumeration: without it, an attacker cannot even test a candidate. If two parties must match against each other, both need the shared secret, which is a contractual and key-custody decision — or use a matching protocol designed for it, such as private set intersection. - **Must only aggregate or bucket** → reduce precision instead: domain rather than address, age band rather than date of birth, region rather than postcode. Coarsening is the only technique listed here that actually removes information, which is why it is the only one that can produce genuinely anonymous output. - **Not needed by the partner** → do not include the column. Minimisation beats every cryptographic control. - **Authenticating a person by a secret they chose** → passwords are a separate case with their own requirements; do not reason about them from this question. ## Where hashing is the right answer None of this makes hashing weak. It is correct for what it claims: fingerprinting a large artifact into a short identifier, detecting modification, content addressing, and forming part of signature and authentication-tag constructions. The failure here is a goal mismatch — reaching for an integrity primitive to obtain confidentiality and anonymity — not a defect in SHA-256. ## How to answer in an interview Lead with the classification: this is pseudonymisation, so name the two harms in order — a stable pseudonym still singles out and joins, then enumeration re-identifies it outright. Give the three-primitive distinction in one sentence each, and finish by picking the control from the stated goal rather than from the primitive.