Summary

  • Le 2 novembre, l’IESG a approuvé draft-ietf-hpke-hpke-06 pour publication comme norme proposée; le texte prévoit des KDF en une ou deux étapes.
  • Le projet situe les preuves de sécurité citées du côté des KDF en deux étapes. Leur extension formelle à la nouvelle voie reste à établir.

Un comité peut ouvrir une porte sans prétendre avoir terminé tous les calculs derrière elle. L’annonce de l’IESG approuve le successeur de HPKE, le mécanisme qui combine encapsulation de clé, dérivation et chiffrement authentifié. Le registre de suivi de l’IETF affiche « Approved-announcement sent ». L’attribution d’un numéro RFC et la publication définitive viendront plus tard. La décision du 2 novembre porte déjà sur une architecture élargie.

Dans la construction habituelle, la dérivation sépare Extract() et Expand(). Le projet révision 06 décrit aussi Derive() en un seul appel sur des entrées encodées et étiquetées. Ce choix traverse le calendrier de clés, le mécanisme d’encapsulation et l’exportation de secrets. La révision 05 avait déjà introduit la voie en une étape; la révision approuvée rend surtout explicite la frontière de son analyse.

Le passage décisif se trouve au début et au chapitre 9 du document. Les analyses citées portent sur le chemin à deux étapes. Pour le chemin à une étape, les auteurs attendent qu’une fonction Derive() modélisable comme oracle aléatoire fournisse les propriétés nécessaires; ils écrivent que cette transposition n’a pas été vérifiée formellement. La section 9.3 précise le test intellectuel: la sortie du calendrier doit rester pseudoaléatoire si le secret partagé ou la clé prépartagée échappe à l’adversaire, même lorsque les autres entrées sont connues ou choisies. SHAKE est donné comme exemple de fonction extensible répondant au modèle.

Les noms communs circulent déjà. Le registre IANA de HPKE contient quatre identifiants pour SHAKE et TurboSHAKE, 0x0010 à 0x0013, avec renvoi au projet HPKE post-quantique. Celui-ci demeure un projet actif de groupe de travail. La révision 06 demande l’ajout d’une colonne Two-Stage et la valeur N pour ces quatre entrées; au 3 novembre, la page publique montre encore l’ancien tableau. Le registre nomme des options. Le texte approuvé décrit leur cadre. L’analyse de sécurité possède son propre état.

Un détail de mise en œuvre empêche aussi de réduire les deux chemins à une étiquette unique: pour la voie en une étape, psk, psk_id et info ont chacun une limite de 65 535 octets liée à leur préfixe de longueur; la sortie exportée a une limite distincte de même valeur. Ces bornes peuvent se tester directement. La preuve formelle nécessite un autre document ou une autre analyse.