Cryptographic Hashing and Authentication Questions

Comprehensive knowledge of hash functions including SHA-256, SHA-3, BLAKE2, and older algorithms like MD5 and SHA-1 (and why they're deprecated). Understand hash function properties: collision resistance, pre-image resistance, second pre-image resistance, and avalanche effect. Know applications of hashing in security. Understand message authentication codes (MAC), HMAC, and how they differ from hashing. Know authenticated encryption modes and why authenticated encryption is important. Understand why hash functions are critical for data integrity in cryptographic systems.

MediumTechnical

42 practiced

Implement HMAC-SHA256 in your preferred language. Your implementation must: handle keys longer than the block size by hashing them first, pad keys to block size, compute HMAC per the standard, perform constant-time tag comparison, and optionally support truncation to a specified tag length. Provide function signatures and describe any third-party libraries you would use or avoid.

Sample Answer

**Answer (Python implementation + explanation)**

**Approach (brief)**- Follow RFC 2104: if key > block_size (64 bytes for SHA-256) hash it; pad to block_size with zeros; compute inner = H((K ⊕ ipad) || message), outer = H((K ⊕ opad) || inner). Use constant-time tag compare. Allow optional truncation.

**Code**

python

import hashlib
import secrets
import hmac as _hmac  # only for compare_digest

BLOCK_SIZE = 64  # bytes for SHA-256
HASH = hashlib.sha256

def hmac_sha256(key: bytes, message: bytes, tag_len: int = None) -> bytes:
    """Return HMAC-SHA256 tag. tag_len=None means full 32 bytes; else <=32."""
    # Normalize key
    if len(key) > BLOCK_SIZE:
        key = HASH(key).digest()
    key = key.ljust(BLOCK_SIZE, b'\x00')  # pad to block size

    ipad = bytes((x ^ 0x36) for x in key)
    opad = bytes((x ^ 0x5C) for x in key)

    inner = HASH(ipad + message).digest()
    outer = HASH(opad + inner).digest()

    tag = outer if tag_len is None else outer[:tag_len]
    return tag

def verify_hmac(tag: bytes, key: bytes, message: bytes) -> bool:
    """Constant-time verification."""
    expected = hmac_sha256(key, message, tag_len=len(tag))
    return _hmac.compare_digest(expected, tag)

**Notes, libraries & security**- Use Python stdlib only: hashlib and hmac.compare_digest (or secrets.compare_digest). Avoid rolling your own crypto primitives beyond this construction.- Complexity: O(n) in message length. Constant-time compare avoids timing leaks. Truncation supported but reduces security (recommend >= 16 bytes depending on threat model).

HardTechnical

45 practiced

Given a Merkle–Damgård hash function H built from an iterated compression function f, show why a collision in the compression function f implies a collision in H. Explain how this structural property gives rise to length-extension attacks, and contrast this with the sponge construction used by SHA-3 which does not expose the same chaining state in the same way.

Sample Answer

**High-level claim**A collision in the compression function f implies a collision in the Merkle–Damgård hash H because H is just the iterated application of f over message blocks; equal inputs to f at any step produce equal chaining values and thus equal final hashes.

**Notation**

text

h_0 = IV
h_i = f(h_{i-1}, b_i)   for i = 1..n
H(m) = h_n   where m = b_1 || ... || b_n (with padding)

**Why a collision in f ⇒ collision in H**- Suppose ∃ distinct (h, b) ≠ (h', b') such that f(h, b) = f(h', b') (a compression-function collision).- Choose two messages m and m' whose processing reaches exactly those inputs to f as a step — i.e., m produces chaining value h before block b, and m' produces chaining value h' before block b'.- After processing the corresponding next blocks the chaining values become identical, and continuing with identical remaining blocks (or padding) yields H(m) = H(m'). Thus a collision in f lifts to a collision of the overall hash.

**Length-extension attacks**- Merkle–Damgård outputs the final chaining value directly; given H(m)=h_n and the length of m, an attacker can compute H(m || pad(m) || m_extra) by resuming iteration from h_n using blocks of m_extra, without knowing m.- This lets an attacker forge hashes of extended messages (integrity failure) for constructions that naively use H(m) as a MAC or assume resistance to extension.

**Contrast with sponge (SHA-3)**- Sponge uses an internal state split into rate r and capacity c; it absorbs input into the rate, permutes the whole state, and finally squeezes output from the rate.- Crucially, SHA-3 does not expose the full internal state as its output; domain separation/padding and the capacity c protect against continuing the same internal permutation from a revealed digest.- Therefore, knowing the output digest does not generally provide enough information to continue absorbing additional blocks and compute the digest of an extended message — length-extension is not feasible in the same straightforward way.

**Practical implication**- Merkle–Damgård-based hashes require careful construction (HMAC, prefix-free padding) to avoid misuse; sponge constructions provide stronger built-in resistance to length-extension when properly parameterized (rate/capacity separation and padding).

EasyTechnical

38 practiced

Explain the four canonical security properties of cryptographic hash functions — collision resistance, pre-image resistance, second-pre-image resistance, and the avalanche effect. For each property: define it formally, give a short intuitive example of an attack that violates it, and state why that property matters in real-world protocols (for example: digital signatures, commitment schemes, password storage, and integrity checks).

Sample Answer

**Collision resistance — formal definition**A hash H is collision-resistant if it is computationally infeasible to find distinct x != x' such that H(x) = H(x').

text

Find x, x' with x != x' and H(x) = H(x')

Intuitive attack: an adversary crafts two documents (e.g., two PDF versions) that produce the same hash so both appear signed by the same signature. Why it matters: digital signatures and certificates rely on uniqueness of the digest; collisions let attackers forge signed objects without the private key (used in existential forgery).

**Pre-image resistance — formal definition**Given a digest y, it is infeasible to find any x with H(x) = y.

text

Given y, find x such that H(x) = y

Attack: recover a password from a stored hash by reversing it directly. Why it matters: password storage and commitment schemes depend on inability to recover original input from hash values.

**Second-preimage resistance — formal definition**Given a specific x, it is infeasible to find x' != x with H(x') = H(x).

text

Given x, find x' != x such that H(x') = H(x)

Attack: replace a legitimate large file (software update) with an alternate malicious file that has same hash as the vetted original. Why it matters: integrity checks and signed binaries need that a particular signed payload cannot be swapped for another colliding payload.

**Avalanche effect — formal definition**A small change in input (e.g., one bit) causes each output bit to flip with probability ~1/2; there is no simple predictable relation. Attack: lack of avalanche lets an adversary craft structured inputs that produce related hashes, enabling pattern-based collisions or partial forgery. Why it matters: prevents differential attacks, ensures small manipulations are detectable in integrity checks and strengthens unpredictability needed across protocols.

Summary: collision resistance protects global uniqueness; pre-image protects secrecy of inputs; second-preimage defends specific-message substitution; avalanche ensures unpredictability and diffusion — all essential when designing secure protocols.

EasyBehavioral

42 practiced

Behavioral: Tell me about a time when you discovered or prevented a cryptographic weakness related to hashing or authentication in a project. Describe the context, how you identified the issue (tools, tests, code review), the technical root cause, the mitigation or redesign you recommended, and what you learned from the incident.

HardTechnical

52 practiced

Discuss security implications of using hash functions to accumulate entropy into an RNG (e.g., hashing multiple entropy sources into a single seed). When is simple hashing adequate versus when you should use a standardized DRBG (like HMAC-DRBG)? How do you design reseed and state-compromise recovery procedures?

Sample Answer

**High-level point:** Hashing multiple entropy sources is fine as an “entropy combiner” if you treat hashing as extraction (remove bias, collisions) and you have reliable, independent, min-entropy estimates. For a production RNG with long-lived state, prefer a standardized DRBG (e.g., HMAC-DRBG / CTR-DRBG / Hash-DRBG) because it provides proven extract-then-expand primitives, internal state management, reseeding logic, and forward/backward security guarantees.

Why simple hashing can be adequate- Use-case: one-shot seed accumulation (e.g., boot seed) where you collect many independent sources and immediately seed a secure PRF-based generator.- Requirements: each source has quantified min-entropy; adversary cannot control > allowed threshold; you apply a proper extractor (HMAC or HKDF-style keyed extract) rather than raw hash concatenation.- Example: seed = HKDF-Extract(salt, concat(samples)) then key the PRF. HKDF provides proven entropy extraction even when some inputs are weak.

When to use a standardized DRBG- Long-lived generator, repeated outputs, networked devices, or where state compromise is a real risk.- DRBGs specify internal state update rules, reseed intervals, prediction resistance modes, and limits on output-per-seed (e.g., NIST SP800‑90A constraints).- HMAC-DRBG gives a keyed PRF with internal K/V state and standardized reseed_counter semantics—this yields established forward secrecy on rekey and bounds on prediction after partial compromise.

Designing reseed policy and procedures- Entropy thresholds: require reseed when accumulated fresh entropy ≥ security_strength bits (e.g., 128/256).- Event triggers: periodic (time-based), request-count-based, health-test failure, or external event (network compromise).- Parameters: follow standards—e.g., limit output-per-reseed and reseed intervals (NIST suggests a reseed_counter limit like 2^48 for DRBGs; choose conservative values for embedded or high-risk systems).- Practical: reseed if either T seconds elapsed OR R outputs produced OR new hardware event; require at least X bits of estimated entropy from independent sources before accepting reseed.

State-compromise recovery- Detection: monitor entropy source health tests, seed-usage anomalies, and external alerts.- Immediate steps on suspected compromise: - Stop using existing generator output. - Gather fresh entropy from multiple independent sources; require conservative min-entropy (exceed security strength). - Reinitialize using an extractor (HKDF/HMAC) with fresh randomness and a new unique salt/nonce. - If possible, perform forward-recovery: rotate keys derived from the DRBG only after reseeding with entropy that adversary cannot have seen.- Additional mitigations: - Use forward-secure constructions (periodic rekey) so past outputs remain safe after compromise. - Keep an immutable audit log of reseed events and entropy estimates. - Zeroize internal state on compromise and enforce secure erasure.

Practical recommendations for a cryptographer- Prefer extract-then-expand (HMAC/HKDF) over raw hash concatenation.- Use a standardized DRBG for long-lived use and follow NIST/ISO guidance for limits and reseed policies; tune reseed counters conservatively for your threat model.- Always perform health tests, conservative entropy estimation, and require entropy from diverse, independent sources for reseed.- Define and document an incident response (stop, gather >security_strength bits, reinit, rotate dependent keys, log).

This approach balances theoretical soundness (provable extraction and PRF security) with operational resilience (reseed, detection, recovery).

Unlock Full Question Bank

Get access to hundreds of Cryptographic Hashing and Authentication interview questions and detailed answers.

Join thousands of developers preparing for their dream job.