Summary

  • El IESG aprobó el 2 de noviembre draft-ietf-hpke-hpke-06 para publicarlo como estándar propuesto; incluye construcciones KDF de una y dos etapas.
  • La propia versión 06 dice que las pruebas de HPKE citadas analizan la ruta de dos etapas y que la extensión formal a una etapa sigue pendiente.

El sello llegó antes que la demostración completa. El anuncio del IESG convirtió en decisión de publicación lo que hasta entonces era una propuesta en evaluación. El expediente de la IETF registra « Approved-announcement sent ». Falta todavía el texto final del RFC y su número; la aprobación del 2 de noviembre es el hecho institucional verificable.

HPKE reúne encapsulación de claves, derivación y cifrado autenticado. La versión habitual deriva material mediante dos operaciones, Extract() y Expand(). La revisión 06 permite además una operación Derive() que procesa entradas codificadas y etiquetadas en una etapa. El cambio afecta al calendario de claves, al secreto del mecanismo de encapsulación y a la exportación. La revisión 05 ya contenía esa vía; la novedad de la 06 es que explica con más claridad su límite probatorio.

En la sección 1.1, los autores atribuyen los análisis de seguridad citados a KDF de dos etapas. En la 9.1 indican que esperan trasladar el razonamiento a una función de una etapa modelable como oráculo aleatorio, pero que la extensión no se ha verificado formalmente. La sección 9.3 fija la propiedad que la derivación debe conservar: la salida del calendario ha de ser seudoaleatoria si el atacante desconoce el secreto compartido o la clave precompartida, incluso cuando conoce o elige las otras entradas. El borrador menciona SHAKE como ejemplo del tipo de función que satisface ese modelo.

La tabla de identificadores va por delante de la tabla de garantías. IANA ya publica cuatro KDF SHAKE/TurboSHAKE, 0x0010 a 0x0013, atribuidos al borrador poscuántico del grupo HPKE. Ese texto conserva el estado I-D Exists. La revisión aprobada pide una columna Two-Stage que marque esas entradas con N; la tabla pública observada el 3 de noviembre aún no la incluye. El código compartido resuelve el nombre de la opción. La garantía exige examinar su construcción y el análisis correspondiente.

Hay límites concretos que sí se pueden comprobar ya. En la ruta de una etapa, psk, psk_id e info admiten hasta 65.535 bytes cada uno porque usan prefijos de longitud de dos bytes. La salida exportada tiene otro límite de 65.535 bytes. Confundir esos límites operativos con una prueba de seguridad dejaría precisamente sin resolver la cuestión que el borrador reconoce.