opensslコマンドラインツールの「-salt」がセキュリティを強化する方法がまったくわかりません
私はこれを単一のファイルを暗号化するために行います：
openssl aes-256-cbc -a -salt -in file.txt -out file.enc
次に、通常の平文パスワードを入力します。
-saltこれのセキュリティを強化します。その理由は、saltが次のようにファイルの先頭に格納されているためです。
Salted__<eight salt bytes>
そのような明白な方法でクラッカーが利用できる塩は、その目的は何ですか？辞書攻撃がどのように難しくなるかわかりません...特に、私の知る限り、opensslは1回の反復でパスワード/塩からIVを生成するだけなので、修正してください。私が間違っている場合。
ソルトのポイントは、 Rainbow tables などの事前計算攻撃を防ぐことです。ソルトがなければ、誰でもハッシュとそれに関連する平文の巨大な辞書を生成し、既知のハッシュをすぐに解読することができます。 saltを使用すると、考えられるすべてのsaltに対してこのようなディクショナリを生成することが不可能になるため、このようなディクショナリは役に立ちません。
ソルトを保存する方法でこの問題をカバーするかなり詳細な記事を書きましたが、これは一読の価値があります。 。
OpenSSLはソルトをパスワードと組み合わせて使用し、2つの値（IVと実際の暗号化キー）を生成します。
暗号化キーは、パスワードとファイルヘッダーに存在するすべてのデータから導出する必要があります（パスワードのみを知っているファイルを復号化できるようにするため）。ただし、同じパスワードを使用するたびに正確に同じキーを取得することは望ましくありません。そうしないと、攻撃者が改ざんを試みる可能性があるためです[〜＃〜] n [〜＃〜][〜＃〜] n [〜＃〜]倍のコストよりも少ないファイルコスト共有の例は、事前計算されたテーブル（パスワードとキーのマッピングのテーブル）です。 Rainbowテーブル は、事前計算されたテーブルの特殊なケースです。
[〜＃〜] iv [〜＃〜] は可能な限り一様にランダムでなければなりません。ここでも、同じパスワードで暗号化されている場合でも、2つの異なるファイルは異なるIVを使用する必要があります。考えられる設計の1つは、ファイルヘッダーにIVを追加することでした（結局のところ、IVは秘密である必要はありません。それ以外の場合は、IVではなくキーと呼びます）。 OpenSSLの開発者は、キーと同じように、パスワードからIVを派生させることを好みました（つまり、パスワードから長いシーケンスを生成し、2つに分割し、半分を暗号化キー、もう半分をIVとします）。 2つの別個のファイルには別個のIVが必要であるため、これは、いくつかの別個の要素がミックスに追加されている限り有効です。塩もそれをします。
OpenSSLで使用される暗号化方式は標準ではないことに注意してください。これは「OpenSSLの機能」ですが、OpenSSLソースコード以外には文書化されていません。暗号化ファイル形式としては、少しお粗末です。特に：
パスワードからキーへの派生で使用する反復の数を構成する方法がないようです。これは問題です構成可能な遅延はパスワードの主要な問題に対処することが重要です。つまり、パスワードは、結局のところ、パスワード、つまり、エントロピーが高すぎないものです。最良の場合。
暗号化システムには [〜＃〜] mac [〜＃〜] が含まれていないため、変更が必ずしも検出されるわけではありません（変更は検出されませんです）パディングされたファイルの最後の2つのブロックが変更されていない場合）。
したがって、可能であれば、パスワードベースのファイル暗号化のためのより優れたツールを使用することをお勧めします。たとえば GnuPG です。