1. Introduzione
Molti protocolli crittografici richiedono una procedura che codifichi un input arbitrario, ad esempio una password, in un punto di una curva ellittica. Tale procedura è nota come hashing su una curva ellittica, in cui la procedura di hashing fornisce resistenza alle collisioni e non rivela il logaritmo discreto del punto prodotto. Esempi di rilievo di crittosistemi che effettuano l'hashing su curve ellittiche includono gli scambi di chiavi autenticati con password (password-authenticated key exchanges) [BM92] [J96] [BMP00] [p1363.2], la crittografia basata sull'identità (Identity-Based Encryption) [BF01], le firme Boneh-Lynn-Shacham [BLS01] [BLS-SIG], le funzioni casuali verificabili (Verifiable Random Functions) [MRV99] [VRF] e le funzioni pseudo-casuali oblivious (Oblivious Pseudorandom Functions) [NR97] [OPRFs].
Purtroppo, per gli implementatori, la funzione di hash esatta adatta a un dato protocollo realizzato tramite una data curva ellittica è spesso poco chiara dalla descrizione del protocollo. Nel frattempo, una scelta errata della funzione di hash può avere conseguenze disastrose per la sicurezza.
Il presente documento mira a colmare questa lacuna fornendo un insieme completo di algoritmi raccomandati per un'ampia gamma di tipi di curve. Ciascun algoritmo è conforme a un'interfaccia comune: prende in input una stringa di byte di lunghezza arbitraria e produce in output un punto su una curva ellittica. Forniamo i dettagli di implementazione di ciascun algoritmo, descriviamo la motivazione di sicurezza alla base di ciascuna raccomandazione e forniamo indicazioni per le curve ellittiche non esplicitamente trattate. Presentiamo inoltre implementazioni ottimizzate delle funzioni interne utilizzate da tali algoritmi.
I lettori che desiderano specificare o implementare rapidamente una funzione di hash conforme dovrebbero consultare la Sezione 8, che elenca le suite di hash-to-curve raccomandate e descrive sia come implementare una suite esistente sia come specificarne una nuova.
Il presente documento non specifica metodi di campionamento per rifiuto probabilistici, a volte denominati "try-and-increment" o "hunt-and-peck", poiché l'obiettivo è specificare algoritmi che possano ragionevolmente essere calcolati in tempo costante. L'uso di questi metodi di rifiuto probabilistici NON È RACCOMANDATO, poiché sono stati una causa ricorrente di vulnerabilità da canali laterali. Si veda Dragonblood [VR20] come esempio concreto di questo problema, e l'Appendice A per una descrizione informale dei metodi di campionamento per rifiuto e dei canali laterali temporali che essi introducono.
Il presente documento rappresenta il consenso del Crypto Forum Research Group (CFRG).
1.1. Notazione dei requisiti
Le parole chiave "MUST" (DEVE), "MUST NOT" (NON DEVE), "REQUIRED" (RICHIESTO), "SHALL" (DOVRÀ), "SHALL NOT" (NON DOVRÀ), "SHOULD" (DOVREBBE), "SHOULD NOT" (NON DOVREBBE), "RECOMMENDED" (RACCOMANDATO), "NOT RECOMMENDED" (NON RACCOMANDATO), "MAY" (PUÒ) e "OPTIONAL" (OPZIONALE) contenute nel presente documento devono essere interpretate come descritto nel BCP 14 [RFC2119] [RFC8174] solo ed esclusivamente quando compaiono in lettere maiuscole, come qui mostrato.