メインコンテンツまでスキップ

3. バイト列の楕円曲線への符号化 (Encoding Byte Strings to Elliptic Curves)

本節では、バイト列を楕円曲線上の点へ符号化するための一般的な枠組みとインタフェースを提示します。本節の構成は、3 つの基本関数に依拠しています。

  • 関数 hash_to_field は、任意長のバイト列を、有限体 F の 1 個以上の元からなるリストへとハッシュします。その実装は第 5 節で定義されます。
hash_to_field(msg, count)

入力 (Input):
- msg, ハッシュ対象のメッセージを含むバイト列。
- count, 出力する F の元の個数。

出力 (Output):
- (u_0, ..., u_(count - 1)), 体の元のリスト。

手順 (Steps): 第 5 節で定義される。
  • 関数 map_to_curve は、E が定義される有限体 F の元から、楕円曲線 E 上の点を計算します。第 6 節では、さまざまな曲線族に対する写像を記述します。
map_to_curve(u)

入力 (Input): u, 体 F の元。
出力 (Output): Q, 楕円曲線 E 上の点。
手順 (Steps): 第 6 節で定義される。
  • 関数 clear_cofactor は、曲線 E 上の任意の点を E の部分群 G へ送ります。第 7 節では、この演算を実行する方法を記述します。
clear_cofactor(Q)

入力 (Input): Q, 楕円曲線 E 上の点。
出力 (Output): P, G 内の点。
手順 (Steps): 第 7 節で定義される。

本節で定義される 2 つの符号化（第 2.2.2 節）は同一のインタフェースを持ち、どちらもランダムオラクル符号化（第 2.2.3 節）です。いずれも上記 3 つの基本関数の合成として実装されます。両者の違いは、その出力が異なる分布からサンプリングされる点にあります。

  • encode_to_curve は、バイト列から G 内の点への非一様な符号化です。すなわち、その出力の分布は G において一様ランダムではありません。encode_to_curve が取りうる出力の集合は G 内の点の一部分にすぎず、またこの集合内のある点は他の点よりも出力されやすくなっています。第 10.4 節では encode_to_curve の出力分布のより厳密な定義を与えます。
encode_to_curve(msg)

入力 (Input): msg, 任意長のバイト列。
出力 (Output): P, 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, 任意長のバイト列。
出力 (Output): P, 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              # 点の加算
5. P = clear_cofactor(R)
6. return P

第 8 節の各ハッシュ・トゥ・カーブ・スイートは、特定の楕円曲線についてこれらの符号化関数のいずれかを実体化します。

3.1. ドメイン分離の要件 (Domain Separation Requirements)​

本文書で定義される符号化関数のすべての利用は、類似の機能を持つ他の利用との干渉を避けるため、ドメイン分離（第 2.2.5 節）を含めなければなりません (MUST)。

hash_to_curve または encode_to_curve の複数の独立したインスタンスを実体化する応用は、それらのインスタンス間でドメイン分離を強制しなければなりません (MUST)。この要件は、複数のインスタンスが同じ曲線を対象とする場合と、異なる曲線を対象とする場合の双方に適用されます。（これは、内部で用いられる hash_to_field プリミティブ（第 5 節）が、独立した出力を保証するためにドメイン分離を必要とするためです。）

ドメイン分離はドメイン分離タグ (domain separation tag, DST) によって強制されます。DST は、以下の要件に従って構成されるバイト列です。

  1. タグは、第 5 節に記述されるとおり、hash_to_field への DST パラメータとして供給されなければなりません (MUST)。

  2. タグは非ゼロの長さを持たなければなりません (MUST)。他の応用との衝突の可能性を減らすため、最小長として 16 バイトが推奨されます (RECOMMENDED)。

  3. タグは、その応用に固有の固定された識別文字列で始まるべきです (SHOULD)。

  4. タグはバージョン番号を含むべきです (SHOULD)。

  5. 複数の暗号スイートを定義する応用では、各暗号スイートのタグは相異なっていなければなりません (MUST)。この目的のため、各タグに暗号スイート識別子を含めることが推奨されます (RECOMMENDED)。

  6. 同じ曲線または異なる曲線に対して複数の符号化を用いる応用では、各符号化は相異なるタグを用いなければなりません (MUST)。この目的のため、ドメイン分離タグに符号化の Suite ID（第 8 節）を含めることが推奨されます (RECOMMENDED)。同じスイートに基づく独立した符号化については、各タグはさらに、たとえば "ENC1" や "ENC2" のような区別可能な識別子を含めるべきです (SHOULD)。

一例として、それぞれ異なる曲線を対象とするいくつかの異なる暗号スイートを定義する、Quux という架空の応用を考えてみましょう。妥当なタグの選択は "QUUX-V<xx>-CS<yy>-<suiteID>" です。ここで <xx> と <yy> はそれぞれバージョンと暗号スイートを示す 2 桁の数字であり、<suiteID> は暗号スイート <yy> で用いられる符号化の Suite ID です。

もう一つの例として、同じ曲線に対して 2 つの独立したランダムオラクルを必要とする、Baz という架空の応用を考えてみましょう。これらのオラクルに対する妥当なタグの選択は、それぞれ "BAZ-V<xx>-CS<yy>-<suiteID>-ENC1" および "BAZ-V<xx>-CS<yy>-<suiteID>-ENC2" です。ここで <xx>、<yy>、<suiteID> は上述のとおりです。

上に挙げた例のタグは、ヌル終端を持たない ASCII 符号化されたバイト列であると想定されており、これが推奨される (RECOMMENDED) 形式です。他の符号化を用いることもできますが、いずれの場合もバイト列としての符号化が曖昧さなく規定されなければなりません (MUST)。

に最終更新