Calculadora de derivação de chaves HKDF | RFC 5869 dividido em Extract e Expand

Ferramenta que separa o HKDF (função de derivação de chaves baseada em HMAC) em suas duas etapas para exibi-las juntas. Insira IKM, salt e info, escolha SHA-256/384/512, e ela mostra o PRK (chave pseudoaleatória) da etapa Extract ao lado do OKM (material de chave de saída) da etapa Expand, em hexadecimal.

💡 Sobre esta ferramenta

O HKDF é definido em dois passos internos: Extract -> Expand. A etapa Extract primeiro condensa a entropia dispersa do IKM em um PRK de comprimento fixo; a etapa Expand depois estica esse PRK, junto com o campo info, até o comprimento em bytes solicitado. Na prática, quase todas as bibliotecas expõem apenas uma chamada HKDF(ikm, salt, info, length) e escondem o PRK intermediário. Quando um valor não bate com a especificação, não dá para saber se a falha está no Extract ou no Expand.

Esta calculadora mostra PRK = HMAC(salt, IKM) separadamente e, logo abaixo, o OKM derivado dele. Se você deixar o salt vazio, ela segue o RFC 5869 usando HashLen bytes zero como salt. O OKM tem limite de 255xHashLen bytes (8160 para SHA-256); pedir mais retorna um erro. Tudo é calculado pela API Web Crypto nativa do navegador (crypto.subtle), então os resultados batem com os do seu ambiente de execução.

O IKM, o salt e o info que você digita são material de chave bruto: não saem do navegador, então você pode colar chaves de teste sem que sejam enviadas a lugar nenhum.

🧐 Perguntas frequentes

P. Qual a diferença entre PRK e OKM? O PRK (chave pseudoaleatória) é a saída do Extract: um HMAC do IKM com o salt como chave, de comprimento fixo igual ao hash. O OKM (material de chave de saída) é a saída do Expand: a chave final, do comprimento solicitado, esticada a partir do PRK e do info. O OKM é o que sua aplicação de fato usa.

P. O que acontece se eu deixar o salt vazio? O RFC 5869 determina que um salt ausente equivale a HashLen bytes zero. Esta ferramenta faz o mesmo: esvazie o campo salt e um salt de zeros será usado automaticamente.

P. Insiro hexadecimal ou texto? IKM, salt e info são tratados como sequências de bytes UTF-8. Se você digitar abc, obtém 3 bytes (0x61 0x62 0x63). Para bytes específicos, insira o texto cuja codificação UTF-8 produza esses bytes.

P. Qual o comprimento máximo do OKM? 255xHashLen bytes: 8160 para SHA-256, 12240 para SHA-384 e 16320 para SHA-512. O limite vem do contador de um único byte (1 a 255) da etapa Expand.

P. Em que difere de PBKDF2 ou Argon2? PBKDF2 e Argon2 são funções de alongamento que deliberadamente tornam o hashing de senhas mais lento. O HKDF distribui um segredo já de alta entropia em várias chaves com propósitos distintos; não tem fator de trabalho lento. Os objetivos são diferentes.

P. Minha saída não bate com outra ferramenta As diferenças vêm do preenchimento com zeros do salt, da presença ou não de info, e da interpretação UTF-8 versus bytes brutos. Confirme que as três entradas são idênticas byte a byte.

📚 Curiosidades

O HKDF foi padronizado em 2010 por Hugo Krawczyk e Pasi Eronen como RFC 5869. Seu design "Extract-then-Expand" parte de uma ideia elegante: primeiro extrair a entropia desordenada para um PRK uniforme, e depois expandi-lo em quantas chaves forem necessárias. Essa separação é o que permite derivar chaves seguras a partir de entradas enviesadas, como um segredo compartilhado Diffie-Hellman. O TLS 1.3 constrói todo o seu cronograma de chaves sobre o HKDF e usa bastante uma variante rotulada chamada HKDF-Expand-Label. Colocar uma string de contexto no campo info para dividir um mesmo IKM em chaves de "cifragem" e "autenticação" independentes é o padrão canônico, e a própria razão de existir o parâmetro info.