1. Introduction
De nombreux protocoles cryptographiques nécessitent une procédure permettant d'encoder une entrée arbitraire, par exemple un mot de passe, en un point d'une courbe elliptique. Cette procédure est connue sous le nom de « hachage vers une courbe elliptique » (hashing to an elliptic curve) ; la procédure de hachage doit offrir une résistance aux collisions et ne doit pas révéler le logarithme discret du point produit. Parmi les exemples marquants de cryptosystèmes qui hachent vers des courbes elliptiques figurent les échanges de clés authentifiés par mot de passe (password-authenticated key exchanges) [BM92] [J96] [BMP00] [p1363.2], le chiffrement basé sur l'identité (Identity-Based Encryption) [BF01], les signatures Boneh-Lynn-Shacham [BLS01] [BLS-SIG], les fonctions aléatoires vérifiables (Verifiable Random Functions) [MRV99] [VRF], ainsi que les fonctions pseudo-aléatoires oublieuses (Oblivious Pseudorandom Functions) [NR97] [OPRFs].
Malheureusement pour les implémenteurs, la description d'un protocole ne permet souvent pas de déterminer clairement quelle fonction de hachage convient précisément à ce protocole lorsqu'il est mis en œuvre à l'aide d'une courbe elliptique donnée. Or, un choix incorrect de fonction de hachage peut avoir des conséquences désastreuses pour la sécurité.
Le présent document vise à combler cette lacune en fournissant un ensemble complet d'algorithmes recommandés pour une gamme de types de courbes. Chaque algorithme est conforme à une interface commune : il prend en entrée une chaîne d'octets de longueur arbitraire et produit en sortie un point d'une courbe elliptique. Nous donnons les détails d'implémentation de chaque algorithme, exposons le raisonnement de sécurité qui sous-tend chaque recommandation et fournissons des orientations pour les courbes elliptiques qui ne sont pas explicitement traitées. Nous présentons également des implémentations optimisées des fonctions internes utilisées par ces algorithmes.
Les lecteurs souhaitant spécifier ou implémenter rapidement une fonction de hachage conforme se reporteront à la section 8, qui énumère les suites de hachage vers courbe (hash-to-curve suites) recommandées et décrit à la fois comment implémenter une suite existante et comment en spécifier une nouvelle.
Le présent document ne spécifie pas de méthodes d'échantillonnage par rejet probabiliste (probabilistic rejection sampling methods), parfois appelées « try-and-increment » ou « hunt-and-peck », car notre objectif est de spécifier des algorithmes dont on puisse raisonnablement attendre qu'ils soient calculés en temps constant. L'utilisation de ces méthodes de rejet probabilistes n'est PAS RECOMMANDÉE (NOT RECOMMENDED), car elles ont constitué une cause récurrente de vulnérabilités par canaux auxiliaires. Voir Dragonblood [VR20] pour un exemple concret de ce problème, et l'annexe A pour une description informelle des méthodes d'échantillonnage par rejet et des canaux auxiliaires temporels qu'elles introduisent.
Le présent document représente le consensus du Crypto Forum Research Group (CFRG).
1.1. Terminologie relative aux exigences (Requirements Notation)
Les mots-clés « MUST », « MUST NOT », « REQUIRED », « SHALL », « SHALL NOT », « SHOULD », « SHOULD NOT », « RECOMMENDED », « NOT RECOMMENDED », « MAY » et « OPTIONAL » figurant dans le présent document doivent être interprétés comme décrit dans le BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme ici.