1. Einführung

Viele kryptografische Protokolle erfordern ein Verfahren, das eine beliebige Eingabe, zum Beispiel ein Passwort, auf einen Punkt auf einer elliptischen Kurve abbildet. Dieses Verfahren ist als Hashing auf eine elliptische Kurve bekannt, wobei das Hashing-Verfahren Kollisionsresistenz bietet und den diskreten Logarithmus des Ausgabepunkts nicht preisgibt. Prominente Beispiele für Kryptosysteme, die auf elliptische Kurven hashen, sind passwortgeschützte Schlüsselaustauschprotokolle [BM92] [J96] [BMP00] [p1363.2], Identity-Based Encryption [BF01], Boneh-Lynn-Shacham-Signaturen [BLS01] [BLS-SIG], Verifiable Random Functions (VRF) [MRV99] [VRF] und Oblivious Pseudorandom Functions (OPRF) [NR97] [OPRFs].

Leider ist für Implementierer oft nicht klar, welche präzise Hash-Funktion für ein gegebenes Protokoll, das mit einer bestimmten elliptischen Kurve implementiert wird, geeignet ist. Gleichzeitig kann eine falsche Wahl der Hash-Funktion fatale Folgen für die Sicherheit haben.

Dieses Dokument soll diese Lücke schließen, indem es einen umfassenden Satz empfohlener Algorithmen für eine Reihe von Kurventypen bereitstellt. Jeder Algorithmus entspricht einer gemeinsamen Schnittstelle: Er nimmt einen Byte-String beliebiger Länge als Eingabe und gibt einen Punkt auf einer elliptischen Kurve aus. Wir liefern Implementierungsdetails für jeden Algorithmus, beschreiben die Sicherheitsüberlegungen hinter jeder Empfehlung und geben Ratschläge für elliptische Kurven, die nicht explizit abgedeckt sind. Wir stellen auch optimierte Implementierungen für die von diesen Algorithmen verwendeten internen Funktionen vor.

Leser, die schnell eine konforme Hash-Funktion spezifizieren oder implementieren möchten, sollten Abschnitt 8 konsultieren. Dort sind die empfohlenen Hash-to-Curve-Suites aufgeführt und es wird beschrieben, wie eine bestehende Suite implementiert oder eine neue spezifiziert wird.

Dieses Dokument spezifiziert keine probabilistischen Rejection-Sampling-Methoden, die manchmal als „try-and-increment“ oder „hunt-and-peck“ bezeichnet werden, da das Ziel darin besteht, Algorithmen zu spezifizieren, die plausibel in konstanter Zeit berechnet werden können. Die Verwendung dieser probabilistischen Rejection-Methoden wird NICHT EMPFOHLEN, da sie eine dauerhafte Ursache für Seitenkanal-Schwachstellen waren. Siehe Dragonblood [VR20] als Beispiel für dieses Problem in der Praxis und Anhang A für eine informelle Beschreibung von Rejection-Sampling-Methoden und den damit verbundenen Timing-Seitenkanälen.

Dieses Dokument repräsentiert den Konsens der Crypto Forum Research Group (CFRG).

1.1. Anforderungsnotation

Die Schlüsselwörter „MUST“, „MUST NOT“, „REQUIRED“, „SHALL“, „SHALL NOT“, „SHOULD“, „SHOULD NOT“, „RECOMMENDED“, „NOT RECOMMENDED“, „MAY“ und „OPTIONAL“ in diesem Dokument sind so zu interpretieren, wie in BCP 14 [RFC2119] [RFC8174] beschrieben, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.