回答編集履歴
4
answer
CHANGED
|
@@ -24,11 +24,13 @@
|
|
|
24
24
|
|
|
25
25
|
なお、PBKDF2も反復回数やsaltの設定次第で攻撃耐性が変わります。
|
|
26
26
|
|
|
27
|
-
質問文に記載の[string-cryptoの実装](https://github.com/simplyhexagonal/string-crypto/blob/main/src/index.ts#L10-L15) を見ると、
|
|
27
|
+
質問文に記載の[string-cryptoのデフォルト実装](https://github.com/simplyhexagonal/string-crypto/blob/main/src/index.ts#L10-L15) を見ると、
|
|
28
28
|
・saltに「s41t」という固定値が使用されている。
|
|
29
29
|
・iterationが1回
|
|
30
|
-
ということから、
|
|
30
|
+
ということから、デフォルトの状態ではあまり意味がありません。
|
|
31
|
+
実際には [option でカスタマイズして使用](https://github.com/simplyhexagonal/string-crypto#options)すべきです。
|
|
31
32
|
|
|
33
|
+
|
|
32
34
|
ユーザビリティ（パスワードを知っている正規ユーザーがパスワードを使って鍵を開くまでの待ち時間）とのトレードオフになりますが、
|
|
33
35
|
安全性を高めるならば、iterationをもっと多くするべきでしょう。（例：[iOS4は1万回のストレッチングを行っているとの情報](https://blog.elcomsoft.com/2010/09/smartphone-forensics-cracking-blackberry-backup-passwords/)）
|
|
34
36
|
さらにsaltをパスワードごとに異なる長いランダム値にすれば、より安全です。
|
3
answer
CHANGED
|
@@ -1,42 +1,42 @@
|
|
|
1
|
-
パスワードをそのまま鍵として用いるよりも、パスワードを鍵導出関数に通して得られた値を鍵として使用した方が、より安全性が高まるからです。
|
|
1
|
+
パスワードをそのまま鍵として用いるよりも、パスワードを鍵導出関数に通して得られた値を鍵として使用した方が、より安全性が高まるからです。
|
|
2
|
-
|
|
3
|
-
|
|
2
|
+
|
|
3
|
+
|
|
4
|
-
攻撃者は、初期化Vectorとユーザーが使いそうなパスワード（pass、12345、hogehoge等）を手あたり次第使うことによって復号を試みることができます。（辞書攻撃）
|
|
4
|
+
攻撃者は、初期化Vectorとユーザーが使いそうなパスワード（pass、12345、hogehoge等）を手あたり次第使うことによって復号を試みることができます。（辞書攻撃）
|
|
5
|
-
|
|
5
|
+
|
|
6
|
-
ここで、パスワードがそのまま鍵として使われている場合と、パスワードを鍵導出関数に反復して通して得た値が鍵として使用されている場合とを比較すると、後者の方が計算負荷が高いため、単位時間あたりの攻撃試行回数を少なくすることができます。
|
|
6
|
+
ここで、パスワードがそのまま鍵として使われている場合と、パスワードを鍵導出関数に反復して通して得た値が鍵として使用されている場合とを比較すると、後者の方が計算負荷が高いため、単位時間あたりの攻撃試行回数を少なくすることができます。
|
|
7
|
-
|
|
8
|
-
|
|
7
|
+
|
|
8
|
+
|
|
9
|
-
> SHA-256などを使用せず、代わりに鍵導出関数を使う理由
|
|
9
|
+
> SHA-256などを使用せず、代わりに鍵導出関数を使う理由
|
|
10
|
-
|
|
10
|
+
|
|
11
|
-
PBKDF2は、iteration（反復回数）の設定によって計算負荷を柔軟に変更し、安全性を高めることができるからです。
|
|
11
|
+
PBKDF2は、iteration（反復回数）の設定によって計算負荷を柔軟に変更し、安全性を高めることができるからです。
|
|
12
|
-
（iteration＝パスワードに関数を通して出てきた値をもういちど関数に通す、ということを繰り返す回数（「ストレッチング」））
|
|
12
|
+
（iteration＝パスワードに関数を通して出てきた値をもういちど関数に通す、ということを繰り返す回数（「ストレッチング」））
|
|
13
|
-
|
|
13
|
+
|
|
14
|
-
SHA-256そのものは単純にハッシュを作るだけであり、**パスワードにSHA-256を通して得られた値をそのまま使う場合は**計算負荷が低いため、鍵導出関数の中で反復して得た値を使用する場合と比較して辞書攻撃に弱いといえます。
|
|
14
|
+
SHA-256そのものは単純にハッシュを作るだけであり、**パスワードにSHA-256を通して得られた値をそのまま使う場合は**計算負荷が低いため、鍵導出関数の中で反復して得た値を使用する場合と比較して辞書攻撃に弱いといえます。
|
|
15
|
-
|
|
16
|
-
|
|
15
|
+
|
|
16
|
+
|
|
17
|
-
もちろん独自実装すればSHA-256だけを利用して、PBKDF2と同じようなものはできるでしょう。
|
|
17
|
+
もちろん独自実装すればSHA-256だけを利用して、PBKDF2と同じようなものはできるでしょう。
|
|
18
|
-
|
|
18
|
+
|
|
19
|
-
しかしPBKDF2の方が長い歴史の中で破られておらず、また既に多様なプラットフォームで動くライブラリが存在するという強みがあると考えられます。
|
|
19
|
+
しかしPBKDF2の方が長い歴史の中で破られておらず、また既に多様なプラットフォームで動くライブラリが存在するという強みがあると考えられます。
|
|
20
|
-
|
|
20
|
+
|
|
21
|
-
[RFC8018](https://tools.ietf.org/html/rfc8018)がPBKDF2を推奨していることからも、暗号化関係のソリューションにおいて、鍵導出関数としてPBKDF2を使用することはデファクトスタンダードであり、一種の御作法みたいなイメージなのでしょう。
|
|
21
|
+
[RFC8018](https://tools.ietf.org/html/rfc8018)がPBKDF2を推奨していることからも、暗号化関係のソリューションにおいて、鍵導出関数としてPBKDF2を使用することはデファクトスタンダードであり、一種の御作法みたいなイメージなのでしょう。
|
|
22
|
-
（計算機の能力が飛躍的に向上した現状、PKDF2は既に弱いともいわれているらしいですが（[wikipedia](https://ja.wikipedia.org/wiki/PBKDF2)中段「PKDF2の代替」参照））
|
|
22
|
+
（計算機の能力が飛躍的に向上した現状、PKDF2は既に弱いともいわれているらしいですが（[wikipedia](https://ja.wikipedia.org/wiki/PBKDF2)中段「PKDF2の代替」参照））
|
|
23
|
-
|
|
24
|
-
|
|
23
|
+
|
|
24
|
+
|
|
25
|
-
なお、PBKDF2も反復回数やsaltの設定次第で攻撃耐性が変わります。
|
|
25
|
+
なお、PBKDF2も反復回数やsaltの設定次第で攻撃耐性が変わります。
|
|
26
|
-
|
|
26
|
+
|
|
27
|
-
質問文に記載のstring-cryptoの実装
|
|
27
|
+
質問文に記載の[string-cryptoの実装](https://github.com/simplyhexagonal/string-crypto/blob/main/src/index.ts#L10-L15) を見ると、
|
|
28
|
-
・saltに「s41t」という固定値が使用されている。
|
|
28
|
+
・saltに「s41t」という固定値が使用されている。
|
|
29
|
-
・iterationが1回
|
|
29
|
+
・iterationが1回
|
|
30
|
-
ということから、使わないよりまし、程度だと思われます。
|
|
30
|
+
ということから、使わないよりまし、程度だと思われます。
|
|
31
|
-
|
|
31
|
+
|
|
32
|
-
ユーザビリティ（パスワードを知っている正規ユーザーがパスワードを使って鍵を開くまでの待ち時間）とのトレードオフになりますが、
|
|
32
|
+
ユーザビリティ（パスワードを知っている正規ユーザーがパスワードを使って鍵を開くまでの待ち時間）とのトレードオフになりますが、
|
|
33
|
-
安全性を高めるならば、iterationをもっと多くするべきでしょう。（例：[iOS4は1万回のストレッチングを行っているとの情報](https://blog.elcomsoft.com/2010/09/smartphone-forensics-cracking-blackberry-backup-passwords/)）
|
|
33
|
+
安全性を高めるならば、iterationをもっと多くするべきでしょう。（例：[iOS4は1万回のストレッチングを行っているとの情報](https://blog.elcomsoft.com/2010/09/smartphone-forensics-cracking-blackberry-backup-passwords/)）
|
|
34
|
-
さらにsaltをパスワードごとに異なる長いランダム値にすれば、より安全です。
|
|
34
|
+
さらにsaltをパスワードごとに異なる長いランダム値にすれば、より安全です。
|
|
35
|
-
|
|
35
|
+
|
|
36
|
-
（そもそもPBKDF2では使用するハッシュアルゴリズムを指定するようになっていて、そこにSHA-256を指定することも可能です。
|
|
36
|
+
（そもそもPBKDF2では使用するハッシュアルゴリズムを指定するようになっていて、そこにSHA-256を指定することも可能です。
|
|
37
|
-
PBKDF2は指定したハッシュアルゴリズムを利用しつつ、saltやiteration等のパラメータに基づいてパスワードを加工し最終的な鍵を作ります。
|
|
37
|
+
PBKDF2は指定したハッシュアルゴリズムを利用しつつ、saltやiteration等のパラメータに基づいてパスワードを加工し最終的な鍵を作ります。
|
|
38
|
-
|
|
38
|
+
|
|
39
|
-
したがってPBKDF2はSHA-256と競合する関係というよりは、料理(鍵）を作るためのシェフとレシピのような関係ともいえるでしょう。
|
|
39
|
+
したがってPBKDF2はSHA-256と競合する関係というよりは、料理(鍵）を作るためのシェフとレシピのような関係ともいえるでしょう。
|
|
40
|
-
|
|
40
|
+
|
|
41
|
-
パスワードとsaltを材料にして、シェフ（PKDF2）が、レシピ（指定されたハッシュアルゴリズムとiteration）に基ついて料理（鍵）を作る。
|
|
41
|
+
パスワードとsaltを材料にして、シェフ（PKDF2）が、レシピ（指定されたハッシュアルゴリズムとiteration）に基ついて料理（鍵）を作る。
|
|
42
42
|
レシピ（SHA-256）だけでも鍵は作れますが、saltとiterationで手間暇をかけるともっとおいしい料理（安全性の高い鍵）が作れます）
|
2
修正
answer
CHANGED
|
@@ -1,43 +1,42 @@
|
|
|
1
1
|
パスワードをそのまま鍵として用いるよりも、パスワードを鍵導出関数に通して得られた値を鍵として使用した方が、より安全性が高まるからです。
|
|
2
2
|
|
|
3
3
|
|
|
4
|
-
|
|
4
|
+
攻撃者は、初期化Vectorとユーザーが使いそうなパスワード（pass、12345、hogehoge等）を手あたり次第使うことによって復号を試みることができます。（辞書攻撃）
|
|
5
5
|
|
|
6
|
-
ここで、
|
|
6
|
+
ここで、パスワードがそのまま鍵として使われている場合と、パスワードを鍵導出関数に反復して通して得た値が鍵として使用されている場合とを比較すると、後者の方が計算負荷が高いため、単位時間あたりの攻撃試行回数を少なくすることができます。
|
|
7
7
|
|
|
8
8
|
|
|
9
9
|
> SHA-256などを使用せず、代わりに鍵導出関数を使う理由
|
|
10
10
|
|
|
11
|
-
PBKDF2
|
|
11
|
+
PBKDF2は、iteration（反復回数）の設定によって計算負荷を柔軟に変更し、安全性を高めることができるからです。
|
|
12
12
|
（iteration＝パスワードに関数を通して出てきた値をもういちど関数に通す、ということを繰り返す回数（「ストレッチング」））
|
|
13
13
|
|
|
14
|
-
SHA-256そのものは単純にハッシュを作るだけであり、**パスワードにSHA-256を通して得られた値をそのまま使う場合は**計算負荷が低いため、鍵導出関数の中で反復して得た値を使用する場合と比較して
|
|
14
|
+
SHA-256そのものは単純にハッシュを作るだけであり、**パスワードにSHA-256を通して得られた値をそのまま使う場合は**計算負荷が低いため、鍵導出関数の中で反復して得た値を使用する場合と比較して辞書攻撃に弱いといえます。
|
|
15
15
|
|
|
16
16
|
|
|
17
17
|
もちろん独自実装すればSHA-256だけを利用して、PBKDF2と同じようなものはできるでしょう。
|
|
18
18
|
|
|
19
19
|
しかしPBKDF2の方が長い歴史の中で破られておらず、また既に多様なプラットフォームで動くライブラリが存在するという強みがあると考えられます。
|
|
20
20
|
|
|
21
|
-
[RFC8018](https://tools.ietf.org/html/rfc8018)がPBKDF2を推奨していることも
|
|
21
|
+
[RFC8018](https://tools.ietf.org/html/rfc8018)がPBKDF2を推奨していることからも、暗号化関係のソリューションにおいて、鍵導出関数としてPBKDF2を使用することはデファクトスタンダードであり、一種の御作法みたいなイメージなのでしょう。
|
|
22
22
|
（計算機の能力が飛躍的に向上した現状、PKDF2は既に弱いともいわれているらしいですが（[wikipedia](https://ja.wikipedia.org/wiki/PBKDF2)中段「PKDF2の代替」参照））
|
|
23
23
|
|
|
24
24
|
|
|
25
|
-
PBKDF2も反復回数やsaltの設定次第で攻撃耐性が変わります。
|
|
25
|
+
なお、PBKDF2も反復回数やsaltの設定次第で攻撃耐性が変わります。
|
|
26
26
|
|
|
27
27
|
質問文に記載のstring-cryptoの実装の場合、
|
|
28
28
|
・saltに「s41t」という固定値が使用されている。
|
|
29
29
|
・iterationが1回
|
|
30
|
-
ということから、
|
|
30
|
+
ということから、使わないよりまし、程度だと思われます。
|
|
31
31
|
|
|
32
|
-
ユーザビリティ（パスワードを知っているユーザーがパスワードを使って鍵を開くまでの待ち時間）とのトレードオフになりますが、
|
|
32
|
+
ユーザビリティ（パスワードを知っている正規ユーザーがパスワードを使って鍵を開くまでの待ち時間）とのトレードオフになりますが、
|
|
33
|
-
安全性を高めるならば、
|
|
33
|
+
安全性を高めるならば、iterationをもっと多くするべきでしょう。（例：[iOS4は1万回のストレッチングを行っているとの情報](https://blog.elcomsoft.com/2010/09/smartphone-forensics-cracking-blackberry-backup-passwords/)）
|
|
34
|
+
さらにsaltをパスワードごとに異なる長いランダム値にすれば、より安全です。
|
|
34
35
|
|
|
35
|
-
|
|
36
|
-
|
|
37
36
|
（そもそもPBKDF2では使用するハッシュアルゴリズムを指定するようになっていて、そこにSHA-256を指定することも可能です。
|
|
38
37
|
PBKDF2は指定したハッシュアルゴリズムを利用しつつ、saltやiteration等のパラメータに基づいてパスワードを加工し最終的な鍵を作ります。
|
|
39
38
|
|
|
40
|
-
したがってPBKDF2はSHA-256と競合する関係というよりは、料理(鍵）を作るための
|
|
39
|
+
したがってPBKDF2はSHA-256と競合する関係というよりは、料理(鍵）を作るためのシェフとレシピのような関係ともいえるでしょう。
|
|
41
40
|
|
|
42
41
|
パスワードとsaltを材料にして、シェフ（PKDF2）が、レシピ（指定されたハッシュアルゴリズムとiteration）に基ついて料理（鍵）を作る。
|
|
43
42
|
レシピ（SHA-256）だけでも鍵は作れますが、saltとiterationで手間暇をかけるともっとおいしい料理（安全性の高い鍵）が作れます）
|
1
修正
answer
CHANGED
|
@@ -3,24 +3,26 @@
|
|
|
3
3
|
|
|
4
4
|
御記載の通り、初期化Vectorとユーザーが使いそうなパスワード（pass、12345、hogehoge等）を手あたり次第使って暗号文に総当たり攻撃することによって、復号を試みることができます。（辞書攻撃）
|
|
5
5
|
|
|
6
|
-
ここで、鍵にパスワードがそのまま使われている場合と、パスワードを鍵導出関数に通して得た値が使用されている場合とを比較すると、後者の方が計算負荷が高いため、攻撃に時間がかかります。
|
|
6
|
+
ここで、鍵にパスワードがそのまま使われている場合と、パスワードを鍵導出関数に反復して通して得た値が使用されている場合とを比較すると、後者の方が計算負荷が高いため、総当たり攻撃に時間がかかります。
|
|
7
7
|
|
|
8
8
|
|
|
9
9
|
> SHA-256などを使用せず、代わりに鍵導出関数を使う理由
|
|
10
10
|
|
|
11
|
-
PBKDF2の方が、saltやiteration（反復回数）の設定によって計算負荷を
|
|
11
|
+
PBKDF2の方が、saltやiteration（反復回数）の設定によって計算負荷を変更し、安全性を高めることができるからです。
|
|
12
12
|
（iteration＝パスワードに関数を通して出てきた値をもういちど関数に通す、ということを繰り返す回数（「ストレッチング」））
|
|
13
13
|
|
|
14
|
-
SHA-256そのものは単純にハッシュを作るだけであり、**そのまま使う場合は**計算負荷が低いため、
|
|
14
|
+
SHA-256そのものは単純にハッシュを作るだけであり、**パスワードにSHA-256を通して得られた値をそのまま使う場合は**計算負荷が低いため、鍵導出関数の中で反復して得た値を使用する場合と比較して総当たり攻撃に弱いといえます。
|
|
15
15
|
|
|
16
|
+
|
|
16
17
|
もちろん独自実装すればSHA-256だけを利用して、PBKDF2と同じようなものはできるでしょう。
|
|
17
18
|
|
|
18
19
|
しかしPBKDF2の方が長い歴史の中で破られておらず、また既に多様なプラットフォームで動くライブラリが存在するという強みがあると考えられます。
|
|
19
20
|
|
|
20
|
-
[RFC8018](https://tools.ietf.org/html/rfc8018)がPBKDF2を推奨していることもあり、暗号化関係のソリューションにおいて、鍵導出関数としてPBKDF2を使用することはデファクトスタンダードであり、一種の御作法みたいなイメージ
|
|
21
|
+
[RFC8018](https://tools.ietf.org/html/rfc8018)がPBKDF2を推奨していることもあり、近年までは暗号化関係のソリューションにおいて、鍵導出関数としてPBKDF2を使用することはデファクトスタンダードであり、一種の御作法みたいなイメージだったのでしょう。
|
|
22
|
+
（計算機の能力が飛躍的に向上した現状、PKDF2は既に弱いともいわれているらしいですが（[wikipedia](https://ja.wikipedia.org/wiki/PBKDF2)中段「PKDF2の代替」参照））
|
|
21
23
|
|
|
22
24
|
|
|
23
|
-
|
|
25
|
+
PBKDF2も反復回数やsaltの設定次第で攻撃耐性が変わります。
|
|
24
26
|
|
|
25
27
|
質問文に記載のstring-cryptoの実装の場合、
|
|
26
28
|
・saltに「s41t」という固定値が使用されている。
|
|
@@ -28,4 +30,14 @@
|
|
|
28
30
|
ということから、やらないよりまし、程度だと思われます。
|
|
29
31
|
|
|
30
32
|
ユーザビリティ（パスワードを知っているユーザーがパスワードを使って鍵を開くまでの待ち時間）とのトレードオフになりますが、
|
|
31
|
-
安全性を高めるならば、saltを長いランダム値にし、iterationをもっと多くするべきでしょう。（例：[iOS4は1万回のストレッチングを行っているとの情報](https://blog.elcomsoft.com/2010/09/smartphone-forensics-cracking-blackberry-backup-passwords/)）
|
|
33
|
+
安全性を高めるならば、saltを長いランダム値にし、iterationをもっと多くするべきでしょう。（例：[iOS4は1万回のストレッチングを行っているとの情報](https://blog.elcomsoft.com/2010/09/smartphone-forensics-cracking-blackberry-backup-passwords/)）
|
|
34
|
+
|
|
35
|
+
|
|
36
|
+
|
|
37
|
+
（そもそもPBKDF2では使用するハッシュアルゴリズムを指定するようになっていて、そこにSHA-256を指定することも可能です。
|
|
38
|
+
PBKDF2は指定したハッシュアルゴリズムを利用しつつ、saltやiteration等のパラメータに基づいてパスワードを加工し最終的な鍵を作ります。
|
|
39
|
+
|
|
40
|
+
したがってPBKDF2はSHA-256と競合する関係というよりは、料理(鍵）を作るためのレシピとシェフのような関係ともいえるでしょう。
|
|
41
|
+
|
|
42
|
+
パスワードとsaltを材料にして、シェフ（PKDF2）が、レシピ（指定されたハッシュアルゴリズムとiteration）に基ついて料理（鍵）を作る。
|
|
43
|
+
レシピ（SHA-256）だけでも鍵は作れますが、saltとiterationで手間暇をかけるともっとおいしい料理（安全性の高い鍵）が作れます）
|