Saltar al contenido
ecdsa.com

Calculadora de HMAC y hashes online

Elige qué calcular —un HMAC con una clave secreta, resúmenes simples o una comparación en tiempo constante— y escribe: el resultado se actualiza a medida que escribes, en hex, base64 y base64url, con notas sobre lo que hace que dos sistemas obtengan resultados distintos.

100 % local: la clave, el mensaje y los resultados se quedan en tu navegador; no se envía nada a ningún servidor

Qué calcular

HMAC

Se compara en tiempo constante; un valor más corto se comprueba como MAC truncado

Ejemplo: caso de prueba 2 del RFC 4231 §4.3, HMAC-SHA-256 con la clave «Jefe», comprobado con el MAC publicado.

Hashes: fingerprints of data

A cryptographic hash function maps any input to a fixed-size digest: 32 bytes for SHA-256, 64 for SHA-512. Change one bit of the input and about half the output bits change. The SHA-2 family is specified in FIPS 180-4, SHA-3 — a different design on the Keccak permutation — in FIPS 202. The calculator computes all of them at once, plus SHA-1 and MD5, which survive in checksums and old protocols: collisions for MD5 can be produced in seconds, and the first SHA-1 collision was published in 2017. Use them to compare with existing values, never to protect anything new.

A digest proves nothing about who produced the data — anyone can recompute it. That is what a key is for.

HMAC: a hash with a key

HMAC (RFC 2104, FIPS 198-1) turns a hash into a message authentication code. Only someone who holds the key can compute the MAC of a message, and only someone who holds it can check one:

RFC 2104 §2
HMAC(K, m) = H((K ⊕ opad) ‖ H((K ⊕ ipad) ‖ m))

The key is padded to the hash's block size (64 bytes for SHA-256, 128 for SHA-512) and mixed in twice, with two different constants. The obvious shortcut — SHA-256(key ‖ message) — is broken for SHA-2: a hash built on the Merkle–Damgård construction lets anyone who knows one digest compute the digest of the message with more data appended, without the key. That is the length-extension attack, and the nested structure of HMAC is what defeats it.

A key longer than the block is first replaced by its hash (RFC 2104 §2), so extra length adds nothing. A key shorter than the output is discouraged (§3); for JWTs, RFC 7518 §3.2 requires an HS256 key of at least 32 bytes. The calculator says when your key is outside those bounds.

HMAC in JWTs

A JWT signed with HS256, HS384 or HS512 carries exactly this MAC: HMAC with SHA-256, SHA-384 or SHA-512 over the ASCII bytes of base64url(header).base64url(payload), base64url-encoded as the third part of the token. Paste the first two parts of a token as the message and the secret as the key, and the HMAC (base64url) output is the signature the token should end with. If it is not, the token was signed with another secret or changed. To build and sign a whole token instead, use the JWT signer; to find out whether the secret is one of the thousands that leaked into tutorials and code, the JWT secret checker.

Why two systems disagree

HMAC itself is deterministic: identical bytes in, identical MAC out. When two systems disagree, the bytes were different. The usual culprits, which the calculator points out as it sees them:

  • Encoding of the key or the message. The secret c2VjcmV0 used as text is eight bytes; decoded from base64 it is six. Choose how each input is written: text (UTF-8), hex, base64 or base64url.
  • A trailing newline. echo "message" | openssl dgst -sha256 -hmac key hashes the line break too; echo -n does not.
  • Windows line breaks (CR LF) against Unix ones (LF), and spaces at the ends of the text.
  • Unicode normalization. "é" can be one code point or two, and they are different bytes.
  • Output encoding. The same MAC is a 64-character hex string, a 44-character base64 string or a 43-character base64url string.

Checking a MAC: constant time

Comparing a received MAC with the computed one byte by byte and stopping at the first difference leaks, through timing, how many leading bytes were right — enough, over many requests, to forge a MAC one byte at a time. The comparison must take the same time wherever the first difference is. The Expected MAC field and the Compare two values mode compare that way, independent of how each value is written. A shorter expected value is checked as a truncated MAC, as RFC 2104 §5 allows, with a warning when it is shorter than half the output or 80 bits.

Everything stays here

The calculator runs on the audited @noble/hashes in your browser and makes no network request. A share link carries the algorithm, the message and the expected MAC — never the key, and never the two values of a comparison. The examples are published test vectors: RFC 4231 §4.3 for HMAC-SHA-256 and a NIST CAVP vector for SHA-256, and the page shows that it reproduces them.