Your hkdf.Key wrapper let an empty info string through and two features now derive the same key — how do you catch this?

## What the package does and does not check The first thing to internalise is how narrow `crypto/hkdf`'s validation is. Reading the package, the only condition either `Key` or `Expand` reports outside FIPS 140-only mode is: ``` keyLength > h().Size() * 255 -> "hkdf: requested key length too large" ``` That is it. Everything else is accepted: - a `nil` salt (a zero-filled salt of hash length is substituted), - an empty `info` string (mixed in as zero bytes of context), - a very short or low-entropy `secret`, - an `info` string identical to one already used elsewhere in the same binary. So a wrapper like this compiles, passes review, runs, and is wrong: ```go func (d *Deriver) Key(purpose string, n int) ([]byte, error) { return hkdf.Key(sha256.New, d.master, d.salt, purpose, n) } ``` Two callers that pass `""` — a struct field that was never set, a config value that defaulted to empty, a constant someone forgot to fill in — get byte-identical keys, and both calls return a nil error. ## Why it is hard to see The defect has no signature that ordinary tooling recognises. - There is **no race**, so `-race` is silent. This is deterministic single-goroutine behaviour. - There is **no vet check**. `go vet` has no analyser for the semantics of a key-derivation label; an empty string is a perfectly ordinary string. - **Per-feature unit tests pass.** The cookie feature derives a key, uses it, and round-trips fine. The URL-signing feature does the same. Neither test ever compares its key to the other's, which is where the defect lives. - **Nothing fails in production either**, at first. The two features work. What eventually happens is that one of them accepts an artefact produced by the other — a signed URL that verifies against the cookie key, a record readable across a boundary that should have been cryptographically sealed. That gets reported as a strange authorisation bug or a cross-environment data leak, and the KDF is not the first place anyone looks. ## The diagnostic that actually works Because the input is a string literal at a call site, the cheapest reliable check is an audit of those literals across the repository. Collect every value passed as the `info` argument — including the ones that come from constants and from configuration defaults — sort them, and look for two things: blanks, and duplicates. In a repository with a handful of services and one shared keys library that is a short list, and the diff is unambiguous. Doing that once catches today's collisions. Doing it in CI keeps it caught, but it is fragile: it only sees literals, not a value computed at runtime. Which points at the real fix. ## Closing it in the API The durable fix is to remove the free-form parameter. Two shapes work: **A registry.** The deriver holds the set of allocated purposes and rejects anything not in it: ```go func (d *Deriver) Key(purpose string, n int) ([]byte, error) { if purpose == "" { return nil, errors.New("kdf: empty purpose") } if !d.registered[purpose] { return nil, fmt.Errorf("kdf: unregistered purpose %q", purpose) } return hkdf.Key(sha256.New, d.master, d.salt, purpose, n) } ``` **Named accessors.** No string parameter at all — one exported method per purpose, so adding a purpose is a change to the library that a reviewer sees. This is stronger, because a caller cannot express the mistake. Either way, add the test that the audit was standing in for: derive every registered purpose and assert that no two outputs are equal. That test is trivial, runs in microseconds, and is the one check that fails loudly when a label is duplicated. ## Two environments deriving the same key A related report is worth separating. If staging and production derive the same key even though their info strings genuinely differ, the info string is not the culprit — the master secret or the salt is shared. HKDF is deterministic in all four inputs, so identical output means identical input. Either the same secret was provisioned to both environments, or both passed a `nil` salt against a copied secret. Including the environment name in the info string makes the two unrelated by construction, which is good for blast radius and bad for anything that has to move data between environments. It is a decision to make once, library-wide, not per call site. ## The expensive part is the fix, not the detection Once keys derived under the wrong label are protecting real artefacts, correcting the label is not a code change — it is a data migration. The new label yields a different key, so everything sealed under the old one has to be re-derived and rewritten: add the correct purposes, derive both old and new keys, accept either on read, write only the new, and retire the old label when nothing reads it any more. That asymmetry — cheap to prevent, expensive to correct — is the argument for putting the guard in before the first release.