1. Introduction
De nombreux protocoles cryptographiques nécessitent une procédure qui encode une entrée arbitraire, par exemple un mot de passe, vers un point sur une courbe elliptique. Cette procédure est connue sous le nom de hachage vers une courbe elliptique, où la procédure de hachage offre une résistance aux collisions et ne révèle pas le logarithme discret du point de sortie. Des exemples marquants de cryptosystèmes qui hachent vers des courbes elliptiques incluent les échanges de clés authentifiés par mot de passe [BM92] [J96] [BMP00] [p1363.2], l'Identity-Based Encryption [BF01], les signatures Boneh-Lynn-Shacham [BLS01] [BLS-SIG], les fonctions aléatoires vérifiables (VRF) [MRV99] [VRF], et les fonctions pseudo-aléatoires oblitérantes (OPRF) [NR97] [OPRFs].
Malheureusement pour les implémenteurs, la fonction de hachage précise qui convient à un protocole donné implémenté à l'aide d'une courbe elliptique donnée n'est souvent pas claire à partir de la description du protocole. Parallèlement, un choix incorrect de fonction de hachage peut avoir des conséquences désastreuses pour la sécurité.
Ce 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 sur une courbe elliptique. Nous fournissons des détails d'implémentation pour chaque algorithme, décrivons le raisonnement de sécurité derrière chaque recommandation, et donnons des conseils pour les courbes elliptiques qui ne sont pas explicitement couvertes. Nous présentons également des implémentations optimisées pour les fonctions internes utilisées par ces algorithmes.
Les lecteurs souhaitant spécifier ou implémenter rapidement une fonction de hachage conforme doivent consulter la section 8, qui répertorie les suites recommandées de hachage vers courbe et décrit à la fois comment implémenter une suite existante et comment en spécifier une nouvelle.
Ce document ne spécifie pas de méthodes d'échantillonnage de rejet probabilistes, parfois appelées « try-and-increment » ou « hunt-and-peck », car l'objectif est de spécifier des algorithmes qui peuvent plausiblement être calculés en temps constant. L'utilisation de ces méthodes de rejet probabilistes n'est PAS RECOMMANDÉE, car elles ont été une cause pérenne de vulnérabilités par canaux auxiliaires. Voir Dragonblood [VR20] comme un exemple de ce problème en pratique, et voir l'Annexe A pour une description informelle des méthodes d'échantillonnage de rejet et des canaux auxiliaires de synchronisation qu'elles introduisent.
Ce document représente le consensus du Crypto Forum Research Group (CFRG).
1.1. Notation des exigences
Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", et "OPTIONAL" dans ce document sont à interpréter comme décrit dans le BCP 14 [RFC2119] [RFC8174] quand, et seulement quand, ils apparaissent en majuscules, comme indiqué ici.