3.2 Cryptographic Hash Functions, MACs & Digital Signatures

Cryptographic Hash Functions, MACs & Digital Signatures

Quick Summary: While encryption ensures confidentiality, cryptographic hash functions, Message Authentication Codes (MACs), and digital signatures ensure integrity, authenticity, and non-repudiation. For the CPSA exam, candidates must understand hash function properties, the cryptanalysis of MD5 and SHA-1, length extension attacks, HMAC construction (RFC 2104), digital signature verification mechanics, and Public Key Infrastructure (PKI) certificate revocation methods including CRL, OCSP, and OCSP Stapling.

---

Mathematical Properties of Cryptographic Hash Functions

A cryptographic hash function $H$ is a deterministic mathematical algorithm that ingests an arbitrary-length message $M$ and produces a fixed-size bit string known as a digest or hash value ($h = H(M)$).

Input Data (Any Size) ───► [ Cryptographic Hash Engine ] ───► Fixed-Length Output Digest
"hello"               ───► [ SHA-256 Algorithm         ] ───► 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
"War and Peace (Book)" ──► [ SHA-256 Algorithm         ] ───► e5a1f6... (Exactly 256 bits / 64 hex characters)

To be cryptographically secure, a hash function must satisfy five primary criteria:

1. Determinism and Fixed Output Length

The algorithm must always produce the exact same digest for an identical input, regardless of how many times it executes. The output length is strictly constant regardless of input size (e.g., SHA-256 always produces 256 bits).

2. Efficiency (High Computational Speed)

Computing $H(M)$ must be fast and consume reasonable processor resources for arbitrary datasets.

3. Pre-Image Resistance (One-Way Property)

Given an existing hash digest $h$, it must be computationally infeasible to find any original message $M$ such that $H(M) = h$.

• Brute-Force Complexity: For an $n$-bit hash function, recovering $M$ requires testing on average $2^n$ random inputs.
• Relevance: Protects stored hashed credentials against direct inversion.

4. Second Pre-Image Resistance (Weak Collision Resistance)

Given a specific, known input $M_1$, it must be computationally infeasible to find another distinct input $M_2 \neq M_1$ such that $H(M_1) = H(M_2)$.

• Brute-Force Complexity: Requires approximately $2^n$ operations.
• Relevance: Prevents an attacker from substituting a malicious binary or contract for a legitimate file while maintaining an identical hash.

5. Collision Resistance (Strong Collision Resistance)

It must be computationally infeasible to find any two arbitrary distinct inputs $M_1 \neq M_2$ such that $H(M_1) = H(M_2)$.

• The Birthday Paradox Complexity: Finding an arbitrary pair of matching hashes is exponentially easier than finding a pre-image for a specified target. Governed by the Birthday Problem, collisions occur after testing roughly $\sqrt{2^n} = 2^{n/2}$ random messages.
• Security Strength: An $n$-bit hash function provides only $n/2$ bits of security against collision attacks.

6. The Avalanche Effect

A minor change in the input (such as flipping a single bit) must result in a drastic, pseudorandom change in the output digest (approximately 50% of the output bits flipping). Without the avalanche effect, cryptanalysts can apply statistical gradient analysis to reverse-engineer inputs.

---

Major Cryptographic Hash Algorithms & Historical Cryptanalysis

Message Digest 5 (MD5)

Designed by Ron Rivest in 1991, MD5 processes input data in 512-bit blocks through 64 operations divided into four rounds. In 2004, Xiaoyun Wang and colleagues published analytical collision attacks that broke MD5's collision resistance.

• Rogue CA Demonstration (2008): Sotirov et al. leveraged MD5 collision attacks to forge a valid intermediate Certificate Authority certificate signed by a legitimate commercial CA, allowing them to issue rogue SSL certificates for any website on the internet.
• Flame Malware (2012): The sophisticated Flame cyberespionage campaign used MD5 collisions to forge code-signing certificates from Microsoft Terminal Server licensing authorities, enabling malware to disguise itself as an official Microsoft Windows Update.
• Triage Context: In modern penetration tests, finding MD5 used for password storage (without salt), file integrity verification, or digital signatures represents a high-priority vulnerability. Collisions can be computed on standard laptop CPUs in seconds using tools like fastcoll.

Secure Hash Algorithm 1 (SHA-1)

Published by NIST in 1995 (FIPS 180-1), SHA-1 produces a 160-bit digest. Despite a theoretical collision resistance of $2^{80}$ operations, mathematical weaknesses emerged in 2005.

• The SHAttered Demonstration (2017): Researchers from CWI Amsterdam and Google announced the first practical collision attack against SHA-1. They produced two distinct PDF documents with entirely different contents that yielded the identical SHA-1 hash after $2^{63.1}$ evaluations (equivalent to 6,500 CPU-years or 110 GPU-years).
• Compliance & Deprecation: Modern operating systems, web browsers, and TLS certificates completely reject SHA-1. NIST formally retired SHA-1 under SP 800-131A.

Secure Hash Algorithm 2 (SHA-2)

Standardized in FIPS 180-4, the SHA-2 family consists of six hash functions: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. Built on 32-bit (SHA-256) or 64-bit (SHA-512) words, SHA-2 remains resistant to all known practical collision and pre-image cryptanalysis.

The Merkle-Damgård Construction & Length Extension Attacks

MD5, SHA-1, and SHA-2 all rely on the Merkle-Damgård construction. The message is padded, divided into equal blocks ($M_1, M_2, \dots, M_k$), and iteratively fed into a one-way compression function ($f$). The compression function updates an internal state vector ($H_i$):

$H_i = f(H_{i-1}, M_i)$

The final internal state vector $H_k$ is directly output as the hash digest.

The Length Extension Vulnerability: Because the final hash digest of SHA-256 is simply the internal state of the compression function after the last block, an attacker who intercepts $h = H(\text{secret} \parallel \text{data})$ and knows the length of the data can append their own malicious extension data ($M_{\text{ext}}$). The attacker initializes the hash algorithm's internal registers with $h$ and hashes $M_{\text{ext}}$ to produce a valid signature:

$h' = H(\text{secret} \parallel \text{data} \parallel \text{padding} \parallel M_{\text{ext}})$

This attack succeeds without ever knowing the secret key. Therefore, naive MAC constructions like $H(\text{key} \parallel \text{message})$ are critically broken.

Secure Hash Algorithm 3 (SHA-3 / Keccak)

Standardized in FIPS 202 (2015), SHA-3 resulted from a 5-year public NIST competition won by the Keccak team. SHA-3 uses an entirely different mathematical architecture called the Sponge Construction based on the Keccak-$f[1600]$ permutation:

1. Absorbing Phase: Input message blocks are iteratively XORed into a subset of the internal state (the rate $r$), interspersed with permutation rounds across the full state (rate $r$ + capacity $c$).
2. Squeezing Phase: The state is permuted, and output bits are extracted sequentially to form the digest.

Because the internal capacity $c$ is never exposed in the output, SHA-3 is inherently immune to length extension attacks without needing special wrapper constructions.

---

Message Authentication Codes (MACs) and HMAC

A Message Authentication Code (MAC) verifies both data integrity and data origin authenticity using a symmetric shared secret key $K$. It allows communicating parties to detect both accidental bit-flips and active attacker tampering.

HMAC Construction (RFC 2104):
                    ┌────────────────────────────────────────┐
                    │ Inner Hash:                            │
Message (M) ───────►│ H( (K' ⊕ ipad)  ||  M )                │
                    └───────────────────┬────────────────────┘
                                        │ Inner Digest
                    ┌───────────────────▼────────────────────┐
                    │ Outer Hash:                            │
                    │ H( (K' ⊕ opad)  ||  Inner Digest )     │ ──► HMAC Output Tag
                    └────────────────────────────────────────┘

Hash-Based Message Authentication Code (HMAC / RFC 2104)

To defeat length extension attacks while leveraging the high performance of Merkle-Damgård hash functions, RFC 2104 established HMAC. HMAC combines a secret key $K$ and message $M$ using a two-pass nested hashing structure:

$\text{HMAC}_H(K, M) = H\Big((K' \oplus opad) \;\parallel\; H\big((K' \oplus ipad) \;\parallel\; M\big)\Big)$

• Key Normalization ($K'$): If key $K$ is longer than the hash block size $B$ (e.g., 64 bytes for SHA-256), it is pre-hashed: $K' = H(K)$. If shorter, it is padded with zeros on the right until it equals $B$ bytes.
• Inner Pad ($ipad$): The byte 0x36 repeated $B$ times (e.g., 64 bytes of 0x36).
• Outer Pad ($opad$): The byte 0x5C repeated $B$ times (e.g., 64 bytes of 0x5C).
• Inner Pass: $K'$ is XORed with $ipad$, concatenated with message $M$, and hashed to produce an intermediate digest.
• Outer Pass: $K'$ is XORed with $opad$, concatenated with the intermediate digest, and hashed again to yield the final HMAC tag.

The Non-Repudiation Limitation of HMAC

HMAC relies on a symmetric shared secret known to both parties (Alice and Bob). While an external eavesdropper (Eve) cannot generate a valid HMAC tag, Bob can generate any tag that Alice can generate. Therefore, HMAC does not provide non-repudiation; Alice can always claim that Bob created or altered the message.

---

Digital Signatures: Integrity, Authenticity & Non-Repudiation

Digital signatures combine cryptographic hash functions with asymmetric cryptography to provide three fundamental security guarantees:

1. Authenticity: Confirms that the message was signed by the legitimate holder of the private key.
2. Integrity: Confirms that the message has not been altered in transit.
3. Non-Repudiation: The signer cannot deny having signed the message because the private key is uniquely and exclusively held by them.

Signing and Verification Lifecycle

Signing Procedure (Sender / Alice):
Message (M) ──► [ Hash Function H(M) ] ──► Digest ──► [ Encrypt with Alice's Private Key ] ──► Digital Signature

Verification Procedure (Receiver / Bob):
1. Received Message (M) ──► [ Hash Function H(M) ] ──────────────► Computed Digest (h1)
                                                                            │
2. Signature ─────────────► [ Decrypt with Alice's Public Key ] ──► Extracted Digest (h2)
                                                                            │
3. Match Verification: ───────────────────────────────────────────► Check if h1 == h2
   [ Valid Signature (Intact) ] ◄── (If Equal)    (If Different) ──► [ INVALID / TAMPERED ]

1. Signing Phase:
   • Alice takes the message $M$ and computes a cryptographic hash: $h = H(M)$.
   • Alice encrypts the hash $h$ using her private key ($K_{\text{privA}}$): $S = \text{Sign}(K_{\text{privA}}, h)$.
   • Alice transmits both the plaintext message $M$ and digital signature $S$ to Bob.
2. Verification Phase:
   • Bob independently computes the hash of the received message: $h_1 = H(M)$.
   • Bob decrypts the signature $S$ using Alice's public key ($K_{\text{pubA}}$) to extract the original digest: $h_2 = \text{Verify}(K_{\text{pubA}}, S)$.
   • Bob compares $h_1$ and $h_2$. If $h_1 == h_2$, the signature is cryptographically valid. If any bit of the message was altered in transit, $h_1 \neq h_2$, and verification immediately fails.

Modern Signature Schemes

• RSA-PSS (Probabilistic Signature Scheme): Replaces legacy PKCS#1 v1.5 padding with randomized salt, providing provable security against chosen-message attacks.
• ECDSA: Standardized in FIPS 186-4, uses elliptic curves for signatures. Critical weakness: ECDSA requires a cryptographically random per-signature nonce ($k$). If an attacker captures two signatures generated with the same nonce $k$, the signer's private key is immediately exposed (the flaw that allowed George Hotz / fail0verflow to extract the Sony PlayStation 3 master private key in 2010). Modern implementations use RFC 6979 deterministic nonce generation.
• Ed25519 (EdDSA): Uses Twisted Edwards curves, provides high performance, and is immune to random number generator flaws and side-channel cache attacks.

---

Public Key Infrastructure (PKI) & X.509 Architecture

Asymmetric cryptography requires a mechanism to securely bind a public key to an individual, server, or organization. Without binding, an attacker could execute an inline Man-in-the-Middle attack by substituting their own public key. Public Key Infrastructure (PKI) provides this trust hierarchy.

PKI Components

• Certificate Authority (CA): A trusted entity that verifies identities and issues cryptographically signed digital certificates.
• Registration Authority (RA): An entity that verifies applicant credentials, domain ownership, and company identity before submitting the request to the CA.
• Certificate Repository / CRL Distribution Point: Publicly accessible servers hosting issued certificates and revocation records.

Hierarchical Trust Model

• Root CA: Top of the trust chain. Signs its own certificate (Self-Signed Root Certificate). Modern operating systems and browsers ship with a pre-installed "Trust Store" containing ~150 trusted Root CA certificates.
• Intermediate CAs (Subordinate CAs): The Root CA delegates signing authority to one or more Intermediate CAs. The Root CA private key is kept strictly offline in an air-gapped Hardware Security Module (HSM) to protect it from network compromise.
• Leaf (End-Entity) Certificates: Issued to web servers, mail servers, code signers, or individuals. Browsers validate the chain of trust iteratively from the leaf certificate, through the intermediate CAs, up to a trusted Root CA.

Trust Chain Hierarchy:
[ Root CA ] (Self-Signed, Stored in OS Trust Store, Air-Gapped HSM)
    │
    └──► [ Intermediate CA ] (Online Signing Authority)
            │
            └──► [ Leaf Certificate ] (e.g., *.bank.com, Issued to Web Server)

Anatomy of an X.509 v3 Certificate

RFC 5280 defines the X.509 standard structure:

• Version: Typically v3 (adds standard extension fields).
• Serial Number: Unique positive integer assigned by the CA.
• Signature Algorithm: Algorithm used to sign the certificate (e.g., sha256WithRSAEncryption).
• Issuer: Distinguished Name (DN) of the CA that signed the certificate.
• Validity Period: Strict Not Before and Not After UTC timestamps.
• Subject: Distinguished Name of the entity owning the certificate.
• Subject Public Key Info: The entity's public key algorithm and raw key data.
• Key Usage & Extended Key Usage (EKU): Defines authorized operations (e.g., Server Authentication, Client Authentication, Code Signing).
• Subject Alternative Name (SAN): Modern replacement for the deprecated Common Name (CN). Contains domain names, subdomains, and IP addresses protected by the certificate (supporting multi-domain and wildcard certificates).
• AIA (Authority Information Access): URLs pointing to intermediate CA certificates and the CA's OCSP responder.

---

Certificate Revocation: CRL vs. OCSP vs. OCSP Stapling

Certificates must be revoked before their expiration date if a private key is compromised, domain ownership transfers, or organizational details change. Three mechanisms handle revocation checks:

1. Certificate Revocation List (CRL)

A CRL is a time-stamped, CA-signed list containing the serial numbers of revoked certificates. Clients download the CRL from the URL in the certificate's CRL Distribution Points extension.

• Downfalls: CRLs grow rapidly in size (often tens of megabytes), consuming massive bandwidth. Because CAs only generate CRLs periodically (e.g., every 24 hours), a dangerous window of vulnerability exists between a key breach and the next published CRL.

2. Online Certificate Status Protocol (OCSP / RFC 6960)

OCSP provides real-time revocation status. Instead of downloading a massive list, the client queries the CA's OCSP responder over HTTP, submitting the target certificate's serial number. The responder returns one of three statuses: good, revoked, or unknown.

• Latency: Every HTTPS connection requires an additional DNS lookup and HTTP round-trip to the CA before completing the TLS handshake.
• Privacy Leakage: The CA learns the IP address of every client and every website they visit in real time.
• Soft-Fail Vulnerability: To maintain browsing availability, most modern browsers implement soft-fail: if the CA's OCSP responder is offline or blocked by a network attacker, the browser silently ignores the failure and accepts the certificate anyway.

3. OCSP Stapling (RFC 6066 / Certificate Status Request)

OCSP Stapling resolves the latency, privacy, and soft-fail flaws of standard OCSP:

1. The web server periodically queries the CA's OCSP responder (e.g., every 60 minutes).
2. The CA returns a cryptographically signed, timestamped OCSP response token.
3. The web server caches this signed token.
4. When a client initiates a TLS connection, the server staples the cached OCSP response token directly into its ServerHello handshake message.
5. The client verifies the CA's signature on the stapled token without making any external network requests.

Security Hardening: With the OCSP Must-Staple X.509 extension configured, the client treats a missing stapled OCSP response as a fatal, unrecoverable TLS error, fully closing the soft-fail security loophole.