3. Codifica di stringhe di byte in curve ellittiche

Questa sezione presenta un quadro generale e un'interfaccia per la codifica di stringhe di byte in punti su una curva ellittica. Le costruzioni in questa sezione si basano su tre funzioni di base:

• La funzione hash_to_field esegue l'hashing di stringhe di byte di lunghezza arbitraria in un elenco di uno o più elementi di un campo finito F; la sua implementazione è definita nella Sezione 5.

  hash_to_field(msg, count)

  Input:

  • msg, una stringa di byte contenente il messaggio da sottoporre ad hashing.
  • count, il numero di elementi di F da produrre.

  Output:

  • (u_0, ..., u_(count - 1)), un elenco di elementi del campo.

• La funzione map_to_curve calcola un punto sulla curva ellittica E a partire da un elemento del campo finito F su cui E è definita. La Sezione 6 descrive le mappature per una gamma di famiglie di curve.

  map_to_curve(u)

  Input: u, un elemento del campo F. Output: Q, un punto sulla curva ellittica E.

• La funzione clear_cofactor mappa qualsiasi punto sulla curva E nel sottogruppo G di E. La Sezione 7 descrive i metodi per eseguire questa operazione.

  clear_cofactor(Q)

  Input: Q, un punto sulla curva ellittica E. Output: P, un punto in G.

Le due codifiche (Sezione 2.2.2) definite in questa sezione hanno la stessa interfaccia e sono entrambe codifiche random oracle (Sezione 2.2.3). Entrambe sono implementate come una composizione delle tre funzioni di base sopra indicate. La differenza tra le due è che i loro output sono campionati da distribuzioni diverse:

• encode_to_curve è una codifica non uniforme di stringhe di byte in punti in G. In altre parole, la distribuzione del suo output non è uniformemente casuale in G: l'insieme dei possibili output di encode_to_curve è solo una frazione dei punti in G e alcuni punti in questo insieme hanno maggiori probabilità di essere prodotti rispetto ad altri. La Sezione 10.4 fornisce una definizione più precisa della distribuzione dell'output di encode_to_curve.

  encode_to_curve(msg)

  Input: msg, una stringa di byte di lunghezza arbitraria. Output: P, un punto in G.

  Passaggi:

  1. u = hash_to_field(msg, 1)
  2. Q = map_to_curve(u[0])
  3. P = clear_cofactor(Q)
  4. ritorna P

• hash_to_curve è una codifica uniforme di stringhe di byte in punti in G. In altre parole, la distribuzione del suo output è statisticamente vicina all'uniformità in G.

  Questa funzione è adatta per la maggior parte delle applicazioni che richiedono un random oracle che restituisca punti in G, se istanziata con una delle funzioni map_to_curve descritte nella Sezione 6. Vedere la Sezione 10.1 per ulteriori dettagli.

  hash_to_curve(msg)

  Input: msg, una stringa di byte di lunghezza arbitraria. Output: P, un punto in G.

  Passaggi:

  1. u = hash_to_field(msg, 2)
  2. Q0 = map_to_curve(u[0])
  3. Q1 = map_to_curve(u[1])
  4. R = Q0 + Q1 # Addizione di punti
  5. P = clear_cofactor(R)
  6. ritorna P

Ogni suite di hashing su curva nella Sezione 8 istanzia una di queste funzioni di codifica per una specifica curva ellittica.

3.1. Requisiti di separazione di dominio

Tutti gli utilizzi delle funzioni di codifica definite in questo documento DEVONO includere la separazione di dominio (Sezione 2.2.5) per evitare di interferire con altri utilizzi di funzionalità simili.

Le applicazioni che istanziano più istanze indipendenti di hash_to_curve o encode_to_curve DEVONO applicare la separazione di dominio tra tali istanze. Questo requisito si applica sia nel caso di più istanze che mirano alla stessa curva, sia nel caso di più istanze che mirano a curve diverse. (In effetti, la primitiva interna hash_to_field (Sezione 5) richiede la separazione di dominio per garantire output indipendenti).

La separazione di dominio viene applicata utilizzando un tag di separazione di dominio (DST), che è una stringa di byte costruita secondo i seguenti requisiti:

1. I tag DEVONO essere forniti come parametro DST a hash_to_field, come descritto nella Sezione 5.

2. I tag DEVONO avere una lunghezza diversa da zero. Una lunghezza minima di 16 byte è RACCOMANDATA per ridurre il rischio di collisioni con altre applicazioni.

3. I tag DOVREBBERO iniziare con una stringa di identificazione fissa che sia univoca per l'applicazione.

4. I tag DOVREBBERO includere un numero di versione.

5. Per le applicazioni che definiscono più suite crittografiche, il tag di ogni suite DEVE essere diverso. A tal fine, si RACCOMANDA di includere un identificatore della suite crittografica in ogni tag.

6. Per le applicazioni che utilizzano più codifiche, verso la stessa curva o verso curve diverse, ogni codifica DEVE utilizzare un tag diverso. A tal fine, si RACCOMANDA di includere l'ID della suite della codifica (Sezione 8) nel tag di separazione di dominio. Per le codifiche indipendenti basate sulla stessa suite, ogni tag DOVREBBE includere anche un identificatore distinto, ad esempio "ENC1" e "ENC2".

Ad esempio, si consideri un'applicazione fittizia denominata Quux che definisce diverse suite crittografiche differenti, ciascuna per una curva diversa. Una scelta ragionevole del tag è "QUUX-V-CS-", dove e sono numeri a due cifre che indicano rispettivamente la versione e la suite crittografica, e è l'ID della suite della codifica utilizzata nella suite .

Come altro esempio, si consideri un'applicazione fittizia denominata Baz che richiede due random oracle indipendenti verso la stessa curva. Scelte ragionevoli di tag per questi oracle sono rispettivamente "BAZ-V-CS--ENC1" e "BAZ-V-CS--ENC2", dove , e sono come descritto sopra.

Si presume che gli esempi di tag forniti sopra siano stringhe di byte codificate in ASCII senza terminazione nulla, che è il formato RACCOMANDATO. Possono essere utilizzate altre codifiche, ma in tutti i casi la codifica come sequenza di byte DEVE essere specificata in modo univoco.