ソルトに関する質問です。

[siritai_san]

こんばんは。ソルトについての質問です。
ソルトの仕組みとしては、元データ(user1)に何文字(FIXEDSALT)かを付け足すことで総探索の時間を長くする（組み合わせを多くして時間
を稼ぐ。8文字よりは20文字以上が組み合わせも多くなる）というものですよね。
このソルトという対策は総探索攻撃に対する有効な対策であるとの解説がp326 で行われているにもかかわらず、p327の6行目では「ソルトを使って
も総当たり攻撃の脅威は残ります。その理由はソルトを使っても計算時間はさほど変わらないからです」との説明がされています。元データを長くしても計算
時間が変わらないのであれば対策にはならないことになり、p326でソルトを総探索への有効な対策として説明されていることと矛盾が生じるのではないで
しょうか。
その点が理解できませんでしたので、ご説明のほど、よろしくお願いいたします。

"ソルト"は導入しないよりはしたほうが良い対策であり、効果が高いのは"ストレッチング"ということを説明されているのでしょうか？

[徳丸浩]

siritai_san さん、こんばんは。質問ありがとうございます。

ソルトは総当たり探索の対策にはならず、レインボーテーブルの対策にはなるということです。
ソルトはユーザ毎に異なるため、レインボーテーブルを予め作成する際には、ソルトは未知のものとなります。このため、仮にパスワードが8文字で、ソルト
が12文字だとすると、合計20文字が変化することになり、レインボーテーブルを作成する上では、20文字の（ソルトなし）パスワードに対するレインボ
ーテーブルを作成することと等価になります。これは膨大な演算量が必要なため、非現実的ですし、ソルト長を長くすることのデメリットはあまりないので、
レインボーテーブルに対する効果的な対策がとれます。

一方、特定ユーザのパスワードハッシュ値から総当たりで元パスワードを調べるという前提では、ソルトは攻撃者にばれているという想定をします。この場
合、変化する文字はパスワードの部分だけですので、ソルト長に関わらず、総当たりすべきすべての場合の数は、ソルトなしの場合と変わりません。このた
め、「ソルトを使っても、ハッシュの計算時間はさほど変わらない」ことになります。

すなわち、矛盾しているのではなく、前提が異なるのです。レインボーテーブルを作成する場合はソルトの値は前もって分からない、一方、特定のハッシュ値
から元のパスワードを総当たり攻撃する場合は、ソルトを既知として考える、その差がソルトのありなしでの計算量の違いになります。