Keyed hashing

Keyed hashing computes a digest under a secret key (typically HMAC) so that producing or precomputing hashes requires the key. For low-entropy inputs like phone numbers, an unkeyed hash is reversible by simply hashing every possible input; a keyed hash removes that capability while staying deterministic, so equal inputs still produce equal digests for matching.

The determinism is the point and the constraint. Equal inputs must produce equal digests or the digest cannot be used for matching, which means the scheme cannot add per-record randomness the way password hashing does. All of the protection therefore sits in the key, and the key's storage is the control.

Rotating that key breaks historical matching unless the system can read under both the old and new keys during a grace window.

The design constraint that trips people up is that this cannot borrow from password hashing. Password schemes add per-record salt and deliberate slowness, and both are available because the system only ever verifies a candidate against one stored value. A digest used for matching across records must be deterministic and fast, so neither defence is available, and the key carries the whole burden.

That places the real control in key management rather than in the hash. Where the key lives, who can read it, whether the database that holds the digests can reach it, and how a compromise would be detected are the questions that decide whether the scheme works. A pepper stored beside the data it protects provides nothing against the breach that matters.

Rotation needs planning before it is needed. Changing the key changes every digest, so historical matching breaks unless records carry a key version and the system can read under both during a grace window. Writing that version alongside the digest at the start costs nothing and is the difference between a rotation and a migration, which is crypto-agility applied to stored values.