What does `hmac.compare_digest` still leak, and how do you compare variable-length secrets?

### The guarantee, stated precisely `hmac.compare_digest` promises that the comparison does not short-circuit on content: it will not return sooner because the third byte differs than because the thirtieth does. What it does not promise is size-independence. The loop covers a number of positions derived from the arguments it was handed, so the total time still scales with how much data there is, and the documentation says so plainly: if the two arguments have different lengths, or an error occurs, a timing attack could theoretically reveal information about the *types and lengths* of the arguments — but not about their values. That is the whole caveat, and it is worth stating in an interview in exactly those terms, because the two wrong summaries are common in both directions. 'It leaks nothing' is over-claiming. 'It leaks the position of the first difference when the lengths differ' is under-claiming in a way that misunderstands the implementation — there is no early exit for an attacker to locate. ### When the caveat is irrelevant Almost always. A message authentication tag from a given algorithm is a fixed number of bytes. A digest is a fixed number of bytes. A token minted by your own code with a fixed-width generator is a fixed number of bytes. When both sides are structurally the same size, there is no length to leak, and passing the two values straight to the comparison is complete and correct. Adding a hashing step there buys nothing and costs a reviewer's attention. ### When it is not It matters when the value on the stored side is not fixed-width. A fraud-scoring service that has accumulated four generations of integration credentials — an early 16-character key, a later 43-character URL-safe token, a couple of hand-issued values of whatever length someone typed — has a stored side whose length varies per caller. Compare directly, and the response time carries a hint about the size of the credential the caller is being checked against, which narrows an attacker's search space before they have guessed a single byte. It is a small leak. It is also entirely avoidable. ### Hash first, then compare The fix is to give the comparison two values that are always the same size: ```python import hashlib, hmac def match(presented: str, stored: str) -> bool: a = hashlib.blake2b(presented.encode('utf-8'), digest_size=32).digest() b = hashlib.blake2b(stored.encode('utf-8'), digest_size=32).digest() return hmac.compare_digest(a, b) ``` Both arguments are now 32 bytes whatever went in, so no length is observable. Two other problems fall out at the same time: text of any encoding is accepted, since the encode step happens before the comparison, and the comparison itself only ever sees bytes, so the TypeError paths are gone. The cost is one fast hash per request, which is invisible next to a network round trip. ### The limits of hashing first Two caveats a senior candidate should raise unprompted. First, a plain fast digest is the right tool only when the underlying secret has real entropy — a randomly generated token of adequate width. If the secret is anything a human chose, a fast digest of it is offline-crackable should the stored side ever leak, and the value belongs in a purpose-built slow key-derivation function instead. Second, hashing does not hide *whether a record exists*: if the code returns early when no credential is on file for a caller, the existence of the account leaks through timing and through the shape of the response, regardless of how the comparison is done. Look the record up, and when there is none, compare against a stored dummy value of the same shape so both paths do the same work and return the same rejection. ### The order to do things in The complete verification path looks like: parse the request, take the non-secret identifier, look up the stored value (falling back to a dummy), normalise both sides to fixed-size digests, run exactly one constant-time comparison, and return one generic result for every kind of failure — with rate limiting in front of the whole thing. Every step there addresses a different leak, and the constant-time comparison is only one of them. ### You cannot unit-test this One practical consequence worth raising: there is no reliable way to assert constant-timeness from a Python test. Wall-clock measurements inside a test process are dominated by scheduling, garbage collection and the interpreter's own adaptive behaviour, so a timing assertion is a flaky test that will eventually be deleted. Test the behaviour — the right value returns True, every wrong one returns False, an absent record rejects identically — and enforce the property structurally instead: one audited helper that every secret comparison goes through, and a review rule against `==` on anything the codebase treats as a credential.