scryptは安全であると見なされるのに十分なテストを受けましたか？
5年前に、非常に類似した質問が尋ねられました： scryptは時の試練に耐えました これは5年前に尋ねられ、いくつかの応答が混合されたため、次のように：
「Scryptはほとんど生き残っています。」または「パスワードハッシュコンテストに細心の注意を払うすべての人は、コリンパーシバルがscryptの改訂版を提出することを期待しています。」または「scryptは、既存の反復ハッシュ構成技法と同じくらい優れているだけです」。
もちろん、ムーアの法則により、scryptは5年前に発表されたものよりも（改訂により）弱くなったり強かったりする可能性があります。
だから私の質問は：
はい。 Scryptは安全に使用できます。潜在的なセキュリティ問題の2つの原因があります。algorithm設計の弱点とimplementationのエラーです。
Scryptの設計は比較的単純なので、現時点で衝撃を与える可能性があるのは実装エラーだけです。
（バッファオーバーフロー、解析ミス、解放後使用のバグなどの問題。これらは注意すべき点ですが、パスワードハッシュコードに固有のものではありません。オペレーティングシステムで危険なバグを見つける可能性がはるかに高いです。 、ウェブサーバー、ブラウザ、OpenSSLなど）。
アルゴリズムの弱点に関しては、scryptがbcryptまたはPBKDF2よりも優れていることに疑問の余地はありません。基本的なWebアプリ認証に適さない問題が1つだけあります。これは、ファイルの暗号化に使用される鍵導出関数になるように設計されています。時間やメモリが不足している可能性がある他の用途には十分な柔軟性がありません。
そのため、パスワードハッシュコンテストが開催されました。暗号化を改善する。開発者はArgon2 v 1.を新しいプロジェクトに組み込む必要があり、古いアルゴリズムを現在使用している場合はアップグレードを可能にする予定です。 （他のものを使用することを検討する唯一の強力な正当化は、本質的にメモリが非常に限られているプラットフォーム用に開発している場合です。）
Scryptが特定のプロジェクトで正しく使用されている場合、パニックを起こす必要はありません。強力なパスワードと十分な大きさの反復回数を使用した場合、暗号化されたデータは安全です。暗号化されたデータは、反復回数に関係なく、一意の（使い捨ての）予測できないパスワードを使用した場合にも安全です。
しかし、scryptの何が悪いのでしょうか？
- 単一のコストパラメータがあります。実行時間を増やすことなくメモリ使用量を増やすことはできません。
- メモリトレードオフの時間で、パスワードクラッカーはメモリを減らすことができます。 nの係数でメモリをカットすると、nの係数だけ実行時間が増加します-）。
- Argon2（既存のx64プラットフォーム上）よりも、メモリを埋めるのに時間がかかります。
- Argon2ハッシュレートを改善するよりも、専用ハードウェアを使用して暗号解読ハッシュレートを改善する方が簡単です。
では、scryptを安全に使用するにはどうすればよいでしょうか。
- 繰り返し回数を高く設定してください。数ギガバイトのメモリを使用してみてください。
- ランダムに生成された塩を使用します。
- 信頼できる実装を使用してください。 GitHubプロジェクトだけではありません。セキュリティアップデートで最新の状態に保ちます。
- パラメータを増やすか、別のハッシュアルゴリズムに移行できるようにソフトウェアを設計します。
上記の4つの点はArgon2の使用にも当てはまりますが、時間やメモリを多かれ少なかれ使用する方が安全です。 PHC Argonプロジェクトのバージョン1.3に付随するパラメーターを選択するためのアドバイスは適切です。