Résumé

  • Les identifiants ajoutés par RFC 9858 indiquent au vérificateur comment lire une signature HSS/LMS ; ils ne racontent pas l’histoire de l’état privé qui l’a produite.
  • Une signature peut être valide alors qu’une copie restaurée ou un second processus réutilise le même indice de feuille.
  • La preuve opérationnelle repose sur l’avancement durable avant sortie, l’unicité du propriétaire, une reprise sans duplication et un passage anticipé à la clé suivante.

Le registre règle la grammaire, pas la garde

RFC 9858, publié en octobre 2025 par le Crypto Forum Research Group de l’IRTF, ajoute des jeux HSS/LMS fondés sur SHA-256 avec une sortie de 192 bits et sur SHAKE256 avec des sorties de 192 ou 256 bits. Les codes LM-OTS et LMS correspondants sont enregistrés par l’IANA. Deux logiciels qui reconnaissent ces codes savent donc quelle fonction, quelle longueur de sortie et quels paramètres appliquer.

Cette précision est essentielle à l’interopérabilité. Elle ne constitue pourtant pas un journal de garde.

Dans LMS, chaque signature consomme une feuille numérotée q. La clé privée avance dans un arbre de Merkle fini ; le secret à usage unique associé à une feuille ne doit jamais resservir. RFC 8554 avertit qu’une réutilisation de l’état privé peut anéantir les garanties du schéma. Or le vérificateur ne voit qu’un message, une signature, une clé publique et un chemin d’authentification. Il peut recalculer la racine et répondre « valide ». Il ne peut pas savoir si une autre machine a déjà signé avec le même q, ni si une sauvegarde ancienne le fera demain.

Il faut donc séparer deux plans de preuve. Le plan des paramètres décrit la famille de hachage, la longueur, la hauteur d’arbre et le réglage de Winternitz. Le plan de garde établit qui détenait l’état mutable, à quel instant l’indice a été réservé puis rendu durable, et quelles copies pouvaient encore signer. RFC 9858 élargit le premier plan sans certifier le second.

Les variantes à 192 bits offrent un compromis concret : des objets plus petits que leurs équivalents à sortie de 256 bits, contre une marge de sécurité moindre. SHAKE256 peut aussi mieux convenir à certaines plates-formes. Mais une fiche d’achat mentionnant seulement « compatible RFC 9858 » ne dit ni quel jeu a été retenu, ni pourquoi il correspond à la durée d’usage, ni comment le compteur survit à une coupure.

NIST SP 800-208 formule justement cette discipline. Dans le cadre de génération conforme en module matériel, le matériau privé n’est pas exportable. Surtout, l’indice doit être incrémenté et inscrit en mémoire non volatile avant que la signature soit livrée ou qu’une autre requête soit acceptée. L’ordre est une propriété de sécurité. Un write confirmé dans un cache ne garantit pas la survie à une panne électrique. Une image de sauvegarde n’est pas une reprise sûre si deux exemplaires peuvent devenir actifs.

La reprise doit donc être conçue sans remonter le temps. On peut attribuer des arbres indépendants sous une hiérarchie HSS, isoler des plages, ou préparer une nouvelle clé dont la clé publique est distribuée à l’avance. Restaurer simplement un état privé ancien transfère au hasard une responsabilité que le vérificateur ne peut assumer.

Enfin, la hauteur de l’arbre impose un budget fini. Les échecs, les réservations prudentes et le parallélisme peuvent consommer des feuilles sans produire autant de signatures visibles. L’organisation a besoin d’un niveau haut fiable, d’une mesure de capacité restante et d’un seuil de bascule. Une fois deux signatures sorties du même secret à usage unique, aucune régularisation ultérieure n’efface l’exposition.

Sources