HKDF

HKDF foi definida pela RFC 5869 em 2010. A etapa Extract é recomendada, mesmo quando IKM parece uniforme, porque cria uma PRK de tamanho fixo e permite salt. Pode ser omitida apenas quando a especificação prova que a entrada já é uma boa chave pseudorrandômica e define. Em APIs, preferir sempre o fluxo completo. Se salt não é fornecido, usa-se string de zeros de HashLen; não é igual a salt aleatório, mas é definido. O salt pode ser público e precisa ser independente do IKM. Reutilizar salt não é catastrófico como nonce AEAD, porém contextos e protocolo devem. A PRK precisa ter pelo menos HashLen de entropia efetiva limitada pelo IKM. Expand gera no máximo 255*HashLen. `info` é opcional na RFC, mas deve ser usado para contexto. Deve conter identificadores não ambíguos de protocolo, versão, algoritmo, direção e participantes quando necessário. Não incluir segredo. HMAC-SHA-256 é comum; SHA-384 em suites. Não trocar sem especificação. HKDF não é password hashing, não adiciona memória/iterações. Não é armazenamento. Não é cifra. Não é autenticação de peer. É KDF. A segurança depende de IKM e protocolo. Em ECDH, validar chaves públicas e evitar all-zero em X25519 conforme protocolo. HKDF não corrige. Em sistemas de casa inteligente, a separação de domínio evita que a chave de um webhook seja igual à de comando. O uso de uma única root aumenta impacto; proteger em HSM/TPM e limitar. Para derivar chaves de muitos dispositivos, uma master global é operacionalmente conveniente, mas perigosa. Preferir secrets únicos ou derivação em HSM com domínio e plano de rotação. A função permite derivação determinística, o que ajuda recuperação, mas também significa que quem tem root e contexto recria tudo. O acesso root deve ser auditado. Bibliotecas devem ser usadas. Vetores da RFC validam. A saída deve ser apagada ao encerrar sessão. Em linguagens gerenciadas, limitar cópias. O protocolo precisa de versionamento e negociação autenticada para evitar downgrade.