3. バイト文字列の楕円曲線へのエンコード

この節では、バイト文字列を楕円曲線上の点にエンコードするための一般的なフレームワークとインターフェースを提示します。この節の構成は、3つの基本関数に依存しています。

関数 hash_to_field は、任意位のバイト文字列を有限体 F の1つ以上の要素のリストにハッシュします。その実装は第5節で定義されています。

hash_to_field(msg, count)

Input:
- msg, a byte string containing the message to hash.
- count, the number of elements of F to output.

Output:
- (u_0, ..., u_(count - 1)), a list of field elements.

Steps: defined in Section 5.

関数 map_to_curve は、Eが定義されている有限体 F の要素から楕円曲線 E 上の点を計算します。第6節では、一連の曲線ファミリーに対するマッピングについて説明します。
```
map_to_curve(u)

Input: u, an element of field F.
Output: Q, a point on the elliptic curve E.
Steps: defined in Section 6.
```
関数 clear_cofactor は、曲線 E 上の任意の点を E の部分群 G に送ります。第7節では、この操作を実行する方法について説明します。
```
clear_cofactor(Q)

Input: Q, a point on the elliptic curve E.
Output: P, a point in G.
Steps: defined in Section 7.
```

この節で定義される2つのエンコーディング（第2.2.2節）は同じインターフェースを持ち、どちらもランダムオラクルエンコーディング（第2.2.3節）です。両方とも、上記の3つの基本関数の組み合わせとして実装されます。2つの違いは、それらの出力が異なる分布からサンプリングされる点です。

encode_to_curve は、バイト文字列から G 内の点への非一様エンコーディングです。つまり、その出力の分布は G 内で一様ランダムではありません。encode_to_curve の可能な出力の集合は G 内の点の一部にすぎず、その集合内の一部の点は他の点よりも出力される可能性が高くなります。第10.4節では、encode_to_curve の出力分布についてより正確な定義を与えています。
```
encode_to_curve(msg)

Input: msg, an arbitrary-length byte string.
Output: P, a point in G.

Steps:
1. u = hash_to_field(msg, 1)
2. Q = map_to_curve(u[0])
3. P = clear_cofactor(Q)
4. return P
```
hash_to_curve は、バイト文字列から G 内の点への一様エンコーディングです。つまり、その出力の分布は統計的に G 内の一様分布に近いです。

この関数は、第6節で説明されている map_to_curve 関数のいずれかを使用してインスタンス化された場合、G 内の点を返すランダムオラクルを必要とするほとんどのアプリケーションに適しています。詳細については、第10.1節を参照してください。
```
hash_to_curve(msg)

Input: msg, an arbitrary-length byte string.
Output: P, a point in G.

Steps:
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              # Point addition
5. P = clear_cofactor(R)
6. return P
```

第8節の各 hash-to-curve スイートは、特定の楕円曲線に対してこれらのエンコード関数のいずれかをインスタンス化します。

3.1. ドメイン分離要件

この文書で定義されているエンコード関数のすべての使用は、同様の機能の他の使用との干渉を避けるために、ドメイン分離（第2.2.5節）を含まなければなりません（MUST）。

hash_to_curve または encode_to_curve の複数の独立したインスタンスをインスタンス化するアプリケーションは、それらのインスタンス間でドメイン分離を強制しなければなりません（MUST）。この要件は、同じ曲線をターゲットとする複数のインスタンスの場合と、異なる曲線をターゲットとする複数のインスタンスの両方に適用されます。（これは、内部の hash_to_field プリミティブ（第5节）が独立した出力を保証するためにドメイン分離を必要とするためです。）

ドメイン分離は、以下の要件に従って構築されたバイト文字列であるドメイン分離タグ (DST) によって強制されます。

タグは、第5節で説明するように、hash_to_field への DST パラメータとして提供されなければなりません（MUST）。
タグはゼロではない長さを持たなければなりません（MUST）。他のアプリケーションとの衝突の可能性を減らすために、少なくとも 16 バイトの長さを推奨します（RECOMMENDED）。
タグは、アプリケーションに固有の固定の識別文字列で始まるべきです（SHOULD）。
タグはバージョン番号を含むべきです（SHOULD）。
複数の暗号スイートを定義するアプリケーションの場合、各暗号スイートのタグは異なっていなければなりません（MUST）。この目的のために、各タグに暗号スイート識別子を含めることを推奨します（RECOMMENDED）。
同じ曲線または異なる曲線に対して複数のエンコーディングを使用するアプリケーションの場合、各エンコーディングは異なるタグを使用しなければなりません（MUST）。この目的のために、ドメイン分離タグにエンコーディングのスイート ID（第8節）を含めることを推奨します（RECOMMENDED）。同じスイートに基づく独立したエンコーディングの場合、各タグには "ENC1" や "ENC2" などの個別の識別子も含めるべきです（SHOULD）。

例として、異なる曲線ごとにいくつかの異なる暗号スイートを定義する Quux という架空のアプリケーションを考えます。タグの合理的な選択は "QUUX-V-CS-" です。ここで、とはバージョンと暗号スイートを示す2桁の数字であり、は暗号スイートで使用されるエンコーディングのスイート ID です。

別の例として、同じ曲線に対して2つの独立したランダムオラクルを必要とする Baz という架空のアプリケーションを考えます。これらのオラクルに対する合理的なタグの選択は、それぞれ "BAZ-V-CS--ENC1" および "BAZ-V-CS--ENC2" です。ここで、、、およびは上記のとおりです。

上記の例のタグは、ヌル終端のない ASCII エンコードされたバイト文字列であると想定されており、これが推奨される（RECOMMENDED）形式です。他のエンコーディングを使用することもできますが、すべての場合において、バイト列としてのエンコーディングを一意に指定しなければなりません（MUST）。

3.1. ドメイン分離要件​

3.1. ドメイン分離要件