Calculadora HMAC, PBKDF2 e HKDF

Calcule um código de autenticação de mensagem com chave usando HMAC-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 ou HMAC-SHA-512 (RFC 2104) sobre texto, bytes hexadecimais ou ficheiros inteiros — chaves como texto, hex ou Base64. Ou derive chaves com PBKDF2 (RFC 8018) e HKDF (RFC 5869). Cada resultado pode ser apresentado em hex, hex em maiúsculas, Base64 ou Base64url. Para resumos simples veja o Gerador de hash; para somas de verificação veja a Calculadora CRC; para o HMAC usado dentro de JWT veja o Descodificador JWT.
Executa-se inteiramente localmente — chaves e mensagens nunca saem do seu separador. Ficheiros até 200 MB.
Construção: Saída:
Algoritmo HMAC: RFC 2104 — a variante MD5 requer md5.js (carregado por esta página).
Chave secreta (segredo partilhado; qualquer comprimento, o texto abaixo é codificado em UTF-8)
A leitura hex tolera espaços, dois-pontos e prefixos 0x; o Base64 tem de estar na forma padrão com ou sem preenchimento.
Uma chave vazia é legal segundo a RFC 2104, mas quase sempre é um erro — um HMAC sem chave é apenas um hash lento.
Texto da mensagem (os dados a autenticar, codificados em UTF-8)
Saída HMAC (uma linha: construção, parâmetros, valor)
A primeira linha regista os parâmetros exatos usados (algoritmo, leitura, tamanhos de entrada), para que um resultado copiado e colado seja sempre reproduzível.
Qual a construção de que precisa?
HMAC transforma um segredo partilhado mais uma mensagem num autenticador: o recetor que conhece a chave pode recalculá-lo e detetar adulteração. É o « HS256 » que existe em cada JWT assinado (veja o Descodificador JWT) e metade dos esquemas de assinatura de pedidos de APIs do mundo. PBKDF2 serve para esticar uma palavra-passe humana numa chave: repete o HMAC milhares de vezes para que cada tentativa de adivinhação custe ao atacante o mesmo atraso. HKDF serve para chaves de protocolo: pega em bytes secretos já aleatórios (por exemplo um segredo partilhado DH) e expande-os com segurança em várias chaves com finalidade própria — o TLS 1.3 deriva todas as suas chaves de tráfego desta forma. Regra prática: autenticar → HMAC; palavra-passe → PBKDF2 (ou scrypt/Argon2, veja o Gerador de hash de palavras-passe quando estiver publicado); segredo uniforme → HKDF.
Autoteste
Executa os motores da página contra vetores publicados: 10 âncoras HMAC (estilo RFC 2202/4231, cinco algoritmos × duas entradas), 6 âncoras PBKDF2 (SHA-1 e SHA-256 em três contagens de iterações) e os quatro casos de teste HKDF da RFC 5869, A.1–A.4. Nada é enviado para lado nenhum.
HMAC, PBKDF2 e HKDF — hashing com chave explicado do zero
Numa frase: um hash puro como o SHA-256 qualquer pessoa o pode calcular, pelo que não prova quem enviou uma mensagem — o HMAC mistura uma chave secreta para que só quem tem a chave consiga produzir (ou verificar) o resumo; o PBKDF2 e o HKDF reutilizam depois essa mesma maquinaria HMAC para transformar segredos em chaves, lentamente para palavras-passe e depressa para material já aleatório.
O que é o HMAC (RFC 2104)

A construção. O HMAC são duas execuções de hash, não uma. A sua chave é preenchida até ao tamanho de bloco da função de hash (64 bytes para MD5/SHA-1/SHA-256, 128 para SHA-384/512); a mensagem é submetida a hash uma vez com a chave em XOR com um preenchimento interno fixo, e esse resumo é submetido a hash de novo com a chave em XOR com um preenchimento externo fixo. Esta dupla sandwich é provadamente segura desde que a função de hash subjacente seja uma função pseudoaleatória decente — e é por isso que o HMAC-MD5 ainda resiste aos ataques de colisão práticos que quebraram o MD5 simples (embora esteja retirado de qualquer forma, veja abaixo).

Chaves. Qualquer comprimento de chave funciona: a mais curta do que o tamanho do bloco é usada tal como está (mas menos de 32 bytes é mal visto), a mais longa é primeiro submetida a hash. A mesma página permite-lhe escrever a chave como texto, hex ou Base64, para que uma chave de produção de 64 caracteres hexadecimais possa ser colada sem que alguém a confunda com uma palavra-passe de texto de 64 caracteres — a leitura fica registada na linha de saída exatamente por essa razão.

Onde se encontra. O campo HS256 do cabeçalho de um JWT é literalmente HMAC-SHA-256 sobre as partes do token codificadas em base64url (o Descodificador JWT deste site calcula exatamente isso quando cola um segredo HS256). As assinaturas de webhooks (Stripe, GitHub), o AWS SigV4, a proteção de registos TLS (versões mais antigas) e o primo do OpenSSH umac-64@openssh.com pertencem todos à mesma família.

Porque não simplesmente hash(mensagem || chave)? Extensão de comprimento: cada hash da família MD5/SHA-1/SHA-2 permite a um atacante que conheça H(segredo || msg) calcular H(segredo || msg || preenchimento || qualquer coisa) sem o segredo. A divisão interna/externa do HMAC elimina essa classe de ataques. É o erro caseiro mais comum em código de assinatura de APIs — e a razão pela qual o HMAC existe.

O que é o PBKDF2 (RFC 8018)

Lento por desenho. Uma palavra-passe tem talvez 40 bits de entropia real; a GPU de um atacante testa milhares de milhões de SHA-256 puros por segundo. O PBKDF2 executa HMAC(palavra-passe, sal) repetidamente — iter vezes — pelo que cada tentativa custa os mesmos iter HMACs para si e para o atacante. A predefinição aqui são 600 000 iterações com HMAC-SHA-256, a linha de base do OWASP Password Storage Cheat Sheet; o cursor vai até dez milhões porque as recomendações de segurança sobem à medida que o hardware acelera.

Sal. Um sal aleatório por palavra-passe significa que utilizadores iguais deixam de produzir hashes iguais, e as tabelas pré-calculadas (tabelas arco-íris) tornam-se inúteis. O sal não é secreto — é armazenado ao lado do hash — só tem de ser único. 16 bytes aleatórios é o normal.

Fraqueza conhecida. O PBKDF2 é difícil para o CPU, mas não para a memória: GPUs e ASICs paralelizam-no muito bem. É por isso que o conselho moderno é scrypt ou Argon2id quando se desenha o armazenamento de hashes de palavras-passe (a página do Gerador de hash de palavras-passe desta família cobre-os), mantendo-se o PBKDF2 como a resposta certa para compatibilidade e definições FIPS-140.

O que é o HKDF (RFC 5869)

Extrair e depois expandir. O HKDF tem dois trabalhos. Extrair: comprime o material de chave de entrada possivelmente irregular (um segredo partilhado Diffie–Hellman, por exemplo) juntamente com um sal num único chave pseudoaleatória curta PRK = HMAC(sal, IKM). Expandir: estica esse PRK até qualquer comprimento até 255 blocos de hash, com cada bloco de saída encadeado ao anterior e marcado pelo campo info. O resultado é que um único segredo pode dar-lhe, com segurança, uma chave de cifragem, uma chave MAC e um IV, todos separados.

Não serve para palavras-passe. O HKDF assume que a sua entrada já tem entropia total — faz um HMAC por cada 32 bytes de saída, pelo que uma palavra-passe humana passa por ele praticamente de imediato, exatamente o que um atacante quer. Passar palavras-passe pelo HKDF em vez do PBKDF2 é um erro de desenho clássico; o campo info serve para rótulos de finalidade ("client traffic key", "server iv"), e não para entropia extra.

Onde se encontra. O TLS 1.3 deriva cada chave que usa a partir do segredo do handshake através do HKDF; o WireGuard, o Signal, o EAP-TLS 1.3 e o JSON Web Encryption (como KDF direto de acordo de chaves) aparecem todos na mesma árvore familiar.

Valores de referência — reproduza-os nesta página

As duas primeiras tabelas são os vetores de teste em que se baseiam o botão Exemplo e o autoteste desta página (chave "key", mensagem « The quick brown fox jumps over the lazy dog »; depois o caso no estilo RFC de uma chave de 16 bytes 0x0b e a mensagem « Hi There »). Todos foram gerados por uma implementação nativa independente e voltaram a ser verificados nesta página.

HMAC de « fox », chave = keyResumo (hex)
HMAC-MD580070713463e7749b90c2dc24911e275
HMAC-SHA-1de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9
HMAC-SHA-256f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA-384d7f4727e2c0b39ae0f1e40cc96f60242d5b7801841cea6fc592c5d3e1ae50700582a96cf35e1e554995fe4e03381c237
HMAC-SHA-512b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec3935357e4e2317250d0372afa2ebeeb3a
Referências KDFParâmetrosSaída (hex, primeiros bytes)
PBKDF2-HMAC-SHA-1password / salt, c=4096, 32 bytes4b007901b765489abead49d926f721d065a429c12e463f6c4cd79401085b03db
PBKDF2-HMAC-SHA-256password / salt, c=4096, 32 bytesc5e478d59288c841aa530db6845c4c8d962893a001ce4e11a4963873aa98134a
HKDF-SHA-256 (RFC 5869 A.1)IKM=0x0b×22, sal=00..0c, info=f0..f9, L=423cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865
HKDF-SHA-256 (RFC 5869 A.2)IKM=00..4f, sal=60..af, info=b0..ff, L=82b11e398dc80327a1c8e7f78c596a49344f012eda2d4efad8a050cc4c19afa97c…
HKDF-SHA-256 (RFC 5869 A.3)IKM=0x0b×22, sal e info vazios, L=428da4e775a563c18f715f802a063c5a31b8a11f5c5ee1879ec3454e5f3c738d2d9d201395faa4b61a96c8
Erros comuns
  • Confundir HMAC com cifragem. O HMAC prova integridade e origem (dado um segredo partilhado); não esconde nada. Quem não tem a chave continua a ver a mensagem completa.
  • Confundir HMAC com uma assinatura. As assinaturas digitais são de chave pública: um assina, qualquer um verifica. O HMAC é simétrico: qualquer verificador também poderia forjar. Para não repúdio precisa de RSA/ECDSA (veja a ferramenta RSA desta família quando estiver publicada), e não de HMAC.
  • Diferenças de leitura da chave. Uma cadeia de 64 caracteres hexadecimais colada numa caixa de chave de texto torna-se 64 bytes, e não 32 — e o HMAC muda por completo. Esta página imprime a leitura na linha de saída; quando duas ferramentas discordam, isso é a primeira coisa a comparar.
  • Iterações PBKDF2 demasiado baixas. 1000 iterações era razoável em 2000; hoje as placas GPU devoram-nas. Se o seu sistema ainda armazena hashes de 1000 iterações, planeie uma migração de novo hash no login.
  • HKDF sobre uma palavra-passe. Um HMAC por bloco de saída significa que uma palavra-passe passa instantaneamente — use PBKDF2 (ou Argon2id) para palavras-passe e HKDF para segredos de alta entropia.
  • Reutilizar uma mesma chave derivada para tudo. A correção é gratuita: derive chaves separadas com rótulos info diferentes. Duas chaves a partir do mesmo IKM com rótulos diferentes são independentes por desenho.
Perguntas frequentes

O HMAC-MD5 está quebrado? Como função de hash resistente a colisões o MD5 está morto, mas a segurança do HMAC-MD5 depende do MD5 como função pseudoaleatória, e não se conhece nenhuma quebra prática. Mesmo assim está retirado — não há razão para o escolher em vez do HMAC-SHA-256, exceto por compatibilidade com um protocolo antigo.

Quão longa deve ser a minha chave HMAC? Pelo menos o tamanho de saída da função de hash (32 bytes para SHA-256) e gerada por um CSPRNG. É permitida uma chave mais curta do que o resumo, mas cada bit abaixo disso reduz diretamente a segurança.

O PBKDF2 com mais iterações torna-se « mais seguro » indefinidamente? Aumenta o custo do atacante de forma linear, mas também o custo do seu próprio login, igualmente de forma linear. O jogo é escolher a contagem mais alta que os seus utilizadores toleram — é isso que os números da OWASP calibram.

Porque é que o HKDF está limitado a 255 × o tamanho do hash? O ciclo de expansão é T(i) = HMAC(PRK, T(i-1) || info || i) com um contador i de um byte — 255 é o maior valor do contador, um limite estrutural rígido da RFC 5869, e não uma escolha de política.

Qual a diferença entre o PBKDF2 desta página e o Gerador de hash de palavras-passe? O mesmo algoritmo, função diferente. Esta página deriva bytes de chave em bruto para usar noutro lugar; a página de hash de palavras-passe produz cadeias de credenciais armazenadas (com sal e parâmetros incorporados) e verifica candidatos colados contra elas.