10. セキュリティに関する考慮事項 (Security Considerations)

セキュリティに関する考慮事項 (Security Considerations)

本節では、本文書で記述されるハッシュ・トゥ・カーブ機構に関する追加のセキュリティ上の考慮事項を扱います。

10.1. 符号化の性質 (Properties of Encodings)

各符号化型（第 3 節）は任意のバイト列を受け取り、その符号化型に依存する分布からサンプリングされた曲線上の点へと写します。非一様符号化を用いること、または第 6 節の写像のいずれかを直接評価することは、一様ランダムな点から容易に識別できる出力を生じさせるという点に注意することが重要です。非一様符号化を用いる応用は、非一様性がもたらすセキュリティ上の含意を注意深く解析すべきです (SHOULD)。必要な符号化が明確でない場合、応用は一様符号化を使用すべきです (SHOULD)。

第 3 節で与えられる両方の符号化は、群 G の単位元を出力しうます。いずれかの符号化関数がランダムな入力に対して単位元を出力する確率はおよそ 1/r であり、これは暗号学的に有用な楕円曲線については無視できる大きさです。さらに、いずれかの符号化関数について、対応する出力が単位元となるような入力を見つけることは計算量的に実行不可能です。（これらの性質はいずれも、符号化関数が第 5 節のすべての指針に従う hash_to_field 関数で実体化されている場合に成り立ちます。）これらの符号化関数を用いるプロトコルは、単位元を検出して「修正」するための特別な場合分けを追加すべきではありません (SHOULD NOT)。

hash_to_curve 関数（第 3 節）が、ランダムオラクルから識別不可能な hash_to_field 関数（第 5 節）で実体化される場合、結果として得られる関数はランダムオラクルから識別不可能です（[MRH04] [BCIMRT10] [FFSTV13] [LBB19] [H20]）。多くの場合、そのような関数は、楕円曲線上の一様ランダムな点を出力するランダムオラクルを仮定したセキュリティ解析を持つ暗号プロトコルにおいて安全に使用できます。しかしながら Ristenpart らが [RSS11] で論じているように、ランダムオラクルに依拠するすべてのセキュリティ証明が、それらのオラクルを識別不可能な機能で置き換えたときにも成り立ち続けるとは限りません。hash_to_curve 関数に依拠するプロトコルのセキュリティを解析する際には、この制限を考慮すべきです。

10.2. パスワードのハッシュ (Hashing Passwords)

本文書に記述されるいずれかの関数を用いてパスワードをハッシュする場合、ハッシュ関数の出力（あるいは潜在的には任意の中間値、たとえば hash_to_field の出力）を知った攻撃者は、辞書攻撃を実行できる可能性があります。そのような攻撃を緩和するため、まずパスワードに対してよりコストの高い鍵導出関数（たとえば PBKDF2 [RFC8018]、 scrypt [RFC7914]、または Argon2 [RFC9106]）を実行し、次にその関数の出力を対象の楕円曲線へハッシュすることが推奨されます。衝突耐性のため、鍵導出関数の基礎となるハッシュは第 5.3.1 節に列挙された指針に従って選択されるべきです。

10.3. 定数時間に関する要件 (Constant-Time Requirements)

サイドチャネルを介した情報漏洩を避けるため、本文書のすべての関数の定数時間実装が、あらゆる用途において強く推奨されます (STRONGLY RECOMMENDED)。符号化への入力が秘密値である場合には、定数時間実装を用いることが特に重要です。そのような場合、タイミング攻撃（たとえば [VR20]）に対するセキュリティのために定数時間実装が必須です (REQUIRED)。定数時間実装が要求される場合、第 4 節で論じたとおり、すべての基本演算およびユーティリティ関数が定数時間で実装されなければなりません。ある種の応用（たとえば組込みシステム）では、他のサイドチャネル（たとえば電力や電磁的なサイドチャネル）を介した漏洩が問題となる場合があります。そのような漏洩に対する防御は本文書の範囲外です。漏洩の性質と適切な防御は応用に依存するためです。

10.4. encode_to_curve: 出力分布と識別不可能性 (encode_to_curve: Output Distribution and Indifferentiability)

encode_to_curve 関数（第 3 節）は、一様分布から統計的に大きく離れた分布からサンプリングされた点を返します。この分布はおおよそ次のように限界付けられます。第 1 に、それは G の点の少なくとも 8 分の 1 を含みます。第 2 に、分布における点の確率は高々 4 倍の範囲で変動します。これらの限界は、encode_to_curve が第 6 節の map_to_curve 関数のいずれかで実体化される場合に成り立ちます。

上記の限界は文献中のいくつかの研究から導かれています。具体的には:

Shallue と van de Woestijne [SW06]、および Fouque と Tibouchi [FT12] は、Shallue-van de Woestijne 写像（第 6.6.1 節）に対する限界を導いています。
Fouque と Tibouchi [FT10]、および Tibouchi [T14] は、 Simplified SWU 写像（第 6.6.2 節および第 6.6.3 節）に対する限界を導いています。
Bernstein ら [BHKL13] は、Elligator 2 写像（第 6.7.1 節および第 6.8.2 節）に対する限界を導いています。

encode_to_curve の識別不可能性は、Brier らによって与えられた議論 [BCIMRT10] と類似の議論から従います。ここではその議論を簡潔に概説します。encode_to_curve が呼び出す map_to_curve 関数によって誘導される分布からサンプリングする理想的なランダムオラクル Hc() を考え、簡単のため対象の楕円曲線の余因子が 1 であると仮定します（1 でない余因子についても同様の議論が適用されます）。識別不可能性が成り立つのは、encode_to_curve における「内側の」ランダムオラクル、すなわち hash_to_field を効率的にシミュレートすることが可能である場合に限られます。シミュレータは次のように動作します。新しいクエリ msg に対して、シミュレータは Hc(msg) にクエリを行い、 map_to_curve の像に属する点 P を受け取ります（msg が以前のクエリと同一である場合、シミュレータはそのクエリへの応答として与えた値を単に返します）。次にシミュレータは、map_to_curve の下での P の可能な原像、すなわち map_to_curve(u) == P を満たす F の元 u を計算します（Tibouchi [T14] は、これが Shallue-van de Woestijne 写像と Simplified SWU 写像に対して効率的に行えることを示しており、 Bernstein らは Elligator 2 について同様のことを示しています）。シミュレータはそのような原像の 1 つをランダムに選択し、この値を「内側の」ランダムオラクルのシミュレートされた出力として返します。仮定により、Hc() は F の一様ランダムな入力元に対して map_to_curve が誘導する分布からサンプリングするため、この値は一様ランダムであり、 map_to_curve を通したときに正しい点 P を誘導します。

10.5. hash_to_field のセキュリティ (hash_to_field Security)

第 5 節で定義される hash_to_field 関数は、expand_message （第 5.3 節）がランダムオラクルとしてモデル化されるとき、ランダムオラクル [MRH04] から識別不可能です。識別不可能性の証明は合成可能であるため、これは expand_message が、ランダムオラクルとしてモデル化される基礎プリミティブに対して相対的にランダムオラクルから識別不可能であることが証明されている場合にも成り立ちます。第 5.3 節の指針に従う場合、同節で定義される expand_message の両変種はこの要件を満たします（第 10.6 節も参照）。

ここでは hash_to_field に対する識別不可能性の議論をごく簡潔に概説します。hash_to_field が返す各 mod p 整数（すなわち F のベクトル表現の各成分）は、長さ log2(p) + k ビットのおよそ 2^k 個の整数からなる同値類の一員であり、それらはすべて p を法として等しいことに注意してください。hash_to_field が返す各 mod p 整数について、シミュレータはこの同値類の一員をランダムにサンプリングし、 I2OSP が返すバイト列を出力します。（これは本質的に hash_to_field の手続きの逆であることに注意してください。）

10.6. expand_message_xmd のセキュリティ (expand_message_xmd Security)

第 5.3.1 節で定義される expand_message_xmd 関数は、以下のいずれかが成り立つとき、ランダムオラクル [MRH04] から識別不可能です。

H がランダムオラクルから識別不可能である、
H が、その内部関数がランダム変換またはランダム置換としてモデル化されるスポンジ構造に基づくハッシュ関数である [BDPV08]、または
H が、その圧縮関数がランダムオラクルとしてモデル化される Merkle-Damgaard ハッシュ関数である [CDMP05]。

場合 (1) と (2) については、expand_message_xmd の識別不可能性は H の識別不可能性から直接従います。

場合 (3)、すなわち H が Merkle-Damgaard ハッシュ関数である場合、識別不可能性は [CDMP05] の定理 5 から従います。とりわけ、 expand_message_xmd は、メッセージの前に 1 ブロック分のゼロと補助情報（長さ、カウンタ、および DST）を付加することによって b_0 を計算します。次に、expand_message_xmd における各出力ブロック b_i（i >= 1）は、b_0 の一意なプレフィックスフリー符号化に対して H を呼び出した結果です。これが成り立つのは、第 1 に、そのようなすべての呼び出しへの入力の長さが等しく、H と DST の選択によって固定されているためであり、第 2 に、そのような各入力が（カウンタバイト I2OSP(i, 1) を含むことにより）一意なサフィックスを持つためです。

[CDMP05] で論じられている構成と expand_message_xmd との本質的な相違は、後者がカウンタを b_0 ではなく strxor(b_0, b_(i - 1)) （{#hashtofield-expand-xmd}、手順 10）に追記したものをハッシュする点にあります。このアプローチは H の異なる呼び出しへの入力間のハミング距離を増大させ、これにより H の非理想性が b_i の値の分布に影響を及ぼす可能性を低減します。

expand_message_xmd は、上記の基準のいずれかを満たす任意のハッシュ関数に基づいて、可変長出力を持つ汎用の識別不可能な機能を実体化するために使用できることに注意します。hash_to_field の外部で expand_message_xmd を用いる応用は、DST に相異なる値を選ぶことによってドメイン分離を保証すべきです。

10.7. expand_message 変種に対するドメイン分離 (Domain Separation for expand_message Variants)

第 2.2.5 節で論じたとおり、ドメイン分離の目的は、複数の独立したランダムオラクルにクエリを行う暗号プロトコルのセキュリティ解析が、それらのランダムオラクルのすべてが 1 つの基礎関数 H に基づいて実体化される場合であっても有効であり続けることを保証することです。

本文書の expand_message 変種（第 5.3 節）は、基礎となるハッシュ関数または拡張可能出力関数である H によってハッシュされるすべての文字列に、サフィックスフリー符号化されたドメイン分離タグ DST_prime を追記することによってドメイン分離を保証します。（第 5.3.4 節の指針に従う他の expand_message 変種も同様に振る舞うと期待されますが、これらは個別に解析されるべきです。）セキュリティのため、 expand_message の外部で同じ関数 H を用いる応用は、それらの H の使用と expand_message との間のドメイン分離を強制すべきであり、またこれらすべてを他の応用における H の使用から分離すべきです。

本節では、expand_message 変種からドメイン分離を強制するための 4 つの方法を提案し、各方法がどのようにドメイン分離を達成するかを説明し、それぞれが適切となる状況を列挙します。これらの方法は高レベルの構造を共有しています。すなわち、応用の設計者は DST_prime とは相異なるタグ DST_ext を定め、H への呼び出しを DST_ext で拡張します。各方法は H への呼び出しを異なる方法で拡張し、それぞれが DST_ext に追加の要件を課す場合があります。

これらの方法は、それぞれに相異なる DST_ext の値（たとえば DST_ext1, DST_ext2）を選択することにより、複数のドメイン分離された関数（たとえば H1 と H2）を実体化するために使用できます。

（サフィックスのみによるドメイン分離。）この方法は、H の呼び出しを expand_message_xmd または expand_message_xof からドメイン分離する際に有用です。expand_message を HMAC-H [RFC2104] からドメイン分離する目的には適していません。その目的には方法 4 を参照してください。

サフィックスのみでドメイン分離された関数 Hso を実体化するには、次を計算します。

  Hso(msg) = H(msg || DST_ext)

   同じ値にハッシュされる相異なる (msg, DST_ext) の組を見つけることを
   実行不可能にするため、DST_ext はサフィックスフリー符号化される
   べきです（たとえば DST_ext の長さを符号化した 1 バイトを
   追記することによって）。

   DST_ext は DST_prime とは相異なるため、H のすべての相異なる
   呼び出しは相異なるサフィックスを持ちます。したがってこの方法は
   ドメイン分離を保証します。

2. （プレフィックス・サフィックスによるドメイン分離。）この方法はサフィックスのみの方法と同じ場合に使用できます。

   プレフィックス・サフィックスでドメイン分離された関数 Hps を
   実体化するには、次を計算します。

  Hps(msg) = H(DST_ext || msg || I2OSP(0, 1))

   同じ値にハッシュされる相異なる (msg, DST_ext) の組を見つけることを
   実行不可能にするため、DST_ext はプレフィックスフリー符号化される
   べきです（たとえば DST_ext の長さを符号化した 1 バイトの
   プレフィックスを付加することによって）。

   バイト I2OSP(0, 1) を追記することにより、Hps の内部での H への
   入力が expand_message の内部での入力と相異なることが保証されるため、
   この方法はドメイン分離を保証します。具体的には、DST_prime の
   最終バイトは DST の長さを符号化しており、これは非ゼロで
   あることが要求されます（第 3.1 節、要件 2）。また DST_prime は
   expand_message の内部での H の呼び出しに常に追記されます。

3. （プレフィックスのみによるドメイン分離。）この方法は、H の呼び出しを expand_message_xmd からドメイン分離する場合にのみ有用です。 expand_message_xof や HMAC-H に対するドメイン分離は与えません。

   プレフィックスのみでドメイン分離された関数 Hpo を実体化するには、
   次を計算します。

  Hpo(msg) = H(DST_ext || msg)

   この方法がドメイン分離を与えるためには、DST_ext は少なくとも
   b ビットの長さであるべきです。ここで b はハッシュ関数 H が
   出力するビット数です。加えて、最初の b ビットのうち少なくとも
   1 ビットは非ゼロでなければなりません。最後に、同じ値に
   ハッシュされる相異なる (msg, DST_ext) の組を見つけることを
   実行不可能にするため、DST_ext はプレフィックスフリー符号化される
   べきです（たとえば DST_ext の長さを符号化した 1 バイトの
   プレフィックスを付加することによって）。

   この方法は次のようにドメイン分離を保証します。第 1 に、DST_ext は
   その最初の b ビットの中に少なくとも 1 つの非ゼロビットを含むため、
   値 Z_pad（第 5.3.1 節、手順 4）とは相異なることが保証され、
   これにより H へのすべての入力が expand_message_xmd において
   b_0 を生成するために用いられる入力と相異なることが保証されます。
   第 2 に、DST_ext は少なくとも b ビットの長さであるため、
   値 b_0 および strxor(b_0, b_(i - 1)) とはほぼ確実に相異なり、
   したがって H へのすべての入力は、高い確率で、b_i（i >= 1）を
   生成するために用いられる入力と相異なります。

4. （XMD-HMAC ドメイン分離。）この方法は、HMAC-H（すなわちハッシュ関数 H で実体化された HMAC [RFC2104]）の内部での H の呼び出しを expand_message_xmd からドメイン分離する際に有用です。これは以下で論じるとおり、HKDF-H（すなわちハッシュ関数 H で実体化された HKDF [RFC5869]）にも適用されます。

   具体的には、この方法は、ハッシュ関数 H に基づいてランダムオラクルを
   実体化するために HMAC-H が非秘密の鍵とともに用いられる場合に
   適用されます（expand_message_xmd もこの目的に使用できることに
   注意してください。第 10.6 節を参照）。高エントロピーの秘密鍵とともに
   HMAC-H を用いる場合、ドメイン分離は必要ありません。以下の議論を
   参照してください。

   expand_message_xmd からのドメイン分離を保証する非秘密の HMAC 鍵
   DST_key を選ぶには、次を計算します。

  DST_key_preimage = "DERIVE-HMAC-KEY-" || DST_ext || I2OSP(0, 1)
  DST_key = H(DST_key_preimage)

   次に、HMAC-H を用いてランダムオラクル Hro を実体化するには、
   次を計算します。

  Hro(msg) = HMAC-H(DST_key, msg)

   DST_key_preimage の末尾のゼロバイトは、この値が
   expand_message_xmd の内部での H への入力と相異なることを
   保証します（そのようなすべての入力はサフィックス DST_prime を
   持ち、上で論じたとおりゼロバイトで終わることはありえないため）。
   これは、圧倒的な確率で、鍵 DST_key を用いる HMAC-H の内部での
   H へのすべての入力が、expand_message_xmd の内部の値 Z_pad,
   b_0, および strxor(b_0, b_(i - 1)) とは相異なるプレフィックスを
   持つため、ドメイン分離を保証します。

   高エントロピーの秘密鍵を固定することによって私的なランダムオラクルを
   実体化する HMAC-H の使用については、expand_message_xmd からの
   ドメイン分離は必要ありません。これは上記の場合と同様に、
   この秘密鍵を用いる HMAC-H の内部での H へのすべての入力が、
   expand_message_xmd の内部での H へのすべての入力とほぼ確実に
   相異なるプレフィックスを持つためです。

   最後に、この方法は、上記のとおり計算された DST_key に
   HKDF-Extract のソルト入力を固定することにより、HKDF-H [RFC5869]
   とともに使用できます。これは、DST_key を用いる HMAC-H に対するのと
   同じ議論により、HKDF-Extract に対するドメイン分離を保証します。
   さらに、HKDF-Extract に供給される入力鍵材料 (IKM) が十分に高い
   エントロピー（たとえばセキュリティパラメータに見合うもの）を
   持つと仮定すれば、HKDF-Expand の段階は、高エントロピーの秘密鍵を
   用いる HMAC-H に対するのと同じ議論によってドメイン分離されます
   （疑似ランダム鍵はまさにそのようなものであるため）。

10.8. 目標セキュリティレベル (Target Security Levels)

各暗号スイートは、基礎となる曲線に対する目標セキュリティレベル（ビット単位）を規定します。このパラメータは、対応する hash_to_field の実体化が保守的かつ正しいものであることを保証します。このパラメータは曲線のセキュリティレベルの上界にすぎず、所与の応用に対する適合性の保証でも推奨でもないことを強調します。数学的および暗号学的な進展は、任意の曲線に対する実効的なセキュリティレベルを低下させる可能性があります。