↓ Skip to main content
Le Site de François
  1. Index/

HMAC (Hash-based Message Authentication Code)

Cryptography Security Integrity Authentication Primitives

HMAC (Hash-based Message Authentication Code), standardised in RFC 2104 (1997) and FIPS 198-1, is a construction that produces a Message Authentication Code (MAC) by combining a cryptographic hash function with a shared secret key. A plain hash function provides integrity — any modification to a message changes its digest — but anyone can recompute the digest of a modified message, so a hash alone cannot prove that a message came from a specific party who holds a secret. HMAC adds authenticity: only a party who knows the key K can produce a valid HMAC(K, message), and only a party who knows K can verify it. The construction is HMAC(K, m) = H((K ⊕ opad) ∥ H((K ⊕ ipad) ∥ m)) — two rounds of hashing with the key XOR’d against inner and outer padding constants — a design chosen to be provably secure against length-extension attacks that affect naive H(K ∥ m) constructions with Merkle-Damgård hash functions like SHA-256. HMAC is proven secure as long as the underlying hash function is a pseudorandom function, a weaker requirement than collision resistance, meaning HMAC-SHA-256 remains secure even in scenarios where SHA-256 collision resistance might be weakened.

HMAC appears throughout the infrastructure stack in roles that require both integrity and authenticity from a shared secret. In TLS, the Finished message in the TLS 1.2 handshake is an HMAC over the handshake transcript, binding the negotiated session keys to the exact exchange that produced them and preventing transcript manipulation. In JWT (JSON Web Tokens), the HS256, HS384, and HS512 algorithm identifiers use HMAC-SHA-256/384/512 to sign the token header and payload with a shared secret — a symmetric alternative to the asymmetric RS256/ES256 used in OIDC ID tokens; HMAC-signed JWTs are appropriate for single-issuer/single-verifier scenarios (both parties share the secret) but cannot be used where multiple relying parties need to verify a token without also being able to forge one. TOTP (Time-based One-Time Password, RFC 6238) is built on HOTP (HMAC-based OTP, RFC 4226): the OTP is derived as HOTP(K, T) = truncate(HMAC-SHA-1(K, T)) where T is the current 30-second time window, and the shared secret K is the value encoded in an authenticator app’s QR code — meaning TOTP security depends entirely on the secrecy of that shared key and the integrity of its provisioning. API request signing (AWS Signature Version 4, GitHub webhook signatures) uses HMAC-SHA-256 over the canonical request string with a derived key, allowing the server to verify that a request was produced by a party knowing the API secret without transmitting the secret itself.

HMAC is also the construction inside HKDF (HMAC-based Key Derivation Function, RFC 5869), the standard key derivation function used throughout modern cryptographic protocols. HKDF takes an input key material (a shared secret from a Diffie-Hellman exchange, a pre-shared key, or a password hash), an optional salt, and optional context information, and uses two HMAC operations to produce a pseudorandom output of any desired length: HKDF-Extract(salt, IKM) = HMAC(salt, IKM) produces a uniformly distributed pseudorandom key, and HKDF-Expand(PRK, info, length) = HMAC(PRK, ...) stretches it to the required length. TLS 1.3 uses HKDF-SHA-256 or HKDF-SHA-384 to derive all session keys from the handshake transcript and the DH shared secret; ML-KEM decapsulation outputs a 32-byte shared secret that is typically passed through HKDF before use; WireGuard uses HKDF-BLAKE2s for key derivation. Against quantum computers, HMAC and HKDF are not directly threatened: Grover’s algorithm does not apply to MAC forgery (which requires knowing the key, not inverting the hash), and their security depends on the hash function’s pseudorandomness properties rather than its collision resistance. HMAC-SHA-256 and HMAC-SHA-384 are considered quantum-safe at their current key lengths, requiring no algorithm migration as part of the PQC transition.

Related

Hash Function (Cryptographic Hash Function)

Cryptography Security Primitives Integrity Pqc
A cryptographic hash function maps an input of arbitrary length (a file, a certificate, a password, a block of network data) to a fixed-length digest (also called a hash or fingerprint) with three security properties that distinguish it from non-cryptographic checksums. Preimage resistance: given a digest h, it is computationally infeasible to find any input m such that H(m) = h. Second preimage resistance: given an input m1, it is computationally infeasible to find a different input m2 such that H(m1) = H(m2). Collision resistance: it is computationally infeasible to find any pair (m1, m2) with m1 ≠ m2 such that H(m1) = H(m2). Collision resistance is the strongest property and implies second preimage resistance but not preimage resistance. These properties together make a hash function a one-way, tamper-evident fingerprint: two inputs that produce the same digest cannot be found by an adversary, and knowing the digest reveals nothing about the input beyond its length.

AES (Advanced Encryption Standard)

Cryptography Symmetric Encryption Nist Security Primitives
AES (Advanced Encryption Standard), standardised as NIST FIPS 197 in 2001, is the symmetric block cipher that underlies virtually all data encryption in modern infrastructure. It was selected through a five-year open competition that evaluated 15 candidate algorithms; the winner, Rijndael (designed by Joan Daemen and Vincent Rijmen), became AES. A block cipher takes a fixed-size block of plaintext and a key and produces a fixed-size block of ciphertext — AES always operates on 128-bit (16-byte) blocks, regardless of key size. Three key lengths are standardised: AES-128 (128-bit key, 10 rounds), AES-192 (192-bit key, 12 rounds), and AES-256 (256-bit key, 14 rounds), providing 128, 192, and 256 bits of security respectively against classical attacks. AES-256 is the conservative choice for data with long confidentiality requirements and is mandated by CNSA 2.0 for national security systems; AES-128 is widely deployed in TLS and provides adequate security for most workloads. The internal structure — SubBytes, ShiftRows, MixColumns, AddRoundKey — is fully public and has withstood over two decades of cryptanalysis; the best known attacks against full-round AES are theoretical and computationally infeasible, requiring work far beyond brute force but not threatening practical security.

FIDO (Fast IDentity Online) / FIDO2

Security Authentication Cryptography Pki Webauthn Mfa Zero-Trust
FIDO2 is the current generation of authentication standards produced jointly by the FIDO Alliance and the W3C, combining two specifications: WebAuthn (Web Authentication API, W3C Level 3, 2025) and CTAP2 (Client to Authenticator Protocol 2, FIDO Alliance). Its defining security property is origin binding: every FIDO2 credential is generated and used with a cryptographic binding to the specific Relying Party ID (RP ID — typically the registering domain’s origin) encoded into every authentication assertion. An authenticator will refuse to produce an assertion for evil.com using a credential registered with bank.com, even if the phishing site presents an identical login page and intercepts the WebAuthn call — the origin check is enforced inside the authenticator, not in JavaScript, and cannot be bypassed by a man-in-the-middle who controls the network or the browser DOM. This property is what makes FIDO2 phishing-resistant by construction, whereas TOTP, SMS OTP, and push-notification MFA are all interceptable by a real-time phishing proxy. FIDO2 is the direct successor to FIDO U2F (Universal 2nd Factor), which provided phishing resistance as a second factor only; FIDO2 extends the model to full passwordless primary authentication.