Résumé

  • Le CFRG a publié le 7 septembre 2026 la révision 14 de draft-irtf-cfrg-pairing-friendly-curves. Il s’agit d’un Internet-Draft actif d’un groupe de recherche de l’IRTF, destiné à une publication de type Information, et non d’un RFC ni d’une norme de l’IETF.
  • Le texte fixe des procédures normatives de sérialisation et de désérialisation des points pour BLS12-381 et BLS48-581, ainsi que des scalaires pour ces deux courbes et BN462. Le décodeur vérifie notamment la représentation canonique, l’appartenance à la courbe et au sous-groupe.
  • Trois décisions demeurent du ressort du protocole appelant : accepter les points compressés, non compressés ou les deux ; admettre ou refuser l’élément neutre ; admettre ou refuser le scalaire zéro.
  • Par rapport à la révision 13, le nouveau texte retire la recommandation générale de refuser l’identité et dissocie le traitement du zéro de celui de l’identité. Il ne définit toujours pas d’encodage normatif des points BN462, faute de convergence des pratiques observées.
  • Daniel Kade propose un profil d’acceptation à sept champs pour rendre ces choix comparables. Cette proposition relève de l’analyse éditoriale, pas du projet du CFRG.

La validité mathématique n’épuise pas le contrat

Dans les textes cryptographiques, le mot « validation » recouvre souvent deux opérations. La première demande si une suite d’octets représente sans ambiguïté un élément du bon corps, un point de la courbe voulue et un membre du sous-groupe prévu. La seconde demande si le protocole admet cet élément à cet endroit de son échange.

La révision 14 rend la première opération beaucoup plus précise. Ses procédures de désérialisation renvoient soit un élément de groupe, soit INVALID. Elles contrôlent la longueur et les bits de métadonnées, rejettent une coordonnée supérieure ou égale au module au lieu de la réduire, reconstruisent le point, vérifient la courbe et effectuent le contrôle de sous-groupe. Des types de points de même longueur ne deviennent pas pour autant interchangeables.

Pour les scalaires, l’entier encodé doit être strictement inférieur à l’ordre du corps scalaire. Zéro possède donc une représentation canonique. Cela ne signifie pas que zéro soit acceptable dans toute construction. La règle mathématique indique ce que les octets désignent ; le protocole indique si cette valeur a un sens autorisé.

Deux implémentations peuvent ainsi employer correctement la même routine commune et diverger ensuite. La frontière d’interopérabilité ne se trouve pas seulement dans le décodeur. Elle se trouve dans la politique appliquée à sa sortie.

Trois commutateurs, et non une seule règle « non nulle »

Le premier choix porte sur la forme du point. Le protocole appelant doit préciser s’il reçoit uniquement la forme compressée, uniquement la forme non compressée ou les deux. Accepter les deux autorise deux suites d’octets pour le même point. La différence devient substantielle dès que l’application hache les octets reçus, les signe, les compare tels quels ou les utilise comme clé de stockage.

Le deuxième choix concerne l’élément neutre. Certaines constructions ont une raison propre de le refuser. Dans le projet sur les signatures BLS, la validation d’une clé exclut l’identité, notamment en lien avec la clé secrète zéro invalide et le cas d’une signature identité. Dans un autre calcul, l’identité peut avoir une fonction légitime. La révision 14 renvoie donc la décision à la sémantique et au modèle de menace de la construction.

Le troisième choix concerne le scalaire zéro. Il est autonome. La révision 13 présentait le refus de l’identité comme option recommandée par défaut et rapprochait la politique du zéro de celle de l’identité. La révision 14 abandonne ce défaut universel et sépare les deux questions. RFC 9591 montre concrètement pourquoi : sa désérialisation des éléments rejette l’identité, tandis que sa désérialisation des scalaires n’ajoute pas une interdiction analogue du zéro.

Un protocole peut donc imposer la compression, refuser l’identité et accepter zéro dans un champ donné. Un autre peut accepter les deux formes, utiliser l’identité dans une opération et interdire zéro. Une bibliothèque générique ne peut pas déduire ces décisions de l’équation de la courbe.

BN462 indique où s’arrête la couche commune

Le projet définit le format des points BLS12-381 et BLS48-581, mais pas celui des points BN462. Le module de base de BN462 occupe 462 bits. Dans 58 octets, il ne reste que deux bits libres, alors que la disposition compressée commune doit porter trois indications.

L’annexe informative recense des solutions incompatibles dans des logiciels existants : octet de type inspiré de SEC1, octet de drapeaux distinct, ou représentation compacte sans la même convention de métadonnées. Les auteurs indiquent que les spécifications examinées n’exigent pas d’encodage de point BN462 et que la pratique n’a pas convergé. Ils choisissent donc de ne pas créer artificiellement une norme commune.

Ce constat ne prouve ni l’absence d’implémentations BN462, ni la faiblesse cryptographique d’un format, ni la nécessité de modifier tous les systèmes existants. Il impose une obligation plus limitée : tout protocole qui transporte des points BN462 doit nommer une référence d’encodage externe ou définir explicitement sa convention.

Une décision locale ne doit pas rester invisible

Le dossier de développement explique cette architecture. L’issue 74 du dépôt CFRG demandait une définition faisant autorité, plutôt que plusieurs copies susceptibles de diverger. La pull request 108 a apporté à la révision 14 les procédures nommées, les contrôles d’appartenance, les choix laissés au protocole et des travaux sur les vecteurs de test. Les échanges sur la liste CFRG ont prévenu les auteurs de documents dépendants. Les projets BBS et COSE sur les clés BLS montrent que cette dépendance est déjà concrète.

Une couche commune minimale peut éliminer la divergence mathématique sans gouverner la sémantique de chaque application. Mais la liberté locale n’est saine que si elle est déclarée. Une option cachée dans les valeurs par défaut d’une bibliothèque ressemble, vue depuis le réseau, à une bifurcation non documentée.

Je propose donc que chaque spécification appelante publie un profil d’acceptation comprenant : la révision exacte du document de courbes, la courbe choisie, les formes de point reçues, la règle sur l’identité, la règle sur le scalaire zéro, la voie de contrôle du sous-groupe et, pour BN462, la référence externe d’encodage. Le nom et les sept champs de ce profil sont ma proposition ; le CFRG ne les impose pas.

Sources