Resumo

  • No HKDF, o sal costuma ser não secreto. Ele pode reforçar a independência da extração, mas não acrescenta entropia ao material inicial, não autentica a origem e não impõe custo a quem testa senhas.
  • O parâmetro info atua na expansão e vincula as saídas a protocolo, versão, papel ou finalidade. Uma trilha confiável separa a procedência do IKM, a procedência do sal, o contexto codificado e a guarda de cada saída.

Quando o vazamento não é do segredo

Um alerta aponta que o sal da derivação apareceu numa captura. A primeira reação é pedir rotação de todas as chaves. A equipe de implementação responde mostrando que cliente e servidor calcularam os mesmos bytes. Nenhuma das duas evidências resolve a questão.

O RFC 5869 define o sal do HKDF como um valor aleatório opcional e não secreto. Na ausência dele, entra uma sequência de zeros do tamanho do hash. Portanto, enxergar o sal não revela por si só o IKM nem a chave derivada. E a igualdade entre resultados prova apenas que as duas pontas executaram uma transformação compatível. Ela não prova entropia suficiente, autenticidade dos pares, independência do sal ou uso correto da saída.

Hugo Krawczyk e Pasi Eronen assinaram juntos a especificação. O artigo de Krawczyk apresentou a análise formal do modelo extract-then-expand; seu histórico no IETF também inclui o RFC do HMAC, base do HKDF. O registro de premiação da ACM em 2025 reconheceu suas contribuições aos fundamentos e aos protocolos práticos de comunicação segura. Esse percurso importa menos como biografia do que como rastro de uma ideia: uma chave intermediária precisa atravessar uma fronteira explícita antes de ganhar função.

Extrair é concentrar, não fabricar

O primeiro estágio calcula:

PRK = HMAC-Hash(salt, IKM)

O material de chave inicial pode ter distribuição irregular ou estrutura parcialmente conhecida. A extração concentra a incerteza que já existe em uma chave pseudorrandômica de tamanho fixo, adequada para comandar o HMAC na etapa seguinte. Ela não aumenta o conjunto real de possibilidades. Se o IKM veio de uma senha humana, o atacante continua podendo enumerar candidatos e executar a mesma operação rapidamente.

Por isso, pular Extract depende do tipo de entrada. Um IKM que já seja uma boa chave pseudorrandômica pode, em situações específicas, alimentar Expand diretamente. Um valor Diffie–Hellman não deve ser tratado como uma chave HMAC uniforme; o RFC 5869 orienta a não omitir a extração nesse caso.

O NIST SP 800-56C Rev. 2 também organiza métodos de derivação para estabelecimento de chaves em extração, expansão e extração seguida de expansão. A separação não é estética de API. Ela permite declarar qual hipótese foi satisfeita antes que o segredo seja usado para uma cifra, autenticação ou exportação.

Público não quer dizer sob escolha do atacante

Um sal pode ser publicado, repetido quando o modelo permite ou derivado de nonces públicos autenticados. Mesmo com entropia limitada, pode melhorar a independência entre usos da função hash e a base analítica da extração. O benefício não está em esconder o valor.

Existe, porém, uma condição operacional: o sal deve ser independente do IKM. Se uma contraparte fornece valores usados para formá-lo, o protocolo precisa impedir seleção maliciosa sem autenticação. Um campo has_salt não captura essa diferença. O inventário precisa distinguir ausência com padrão de zeros, constante versionada do protocolo, sal público novo e autenticado, e sal influenciado por fonte não confiável.

No RFC 8188, o contraste aparece numa aplicação concreta. Um sal transmitido entra em HKDF-Extract para a codificação de conteúdo HTTP cifrado; uma cadeia fixa que nomeia a codificação entra em info na expansão. Os dois podem ser públicos porque respondem a perguntas diferentes.

A palavra sal engana no caso de senhas

Em armazenamento de senhas, um sal único reduz o valor de tabelas pré-calculadas e evita que senhas iguais produzam registros iguais. Ainda resta o pequeno universo das escolhas humanas. Contra busca offline, é preciso tornar cada tentativa intencionalmente cara em tempo ou memória.

O HKDF não tem fator de trabalho nem fase memory-hard. O próprio RFC 5869 afirma que Extract concentra entropia existente, mas não a amplifica, e que a construção não traz o mecanismo de lentidão necessário a uma KDF de senhas. O PBKDF2 expõe uma contagem de iterações. O Argon2 inclui parâmetros de memória, passagens e paralelismo. Nenhum corrige uma senha ruim, mas ambos permitem elevar o custo de adivinhação de modo que uma chamada rápida ao HKDF não faz.

Assim, “a senha tem sal” não encerra uma revisão. É necessário saber qual construção recebeu o sal, qual era a classe do material inicial, quanto custa um palpite, se o requisito era unicidade ou independência e quem o fez valer.

info é o endereço funcional da saída

HKDF-Expand recebe a PRK, info e o comprimento desejado. O info pode incluir protocolo, algoritmo, identidade, função ou comprimento. Sua finalidade é vincular a saída ao contexto de aplicação e impedir que o mesmo IKM produza material indistinto para domínios diferentes.

Mover esse dado para o sal não é equivalente. O RFC 5869 desaconselha usar a PRK diretamente como saída, mesmo quando ela já tem comprimento suficiente, porque isso evita info. Também desaconselha enfiar o contexto em Extract como substituição. A PRK é um segredo genérico para derivação; ainda não é chave de envio, IV ou segredo de retomada.

O TLS 1.3 transforma essa distinção em bytes. HKDF-Expand-Label acrescenta o prefixo tls13 , um rótulo e um contexto que pode carregar o hash da transcrição. Termos como finished, key e iv participam do cálculo.

O QUIC usa quic key, quic iv e quic hp para separar a chave AEAD, o vetor de inicialização e a chave de proteção do cabeçalho. O RFC 9001 explica que os rótulos também separam o domínio do QUIC do TLS. Um registro que diga apenas “HKDF-SHA256: ok” perdeu a evidência da finalidade.

O HPKE inclui HPKE-v1, a identificação da suíte e o rótulo em LabeledExtract e LabeledExpand, vinculando o resultado ao esquema, à versão e aos algoritmos. O MLS usa seu próprio prefixo MLS 1.0 e deriva segredos distintos para uma época de grupo. O texto legível não é uma política automática: a separação só existe se todas as implementações codificarem os campos sem ambiguidade e validarem versão e suíte.

Quatro recibos para a mesma derivação

O primeiro é a procedência do IKM. Um acordo Diffie–Hellman autenticado, uma chave aleatória, um segredo pré-compartilhado, uma senha e a saída de outra KDF podem ter tamanho igual, mas não compartilham as mesmas hipóteses.

O segundo é a procedência do sal: regra de geração, versão, autenticação, política de repetição e fundamento de independência em relação ao IKM. Não secreto é uma classificação de confidencialidade, não um certificado de origem.

O terceiro é o contexto codificado. Preserve uma impressão não secreta dos bytes efetivos: prefixo, versão, suíte, rótulo, papel, transcrição e comprimento. Um nome amigável de painel não revela concatenação ambígua nem divergência entre bibliotecas.

O quarto é a custódia da saída. Declare se o valor é chave, IV, PRK, segredo de exportação ou retomada; quem pode usá-lo, em qual época e quando deve ser apagado. A derivação correta não conserta reutilização de nonce ou retenção além do prazo.

Os quatro recibos colocam a igualdade de bytes no lugar certo. Ela demonstra consistência computacional, mas não autenticação, qualidade da fonte, correção de contexto ou descarte do segredo anterior.

Fontes