Summary

  • Em 2 de novembro, o IESG aprovou draft-ietf-hpke-hpke-06 para publicação como Padrão Proposto, incluindo KDFs de uma e de duas etapas.
  • A revisão aprovada explicita que as provas de segurança citadas tratam da construção em duas etapas; a extensão formal para a alternativa em uma etapa ainda não foi verificada.

O carimbo chegou com uma nota de rodapé que deveria estar na capa. O comunicado do IESG aprovou a publicação do novo texto de HPKE, mecanismo que combina encapsulamento de chave, derivação e criptografia autenticada. O Datatracker da IETF mostra “Approved-announcement sent”. A edição final e um número RFC ainda virão. Já houve, porém, uma decisão institucional sobre o desenho que pretende suceder o RFC 9180.

No caminho conhecido, o KDF usa Extract() e depois Expand(). Na revisão 06, outro caminho chama Derive() uma vez, com entradas codificadas, rótulos próprios de HPKE e identificador da suíte. A mudança alcança o processo de derivação de chaves, o segredo do encapsulamento e a exportação. A revisão 05 já continha a construção em etapa única. A revisão aprovada faz uma coisa adicional e decisiva: delimita o que o argumento de segurança existente cobre.

Na seção 1.1, os autores dizem que as análises citadas consideram KDFs de duas etapas. A seção 9.1 espera que o raciocínio possa alcançar uma função Derive() modelada como oráculo aleatório, mas registra que essa extensão não passou por verificação formal. A seção 9.3 especifica a propriedade exigida: a saída do processo de derivação de chaves deve permanecer pseudorrandômica quando o adversário desconhece o segredo compartilhado ou a chave pré-compartilhada, mesmo que conheça ou escolha as demais entradas. Funções com saída de comprimento variável, como SHAKE, servem de exemplo para esse modelo.

Há uma segunda trilha administrativa. O registro da IANA já contém SHAKE128, SHAKE256, TurboSHAKE128 e TurboSHAKE256, com os códigos 0x0010 a 0x0013. Ele remete ao rascunho pós-quântico do grupo HPKE, ainda no estado I-D Exists. A revisão 06 manda acrescentar uma coluna Two-Stage e marcar esses quatro códigos com N; a tabela pública consultada em 3 de novembro ainda não exibe a coluna. O cadastro dá nomes interoperáveis a opções. A análise formal tem calendário próprio.

Os limites de implementação são mensuráveis: psk, psk_id e info aceitam até 65.535 bytes cada um na construção em uma etapa, por causa do prefixo de comprimento de dois bytes. A saída exportada tem outro teto, também de 65.535 bytes. Esses limites ajudam um teste de conformidade. A publicação que demonstrará formalmente o novo caminho é uma peça diferente. O anúncio tampouco traz um levantamento de quais produtos usam cada KDF; esse dado definiria o alcance prático da mudança.