1. Introduzione

Molti protocolli crittografici richiedono una procedura che codifica un input arbitrario, ad esempio una password, in un punto su una curva ellittica. Questa procedura è conosciuta come hashing su una curva ellittica, dove la procedura di hashing offre resistenza alle collisioni e non rivela il logaritmo discreto del punto di output. Esempi prominenti di crittosistemi che operano hashing su curve ellittiche includono gli scambi di chiavi autenticati tramite password [BM92] [J96] [BMP00] [p1363.2], Identity-Based Encryption [BF01], le firme Boneh-Lynn-Shacham [BLS01] [BLS-SIG], le funzioni casuali verificabili (VRF) [MRV99] [VRF], e le funzioni pseudocasuali oblioviose (OPRF) [NR97] [OPRFs].

Sfortunatamente per gli implementatori, la funzione di hash precisa adatta a un dato protocollo implementato utilizzando una data curva ellittica spesso non è chiara dalla descrizione del protocollo. Parallelamente, una scelta errata della funzione di hash può avere conseguenze disastrose per la sicurezza.

Questo documento mira a colmare questa lacuna fornendo un insieme completo di algoritmi raccomandati per una gamma di tipi di curve. Ogni algoritmo è conforme a un'interfaccia comune: accetta come input una stringa di byte di lunghezza arbitraria e produce come output un punto su una curva ellittica. Forniamo dettagli di implementazione per ogni algoritmo, descriviamo il ragionamento di sicurezza dietro ogni raccomandazione e diamo consigli per le curve ellittiche non esplicitamente coperte. Presentiamo anche implementazioni ottimizzate per le funzioni interne utilizzate da questi algoritmi.

I lettori che desiderano specificare o implementare rapidamente una funzione di hash conforme devono consultare la Sezione 8, che elenca le suite raccomandate di hash-to-curve e descrive sia come implementare una suite esistente che come specificarne una nuova.

Questo documento non specifica metodi di campionamento a rifiuto probabilistici, a volte chiamati "try-and-increment" o "hunt-and-peck", perché l'obiettivo è specificare algoritmi che possano plausibilmente essere calcolati in tempo costante. L'uso di questi metodi di rifiuto probabilistici NON è RACCOMANDATO, poiché sono stati una causa perenne di vulnerabilità da canale laterale. Vedere Dragonblood [VR20] come esempio di questo problema in pratica, e vedere l'Appendice A per una descrizione informale dei metodi di campionamento a rifiuto e dei canali laterali temporali che introducono.

Questo documento rappresenta il consenso del Crypto Forum Research Group (CFRG).

1.1. Notazione dei requisiti

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto nel BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in maiuscolo, come mostrato qui.