web-dev-qa-db-ja.com

暗号化されたファイルの先頭にソルトおよび/またはIVを書き込んでも安全ですか？

CESモードでAESを使用してファイルを暗号化したい（ファイルの暗号化には別のモードの方が適しているかもしれません...わかりませんが、提案は大歓迎です！）。

私が通常行うことは、最初にいくつかのランダムデータ（256ビット、ただ水を濁すため）を書き込み、次に私の塩とIV（どちらもuuid4 ...または安全なPRNGから生成されたもの）を最初に書き込みます暗号化されたファイル、そして暗号化されたブロック。

そのソリューションは他のものより安全性が低いのだろうか？とにかく、どうすれば他の方法ができるのか本当にわかりません。

encryptionaessalt
17
SuperPython

塩とIVは同じものではありません。 saltはパスワードハッシュ用、IVは一部の暗号化モードの起動用です。ただし、どちらも秘密にすることは意図されていません。それ以外の場合は、それらを「キー」と呼びます。 IVやソルトをファイルヘッダーに含めても安全です。

「数個のランダムデータ（256ビット、ただ水を濁らせるため）」を追加すると、コンピューターを使ってニワトリを犠牲にして神々をなだめます。あなたが気分を良くするためにそのような儀式が必要な場合は、なぜそうしないのですか？しかし、それが実際のセキュリティに何かを変えると信じることは、いくぶん素朴なものになるでしょう。

CBCモードでは、ランダムで予測不可能なIVが必要です。それは難しい要件です。 UUIDの使用は、いくつかの点で危険です。

  • "v4" UUIDのみがPRNGを使用します。
  • UUID v4に使用されるPRNGが暗号学的に強力であることを誰も保証しません。
  • それが強い場合でも、UUIDには6つの固定ビットがあります（「これはv4 UUIDです」と表示されています）。ランダムなビットは122ビットのみです。

CBCはクラス最高のモードではなくなりました。私たちはより良い発見しました。特に：

  • CBCにはIV生成に関する厳しい要件があります（ Chosen-Plaintext Attacks は、IV生成の低下に対して特に効果的であることが示されています）。
  • CBCはパディングを必要とし、パディングの処理はデリケートであることが示されています（復号化が不適切に行われると "padding Oracle" に変わる可能性があります）。
  • CBCは整合性を保証しません。通常、（機密保持のために）暗号化する必要がある場合は、敵対的な変更を確実に検出する必要もあります。そのためには、 [〜＃〜] mac [〜＃〜] が必要です。 MACと暗号化の組み立ては tricky です。

新しいモードでは、単純なIVを許容し（非繰り返しカウンターで十分です）、パディングを必要とせず、統合が適切に行われた統合MACを使用することで、これらの問題を解決します。特に [〜＃〜] gcm [〜＃〜] および [〜＃〜] eax [〜＃〜] を参照してください。

39
Tom Leek

あなたの質問に答えるために：はい、暗号文の最初にIVを書くことは完全に安全です。

ここで「塩」について話すとき、何を指しているのかわかりませんが、理論的には、「塩」はランダムな値であり、一方向のハッシュ関数を通過する前にクリアテキストの値と混合されます。 。これが存在する理由は、誕生日ごとの攻撃や計算されたハッシュテーブルを防ぐために、同じ入力が同じ出力にならないようにするためです。

暗号化の場合、操作モードのIVは同じ機能を提供する必要があります。

どのモードを選択するかは、要件によって大きく異なります。 この回答 と このページ を確認して、いくつかの操作モードとその長所/短所を確認してください。

最終データの正確な要件がわからない場合は、ほとんどの機能を備えたモードを選択する必要があります（おそらくCWCまたはOCM）。

4
Stephane

暗号化されていない、暗号で保護されたハッシュは、メッセージが一意である限り、理論的にはメッセージの内容に関するヒントを提供してはなりません。しかし、メッセージが有限数の既知のメッセージの1つであると盗聴者が疑う場合、ハッシュをこれらの既知のメッセージのハッシュと比較して、それがそれらの1つであることがわかります。

例：著作権で保護された映画の違法コピーを入手したとしましょう。今度はそれをあなたに再配布したいと思います。著作権所有者は私に映画の海賊行為を疑っているため、私たちのつながりを盗聴しています。彼らはインターネット上で流通しているすべての違法コピーを知っており、ハッシュを計算するために自分で入手しました。

私があなたの暗号化スキームを使用するとき、彼らは私が送るファイルのハッシュを見て、それらを彼らがコピーを持っているファイルのハッシュと比較することができました。私のメッセージの1つがハッシュの1つと一致することがわかったとき、暗号化を解読する必要がなくても、著作権で保護されたコンテンツを配布したことが非常に確実に証明されました。

ソルトが暗号化されていない場合、各メッセージのソルトを使用してファイルのハッシュを再計算できるため、ソルトを追加してもあまり役に立ちません。

意味のないデータをハッシュの前の「泥だらけの水」に追加しても、セキュリティは追加されません。暗号分析者がデータを無視できることに気付くのに時間がかかりません。

結論：ハッシュとコンテンツをよりよく暗号化します。

3
Philipp