Cryptographic Implementation Security Questions

Direct answer

Certificate validation bugs almost always come from skipping or short-circuiting one of the checks that make a certificate chain trustworthy: who signed it, is it still valid, and does it actually name the host being connected to. These bugs are usually introduced as a debugging shortcut (disabling a check to get past a local development error) that never gets re-enabled, or by hand-rolling validation logic instead of using the platform's TLS (Transport Layer Security) stack correctly. Below are five common mistakes, each with the resulting attack and the fix.

Structured elaboration

1. Skipping hostname verification. The code validates the certificate chain but never confirms the certificate's Subject Alternative Name (SAN) matches the hostname actually being connected to. Attack: an attacker with ANY valid certificate for ANY domain (one they legitimately purchased for, say, evil.com) can man-in-the-middle (MITM, intercept and impersonate) a connection to bank.com, because the code never checks that the certificate says bank.com. Fix: always verify the hostname against the SAN entries (not the deprecated Common Name field) using the platform TLS library's built-in hostname check, and never disable it as a "temporary" fix that ships.

2. Trusting expired or not-yet-valid certificates. The code skips the notBefore/notAfter validity-window check. Attack: an attacker who has compromised a private key tied to an EXPIRED certificate (which the legitimate owner may no longer be actively monitoring or rotating) can still impersonate the server if expiry is never checked. Fix: verify the current time falls within the certificate's validity window on every connection, and separately ensure the system clock itself is trustworthy, since a badly wrong clock defeats this check even when it is present.

3. Accepting self-signed certificates or disabling chain validation entirely. A "temporary" development workaround (setting an equivalent of verify=False or InsecureSkipVerify) ships to production. Attack: literally any man-in-the-middle proxy presents any self-signed certificate and it is accepted without complaint. Fix: never ship a disabled-verification code path; if local development genuinely needs it, gate it behind a build flag that cannot compile into a release build, and use a real local certificate authority (CA, the entity that issues and signs certificates) for development instead.

4. Not checking revocation status. The code validates the chain and expiry but never checks whether an intermediate or leaf certificate has been revoked via the Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP). Attack: a certificate authority's intermediate signing key is compromised and revoked; without revocation checking, a forged certificate chained through that intermediate is silently accepted even after the compromise is public. Fix: use OCSP stapling where available, fail closed (or soft-fail with logging and alerting, depending on risk tolerance) when revocation status cannot be determined for a high-value connection, and keep the local trust store current.

5. Accepting weak or deprecated signature algorithms or key sizes. The code accepts any certificate the chain-builder considers structurally valid, without an explicit allow-list of acceptable signature algorithms and minimum key sizes. Attack: an attacker exploits a known weakness in a deprecated hash algorithm (collision attacks against certificates signed with MD5 (Message-Digest Algorithm 5, an older cryptographic hash function long known to be broken) have been demonstrated in published research) to forge a certificate that still validates against a legitimate certificate authority's signature. Fix: pin an explicit allow-list of acceptable signature algorithms and minimum key sizes, reject anything outside it, and keep that allow-list current as algorithms are deprecated.

Worked example

Mistake 1 (hostname verification) is the easiest to demonstrate concretely, and it illustrates a real historical anti-pattern: hand-rolled code that checks whether the certificate name appears as a SUBSTRING of the requested host (or vice versa) instead of doing an exact or wildcard match.

def broken_match(requested_host: str, cert_name: str) -> bool:
    """VULNERABLE anti-pattern seen in real hand-rolled validation code:
    treats the certificate name as matching if it appears anywhere in (or
    the requested host appears anywhere in) the certificate's name field."""
    return cert_name in requested_host or requested_host in cert_name


def correct_match(requested_host: str, cert_name: str) -> bool:
    """RFC 6125 style matching: exact match, or a single leading wildcard
    label matching exactly one label (never matches the bare domain, never
    matches across multiple labels)."""
    requested_host = requested_host.lower()
    cert_name = cert_name.lower()
    if not cert_name.startswith("*."):
        return requested_host == cert_name
    wildcard_suffix = cert_name[1:]  # ".bank.com"
    if not requested_host.endswith(wildcard_suffix):
        return False
    remaining_label = requested_host[: -len(wildcard_suffix)]
    return remaining_label != "" and "." not in remaining_label


if __name__ == "__main__":
    cases = [
        # (requested_host, cert_name, description)
        ("bank.com", "bank.com", "exact match, legitimate"),
        ("www.bank.com", "*.bank.com", "wildcard match, legitimate"),
        ("bank.com", "*.bank.com", "bare domain against a wildcard cert (must NOT match)"),
        ("a.b.bank.com", "*.bank.com", "wildcard must not span multiple labels"),
        ("bank.com.evil-attacker.com", "bank.com",
         "attacker registers bank.com.evil-attacker.com and gets a REAL cert for it"),
        ("bank.com", "bank.com.evil-attacker.com",
         "same attack, arguments reversed (both orderings appear in real bugs)"),
    ]

    print(f"{'requested_host':32} {'cert_name':24} {'broken':>8} {'correct':>8}  description")
    for host, cert, desc in cases:
        b = broken_match(host, cert)
        c = correct_match(host, cert)
        print(f"{host:32} {cert:24} {str(b):>8} {str(c):>8}  {desc}")

    # the concrete failure: the substring check accepts the attacker's cert
    attack_host, attacker_cert = "bank.com", "bank.com.evil-attacker.com"
    print(f"\nattacker cert '{attacker_cert}' accepted for host '{attack_host}' "
          f"by broken_match: {broken_match(attack_host, attacker_cert)} (must be True to prove the bug)")
    print(f"same attack rejected by correct_match: "
          f"{correct_match(attack_host, attacker_cert)} (must be False)")

Running this against an attacker who registers bank.com.evil-attacker.com (a domain they legitimately own and can get a real certificate for) and presents it while the victim believes they are connecting to bank.com:

requested_host                   cert_name                  broken  correct  description
bank.com                         bank.com                     True     True  exact match, legitimate
www.bank.com                     *.bank.com                  False     True  wildcard match, legitimate
bank.com                         *.bank.com                   True    False  bare domain against a wildcard cert (must NOT match)
a.b.bank.com                     *.bank.com                  False    False  wildcard must not span multiple labels
bank.com.evil-attacker.com       bank.com                     True    False  attacker registers bank.com.evil-attacker.com and gets a REAL cert for it
bank.com                         bank.com.evil-attacker.com     True    False  same attack, arguments reversed (both orderings appear in real bugs)

attacker cert 'bank.com.evil-attacker.com' accepted for host 'bank.com' by broken_match: True (must be True to prove the bug)
same attack rejected by correct_match: False (must be False)

The substring check is not just insecure, it also happens to reject a legitimate wildcard match (www.bank.com against *.bank.com), which is a realistic reminder that hand-rolled security checks tend to be both unsafe AND unreliable at the same time.

Trade-offs and pitfalls

Fail-open versus fail-closed on revocation checking is a genuine tension: OCSP responders can be slow or unavailable, and a strict fail-closed policy turns an OCSP outage into a service outage, while soft-failing weakens the security guarantee; OCSP stapling (the server fetches and caches the OCSP response itself) reduces this tension considerably. Certificate pinning, if used, should pin to a CA or a backup key rather than a single leaf certificate, otherwise a legitimate certificate rotation breaks every pinned client. The recurring root cause across all five mistakes is the same: a check disabled "temporarily" for local development that ships to production; the fix is a build-time gate that makes shipping that code path structurally impossible, not a code review reminder.

Direct answer

Split the file into fixed-size chunks, encrypt each one independently with an AEAD (Authenticated Encryption with Associated Data) mode using a deterministic, counter-derived nonce, and bind each chunk's position and end-of-file status into the authenticated associated data (AAD) so the decryptor can detect reordering, duplication, or truncation. Handle key rotation with envelope encryption, each file is encrypted under its own randomly generated data key, and that data key is the thing wrapped under a longer-lived master key, so rotating the master key means re-wrapping small data keys, not re-encrypting file content.

Structured elaboration

Algorithms and modes

• AES-256-GCM, AES (the Advanced Encryption Standard) run in Galois/Counter Mode with a 256-bit key, or an equivalent AEAD construction, per chunk. AEAD is the right primitive family here specifically because it gives confidentiality and integrity together with no separate MAC (message authentication code) step whose ORDERING relative to decryption can be gotten wrong, exactly the class of bug that affects manually composed encrypt-then-MAC schemes.

Chunking and per-chunk nonce derivation

• Nonce = an 8-byte random salt generated fresh per FILE (via a cryptographically secure random source), concatenated with a 4-byte big-endian chunk counter. This guarantees uniqueness within a file as long as no file exceeds $2^{32}$ chunks and the per-file salt is never reused across files, and because the counter is deterministic rather than randomly drawn per chunk, the birthday-bound collision math that matters for a purely random-nonce scheme does not apply here at all, uniqueness is structural, not probabilistic.
• Fixed chunk size (for example, a power-of-two size chosen to balance overhead against granularity, discussed below) makes both encryption and decryption streamable: a writer never needs the whole file in memory, and a reader can decrypt starting at any chunk boundary without decrypting anything before it.

Metadata authentication

• Bind the chunk's INDEX and an explicit "is this the final chunk" flag into the AEAD's associated data for every chunk. Because the tag authenticates the AAD as well as the ciphertext, a decryptor that recomputes the AAD it EXPECTS for a given position, rather than trusting an AAD value carried alongside the ciphertext, will fail authentication on any chunk that has been moved, duplicated, or is missing its expected end-of-file marker.

Random access reads

• Because each chunk's nonce is fully determined by (per-file salt, chunk index), any single chunk can be decrypted independently, without touching any other chunk, which is exactly what random-access reads need. The cost is read granularity: a read that spans two chunks touches two independent decrypt calls, so the chunk-size choice below directly trades off against how fine-grained a "random access" read can be.

Key rotation without re-encrypting existing files

• Use envelope encryption: each file's chunks are encrypted under a randomly generated, file-specific data key, and that data key itself is encrypted ("wrapped") under a separate, longer-lived master key.
• Rotating the master key means re-wrapping every file's small data key, a cheap operation independent of file size, not re-encrypting the file's actual content. Content only needs full re-encryption if the DATA key itself, not the master key, is believed compromised.

Worked example

import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
from cryptography.exceptions import InvalidTag

KEY = AESGCM.generate_key(bit_length=256)
FILE_ID = bytes(range(8))     # random per-file salt so nonces never repeat across files
aead = AESGCM(KEY)

def chunk_nonce(file_id, chunk_index):
    """96-bit GCM nonce = 8-byte per-file random salt || 4-byte big-endian counter.
    Unique as long as no file exceeds 2**32 chunks and file_id is never reused."""
    return file_id + chunk_index.to_bytes(4, 'big')

def chunk_aad(chunk_index, is_last):
    """Authenticated (but not encrypted) metadata: binds each ciphertext chunk to its
    POSITION and whether it is the final chunk, so the decryptor can detect reordering,
    duplication, or truncation."""
    return chunk_index.to_bytes(4, 'big') + (b'\x01' if is_last else b'\x00')

def encrypt_file(chunks, key_aead):
    out = []
    for i, chunk in enumerate(chunks):
        is_last = (i == len(chunks) - 1)
        nonce = chunk_nonce(FILE_ID, i)
        aad = chunk_aad(i, is_last)
        ct = key_aead.encrypt(nonce, chunk, aad)
        out.append((nonce, aad, ct))
    return out

def decrypt_file(encrypted_chunks, key_aead, expected_count):
    plaintext = b''
    for i, (nonce, aad, ct) in enumerate(encrypted_chunks):
        is_last = (i == expected_count - 1)
        expected_aad = chunk_aad(i, is_last)
        # The decryptor recomputes the AAD it EXPECTS for position i and hands it to
        # the AEAD; it never trusts an AAD value carried alongside the ciphertext.
        plaintext += key_aead.decrypt(nonce, ct, expected_aad)
    return plaintext

chunks = [b'CHUNK-0:first  16B', b'CHUNK-1:second 16B', b'CHUNK-2:third  16B (last)']
encrypted = encrypt_file(chunks, aead)

recovered = decrypt_file(encrypted, aead, expected_count=len(chunks))
print('sequential decrypt matches original:', recovered == b''.join(chunks))

tampered = list(encrypted)
tampered[1], tampered[2] = tampered[2], tampered[1]   # attempt to reorder two chunks
try:
    decrypt_file(tampered, aead, expected_count=len(chunks))
    print('REORDERING WAS NOT DETECTED (this would be a broken scheme)')
except InvalidTag:
    print('reordering attempt raised InvalidTag at the swapped position: rejected')

truncated = list(encrypted[:2])   # drop the final chunk
try:
    decrypt_file(truncated, aead, expected_count=2)   # decryptor told (wrongly) count=2
    print('TRUNCATION NOT DETECTED via is_last flag (would be a broken scheme)')
except InvalidTag:
    print('truncation attempt raised InvalidTag: rejected')

Output:

sequential decrypt matches original: True
reordering attempt raised InvalidTag at the swapped position: rejected
truncation attempt raised InvalidTag: rejected

Reordering fails because the swapped chunk's ciphertext was authenticated under a different position's AAD than the one the decryptor now recomputes for that slot. Truncation fails because the decryptor recomputes an is_last=True AAD for the new final position, which does not match the AAD the (non-final) chunk was actually authenticated under.

Trade-offs and pitfalls

Chunk size is a genuine three-way trade-off: a larger chunk amortizes the fixed per-chunk tag overhead (GCM's authentication tag is a fixed size regardless of chunk size) over more data, but it coarsens random-access granularity and means a small in-place edit has to re-encrypt a larger chunk; a smaller chunk gives finer-grained seeks and cheaper partial updates at the cost of proportionally more tag overhead and more per-chunk encryption calls. A subtler pitfall lives in the truncation check itself, in the worked example above, decrypt_file's expected_count is a value the CALLER supplies, it is not itself authenticated by anything in the chunk stream. That is fine for the specific attack demonstrated (a caller who does not update expected_count to match a truncated stream gets a rejection), but a production design should not leave the expected total chunk count, or equivalently the expected file length, as an unauthenticated parameter a caller could be tricked into supplying incorrectly; the more robust version binds an authenticated file-level manifest (total chunk count, total length, or a hash of the chunk list) that is itself checked independently of any per-chunk flag, rather than relying solely on a per-chunk boolean.

Direct answer

The recurring misuses application developers make with cryptographic libraries are: using unauthenticated or pattern-preserving modes like ECB (electronic codebook, encrypts identical blocks to identical ciphertext), reusing a nonce (a number used once) or initialization vector (IV) where uniqueness is required, silently ignoring cryptographic error returns, and reaching for low-level primitives (raw block-cipher calls, raw RSA (Rivest-Shamir-Adleman) operations) instead of a vetted high-level construction. A company-wide strategy to reduce these needs to make the safe path the easy path: secure-defaults API wrappers, automated detection in CI/CD (continuous integration and continuous delivery, the pipeline that builds, tests, and ships code), a review checklist, and targeted education, in that priority order, since automation and defaults scale further than developer memory.

Structured elaboration

Common misuses:

• ECB mode: encrypts identical plaintext blocks to identical ciphertext blocks, leaking the structure of the plaintext even without breaking the key.
• Nonce or IV reuse: under a stream-cipher-style mode (CTR, or GCM's internal counter construction), reusing a nonce with the same key lets an attacker XOR (exclusive-or) two ciphertexts together and recover the XOR of the two plaintexts directly.
• Failing to check errors: ignoring a decryption or verification failure return value and proceeding to use the (possibly forged or corrupted) result anyway.
• Using low-level primitives incorrectly: calling raw block-cipher encrypt/decrypt without authentication, implementing custom padding, or using textbook RSA without proper padding, each reintroducing a class of well-studied vulnerability that a vetted high-level API already closed off.

Company-wide strategy:

1. Safer API wrappers (secure defaults): provide one internal, misuse-resistant encrypt/decrypt entry point that always uses authenticated encryption with associated data (AEAD), generates its own nonce, and returns a clear error type on any failure rather than a value that could be mistaken for success.
2. Automation in CI/CD: static analysis rules that flag ECB mode, hardcoded key material, and weak pseudorandom number generators used for security purposes, run on every pull request as part of a broader static and dynamic misuse-detection pipeline.
3. Code review checklist: a short, concrete checklist (not a vague "review for security") that reviewers actually use, covering the same anti-patterns the automation checks for, as a human backstop for what a linter cannot catch.
4. Education: targeted, example-driven training (not a generic "crypto 101" deck) tied to the specific anti-patterns your own incident history or static-analysis findings surface, delivered close in time to when a developer actually needs it (for example, as part of onboarding to a service that touches cryptographic code).
5. Deprecate and ban direct access: once the wrapper is available, add a CI rule that fails the build on any new direct import of the underlying low-level library, so new code cannot bypass the wrapper even during a long migration.

Worked example

The following demonstrates two of these misuses concretely and their fixes, executed against the real AES (Advanced Encryption Standard) implementation in a production cryptography library, not asserted in the abstract.

import hashlib
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

KEY = hashlib.sha256(b"pinned-demo-key-seed-v2").digest()


def ecb_encrypt(plaintext_blocks: bytes) -> bytes:
    encryptor = Cipher(algorithms.AES(KEY), modes.ECB()).encryptor()
    return encryptor.update(plaintext_blocks) + encryptor.finalize()


def aead_encrypt(plaintext: bytes, nonce: bytes) -> bytes:
    return AESGCM(KEY).encrypt(nonce, plaintext, associated_data=None)


if __name__ == "__main__":
    # --- misuse 1: ECB mode leaks that two 16-byte blocks are equal, even
    # though the attacker never learns the key or the plaintext values ---
    block = b"REPEAT-PATTERN!!"  # 16 bytes, deliberately identical across repeats
    plaintext = block * 4        # 4 identical plaintext blocks, e.g. a bitmap's blank rows
    ct_ecb = ecb_encrypt(plaintext)
    ciphertext_blocks = [ct_ecb[i:i + 16] for i in range(0, len(ct_ecb), 16)]
    print("ECB ciphertext blocks for 4 identical plaintext blocks:")
    for i, b in enumerate(ciphertext_blocks):
        print(f"  block {i}: {b.hex()}")
    print(f"all 4 ciphertext blocks identical: {len(set(ciphertext_blocks)) == 1} "
          f"(structure of the plaintext leaks with zero key knowledge)")

    # --- fix: AEAD (AES-GCM). Same repeating plaintext, unique nonce, and the
    # ciphertext no longer exposes block-level repetition ---
    nonce = hashlib.sha256(b"pinned-demo-nonce-seed-v2").digest()[:12]
    ct_gcm = aead_encrypt(plaintext, nonce)
    gcm_body = ct_gcm[:-16]  # strip the 16-byte auth tag to compare ciphertext body only
    gcm_blocks = [gcm_body[i:i + 16] for i in range(0, len(gcm_body), 16)]
    print(f"\nAES-GCM ciphertext blocks for the SAME repeating plaintext:")
    for i, b in enumerate(gcm_blocks):
        print(f"  block {i}: {b.hex()}")
    print(f"all 4 ciphertext blocks identical: {len(set(gcm_blocks)) == 1} (must be False)")

    # --- misuse 2: nonce reuse under a stream-like mode (CTR) leaks the XOR
    # of two plaintexts the moment the SAME nonce is reused ---
    def ctr_encrypt(pt: bytes, nonce: bytes) -> bytes:
        encryptor = Cipher(algorithms.AES(KEY), modes.CTR(nonce + b"\x00" * (16 - len(nonce)))).encryptor()
        return encryptor.update(pt) + encryptor.finalize()

    reused_nonce = hashlib.sha256(b"pinned-demo-nonce-seed-v2").digest()[:12]
    msg_a = b"transfer $10 to bob!!!"
    msg_b = b"transfer $99999 to eve"
    assert len(msg_a) == len(msg_b)

    ct_a = ctr_encrypt(msg_a, reused_nonce)
    ct_b = ctr_encrypt(msg_b, reused_nonce)  # same nonce reused: the bug

    xor_of_ciphertexts = bytes(a ^ b for a, b in zip(ct_a, ct_b))
    xor_of_plaintexts = bytes(a ^ b for a, b in zip(msg_a, msg_b))
    print(f"\nnonce reuse under CTR: XOR(ct_a, ct_b) == XOR(pt_a, pt_b): "
          f"{xor_of_ciphertexts == xor_of_plaintexts}")
    print("(an attacker who knows or guesses one plaintext recovers the other "
          "directly from that XOR, with no key material needed)")

Encrypting four identical 16-byte plaintext blocks (for example, four blank rows of a bitmap):

ECB ciphertext blocks for 4 identical plaintext blocks:
  block 0: d7e3d212a2dc0b5cc4d3de6846be077d
  block 1: d7e3d212a2dc0b5cc4d3de6846be077d
  block 2: d7e3d212a2dc0b5cc4d3de6846be077d
  block 3: d7e3d212a2dc0b5cc4d3de6846be077d
all 4 ciphertext blocks identical: True (structure of the plaintext leaks with zero key knowledge)

AES-GCM ciphertext blocks for the SAME repeating plaintext:
  block 0: 544f53cb313ae00cf273aa7c5c20ef99
  block 1: 05a2493f93909dcb04083f6b8781d9b0
  block 2: 7b0700634e38a35c2fd4bf9de50fdee8
  block 3: 5650b8a9e43732616eb5f999e4a39f4e
all 4 ciphertext blocks identical: False (must be False)

And nonce reuse under counter (CTR) mode with the same key and nonce for two different messages of equal length:

nonce reuse under CTR: XOR(ct_a, ct_b) == XOR(pt_a, pt_b): True
(an attacker who knows or guesses one plaintext recovers the other directly from that XOR, with no key material needed)

Trade-offs and pitfalls

A misuse-resistant wrapper only helps if direct access to the underlying library is actually removed from new code, not just discouraged; without an enforced CI ban, teams under deadline pressure route around the "recommended" wrapper the first time it doesn't do something they need. Static analysis for these patterns has a real false-positive cost (a rule that flags every Cipher.getInstance call rather than only ones with a hardcoded key gets disabled by frustrated developers within weeks); tune detection rules carefully rather than shipping a broad, noisy first pass. Education alone, without automation, does not scale: a training deck delivered once during onboarding is largely forgotten by the time a developer actually writes vulnerable code six months later; pair it with just-in-time automated feedback in the pull request itself.

Direct answer

Reusing one HMAC (hash-based message authentication code) key to sign both session tokens and password-reset links means a signature legitimately produced for one purpose can, if the two message formats are not unambiguously distinguishable, be replayed or reinterpreted as valid for the OTHER purpose, a cross-protocol confusion attack. The fix is both deriving separate, purpose-scoped subkeys from the shared secret AND framing each signed message so no two distinct (purpose, payload) pairs can ever serialize to the same bytes.

Structured elaboration

• The core weakness class: with one key used across two message types built by naive string concatenation of purpose + payload, two logically different inputs can produce byte-identical signed strings purely because of where the boundary between fields falls. An attacker holding a validly-issued signature for one message can find a DIFFERENT (purpose, payload) split that maps to the identical bytes, and that same signature verifies for the second purpose too.
• Additional risk even without the framing bug: sharing one key at all means any future weakness discovered in how ONE consumer uses the key (a debug endpoint that echoes part of a signature, a length-extension-prone construction) exposes both consumers, not just the vulnerable one; purpose isolation limits blast radius the same way network segmentation does.
• Fix, part 1, key separation: derive a distinct subkey per purpose from the shared master secret using a key derivation function (KDF) such as HKDF (HMAC-based key derivation function), with the purpose string as the context input: a session-token subkey and a reset-link subkey. A signature computed under one subkey structurally cannot verify under the other, closing the cross-purpose path even if the framing bug is also present.
• Fix, part 2, unambiguous framing: length-prefix or otherwise unambiguously delimit each field before concatenation, length(purpose) || purpose || length(payload) || payload, so no two distinct (purpose, payload) pairs can ever produce the same signed byte string. This closes the framing bug even if key separation somehow were not in place; the two fixes are complementary defense in depth, not alternatives to each other.
• Migration plan preserving backward compatibility: version the token format (a leading version byte or field); issue all new tokens exclusively under the new derived-key, domain-separated scheme; keep verification of the OLD scheme's tokens working only until their natural expiry, reset links already expire quickly, session tokens can be given a bounded grace window; and monitor old-format verification volume, removing that code path once it reaches zero rather than picking an arbitrary cutover date.

Worked example

import hmac
import hashlib
import struct


def naive_sign(key: bytes, purpose: str, payload: str) -> bytes:
    """VULNERABLE: purpose and payload are just concatenated. Two different
    (purpose, payload) pairs can produce the IDENTICAL signed bytestring."""
    message = (purpose + payload).encode()
    return hmac.new(key, message, hashlib.sha256).digest()


def domain_separated_sign(key: bytes, purpose: str, payload: str) -> bytes:
    """FIXED: length-prefix each field so no byte sequence is ambiguous
    between two different (purpose, payload) splits, AND derive a
    purpose-scoped subkey via HKDF so a session-token signature and a
    reset-link signature are never even computed under the same key."""
    subkey = hashlib.pbkdf2_hmac("sha256", key, purpose.encode(), 1)  # stand-in for HKDF-Expand(key, purpose)
    framed = struct.pack(">I", len(purpose)) + purpose.encode() + struct.pack(">I", len(payload)) + payload.encode()
    return hmac.new(subkey, framed, hashlib.sha256).digest()


if __name__ == "__main__":
    shared_key = b"user-42-per-user-secret-key-material"

    # --- the confusion: two DIFFERENT logical messages collide because the
    # naive concatenation has no boundary between purpose and payload ---
    session_sig = naive_sign(shared_key, "session:", "adminuser")
    reset_sig = naive_sign(shared_key, "session:a", "dminuser")
    print("naive concatenation, two different (purpose, payload) pairs:")
    print(f"  sign('session:', 'adminuser')  = {session_sig.hex()[:16]}...")
    print(f"  sign('session:a', 'dminuser')  = {reset_sig.hex()[:16]}...")
    print(f"  signatures identical: {session_sig == reset_sig}")

    # --- the concrete attack this enables: attacker holds a validly-issued
    # reset-link signature for a payload they control, and re-presents it as
    # a forged session token, if the verifier only checks the HMAC without
    # confirming which purpose issued it (the missing check is exactly what
    # a shared key make impossible to add cheaply) ---
    attacker_controlled_reset_payload = "a:admin-session-hijack"
    forged_reset_sig = naive_sign(shared_key, "reset:", attacker_controlled_reset_payload)
    equivalent_session_sig = naive_sign(shared_key, "reset:a", ":admin-session-hijack")
    print(f"\nattacker-obtained reset signature reused as a session signature: "
          f"{forged_reset_sig == equivalent_session_sig}")

    # --- the fix: domain-separated, purpose-scoped signing ---
    fixed_session_sig = domain_separated_sign(shared_key, "session:", "adminuser")
    fixed_reset_sig = domain_separated_sign(shared_key, "session:a", "dminuser")
    print(f"\ndomain-separated construction, same ambiguous split as above:")
    print(f"  sign('session:', 'adminuser')  = {fixed_session_sig.hex()[:16]}...")
    print(f"  sign('session:a', 'dminuser')  = {fixed_reset_sig.hex()[:16]}...")
    print(f"  signatures identical: {fixed_session_sig == fixed_reset_sig} (must be False)")

    # --- and purpose-scoped subkeys mean even IDENTICAL payloads signed for
    # different purposes produce different tags, so a reset-link signature
    # can never verify as a session-token signature at all ---
    same_payload_session = domain_separated_sign(shared_key, "session", "adminuser")
    same_payload_reset = domain_separated_sign(shared_key, "reset", "adminuser")
    print(f"\nsame payload 'adminuser', purposes 'session' vs 'reset': "
          f"signatures identical: {same_payload_session == same_payload_reset} (must be False)")

Running this with a shared per-user key and two different (purpose, payload) pairs that collide under naive concatenation:

naive concatenation, two different (purpose, payload) pairs:
  sign('session:', 'adminuser')  = 48280526e93ea281...
  sign('session:a', 'dminuser')  = 48280526e93ea281...
  signatures identical: True

attacker-obtained reset signature reused as a session signature: True

domain-separated construction, same ambiguous split as above:
  sign('session:', 'adminuser')  = 4d703ee8c96f4310...
  sign('session:a', 'dminuser')  = 11020fd1286362cb...
  signatures identical: False (must be False)

same payload 'adminuser', purposes 'session' vs 'reset': signatures identical: False (must be False)

Under naive concatenation the two logically distinct inputs sign to the identical value, meaning a signature the attacker legitimately obtained for one purpose verifies as the other purpose too. The domain-separated construction produces different signatures for the ambiguous split, and, independently, different signatures for the identical payload signed under two different purposes, confirming both fixes are doing real work.

Trade-offs and pitfalls

Deriving a purpose-scoped subkey adds a small, fixed computational cost per verification, one extra HMAC-based derivation, negligible compared to the cost of getting cross-purpose forgery wrong; do not skip it for performance reasons. A common pitfall in the migration plan: rotating the KEY without also fixing the FRAMING (or the reverse) leaves half the vulnerability in place; audit both independently, since a framing bug alone remains exploitable under separate purpose-scoped keys if two payloads for the SAME purpose can still collide, for example, no delimiter between a username field and a role field. Another pitfall: deriving the purpose-scoped subkey using ad hoc string concatenation into the KDF's context input, without also length-prefixing it, repeats the exact same class of bug one level up; use the KDF's own structured context parameter rather than manually gluing strings together anywhere in the design.

Direct answer

Audit two genuinely different surfaces, not one: how the hash's OWN compression function processes its input when that input is secret (an HMAC key, HMAC being a hash-based message authentication code, a password, key-derivation material), and how the hash's OUTPUT gets compared downstream in an authentication flow. The first surface only matters for hash constructions that use data-dependent memory access internally; most modern hash functions (SHA-2 and SHA-3/Keccak, both members of the SHA family, Secure Hash Algorithm) are built entirely from fixed-size rotations, shifts, XOR (exclusive OR), and modular addition with no table lookups at all, so they have no secret-dependent memory-access risk by construction. The second surface is where the real-world risk concentrates: a naive digest comparison in application code reintroduces exactly the early-exit timing leak seen in every other constant-time-comparison problem in this domain, regardless of how carefully the hash itself was implemented.

Structured elaboration

Risks inside the hash implementation itself, when it processes secret input

• Table-driven round functions: some hash DESIGNS (Whirlpool is the clearest example, it reuses a substitution box internally in the style of AES, the Advanced Encryption Standard) index a lookup table with intermediate STATE that depends on the input. If that input is secret (hashing a password directly, or the key-schedule step of an HMAC construction), this is the identical cache-timing risk as a table-driven cipher, and the remediation is the identical technique: touch every table entry and select with a mask, or use a table-less algebraic formulation.
• Most modern hash functions have NO such risk by construction: SHA-2's and SHA-3/Keccak's compression functions are built entirely from fixed-width rotations, shifts, bitwise XOR, and modular addition on words of a fixed size, operations whose cost and memory-access pattern do not depend on the data being processed. The audit question is genuinely "does THIS specific construction use data-dependent table lookups," not an assumption that all hash functions carry this risk.
• Branch risk: implementations that special-case short inputs, zero-length input, or add variable-time fast paths for performance can leak input-LENGTH-correlated timing. This is usually low severity, since length is rarely the secret, but worth flagging if length itself needs to stay hidden (for instance, a password-length distribution feeding an offline guessing strategy).

Risks in how the digest is compared, in authentication flows

• The highest-frequency real defect: comparing a computed digest to an expected one with memcmp, strcmp, or a hand-written == loop. Both memcmp and strcmp are general-purpose library functions with NO documented constant-time guarantee, and common implementations early-exit on the first differing byte, so using either one to check an API key hash, an HMAC signature, or a password hash reopens the same early-exit timing leak this whole domain keeps returning to, no matter how carefully the hash computation itself was written.
• This risk is entirely independent of the first: a perfectly side-channel-free hash implementation, compared with a leaky memcmp at the call site, is still a leaky authentication flow. Auditing the hash function alone and skipping every call site that consumes its output is the single most common gap in this kind of review.

Remediation strategies specific to hash functions and their comparisons

• For a hash construction with table-driven internals processing secret input: apply the same masked-selection or table-less techniques used for any other secret-indexed lookup, verified for correctness across every possible secret value, not spot-checked.
• For digest comparison at every call site that checks a hash against an expected value: use a comparison function specifically documented to be constant-time (Python's hmac.compare_digest, or the equivalent in any serious language's standard crypto library), never a raw equality check or a general-purpose string/memory comparison function, applied consistently, since a single missed call site (a debug code path, a legacy fallback comparison) reopens the whole class of bug.
• Prefer a language or library convention that makes the unsafe comparison hard to reach by accident: wrapping the expected digest in a type whose == operator is itself defined to be constant-time, so the safe path is also the path of least resistance for the next engineer touching that code.

Worked example

Illustrative contrast between the two internal-processing patterns (not tied to any specific real hash's exact round function, but representative of the actual design choice each family makes):

/* Pattern that DOES carry a secret-dependent memory-access risk if the input
   byte can be secret: an S-box-style table indexed by intermediate state. */
uint8_t sbox_round_step(uint8_t state, const uint8_t table[256]) {
    return table[state];              /* address depends on `state` */
}

/* The SHA-2 / Keccak family's actual style: fixed-width rotate/XOR/add only,
   no table, no data-dependent address, regardless of what `state` holds. */
uint32_t rotate_xor_round_step(uint32_t state, uint32_t round_constant) {
    uint32_t rotated = (state << 7) | (state >> (32 - 7));   /* fixed-width rotate */
    return rotated ^ round_constant;                          /* fixed-width XOR */
}

And the comparison-side pattern that matters far more often in practice, in Python, since correctness is what matters here rather than the specific language, using the identical constant-time comparison technique used for any other secret comparison:

import hmac

def naive_digest_check(computed_digest, expected_digest):
    return computed_digest == expected_digest   # early-exits on the first differing byte

def safe_digest_check(computed_digest, expected_digest):
    return hmac.compare_digest(computed_digest, expected_digest)

good = bytes.fromhex('a94a8fe5ccb19ba61c4c0873d391e987982fbbd3')
tampered = bytes.fromhex('a94a8fe5ccb19ba61c4c0873d391e987982fbbd4')

print('naive_digest_check (equal)   ->', naive_digest_check(good, good))
print('naive_digest_check (differ)  ->', naive_digest_check(good, tampered))
print('safe_digest_check  (equal)   ->', safe_digest_check(good, good))
print('safe_digest_check  (differ)  ->', safe_digest_check(good, tampered))

Output:

naive_digest_check (equal)   -> True
naive_digest_check (differ)  -> False
safe_digest_check  (equal)   -> True
safe_digest_check  (differ)  -> False

Both functions agree on every case, the fix changes only the amount of work performed on a mismatch, never the answer returned.

Trade-offs and pitfalls

The most common audit mistake is scope: reviewing the hash's own compression function carefully (checking for table lookups, checking round logic) while never tracing forward to every call site that compares its output, since that comparison is usually written in ordinary application code far from the cryptographic library and does not look like "crypto code" to a reviewer scanning for it. A second pitfall is over-generalizing from one hash family to another: flagging SHA-2 or SHA-3 for a table-lookup risk they structurally do not have wastes review time and trains reviewers to distrust flags that turn out to be false positives; the audit has to be specific to the actual construction in front of you, not a blanket rule applied to "hash functions" as a category.